Release 2 (8.1.6)
Part Number A76970-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Parallel Server Administration, Deployment, and Performance Release 2 (8.1.6) Part Number A76970-01 |
|
To protect your data, archive the online redo log files and periodically back up the data files. 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 the following topics:
Oracle Parallel Server supports all Oracle backup features in exclusive mode, including both open and closed backup of either an entire database or individual tablespaces.
|
See Also:
|
You can perform backup and recovery operations using two methods:
The information provided in this chapter is useful for both methods, unless specified otherwise.
|
See Also:
Oracle Enterprise Manager Administrator's Guide about using Oracle Enterprise Manager's Backup Wizard. |
To avoid confusion between online and offline data files and tablespaces, this chapter 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 data files and control files have been backed up. "Full" and "incremental" backups refer only to particular types of backups provided by RMAN.
|
See Also:
Oracle8i Recovery Manager User's Guide and Reference for a complete discussion of backup and recovery operations and terminology related to RMAN. |
This section explains how to archive the redo log files for each instance of Oracle Parallel Server:
Oracle provides two archiving modes: ARCHIVELOG mode and NOARCHIVELOG mode. 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 failure. In ARCHIVELOG mode, you can produce both open and closed backups. In NOARCHIVELOG mode, you can make only closed backups.
Determine whether to use archive logging which preserves groups of online redo log files. Without archive logging, Oracle overwrites redo log files once they are available for reuse.
The choice of whether to enable the archiving of filled online redo log files depends on your application's availability and reliability requirements. If you cannot afford to lose any data in the event of a disk failure, use ARCHIVELOG mode. Note that archiving filled online redo log files can require extra administrative operations.
|
See Also:
Oracle8i Parallel Server Setup and Configuration Guide for information on how to configure archive logs in Oracle Parallel Server. |
To enable archive logging in Oracle Parallel Server environments, the database must be mounted but not open. Then start Parallel Server in a disabled state. To do this:
ALTER DATABASE ARCHIVELOG
To disable archive logging, follow the same steps but use the NOARCHIVELOG clause of the ALTER DATABASE statement.
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 Oracle Parallel Server instance. For example, you can manually use SQL statements 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 clauses include:
You can use the THREAD clause of ALTER SYSTEM ARCHIVE LOG to archive redo log files in a thread associated with an instance other than the current instance.
|
See Also:
|
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 13-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 Oracle Parallel Server. 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:
|
You can use the MAXLOGHISTORY clause of the CREATE DATABASE or CREATE CONTROLFILE statement to make the control file retain a history of redo log files that an instance has filled. After creating the database, you can only increase or decrease the log history by creating new control files. Using CREATE CONTROLFILE destroys all log history in the current control file.
The MAXLOGHISTORY clause 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, SQL*Plus prompts you for the appropriate file names. RMAN 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. 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:
|
Archive logs are generally accessible only by the node on which they were created. In Oracle Parallel Server you have three backup options:
You can use RMAN to implement the first and second solutions and operating system utilities to implement the third.
If you share all archive logs with all nodes of a cluster, backup is very easy and can be executed from any node because every node can read all the logs. In the example below, node 1 backs up all redo logs of all nodes. Make sure that the directories are configured for sharing as described in the Oracle8i Parallel Server Setup and Configuration Guide.
rman TARGET INTERNAL/sys@node1 catalog rman/rman@rman RUN { ALLOCATE CHANNEL t1 type 'sbt_tape' FORMAT 'al_t%t_s%s_p%p'; SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; BACKUP ARCHIVELOG ALL DELETE INPUT; RELEASE CHANNEL t1; }
With the ALTER SYSTEM ARCHIVE LOG CURRENT statement, you force all nodes to back up their current log files.
If you do not share all archive logs, you can back up the logs locally on every node. In case of recovery, however, you need to have access from the node on which you begin recovery to all the archive logs on all nodes. For this reason Oracle recommends using a media management system that supports archiving over the network or shared directory services to simplify restoring log files. The following RMAN script starts the local backup of all nodes using the CONNECT and LIKE clauses.
rman TARGET internal/sys@node1 catalog rman/rman@rman RUN { ALLOCATE CHANNEL t1 TYPE 'sbt_tape' FORMAT 'al_n1_t%t_s%s_p%p' CONNECT internal/sys@node1; SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; BACKUP ARCHIVELOG LIKE '%/arch1/%' delete input; RELEASE CHANNEL t1; } RUN { ALLOCATE CHANNEL t1 TYPE 'sbt_tape' FORMAT 'al_n2_t%t_s%s_p%p' CONNECT internal/sys@node2; BACKUP ARCHIVELOG LIKE '%/arch2/%' DELETE INPUT; RELEASE CHANNEL t1; } RUN { ALLOCATE CHANNEL t1 TYPE 'sbt_tape' FORMAT 'al_n3_t%t_s%s_p%p' CONNECT internal/sys@node3; BACKUP ARCHIVELOG LIKE '%/arch3/%' DELETE INPUT; RELEASE CHANNEL t1; }
Back up all the archive logs from one node into one backup archive instead of archiving them from each node separately. This makes it easier to find all backups during recovery. If you do not use shared directories to back up and restore archive logs, copy or move them using operating system tools. You can easily create scripts to do this job before backing up or restoring the logs.
To copy all archive logs to the local directories on node 1 use a script similar to the following:
#!/bin/sh sqlplus system/manager@node1 @switchlog.sql rcp node2:/u01/app/oracle/product/815/admin/ops/arch2/* /u01/app/oracle/product/815/admin/ops/arch2 rcp node3:/u01/app/oracle/product/815/admin/ops/arch3/* /u01/app/oracle/product/815/admin/ops/arch3
The switchlog.sql script is used to make sure to get all necessary log files for recovery. It looks like this:
#!/bin/sh ALTER SYSTEM ARCHIVE LOG CURRENT; EXIT
To back up the archived logs from node 1 using RMAN, the command is similar to the example except that the ALTER SYSTEM ARCHIVE LOG CURRENT statement is executed from the shell script:
rman TARGET internal/sys@node1 catalog rman/rman@rman RUN { ALLOCATE CHANNEL t1 TYPE 'sbt_tape' FORMAT 'al_t%t_s%s_p%p'; BACKUP ARCHIVELOG ALL DELETE INPUT; RELEASE CHANNEL t1; }
If RMAN has concurrent access to all backups, it automatically restores all necessary archive logs from previous backups for recovery. In Oracle Parallel Server environments, the restore procedure varies depending on the option you used to back up the archive logs.
If you share archive log directories, you can change the destination of the automatic restoration of archive logs with the SET clause to restore the files to a local directory of the node from where you begin recovery.
To restore the USERS tablespace from node 1, use an RMAN command syntax similar to the following:
rman TARGET internal/sys@node1 catalog rman/rman@rman run { allocate channel t1 type 'sbt_tape'; set archivelog destination to '/u01/app/oracle/product/815/admin/ops/arch1'; recover tablespace users; sql 'alter tablespace users online'; release channel t1; }
If you backed up each node's log files using a central media management system, you can use the RMAN AUTOLOCATE option of the SET command. If you use several channels for recovery, RMAN asks every channel for the required file if it does not find it in the first one. This feature allows you to recover a database using the local tape drive on the remote node:
rman TARGET internal/sys catalog rman/rman@rman RUN { ALLOCATE CHANNEL t1 type 'sbt_tape' parms 'ENV=(NSR_CLIENT=node1)'; ALLOCATE CHANNEL t2 type 'sbt_tape' parms 'ENV=(NSR_CLIENT=node2)'; ALLOCATE CHANNEL t3 type 'sbt_tape' parms 'ENV=(NSR_CLIENT=node3)'; SET AUTOLOCATE ON; RECOVER TABLESPACE users; SQL 'ALTER TABLESPACE users ONLINE'; RELEASE CHANNEL t1;}
If you backed up the logs from each node without using a central media management system, you must first restore all the log files from the remote nodes and move them to the host from which you will start recovery. This means you must perform recovery in three steps:
rman target internal/sys catalog rman/rman@rman RUN { ALLOCATE CHANNEL t1 TYPE 'sbt_tape' connect internal/sys@node1; RESTORE TABLESPACE users; RELEASE CHANNEL t1; } RUN { ALLOCATE CHANNEL t1 TYPE 'sbt_tape' connect internal/sys@node2; RESTORE ARCHIVELOG # this line is optional if you don't want to restore ALL archive logs: FROM TIME "to_date('05.09.1999 00:00:00','DD.MM.YYYY HH24:Mi:SS')" LIKE '%/2_%'; RELEASE CHANNEL t1; } RUN { ALLOCATE CHANNEL t1 TYPE 'sbt_tape' connect internal/sys@node3; RESTORE ARCHIVELOG # this line is optional if you don't want to restore ALL archive logs: FROM TIME "to_date('05.09.1999 00:00:00','DD.MM.YYYY HH24:Mi:SS')" like '%/3_%'; RELEASE CHANNEL t1; } EXIT rcp node2:/u01/app/oracle/product/815/admin/ops/arch2 /u01/app/oracle/product/815/admin/ops/arch2 rcp node3:/u01/app/oracle/product/815/admin/ops/arch2 /u01/app/oracle/product/815/admin/ops/arch2 rman TARGET internal/sys catalog rman/rman@rman RUN { ALLOCATE CHANNEL t1 TYPE 'sbt_tape'; ALLOCATE CHANNEL d1 type disk; RECOVER TABLESPACE users; SQL 'ALTER TABLESPACE USERS ONLINE'; }
If you moved all archive logs to one node to back them up, recovery is as easy as recovery using shared directories. To make sure you have all the log files, copy all remote log files with your shell script as in this example:
/rcp_all_logs.sh rman TARGET internal/sys@node1 catalog rman/rman@rman RUN { ALLOCATE CHANNEL t1 type 'sbt_tape' format 'al_t%t_s%s_p%p'; BACKUP ARCHIVELOG ALL DELETE INPUT; RELEASE CHANNEL t1; }
This section discusses:
Oracle performs checkpointing automatically on a consistent basis. Checkpointing requires that Oracle write all dirty buffers to disk and advance the 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 data files on disk.
The GLOBAL clause 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 requiring 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 CONNECT statement.
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. This can be done 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 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.
When all instances to perform forced log switches, it is known as a "global log switch." To do this, use the SQL statement ALTER SYSTEM ARCHIVE LOG CURRENT omitting 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.
Use the INSTANCE FORCE LOG SWITCH clause for each instance; there is no global option for forcing a log switch. 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 SQL statement ALTER SYSTEM with the ARCHIVE LOG clause. 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 describes backup operation issues in Oracle Parallel Server. It covers the following topics:
You can perform all backup operations from any node of an Oracle Parallel Server. Open backups allow you to back up all or part of the database while it is running. Users can update data in any part of the database during an open backup. With Oracle Parallel Server you can make open backups of multiple tablespaces simultaneously from different nodes. An open backup includes copies of one or more data files 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 you use the operating system, closed backups are done while the database is closed. When you use RMAN, an instance must be started and mounted, but not open, to perform closed backups. Before making a closed backup, shut down all instances of your Oracle 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 data files 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.
Never erase, reuse, or destroy archived redo log files until completing another whole backup, or preferably two whole backups, in either open or closed mode.
Online backups in Oracle Parallel Server are efficient because they do not use the cache. This means you can run online backups from a single instance in the cluster and not experience pinging.
Because backups use primarily CPU resources, so you can make use of the less busy instances. However, you should monitor disk usage to ensure that the I/O is not being saturated by the backup. If the I/O is saturated by the backup, it may adversely affect the online users.
This section describes the following RMAN backup issues:
In Oracle Parallel Server, you must prepare for snapshot control files before performing backups using RMAN.
Any node making a backup may need to create a snapshot control file. Therefore, on all nodes used for backup, ensure the existence of the destination directory for such a snapshot control file.
For example, to specify that the snapshot control file should be written to the file /oracle/db_files/snapshot/snap_prod.cf, 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 data files in Oracle Parallel Server will be shared across all nodes in the cluster.
If you are also backing up archive logs, then issue an ALTER SYSTEM ARCHIVE LOG CURRENT statement after the backup is complete. This ensures that you have all redo data to make the files in your backup consistent.
The following sample script distributes data file 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);
|
See Also :
Oracle8i Recovery Manager User's Guide and Reference for complete information on open backups using RMAN. |
On some cluster platforms, certain nodes of the cluster have faster access to some data files than to other data files. RMAN automatically detects this type of affinity. When deciding which channel will back up a particular data file, RMAN gives preference to channels allocated at nodes with affinity to that data file. To use this feature, allocate RMAN channels at the various nodes of the cluster that have affinity to the data files being backed up.
For example:
RUN { ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE' CONNECT '@INST1'; ALLOCATE CHANNEL CH2 TYPE 'SBT_TAPE' CONNECT '@INST2'; ... }
|
See Also:
Oracle8i Backup and Recovery Guide for more information about the CONNECT clause of the ALLOCATE statement. |
This section discusses the following operating system 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 data files... ....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 clause has no effect on user access to tablespaces.
For an open backup to be usable for complete or incomplete media recovery, retain all archived redo logs spanning the period of time between the execution of the BEGIN BACKUP statement 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:
Oracle8i SQL Reference for a description of the BEGIN BACKUP and END BACKUP clauses of the ALTER TABLESPACE statement. |
The following steps are recommended if you are using operating system utilities to perform an open backup in Oracle Parallel Server.
This switches and archives the current redo log file for all threads in your Oracle Parallel Server environment, including threads that are not currently up.
For added safety, back up the control file to a trace file with the ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS statement, 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 back to the "end backup" marker.
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|