1) When you say "hang": if you enter q session, do you see a hung session
for the admin id the reporter uses?
3) If you look at the actlog, is the last query the Daily Reporter issues
before it hangs a SELECT against the EVENTS table?
If so it may be a known bug querying the events table, I can send you more
info to get around it...
On Mon, Dec 14, 2009 at 3:08 AM, Stefan Holzwarth
<stefan.holzwarth AT adac DOT de>wrote:
> 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
> >
>
|
