Kbase P121756: Why is it necessary to run rfutil -C aimage sequence on an OS copy ?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
3/11/2009 |
|
Status: Verified
GOAL:
Why is it necessary to run rfutil -C aimage sequence on an OS copy ?
GOAL:
error 8019 rolling forward ai to OS copied database
GOAL:
Expected ai file number 1 but file specified is n+1 in sequence. (8019)
GOAL:
Why can the latest ai files not be rolled forward against the OS copy baseline?
GOAL:
Why aimage files after mark backedup cannot be rolled forward against an OS copy of production database
FACT(s) (Environment):
Progress 9.1E
OpenEdge 10.0B01
OpenEdge 10.1x
All Supported Operating Systems
FIX:
There are essentially two different methodologies that need to be used in an OS copy/mirror methodology involving replication, depending on the Progress version.
What is of paramount importance to this subject (irrespective of Progress version) is that the "problem" with using OS copy and after-imaging, is that one has to manually ensure that on the database side, a valid OS backupcopy is one that has an increment of the backupversion in masterblock + a "CLEAN" ai file. ie: the ai file must not span the OS copy. Moreover, absolutely nothing must touch the database while the OS copy is taking place - this would invalidate the baseline (period).
These methodologies are outlined in Progress Solutions:
P2862, "How to use offline OS backup with after imaging enabled - pre Progress 9.1E?"
P115048, "How to use offline OS backup with after imaging enabled - post Progress 9.1E?"
P102501, "When to use rfutil -C sequence?" (.. with proquiet)
Upgrading to 9.1E (or 10.0B01 or 10.1A) is a good idea apart from the many other benefits, the introduction "$ rfutil <db> -C sequence" utility that particularly relates to this case. It is not the objective of this Solution to discuss the methodology, but to provide some D/R planning considerations by clarifying the methodology behind the internals checks that allow successful roll forward against OS copy.
Essentially, before the introduction of this "rfutil -C sequence" utility, OS_Backup_ai plan meant that if one wanted to use an_other/a_later OS backup to roll forward against, one would have to first re-set the backup + ai file baseline offline (rfutil -C aimage end; OS backup; rfutil -C mark backedup, rfutil -C aimage begin) .. then any OS backups that are taken "in between" baselines, are just OS backup baselines that cannot be roll forwarded against.
WHY?
There are two counters in a database master block that have relevance in this situation:
- One counter is the /expected/ AI sequence and
- the other counter is the /current/ AI sequence.
These counters are incremented under the following conditions:
Every time an AI file is switched (automatic ai switch when filled, aiarchiver daemon, trigger a switch with "rfutil -C new" or disable a quiet point without the nolock option): the /current/ AI sequence number is incremented.
When probkup is issued against a database, it adjusts the /expected/ AI sequence number.
After an after image file applied to a database (roll forward), it adjusts the /expected/ AI sequence number.
The "sequence" option of rfutil, adjusts the /expected/ AI sequence number.
When an OS copy of the production database is taken, the database master block in the OS copy is an exact copy of that in the production database. No ai files will have ever been rolled forward against this database since after-imaging was initially set (rfutil -C aimage begin), neither is probkup part of the plan, so the expected sequence number will not have been incremented under these conditions. When ai files are rolled forward against this copy (hot-standby), the first roll-forward disables after-imaging.
The expected AI sequence in production is therefore typically 1 and never grows, or more specifically, not inline with the current ai sequence number. OS backups are outside the Progress database manager control, there's no point in incrementing the "expected counter", an equally disparate message would still result. Furthermore, with OS backups, it's up to the administrator to ensure that the "rfutil -C new" is issued. precisely.
So...every time an OS backup is taken, a progressively higher /current/ AI sequence (these are recorded by the Progress rfutil utilities) but the /expected/ is usually 1 but will never-the-less always be a much smaller sequence value than the current ai sequence.
The "sequence" option of rfutil was therefore introduced to adjust the expected to match the current ai sequence. The utility reads the current AI sequence and uses the number it gets from that to overwrite the expected AI sequence in the master block of the database AI files are about to roll forward against..