HDR issues
Posted in 2004
A DBA on IDS 9.40.UC3 (Solaris 8) shut down his HDR secondary during a schema upgrade; when it restarted and replayed the logs, applying the last CREATE INDEX hung both primary and secondary in a checkpoint for over 40 minutes (the index took only 2 minutes to build on the primary). Killing the secondary caused an assert failure, so he ran the primary in standard mode. Respondents identified it as a known bug (167294, checkpoint request in bfphyslogx hanging HDR; also bug 166760, physical log overflow during index creation on the secondary), fixed in 9.40.UC5/9.40.UC4W4, with PLOG_OVERFLOW_PATH suggested as a 9.40 workaround and breaking/re-establishing replication as another. The original poster did not confirm a fix.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: High Availability & Replication, Installation, Setup & Upgrades, Logging & Checkpoints
All, I had a peculiar problem with HDR last night. We had a software = upgrade, which made some changes to the db schema (columns added, indexes created). In order to = facilitate this,=20 I shut down the secondary server until the everything was complete. = When I started up the secondary server, all was fine......the logical logs were transferred = and were being applied to=20 the secondary......looks great, right. Wrong. When all the logical logs were finished transferring, I saw some = messages in the message log pertaining to indexes being transferred. I thought this was no problem = until I noticed the last index was taking forever to apply on the secondary......For over 40 min = the prim / sec were stuck=20 in a checkpoint while this index was being applied - keep in mind it = only took 2 min to create the=20 index. =20 I ended up shutting down the secondary (caused an assert failure on the = primary), putting the primary=20 in standard mode so we could fire up the app. =20 Is there a way to speed up index creation in HER? OR will I have to = suffer thru this again? Terrence Mullins Database Administrator www.WagerWorks.com=20
Sun V440=20 Solaris 8=20 IDS 9.40.UC3=20 -Terrence=20 -----Original Message----- From: Robert Roussey = [mailto:IMCEAEX-_O=3DSPIRITAIR_OU=3DRESCT_CN=3DRECIPIENTS_CN=3DROBERTRO@S= piritAir.com] Sent: Friday, November 19, 2004 12:29 PM To: Terrence Mullins; ids@iiug.org Subject: RE: HDR issues [3730]=20 =09 Hardware? OS? Informix version??=20 Bob Roussey=20 Spirit Airlines=20 Informix/Unix Administration=20 Phone: 586.741.8991=20 e-mail: RobertRo@SpiritAir.com=20 =09 -----Original Message-----=20 From: forum.subscriber@iiug.org [<mailto:forum.subscriber@iiug.org>] On = Behalf Of Terrence Mu....=20 Sent: Friday, November 19, 2004 12:53 PM=20 To: ids@iiug.org=20 Subject: HDR issues [3730]=20 All,=20 I had a peculiar problem with HDR last night. We had a software =3D=20 upgrade, which made some=20 changes to the db schema (columns added, indexes created). In order to = =3D=20 facilitate this,=3D20=20 I shut down the secondary server until the everything was complete. =3D = When I started up the=20 secondary server, all was fine......the logical logs were transferred = =3D=20 and were being applied to=3D20=20 the secondary......looks great, right. Wrong.=20 When all the logical logs were finished transferring, I saw some =3D=20 messages in the message log=20 pertaining to indexes being transferred. I thought this was no problem = =3D=20 until I noticed the last=20 index was taking forever to apply on the secondary......For over 40 min = =3D=20 the prim / sec were stuck=3D20=20 in a checkpoint while this index was being applied - keep in mind it = =3D=20 only took 2 min to create the=3D20=20 index. =3D20=20 I ended up shutting down the secondary (caused an assert failure on the = =3D=20 primary), putting the primary=3D20=20 in standard mode so we could fire up the app. =3D20=20 Is there a way to speed up index creation in HER? OR will I have to =3D = suffer thru this again?=20 Terrence Mullins=20 Database Administrator=20 www.WagerWorks.com=3D20=20
Version number would be good. Bug 166760 -- HDR secondary AFs with physical log file overflow when creating indexes. Possible workaround in 9.40 is to use PLOG_OVERFLOW_PATH. Terrence Mu.... said: > All, > > I had a peculiar problem with HDR last night. We had a software = > upgrade, which made some > changes to the db schema (columns added, indexes created). In order to = > facilitate this,=20 > I shut down the secondary server until the everything was complete. = > When I started up the > secondary server, all was fine......the logical logs were transferred = > and were being applied to=20 > the secondary......looks great, right. Wrong. > > When all the logical logs were finished transferring, I saw some = > messages in the message log > pertaining to indexes being transferred. I thought this was no problem = > until I noticed the last > index was taking forever to apply on the secondary......For over 40 min = > the prim / sec were stuck=20 > in a checkpoint while this index was being applied - keep in mind it = > only took 2 min to create the=20 > index. =20 > > I ended up shutting down the secondary (caused an assert failure on the = > primary), putting the primary=20 > in standard mode so we could fire up the app. =20 > > Is there a way to speed up index creation in HER? OR will I have to = > suffer thru this again? > > > > > > Terrence Mullins > Database Administrator > www.WagerWorks.com=20 > > > -- Bye now, Obnoxio "C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule" - Coluche "I'm trying to see things your way, but I can't get my head up my ass" - JCH "Ogni uomo mi guarda come se fossi una testa di cazzo" - Marco I went to the airport to check in and they asked what I did because I looked like a terrorist. I said I was a comedian. They said, "Say something funny then." I told them I had just graduated from flying school. -- Ahmed Ahmed
Could you provide us with server version number? Contact IBM customer support to collect some more data from hung server. This could be some problem during sync. Transfer of index should not take this much of time. -Ajay
How many rows in the table ? Can you send through the schema for the table & index -----Original Message----- From: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] On Behalf Of Terrence Mu.... Sent: 19 November 2004 17:53 To: ids@iiug.org Subject: HDR issues [3730] All, I had a peculiar problem with HDR last night. We had a software = upgrade, which made some changes to the db schema (columns added, indexes created). In order to = facilitate this,=20 I shut down the secondary server until the everything was complete. = When I started up the secondary server, all was fine......the logical logs were transferred = and were being applied to=20 the secondary......looks great, right. Wrong. When all the logical logs were finished transferring, I saw some = messages in the message log pertaining to indexes being transferred. I thought this was no problem = until I noticed the last index was taking forever to apply on the secondary......For over 40 min = the prim / sec were stuck=20 in a checkpoint while this index was being applied - keep in mind it = only took 2 min to create the=20 index. =20 I ended up shutting down the secondary (caused an assert failure on the = primary), putting the primary=20 in standard mode so we could fire up the app. =20 Is there a way to speed up index creation in HER? OR will I have to = suffer thru this again? Terrence Mullins Database Administrator www.WagerWorks.com=20
Hi, Which Informix version/OS you are working on, I had similar problem with 9.30 uc3 AIX 5.1 but did not have "assert failures" it just didn't create index correctly on secondary, tech said there is a bug which got fixed in 9.4. Currently we are on 9.4 fc4 AIX 5.2 I haven't created any indexes on primary yet but very soon I am going to try it. The workaround I was using is to break the replication and re-connect it. Sushil.... >From: "Terrence Mu...." <terrence@wagerworks.com> >To: ids@iiug.org >Subject: HDR issues [3730] Date: Fri, 19 Nov 2004 12:53:12 -0500 (EST) >Received: from mc4-f28.hotmail.com ([65.54.190.164]) by mc4-s20.hotmail.com >with Microsoft SMTPSVC(5.0.2195.6824); Fri, 19 Nov 2004 13:46:19 -0800 >Received: from ace.iiug.org ([216.177.38.212]) by mc4-f28.hotmail.com with >Microsoft SMTPSVC(5.0.2195.6824); Fri, 19 Nov 2004 11:17:34 -0800 >Received: from ace.iiug.org (localhost [127.0.0.1])by ace.iiug.org >(8.12.10-14/8.12.8) with ESMTP id iAJHuoVM018785;Fri, 19 Nov 2004 13:41:36 >-0500 (EST) >Received: (from nobody@localhost)by ace.iiug.org (8.12.10-14/8.12.8/Submit) >id iAJHrCEm018681;Fri, 19 Nov 2004 12:53:12 -0500 (EST) >X-Message-Info: 0jbW5ANosZL9xBKWDJ88+ssSCLDugYho >Apparently-To: forum.subscriber@iiug.org >Precedence: bulk >Return-Path: nobody@ace.iiug.org >X-OriginalArrivalTime: 19 Nov 2004 19:17:34.0463 (UTC) >FILETIME=[6C7540F0:01C4CE6C] > >All, > >I had a peculiar problem with HDR last night. We had a software = >upgrade, which made some >changes to the db schema (columns added, indexes created). In order to = >facilitate this,=20 >I shut down the secondary server until the everything was complete. = >When I started up the >secondary server, all was fine......the logical logs were transferred = >and were being applied to=20 >the secondary......looks great, right. Wrong. > >When all the logical logs were finished transferring, I saw some = >messages in the message log >pertaining to indexes being transferred. I thought this was no problem = >until I noticed the last >index was taking forever to apply on the secondary......For over 40 min = >the prim / sec were stuck=20 >in a checkpoint while this index was being applied - keep in mind it = >only took 2 min to create the=20 >index. =20 > >I ended up shutting down the secondary (caused an assert failure on the = >primary), putting the primary=20 >in standard mode so we could fire up the app. =20 > >Is there a way to speed up index creation in HER? OR will I have to = >suffer thru this again? > > > > > >Terrence Mullins >Database Administrator >www.WagerWorks.com=20 > > >
Known BUG (bug# 167294 CHECKPOINT REQUEST IN BFPHYSLOGX CAN CAUSE HDR TO HANG ), fixed in 9.40uc5 and 9.40uc4w4 I've also run into this bug some time ago... ------------------------------------------ Alexey Sonkin > -----Original Message----- > From: Terrence Mu.... [mailto:terrence@wagerworks.com] > > All, > > I had a peculiar problem with HDR last night. We had a software = > upgrade, which made some > changes to the db schema (columns added, indexes created). In order to = > facilitate this,=20 > I shut down the secondary server until the everything was complete. = > When I started up the > secondary server, all was fine......the logical logs were transferred = > and were being applied to=20 > the secondary......looks great, right. Wrong. > > When all the logical logs were finished transferring, I saw some = > messages in the message log > pertaining to indexes being transferred. I thought this was no problem = > until I noticed the last > index was taking forever to apply on the secondary......For over 40 min = > the prim / sec were stuck=20 > in a checkpoint while this index was being applied - keep in mind it = > only took 2 min to create the=20 > index. =20 > > I ended up shutting down the secondary (caused an assert failure on the = > primary), putting the primary=20 > in standard mode so we could fire up the app. =20 > > Is there a way to speed up index creation in HER? OR will I have to = > suffer thru this again? > > > > > > Terrence Mullins > Database Administrator > www.WagerWorks.com=20 >