Data Consistency, Recovery, and Migration 4-35
Write Tape Header Page
Archive blobpages
The second task facingtbtape is to prevent database server processes from
overwriting blobspace blobpages before they have been archived. Since
blobpages do not pass through shared memory, the strategy of archiving
from the physical log (described in the preceding section) is insufficient in
itself.In addition, tbtape must postpone all changes to blobpages until after
the blobpage is archived.
To accomplish this,tbtape blocks allocation of blobpages in each blobspace
chunkuntil tbtape has read and archived all used blobpages in the chunk. As
soon as the chunk is archived, blobpage allocation in that chunk resumes.
One implication of this implementation is that during an online archive,
blobscannot be inserted into a blobspace until the blobspace chunk has been
archived.Since chunks are read and archived by tbtape in order of the chunk
identification numbers, you can minimize this inconvenience by creating
blobspaces early, ensuring a low chunk ID number.
Write Tape Header PageAftertbtape and tbinit have synchronized activities,tbtape writes a tape
header page to the archive device. The tape header page contains the
following information:
■The tape device block size (TAPEBLK)
■The size of tape (TAPESIZE)
■A flag that indicates the tape is for an archive
■A timestamp that indicates the date and time of the archive
■The archive level
■The ID number of the logical log file that contains the checkpoint
record that began the archive
■The physical location of that checkpoint record in the logical log file
Ifthe archive device (TAPEDEV) is defined as /dev/null,tbtape does not write
apage to the device. Instead, tbtape updates the active PAGE_ARCH reserved
pagewith the same information that would have been written to the header
page.(Refer to the preceding list.) The checkpoint information is also copied
to the active PAGE_CKPT (checkpoint) reserved page.