Databases Reference
In-Depth Information
Understanding the Split-Block Issue
To perform a hot backup, one critical step is to alter a tablespace into backup mode before you copy any of the data
files associated with the tablespace, using an OS utility. To understand why you have to alter a tablespace into backup
mode, you must be familiar with what is sometimes called the split- (or fractured-) block issue.
Recall that the size of a database block is often different from that of an OS block. For instance, a database block
may be sized at 8KB, whereas the OS block size is 4KB. As part of the hot backup, you use an OS utility to copy the live
data files. While the OS utility is copying the data files, the possibility exists that database writers are writing to a block
simultaneously. Because the Oracle block and the OS block are different sizes, the following may happen:
1.
The OS utility copies part of the Oracle block.
2.
A moment later, a database writer updates the entire block.
3.
A split second later, the OS utility copies the latter half of the Oracle block.
This can result in the OS copy of the block's being inconsistent with what Oracle wrote to the OS. Figure
16-1
illustrates this concept.
Figure 16-1.
Hot backup split- (or fractured-) block issue
Looking at Figure
16-1
, the block copied to disk at time 3 is corrupt, as far as Oracle is concerned. The first half
of the block is from time 1, and the latter half is copied at time 3. When you make a hot backup, you're guaranteeing
block-level corruption in the backups of the data files.
To understand how Oracle resolves the split-block issue, first consider a database operating in its normal mode
(not in backup mode). The redo information that is written to the online redo logs is only what Oracle needs, to
reapply transactions. The redo stream doesn't contain entire blocks of data. Oracle only records a change vector in the
redo stream that specifies which block changed and how it was changed. Figure
16-2
shows Oracle operating under
normal conditions.
