Sorry, I do not have details about that problem any longer. I experienced it
some weeks ago and gave up.
After changing the default queries and my customized one's according to the tsm
blog they work again :-)
Thanks a lot
Stefan Holzwarth
> -----Ursprüngliche Nachricht-----
> Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im
> Auftrag von Wanda Prather
> Gesendet: Montag, 14. Dezember 2009 20:16
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: AW: 6.1 experience so far
>
> 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
> > >
> >
>
|
