Oracle7 Parallel Server Concepts and Administrator's Guide Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index

Go to previous file in sequence Go to next file in sequence

Backing Up the Database

Those behind cried "Forward!" And those before cried "Back!"

Thomas Babington, Lord Macaulay: On Frederic The Great

To protect your data, you should archive the online redo log files and periodically back up the datafiles. You should also back up the control file for your database and the parameter files for your instances. This chapter discusses:

Oracle Parallel Server supports all of the backup features of Oracle in exclusive mode, including both online and offline backup of either an entire database or individual tablespaces.

Archiving the Redo Log Files

This section explains how to archive the redo log files for each instance of a parallel server:

Archiving Mode

Oracle provides two archiving modes: ARCHIVELOG mode and NOARCHIVELOG mode. With Oracle in ARCHIVELOG mode, the instance must archive its redo logs as they are filled--before they can be overwritten. The logs can thus be recovered in the event of media failure. In ARCHIVELOG mode, you can make both online and offline backups. In NOARCHIVELOG mode, you can only make offline backups.

Note that archiving is a per-instance operation which can be handled in one of two ways:

See Also: "Online and Offline Backups" [*].

Automatic or Manual Archiving

Archiving can be performed automatically or manually for a given instance, depending on the value you set for the initialization parameter LOG_ARCHIVE_START.

For Oracle Parallel Server, each instance can set this parameter differently. Thus, for example, you can manually use SQL commands or Server Manager to have instance 1 archive the redo log files of instance 2, if instance 2 has LOG_ARCHIVE_START set to FALSE.

Automatic Archiving

The ARCH background process performs automatic archiving upon instance startup when LOG_ARCHIVE_START is set to TRUE. With automatic archiving, online redo log files are copied only for the instance that performs the archiving.

In the case of a closed thread, the archiving process in the active instance performs the log switch and archiving for the closed thread. This is done when log switches are forced on all threads to maintain roughly the same range of SCNs in the archived logs of all enabled threads.

Manual Archiving

When LOG_ARCHIVE_START is set to FALSE, you can perform manual archiving in one of the following ways:

Manual archiving is performed by the user process that issues the archiving command; it is not performed by the instance's ARCH process.

ALTER SYSTEM ARCHIVE LOG Options for Manual Archiving

ALTER SYSTEM ARCHIVE LOG provides the following options for manual archiving:


All online redo log files that are full but have not been archived.


The lowest system change number (SCN) in the online redo log file.


The current redo log of every enabled thread.

GROUP integer

The group number of an online redo log.

LOGFILE 'filename'

The filename of an online redo log file in the thread.


The next full redo log file that needs to be archived.

SEQ integer

The log sequence number of an online redo log file.

THREAD integer

The thread containing the redo log file to archive (defaults to the thread number assigned to the current instance).

You can use the THREAD option of ALTER SYSTEM ARCHIVE LOG to archive redo log files in a thread associated with an instance other than the current instance.

See Also: Oracle7 Server SQL Reference manual for information about the syntax of the ALTER SYSTEM ARCHIVE LOG statement.

"Archiving Redo Information" chapter in Oracle7 Server Administrator's Guide for more information about manual and automatic archiving.

"Recovery Structures" chapter in Oracle7 Server Concepts for more information about manual and automatic archiving.

"Forcing a Log Switch" [*] for more information about threads and log switches.

Archive File Format and Destination

Archived redo logs are uniquely named as specified by the LOG_ARCHIVE_FORMAT parameter. This operating-system specific format can include text strings, one or more variables, and a filename extension.

LOG_ARCHIVE_FORMAT can have the following variables:

Parameter Description Example
%T thread number, left-zero-padded arch0000000001
%t thread number, not padded arch1
%S log sequence number, left-zero-padded arch0000000251
%s log sequence number, not padded arch251
Table 22 - 1. Archived Redo Log Filename Format Parameters

Note: Table 22 - 1 assumes that LOG_ARCHIVE_FORMAT= arch%parameter, and the upper bound for all parameters is 10 characters.

The thread parameters %t and %T are used only with the Parallel Server Option. For example, if the instance associated with redo thread number 7 sets LOG_ARCHIVE_FORMAT to LOG_%s_T%t.ARC, then its archived redo log files are named:


Note: Always specify thread and sequence number in archive log file format for easy identification of the redo log file.

See Also: Your Oracle system-specific documentation for default log archive format and destination.

"Archiving Redo Information" chapter in Oracle7 Server Administrator's Guide for more information about specifying the archived redo log filename format and destination.

"Recovery Structures" chapter in Oracle7 Server Concepts.

Redo Log History in the Control File

