Re: IDS 9.4 Stuck at Fast Recovery

Keith Simmons wrote: > 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 Nope, not the LSN. I take it there are no recovery afs in the logs, right? if this is the case, kill the engine, set OFF_RECOVERY_THREADS to 1 and see what happens -- 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