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:ADSM-L AT VM.MARIST DOT EDU] Im
> Auftrag von Sam Sheppard
> Gesendet: Samstag, 12. Dezember 2009 01:44
> An: ADSM-L AT VM.MARIST DOT 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
>
|
