ca.portal.admin

Transaction ID overflowing

Discussion created by ca.portal.admin on Jun 4, 2008
Probably not an issue that will affect many sites, but it caught us out.

A very active CV, whose journals haven't been formatted for about 2 1/2
years. Transaction ID eventually reached and exceeded 2,147,483,647
(x'7FFFFFFF').No indication at this point of any problem; no warning
messages issued.

About a week later, CV issued DC203006 - Unable to find BGIN/COMT Ckpts
for all active Transactions

Further examination showed no condensed segments on the disk journals,
and that the rununit the CV was trying to recover spanned two journals.
The condense phase of archive journal seems to have got confused by the
decreasing transaction ID (this is our belief), and didn't create any
condensed segments on the journal being offloaded. Anything which tries
to rollback, and goes to an older journal than the current one is going
to have a real problem. Obviously, anything rolling back and using only
the currently active journal will be OK.

Side effect of this is that CV won't shutdown, as it's waiting for a
transaction to recover. Obviously warmstart will fail too.

We got lucky - the transaction that had the problem was updating an area
used for holding information about DMLO sessions. Had it been a real
database area, we'd have had problems.

CA are investigating the problem at the moment.

Iain Robertson
BT Operate, Senior DBA
Email: iain.dk.robertson@bt.com
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Transaction ID overflowing
"Probably not an issue that will affect many sites, but it caught us out.

A very active CV, whose journals haven't been formatted for about 2 1/2
years. Transaction ID eventually reached and exceeded 2,147,483,647
(x'7FFFFFFF').No indication at this point of any problem; no warning
messages issued.

About a week later, CV issued DC203006 - Unable to find BGIN/COMT Ckpts
for all active Transactions

Further examination showed no condensed segments on the disk journals,
and that the rununit the CV was trying to recover spanned two journals.
The condense phase of archive journal seems to have got confused by the
decreasing transaction ID (this is our belief), and didn't create any
condensed segments on the journal being offloaded. Anything which tries
to rollback, and goes to an older journal than the current one is going
to have a real problem. Obviously, anything rolling back and using only
the currently active journal will be OK.

Side effect of this is that CV won't shutdown, as it's waiting for a
transaction to recover. Obviously warmstart will fail too.

We got lucky - the transaction that had the problem was updating an area
used for holding information about DMLO sessions. Had it been a real
database area, we'd have had problems.

CA are investigating the problem at the moment.

Iain Robertson
BT Operate, Senior DBA
Email: iain.dk.robertson@bt.com
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: getting ptfs for IDMS
"Chris

I just tried this and it seemed to work (I used WsFTP - your usage might
vary)

Step 1. Log into the CA site: ftp.ca.com
Step 2. Change the directory To: /apars/d8/pIDMS/r16.0/oOS

There are a list of APARS. (B5, BB, BC, BE, QI, QO, QS, T5, TB, TC, TD,
TE and TF prefixes.)


Hope this helps,

Dick

Richard Pierce
(617) 973-8911
richard.pierce@state.ma.us

Outcomes