Previous | Table of Contents | Next

Page 600

TIP
Backup Manager will not perform an offline backup if there are open sessions (including Server Manager). If you have difficulty keeping sessions from opening in Oracle, you can open the database in RESTRICT mode before starting Backup Manager. Don't forget to close your Server Manager session!

Backup Manager does not back up the init.ora, config.ora, or archived log files. Although these files would typically be backed up during normal OS backup procedures, you should double-check with the system administrator to ensure that these very important files are backed up regularly.

Using Hot Physical Backups

The databases DBAs are entrusted with maintaining can often be the lifeblood of a company. They are sometimes called on to be available 24 hours a day, 7 days a week. In this environment, nothing short of an industrial-strength RDBMS will suffice. Oracle is such a database, with a track record spanning many years and many different environments.

Hot backups require you to have a higher level of expertise and comfort level with both Oracle and the supporting OS. Because of the added complexity of hot backups, you must also invest more time and effort in testing your backup strategy. No hot backup system should be considered reliable until you have recovered from a multitude of failures on a test system. Before embarking on a hot backup project, be sure that the added availability time is worth the additional costs and headaches.

Before continuing, you should make sure you're familiar with cold backups. We'll be building on the topics discussed in the previous section when discussing hot backups. In particular, this section takes your knowledge of cold backups and adds the complexity of backing up your database while it is up and running. Oracle provides two hot backup methods, one for the command-line UNIX/VMS world and one for the desktop (Windows) world. Because of this, we'll discuss hot backups for each method separately.

Understanding the Reasoning

A very common question from system administrators and DBAs alike is, "Why are hot backups such a big deal? We back up the OS with users on it without any problems, so we can just back up Oracle data files with users on the system. Right?" Wrong. Explaining the complexities of hot backups requires a brief discussion of how Oracle stores information and changes.

Recall that Oracle's atomic storage unit is the block (whose size is configurable when the database is created). There is data in the block, along with a block header that stores information about the data contained therein.

As a normal cold backup proceeds, each data file is copied bit by bit to the backup device. If the database is online, your trouble spot is the case in which both the backup program and Oracle are working on the same block. Suppose the backup program has just finished backing up the header portion of a particular block when Oracle writes new data and updates the header. Once the backup has finished backing up the block in question, it has an old header with new data. It has a corrupt block that Oracle would not know what to do with.

Page 601

Oracle's solution is to implement a special mode, known as backup mode, that is enabled and disabled on a tablespace-by-tablespace basis. When it's enabled and Oracle updates a block, an entire copy of the changed block is written to the redo logs. This is in contrast to Oracle's normal procedure of just writing the specific changes to the redo logs.

An online backup of the Oracle data files will still have the corrupt data blocks, but valid copies exist in the redo logs (and ultimately in the archived logs). In a recovery situation, a data file is restored and Oracle uses the redo/archived logs to "patch" the data files with valid blocks. Thus, the end result is a valid and consistent database. This system is illustrated in Figure 24.2.

FIG. 24.2
Oracle's backup mode
allows for the patching
of corrupted
data blocks during recovery.

Command-Line_Driven Hot Physical Backups

Hot backups in the command-line_based UNIX and VMS worlds are usually accomplished through a combination of SQL and OS-based scripts. The specifics will vary from OS to OS, but here's the sequence of operations:

  1. Build a list of tablespaces to be backed up.

  2. For each tablespace in that list:
    a. Build a list of data files.

    b. Place the tablespace in backup mode.

    c. Back up data files in the list from #2a to a backup device. d. Take the tablespace out of backup mode.
  3. Use Oracle to produce a "backupable" control file.

Page 602

  1. Back up the control file from #3 to a backup device.

  2. Force a log switch.

  3. Wait for the redo log to be archived.

  4. Back up the archived log directory to a backup device.

Building a List of TablespacesA simple SQL statement will generate a list of tablespaces in an Oracle database:

SELECT TABLESPACE_NAME FROM DBA_TABLESPACES;

Building a List of Data Files for a TablespaceYou'll need a list of data files for the tablespace so you know exactly which files to back up:

SELECT FILE_NAME FROM DBA_DATA_FILES WHERE
TABLESPACE_NAME='<tablespace name>';

Placing Tablespaces in Backup ModeBefore backing up a tablespace's data files, it needs to be placed in backup mode by using the following SQL statement:

ALTER TABLESPACE <tablespace name> BEGIN BACKUP;

Backing Up Data Files to Backup DeviceThis is largely an operating system issue. You would be wise to use SQL*Plus to generate a list of files that should be backed up for each tablespace.

Taking Tablespaces Out of Backup ModeJust as you used the SQL statement to place the tablespace in backup mode, you'll use a similar statement to take it out of backup mode:

ALTER TABLESPACE <tablespace name> END BACKUP;

Generating a "Backupable" Control FileBecause having an Oracle instance running necessarily means that the control files are open and prone to updates at any time, you need Oracle to produce a copy of the control files that is guaranteed to be consistent and will not be updated. The following SQL statement will do just this:

ALTER DATABASE BACKUP CONTROL FILE TO <output
filename> REUSE;

<output filename> should be any valid filename that specifies where you would like the control file copy to be written. REUSE just means that if the file already exists, it should be written over instead of aborted.

Forcing a Log SwitchOracle marks in the redo logs when a backup on a tablespace begins and ends. Because you do not back up redo logs, you need to archive the current redo log (which has the "end of backup" marker in it for the tablespace you just backed up). That way, when you back up the archived log directory, you'll also be backing up the logs with "begin backup" and "end backup" for each tablespace. The log switch is accomplished as follows:

ALTER SYSTEM SWITCH LOGFILE;

Waiting for the Switched Redo Log to Be ArchivedNormally when a log switch occurs, Oracle's archiver process immediately copies the current redo log to the archived log directory. This takes time, and Oracle does not tell you when the redo log has been successfully archived. Generally, a fixed delay of 2 to 5 minutes is placed in the backup script, which should

Previous | Table of Contents | Next