|Oracle7 Parallel Server Concepts and Administrator's Guide||
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:
Note that archiving is a per-instance operation which can be handled in one of two ways:
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.
All online redo log files that are full but have not been archived.
The lowest system change number (SCN) in the online redo log file.
The current redo log of every enabled thread.
The group number of an online redo log.
The filename of an online redo log file in the thread.
The next full redo log file that needs to be archived.
The log sequence number of an online redo log file.
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.
LOG_ARCHIVE_FORMAT can have the following variables:
|%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|
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:
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.
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. 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.
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.
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.
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.
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.
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.
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.
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.
To Perform an Online Backup in OPS
Copyright © 1996 Oracle Corporation.
All Rights Reserved.