The backward recovery is acting as just another batch task ... it
takes primary exclusive control while modifying a row, and holds
secondary exclusive control until completion/commit. Regular
application tasks will wait on exclusive control held by the recovery
job as they would wait on any other job.
If some other task modifies a row following the termination of the job
being recovered and before the recovery gets to it, the backward
recovery will be unable to 'undo' that request (just as with backward
recovery in prior releases), but in 9.0 you can specify the recovery
terminates when it encounters such an error, or documents it and
continues (parm : MISMATCH=FAIL or IGNORE)
______________________________ Reply Separator _________________________________
Subject: Re: Backward recovery question
Author: CADRE-L CA-Datacom/DB Database Discussion Forum
<
CADRE-L@CNSIBM.ALBANY.EDU> at SMTPLINK
Date: 12/15/98 10:08 AM
What about data integrity when base is open? A batch job or online trans. = trying to update records that are included in the backward recovery?
Clyde McPherson <CLYDE.MCPHERSON=40CUSTOMS.TREAS.GOV> 12/15 7:27 AM
=
Paul,
With Datacom 9.0, backward recovery actually runs as a multiuser
function ... that is : although you have the distinct utility job, with
the RXX tape and the appropriate SYSIN cards, all the requests are
processed by the multiuser. This means that not only must the base(s)
be enabled for the recovery to be run, THEY DO NOT NEED TO BE CLOSED TO
NORMAL ACTIVITY. ... you don=27t need to close online URTs = or
terminate batch jobs, the recovery will be processed as just one more
task against the targeted bases.
One other point about backward recovery : with solutions 123 & 184
(both on 9808 I think), you can have the recovery read the tape
FORWARD. The fixes actually add sort to the recovery process : the
data is read forward, and then sorted into reverse sequence for the
actual recovery. This saves a whole lot of time on a good size
recovery if you are using =27compacted=27 (IDRC ??) cassette tapes.
Clyde McPherson
______________________________ Reply Separator ____________________________= _____
Subject: Backward recovery question
Author: CADRE-L CA-Datacom/DB Database Discussion Forum
<CADRE-L=40CNSIBM.ALBANY.EDU> at SMTPLINK
Date: 12/11/98 3:21 PM
Since our expert Datacom DBA is out on maternity leave, I had occasion to step in with my rusty hands and do a backward recovery last night. It turned out to be a relatively simple matter of backing out 1 job that had done minimal updating of a database. We have some pretty good internal = doc on how to do a backward recovery which I dutifully followed.
My question is on enabling the database. The online region was already = down and I disabled the database in question. After the LXX spill, our doc = says run the recovery but I got return code 88(85) -- database disabled. So I enabled the database and reran the recovery and everything was fine. But = our doc says do the recovery step, then enable the db. I would think you = would want to disable the db and then run backward recovery if you want to = ensure no other job can sneak in and do some updating before the recovery begins.
Did I miss something or is this how it works? I used the COMM DISABLE/ENAB= LE commands. We=27re OS/390, Datacom 9.0.
Paul Stewart