熱備或RMAN備份期間 fractured (split) block 的檢測

One danger in making online backups is the possibility of inconsistent 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 afractured 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 ,   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 datbase writes the before-image ofthe 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 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.