Checking database partition index... FAILED

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. The complete startup sequence would be: Checking group membership to determine server run modesucceeded Reading configuration file '/usr/informix/etc/onconfig'...succeeded Creating /INFORMIXTMP/.infxdirs ... succeeded Creating infos file "/usr/informix/etc/.infos.online1" ... "/usr/informix/etc/.conf.online1" ... succeeded Writing to infos file ... succeeded Checking config parameters...succeeded Allocating and attaching to shared memory... succeeded Creating resident pool 22108 kbytes...succeeded Creating buffer pool 200002 kbytes...succeeded Initializing rhead structure...succeeded Initializing ASF ...succeeded Initializing Dictionary Cache and SPL Routine Cache...succeeded Bringing up ADM VP...succeeded Creating VP classes...succeeded Onlining 0 additional cpu vps...succeeded Onlining 6 IO vps...succeeded Initialization of Encryption...succeeded Forking main_loop thread...succeeded Initializing DR structures...succeeded Forking 1 'ipcshm' listener threads...succeeded Forking 4 'tlitcp' listener threads...succeeded Forking 0 'tlitcp' listener threads...succeeded Starting tracing...succeeded Initializing 127 flushers...succeeded Initializing log/checkpoint information...succeeded Opening primary chunks...succeeded Opening mirror chunks...succeeded Initializing dbspaces...succeeded Validating chunks...succeeded Initialize Async Log Flusher...succeeded Forking btree cleaner...succeeded Initializing DBSPACETEMP list Checking database partition index...FAILED Any idea of what this error might be?

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

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