part1: recover postponed thread, retain locks (DB2 for OS390 V6.1)

Kadir Guray Meric

part1: recover postponed thread, retain locks (DB2 for OS390 V6.1)
Hi to everyone in the list,
This mail is part1, next mail is part2 for the same problem. It is because of the message size limit.

We have a problem regarding recover postponed threads, retain locks. We have DB2 for OS390 V6.1 with 3 data sharing members.
From DB1T data sharing member DB2 log,we see that a batch job was run, and it caused
STC06830 DSNR035I +DB1T DSNRPBCW WARNING -
UNCOMMITTED UR AFTER 576 CHECKPOINTS - message.
Log volumes were full.Afterwards,DB2 was restarted.This message occured in the log:
STC06758 DSNR004I +DB1T RESTART...UR STATUS COUNTS IN COMMIT=0, INDOUBT=0, INFLIGHT=0, IN ABORT=1, POSTPONED ABORT=0
STC06758 DSNR007I +DB1T RESTART...STATUS TABLE
T CON-ID CORR-ID AUTHID PLAN S URID DAY TIME
B BATCH N812I370 SDBA1 PDTUK99 A 002AB444A3B2 344 17:31:37
DSNI023I +DB1T DSNIERST PAGESET DDTUK00 .SDTUKG25
PART (n/a)
IS AREST ON BEHALF OF UR 002AB444A3B2. BACKOUT TO
LRSN B8A856668BC5 IS REQUIRED.
DSNI023I +DB1T DSNIERST PAGESET DDTUK00 .XTUK1SKP
PART (n/a)
IS AREST ON BEHALF OF UR 002AB444A3B2. BACKOUT TO
LRSN B8A856668C5B IS REQUIRED.
With "-dis db (DDTUK00) spacenam(SDTUKG25) locks" commands, we see:
DSNT397I +DB1T
NAME TYPE PART STATUS CONNID CORRID LOCKINFO
SDTUKG25 TS RW,AREST H-X,PP,I
- MEMBER NAMEDB1T
SDTUKG25 TS RW,AREST R-IX,S
- MEMBER NAME DB1T
176 TB R-IX,T
- MEMBER NAME DB1T
Output of "-dis group" command is below:
MEMBER ID SUBSYS CMDPREF STATUS LVL NAME SUBSYS IRLMPROC
DB1T 1 DB1T +DB1T AI 610 TD90 DJ1T DB1TIRLM
DB2T 2 DB2T +DB2T ACTIVE 610 TD91 DJ2T DB2TIRLM
DB3T 3 DB3T +DB3T ACTIVE 610 TD91 DJ3T DB3TIRLM

since the limit on mail size, this mail will be continued on next mail, part 2.

Kadir Guray MERIC
Data Management Specialist

Ali OZTURK

Re: part1: recover postponed thread, retain locks (DB2 for OS390 V6.1)
(in response to Kadir Guray Meric)
Hi Kadir,
You mentioned your note that the log volumes are full.
After DB2 RESTART, did you check any available log dataset ? DB2 need available log dataset to write roolback records. If there is not, you should provide some available log dataset via ARCHIVE LOG command or add a new log dataset ?

Best regards.


Kadir Guray Meric

Re: part1: recover postponed thread, retain locks (DB2 for OS390 V6.1)
(in response to Ali OZTURK)
Hi Ali,

I have checked the point you suggested about available log datasets.

When we use recover postponed, abort status changes from P to PSTRT.

ABORT-P: This line represents a Postponed Abort UR.

Objects for which this UR has backout work pending are

inaccessible (Restart Pending) until the abort is

completed (for example, by means of the -RECOVER POSTPONED

command).

ABORT-PSTRT: This line represents a Postponed Abort UR

that is currently undergoing -RECOVER POSTPONED processing

or automatic DB2 backout processing (requested by

restarting with system parameter LBACKOUT =3D AUTO).

We see that we are now in ABORT-PSTRT state.DB1T/RESTART NEEDS UNIT FOR

VOL SER message comes. We supply volumes, and backout continues. It

takes to much time for DB2 to recover postponed threads,I think the

only way to do is just to wait for DB2 to complete.

"Ali Ozturk"

wrote in message news:



Hi Kadir,

You mentioned your note that the log volumes are full.

After DB2 RESTART, did you check any available log dataset ? DB2 need available log dataset to write roolback records. If there is not, you should provide some available log dataset via ARCHIVE LOG command or add a new log dataset ?


Best regards.




----------