ORACLE hot standby begin backup/end Backup

After the begin backup is performed, Oracle marks the data files that will be backed up as hot-backup-in-progress, locking the SCN of the datafile header to be backed up, such as at this point scn= 100, while Redolog will remember this SCN, other data files normal use, SCN will continue to grow. The data file is then allowed to write and checkpoint during the backup of the data file to be backed up, and may be checkpoint more than once, and all operations and checkpoint in the process are logged to Redolog and Archivelog as usual. The problem arises when the minimum storage unit for the Oracle system data file is a block of data, such as 8192bytes, while the operating system's minimum storage unit OS is fast to a fixed 512bytes. After Oracle executes the begin backup copy operation, this copy operation is subordinate to the operating system command, each time can only copy an OS block, if the Oracle database block unit is 8192bytes, then this Oracle Block is comprised of 16 OS blocks, which we mark as 1--16 OS block for ease of understanding. The copy command has no order for the copy of the data block, that is, the first time it is possible to copy block 1th, and the second time it may copy block 16th. In this copy process, for the Oracle hot-standby mechanism, the entire block of Oracle is allowed to read and write, which creates the following problems, such as: Perform a BEGIN backup,oracle lock datafile header of the SCN, Assuming that data room 10, which is stored in Oracle block, is copied, the system will copy the 16 OS blocks in this Oracle block one by one to the backup directory, and if there is data written to the fifth OS block, For example, the data in this block of data update to 20,oracle will call the DBWR process to make data changes to the data block, the same DBWR process is also not sequentially write data to the 16 OS block, so he may have copied from the five OS block to start writing data , it is also possible to start writing data from the remaining 11 OS blocks. If you start writing from the remaining 11 OS blocks, there will be a serious consequence of a hot backup copy in progress, and several of the remaining 11 blocks may have changed so that the copied backup file will be inconsistent, and the copyBackup files out for this Oracle block, the first 5 blocks are the original storage data 10 information, and then the copy of the 11 blocks may be stored in the update after the data 20 information, which is absolutely not allowed. As a result, Oracle has made such a mechanism that, if a data UPDATE,DBWR process is required during the copy process to tell Oracle that I want to update, Oracle will notify the backup system to first write the Oracle The block is fully mirrored in redo, and redo records the image of the entire block of data, not a single piece of information. DBWR then began to randomly write data to the 16 OS blocks in this Oracle block. In this way, when the data is restored, the Oracle check is resumed from the time the SCN is locked, and if an Oracle block at that point is checked, the "corrupted block" described above He will copy the image in the redo to this Oracle block completely, so that this chunk is the complete block of data at the time of the begin backup, and then redo can recover from the SCN backwards. This process also explains why sometimes redo can increase dramatically in the hot-standby process. After the end of the hot standby end backup, Oracle unlocks the SCN of the backup DataFile header and automatically synchronizes with the current SCN of the system, for example when the SCN has become 1000, then the SCN for the backup file is automatically synchronized with the system to 1000.
Because data files and redo are allowed to be written during the backup process, the backed-up data file contains not only scn=100 previous data, but also all operational data for SCN between 100 and 1000. This is what I call the "broken Block" above.
When data is restored, the backed up data file is copied to the Oracle system because the SCN of the backup file is the point in time when the ALTER DATABASE begin backup is executed, that is, Scn=100,oracle will look for the SCN in Redolog , if there is a "corrupted block" at the SCN point in time, redo the previously mirrored block and automatically executes all operations and data after the SCN is greater than 100, writing to the current data file. The data recovered from the backup file to the current data file, the SCN between 100 and 1000 will be overwritten by the redo operation. "From:http://blog.chinaunix.net/uid-182041-id-84238.html" ============ in Oracle Backup, we can use the ALTER tablespace ... begin Backup puts the tablespace in the online backup mode, then uses the operating system command to make the physical copy of the data file, to achieve the purpose of the backup, the data file is still online, and normal data insertion, but will lead to more than usual redo record generation

Generating more redo records is caused by hot preparation, because in the hot standby process, we use the copy/ocopy command, this is the command of the operating system, he and Oracle is irrelevant, and Oracle's internal processes such as DBWR can not interact with, which may lead to the emergence of hot tiles, Because the operating system reads the data file, his IO size is not the size of block size, it is generally smaller, which causes a block of data to be read multiple times, and each acquisition of the parts are inconsistent (data constantly updated), in order to restore the Broken hot monument block, Oracle has the data block pre-image this operation, for the data file block of the backup mode, the first time the data block is affected by DML, the whole copy to redo, the subsequent DML in the undo, the normal redo information records, when the data file recovery, Will first apply the first Data block pre-image, and then the subsequent redo record information, more log records are generated by this pre-image, this can not be confused with undo, he is the entire data block, not a simple row record, because Oracle itself does not know that in the copy of those blocks may appear hot monument, So as long as there is a DML block during backup, follow the above situation, so if you run a large number of batch programs during backup, the log information will accumulate

And why is alter tablespace ... begin backup to freeze the SCN of the file header?

This is primarily the starting SCN for the recovery of the data file later, after the begin backup is released, the system will perform a checkpoint on the tablespace and solidify all the transaction applications before that checkpoint to the data file, and then freeze the SCN until end backup is used, so that the backup process ends. Update to the new SCN, the reason for the freeze is because when copying a data file using operating system commands, he cannot guarantee that the first read block is the data file header, if not frozen, it may start from the backup, the file header has been updated several times, and the file header has not been copied, so that the file header is copied, His SCN is far greater than the SCN of other data blocks in the data file, so it is unrealistic to locate the recovery starting point from the SCN of the file header.

As can be seen from the above, hot spare and Rman online backup is an essential difference, Rman is to connect the target database, generate Oracle user process, call his own process package, interacting with DBWR, using Oracle's SGA or PGA for backup, In this way, he will first ensure that each block is consistent, there will be no hot stele phenomenon, thus reducing the production of redo records, and he does not need to freeze the file head SCN, because Rman can always read the data file header block first. "From:http://www.cnblogs.com/froster/archive/2005/11/16/277633.html"

ORACLE hot standby begin backup/end Backup