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.