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.ibm.com/support/docview.wss?uid=swg21365583

Regards

Steve

Steven Harris
TSM Admin
Canberra Australia


On 13/03/2013 7:43 AM, Skylar Thompson wrote:

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 (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

On 03/12/13 01:39 PM, Stackwick, Stephen wrote:

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 hundreds of clients. I suppose it's a marvel of TSM that it
works at all on W2K3.

Steve

STEPHEN STACKWICK | Senior Consultant | 301.518.6352 (m) |
Stephen.Stackwick AT icfi DOT com | icfi.com
ICF INTERNATIONAL | 410 E. Pratt Street Suite 2214, Baltimore, MD
21202 | 410.539.1135 (o)

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
Of Zoltan Forray
Sent: Tuesday, March 12, 2013 4:07 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM database randomly failing backup

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
kernel values.
Once we set them to the IBM "recommended" (more like
required) values, my intermittent DB2 backup failures stopped.

Being 32-bit, you might not be able to give it enough memory.

 From this document:

http://www-01.ibm.com/support/docview.wss?uid=swg21421060

It says:

*TSM servers are optimized for and perform best on machines running
with 64-
bit architectures. Versions prior to V6.3 supported running on
32-bit windows. 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, TSM deduplication, or other such
capabilities.*

On Tue, Mar 12, 2013 at 3:59 PM, Stackwick, Stephen <
Stephen.Stackwick AT icfi DOT com> wrote:

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
that might not affect the 64-bit variants, but we're stuck on the
32-bit W2K3 for a while.

This seems to be new with 6.2.5. We recently upgraded from 6.2.3 to
resolve active log issues and the annoying automatic incremental DB
backups.

Anyone else seen this?

Steve

STEPHEN STACKWICK | Senior Consultant | 301.518.6352 (m) |
Stephen.Stackwick AT icfi DOT com<mailto:sstackwick AT icfi DOT com> | icfi.com<
http://www.icfi.com/> ICF INTERNATIONAL | 410 E. Pratt Street Suite
2214, Baltimore, MD 21202 |
410.539.1135 (o)

--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations
will never use
email to request that you reply with your password, social security
number or
confidential personal information. For more details visit
http://infosecurity.vcu.edu/phishing.html