Glad to help.
BTW, I forgot to mention (since Richard Sims usually responds very
quickly), that this plus other undocumented "show" commands are on the
ADSM Quickfacts webpage at:
http://people.bu.edu/rbs/ADSM.QuickFacts
There are 9-LOG related "show" commands listed !
PAC Brion Arnaud <Arnaud.Brion AT PANALPINA DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
09/09/2005 10:04 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
Re: [ADSM-L] Need tool to give evidence that "repair stgvol" command is
pinning the log
Zoltan,
Looks like you won gold medal on that one !
Many thanks.
Regards.
Arnaud
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Friday, 09 September, 2005 16:00
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Need tool to give evidence that "repair stgvol" command is
pinning the log
Have you tried:
show logpinned
PAC Brion Arnaud <Arnaud.Brion AT PANALPINA DOT COM> Sent by: "ADSM: Dist Stor
Manager" <ADSM-L AT VM.MARIST DOT EDU>
09/09/2005 09:45 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
[ADSM-L] Need tool to give evidence that "repair stgvol" command is
pinning the log
Hi all,
Some weeks ago our TSM server (5.3.1.4 on AIX) had problems while
performing reclamation, and began issuing lots of "ANR0102E
asalloc.c(XXX): Error 1 inserting row in table AS.Segments" messages. I
consequently opened a PMR, and got the advice to perform a "repair
stgvol" command against the volume being reclamed, which solved the
problem.
However, on the same day, a new problem appeared : TSM's log began
growing endlessly, although I had a database trigger defined at 50 %,
which started to chain up Dbbackups, each of them resulting in a message
in the activity log looking like "ANR4556W Attention: the database
backup operation did not free sufficient recovery log space to lower
utilization below the database backup trigger....". I had no other mean
than restarting the server to get the log freed again ...
Yesterday, same problem happened and I'm now 99,99% sure that this
"repair stgvol" is guilty. However, before reporting this to IBM, I
would like to have the certainty that my assertion is right. Does anyone
know some command that would show which process is pinning the log ?
Thanks in advance !
Regards.
Arnaud
|