Explaining why 1119 error during ONLINE PROBKUP or PROBKUP -norecover

Explaining why 1119 error occurs during ONLINE PROBKUP or PROBKUP -norecover

1119 error during ONLINE backup
1119 error during probkup -norecover
Error 1119 re-appears during backup operation after having truncated the bi file and further activity causes the bi file to grow again.
 

Database has multiple bi extents
BI Blocksize is not be the default biblocksize (8K)
BI Cluster size is not be the default cluster size. (512K)

The 1119 error typically means there is corruption in the bi file or block on disk or that the wrong block was read into the buffer. If the conditions listed below do not apply and truncating the bi without having to force in does not fix the problem, then revert to re-instating the database from the previous backup set and roll forward if ai is enabled. 

If the error is on a probkup -norecover of a hot spare database, then truncating the bi is not recommended, as it will likely interrupt the next ai roll forward. In this case, re-sync the hot spare from the latest probkup of the production database and associated ai files. Refer to Article  PROBKUP on the standby database with -norecover fails 1119 1553   

Conditions:

The following set of conditions must apply for this 1119 error to occur, when there is not bi corruption and the corrective steps detailed below needs to be implemented.

1.   Database structure must have multiple bi extents, or only one fixed bi extent. Confirm with Condition 2 below or: 
2.   The -biblocksize must have been changed at some time in the past.
Confirm with PROMON to verify the current biblocksize: 
3.  ONLINE probkup or probkup with the -norecover option fails with this error 1119, however, the following complete without error:

• PROBKUP with server down (off line)
• PROCOPY
• Truncating the bi file

4. (Optionally) The database may have been created by PROCOPY into a pre-existing database structure where the bi blocksize or bi cluster size of the original database is not the same as  the bi blocksize or cluster size of the database being copied into it for subsequent online probkup/-norecover to fail with 1119

Why does error 1119 occur when there is no bi corruption?

Being able to subsequently complete BI redo and undo recovery confirms there is no bi corruption.

The reason error 1119 is raised is because of how two separate bi functions work:

1.   BI functions when changing the -biblock size. 

When the BI blocksize structure is changed:

• BI crash recovery takes place and the bi file is truncated.
• Only the first four (4) BI Clusters are formatted initially.
• More blocks are formatted in the bi as needed thereafter. (see examples below).

BI file blocks and block numbers by default

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|01|02|03|04|05|06|07|08|09|10|11|12|13|14|15|16|17|18|19|20|21|22|
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

bi file blocks and block numbers after change to 4k blocksize using: proutil dbname -C truncate bi -biblocksize 4

---------------------- -- -- -- -- --  
| 01 | 02 | 03 | 04 |17|18|19|20|21|22|
---------------------- -- -- -- -- --
***notice reading the bi file the block numbers go from 04 to 17***

2.   BI functions when During an online probkup or probkup with the -norecover option.

When a PROBKUP is taken without crash recovery:

• All bi blocks in the fixed extent {01 .. 22} are backed up. 

(Whereas) offline PROBKUP and PROCOPY:

• Only the active blocks in the bi file {01 .. 04} are backed up.

With ONLINE PROBKUP (or -norecover), the utility is reading the bi block numbers for the whole fixed bi extent (active, non-active & unused blocks) and finds a block that goes from 04 to 17, the utility reads this as corruption, aborts the backup and send the 1119 error. This example is simplified to demonstrate. The block referenced in the 1119 message will be whichever bi block the last bi cluster extended to.
 

This behavior has been Enhanced in the following OpenEdge versions:

• OpenEdge 10.1B or later where by default, only the active bi clusters (aka initialized bi blocks) are backed up with the -norecover option
• Upgrade to OpenEdge 11.3.0 or later where by default, only the active bi clusters (aka initialized bi blocks) are backed up during online backups. OpenEdge 11.5 or later is recommended when active bi clusters exceed 2GB. Refer to Article  What happens during an online backup of the database?   

 

After changing the BI Blocksize, truncating the bi file alone will not fix this problem, as explained above. Physically removing these bi extents from the database structure and then adding the bi extents back in again is necessary to re-format the structure.

The following steps are necessary (exclude reference to after-imaging if it doesn't apply):

0.   Shutdown the database:
1.   End AI on production database. This will also disable AI Management (not available prior OpenEdge 10.1A) and Replication if either is active. If OpenEdge Replication is enabled the target database will have to be re-sourced after these corrective steps have been undertaken.
   

• The new BI block size is in kilobytes. Valid values are 0, 1, 2, 4, 8, and 16 and cannot be smaller than the database block size..
• The new BI cluster size is in kilobytes. The number must be a multiple of 16 in the range 16 to 262128 (16K-256MB).