You can use the MAXLOGHISTORY clause of the CREATE DATABASE or CREATE CONTROLFILE command to enable the control file to keep a history of the redo log files that a parallel server has filled. After creating the database, it is only possible to disable or enable the log history by creating a new control file. Note that using CREATE CONTROLFILE destroys all log history in the current control file.

The MAXLOGHISTORY option specifies how many entries can be recorded in the archive history. Its default value is operating-system specific. If MAXLOGHISTORY is set to a value greater than zero, then whenever an instance switches from one online redo log file to another, its LGWR process writes the following data to the control file.

Note: LGWR writes log history data to the control file during a log switch, not when a redo log file is archived.

Log history records are small, and are overwritten in a circular fashion when the log history exceeds the limit set by MAXLOGHISTORY.

During recovery, Server Manager prompts for the appropriate file names. You can use the log history to reconstruct archived log file names from an SCN and thread number, for automatic media recovery of a parallel server that has multiple threads of redo. An Oracle instance that accesses the database in exclusive mode with only one thread enabled does not need the log history--but the log history is useful when multiple threads are enabled, even if only one thread is open.

You can query the log history information from the V$LOG_HISTORY dynamic performance table. Additionally, V$RECOVERY_LOG, which also displays information about archived logs needed to complete media recovery, is derived from information in the log history records.

Multiplexed redo log files do not require multiple entries in the log history. Each entry identifies a group of multiplexed redo log files, not a particular filename.

See Also: Your Oracle system-specific documentation for the default MAXLOGHISTORY value.

"Mounting Redo Log Files for Recovery" [*] for Server Manager prompts during recovery.

Checkpoints and Log Switches


A checkpoint causes modified datablocks held in the SGA buffer cache to be written to disk. A global checkpoint causes all instances to write modified datablocks to disk. An instance checkpoint causes one instance to write modified datablocks to disk. Lastly, a datafile checkpoint causes all instances to write the modified datablocks for a single datafile to disk. During a checkpoint, the DBWR process of an instance writes the modified datablocks to disk only for that instance.

Because all database changes up to the checkpoint are written to the datafiles, redo log entries before the checkpoint are not needed for recovery.

For a single instance with exclusive access to a database, checkpoints determine the maximum recovery time after instance failure, because you only need to recover changes made after the last checkpoint.

For multi-instance systems, checkpoints determine the maximum recovery time for each instance. Since instances usually have different checkpoint intervals, instance failures on different nodes generally require different recovery times.

Log Switches

A log switch is the point in time when an instance's LGWR process ceases writing redo log entries in one online redo log file and begins writing redo log entries in the next available redo log file.

The intervals between checkpoints for each instance are determined by the frequency of log switches, which depend on the redo log file size and the amount of redo data generated, and by the values of the initialization parameters LOG_CHECKPOINT_TIMEOUT and LOG_CHECKPOINT_INTERVAL. Additional checkpoints and log switches can be forced by various SQL statements and Server Manager commands, and a parallel server can force a log switch so that an online redo log file can be archived.

When Checkpoints Occur Automatically

An instance performs a checkpoint under any of the following circumstances:

See Also: "Forcing a Log Switch" [*].

Forcing a Checkpoint

The SQL statement ALTER SYSTEM CHECKPOINT explicitly forces Oracle to perform a checkpoint for either the current instance or all instances. Forcing a checkpoint ensures that all changes to the database buffers are written to the datafiles on disk.

The GLOBAL option of ALTER SYSTEM CHECKPOINT is the default. It forces all instances that have opened the database to perform a checkpoint. The LOCAL option forces a checkpoint by the current instance.

A global checkpoint is not finished until all instances that require recovery have been recovered. If any instance fails during the global checkpoint, however, the checkpoint might complete before that instance has been recovered.

In Server Manager, you can use the Force Checkpoint dialog box to force a global or local checkpoint.

To force a checkpoint on an instance running on a remote node, you can change the current instance with the Server Manager command CONNECT.

Note: You need the ALTER SYSTEM privilege to force a checkpoint.

See Also: "Specifying Instances" [*] for information on specifying a remote node.

Forcing a Log Switch

A parallel server can force a log switch for any instance that fails to archive its online redo log files for some period of time, either because the instance has not generated many redo entries or because the instance has shut down. This prevents an instance's redo log, known as a thread of redo, from remaining unarchived for too long. If media recovery is necessary, the redo entries used for recovery are always reasonably recent.

For example, after an instance has shut down, another instance can force a log switch for that instance so that its current redo log file can be archived.

Note: The LOG_CHECKPOINT_TIMEOUT and LOG_CHECKPOINT_INTERVAL initialization parameters can force an inactive instance to perform checkpoints, but these do not force the instance to perform log switches.

