Release 8.0
A58238-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8 Parallel Server Concepts & Administration Release 8.0 A58238-01 |
|
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 open and closed backup of either an entire database or individual tablespaces.
In Oracle8 you can perform backup and recovery operations using two different methods:
The information provided in this chapter is true for both methods, unless specified otherwise.
Note: To avoid confusion between online and offline datafiles and tablespaces, this documentation uses the terms "open" and "closed" to indicate whether a database is available or unavailable during a backup. The term "whole backup" or "database backup" indicates that all datafiles and control files have been backed up. "Full" and "incremental" backups refer only to particular types of backup provided by Recovery Manager.
See Also: Oracle8 Backup and Recovery Guide for a complete discussion of backup and recovery operations and terminology.
This section explains how to archive the redo log files for each instance of a parallel server:
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 open and closed backups. In NOARCHIVELOG mode, you can only make closed backups.
Note that archiving is a per-instance operation which can be handled in one of two ways:
See Also: "Open and Closed Database Backups" on page 21-12.
Archiving can be performed automatically or manually for a given instance, depending on the value you set for the LOG_ARCHIVE_START initialization parameter.
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.
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.
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 manual archiving options include:
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.
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. (Table 21-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:
LOG_1_T7.ARC LOG_2_T7.ARC LOG_3_T7.ARC ...
Note: Always specify thread and sequence number in archive log file format for easy identification of the redo log 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 increase or decrease 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. Recovery Manager automatically restores the redo logs it requires. 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 view. When you are using Server Manager, V$RECOVERY_LOG also displays information about archived logs needed to complete media recovery; this 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.
"Restoring and Recovering Redo Log Files" on page 22-18 for Server Manager prompts during recovery.
Archive logs are generally only accessible by the node on which they were created. In a parallel server environment you have two backup options:
Using O/S utilities, you can manually implement either solution.
Recovery Manager can automatically enable each node to back up its own archive logs. However, if you wish to move the logs you must do so manually and then use the appropriate rman catalog and change commands to reflect the movement of files. Once Recovery Manager has been informed of the changes you have made, it can back up archive logs from the single node.
If you are using multiple nodes to back up your archive logs, note that when Recovery Manager compiles the list of logs to be archived, it must be able to check that the archived logs exist. To do this it must be able to read the headers of all archived logs on all nodes.
Each node can then back up the archived logs it has created. In the example below, because the initial target database is node 1 (on the rman command line), you must ensure that node 1 is able to read the headers of the archived logs (even those produced by node 2).
rman target internal/knl@node1 rcvcat rman/rman@rcat run { allocate channel t1 type 'SBT_TAPE' connect 'internal/knl@node1'; allocate channel t2 type 'SBT_TAPE' connect 'internal/knl@node2'; backup filesperset 10 format 'al_%t_%s_%p' (archivelog until time 'SYSDATE' thread 1 delete input channel t1) (archivelog until time 'SYSDATE' thread 2 delete input channel t2); }
By default, rman will restore archive logs to the log_archive_dest of the instances it connects to. If you are using multiple nodes to restore and recover, this means the archive logs may be restored to any of the nodes doing the restore/recover. The node which will actually read the restored logs and perform the roll-forward is the target node initially connected to. For recovery to use these logs, you must ensure that the logs are readable from that node.
This section discusses:
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 instance 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.
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 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.
An instance performs a checkpoint under any of the following circumstances:
See Also: "Forcing a Log Switch" on page 21-10.
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.
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" on page 18-16 for information on specifying a remote node.
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 initialization parameters LOG_CHECKPOINT_TIMEOUT and LOG_CHECKPOINT_INTERVAL 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" on page 6-3 for more information about threads.
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:
ALTER SYSTEM ARCHIVE LOG GROUP 2;
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: Oracle8 Administrator's Guide for information on connecting with SYSDBA or SYSOPER privileges.
This section covers backup operation issues in an Oracle Parallel Server environment. It covers the following topics:
All backup operations can be performed from any node of a parallel server. Open 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 open backup. With a parallel server you can make open backups of multiple tablespaces simultaneously from different nodes. An open backup includes copies of one or more datafiles and the current control file. Subsequent archived redo log files or incremental backups are also necessary to allow recovery up to the time of a media failure.
When using the operating system, closed backups are taken while the database is closed. When using Recovery Manager, an instance must be started and mounted, but not open, in order to do a closed backup. Before you make a closed backup, you must therefore shut down all instances of a parallel server. While the database is closed, you can back up its files in parallel from different nodes. A closed whole database backup includes copies of all datafiles and the current control file.
If you archive redo log files, a closed backup allows recovery up to the time of a media failure. In NOARCHIVELOG mode, full recovery is not possible since a closed backup only allows restoration of the database to the point in time of the backup.
Warning: Do not use operating-system utilities to back up the control file in ARCHIVELOG mode, unless you are performing a whole, closed backup.
Never erase, reuse, or destroy archived redo log files until you have done another whole backup (preferably two whole backups), either open or closed.
See Also: Oracle8 Backup and Recovery Guide.
"Database Backup" and "Database Recovery" in Oracle8 Concepts.
In an Oracle Parallel Server environment, you must prepare for snapshot control files before you perform a backup using Recovery Manager.
Any node making a backup may need to create a snapshot control file. Therefore, on all nodes used for backup, you must ensure the existence of the directory to which such a snapshot control file will be written.
For example, to specify that the snapshot control file should be written to the file
/oracle/db_files/snapshot/snap_prod.cf, you would enter:
SET SNAPSHOT CONTROLFILE TO '/oracle/db_files/snapshot/snap_prod.cf';
You must then ensure that the directory /oracle/db_files/snapshot exists on all nodes from which you perform backups.
It is also possible to specify a raw device destination for a snapshot control file, which like other datafiles in an OPS environment will be shared across all nodes in the cluster.
See the Oracle8 Backup and Recovery Guide for complete information on open backups using Recovery Manager.
If you are also backing up archive logs, then issue an ALTER SYSTEM ARCHIVE LOG CURRENT statement after the backup has completed. This ensures that you have all redo to make the files in this backup consistent.
The following sample script distributes datafile and archive log backups across two instances in a parallel server environment. It assumes:
The sample script is as follows:
run { allocate channel node1_t1 type 'SBT_TAPE' connect 'internal/knl@node1'; allocate channel node1_t2 type 'SBT_TAPE' connect 'internal/knl@node1'; allocate channel node2_t3 type 'SBT_TAPE' connect 'internal/knl@node2'; allocate channel node2_t4 type 'SBT_TAPE' connect 'internal/knl@node2'; backup filesperset 6 format 'df_%t_%s_%p' (database); sql 'alter system archive log current'; backup filesperset 10 format 'al_%t_%s_%p' (archivelog until time 'SYSDATE' thread 1 delete input channel node1_t1) (archivelog until time 'SYSDATE' thread 2 delete input channel node2_t3); }
When using the operating system method, you begin an open 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 open backup. The BEGIN BACKUP option has no effect on users' access to the tablespace.
For an open 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 open 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: Oracle8 SQL Reference for a description of the BEGIN BACKUP and END BACKUP clauses of the ALTER TABLESPACE command.
The following steps are recommended if you are using operating system utilities to perform an open backup in a parallel server environment.
This switches and archives the current redo log file for all threads in a parallel server environment, even those threads that are not currently up.
For an added measure of safety, back up the control file to a trace file with the ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS command, then identify and back up that trace file.
If you are also backing up archive logs, then issue an ALTER SYSTEM ARCHIVE LOG CURRENT statement after END BACKUP. This ensures that you have all redo to roll to the end backup marker.
