Filter
Top Products
Data Consistency, Recovery, and Migration 4-35
Write Tape Header Page
Archive blobpages
The second task facing tbtape 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
chunk until 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,
blobs cannot 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 Page
After tbtape 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
If the archive device (TAPEDEV) is defined as /dev/null, tbtape does not write
a page to the device. Instead, tbtape updates the active PAGE_ARCH reserved
page with 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.