Ah... I know that one.
On linux, to prevent attacks that are based on knowing where a module
gets loaded a randomization is applied. This can cause memory
fragmentation. I had a linux 6.3 box that would run one db backup and
then fail one immediately following or vice versa.
see http://www-01.
Having abundant physical memory in your system doesn't mean that your server
process will get to use it. Operating systems can impose per-process limits,
according to configuration values. See
http://pic.dhe.ibm.com/infocenter/tsminfo/v6r3/index.jsp?topic=%2Fcom.ibm.itsm.srv.install.doc%2Ft_sr
We're running x86_64 Linux servers, with plenty of RAM (48GB in one
server, 64GB in another, no dedupe or node replication) and still get
that error off and on. There's never any paging, either.
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- F
Thanks, Zoltan. From your link:
"In that case, TSM running on a 32-bit architecture will be limited by the
memory available to it and it is not recommended to use those servers for heavy
work-load environments."
Ha! That's what we've been trying to tell everyone for months! >4TB a day, with
hu
We've been getting this off-and-on since v6.2 (we're on v6.3.3.100 now).
I've even run a DB backup within seconds of getting that message, and it
succeeds. Given that it eventually succeeds and doesn't happen very
often, we've just lived with it, although if someone has a fix I'd be
very intereste
Been there - done that - read the book - saw the video.
Just went through this on my Linux servers so I am guessing the resolution
is probably similar.
There are specific memory tuning parameters for DB2 for your OS - things
like memory heap sizes, etc, swap sizes, etc. In my case, it was Linux
Windows 2003 6.2.5:
"ANR4588E A database backup configuration might be incorrect."
This is obviously a bogus message, since sometimes the database *does* back up.
Nothing in the db2diag.log (itself suspicious) or the Windows event logs. The
only thing I can think of is some sort of memory issue
Hi Rick!
This one works like a charm! Thank you very much!
And Andy, thanks for the explanation!
Kind regards,
Eric van Loon
AF/KLM Storage Engineering
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rick
Harderwijk
Sent: dinsdag 12 maart 2013 1
You would expect the SQL world to be standardized, but you will find wide
disparities in implementations and dialects. ENUM is a case in point. In
PostgreSQL, the ENUM type is actually a data type separate from the built in
NUMERIC and TEXT data types, so the regular numeric and string operat
Andy,
Thanks :-) the 50 character limit is a good addition indeed.
Not sure which one yields a better performance, though, might be something
worth looking into.
Cheers,
Rick
On Tue, Mar 12, 2013 at 12:20 PM, Andrew Raibeck wrote:
> I actually like this solution even more than the one I gave
I actually like this solution even more than the one I gave a moment ago!
One comment: I suggest "cast(type as char(50))" instead of just "cast(type
as char)", do avoid a truncation warning.
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Interna
Eric,
If you examine the COLUMNS table for the BACKUPS table, you will see that
the TYPE column is of type "ENUMERATED(OBJECT_TYPE)":
tsm: TSMSERVER1>select colname,typename from columns where
tabname='BACKUPS'
COLNAMETYPENAME
-- --
NODE_NAME
Eric,
How about
select * from backups where node_name='KL127EAC' and cast(type as char)
like 'IMAGE%'
Cheers,
Rick
On Tue, Mar 12, 2013 at 11:57 AM, Loon, EJ van - SPLXM <
eric-van.l...@klm.com> wrote:
> Hi Ulli!
> Unfortunately the same error:
>
> ANR2921E The SQL data type of expression 'BA
Hi Ulli!
Unfortunately the same error:
ANR2921E The SQL data type of expression 'BACKUPS.TYPE' is
ENUMERATED(OBJECT_TYPE); expecting a character string expression.
Kind regards,
Eric van Loon
AF/KLM Storage Engineering
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.
Hi Rick!
Yes, I tried IMAGE*, it returns the same error...
Kind regards,
Eric van Loon
AF/KLM Storage Engineering
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Rick Harderwijk
Sent: dinsdag 12 maart 2013 11:14
To: ADSM-L@VM.MARIST.EDU
Subject:
Eric,
Maybe the wildcard % is not valid for the datatype of TYPE which is
ENUMERATED(OBJECT_TYPE).
Have you tried * ?
Rick
On Tue, Mar 12, 2013 at 10:49 AM, Loon, EJ van - SPLXM <
eric-van.l...@klm.com> wrote:
> Hi TSM-ers!
>
> I'm trying to retrieve all image backups for a specific node. I'm
>
Hi Eric,
try to add the table name as follows:
select * from backups where backups.node_name='KL127EAC' and backups.type
like 'IMAGE%'
good luck
regards
Ulli
Ullrich Mänz
Data Center Services
FRITZ & MACZIOL Software und Computervertrieb GmbH
Ludwig Str. 180D, 63067 Offenbach, Germany
Mo
Hi TSM-ers!
I'm trying to retrieve all image backups for a specific node. I'm
issuing the following query:
select * from backups where node_name='KL127EAC' and type like 'IMAGE%'
This returns the following error:
ANR2921E The SQL data type of expression 'TYPE' is
ENUMERATED(OBJECT_TYPE
18 matches
Mail list logo
