2
Managing Data Structures

This chapter describes how to manage data structures that are crucial for successful backup and recovery. It includes the following topics:

• Overview of Backup and Recovery Data Structures

• Managing the Control File

• Managing the Online Redo Logs

• Managing the Archived Redo Logs

  See Also: Oracle8i Concepts for a conceptual overview of these data structures Oracle8i Administrator's Guide for detailed administration information Oracle8i Parallel Server Documentation Set: Oracle8i Parallel Server Concepts; Oracle8i Parallel Server Setup and Configuration Guide; Oracle8i Parallel Server Administration, Deployment, and Performance if you are using Oracle with the Parallel Server

Overview of Backup and Recovery Data Structures

The single most useful strategy in backup and recovery is planning ahead. To prevent data loss, you must anticipate the various ways that data can be lost and develop your defense accordingly.

An important aspect of planning ahead is the intelligent management of database data structures. For example, what can you do to prevent a database crash if your control file become corrupted? What can you do to prevent the loss of archived redo logs if a disk failure occurs? Besides the datafiles, the data structures that are most important for developing a backup and recovery strategy are:

• Control files

• Online redo logs

• Archived redo logs (if you run in ARCHIVELOG mode)

If these structures become corrupted or unavailable, then you may find yourself unable to recover lost data.

If you have sufficient resources, then you can help protect yourself from data loss by following this basic data management strategy:

• Mirror datafiles at the operating system or hardware level.

• Maintain at least two current control files on different disks by Oracle multiplexing or operating system mirroring, or both at the same time. Operating system or hardware mirroring ensures that you can recover from any one media failure while the system is fully available.

• Maintain at least three online redo log groups with two members each. Place each member of the group on a different disk and on a different disk controller.

• Archive redo logs to multiple destinations and back them up frequently to different media. It is advisable to take multiple backups to multiple different media devices.

  Note: This chapter assumes that you understand the function of the control file, online redo logs, and archived redo logs as well as the basics of how to administer them. If you do not, refer to the relevant chapters in Oracle8i Concepts and the Oracle8i Administrator's Guide.

Managing the Control File

The control file is a small binary file containing a record of the database schema. It is one of the most essential files in the database because it is necessary for the database to start and operate successfully. Oracle updates the control file continuously during database use, so it must be available for writing whenever the database is mounted. If for some reason the control file is not accessible, then the database cannot be mounted and recovery is difficult.

A control file contains information about the associated database that is required for the database to be accessed by an instance, both at startup and during normal operation. Only the Oracle database server can modify a control file's information; no user can edit a database's control file directly.

The control file has various properties that make it crucial for backup and recovery. For example, the control file:

• Identifies the database name (taken from either the name specified by the initialization parameter DB_NAME or the name used in the CREATE DATABASE statement).

• Records the names and locations of associated datafiles and online redo log files.

• Records the names and locations of archived redo logs.

• Stores checkpoint and log sequence information for all database files required for the synchronization of the database.

• Stores information on Recovery Manager backups (if you use Recovery Manager). The recovery catalog optionally used by RMAN obtains its essential information from the control file.

• Must be accessible for the database to be mounted, opened, and maintained.

This section addresses the following topics relating to control file management:

• Displaying Control File Information

• Backing Up the Control File After Structural Changes

• Maintaining Multiple Control Files

• Recovering from the Loss of Control Files

Displaying Control File Information

Your first step in managing the control file is learning how to gain information about it. The following data dictionary views contain useful information:

Views	Description
V$CONTROLFILE	Lists the control file filenames.
V$DATABASE	Indicates whether the control file is current or a backup, when the control file was created, and the last timestamp in the control file if it is a backup.

For example, the following query displays the database control files:

SELECT name FROM v$controlfile;

NAME 
--------------------------------------------------------------------------------
/vobs/oracle/dbs/cf1.f 
/vobs/oracle/dbs/cf2.f
2 rows selected.

To display the control file type, query the V$DATABASE view:

SELECT controlfile_type FROM v$database;

CONTROL
------------
BACKUP

The following useful statement displays all control files, datafiles, and online redo log files for the database:

SELECT member FROM v$logfile
UNION ALL
SELECT name FROM v$datafile
UNION ALL
SELECT name FROM v$controlfile;

