What changes did you made to tsm operational reporting ? In our environment most of the reports hang and gave no result. Regards Stefan Holzwarth
> -----Ursprüngliche Nachricht----- > Von: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] Im > Auftrag von Sam Sheppard > Gesendet: Samstag, 12. Dezember 2009 01:44 > An: ADSM-L@VM.MARIST.EDU > Betreff: 6.1 experience so far > > After viewing the experiences of others on the list (particularly Mr. > Forray's) and fearing I would jinx myself, I hesitated to > post this, but > decided to go ahead and post our adventures so far. > > We had a visit from our Servergraph rep a couple of weeks ago > and during > the conversation discovered that we seemed to be alone, at least among > their Southern California customers, in implementing TSM Version 6 in > production. We began in September and started with Version 6.1.2. We > are approaching completion of our project to migrate our existing TSM > 5.5.3 servers, two on z/OS and one on Solaris, to TSM Version > 6 on a new > AIX 6.1 P-520 server. > > Our total database size for the three existing servers is about 120GB. > We are sharing a 3494 ATL with 8 TS1120 drives between the Solaris box > and the Version 6 server, with the Version 6 server acting as the > library manager. So we may be somewhat on the small end of the average > customer. > > Since we started on a fresh box, it looks like we have avoided many of > the pitfalls associated with upgrading in place from version 5, but we > did experience what in hindsight look like fairly minor problems: > > IC62978 - active logs fill up due to DB2 table reorg > processes. Fix > was to specify the undocumented ALLOWTABLEREORG NO option. > > IC63373 - while running a large image backup (around 600GB) and > several other clients, received message ANS1316e and ANR0526W, > indicating recovery log out of space, even though we have 30GB and > it's not even close to full. Solution is to do the following to > change a DB2 variable from its standard setting: > > 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. > > IC63637 - We have a large (30-40TB) amount of archived > data to move > from our existing server(s) to version 6. The good news > is that the > large archived image backups exported server-to-server very fast, > around 60MB/sec. The bad new is, the Version 6 library manager > function periodically reclaims a tape drive being used by the > library client, in our case, causing the large > EXPORT/IMPORT process > being run to fail and mark the file being exported at the > time to be > flagged, causing a copy pool tape to be requested if the > process is > restarted. The fix for this was to install version > 6.1.2.1 and then > replace the DSMSERV module with a fix version. > > Database backups suddenly failed for 5 days in a row, but then > started working again when support requested various > documentation. > Looks like DB2 communicates with the TSM server with its own OPT > file, specifying 'localhost' as the TCPSERVERADDRESS, > which appeared > to be failing even though all other functions in the TSM > server were > working fine. Waiting for reoccurence. > > Export Node function apparently does not copy the > MAXNUMMP setting. > > A (relatively) long list of quirks in the ISC, which we forced > ourselves to use while our Servergraph license was updated. Some > of these were only related to Firefox 3.5.4. The worst was a Java > problem that 'unchecked' the 3 'enable sessions' boxes in the > 'Sessions' display of the Server Properties window when > you left the > display and then came back, causing all sessions to be disabled > necessitating a server restart. Using IE, however, the ISC has > become almost bearable and performs much better than previous > versions. > > The Operational Reporter is not officially supported in Version 6, > something we missed, but is easily modified to supply most of the > info needed. > > We have not seen the dreaded huge increase in database size and after > the setting of the ALLOWREORGTABLE option, we haven't had any log > problems either. We are currently running full database backups on > Monday, Wednesday, and Friday, with incrementals in between. Full DB > backup of the 45GB database takes about 6 minutes to a TS1120 drive. > As noted, the current size of our DB is around 45GB with about 2/3 of > our 350 client having been moved. However, the largest of > them, several > Windows file/print servers containing in the neighborhood of > 40 million > files, are still to be moved. We begin testing next week on an NDMP > solution for these, or perhaps experiment with the new > SnapDiff feature. > > Sam Sheppard > San Diego Data Processing Corp. > (858)-581-9668 >