Dave, Thanks for the response.
As I suspect, the oldest thread is from 03/07/2011. I have 2-IMPORT processes that hung (one started 03/07/2011 the other 04/19/2011) since the exporting server had a tape-mount problem and the exports died. I have long since tried to cancel the imports, to no avail. A "q proc" just shows "cancel in process". I wasn't sure of the proper syntax for the "show threads" command and just used the ThreadID and used it. In this case: Start ThreadId=137117, Timestamp=03/07/2011 12:35:37 PM, (the oldest) and did a "show threads 137117" to get: ------------------------------------------------- 12:34:20 PM SUN : show threads 137117 Server PID: 8520 Active threads: 126 Zombie threads: 0 Cached descriptors: 6 Thread 1, Parent 0: main, Storage 6203696, AllocCnt 8342 HighWaterAmt 6203696 tid=1971136576, ptid=<none>, det=0, zomb=0, join=0, result=0, sess=0 Thread 2, Parent 1: TmDeadlockDetector, Storage 0, AllocCnt 0 HighWaterAmt 0 tid=1086736704, ptid=1971136576, det=1, zomb=0, join=0, result=0, sess=0 Thread 3, Parent 1: TbCacheMonitorThread, Storage 0, AllocCnt 2081959 HighWaterAmt 0 tid=1099311424, ptid=1971136576, det=0, zomb=0, join=0, result=0, sess=0 Thread 4, Parent 1: AdmActivityLogThread, Storage 0, AllocCnt 20132093 HighWaterAmt 114297 tid=1105582400, ptid=1971136576, det=1, zomb=0, join=0, result=0, sess=0 Awaiting cond descP->outReady (0x0x2b7879076ee0), using mutex OUTV->mutex (0x0xb5de3e8), at output.c(3292) Thread 13, Parent 1: NaDiscoverThread, Storage 733, AllocCnt 14 HighWaterAmt 37761 tid=1100364096, ptid=1971136576, det=1, zomb=0, join=0, result=0, sess=0 Awaiting cond NAV->checkConfig (0x0x2b78790770a0), using mutex NAV->mutex (0x0xb7be7b8), at nadiscvr.c(2137) Thread 14, Parent 1: RemAgent, Storage 0, AllocCnt 0 HighWaterAmt 0 tid=1102469440, ptid=1971136576, det=1, zomb=0, join=0, result=0, sess=0 Awaiting cond MMSV->remCond (0x0x2b7879077180), using mutex MMSV->mutex (0x0x2aaab0009638), at mmsop.c(1409) Thread 15, Parent 1: PollAgent, Storage 0, AllocCnt 0 HighWaterAmt 0 tid=1101416768, ptid=1971136576, det=1, zomb=0, join=0, result=0, sess=0 (lot of snippage to not anger the listserv gods....................) Awaiting cond descP->outReady (0x0x2b78790900f0), using mutex OUTV->mutex (0x0xb5de3e8), at output.c(3292) Thread 517131, Parent 517130: SmAdminCommandThread, Storage 253205, AllocCnt 4574 HighWaterAmt 321609 tid=1120319808, ptid=1201375552, det=0, zomb=0, join=0, result=0, sess=0 Holding mutex THRV->mutex (0x0xb5ea958), acquired at pkthread.c(2397) Server PID: 8520 Active threads: 126 Zombie threads: 0 Cached descriptors: 6 ---------------------------------------------------------------------- I know there are fixes to import in 6.2.2.2 so I am going straight to 6.2.2.30 On Mon, May 2, 2011 at 12:26 PM, Dave Canan <ddca...@gmail.com> wrote: > Zoltan, there is no "show logpinned" command in V6.2.2, but it is still > possible to figure out which session and transaction is causing the log to > be pinned. Here is an example of what you would need to do: > This isn't quite as straight-forward as the old show command, but this will > work. Call or re-post if you have questions. > > > 1. You need to start with doing a "show txnt" command. Here is an example > of > one: > > > Session established with server xxxxxxx: AIX > Server Version 6, Release 2, Level 2.0 > Server date/time: 05/02/11 12:09:43 Last access: 05/02/11 12:09:30 > > > tsm: xxxxxxx>show txnt > > Transaction hash table contents (slots=256): > slot -> 38: > Tsn=0:688678, Resurrected=False, InFlight=True, Distributed=False, > Persistent=True, Addr 113001ab8 > Start ThreadId=17986, Timestamp=05/02/11 12:10:06, Creator=imdmgr.c(3552) > Last known in use by ThreadId=17986 > Participants=1, summaryVote=ReadOnly > EndInFlight False, endThreadId 0, tmidx 0 0, processBatchCount 0, > mustAbort > False. > Participant DB: voteReceived=False, ackReceived=False > DB: Txn 11295a158, ReadOnly(YES), connP=1128ab1f8, applHandle=23208, > openTbls=2: > DB: --> OpenP=115facf38 for table=Management.Classes. > DB: --> OpenP=116eba978 for table=Management.Class.Ids. > DB: --> RegSqlId=0x03000000 SELECT for table=Backup.Objects, > executed(Yes). > slot -> 39: > Tsn=0:688679, Resurrected=False, InFlight=True, Distributed=False, > Persistent=True, Addr 115646a78 > Start ThreadId=17986, Timestamp=05/02/11 12:10:06, Creator=imdmgr.c(3673) > Last known in use by ThreadId=17986 > Participants=2, summaryVote=ReadOnly > EndInFlight False, endThreadId 0, tmidx 0 0, processBatchCount 0, > mustAbort > False. > Participant DB: voteReceived=False, ackReceived=False > DB: Txn 112f855b8, ReadOnly(NO), connP=112ef88f8, applHandle=23205, > openTbls=24: > DB: --> OpenP=1147eded8 for table=Activity.Summary. > DB: --> OpenP=118b7e038 for table=Group.Objects.ByLeader. > DB: --> OpenP=112fbdcf8 for table=Backup.Objects. > DB: --> OpenP=11300d3d8 for table=Group.Leaders. > DB: --> OpenP=11730b3b8 for table=AS.Volume.Status. > DB: --> OpenP=11307a7b8 for table=AF.Vol.Clusters. > DB: --> OpenP=11743acd8 for table=AF.Clusters. > DB: --> OpenP=117335198 for table=BF.Dereferenced.Chunks. > DB: --> OpenP=112fa2bb8 for table=DF.Segments. > DB: --> OpenP=113084658 for table=AS.Segments. > DB: --> OpenP=1160b65b8 for table=AF.Damaged. > DB: --> OpenP=112fe8b78 for table=BF.Bitfile.Extents. > DB: --> OpenP=115641438 for table=AF.Segments. > DB: --> OpenP=115f7d578 for table=AF.Bitfiles. > DB: --> OpenP=114536ad8 for table=DF.Bitfiles. > DB: --> OpenP=11303ff78 for table=BF.Aggregate.Attributes. > DB: --> OpenP=118c62eb8 for table=BF.Aggregated.Bitfiles. > DB: --> OpenP=1170581d8 for table=ARCH_EXPDIRS. > DB: --> OpenP=1147ec498 for table=Archive.Objects. > DB: --> OpenP=11604ddb8 for table=Management.Class.Ids. > DB: --> OpenP=116e91c98 for table=Management.Classes. > DB: --> OpenP=113034e98 for table=Filespaces. > DB: --> OpenP=1144d3e38 for table=Nodes. > DB: --> OpenP=114d1ce58 for table=Policy.Domain.Members. > Participant IM: voteReceived=False, ackReceived=False > Locks held by Tsn=0:688679 : > Type=19002(im node filespace), NameSpace=0, SummMode=xLock, Mode=xLock, > Key='154.1' > Type=19001(im node), NameSpace=0, SummMode=ixLock, Mode=ixLock, > Key='154' > Type=19000(im universe), NameSpace=0, SummMode=ixLock, Mode=ixLock, > Key='' > slot -> 165: > Tsn=0:692901, Resurrected=False, InFlight=True, Distributed=False, > Persistent=True, Addr 114532178 > Start ThreadId=17984, Timestamp=05/02/11 12:10:07, Creator=imdmgr.c(2460) > Last known in use by ThreadId=17984 > Participants=1, summaryVote=ReadOnly > EndInFlight False, endThreadId 0, tmidx 0 0, processBatchCount 0, > mustAbort > False. > > 2. What you're going to want to do is look at the lines that state "Start > Threadid=nnnnn, Timestamp=". You need to find the oldest Timestamp. That > will also give you the threadid. From there you do a "show threads" > command. > Here is a piece from that command : > > Thread 17980, Parent 42: psSessionThread, Storage 0, AllocCnt 490 > HighWaterAmt > 174080 > tid=253c, ptid=1e2a, det=1, zomb=0, join=0, result=0, sess=4612 > Holding mutex OUTV->mutex (0x112018018), acquired at output.c(3267) > > Stack trace: > 0x0900000000595f30 _cond_wait_global > 0x0900000000596abc _cond_wait > 0x09000000005977ac pthread_cond_wait > 0x0000000100008414 pkWaitConditionTracked > 0x00000001000130f8 outGetNext > 0x0000000100870e58 SmAdminOutput > 0x000000010086ffb8 SmExecuteAdminCommand > 0x000000010086f888 SmAdminSession > 0x00000001003f123c DoAdminGeneral > 0x00000001003ec9bc smExecuteSession > 0x000000010009ad48 psSessionThread > 0x000000010001b688 StartThread > > > 3. Look for the thread Id for the longest running transaction in the first > step. This will also point you to the session matching that thread. From > there, the session (that is the longest running transaction), can be > canceled. > > > Dave Canan > IBM ATS TSM Performance > ddcananATUSDOTIBMDOTCOM > 916-723-2410 > > > On Fri, Apr 29, 2011 at 5:50 AM, Zoltan Forray <zforray....@gmail.com > >wrote: > > > Yes, I realize 6.x is DB2 but I was wondering is there is an equivalent > to > > "show logpinned". I seem to be in some kind of situation where the logs > are > > not being released and growing daily, eventhough I have performed > numerous > > full DB backups and backup volhist. > > > > I am going to have to bounce it soon, if I can't kill whatever is holding > > things up. > > > > My suspicion is a hung import. I have been moving numerous nodes from an > > old 5.5 server and along the way at least 2-export/imports have crashed > for > > various reasons and left zombie imports on the 6.2.2 server (yes I tried > > cancel proc with no results other than "cancel in progress") > > > > -- > > Zoltan Forray > > TSM Software & Hardware Administrator > > Virginia Commonwealth University > > UCC/Office of Technology Services > > zfor...@vcu.edu - 804-828-4807 > > Don't be a phishing victim - VCU and other reputable organizations will > > never use email to request that you reply with your password, social > > security number or confidential personal information. For more details > > visit > > http://infosecurity.vcu.edu/phishing.html > > > -- Zoltan Forray TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
