Stuck in FAST RECOVERY
A user on IDS 7.31.UC2A (Solaris) found the engine stuck in fast recovery for hours after a power failure, following index/primary-key changes. Art Kagel noted long recovery can be normal if there's real I/O activity (check onstat -D / -g iof), and the poster saw heavy disk activity. Another user reported the same hang on HP-UX was a known bug (defect 107840, Tech Alert 1999-A051) where physical recovery loops hunting an overwritten physical log page; support's only remedy was restoring from archive, with a fix in 7.31.UC3A. The original poster's outcome isn't recorded; the rest of the thread complains that Informix only publishes such alerts on its password-protected TechInfo site rather than emailing customers.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi, I have IDS 7.31.UC2A installed on Solaris and it has been running fine for over 1 month. I deleted some data then dropped a few primary keys on some tables and then added unique indexes. Then there was a power hit and the system rebooted. The system came back up but IDS has been stuck in Fast Recovery for HOURS. Does it need to be reloaded or is this normal?
"Gregory P. Schin" wrote:
>
> Hi,
>
> I have IDS 7.31.UC2A installed on Solaris and it has been running fine
> for over 1 month. I deleted some data then dropped a few primary keys
> on some tables and then added unique indexes. Then there was a power
> hit and the system rebooted. The system came back up but IDS has been
> stuck in Fast Recovery for HOURS. Does it need to be reloaded or is
> this normal?
It CAN happen. Is there disk activity? What does onstat -D show or
onstat -g iof show as to the whether the fast recovery is doing anything.If the engine was close to a checkpoint and there was lots of activity
then there just may be lots to undo due to the crash.
Art S. Kagel
Yes - lots of disk activity! I'll wait it out (good thing its just a lab box). Thanks
In article <3846EEA6.E1A88821@lucent.com>, "Gregory P. Schin" <gps@lucent.com> wrote: > Hi, > > I have IDS 7.31.UC2A installed on Solaris and it has been running fine > for over 1 month. I deleted some data then dropped a few primary keys > on some tables and then added unique indexes. Then there was a power > hit and the system rebooted. The system came back up but IDS has been > stuck in Fast Recovery for HOURS. Does it need to be reloaded or is > this normal? > > I know the answer to his one.. I had this problem occur to me just yesterday only I am running 7.31.UC2A on HP-UX 10.20. It is a bug in this release of the Informix engine. I forget the bug number but I just got that info from tech support yesterday. The problem is that the physical recovery process is stuck in an endless loop looking for a physical log page that it has already overwritten itself, and will obviously never find. As the tech support referred to it yesterday "This is a very serious bug" That was the understatement of the year. -- the only fix -- restore from an archive tape... Just a side note I think that we should lobby for some better notification to us the user community when these serious problems occur. Our local User Group president is very good about sending us any thing that Informix puts out. Informix tells me that it is fixed in the 7.31.UC3A release of the engine, but I could have upgraded over a month ago if I had known. CGK. Sent via Deja.com http://www.deja.com/ Before you buy.
In article <82bj5i$5vj$1@nnrp1.deja.com>, Clint G. Kunz <clintk@email.utcourts.gov> writes >In article <3846EEA6.E1A88821@lucent.com>, > "Gregory P. Schin" <gps@lucent.com> wrote: >> Hi, >> >> I have IDS 7.31.UC2A installed on Solaris and it has been running fine >> for over 1 month. I deleted some data then dropped a few primary >keys >> on some tables and then added unique indexes. Then there was a power >> hit and the system rebooted. The system came back up but IDS has been >> stuck in Fast Recovery for HOURS. Does it need to be reloaded or is >> this normal? >> >> > >I know the answer to his one.. > >I had this problem occur to me just yesterday only I am running >7.31.UC2A on HP-UX 10.20. It is a bug in this release of the Informix >engine. I forget the bug number but I just got that info from tech >support yesterday. The problem is that the physical recovery process is >stuck in an endless loop looking for a physical log page that it has >already overwritten itself, and will obviously never find. As the tech >support referred to it yesterday "This is a very serious bug" That was >the understatement of the year. -- the only fix -- restore from an >archive tape... > >Just a side note I think that we should lobby for some better >notification to us the user community when these serious problems >occur. Our local User Group president is very good about sending us any Already exists. Go to www.informix.com Techinfo Centre -> Access You need a password, which you can get if you have a valid support contract. Then look under Tech Alerts!! >thing that Informix puts out. Informix tells me that it is fixed in the >7.31.UC3A release of the engine, but I could have upgraded over a month >ago if I had known. > > >CGK. > > >Sent via Deja.com http://www.deja.com/ >Before you buy. -- David Williams
If it is defect no. 107840 then there is a Tech Alert out on this - ref. 1999-A051. It affects pretty much every version prior to 7.30.UC9 and a couple of 7.31 releases. You'll only get to know about it though if you have access to the techinfo centre. I am inclined to agree that Informix could do a better job of bringing these alerts to the attention of their user base. Pete Logica In article <82bj5i$5vj$1@nnrp1.deja.com>, Clint G. Kunz <clintk@email.utcourts.gov> wrote: > In article <3846EEA6.E1A88821@lucent.com>, > "Gregory P. Schin" <gps@lucent.com> wrote: > > Hi, > > > > I have IDS 7.31.UC2A installed on Solaris and it has been running fine > > for over 1 month. I deleted some data then dropped a few primary > keys > > on some tables and then added unique indexes. Then there was a power > > hit and the system rebooted. The system came back up but IDS has been > > stuck in Fast Recovery for HOURS. Does it need to be reloaded or is > > this normal? > > > > > > I know the answer to his one.. > > I had this problem occur to me just yesterday only I am running > 7.31.UC2A on HP-UX 10.20. It is a bug in this release of the Informix > engine. I forget the bug number but I just got that info from tech > support yesterday. The problem is that the physical recovery process is > stuck in an endless loop looking for a physical log page that it has > already overwritten itself, and will obviously never find. As the tech > support referred to it yesterday "This is a very serious bug" That was > the understatement of the year. -- the only fix -- restore from an > archive tape... > > Just a side note I think that we should lobby for some better > notification to us the user community when these serious problems > occur. Our local User Group president is very good about sending us any > thing that Informix puts out. Informix tells me that it is fixed in the > 7.31.UC3A release of the engine, but I could have upgraded over a month > ago if I had known. > > CGK. > > Sent via Deja.com http://www.deja.com/ > Before you buy. > Sent via Deja.com http://www.deja.com/ Before you buy.
I have to say I would tell our friends at Informix that, thats the wrong answer. Surely tech support can dial in and fix your engine. After all some instances out there are terrabytes in size and would take forever to restore from tape and roll forward on. mja In article <82bj5i$5vj$1@nnrp1.deja.com>, Clint G. Kunz <clintk@email.utcourts.gov> wrote: > In article <3846EEA6.E1A88821@lucent.com>, > "Gregory P. Schin" <gps@lucent.com> wrote: > > Hi, > > > > I have IDS 7.31.UC2A installed on Solaris and it has been running fine > > for over 1 month. I deleted some data then dropped a few primary > keys > > on some tables and then added unique indexes. Then there was a power > > hit and the system rebooted. The system came back up but IDS has been > > stuck in Fast Recovery for HOURS. Does it need to be reloaded or is > > this normal? > > > > > > I know the answer to his one.. > > I had this problem occur to me just yesterday only I am running > 7.31.UC2A on HP-UX 10.20. It is a bug in this release of the Informix > engine. I forget the bug number but I just got that info from tech > support yesterday. The problem is that the physical recovery process is > stuck in an endless loop looking for a physical log page that it has > already overwritten itself, and will obviously never find. As the tech > support referred to it yesterday "This is a very serious bug" That was > the understatement of the year. -- the only fix -- restore from an > archive tape... > > Just a side note I think that we should lobby for some better > notification to us the user community when these serious problems > occur. Our local User Group president is very good about sending us any > thing that Informix puts out. Informix tells me that it is fixed in the > 7.31.UC3A release of the engine, but I could have upgraded over a month > ago if I had known. > > CGK. > > Sent via Deja.com http://www.deja.com/ > Before you buy. > Sent via Deja.com http://www.deja.com/ Before you buy.
In article <82j5a4$9qh$1@nnrp1.deja.com>, martyn.ayshford@orange.co.uk wrote: > I have to say I would tell our friends at Informix that, thats the > wrong answer. Surely tech support can dial in and fix your engine. > > After all some instances out there are terrabytes in size and would > take forever to restore from tape and roll forward on. > > mja > Very good point, If I would have had to spend more than a few hours restoring than I probably would have been more inclined to argue a little bit with the tech support engineer. Unfortunately I had an online engineer dialed on to the system for a few hours to no avail. PS Thanks for the Bug Info plsmith.. it is indeed 107840 that was cited for the problem. PSS. Did your problem get solved Gregory. Sent via Deja.com http://www.deja.com/ Before you buy.
>In article <johmlAAzGwS4EwPV@smooth1.demon.co.uk>, > David Williams <djw@smooth1.demon.co.uk> wrote: > > Already exists. Go to www.informix.com > > Techinfo Centre -> Access > > You need a password, which you can get if you have a valid support > contract. > > Then look under Tech Alerts!! > > -- > David Williams > No doubt that the information there is invaluable and I wish that I could live there, but there is a new technology out now known as ..email.. It could be used to actually provide.. the link/article/anything directly to the user community when a serious bug is discovered. Call it sort of doing something for your maintenance dollars!! Sent via Deja.com http://www.deja.com/ Before you buy.
"Clint G. Kunz" wrote: > > >In article <johmlAAzGwS4EwPV@smooth1.demon.co.uk>, > > David Williams <djw@smooth1.demon.co.uk> wrote: > > > > Already exists. Go to www.informix.com > > > > Techinfo Centre -> Access > > > > You need a password, which you can get if you have a valid support > > contract. > > > > Then look under Tech Alerts!! > > > > -- > > David Williams > > > > No doubt that the information there is invaluable and I wish that I > could live there, but there is a new technology out now known > as ..email.. It could be used to actually provide.. the > link/article/anything directly to the user community when a serious bug > is discovered. Call it sort of doing something for your maintenance > dollars!! Actually I do get the alerts by email from my Regency Support Manager. It is one of the few things making the multiple 6 figure cost worthwhile. On the other hand how much would it cost to get an email address from every support customer and forward tech alerts to us all? OK thou lurkers from Lenexa, how about passing this along. Art S. Kagel
Related threads
- IDS 10 table-level restore
- Informix Development Webinar December 11, 2007
- ontape -p/r with changed ROOTPATH
- Migrate from HP PA-RISC to HP ITANIUM by ontape