When the oracle online backup is kick started a SQL command issued which puts the tablespaces into backup active mode, then copies the datafiles to disk / tape. Once the backup is complete, anothe sql statement issued which takes the tablespace out the backup mode.
The sqls are
alter database/tablespace begin backup;
alter database/tablespace end backup;
This can be seen via v$backup dynamic view.
SQL> select * from v$backup ;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- ---------
1 ACTIVE 831311 05-MAY-10
2 ACTIVE 831311 05-MAY-10
3 ACTIVE 831311 05-MAY-10
4 ACTIVE 831311 05-MAY-10
5 ACTIVE 831311 05-MAY-10
6 ACTIVE 831311 05-MAY-10
6 rows selected.
So, during the backup, all the tablespaces/datafiles are sealed and are not writable. Transaction changes are recorded in rego log files or sga or rollback/undo segments or something and then will be written back into the datafile when the database/tablespace is taken out of the backup mode.
We might have observed during the online backup there is a change of huge generation of redo data which may impact the database performance if the database is in archivelog mode.
Let's see what are steps taken during the online backup.
1. The tablespace is checkpointed.
2. The checkpoint SCN number in the datafile headers cease to increment with checkpoints.
3. Full images (before and after image) of the changed database blocks are written to the redologs.
When you issue
alter tablespace tbs_name begin backup;
A checkpoint is performed against the target tablespace and the datafile header is frozen, so, no more updates are allowed on the datafile header, this is for the database to know which was the last time the tablespace had a consistent image of the data.
But during the backup, the corresponding datafiles in the tablespace allow just normal read/write operations, that is IO activity is not frozen.
In case of redo log generation, each block will be recorded into the redo logs files, the first the block is changed. So, if a row is modified for the first time inside the data block since online backup is started, the complete block image is recorded in the redo log files but the subsequent transactions on the block will only record the transaction just as normal.
Above three steps are required to guarantee consistency during the file is restored and recovered. By the freezing the checkpoint SCN in the file headers, any subsequent recovery on that backup copy of the file will know that it must commence at that SCN. Having an old SCN in the file header tells recovery that the file is an old one, and that it should look for the redo log file containing that SCN, and apply recovery starting there. Note that checkpoints to the datafiles in online backup mode are not suppressed during the backup, only the incrementing of the main checkpoint SCN flag. An "Online backup checkpoint" SCN marker in the file header continues to increment as periodic or incremental checkpoints progress normally.
By initially checkpointing the datafiles that comprise the tablespace and logging full block images to redo, Oracle guarantees that any blocks changed in the datafile while in online backup mode will also be available in the redologs in case they are ever used for a recovery.
Now many one claim that during online backup there is excessive redo log generation than normal mode. It actually depends on the amound of block changes during online backup. Because the first time a block is changed logging of full images of the changed blocks in these tablespaces are recorded to the redo logs. Normally, Oracle logs an entry into the database block. But during the online backup, by logging full images of changed database blocks to the redologs, Oracle eliminates the possibility of the backup containing irresolvable split blocks. To understand this reasoning, you must first understand what a ssplit block is.
Typically, Oracle database blocks are a multiple of OS blocks. For instance, most AIX installations offer a default block size of 4MB and where as Oracle's default blcok size is of 8KB. That means the file system stores data in 4MB chunks and oracle reads or writes in 8K chunks or multiples of 8K. While backing up a datafile, backup utility (brbackup in the case of SAP) makes a copy of the datafile from the filesystem, using OS utilities such as copy, dd, cpio or ocopy. While making this copy, it is reading in OS block sized increments. If the database writer happens to be writing a DB block into the datafile at the sametime that backup utility is reading that block's constituent OS blocks, the backup copy of the DB block could contain some OS blocks from before the database performed the write, and some from after. This would be a split block.
By logging the full block image of the changed block to the redologs, it guarantees that in the event of a recovery, any split blocks that might be in the backup copy of the datafile will be resolved by overlaying them with the full legitimate image of the block from the redologs. Upon completion of a recovery, any blocks that got copied in a split state into the backup will have been resolved through application of full block images from the redologs.
No comments:
Post a Comment