The following describes the stages of an online backup: PROBKUP online
The moment an online PROBKUP begins, all database operations are suspended until the BI file is backed up after which they can resume while relevant database blocks are being backed up. This is to ensure a concurrent snapshot of the database at the time the online PROBKUP command was executed: shared-memory, bi file and disk resident database
. This is assured as follows:
1. When the online backup starts, all BI logging activity stops
where all operations against the database are suspended with the exception of read operations. The time it takes to complete this phase is how long any connected user session running transaction activity (create/update/delete) stalls.
2. The backup process will cause a temporary spike in disk IO reads while:
- It determines how much data needs to be backed up.
- The database Buffer Pool and BI and AI buffers are flushed. When page writers are in use (APW, BIW, AIW), there will be correspondingly less buffers needing to be flushed, which should result in this stage being carried out faster than if no pagewriters are active.
3. Once all buffers are flushed, online PROBKUP backs up the BI file.
- More exactly, it backs up to the position of the before-image file with the High Water Mark.
- In this context, the term "BI file" does not refer to the whole disk-resident file, the total size of which is the sum of all the physical BI extents; it refers instead to bi blocks (as grouped by biclusters) currently in the double-linked bi cluster chain. Effectively, the High Water Mark of the bi extents.
To improve online backup performance the backup of bi clusters
was enhanced since OpenEdge 11.3.0
, to only backup Active BI clusters
within the BI cluster chain by default, as opposed to the entire BI cluster chain in previous versions.
4. Once the BI file is backed up, BI logging activity resumes and all online operations resume. None of these will be included in the backup volume. When after-imaging is enabled, all database changes will be recorded in the current AI file (see below)
5. After the BI is backed up, data blocks in the database get backed up, from the beginning of the database to the end of the database. Or more specifically, to the High Water Mark (HWM) of each Storage Area. The exception to this stage is when an incremental online backup is taken, which backs up only the data that has changed since the last full or incremental backup.
At this stage of an online backup, database buffers may need to be read from and written to disk while connected processes are able to make changes. When a database block needs to be modified it first gets backed up. The online backup jumps to that block in the shared-memory buffer pool (-B), backs it up, increments the backup counter on that block then releases it so that it can be modified. When the online backup encounters that block again, it simply skips the block, because the backup counter has already been incremented.
In this way, when the online PROBKUP is restored, the notes in the bi for the Physical Redo Phase (and Logical Redo and Undo as may be necessary) can successfully be executed as the information in the database blocks correspond to that exact snapshot in time that the database was at.
To this end it is important to consider that an OpenEdge database can be backed up a maximum of 65535 times. For further information refer to Article 000068748, How many online probkups can be taken?
5. When after-imaging is enabled, PROBKUP online automatically causes an AI extent switch before data blocks are backed up.
- AI extents need to be backed up separately using system utilities or the AI Management feature, they are not backed up as part of PROBKUP.
- Database backups can be restored to a specific time by first restoring the backup and then applying ai notes using RFUTIL roll forward with: endtime yyyy:mm:dd:hh:mm:ss
PROBKUP online is the only online backup that Progress supports other than full verified copies of every database extent (including ai files) which are taken while the database is quiesced. For further detail refer to Article 000022666, What happens when a PROQUIET is requested