Kbase 19646: What are some concerns with data integrity and functionality when an online backup of single and mul
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
4/10/2009 |
|
Status: Unverified
GOAL:
What are some concerns with data integrity and functionality when an online backup of single and multiple databases are performed.
GOAL:
What happens to ongoing transactions during an Online Backup?
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
FIX:
When an update of a record is requested from a single database, the block that contains the record is placed in the backup queue.
The main task executes two processes:
Connects to shared memory:
--Obtains the MT lock.
--Locks the Before Image (BI) system (database updates are disabled at this stage).
--Backs up the BI file(s).
--Releases the MT lock (database updates are enabled).
Scans the database looking for blocks to backup:
--Scans from beginning to end.
--Reads database blocks from disk into shared memory.
--Locks the block while in shared memory.
--Compresses blocks and copies to a local buffer.
--Unlocks the block (records available for read/update).
Use of multiple databases (for example, six) raises the questions of guaranteeing data integrity within the six databases as well as overall completion of the task. In order to backup multiple databases, many client sessions connect to the databases and perform numerous transactions involving multiple blocks of data from different sources which begin online backup at the approximately the same time using cron.
Two methods can be used:
The first method assumes Two Phase Commit (2pc)and After Image (AI) is being used. Also backup is done to disk (not tape) to allow multiple backups to take place at the same time:
1) Back up the 2pc coordinator database (in the background).
2) Back up the remaining databases (still in the background).
** If 2pc and AI is not being run, the backup is not a concern since a crash of one of the databases would potentially cause a transactional integrity issue, not to mention a recovery scenario.
An alternative method is the use of Quiet Points to coordinate multiple backups. One possibility is to use a script:
1) proquiet enable coordinator database.
2) proquiet enable remaining databases.
3) proquiet disable coordinator database (it will not be able to commit 2pc transactions).
4) Start online backup on coordinator.
5) proquiet enable coordinator (backup will pause).
6) proquiet disable remaining databases.
7) Start online backups on remaining databases.
8) proquiet disable coordinator database (backup will continue).
It is possible to end up with ready-to-commit transactions but probably not possible to end up with committed transactions in databases that are not also committed in the coordinator.