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 placePre-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.
