Seem's to me I'm hit by IC63373 -despit eit should be fixed in 6.1.2.
Will change the value and report results next week.
Regards
Stefan Holzwarth
ERROR DESCRIPTION:
If in the Tivoli Storage Manager server options file dsmserv.opt
the size of the active log (ACTIIVELOGSIZE) is changed,
the DB2 configuration parameter NUM_LOG_SPAN does not get
updated correctly.
The NUM_LOG_SPAN setting is used by Tivoli Storage Manager to
manage how much of the active log a transaction can span.
This value should represent 90% of the number of primary log
files (LOGPRIMARY) which each is be default 512MB in size.
So for the default Tivoli Storage Manager active log size of
2GB, 4 primary log volumes are used and Tivoli Storage Manager
sets NUM_LOG_SPAN to 90% of this size (3 volumes). When the
size of the active log (ACTIIVELOGSIZE) is increased in the
dsmserv.opt file, the NUM_LOG_SPAN is not updated to represent
90% of the new log size in DB2. This can cause in the worst case
a crash of the Tivoli Storage Manager server in case of a long
running transaction which spans over more volumes than allowed
by the NUM_LOG_SPAN value.
LOCAL FIX:
The work around is to manually calculate 90% of the log size and
update the db2 database to correctly set NUM_LOG_SPAN.
Calculate correct value of NUM_LOG_SPAN (each log size is fixed
at 512MB):
1. Take the new value of activelogsize in dsmserv.opt in and
divide that by 512MB. This value is the total number of log
volumes reflected in db2 value LOGPRIMARY.
2. Multiple LOGPRIMARY by 90%. This value should be reflected in
NUM_LOG_SPAN.
(alternate method involving slightly less arithmetic)
Calculate correct value of NUM_LOG_SPAN:
1. Use the following db2 command to determine the number of log
volumes used:
db2 get db cfg for TSMDB1
2. Multiply the value for the LOGPRIMARY parameter by 90%. This
value should be reflected in NUM_LOG_SPAN.
Update NUM_LOG_SPAN by issuing the following db2 command:
db2 update db cfg for TSMDB1 using NUM_LOG_SPAN <newValue>
You may need to restart the TSM server, which will restart the
db2 database as well.
> -----Ursprüngliche Nachricht-----
> Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im
> Auftrag von Kelly Lipp
> Gesendet: Freitag, 2. Oktober 2009 17:50
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: AW: TSM 6.1 and the ever expanding DB
>
> That last paragraph made my head hurt! I had the
> "opportunity" to take a database class in college. Didn't
> want to know it then, don't want to know it now.
>
> I recall one of the design centers for the DB2 thing was to
> ensure that a TSM admin didn't need to become a DB2 admin. I
> don't even know the lingo!
>
> I'll echo Rick's comments: you pioneers, you go! Those
> arrows don't hurt that much. That which doesn't kill you
> makes you and all of us stronger.
>
> Kelly Lipp
> Chief Technical Officer
> www.storserver.com
> 719-266-8777 x7105
> STORServer solves your data backup challenges.
> Once and for all.
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]
> On Behalf Of Richard Rhodes
> Sent: Friday, October 02, 2009 9:26 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] AW: TSM 6.1 and the ever expanding DB
>
> I've been watching this discussion with great interest, and
> more than a
> little fear.
>
> We are going to implement the v6 ISC/SC shortly on a
> standalone Win server,
> but we aren't planning to upgrade the TSM servers until next
> year. A BIG
> thanks to all you bleeding edge types out there!!!!
>
> IBM has a interesting/hard problem - TSM is used to backup
> TSM. I assume
> the requirement for multiple backups before a archive log is
> deleted is to
> ensure that multiple backups occur for each archive log. They are
> effectively throwing disk space at the archive logs to ensure
> they have
> good over lapping backups of them.
>
> I wonder if IBM isn't eventually going to have to implement
> some process
> that will periodically backup archive logs, make a second
> copy of them on
> different media, generate a Vol_Hist, a prepare(?), then
> delete the archive
> logs. In other words, on some trigger make a good backup of
> all archive
> logs (multiple copies on separate media) and everything needed for a
> recovery from the last full - roll forward through archive
> logs - then the
> active log.
>
> Rick
>
>
>
>
>
>
>
>
>
> Zoltan
>
> Forray/AC/VCU
>
> <zforray AT VCU DOT EDU>
> To
> Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
>
> Dist Stor
> cc
> Manager"
>
> <[email protected]
> Subject
> .EDU> Re: AW: TSM 6.1 and
> the ever
> expanding DB
>
>
>
> 10/02/2009 10:52
>
> AM
>
>
>
>
>
> Please respond to
>
> "ADSM: Dist Stor
>
> Manager"
>
> <[email protected]
>
> .EDU>
>
>
>
>
>
>
>
>
>
> Good luck with the PMR. Let us know how it works out.....
>
> As I understand it, currently this is WAD (requiring 2+ full
> backups and
> corresponding volhist backups before clearing the archivelog).
>
> It is also my understanding (from my last conversation with
> an L2 tech at
> IBM) that they know this is a problem and hope to reduce the
> requirements,
> in future (V6.2?) releases. They still have numerous DB2/TSM
> interaction
> bugs to squash, first!
>
>
>
> From:
> Stefan Holzwarth <stefan.holzwarth AT ADAC DOT DE>
> To:
> ADSM-L AT VM.MARIST DOT EDU
> Date:
> 10/02/2009 10:16 AM
> Subject:
> [ADSM-L] AW: TSM 6.1 and the ever expanding DB
> Sent by:
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
>
> We want also to go into production with 6.1.2. All setup is finished.
> But with about 20 nodes (all export/import) we continously
> have trouble
> with full active log and full archivelog.
> Our active log size is 16Gbyte and it seems to be enough for
> this small
> setup. But sometimes the log usage explodes and goes rapidly up to the
> limit.
> I opened my second PMR....
>
> Regards
> Stefan Holzwarth
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im
> > Auftrag von Zoltan Forray/AC/VCU
> > Gesendet: Freitag, 2. Oktober 2009 15:15
> > An: ADSM-L AT VM.MARIST DOT EDU
> > Betreff: Re: TSM 6.1 and the ever expanding DB
> >
> > Join the club. I am beginning to wonder if anyone is
> > successfully using
> > V6.1, trouble-free.
> >
> > Monday I decided to put my 6.1.2 server into production and
> > am wondering
> > if this was a really bad decision.
> >
> > I have had to bounce it 5-times due to it simply hanging/going
> > non-responsive eventhough the only "activity" has been
> > exporting a large
> > node from another server.
> >
> > The primary active log has been expanded 3-times (from 20GB to 60GB)
> > eventhough I run 3-full DB backups daily.
> >
> > I had to reserve 300GB for the archivelog space.
> >
> > The DB has grown to 65GB for 4-nodes eventhough the original
> > server with
> > 250-nodes is only 80GB used.
> >
> > The diagnostic information for DB/log errors is fairly
> > useless. The book
> > says to go to DB2 to get it to explain the SQL????? errors,
> > eventhough in
> > other places the book says to not mess with DB2 ("pay no
> > attention to the
> > man behind the curtain......"). I am having to become way more
> > knowledgeable in DB2 than I ever wanted to be ("Damn it,
> > Jim.....I am the
> > backup/TSM administrator - not a DBA!" - apologies to
> DeForest Kelley)
> >
> > Just got my 5th SQL error this week ("10/2/2009 8:49:46 AM ANR0162W
> > Supplemental database diagnostic information: -1:22003:-413
> > ([IBM][CLI
> > Driver][DB2/LINUXX8664] SQL0413N Overflow occurred during
> > numeric data
> > type conversion. SQLSTATE=22003")
> >
> > I have to run 3-full DB backups every day (along with the now added
> > 3-BACKUP VOLHIST) just to try to keep ahead of what I
> > consider normal,
> > daily activity (never had to do this on V5.x - daily DB
> > incrementals use
> > to be more than enough - heaven help me if I get this
> server up to the
> > size of my biggest V5 server which has a 150GB DB - I could
> > never backup
> > the DB fast enough to keep it from crashing).
> >
> > ---------------
> >
> > How about an informal poll.
> >
> > How many folks are running V6.1.2 servers in production?
> >
> > How big (occupancy? DB size? Number of active nodes?)
> >
> > What platform?
> >
> >
> >
> > From:
> > "Gill, Geoffrey L." <GEOFFREY.L.GILL AT SAIC DOT COM>
> > To:
> > ADSM-L AT VM.MARIST DOT EDU
> > Date:
> > 10/01/2009 08:12 PM
> > Subject:
> > [ADSM-L] TSM 6.1 and the ever expanding DB
> > Sent by:
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >
> >
> >
> > I'm finding that what I know about how the DB works in 5.5 doesn't
> > really equal how it works in 6.1. On a Linux box I brought up
> > to migrate
> > clients to a 6.1 server I created a 20GB log and 100GB DB.
> There 'will
> > be' about 150 nodes moved to this instance but currently
> about 20 are
> > backing up. My 5.5 server, on AIX 5.3, has a 125GB DB about
> > 50% used, a
> > 11GB log and it backs up 500+ clients per day with no issues.
> >
> >
> >
> > Last nights backup on the new box is telling me there is no
> more space
> > in the database so backups are failing. After backing up
> > systems for 30
> > days? I find that way out of whack from how 5.5 works and it
> > seems to be
> > telling me I need more than 10 times the space to keep 6.1
> up. I can't
> > believe 20 computers have eaten up 100GB of DB space in such a short
> > period of time.
> >
> >
> >
> > I have a case open with IBM to discuss but I'm wondering what
> > others are
> > finding that are using 6.1. Perhaps I'm missing something
> in my setup
> > that is causing the problem (I hope) because if not I don't
> > want to even
> > think about how much disk I have to add to the current box so I can
> > upgrade it and make it run with the 400+ systems that will
> stay on it.
> >
> >
> >
> > Anyone else seeing this or have an idea what I may have missed?
> >
> >
> >
> > Geoff Gill
> > TSM/PeopleSoft Administrator
> >
> > SAIC M/S-B1P
> >
> > 4224 Campus Pt. Ct.
> >
> > San Diego, CA 92121
> > (858)826-4062 (office)
> >
> > (858)412-9883 (blackberry)
> >
>
>
> -----------------------------------------
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
> the reader of this message is not the intended recipient or an
> agent responsible for delivering it to the intended recipient, you
> are hereby notified that you have received this document in error
> and that any review, dissemination, distribution, or copying of
> this message is strictly prohibited. If you have received this
> communication in error, please notify us immediately, and delete
> the original message.
>
|
