Detection of Fractured Blocks During Open Backups

One danger in making online backups is the possibility of inconsistent data within a block. For example, assume that you are backing up block 100 in datafile users.dbf. Also, assume that the copy utility reads the entire block while DBWR is in the middle of updating the block. In this case, the copy utility may read the old data in the top half of the block and the new data in the bottom top half of the block. The result is called a fractured block, meaning that the data contained in this block is not consistent. at a given SCN.

When performing backups of an open tablespace without using RMAN, you must put tablespaces in backup mode to prevent the creation of fractured blocks in your backup. When not in backup mode, the database records only changed bytes in the redo stream. When a tablespace is in backup mode, each time a block is changed the database writes the before-image of the entire block to the redo stream before modifying the block. Then, the database also records the changes to the block in the redo log. During user-managed recovery using SQL*Plus, the database applies both the captured block images and the recorded block changes from the redo logs. Applying the block images repairs any possible fractured blocks in the backup being restored and recovered.

RMAN does not require that you put datafiles into backup mode. During an RMAN backup, a database server session reads each block of the datafile and checks whether each block is fractured by comparing the block header and footer. If a block is fractured, the session re-reads the block. If the same fracture is found, then the block is considered permanently corrupt. If MAXCORRUPT is exceeded, the backup stops.

4,rman

run{

allocate channel  c1 device type disk;

allocate channel  c2 device type disk;

backup as compressed backupset database

}

list backup;

crosscheck backupset;

delete expired backupset;

list backup of database;

restore preview database;预览oracle使用哪个来恢复

from tag= 或者空格