Oracle8i Parallel Server Administration, Deployment, and Performance
Release 2 (8.1.6)

Part Number A76970-01

Library

Product

Contents

Index

Go to previous page Go to next page

13
Backing Up Your Database

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:

 

Choosing a Backup Method

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.  

Archiving the Redo Log Files

This section explains how to archive the redo log files for each instance of Oracle Parallel Server:

Archiving Mode

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.


Note:

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

  • Each instance on Oracle Parallel Server can archive its own redo log files

  • Alternatively, one or more instances can archive the redo log files manually for all instances, as described in the following section

 

See Also:

"Open and Closed Database Backups".  

Changing the Archiving Mode

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:

  1. Shut down all instances.

  2. Reset the parameter PARALLEL_SERVER to FALSE on one instance.

  3. Start up the instance on which you have set PARALLEL_SERVER to FALSE.

  4. Enter the following statement:

    ALTER DATABASE ARCHIVELOG
    
    
    
  5. Shut down the instance.

  6. Change the value of the PARALLEL_SERVER parameter to TRUE.

  7. Restart your instances.

To disable archive logging, follow the same steps but use the NOARCHIVELOG clause of the ALTER DATABASE statement.

Automatic or Manual Archiving

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.

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 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.

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 issuing the archiving command; it is not performed by the instance's ARCH process.

ALTER SYSTEM ARCHIVE LOG Clauses for Manual Archiving

ALTER SYSTEM ARCHIVE LOG manual archiving clauses include:

ALL  

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

CHANGE 

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

CURRENT 

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 

NEXT 

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 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:

 

Monitoring the Archiving Process

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.

See Also:

Oracle8i Reference for more information about these views.  

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 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.

Table 13-1 Archived Redo Log Filename Format Parameters
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 

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 
... 


Note:

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


See Also:

  • Oracle8i Administrator's Guide for information about specifying the archived redo log filename format and destination.

  • Oracle system-specific documentation for information about the default log archive format and destination.

 

Redo Log History in the Control File

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:

 

Backing Up the Archive Logs

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.

Backing Up Archive Logs with RMAN

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.


Note:

Oracle recommends using the LIKE clause instead of THREAD so that one instance can archive logs on behalf on another thread when the other thread is down. As well, the archive log destinations of the various instances must be different so that LIKE can distinguish them from one another.  


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;
         }

Restoring Archive Logs with RMAN

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:

  1. Restore the datafiles.

  2. Restore the archive logs.

  3. Begin recovery.

    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';
             }
    
    


    Note:

    In the recover step, there is an 'sbt_tape' channel allocated so that the archivelogs generated on node 1 will be automatically restored.  


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;
         }

Checkpoints and Log Switches

This section discusses:

Checkpoints

Oracle performs checkpointing automatically on a consistent basis. Checkpointing requires that Oracle write all dirty buffers to disk and advance the checkpoint.

See Also:

Oracle8i Designing and Tuning for Performance for more information about checkpoints.  

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 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.


Note:

You need the ALTER SYSTEM privilege to force a checkpoint.  


See Also:

"Setting and Connecting to 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. 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.


Note:

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


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 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.  

Backing Up the Database

This section describes backup operation issues in Oracle Parallel Server. It covers the following topics:

Open and Closed Database Backups

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.


Warning:

Do not use operating-system utilities to back up the control file in ARCHIVELOG mode unless you are performing a closed, whole 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.

See Also:

 

Online Backups and Oracle Parallel Server

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.


Note:

Using the ALTER TABLESPACE ... BEGIN BACKUP statement generates extra redo logs.  


RMAN Backup Issues

This section describes the following RMAN backup issues:

Preparing for Snapshot Control Files in RMAN

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.

Performing an Open Backup Using RMAN

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. 

Node Affinity Awareness

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.  

Operating System Backup Issues

This section discusses the following operating system backup issues:

Beginning and Ending an Open Backup Using Operating System Utilities

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.


Note:

If you do not issue the ALTER TABLESPACE ... BEGIN BACKUP statement, or if processing does not complete before an operating system backup of the tablespace begins, then the backed up data files are not useful for subsequent recovery operations. Attempting to recover such a backup is risky and can cause errors resulting 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 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.  

Performing an Open Backup Using Operating System Utilities

The following steps are recommended if you are using operating system utilities to perform an open backup in Oracle Parallel Server.

  1. Before starting the open backup, issue the ALTER SYSTEM ARCHIVE LOG CURRENT statement.

    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.

  2. Issue the ALTER TABLESPACE tablespace BEGIN BACKUP statement.

  3. Wait for the ALTER TABLESPACE statement to successfully complete.

  4. In the operating-system environment, issue the appropriate statements to back up the data files for the tablespace.

  5. Wait for the operating-system backup to successfully complete.

  6. Issue the ALTER TABLESPACE tablespace END BACKUP statement.

  7. Back up the control files with ALTER DATABASE BACKUP CONTROLFILE TO filename.

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.


Go to previous page Go to next page
Oracle
Copyright © 1996-2000, Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index