PROBKUP has a limit of 65535 online backups:
The backup counter
stored in the database Master Block is 2 bytes which has a maximum value of 65535
The backup counter is incremented in the Database Master Block every time a PROBKUP is run (online, offline; full, incremental). For example, if one PROBKUP is taken every hour (online/offline/incremental), the counter will overflow in ~7 years. An Enhancement has been requested but not been implemented in the product to date.Once the backup counter overflows:
To reset database block backup counters:
- The logic in the online backup routine, which determines if a block should be backed up, does not consider existing data blocks as their backup counters are higher than the overflow value stored in the master block backup counter. The online backup will initially only backup 'new' database blocks that have never been backed up (ie empty blocks that have been formatted) and from that point on, these database blocks if they qualify and 'new' database blocks resulting in an invalid backup volume.
- The offline backup's logic is different and is not affected by the backup counter overflow. In other words, an offline PROBKUP will be complete and a full restored database will result, but subsequent online PROBKUP of this restore will suffer the same online backup counter overflow logic.
Once the backup counter has overflowed, neither PROCOPY nor offline backup PROREST will reset block backup counters. The following methods each have their pro's and con's which will need to be mooted per user case:
Until the database block backup counters can be reset:
- A dump and load of the database is needed to re-initialise the counters on all database blocks.
- Another strategy is to tablemove/indexmove all database objects to new Storage Areas, then remove the existing Areas. This includes using 'PROUTIL -C mvsch' to re-initialise the Schema Area.
An alternative backup strategy will need to be engineered, Options include:
OpenEdge 10 and later: To determine if the current backup counter value
- Offline PROBKUP
- Online OS copy (with PROQUIET on Enterprise databases)
- AI Rollforward
- OpenEdge Replication Target database online PROBKUP (available since OpenEdge 10.1C)
1. Examine the value of "bk_incr
" in the Master Block approaching 2^16 - 1 = 65535
$ proutil dbname -C truncate bi
$ proutil dbname -C dbrpr
Select the following Menu options, or provide these in an input text file as outlined below.
13. Display Block Contents
3. Select Block Type
C. Clear all types
1. Master Block
R. Return to Display Menu
Schema Area (6) Extent 1 Block 2
Progress 9 : To determine if the current backup counter value
0000 bk_dbkey: 0x00000020 32
bk_type: 0x01 1 (Master Block)
bk_frchn: 0x7f 127 (NOCHN)
** bk_incr: 0xFC92 64658
The DBRPR Menu Options above are not available in Progress 9. Instead, the Master Block
needs to be dumped with DBRPR and analysed, where the backup counter value is on the first line offset 06-07
1. The database Master Block for a multi-volume database is the second physical block of the first data extent (Schema Area).
Identify if the Schema Area has 32 or 64 records per blocks (RPB) from the database structure with "prostrct list <dbname>
2. Use DBRPR to dump the Master Block from the Schema Area (6)
By default the DBRPR tool starts in the Schema Area:
Current Working Area: Schema Area
The Master Block is the first Block in this Area:
- If the Schema Area is 32 RPB then the dbkey for the master block is 32.
- If the Schema Area is 64 RPB then dbkey for the master block is 64.
$ proutil dbname -C truncate bi
$ proutil <dbname> -C dbrpr <dump.in> /dev/null 2>&1
<Substitute with 32 or 64 depending on the RPB value>
Alternatively, navigate the DBRPR CHUI menu manually:
4. Dump Block
Enter dbkey: <32 or 64>
Examine the resulting 32.dmp or 64.dmp file:
The bk_updctr is at HEX offset 06-07
Example: The current backup counter value is 0xFDFE == 65,022 (513 backups remaining)>0000 4000 0000 017F FDFE 0000 0000 0000 00E6------------------------^^^^
, the value is byte swapped:
Example: The current backup counter value byte swapped is 0xFDFE == 65022 (513 backups remaining)>0000 4000 0000 017F FEFD 0000 0000 00E6 0000------------------------^^^^Other 'tells' that the backup counter has overflown:
Just because the bk_incr value
is not approaching the 65535 limit, it may have already overflown. Further samples of data blocks will need to be examined through the above DBRPR menu to find if there are any blocks with higher backup counter values.
a. The online backup is a lot quicker than usual, as there are less blocks that qualified to be backed up
b. The online backup volume is smaller than it should have been, provided the same volume is not overwritten by subsequent backups.
c. The backup volume will also restore faster than usual.
d. Parsing historic database lg files, the number of "backup blocks" drops dramatically then starts increasing again:
(13625) Wrote a total of 11955 backup blocks using 1.6 GBytes of media
(13625) Wrote a total of 16 backup blocks using 2.1 MBytes of media.
(13625) Wrote a total of 806 backup blocks using 107.1 MBytes of media.
e. Approximating the HWM from prostrct statistics with the backup blocks written from full online backups will show that online volumes do not include all blocks to the HWM of each Area
This database backup volume should be around 1.6 GB using 11955 backup blocks with a default -bf 34 and database blocksize of 4KB
f. The PROREST (restore) of this online backup will succeed, but the restored database is unlikely to be accessible when blocks that were not backed up are involved with BI redo or undo processing. If the database is accessible, it will crash with block corruption (1124) errors, where the blocks found are empty.
(9445) SYSTEM ERROR: read wrong dbkey at offset
(1124) SYSTEM ERROR: Wrong dbkey in block. Found 0, should be <dbkey> in area <area number>.