MEMBER
--------------------------------------------------------------------------------
/vobs/oracle/dbs/rdo_log1.f 
/vobs/oracle/dbs/rdo_log2.f
/vobs/oracle/dbs/tbs_01.f
/vobs/oracle/dbs/tbs_02.f
/vobs/oracle/dbs/tbs_11.f
/vobs/oracle/dbs/tbs_12.f
/vobs/oracle/dbs/tbs_21.f
/vobs/oracle/dbs/tbs_22.f 
/vobs/oracle/dbs/tbs_13.f
/vobs/oracle/dbs/cf1.f
/vobs/oracle/dbs/cf2.f
11 rows selected.

See Also: Oracle8i Reference for more information on the dynamic performance views.

Backing Up the Control File After Structural Changes

Each time that a user adds, renames, or drops a datafile or an online redo log file from the database, Oracle updates the control file to reflect this physical structure change. Oracle records these changes so that it can identify:

• The datafiles and online redo log files that it needs to open during database startup.

• The files that are required or available in case database recovery is necessary.

Therefore, if you make a change to your database's physical structure, immediately back up the control file. If you do not, and your control file is corrupted or destroyed, then the backup control file will not accurately reflect the state of the database at the time of the failure.

Generate a binary copy of the control file or back up to a text trace file (with the destination specified by the USER_DUMP_DEST initialization parameter). You can run the script in the text trace file to re-create the control file. Back up the control file after you issue any of the following statements:

• ALTER DATABASE [ADD | DROP] LOGFILE

• ALTER DATABASE [ADD | DROP] LOGFILE MEMBER

• ALTER DATABASE [ADD | DROP] LOGFILE GROUP

• ALTER DATABASE [ARCHIVELOG | NOARCHIVELOG]

• ALTER DATABASE RENAME FILE

• CREATE TABLESPACE

• ALTER TABLESPACE [ADD | RENAME] DATAFILE

• ALTER TABLESPACE [READ WRITE | READ ONLY]

• DROP TABLESPACE

To learn how to back up the control file, see "Performing Control File Backups".

See Also: Oracle8i Administrator's Guide for more information on managing the control file, and "Backing Up the Control File to a Trace File" for a sample scenario involving editing a trace file.

Maintaining Multiple Control Files

As with online redo log files, Oracle allows you to multiplex control files, that is, configure Oracle to open and write to multiple, identical copies. Oracle writes the same data to each copy of the control file. You can also mirror them, that is, allow the operating system to write a copy of a control file to two or more physical disks. Oracle corporation recommends that you both multiplex and mirror the control files.

Mirroring at the operating system level is often better than multiplexing at the Oracle level because operating system mirroring usually tolerates failure of one of the mirrors, whereas Oracle multiplexing does not. With Oracle multiplexing, if any mirror fails, then the instance shuts down. The user then has to either:

• Repair the failed disk, copy a good control file into the old location, and restart.

• Copy a good control file to a new location and edit the CONTROL_FILES parameter of the initialization parameter file accordingly.

With operating system or hardware mirroring, you achieve the same redundancy that you do with multiplexing, but in many cases you do not have to pay with a loss in availability when a failure occurs.

The permanent loss of all copies of a database's control file is a serious problem. If any copy of a control file fails during database operation, then the instance aborts and media recovery is required. If you do not multiplex or mirror the control file, then recovery is more complex. Therefore, you should use multiplexed or mirrored control files with each database.

Figure 2-1 Multiplexing and Mirroring the Control File

Text description of the illustration datastr3.gif.

Multiplexing the Control File

By storing multiple control files for a single database on different disks, you safeguard against a single point of failure. If a single disk containing a control file crashes, then the instance fails when Oracle attempts to access the damaged control file.

If the control file is multiplexed, other copies of the current control file are available on different disks. After repairing the bad disk, you can then copy a good control file to the old location and restart the instance easily without having to perform media recovery. If you cannot repair the disk, then you can edit the CONTROL_FILES initialization parameter to specify a new location and copy the good control file copy to this location.

The only disadvantage of multiplexing control files is that operations that update the control files such as adding a datafile or checkpointing the database can take slightly longer. This increase in performance overhead is usually insignificant, however, especially for operating systems that can perform multiple, concurrent writes. A slight performance loss does not justify using only a single control file.

