SEO

Art,
I have seen this problem myself. When doing a physical restore. In our
case we did the onmode -m and waited about 20 minutes before giving up.
Fortunately we happened to leave it much longer the next time we tried the
recovery and it came up in a few seconds short of 30 minutes.
But contrary to your suggestion that it indicates that the backup was taken
at a busy time in our case the backup was done in the middle of the night
when no users are running, no cron jobs are running. Out of interest we
have seen this on a few occasions and I now have a standard instruction that
says to wait at least 40 minutes to allow for physical and logical logs to
be cleared.
I now wonder whether this is something that varies with OS, page size,
physical lgo size, logical log size, etc. BTW most of the systems I work
with use about 5 20MByte logical logs per day. They're not busy!

Regards

Malcolm

-----Original Message-----
From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org]
On Behalf Of Art S. Kagel
Sent: 06 July 2006 13:57
To: informix-list@iiug.org
Subject: Re: Checking database partition index... FAILED


GemaVi wrote:
> Hello,
>
> after a cold recovery of Informix 9.40 UC2 the status remained in
> Fast-Recovery. Last line of the online.log during recovery was:
>
> 11:50:28 Maximum server connections 0
> 11:50:35 No logical log restore will be performed.
> 11:50:35 Preparing Physical Log for Fast Recovery ... 11:50:35
> Clearing the physical and logical logs has started (Nothing saying
> that the physical and logical logs had been cleared)
>
> I killed Informix with oninit -ky and try to start it again. But then
> I get the following error message:
>
> Checking database partition index.... FAILED.
<SNIP>
> Any idea of what this error might be?

Yes. Let me recap:

1- You did a restore.
2- You did not restore logical logs.
3- The engine was in recovery mode.
4- You either did not run onmode -m to bring the engine to full online mode
or you did not wait long enough for the fast recovery to complete.
5- You shutdown the engine.
6- You tried to restart the engine.

If that's about right, this is what happened. When the physical restore
completed all of the chunks were marked to an 'Inconsistent' state because
to that point no logical logs had been restored. The chunks are not marked
back online until the engine returns to fully online mode, but you shutdown
while the engine was still in fast recovery trying to determine if the
chunks were OK or not. Now when you try to restart the engine it will
refuse to come up even to recovery mode because all of the chunks are
effectively marked as if they are bad.

There are only two options:
1- Call tech support, explain what happened and beg them to mark the chunks
back to OK status for you.
2- Perform the physical restore again and either restore logical logs (at
least some) or not, but bring the engine to full online mode (ie onstat - -
reports that the engine is 'On-Line' in the header) before shutting down
again. Patience, if the engine was very busy at the time that the archive
was taken there may be many logical logs to roll forward and backwards to
complete fast recovery.

Aside to David Williams:
This is a recurring theme David, did we ever put this one in the FAQ?

Art S. Kagel

_______________________________________________
Informix-list mailing list
Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list