Release 8.1.5
A67778-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Parallel Server Concepts and Administration Release 8.1.5 A67778-01 |
|
Thomas Babington, Lord Macaulay: On Frederic The Great
To protect your data, archive the online redo log files and periodically back up the datafiles. Also back up the control file for your database and the parameter files for each instance. This chapter discusses how to devise a strategy for performing these tasks by explaining:
Oracle Parallel Server (OPS) supports all Oracle backup features in exclusive mode, including both open and closed backup of either an entire database or individual tablespaces.
You can perform backup and recovery operations using two methods:
The information provided in this chapter is true for both methods, unless specified otherwise.
|
See Also:
The Oracle8i 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. Oracle can then recover the log files in the event of media failure. In ARCHIVELOG mode, you can produce both open and closed backups. In NOARCHIVELOG mode, you can only make closed backups.
Archiving can be performed automatically or manually for a given instance, depending on the value you set for the LOG_ARCHIVE_START initialization parameter.
You can set LOG_ARCHIVE_START differently for each OPS instance. 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 performing 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 issuing 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.
|
See Also:
"Forcing a Log Switch" regarding threads and log switches. Refer to the Oracle8i Reference for information about the syntax of the ALTER SYSTEM ARCHIVE LOG statement. Also see the Oracle8i Backup and Recovery Guide as well as the "Archiving Redo Information" chapter in the Oracle8i Administrator's Guide for more information about manual and automatic archiving. |
The GV$ARCHIVE_PROCESSES and V$ARCHIVE_PROCESSES views provide information about the state of the various ARCH processes on the database and instance respectively. The GV$ARCHIVE_PROCESSES view displays 10*n rows, where 'n' is the number of open instances for the database. The V$ARCHIVE_PROCESSES view displays 10 rows, 1 row for each possible ARCH process.
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 variables as shown in Table 21-1. Examples in this table assume 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 OPS. 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 ...
|
See Also:
The "Archiving Redo Information" chapter in the Oracle8i Administrator's Guide for information about specifying the archived redo log filename format and destination. Also refer to the "Recovery Structures" chapter in Oracle8i Concepts. Your Oracle system-specific documentation also contains information about the default log archive format and destination. |
You can use the MAXLOGHISTORY clause of the CREATE DATABASE or CREATE CONTROLFILE command to enable the control file to keep a history of 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. 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.
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 redo threads. An Oracle instance accessing the database in exclusive mode with only one thread enabled does not need the log history. However, 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 using Server Manager, V$RECOVERY_LOG also displays information about archived logs needed to complete media recovery. This information is derived from 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:
"Restoring and Recovering Redo Log Files" for Server Manager prompts that appear during recovery. Your Oracle system-specific documentation also has information about the default MAXLOGHISTORY value. |
Archive logs are generally only accessible by the node on which they were created. In OPS you have two backup options:
Use O/S utilities to manually implement either solution.
Optionally, you can set up each node to backup its own logs by running multiple copies of RMAN, one on each node. The new OEM (Oracle Enterprise Manager) architecture allows you to construct a single backup job and have it submitted to multiple nodes at times you specify.
Recovery Manager can automatically enable each node to back up its own archive logs. However, 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, 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 restores archive logs to the log_archive_dest of the instances it connects to. If you are using multiple nodes to restore and recover, the archive logs may be restored to any of the nodes doing the restore/recover. The node actually reading the restored logs and performing the roll-forward is the target node initially connected to. To make recovery use these logs, ensure that the logs are readable from that node.
The CONNECT option of the RMAN ALLOCATE CHANNEL command allows you to allocate channels on any node of an OPS cluster. If you allocate channels on more than one node in the cluster, RMAN automatically distributes backup processing among those nodes.
On AIX and Pyramid Mesh clusters, RMAN also automatically detects disk-to-node affinity and backs up datafiles onto nodes that can most quickly access those datafiles.
Creating backups on multiple OPS nodes requires the following support from your media manager:
This section discusses:
Oracle8i performs checkpointing automatically on a consistent basis. Checkpointing requires that Oracle write all dirty buffers to disk and advance the checkpoint.
|
See Also:
For more information about checkpoints and how to control Oracle's checkpointing process, please refer to Oracle8i Tuning. |
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.
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 its current redo log file can be archived.
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 all instances to perform log switches is known as a global log switch. To do this, use the SQL statement ALTER SYSTEM ARCHIVE LOG CURRENT and omit the THREAD keyword. After issuing 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, 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.
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:
The Oracle8i Administrator's Guide for information on connecting with SYSDBA or SYSOPER privileges. |
This section covers backup operation issues in OPS. 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, to do a closed backup. Before making a closed backup, 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 completing another whole backup, or preferably two whole backups, either open or closed.
|
See Also:
The Oracle8i Backup and Recovery Guide and the chapters "Database Backup" and "Database Recovery" in Oracle8i Concepts. |
In OPS, 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 OPS will be shared across all nodes in the cluster.
See the Oracle8i 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' LIKE 'node1_archivelog_dest%' DELETE INPUT CHANNEL NODE1_T1) (ARCHIVELOG UNTIL TIME 'SYSDATE' LIKE 'node2_archivelog_dest%' DELETE INPUT CHANNEL NODE2_T3);
On some cluster platforms, certain nodes of the cluster have faster access to some datafiles than to other datafiles. RMAN automatically detects such affinity. When deciding which channel will back up a particular datafile, RMAN gives preference to channels allocated at nodes with affinity to that datafile. To use this feature, allocate RMAN channels at the various nodes of the cluster that have affinity to the datafiles being backed up.
For example:
RUN { ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE' CONNECT '@INST1'; ALLOCATE CHANNEL CH2 TYPE 'SBT_TAPE' CONNECT '@INST2'; ... }
|
Note: For more information about the CONNECT operand of the ALLOCATE command, please see the Oracle8i Backup and Recovery Guide. |
This section discusses the following backup issues:
When using the operating system method, you can begin an open backup of a tablespace at one instance and 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.
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:
The Oracle8i 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 OPS.
This switches and archives the current redo log file for all threads in OPS, even 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.
