HDR/RSS establish fails

IDS 11.70FC7 on RedHat 5 We've built a new instance. At some point, 4 days ago, its chunks were renamed with an external restore. Fast forward to today. A clone of the instance has been created with a blocking checkpoint. onbar -r -e -p onmode -d secondary <primary server name> onmode -d secondary ob_prod_hdr_priDR: Unable to change server type onmode: Please check the message log for any additional errors. And in the online log for the secondary: 13:13:58 External restore started. 13:13:58 External restore Completed. 13:14:09 The mode change is not allowed since the chunks have been renamed on this server. 13:39:09 The mode change is not allowed since the chunks have been renamed on this server. What's going on here?! Same with RSS btw. I am guessing some feature/bug within Informix that a flag is set somewhere saying that a restore/rename has been done and you need to do a Level 0 or something before the image can be used via external restore for RSS. but that's just a guess .. waiting for IBM to respond under PMR 51401,001,866. Meanwhile the customer is howling about the down system (they use the HDR for reporting). So, any inspiraton for workarounds? yes i can use ifxclone/or restore from a Level 0 taken subsequently but that will take many hours when there's probably a quicker fix. Thanks Neil

Tech support believes its because the Sec's image has this: DBspace number 1 DBspace name rootdbs Flags 0x4e0001 No mirror chunks which contains a flag denoting renamed chunks, whereas the primary now has this: DBspace name rootdbs Flags 0x40001 No mirror chunks (What changed the flags on the Pri? A subsequent Level 0 I guess). So a new clone would likely fix it. But the customer insists on stopping not just Informix but the whole Linux server to take a clone (don't ask!) so this isn't easy. Need to find a way to alter the sec image.

... or at least understood! The issue was that a renaming restore sets flags on the dbspace such that the instance cannot then later be used as an HDR or RSS primary or secondary until it has had a full, traditional, old fashioned level 0 run against it. (A false won't do). Not sure what the thinking behind that piece of coding is, but there you have it.

Reason: There are two copies of the chunk table on disk. The engine alternates between them during updates, copying the current page to the other then it switches which is current and updates the new current page. A level zero archive makes the copy and switch at the end of processing so they are identical until the next modification and puts the updated page into the archive so the restore from a true level zero has matching pages. The restore you made from an external backup would not have the pages synced. That's how the engine knew that there were renamed chunks. I had forgotten about that when we spoke about it earlier. Art On Feb 16, 2016 7:58 PM, "NEIL TRUBY" <neil.truby@ardenta.com> wrote: > .... or at least understood! > > The issue was that a renaming restore sets flags on the dbspace such that > the > instance cannot then later be used as an HDR or RSS primary or secondary > until > it has had a full, traditional, old fashioned level 0 run against it. (A > false > won't do). > > Not sure what the thinking behind that piece of coding is, but there you > have > it. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --047d7bea43fcc97918052bed0def

It's to make sure that you don't try to use an old backup to create a secondary... Madison Pruet Retired and Loving it On Tuesday, February 16, 2016 6:57 PM, NEIL TRUBY <neil.truby@ardenta.com> wrote: .... or at least understood! The issue was that a renaming restore sets flags on the dbspace such that the instance cannot then later be used as an HDR or RSS primary or secondary until it has had a full, traditional, old fashioned level 0 run against it. (A false won't do). Not sure what the thinking behind that piece of coding is, but there you have it. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

OK, so it's something that pre-dates the advent of external restores, to which it shouldn't apply? I guess that the onmode -d command can't readily determine HOW the restore image was created. Even so it would be nice if the flag could simply be reset for an external restore. As it is we are having to restore from a level 0, which will take about 12 hours ... Thanks Neil

Or take a level zero then you should be able to restore from an external archive taken after that level zero. Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Feb 17, 2016 at 3:07 AM, NEIL TRUBY <neil.truby@ardenta.com> wrote: > OK, so it's something that pre-dates the advent of external restores, to > which > it shouldn't apply? > > I guess that the onmode -d command can't readily determine HOW the restore > image was created. Even so it would be nice if the flag could simply be > reset > for an external restore. As it is we are having to restore from a level 0, > which will take about 12 hours ... > > Thanks > Neil > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e011602a82b0412052bf54c92