Oracle9i Real Application Clusters Administration Release 1 (9.0.1) Part Number A89869-02 |
|
This chapter discusses creating backups in Real Application Clusters environments. The topics in this chapter are:
See Also:
To protect your data, you should archive the online redo log files and periodically back up the data files.
You can use two methods for backups:
Part of this chapter describes how to use Recovery Manager for backups in Real Application Clusters. For information about using operating system utilities, refer to the Oracle9i Recovery Manager User's Guide.
See Also:
Oracle Enterprise Manager Administrator's Guide for information about using the Oracle Enterprise Manager Backup Wizard |
There are two types of backups:
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 Recovery Manager (RMAN).
An open backup includes copies of one or more data files and the current control file. 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. Subsequent archived redo log files or incremental backups are also necessary to allow recovery up to the time of a media failure.
Depending on your configuration, you can perform backup operations from any node of a Real Application Clusters database. With Real Application Clusters, you can also make open backups of multiple tablespaces simultaneously from different nodes.
When using operating system utilities for closed backups, the backups are done while the database is closed. When you use RMAN for closed backups, an instance must be started and mounted but not open.
Before performing a closed backup, shut down all instances of your Real Application Clusters database. Then start up mount one instance. While the database is closed, you can back up its files in parallel from different nodes (to back up from multiple nodes concurrently, an instance must be started, and mounted, on each node). A closed, whole database backup includes copies of all data files and the current control file.
In ARCHIVELOG mode, both open and closed backups are permitted. In addition, in the event of media failure, you can recover all transactions that were successfully committed to the database. In NOARCHIVELOG mode, however, only whole, closed backups are permitted. Also in NOARCHIVELOG mode, in the event of media failure you can only recover transactions that were committed to the database prior to the time that it was last shut down for backup.
Never erase, reuse, or destroy archived redo log files until completing at least one or preferably multiple backups after the archivelogs were created. You can execute these backups in either open or closed mode.
Online backups in Real Application Clusters are efficient because they do not use the cache. Because backups primarily use I/O resources, you can use the less busy instances for other purposes. 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 explains how to archive the redo log files for each instance:
To enable archive logging in Real Application Clusters environments, the database must be mounted but not open. Then start Real Application Clusters in a disabled state. To do this:
CLUSTER_DATABASE
parameter to false
on one instance. If you are using the server parameter file, make a sid-specific entry for this.
LOG_ARCHIVE_DEST
_n, LOG_ARCHIVE_FORMAT
, and LOG_ARCHIVE_START
parameters to the parameter file. You can multiplex the destination to up to ten locations, and the LOG_ARCHIVE_FORMAT
parameter should contain the %t parameter to include the thread number in the archived log file name.
CLUSTER_DATABASE
to false
.
ALTER DATABASE ARCHIVELOG
CLUSTER_DATABASE
parameter to true
.
To disable archive logging, follow the same steps but use the NOARCHIVELOG
clause of the ALTER DATABASE
statement.
Use the GV$ARCHIVE_PROCESSES
and V$ARCHIVE_PROCESSES
views to find information about the state of the ARCH processes. These views display this information for all database instances, or just the instance you are connected to, respectively.
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 7-1. Examples in Table 7-1 assume that LOG_ARCHIVE_FORMAT= arch%parameter
, and the upper bound for all parameters is 10 characters.
The thread parameters %t
or %T
are mandatory for Real Application Clusters. 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:
|
Archive logs are generally accessible only by the node on which they were created. In Real Application Clusters you have three backup options:
rcp
You can use RMAN to implement the first and second solutions as described in Chapter 6, "Configuring RMAN for Real Application Clusters".
This section discusses the use of checkpoints and log switches in Real Application Clusters environments. The topics in this section are:
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 on the current instance.
A global checkpoint is not finished until all instances complete the checkpoint. 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, change the current instance with the CONNECT
statement.
A Real Application Clusters database 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 from remaining unarchived for an extended period of time. 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 perform forced log switches, it is known as a global log switch. To force all instances to perform a global log switch, 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. Specify the THREAD
keyword to use this statement to force a single instance to perform a log switch and archive its online redo log files.
Use the INSTANCE FORCE LOG SWITCH
clause for each instance. You may want to force a log switch to 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 Oracle9i Database Administrator's Guide for information on connecting with SYSDBA or SYSOPER privileges |
This section describes the following RMAN backup issues:
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 affinity. When deciding which channel to use to back up a particular data file, RMAN gives preference to channels allocated at nodes with affinity to that data file. To use this feature, configure RMAN channels at the various nodes of the cluster that have affinity to the data files being backed up. For example:
CONFIGURE CHANNEL 1 DEVICE TYPE SBT CONNECT '@INST1'; CONFIGURE CHANNEL 2 DEVICE TYPE SBT CONNECT '@INST2';
See Also:
Oracle9i Recovery Manager User's Guide and Reference for more information about the |
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 Real Application Clusters environment. It assumes:
The BACKUP ... PLUS ARCHIVELOG
command switches out of and archives the current online log and backs up archived logs that have not been backed up. Also, At the beginning of a backup of archived logs, RMAN automatically switches out of and archives the current online redo log if needed.
The sample script is as follows:
RUN { ALLOCATE CHANNEL NODE1_T1 TYPE SBT CONNECT 'SYS/KNL@NODE1'; ALLOCATE CHANNEL NODE1_T2 TYPE SBT CONNECT 'SYS/KNL@NODE1'; ALLOCATE CHANNEL NODE2_T3 TYPE SBT CONNECT 'SYS/KNL@NODE2'; ALLOCATE CHANNEL NODE2_T4 TYPE SBT CONNECT 'SYS/KNL@NODE2'; BACKUP FILESPERSET 6 FORMAT 'DF_%T_%S_%P' DATABASE PLUS ARCHIVELOG;
See Also:
Oracle9i Recovery Manager User's Guide and Reference for complete information on open backups using RMAN |
This section contains backup examples using shared directories, some of which use RMAN, for Real Application Clusters. The topics in this section are:
Although you can perform a concurrent backup of more than one node of a cluster using the CONNECT
clause in the ALLOCATE CHANNEL
command, you cannot recover from such a backup unless you have installed Oracle version 8.1.6 or greater.
RMAN stores the local path of the backup file in its recovery catalog. If you allocate multiple channels on recovery, RMAN expects to find the backup file in any of these channels. If RMAN cannot locate the required file in the channel, recovery fails.
Use the SET AUTOLOCATE ON
command to make RMAN search all channels for each backup that is needed for a restore operation.
Do not use the THREAD
statement of the BACKUP ARCHIVED LOG
clause when running RMAN first on one instance and then on the second one. The command syntax for this is:
RMAN TARGET SYS/SYSPASS@DB1 CATALOG RMANUSER/RMANPASS@RMANCAT RUN { ... BACKUP ARCHIVELOG THREAD 1; ... } RMAN TARGET connect /as sys@db2 CATALOG RMANUSER/RMANPASS@RMANCAT { ... BACKUP ARCHIVELOG THREAD 2; ... }
This procedure might not work because it is possible that archivelogs for other threads are archived on different nodes. if node 1, for example, goes down for a longer period of time, the surviving node performs log switches for the inactive instance to maintain the system change number (SCN). The archiver of node 2 also archives the redo logs from DB1 into its log archive destination. This procedure is called a redo log switch.
To create backups by sharing all archive logs with all nodes of a cluster, use NetBios, NFS or HA-NFS. Doing this enables you to execute the backups from any node because every node can read all the logs. In the following example, node 1 backs up all redo logs of all nodes. Make sure that the directories are configured for sharing as described in the previous sections.
The ALTER SYSTEM ARCHIVE LOG CURRENT
statement forces all nodes to back up their current log files.
RUN { ALLOCATE CHANNEL node_1 DEVICE TYPE sbt CONNECT 'sys/sys_pwd@node_1'; ALLOCATE CHANNEL node_2 DEVICE TYPE sbt CONNECT 'sys/sys_pwd@node_2'; BACKUP FILESPERSET 1 (TABLESPACE SYSTEM, rbs, data1, data2 CHANNEL node_1) (TABLESPACE temp, reccat, data3, data4 CHANNEL node_2); BACKUP FILESPERSET 20 ARCHIVELOG ALL DELETE ALL INPUT; }
This section contains examples of making backups using non-shared archive log destinations. The topics in this chapter are:
If you do not share all archive logs, you can back up the logs locally on every node. For recovery, however, you need to have access from the node on which you begin recovery to all the archive logs created by the database. For this reason Oracle Corporation recommends using a media management system that supports archiving over the network or shared directory services to simplify restoring log files.
To do this, adapt the expression in the LIKE
clause to your own configuration, for example, J:%
if you use Windows NT and Windows 2000.
You can back up all the archive logs from one node into one backup instead of archiving them from each node separately. This makes it easier to find all backups when you recover. If you do not use shared directories to back up and restore archive logs, copy or move them using operating system tools, while retaining their exact names. You can easily create scripts to do this before backing up or restoring the logs. If you are using Oracle Enterprise Manager, you can schedule the execution of this script before the backup.
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/901/admin/db/arch2/*' /u01/app/oracle/ product/901/admin/db/arch2
Ensure that you have adequate space on your destination device before executing this script.
If you moved all archive logs to one node to back them up, recovery is as easy as recovery using shared directories. You do not need to use autolocate to restore archivelog backups if they were all backed up from one node, and if you are restoring from that same node.
If you backed the archive logs from each node using a media management system, you can use several channels for recovery. RMAN examines every channel for the required file if RMAN does not find it in the first one. This is the autolocate feature that recovers a database using the local tape drive on the remote nodes as shown in the following example:
RMAN TARGET sys/syspass CATALOG rmanuser/rmanpass@rmancat RUN { ALLOCATE CHANNEL t1 DEVICE TYPE sbt PARMS 'ENV=(NSR_CLIENT=node1)'; ALLOCATE CHANNEL t2 DEVICE TYPE sbt PARMS 'ENV=(NSR_CLIENT=node2)'; SET AUTOLOCATE ON; RECOVER TABLESPACE users; SQL 'alter tablespace users online'; }
If you backed up the logs from each node, restore all the log files from remote nodes before performing recovery. Perform recovery in three steps:
Restore the files locally and move them to the recovering node. Because you have to restore the archive logs before RMAN can begin recovery, specify which log files to restore as in the following example:
RMAN TARGET sys/syspass@node1 catalog rmanuser/rmanpass@rmancat RUN { ALLOCATE CHANNEL t1 TYPE 'sbt_tape'; RESTORE TABLESPACE users; RELEASE CHANNEL t1; } RUN { ALLOCATE CHANNEL t1 TYPE 'sbt_tape' PARMS 'ENV=(NSR_CLIENT=node2)'; # this next line is optional, they will be restored to the first log_archive dest at the restoring node SET ARCHIVELOG DESTINATION TO '/u01/app/oracle/product/901/admin/db/arch2'; RESTORE ARCHIVELOG # this next 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')" # the like operand should be used as each archive dest may contain copies from each thread # (this is due to redo log switches) LIKE '%/2_%'; RELEASE CHANNEL t1; } RUN { ALLOCATE CHANNEL d1 TYPE DISK; RECOVER TABLESPACE users; SQL 'alter tablespace users online'; }
|
Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|