ANSWER KEY: Know-IT-all Chapter Quiz #2
"Chapter 8: Backup and recovery for high availability environments"
Page 276: "An analysis of backup and recovery issues that get opened with Oracle Support Services revealed an interesting point: in situations where backups existed for recovery, a full restore of the entire database was initiated 40 percent of the time. In other words, when a hardware failure or a data corruption occurred, the DBA initiated a restore of every datafile in the database. Folly!"
Page 281: "There is so much good stuff to say about RMAN, there's simply no room in this chapter to cover all the territory. The basics have already been described:
A. Flashback Recovery Area (FRA)
Page 286: "The concept behind the FRA is to simplify the management of your backup and recovery duties by consolidating the requisite files into a single location that Oracle and RMAN can then micromanage, while the DBA moves on to other important HA duties. This simplification is based on some underlying principles of a solid backup strategy that focuses on availability."
Page 291: "RMAN adds an increased amount of reliance on the presence of a controlfile for its continual operation: the cfile is the lookup table for what to back up and restore -- it is the lookup table for determining where the RMAN backups reside and when they were taken, and it is now the home of our backup job controls. As such, we must be just a little nervous about the health of the controlfile."
C. User errors should be dealt with using media recovery, not Flashback Technology.
Page 293: "The HA backup strategy is based on a few guiding principles:
Page 294: "Multiplexing refers to the number of files that are included in a single backupset. During a backup of type backupset, RMAN will stream data from all the files included in the backup job into a single backupset. This leads to efficiencies at the time of the backup, as all files can be accessed at the same time. However, be cautious of multiplexing, as having a high degree of multiplexing can lead to problems during restore."
Page 304: "The most common form of recovery should be datafile recovery. To perform datafile recovery, you must offline the datafile prior to restoration. You can do this from the SQL prompt, or from within RMAN (shown next). These recovery commands assume the database is still open and running."
Page 306: "So we get to the one feature of RMAN that is absolutely too cool for words: block media recovery (BMR). BMR refers to RMAN's ability to restore from backup a single data block, and then perform media recovery on that single block. This is huge, people. Ora-1578? No problem. Plug in the file number and block number from the 1578 error, and RMAN will go to the last backup, get the one block showing corruption, restore it, and then scroll through the archivelogs to see if any of the redo need be applied to the block. Here's the kicker: The file that has the corrupt block remains available through the recovery process. Wait, it gets better. The segment that contains the corrupt block is available during the recovery process. In other words, you can continue to use the table that has a corrupt block, as long as you don't try to select from the bad block. Talk about high availability! It doesn't get any better than this."
D. backup directly to tape
Page 306: "RMAN is a fully functional backup utility that provides unparalleled functionality, particularly in a high-availability environment. However, there is one thing RMAN cannot do by itself: back up directly to tape. To back up directly to tape, RMAN must pass the stream of data blocks to a media management layer (MML), which can redirect the data flow to a media management server that controls your tape devices."
A. hot backup mode
Page 323: "To use split-mirror technology successfully with an Oracle database, it is required that, prior to the mirror split, every tablespace in the database be placed into hot backup mode first. This is required because, despite what the vendor tells you, the mirror split is not a singular event. It is more like peeling a banana: It starts in one place, and progresses to the end. While fast, it is not occurring at the same time across the entire volume. Therefore, it is possible that a write is occurring to the primary volume database, but the write only occurs at the bottom of the unpeeled secondary volume."
NOTE: This prize drawing is now closed -- congratulations to book giveaway winners Patrick M. and Karen R.!
For more information
Featured Topic: RMAN tips and tricks
Featured Topic: Backup and recovery
Ask the Experts: Brian Peasland on backup and recovery
This was first published in May 2004