Note: Oracle strongly recommends that you maintain a minimum of two control files on different disks.

Note the following characteristics of multiplexed control files:

• At least two filenames are listed for the initialization parameter CONTROL_FILES in the database's parameter file.

• The first file listed in the CONTROL_FILES parameter is the only file read by the Oracle database server during database operation.

• If any of the control files becomes unavailable during database operation, then the instance becomes inoperable and aborts. Copy a good control file to the bad control file's location or, if media failure makes the disk inaccessible, copy a good control file to a new location and edit the initialization parameter file.

Mirroring the Control File

If your operating system supports disk mirroring, then the operating system allows for mirrored disk storage. Mirrored disk storage makes several physical disks look like a single disk to Oracle. Oracle writes the data once, then the operating system writes it to each of the underlying physical disks. Each file is a mirror, that is, an exact duplicate, of the others.

The advantage of disk mirroring is that if one of the disks becomes unavailable, then the other disk or disks can continue to function without interruption. Therefore, your control file is protected against a single point of failure. Note that if you store your control file on a mirrored disk system, then you only need Oracle to write one active copy of the control file.

Oracle recommends that you multiplex at least two copies of the control files on mirrored disks. This precaution allows transparent recovery of single failures, and retains fast recovery of the control file data in the case of double failure.

Recovering from the Loss of Control Files

Following are scenarios where you may need to recover or re-create the control file:

• The control file is corrupted or lost due to media failure. If you multiplex or mirror your control files on different disks, you significantly minimize this risk.

• You change the name of a database. Because the control file records the name of the database, you need to re-create it.

To recover from control file corruption using a current control file copy:

This procedure assumes that one of the control files specified in the CONTROL_FILES parameter is corrupted, the control file directory is still accessible, and you have a current multiplexed copy.

1. With the instance shut down, use an operating system command to overwrite the bad control file with a good copy:

   % cp '/disk2/copy/cf.f' '/disk1/oracle/dbs/cf.f';
   

2. Start SQL*Plus and mount or open the database:

   SQL> STARTUP MOUNT
   

To recover from permanent media failure using a current control file copy:

This procedure assumes that one of the control files specified in the CONTROL_FILES parameter is inaccessible due to a permanent media failure, and you have a current multiplexed or mirrored copy.

1. With the instance shut down, use an operating system command to copy the current copy of the control file to a new, accessible location:

   % cp '/disk2/copy/cf.f' '/disk3/copy/cf.f';
   

2. Edit the CONROL_FILES parameter in the initialization parameter file to replace the bad location with the new location:

   CONTROL_FILES = '/oracle/dbs/cf1.f','/disk3/copy/cf.f'
   

3. Start SQL*Plus and mount or open the database:

   SQL> STARTUP MOUNT
   

Managing the Online Redo Logs

Perhaps the most crucial structure for recovery operations is the online redo log, which consists of two or more pre-allocated files that store all changes made to the database as they occur. Every instance of an Oracle database has an associated online redo log to protect the database in case of an instance failure.

WARNING: Oracle recommends that you do not back up a current online log, because if you restore that backup, the backup will appear at the end of the redo thread. Because additional redo may have been generated in the thread, when you attempt to execute recovery by supplying the redo log copy, recovery will erroneously detect the end of the redo thread and prematurely terminate, possibly corrupting the database.

Each database instance has its own online redo logs groups. These online redo log groups, multiplexed or not, are called an instance's thread of online redo. In typical configurations, only one database instance accesses an Oracle database, so only one thread is present. When running the Oracle Parallel Server, however, two or more instances concurrently access a single database; each instance has its own thread.

Note: This manual describes how to configure and manage the online redo log when the Oracle Parallel Server is not used. Thus, the thread number can be assumed to be 1 in all discussions and examples of commands. For complete information about configuring the online redo log with the Oracle Parallel Server, see Oracle8i Parallel Server Documentation Set: Oracle8i Parallel Server Concepts; Oracle8i Parallel Server Setup and Configuration Guide; Oracle8i Parallel Server Administration, Deployment, and Performance.

See Also: Oracle8i Concepts for a conceptual overview of the online redo log, and Oracle8i Administrator's Guide for detailed information about managing the online redo logs.

