Did this article resolve your question/issue?



Why is it necessary to run rfutil -C aimage sequence on an OS copy ?

« Go Back


TitleWhy is it necessary to run rfutil -C aimage sequence on an OS copy ?
URL NameP121756
Article Number000130812
EnvironmentProduct: Progress
Version: 9.1E
Product: OpenEdge
Version: 10.0B01, 10.1x, 10.2x, 11.x and later
OS: All supported platforms
Question/Problem Description
Why is it necessary to run RFUTIL -C aimage sequence on an OS copy before rolling forward AI files ?
Error 8019 rolling forward AI files to OS copied database.
Why can the latest AI files not be rolled forward against the OS copy baseline?
Why aimage files after mark backedup cannot be rolled forward against an OS copy of production database?
Steps to Reproduce
Clarifying Information
Error MessageExpected ai file number 1 but file specified is n+1 in sequence. (8019)
Defect Number
Enhancement Number
There are essentially two different methodologies that need to be used in an OS copy/mirror methodology involving replication, depending on the Progress version. 

Of paramount importance to this subject (irrespective of Progress version) is that the "problem" with using an OS copy/snapshot and after-imaging, is that one has to manually ensure that on the database side, a valid OS backup copy is one that has an increment of the backup version in masterblock (RFUTIL -C MARK BACKEDUP) + a "CLEAN" ai file. In other words, 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 the following Progress Articles:

How to use an OS backup with after imaging enabled - post Progress 9.1E? 
How to use OS backup with after imaging enabled - pre Progress 9.1E? 
When to use rfutil -C sequence with an OS or proquiet database copy?   

Upgrading to Progress 9.1E (or OpenEdge 10.0B01 or 10.1A and above) is a good idea apart from the many other functional feature benefits, the introduction "RFUTIL -C SEQUENCE" utility that particularly relates to this case. It is not the objective of this Article 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 operation against an OS copy of an AI enabled database.

Before the introduction of this "RFUTIL -C SEQUENCE" utility, an 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 used for roll forward.


There are two counters in a database master block that have relevance in this situation:

  • One counter is the expected AI sequence,
  • The other counter is the current AI sequence.

These counters are incremented under the following conditions:

  1. 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.
  2. When probkup is issued against a database, it adjusts the expected AI sequence number.
  3. After an after image file applied to a database (roll forward), it adjusts the expected AI sequence number.
  4. The "rfutil sequence" option, 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),
  • The expected AI sequence number will not have been incremented under these conditions.
  • When AI files are rolled forward against this copy (hot-standby), the first rfutil -C roll-forward disables after-imaging.

The expected AI sequence in production is therefore typically 1 and never grows, unless probkup is occasionally used. More specifically, the expected AI sequence number is not in line 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 AIMAGE NEW" is issued precisely.

Every time an OS backup is taken, a progressively higher current AI sequence number is used which are recorded by the Progress rfutil utilities, but the expected AI sequence number 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.

Last Modified Date11/20/2020 7:28 AM
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.