Yes, the roll forward database goes through the
Redo Phase of bi recovery at the start of every roll forward operation, to assure the last cluster's transaction notes are confirmed. This can be seen in the roll forward database log file while rolling forward an after image extent:
(451) Roll forward session begin for <username> on CON:.
(5326) Begin Physical Redo Phase at 0 .
(7161) Physical Redo Phase Completed at blk 0 off 235 upd 0.
(13547) At end of Physical redo, transaction table size is 5445.
(660) Beginning roll forward of after-image file <file_name>.a<n>.
It is not the BI Redo Phase that invalidates roll forward operations. It is caused by other OpenEdge utilities access - or user application processes that open the database between subsequent roll forward operations.
The design and use of RFUTIL -C roll forward is continually redoing database transactions until it reflects the original database at the time of a crash, disaster or intended roll forward time/transaction using a design implementations similar to the physical REDO phase of crash recovery. Only when all intended roll forward operations have completed, should the database then be allowed to be accessed. When the database is opened it will go through the last two phases of crash recovery, namely: "Physical Undo" and
"Logical Undo" which will only be performed should outstanding transactions are found after the last notes were applied.
There is nothing stopping the bi file of a hotspare being truncated, or more specifically, there is nothing stopping the database being opened with any utility that initiates all three phases of bi recovery and initiates the Physical and Logical UNDO phases before allowing access to the database.
To prevent BI UNDO Recovery and assure continued roll forward processing1. Apply ai extents with the roll forward OPLOCK feature
To Restrict only Roll forward access use: RFUTIL - C OPLOCK
- Since OpenEdge 10.2B, the RFUTIL OPLOCK qualifier enforces a protection mechanism during the roll forward process.
- When enabled it prevents any interruption access to the target database before the final roll forward session is completed.
- The RFUTIL OPUNLOCK qualifier then disables the protection mechanism, making the database accessible again to other users or utilities after it completes the Physical and Logical UNDO phases of bi recovery. Not further ai notes can be applied.
For example: Prevent access until all ai files that need to be rolled forward have completed
$ rfutil <dbname> -C roll forward oplock -ailist <ai files to apply in sequence>.txt [ -MemCheck -DbCheck ] [ [ verbose ] [ -B n ] [ -r ]
$ rfutil <dbname> -C roll forward -a ai-name [ endtime yyyy:mm:dd:hh:mm:ss | endtrans transaction-number] [ -B n ] [ -r ]
$ rfutil <dbname> -C roll opunlock
2. To backup the hotspare database use: NORECOVER
When if the hotspare / standby database needs to be backed up and still available for future roll forward use
probkup -norecover. This will skip crash recovery when in-flight transactions would otherwise initialise the Physical and Logical UNDO phases of bi recovery