Displaying Online Redo Log Information

The following data dictionary views contain useful information about the online redo logs:

Views	Description
V$LOG	Identifies the online redo log groups, the number of members per group, and which logs have been archived.
V$LOGFILE	Displays filenames and status information about the redo log group members.

For example, the following query displays which online redo log group requires archiving:

SELECT group#, sequence#, status, archived FROM v$log;

GROUP#     SEQUENCE#  STATUS           ARC
---------- ---------- ---------------- ---
         1         43 CURRENT          NO 
         2         42 INACTIVE         YES
2 rows selected.

Table 2-1 displays status information that can be crucial in a recovery situation:

Table 2-1 Status Column of V$LOG

Status	Description
UNUSED	The online redo log has never been written to.
CURRENT	This is the current redo log and that it is active. The redo log can be open or closed.
ACTIVE	The log is active, that is, needed for instance recovery, but is not the current log.It may be in use for block recovery, and may or may not be archived.
CLEARING	The log is being recreated as an empty log after an ALTER DATABASE CLEAR LOGFILE command. After the log is cleared, the status changes to UNUSED.
CLEARING_CURRENT	The current log is being cleared of a closed thread. The log can stay in this status if there is some failure in the switch such as an I/O error writing the new log header.
INACTIVE	The log is no longer needed for instance recovery. It may be in use for media recovery, and may or may not be archived.

To display the members for each log group, query the V$LOGFILE view:

SELECT group#, member FROM v$logfile;

GROUP#     MEMBER 
--------  --------------------------------------------------------------------------------
       1  /oracle/dbs/t1_log1.f
       2  /oracle/dbs/t1_log2.f
2 rows selected.

See Also: Oracle8i Reference for more information on the data dictionary views.

Multiplexing Online Redo Log Files

Oracle provides the capability to multiplex an instance's online redo log files to safeguard against damage. When multiplexing online redo log files, LGWR concurrently writes the same information to multiple identical online redo log files, thereby eliminating a single point of failure. You can also mirror redo logs at the operating system level, but in so doing you run the risk of operating system or hardware induced corruption. In most cases, multiplexing of online logs is best.

Oracle recommends multiplexing the online redo log on separate physical disks or possibly different file systems. If the file systems or disk subsystems support mirroring, this operation adds another level of redundancy. The online redo log is the source of your recovery data. Loss of all copies of an online log can mean the loss of committed transaction data.

WARNING: Oracle strongly recommends that you multiplex your redo log files or mirror them at the operating system level; the loss of the redo data can be catastrophic if recovery is required.

Figure 2-2 Multiplexed Online Redo Log Files

Text description of the illustration datastr2.gif.

The corresponding online redo log files are called groups. Each online redo log file in a group is called a member. In Figure 2-2, files A_LOG1 and B_LOG1 are both members of Group 1; A_LOG2 and B_LOG2 are both members of Group 2, and so forth. Each member in a group must be the exact same size.

Notice that each member of a group is concurrently active, that is, concurrently written to by LGWR, as indicated by the identical log sequence numbers assigned by LGWR. In Figure 2-2, first LGWR writes to file A_LOG1 in conjunction with B_LOG1, then A_LOG2 in conjunction with B_LOG2, etc. LGWR never writes concurrently to members of different groups, for example, to A_LOG1 and B_LOG2.

Responding to Online Redo Log Failure

Whenever LGWR cannot write to a member of a group, Oracle marks this member as stale and writes an error message to the LGWR trace file and to the database's alert log to indicate the problem with the inaccessible files. LGWR reacts differently when certain online redo log members are unavailable, depending on the reason for the unavailability.

