Re: IDS 9.4 Stuck at Fast Recovery

On 10/11/2007, Marco Greco <marco@4glworks.com> wrote: > Keith Simmons wrote: > > Anyone > > > > I havea test instance (not being archived that regularly) that > > suffered some disk corruption (crossed chunks with another instance > > !!). It has bee running OK and Ihave been sorting issues with indexes > > as they appear (the crossed chunks were on a dbspace containing mainly > > detatched indexes). However there does appear to be a table in one of > > these chunks. oncheck -cI showed an issue and I sucessfully dropped > > theindexes but was unable to recreate them. The next time I bounced > > the instance it refused to start getting stuck at the Fast Recovery > > stage. I have tried with -p option to oninit but to no avail. > > Although this is only a test instance I really need to preserve most > > of the data if at all possible. I can recreate the odd table or two > > where required, but not all 200 Gb!! > > Any suggestions as to whether it is possible to force this engine into > > life by skipping the Fast Recovery in some way? > > IDS9.4 FC6 on AIX 5.3. > > onstat -p > > IBM Informix Dynamic Server Version 9.40.FC6 -- Fast Recovery -- > > Up 19:41:49 -- 3020880 Kbytes> > > > Profile > > dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached > > 0 0 0 0.00 0 0 0 0.00 > > > > isamtot open start read write rewrite delete commit rollbk > > 0 0 0 0 0 0 0 0 0 > > > > gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs > > 0 0 0 0 0 0 0 > > > > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes > > 0 0 0 70734.67 19.47 0 0 > > > > bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans > > 0 0 0 0 0 0 0 0 > > > > ixda-RA idx-RA da-RA RA-pgsused lchwaits > > 0 0 0 0 52 > > > > Thanks > > > > Keith > > _______________________________________________ > > Informix-list mailing list > > Informix-list@iiug.org > > http://www.iiug.org/mailman/listinfo/informix-list > > > > Chances are that the LSN is way behind, and in the next log that the engine is > trying to use. but without peeking around it's impossible to say. If it is > important to you, you know the drill... > -- > Ciao, > Marco > ______________________________________________________________________________ > Marco Greco /UK /IBM Standard disclaimers apply! > > Structured Query Scripting Language http://www.4glworks.com/sqsl.htm > 4glworks http://www.4glworks.com > Informix on Linux http://www.4glworks.com/ifmxlinux.htm > Marco Thanks. onstat -l 8187fb50 15 U-B---- 16818 3:525053 37500 37500 100.00 8187fbb8 16 U-B---- 16819 3:562553 37500 37500 100.00 8187fc20 17 U-B---- 16820 3:600053 37500 37500 100.00 8187fc88 18 U---C-L 16821 3:637553 37500 22313 59.50 8187fcf0 19 U-B---- 16792 3:675053 37500 37500 100.00 8187fd58 20 U-B---- 16793 3:712553 37500 37500 100.00 8187fdc0 21 U-B---- 16794 3:750053 37500 37500 100.00 8187fe28 22 U-B---- 16795 3:787553 37500 37500 100.00 8187fe90 23 U-B---- 16796 3:825053 37500 37500 100.00 LTAPEDEV /dev/null last checkpoint in the log file was in llog 16821 and was a full checkpoint as part of onmode -yuck. Will do the required next week. Keith