Feedback
Did this article resolve your question/issue?

   

Article

How to estimate how long BI Recovery will take to complete

Information

 
TitleHow to estimate how long BI Recovery will take to complete
URL Name000035413
Article Number000178019
EnvironmentProduct: Progress
Version: 9.x
Product: OpenEdge
Version: 10.x, 11.x
OS: All Supported Operating Systems
Question/Problem Description
How long will bi crash recovery take and how many transactions need to be undone ?
How to get metrics on the length of time it will take to truncate a large bi file?
How to predict BI REDO UNDO phases when restarting a database that crashed?
How long will it take to truncate the BI file
How to estimate how long BI Recovery will take to complete.
During BI recovery, the REDO and UNDO phases are reported at the begin and end of the redo or undo operation.
How to get metrics during BI UNDO processing as to what transactions were involved or when they were started.
Steps to Reproduce
Clarifying Information
The Redo phase is based on the last two clusters in the rebuilt bi cluster chain.
Transaction undo's depend on the related bi cluster where RL_TBGN note for the transaction that was not completed.
Error Message(5326) Begin Physical Redo Phase at 369375 .
(7161) Physical Redo Phase Completed at blk 372005 off 16317 upd 165912.
(13547) At end of Physical redo, transaction table size is 8192.
(12080) Begin Replication Redo Phase for 1 live transactions from 369375 .
(12081) Replication Redo Phase completed at block 60717, offset 12417.
(7163) Begin Physical Undo 2 transactions at block 372005 offset 16353
(5331) Physical Undo Phase Completed at 372004 .
(7162) Begin Logical Undo Phase, 1 incomplete transactions are being backed out.
(11231) Logical Undo Phase begin at Block 372004 Offset 8849.
(12095) Logical Undo Phase completed at block 60717, offset 12417.
Defect/Enhancement NumberEnhancement OE00226136 / PSC00248780
Cause
Resolution
Upgrade to OpenEdge 11.6.1 where two new parameters were enabled:
  • Crash Recovery Status (-crStatus): To assist in predicting how long crash recovery will take
  • Crash Recovery Transaction Display (-crTXDisplay): To report on how many transactions are involved in BI Undo
For further information refer to Article  How to display how far along bi crash recovery is within the whole process?   

The time it takes to truncate the BI file depends on its size, its environment (and location) and whether there were any active database transactions at the time. Tuning the BI I/O subsystem will improve crash recovery times and online processing. For further advice refer to Article  How to tune BI I/O performance   
Workaround
Prior to OpenEdge 11.6.1, one can neither easily nor reliably predict how long it will take to finalise the REDO and UNDO phases of BI recovery.  

The time it takes to truncate the BI file depends its environment (and location), the number of bi active clusters, the number of active database transactions at the time and the time it takes to seek then apply these transaction notes to the related dbkeys in the database itself.

Estimates can be gathered by:

a. Estimate how long it will take to rebuild the bi cluster chain before bi recovery can take place

Pre-grow the bi chain to the same size as the current bi filesize on a test database

Add the same BI extent structure to the test database
$  prodb test sports
$  proutil test -C truncate bi
$  prostrct remove test bi
$  prostrct add test addbi.st
$  proutil test -C truncate bi -bi <biclustersize (KB)>
-biblocksize (8 or 16 KB)

Pre-grow the before-image clusters:
$  proutil test -C bigrow (N)
Where N == (size of the production bi files)/biclustersize - 4

b. Restore the database to a test environment on the same server with an OS copy,

Determine how many bi clusters will be involved bi recovery :
$  proutil dbname -C biscan 

Review the biscan output written to the database lg file:

Analyse all non-zero time values: subtract the highest counter value from the smallest counter value

Example: BI Recovery needs to build, scan and process bi note content from 100 clusters (x 256 blocks)

(4714)  Cluster: 100 Blk:25600 Nxt:25856 Prv:25344 Time:689 Ctr:109
(4714)  Cluster: 101 Blk:25856 Nxt:0 Prv:25600 Time:0 Ctr:110      
(4714)  Cluster: 102 Blk:0 Nxt:256 Prv:25856 Time:430 Ctr:9        
 
When the database is in emergency recovery mode a variable bi extent can be added without having to first truncate the bi file and remove the current variable extent.  Start crash recovery and monitor the size of the variable extent growth to estimate how much longer it may take to complete.
Notes
References to Other Documentation:

OpenEdge Data Management: Database Administration, Recovering a Database, Crash recovery

Progress Articles:

 Considerations when upgrading from OpenEdge 11 to a later OpenEdge 11 version.
 
Last Modified Date11/20/2020 7:09 AM
Attachment 
Files
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.