If...	Then...
LGWR can successfully write to at least one member in a group	Writing proceeds as normal; LGWR simply writes to the available members of a group and ignores the unavailable members.
LGWR cannot access the next group at a log switch because the group needs to be archived	Database operation temporarily halts until the group becomes available, that is, until the group is archived.
All members of the next group are inaccessible to LGWR at a log switch because of disk failures	Oracle returns an error and the database instance shuts down. In this case, you may need to perform media recovery on the database from the loss of an online redo log file.
All members of the next group are inaccessible and the database checkpoint has moved beyond the lost redo log	Media recovery is not necessary because Oracle has saved the data recorded in the redo log to the datafiles. Simply drop the inaccessible redo log group.
You want to drop an unarchived redo log when in ARCHIVELOG mode	Issue ALTER DATABASE CLEAR UNARCHIVED LOG to disable archiving before the log can be dropped.
All members of group become inaccessible to LGWR while it is writing to them	Oracle returns an error and the database instance immediately shuts down. In this case, you may need to perform media recovery. If the media containing the log is not actually lost -- for example, if the drive for the log was inadvertently turned off -- media recovery may not be needed. In this case, you only need to turn the drive back on and let Oracle perform instance recovery.

Managing the Archived Redo Logs

If you run your database in ARCHIVELOG mode, Oracle allows you to save filled groups of online redo log files, known as archived redo logs, to one or more offline destinations. Archiving is the operation of turning online redo logs into archived redo logs.

Use archived logs to:

• Recover a database.

• Update a standby database.

• Gain information about the history of a database through the LogMiner utility.

An archived redo log file is a copy of one of the identical filled members of an online redo log group: it includes the redo entries present in the identical members of a group and also preserves the group's unique log sequence number. For example, if you are multiplexing the online redo logs, and if Group 1 contains member files A_LOG1 and B_LOG1, then the ARCn process will archive one of these identical members. Should A_LOG1 become corrupted, then ARCn can still archive the identical B_LOG1.

If you enable archiving, LGWR is not allowed to re-use and hence overwrite an online redo log group until it has been archived. Therefore, the archived redo log contains a copy of every online redo group created since you enabled archiving. The best way to back up the contents of the current online log is always to archive it, then back up the archived log.

By archiving your online redo logs, you save a copy of every change made to the database since you enabled archiving. If you suffer a media failure, then you can recover the lost data by using the archived redo logs.

See Also: Oracle8i Administrator's Guide for complete procedures for managing archived redo logs as well as for using the LogMiner, and Oracle8i Standby Database Concepts and Administration to learn how to manage a standby database.

This section contains the following topics:

• Displaying Archived Redo Log Information

• Choosing the Database Archiving Mode

• Setting the Archive Mode

• Archiving Redo Logs to Multiple Locations

Displaying Archived Redo Log Information

The following data dictionary views contain useful information about the archived redo logs:

Views	Description
V$DATABASE	Identifies whether the database is in ARCHIVELOG or NOARCHIVELOG mode.
V$ARCHIVED_LOG	Displays archived log information from the control file.
V$ARCHIVE_DEST	Describes the current instance, all archive destinations, and the current value, mode, and status of these destinations.
V$LOG	Displays all online redo log groups for the database and indicates which need to be archived.
V$LOG_HISTORY	Contains log history information such as which logs have been archived and the SCN range for each archived log.

For example, the following query displays which online redo log group requires archiving:

SELECT group#, archived FROM sys.v$log;

GROUP#     ARC
---------- ---
1          YES
2          NO

To see the current archiving mode, query the V$DATABASE view:

SELECT log_mode FROM sys.v$database;

LOG_MODE
------------
NOARCHIVELOG

The SQL*Plus statement ARCHIVE LOG LIST also shows archiving information for the connected instance:

ARCHIVE LOG LIST;

Database log mode                        ARCHIVELOG
Automatic archival                       ENABLED
Archive destination                      /oracle/log
Oldest online log sequence               30
Next log sequence to archive             31
Current log sequence number              33

This display tells you all the necessary information regarding the archived redo log settings for the current instance:

• The database is currently operating in ARCHIVELOG mode.

• Automatic archiving is enabled.

• The destination of the archived redo log (operating system specific).

• The oldest filled online redo log group has a sequence number of 30.

• The next filled online redo log group to be archived has a sequence number of 31.

• The current online redo log file has a sequence number of 33.

You must archive all redo log groups with a sequence number equal to or greater than the Next log sequence to archive, yet less than the Current log sequence number. For example, the display above indicates that the online redo log groups with sequence numbers 31 and 32 need to be archived.

See Also: Oracle8i Reference for more information on the data dictionary views.

Choosing the Database Archiving Mode