The SQL statement ALTER SYSTEM SWITCH LOGFILE forces the current instance to begin writing to a new redo log file, regardless of whether the current redo log file is full.

Forcing a log switch also forces a checkpoint. Oracle returns control to you immediately after beginning the log switch, rather than waiting until the checkpoint is finished.

To force all instances to perform log switches, known as a global log switch, use the SQL statement ALTER SYSTEM ARCHIVE LOG CURRENT omitting the THREAD keyword. After you issue this statement, Oracle waits until all online redo log files are archived before returning control to you. Use this statement to force a single instance to perform a log switch and archive its online redo log files by specifying the THREAD keyword.

In Server Manager, you can use the Instance Force Log Switch option for the current instance only. There is no global option for forcing a log switch in Server Manager. You may want to force a log switch so that you can archive, drop, or rename the current redo log file.

Note: You need the ALTER SYSTEM privilege to force a log switch.

See Also: "Redo Log Files" [*] for more information about threads.

Forcing a Log Switch on a Closed Thread

You can force a closed thread to complete a log switch while the database is open. This is useful if you want to drop the current log of the thread. This procedure does not work on an open thread (including the current thread), even if the instance that had the thread open is shut down. For example, if an instance aborted while the thread was open, you could not force the thread's log to switch.

To force a log switch on a closed thread, manually archive the thread, using the Begin Manual Archive dialog box of Server Manager or the SQL command ALTER SYSTEM with the ARCHIVE LOG option. For example:


To archive a closed redo log group manually that will force it to log switch, you must connect with SYSOPER or SYSDBA privileges.

See Also: Oracle7 Server Administrator's Guide for information on connecting with SYSDBA or SYSOPER privileges.

Backing Up the Database

This section explains how to perform backup operations in an OPS environment. It covers the following topics:

Online and Offline Backups

All backup operations can be performed from any node of a parallel server.

Online backups allow you to back up all or part of the database while it is running. Users can access the database and update data in any part of the database during an online backup. With a parallel server you can make online backups of multiple tablespaces simultaneously from different nodes.

An online backup includes copies of one or more datafiles and the current control file. Subsequent archived redo log files are also necessary to allow recovery up to the time of a media failure.

Offline backups are taken while the database is shut down. Before you make an offline backup, you must therefore shut down all instances of a parallel server. While the database is offline, you can back up its files in parallel from different nodes. An offline backup includes copies of all datafiles and the current control file.

If you archive redo log files, an offline backup allows recovery up to the time of a media failure. In NOARCHIVELOG mode, full recovery is not possible since an offline backup only allows restoration of the database to the point in time of the backup.

Warning: If the control file does not contain the name of a datafile and you have no backup of that datafile, you cannot recover the file if it is lost. Do not use operating-system utilities to back up the control file in ARCHIVELOG mode, unless you are performing a full, offline backup. Never erase, reuse, or destroy archived redo log files until you have done another full backup (preferably two full backups), either online or offline.

See Also: "Backing Up a Database" in the Oracle7 Server Administrator's Guide.

"Database Backup" and "Database Recovery" in Oracle7 Server Concepts.

Beginning and Ending Online Backups

You begin an online backup of a tablespace at one instance and can end the backup at the same instance or another instance. For example:

ALTER TABLESPACE tablespace BEGIN BACKUP;		/* Instance X */
Statement processed.

....operating system commands to copy datafiles...
....copy completed...

ALTER TABLESPACE tablespace END BACKUP;		/* Instance Y */
Statement processed.

Warning: If the ALTER TABLESPACE ... BEGIN BACKUP command is not issued or does not complete before an operating system backup of the tablespace is started, then the backed up datafiles are not useful for subsequent recovery operations. Attempting to recover such a backup is risky and can cause errors that result in inconsistent data.

It does not matter which instance issues each of these statements, but they must be issued whenever you make an online backup. The BEGIN BACKUP option has no effect on users' access to the tablespace.

For an online backup to be usable for complete or incomplete media recovery, you must retain all archived redo logs spanning the period of time between the execution of the BEGIN BACKUP command and the recovery end-point.

After making an online backup, you can force a global log switch by using ALTER SYSTEM ARCHIVE LOG CURRENT. This statement archives all online redo log files that need to be archived, including the current online redo log files of all enabled threads and closed threads of any instance that shut down without archiving its current redo log file.

See Also: Oracle7 Server SQL Reference for a description of the BEGIN BACKUP and END BACKUP clauses of the ALTER TABLESPACE command.

Performing an Online Backup

The following steps are recommended when performing an online backup in a parallel server environment.

To Perform an Online Backup in OPS

Go to previous file in sequence Go to next file in sequence
Prev Next
Copyright © 1996 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index