Hi John,
The undocumented 'SHow LOGPIn' command works well:
**********************************
TSM>sh logpi
Dirty page Lsn=24594790.225.3369, Last DB backup Lsn=24594791.3.3978,
Transaction table Lsn=24593189.104.932, Running DB backup
Lsn=0.0.0, Log truncation Lsn=24593189.104.932
Lsn=24593189.104.932, Owner=DB, Length=64
Type=Update, Flags=C2, Action=SetRange, Page=21311247, Tsn=0:3.3964001625,
PrevLsn=0.0.0, UndoNextLsn=0.0.0, UpdtLsn=24593188.36.1603
===> Start=31967, Count=64
(1592112) Generating SM Context Report:
(1592112) *** no sessions found ***
(132) Generating SM Context Report:
(132) *** no sessions found ***
(1592111) Generating SM Context Report:
(1592111) Session 689954: Type=Node, Id=NEREID.CIT.NIH.GOV
<<============
(1592111) Platform=SUN SOLARIS, NodeId=609, Owner=
(1592111) SessType=4, Index=15, TermReason=0
(1592111) RecvWaitTime=0.000 (samples=0)
(1592111) Backup Objects ( bytes ) Inserted: 108 ( 0.12900381 )
(1592111) Backup Objects ( bytes ) Restored: 0 ( 0.0 )
(1592111) Archive Objects ( bytes ) Inserted: 0 ( 0.0 )
(1592111) Archive Objects ( bytes ) Retrieved: 0 ( 0.0 )
(1592111) Last Verb ( ConfirmResp ), Last Verb State ( Sent )
Session 689954 is assoicated with this transaction.
**********************************
There's some useful information in this output (nodename, session) thought most
of it is for internal use. It is also one of the few places where you can find
the NodeId (in line below the <<====) equated to the nodename -- handy for a
couple of other undocumented commands where you get the nodeID but not
nodename.
Armed with this info you may be able to 'tune' your schedules to ease the
apparent conflict. It may be helpful to issue this command every 'xx' minutes
and pipe the output to a file...the only thing the output is missing is a
timestamp.
Susie
------------------------------
Date: Wed, 25 Jul 2012 21:58:57 -0400
From: "Dury, John C." <JDury AT DUQLIGHT DOT COM>
Subject: backup tape stgpool to tape stgpool pins recovery log
I have 2 sl500 tape libraries attached via dark fiber (which doesn't appear=
to be getting anywhere close to the speeds it should but that's another is=
sue) to an AIX TSM 5.5 server. One is copy storage pool and the other a pr=
imary. I backup the primary to the copy storage pool daily. This process is=
taking an extremely long time and seems to hang because there is at least =
one extremely large file that while it is copying, pins the recovery log an=
d does not finish before the recovery log is over 80% which then causes TSM=
to slow to a crawl so I end up cancelling the backup storage pool process.=
This is hanging my TSM server on a daily basis because the recovery keeps=
getting pinned by the backup storage process.
Is there any way at all I can find out what node or node and filespace, is =
taking so long to backup so I can verify it really needs to be backed up at=
all?
------------------------------
|