Answered Hot To Get The Sequence Number Of Ai Extents Of A Damaged Database

RealHeavyDude

Well-Known Member
OpenEdge 11.3.1 / Solaris SPARC 64Bit

I am trying to come up with a script that produces a "restore hint" for a given database in the way that it tells the one who is executing it, which commands you should execute in which order to be able to restore the database and apply all necessary after image extents. Please don't ask why - I just have to ...

I was just wondering - is somebody else has a better way or thought about it.

  • I can easily see in the archival log file of AI archiver daemon which archived extents in which sequence need to be rolled forward. Plus, it is not rocket science to parse that file either.
  • But there will also be at least one busy after image extent that has not been archived yet and therefore needs to be saved before the restore is started and rolled foward at the end. I can identify which ones of the "live" extents are busy by looking at their time stamps. I can also try and error rfutil aimage scan against all of them. Nevertheless parsing the output of rfutil aimage scan to get the sequence number is rather tricky. More so as the messages are depending on language settings. Still it is the best I've been able to come up with yet as all other rfutil commands fail when you just have the after image extents and no database.
Does anybody have a script that identifies the state and sequence when you just have the after image extents?

Thanks in Advance, RealHeavyDude.
 

TomBascom

Curmudgeon
I sort of recall that you can run rfutil and supply the name of *any* database - even an empty.

I'm not at my desk right now to test it though...
 

RealHeavyDude

Well-Known Member
Hi Tom,

thanks for your answer. That works for some rfutil commands where you directly specify the after image extent ( -a parameter ), for example the aimage scan. But it does not work for those which rely on the database structure, for example aimage extent list ( which would be very valuable for my requirement ).

Thanks, RealHeavyDude.
 

TomBascom

Curmudgeon
It would be a PITA but, in theory anyway, you could parse the .st file for the list of extents and then use something like:

Code:
tmp> rfutil $DLC/empty -C aimage scan -a s2k.a1
OpenEdge Release 10.2B as of Mon Dec 14 17:00:19 EST 2009

After-image dates for this after-image file: (1633)
   Last AIMAGE BEGIN Thu Mar 30 08:20:47 2017 (1640)
   This is aimage file number 1 since the last AIMAGE BEGIN. (1642)
   This file was last opened for output on Thu Mar 30 08:20:47 2017. (1643)


0 notes were processed. (1634)
0 in-flight transactions. (3785)
0 transactions were started. (1635)
0 transactions were completed. (11138)
At the end of the .ai file, 0 transactions were still active. (1636)

to figure out which of the extents have a sequence# that has not yet been archived.
 

RealHeavyDude

Well-Known Member
Thanks.

That's about what I've come up too.

I do love the Progress OpenEdge database, I really do. But sometimes it frustrates me how hard Progress makes it for us to fetch some valuable information.

Thanks and Best Regards, RealHeavyDude.
 

cj_brandt

Active Member
The db has become corrupted for unknown reasons... is it safe to apply the entire contents of the busy AI file ?

Doing it manually you could back up 30 seconds or so. Not sure how that could be scripted.
 

RealHeavyDude

Well-Known Member
I am done. Tom, you were right - it is a PITA ...

Based on the structure description file and dummy database ( with the same AI block size of course ) I am able to execute the rfutil aimage scan against all available "live" extents. By parsing the output of the rfutil aimage scan I am able to fetch the sequences of any full or busy extent which must be saved before prorest is executed and rolled forward when all the archived extents have been rolled forward.

Based on the log file of the AI archiving daemon I am able to identify all archived extents that needs to be rolled forward.

With that information I can produce a list of necessary steps to restore the database.

My managers are now happy again because they are now able to save a lot of money by outsourcing/offshoring the disaster recovery resonse. Me, I am not too convinced it is a good idea, to hand the responsibility over to somebody with minimal Progress DBA know how on the other side of the world.

Thanks for all input!

Regards, RealHeavyDude.
 
Top