Hanging in a "fast recovery"
Alex (Pietje Puk) reported Informix hanging in fast recovery (CKPT REQ) after ontape -r, with sanity-check complaints about tempdbs. Art S. Kagel suggested checking onstat -p and -D for activity, long transactions, and more offline recovery threads. Alex found it was not hanging; the first restore had been killed too early with onmode -ky. After oninit -i and a fresh restore, recovery finished in about 15 minutes. Solved.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hi All,
After an restore with 'ontape -r' Informix keeps hanging in a "fast recovery
(CKPT REQ)".
Online.log says nothing special.
After 'onmode -ky' and 'oninit -s' (or just oninit) online.log complains
about problems with "tempdbs (sanity)", nothing else.
Do i have a corrupt backup?
Thanks in advance,
Alex
More Info from online.log:
chunk failed santy check
Do i have a hardware problem?
Alex
Pietje Puk <Pietje@puk.com> schreef in berichtnieuws
3992cbcc$0$5593@news2.zeelandnet.nl...
> Hi All,
>
> After an restore with 'ontape -r' Informix keeps hanging in a "fast
recovery
> (CKPT REQ)".
>
> Online.log says nothing special.
>
> After 'onmode -ky' and 'oninit -s' (or just oninit) online.log complains
> about problems with "tempdbs (sanity)", nothing else.
>
> Do i have a corrupt backup?
>
>
>
> Thanks in advance,
>
> Alex
>
>
>
>
Pietje Puk wrote:
>
> Hi All,
>
> After an restore with 'ontape -r' Informix keeps hanging in a "fast recovery
> (CKPT REQ)".
Any activity? Does onstat -p or onstat -D show continued activity as
if fast recover is just continuing? I know, you already shutdown,
verify that all of the disks are OK and rerun the restore. If there
were long transactions in progress at the time of the backup starting
and especially if they were already rolling back, the fast recover can
take quite a while. Try adding more offline recover threads in the
ONCONFIG file before trying the restore again.
Art S. Kagel
> Online.log says nothing special.
>
> After 'onmode -ky' and 'oninit -s' (or just oninit) online.log complains
> about problems with "tempdbs (sanity)", nothing else.
>
> Do i have a corrupt backup?
>
> Thanks in advance,
>
> Alex
Thanks Art,
'Onstat -p' showed me "fast recovery" wasn't hanging.
The firts time we restored with 'ontape -r' we killed the recovery to quick, with
'onmode -ky'!
The second and third restories failed because of our first failed restore.
After the fourth restore we reinitialised the engine with 'oninit -i' and the
engine started fine. We only had a rootdbs, but now we know that the hard- and
software were okay.
Build new filesystems, reboot and again a restore with 'ontape -r'.
Now we waited for the recovery finished. With 'onstat -p' we could see disks were
working and the recovery wasn't hanging.
Took about 15 minutes before the engine went to Quiscent mode(onstat -dr and tail
-f online.log)
In status field of 'onstat -d' you also see that status went from PI into PO.
Lucky for us, this was only our, yearly, recovery-test. We learned a lot!
See you,
Alex
"Art S. Kagel" wrote:
> Pietje Puk wrote:
> >
> > Hi All,
> >
> > After an restore with 'ontape -r' Informix keeps hanging in a "fast recovery
> > (CKPT REQ)".
>
> Any activity? Does onstat -p or onstat -D show continued activity as
> if fast recover is just continuing? I know, you already shutdown,
> verify that all of the disks are OK and rerun the restore. If there
> were long transactions in progress at the time of the backup starting
> and especially if they were already rolling back, the fast recover can
> take quite a while. Try adding more offline recover threads in the
> ONCONFIG file before trying the restore again.
>
> Art S. Kagel
>
> > Online.log says nothing special.
> >
> > After 'onmode -ky' and 'oninit -s' (or just oninit) online.log complains
> > about problems with "tempdbs (sanity)", nothing else.
> >
> > Do i have a corrupt backup?
> >
> > Thanks in advance,
> >
> > Alex