Oracle7 Parallel Server Concepts and Administrator's Guide

Library

Product

Contents

Index

Backing Up the Database

• Archiving the Redo Log Files
• Checkpoints and Log Switches
• Backing Up the Database

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:

• Archiving the Redo Log Files

• Checkpoints and Log Switches

• Backing Up the Database

Archiving the Redo Log Files

• Archiving Mode

• Automatic or Manual Archiving

• Archive File Format and Destination

• Redo Log History in the Control File

Archiving Mode

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

• Each instance on a 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.

Automatic or Manual Archiving

• With LOG_ARCHIVE_START set to TRUE, Oracle automatically archives redo logs as they fill.

• With LOG_ARCHIVE_START set to FALSE, Oracle waits until you instruct it to archive.

Automatic 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

• using the ARCHIVE LOG clause of the ALTER SYSTEM command (in SQL)

• using the the Archive Log dialog box (in Server Manager)

• enabling automatic archiving (by using the SQL command ALTER SYSTEM ARCHIVE LOG START, or using Server Manager)

ALTER SYSTEM ARCHIVE LOG Options for Manual Archiving

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 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: Oracle7 Server SQL Reference manual for information about the syntax of the ALTER SYSTEM ARCHIVE LOG statement.

"Archiving Redo Information" chapter in Oracle7 Server Administrator's Guide for more information about manual and automatic archiving.

"Recovery Structures" chapter in Oracle7 Server Concepts for more information about manual and automatic archiving.

"Forcing a Log Switch" for more information about threads and log switches.

Archive File Format and Destination

LOG_ARCHIVE_FORMAT can have the following variables:

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

Table 22 - 1. Archived Redo Log Filename Format Parameters

Note: Table 22 - 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.

See Also: Your Oracle system-specific documentation for default log archive format and destination.

"Archiving Redo Information" chapter in Oracle7 Server Administrator's Guide for more information about specifying the archived redo log filename format and destination.

"Recovery Structures" chapter in Oracle7 Server Concepts.

Redo Log History in the 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.

• thread number

• log sequence number

• low system change number (SCN)

• low SCN timestamp

• next SCN (that is, the low SCN of the next log in sequence)

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. 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 dynamic performance table. Additionally, V$RECOVERY_LOG, which also displays information about archived logs needed to complete media recovery, 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.

"Mounting Redo Log Files for Recovery" for Server Manager prompts during recovery.

Checkpoints and Log Switches

• Checkpoints

• Log Switches

• When Checkpoints Occur Automatically

• Forcing a Checkpoint

• Forcing a Log Switch

• Forcing a Log Switch on a Closed Thread

Checkpoints

Because all database changes up to the checkpoint are written to the datafiles, redo log entries before the checkpoint are not needed for 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.

Log Switches

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

When Checkpoints Occur Automatically

• When the number of redo log blocks written by that instance reaches the limit specified by the initialization parameter LOG_CHECKPOINT_INTERVAL.

• At periods specified by the initialization parameter LOG_CHECKPOINT_TIMEOUT.

• At log switch time, which occurs when the instance's current online redo log file is full, when Oracle forces a log switch to archive a redo log file, or when the database administrator forces a log switch by one of the following methods:

• ALTER SYSTEM SWITCH LOGFILE

• The Switch Online Redo Log File dialog box

• ALTER SYSTEM ARCHIVE LOG CURRENT

• When the database administrator issues the ALTER SYSTEM CHECKPOINT statement or uses the Force Checkpoint dialog box.

• When the instance shuts down using the NORMAL or IMMEDIATE option.

• When backup of an online tablespace begins, a partial checkpoint is performed by every instance for the datafiles in that tablespace.

Forcing a Checkpoint

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.

In Server Manager, you can use the Force Checkpoint dialog box to force a global or local checkpoint.

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" for information on specifying a remote node.

Forcing a Log Switch

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 LOG_CHECKPOINT_TIMEOUT and LOG_CHECKPOINT_INTERVAL initialization parameters 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" for more information about threads.

Forcing a Log Switch on a Closed Thread

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: Oracle7 Server Administrator's Guide for information on connecting with SYSDBA or SYSOPER privileges.

Backing Up the Database

• Online and Offline Backups

• Beginning and Ending Online Backups

• Performing an Online Backup

Online and Offline Backups

Online 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 online backup. With a parallel server you can make online backups of multiple tablespaces simultaneously from different nodes.

An online backup includes copies of one or more datafiles and the current control file. Subsequent archived redo log files are also necessary to allow recovery up to the time of a media failure.

Offline backups are taken while the database is shut down. Before you make an offline backup, you must therefore shut down all instances of a parallel server. While the database is offline, you can back up its files in parallel from different nodes. An offline backup includes copies of all datafiles and the current control file.

If you archive redo log files, an offline backup allows recovery up to the time of a media failure. In NOARCHIVELOG mode, full recovery is not possible since an offline backup only allows restoration of the database to the point in time of the backup.

Warning: If the control file does not contain the name of a datafile and you have no backup of that datafile, you cannot recover the file if it is lost. Do not use operating-system utilities to back up the control file in ARCHIVELOG mode, unless you are performing a full, offline backup. Never erase, reuse, or destroy archived redo log files until you have done another full backup (preferably two full backups), either online or offline.

See Also: "Backing Up a Database" in the Oracle7 Server Administrator's Guide.

"Database Backup" and "Database Recovery" in Oracle7 Server Concepts.

Beginning and Ending Online Backups

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 online backup. The BEGIN BACKUP option has no effect on users' access to the tablespace.

For an online 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 online 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: Oracle7 Server SQL Reference for a description of the BEGIN BACKUP and END BACKUP clauses of the ALTER TABLESPACE command.

Performing an Online Backup

1. Before starting the online backup, issue the ALTER SYSTEM ARCHIVE LOG CURRENT command.

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.

2. Issue the ALTER TABLESPACE tablespace BEGIN BACKUP command.

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

4. In the operating-system environment, issue the appropriate commands to back up the datafiles for the tablespace.

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

6. Issue the ALTER TABLESPACE tablespace END BACKUP command.

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

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.

Prev Next

Copyright © 1996 Oracle Corporation. All Rights Reserved.

Library

Product

Contents

Index