This section describes the issues you must consider when choosing to run your database in NOARCHIVELOG or ARCHIVELOG mode, and includes the following topics:

• Running a Database in NOARCHIVELOG Mode

• Running a Database in ARCHIVELOG Mode

Running a Database in NOARCHIVELOG Mode

When you run your database in NOARCHIVELOG mode, you disable the archiving of the online redo log. The database's control file indicates that filled groups are not required to be archived. Therefore, after a filled group becomes inactive after a log switch, the group is available for reuse by LGWR.

Running your database in NOARCHIVELOG mode has the following consequences:

• You can only restore (not recover) the database to the point of the most recent full database backup. You cannot apply archived logs to the backup because there are no archived logs to be applied.

• You can only perform an operating system backup of the database when it is shut down cleanly.

• You can only restore a whole database backup and then open the database when the backup was taken while the database was closed cleanly. The only time you can restore an inconsistent backup is when the redo logs are undamaged and contain all redo generated since the backup was made.

• You cannot perform online tablespace backups. Furthermore, you cannot use online tablespace backups previously taken while the database operated in ARCHIVELOG mode.

  See Also: "Backing Up a NOARCHIVELOG Database"

Running a Database in ARCHIVELOG Mode

When you run a database in ARCHIVELOG mode, Oracle requires the online redo log to be archived. You can either perform the archiving manually or enable automatic archiving.

In ARCHIVELOG mode, the database control file indicates that a group of filled online redo log files cannot be used by LGWR until the group is archived. A filled group is immediately available to ARCn after a log switch occurs. After the group has been successfully archived, Oracle can reuse the group.

Figure 2-3 illustrates the basic principle of archiving. LGWR writes to a log and then ARCn archives it. Each new write is assigned a new log sequence number, so the log sequence numbers increment by 1.

Figure 2-3 Online Redo Log File Use in ARCHIVELOG Mode

Text description of the illustration datastra.gif.

The archiving of filled groups has these advantages:

• A database backup in conjunction with all (possibly backed up) archived logs and the current online redo logs guarantees that you can recover all committed transactions.

• You can recover the database to a specified time, SCN, or log sequence number.

• You can take tablespace backups while the database is open.

• You can recover offline tablespaces while the database is open.

• You can keep a standby database current with its original database by continually applying the original's archived redo logs to the standby.

  See Also: Oracle8i Administrator's Guide to learn how to enable ARCHIVELOG mode and enable automatic archiving, and Oracle8i Standby Database Concepts and Administration for information about the managed recovery option for standby databases.

Setting the Archive Mode

To switch a database's archiving mode between NOARCHIVELOG and ARCHIVELOG mode, use the SQL statement ALTER DATABASE with the ARCHIVELOG or NOARCHIVELOG option. The following statement switches the database's archiving mode from NOARCHIVELOG to ARCHIVELOG:

ALTER DATABASE ARCHIVELOG; 

Before switching the database's archiving mode, perform the following operations:

1. Shut down the database instance.

2. Back up the database.

3. Restart the instance and mount but do not open the database.

4. Issue ALTER DATABASE ARCHIVELOG or ALTER DATABASE NOARCHIVELOG to switch the database's archiving mode.

Enabling Automatic Archiving

To enable automatic archiving of filled groups, include the initialization parameter LOG_ARCHIVE_START parameter in the database's parameter file and set it to TRUE:

LOG_ARCHIVE_START=TRUE 

The new value takes effect the next time you start the database.

To enable automatic archiving of filled online redo log groups without shutting down the current instance, use the SQL statement ALTER SYSTEM with the ARCHIVE LOG START parameter:

ALTER SYSTEM ARCHIVE LOG START;

If you use the ALTER SYSTEM method, then you do not need to shut down and restart the instance to enable automatic archiving.

See Also: Oracle8i Administrator's Guide for complete procedures for changing the archiving mode and enabling automatic archiving.

Archiving Redo Logs to Multiple Locations

You can specify a single destination or multiple destinations for the archived redo logs. Oracle recommends archiving your logs to different disks to guard against file corruption and media failure.

Specify the number of locations for your archived logs by setting either of two mutually exclusive sets of initialization parameters:

• LOG_ARCHIVE_DEST_n (where n is an integer from 1 to 5)

