Requires Free Membership to View
When you place a tablespace in BACKUP mode, you signal to Oracle that you are going to be copying the tablespace's datafiles to your backup destination. This does not stop DML occurring for objects in that tablespace. It is possible that in the middle of copying one block from the datafile, Oracle changes that block in the datafile. Part of your copy of that block is 'old' and part is 'new.' This is called a fractured block. To solve the fractured block problem with user-managed hot backups, any time any record in a block is changed belonging to a tablespace in BACKUP mode, the entire block is written to the online redo log files. This occurs for all DML statements against that tablespace, not just the first one. Change vectors are not written to the online redo logs for any DML on a tablespace that is in BACKUP mode. Rather, the entire block is written to the online redo logs. Once you take the tablespace out of BACKUP mode, change vectors are written to the online redo logs.
Since DML can cause more than just a change vector to be written to the online redo logs during a user-managed hot backup, much more data can be written to the online redo logs. To mitigate this impact, you can do two things. One, perform your hot backup during periods of low activity. Two, place only one tablespace in BACKUP mode, back it up, place the tablespace back in normal mode and then proceed with the next tablespace. Many make the mistake of placing all tablespaces in BACKUP mode even though their backup is only copying one at a time.
This was first published in April 2006
Join the conversationComment
Share
Comments
Results
Contribute to the conversation