• LOG_ARCHIVE_DEST in conjunction with the optional initialization parameter LOG_ARCHIVE_DUPLEX_DEST

The first method is to use the LOG_ARCHIVE_DEST_n parameter to specify from one to five different destinations for archival. Each numerically-suffixed parameter uniquely identifies an individual destination, for example, LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2, etc. Use the LOCATION keyword to specify a pathname or the SERVICE keyword to specify a net service name (for use in conjunction with a standby database).

The second method, which allows you to specify a maximum of two locations, is to use the LOG_ARCHIVE_DEST parameter to specify a primary archive destination and the LOG_ARCHIVE_DUPLEX_DEST to determine an optional secondary location. Whenever Oracle archives a redo log, it archives it to every destination specified by either set of parameters.

Note: You can also mirror your archived logs at the operating system level.

To set the archiving destination using LOG_ARCHIVE_DEST_n:

1. Edit the LOG_ARCHIVE_DEST_n parameter to specify from one to five archiving locations. For example, enter:

   LOG_ARCHIVE_DEST_1 = 'LOCATION=/disk1/arc/'
   LOG_ARCHIVE_DEST_2 = 'LOCATION=/disk2/arc/'
   LOG_ARCHIVE_DEST_3 = 'LOCATION=/disk3/arc/'
   

2. Edit the LOG_ARCHIVE_FORMAT parameter, using %s to include the log sequence number as part of the filename and %t to include the thread number. Use capital letters (%S and %T) to pad the filename to the left with zeros. For example, enter:

   LOG_ARCHIVE_FORMAT = arch%t_%s.arc
   
   

   For example, this setting results in the following files for log sequence numbers 100-102 on thread 1:

   /disk1/arc/arch1_100.arc, /disk1/arc/arch1_101.arc, /disk1/arc/arch1_102.arc,
   /disk2/arc/arch1_100.arc, /disk2/arc/arch1_101.arc, /disk2/arc/arch1_102.arc,
   /disk3/arc/arch1_100.arc, /disk3/arc/arch1_101.arc, /disk3/arc/arch1_102.arc
   
   

3. If the database is open, start a SQL*Plus session and shut down the database. For example, enter:

   SHUTDOWN IMMEDIATE
   

4. Mount or open the database to enable the settings. For example, enter:

   STARTUP
   

To set archiving destinations with LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST:

1. Edit the initialization parameter file, specifying destinations for the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameter. If the database is open, then you can also edit the parameter dynamically using the ALTER SYSTEM statement.

   For example, change the parameter to read:

   LOG_ARCHIVE_DEST = '/disk1/arc'
   LOG_ARCHIVE_DUPLEX_DEST_2 = '/disk2/arc'
   

2. Edit the LOG_ARCHIVE_FORMAT parameter, using %s to include the log sequence number as part of the filename and %t to include the thread number. Use capital letters (%S and %T) to pad the filename to the left with zeroes. If the database is open, you can alter the parameter using the ALTER SYSTEM statement.

   For example, enter:

   LOG_ARCHIVE_FORMAT = arch_%t_%s.arc
   
   

   For example, this setting will result in the following files for log sequence numbers 300-302 on thread 1:

   /disk1/arc/arch_1_300.arc, /disk1/arc/arch_1_301.arc, /disk1/arc/arch_1_302.arc,
   /disk2/arc/arch_1_300.arc, /disk2/arc/arch_1_301.arc, /disk2/arc/arch_1_302.arc
   
   

3. If the database is open, start a SQL*Plus session and shut down the database. For example, enter:

   SHUTDOWN IMMEDIATE
   

4. Mount or open the database to enable the settings in the initialization parameter file. For example, enter:

   STARTUP
   
   

Oracle provides you with a number of useful archiving options. See the Oracle8i Administrator's Guide for a complete account of how to:

• Obtain status information for each archive destination. For example, you can determine whether there was a problem archiving to a specific destination.

• Specify archiving to a local disk or to either a local or remote standby database site.

• Specify the minimum number of destinations to which Oracle must successfully archive.

• Specify when and how often ARCn attempts to re-archive to a failed destination.

• Specify up to ten ARCn processes for each database instance to parallelize archiving operations.

• Use the LogMiner utility to analyze the contents of online and archived redo logs.