Release 2 (9.2)
Part Number A96521-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Database Administrator's Guide Release 2 (9.2) Part Number A96521-01 |
|
This chapter describes how to archive redo data. It contains the following topics:
| See Also:
Oracle9i Real Application Clusters Administration for information specific to archiving in the Oracle Real Application Clusters environment |
Oracle enables you to save filled groups of online redo log files to one or more offline destinations, known collectively as the archived redo log, or more simply archive log. The process of turning online redo log files into archived redo log files is called archiving. This process is only possible if the database is running in ARCHIVELOG mode. You can choose automatic or manual archiving.
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 member of a redo log group and also preserves the group's unique log sequence number. For example, if you are multiplexing your online redo log, and if Group 1 contains member files a_log1 and b_log1, then the archiver process (ARCn) will archive one of these identical members. Should a_log1 become corrupted, then ARCn can still archive the identical b_log1. The archived redo log contains a copy of every group created since you enabled archiving.
When running in ARCHIVELOG mode, the log writer process (LGWR) is not allowed to reuse and hence overwrite an online redo log group until it has been archived. The background process ARCn automates archiving operations when automatic archiving is enabled. Oracle starts multiple archiver processes as needed to ensure that the archiving of filled online redo logs does not fall behind.
You can use archived redo logs to:
This section describes the issues you must consider when choosing to run your database in NOARCHIVELOG or ARCHIVELOG mode, and contains these topics:
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, when a filled group becomes inactive after a log switch, the group is available for reuse by LGWR.
The choice of whether to enable the archiving of filled groups of online redo log files depends on the availability and reliability requirements of the application running on the database. If you cannot afford to lose any data in your database in the event of a disk failure, use ARCHIVELOG mode. The archiving of filled online redo log files can require you to perform extra administrative operations.
NOARCHIVELOG mode protects a database only from instance failure, but not from media failure. Only the most recent changes made to the database, which are stored in the groups of the online redo log, are available for instance recovery. In other words, if a media failure occurs while in NOARCHIVELOG mode, you can only restore (not recover) the database to the point of the most recent full database backup. You cannot recover subsequent transactions.
Also, in NOARCHIVELOG mode you cannot perform online tablespace backups. Furthermore, you cannot use online tablespace backups previously taken while the database operated in ARCHIVELOG mode. You can only use whole database backups taken while the database is closed to restore a database operating in NOARCHIVELOG mode. Therefore, if you decide to operate a database in NOARCHIVELOG mode, take whole database backups at regular, frequent intervals.
When you run a database in ARCHIVELOG mode, you specify the archiving of the online redo log. 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 for archiving after a redo log switch occurs.
The archiving of filled groups has these advantages:
Decide how you plan to archive filled groups of the online redo log. You can configure an instance to archive filled online redo log files automatically, or you can archive manually. For convenience and efficiency, automatic archiving is usually best. Figure 8-1 illustrates how the archiver process (ARC0 in this illustration) writes filled online redo log files to the database's archived redo log.
If all databases in a distributed database operate in ARCHIVELOG mode, you can perform coordinated distributed database recovery. If any database in a distributed database uses NOARCHIVELOG mode, however, recovery of a global distributed database (to make all databases consistent) is limited by the last full backup of any database operating in NOARCHIVELOG mode.
This section describes how to control the archiving mode of the database, and how to control the archiving process. The following topics are discussed:
You set a database's initial archiving mode as part of database creation in the CREATE DATABASE statement. Usually, you can use the default of NOARCHIVELOG mode at database creation because there is no need to archive the redo information generated then. After creating the database, decide whether to change from the initial archiving mode.
|
Note: If a database is automatically created during Oracle installation, the initial archiving mode of the database is operating system specific. |
To switch a database's archiving mode, use the ALTER DATABASE statement with the ARCHIVELOG or NOARCHIVELOG option. The following steps switch a database's archiving mode from NOARCHIVELOG to ARCHIVELOG:
SHUTDOWN
An open database must first be closed and any associated instances shut down before you can switch the database's archiving mode. You cannot disable archiving if any datafiles need media recovery.
Before making any major change to a database, always back up the database to protect against any problems. This will be your final backup of the database in NOARCHIVELOG mode and can be used if something goes wrong while trying to change to ARCHIVELOG mode. See Oracle9i User-Managed Backup and Recovery Guide or Oracle9i Recovery Manager User's Guide.
STARTUP MOUNT
To enable or disable archiving, the database must be mounted but not open.
ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN;
SHUTDOWN IMMEDIATE
Changing the database archiving mode updates the control file. After changing the database archiving mode, you must back up all of your database files and control file. Any previous backup is no longer usable because it was taken in NOARCHIVELOG mode.
| See Also:
Oracle9i Real Application Clusters Administration for more information about switching the archiving mode when using Oracle9i Real Application Clusters |
You can enable automatic archiving of the online redo log. When automatic archiving is enabled, no action is required to copy a group after it fills: Oracle automatically archives it. However, even when automatic archiving is enabled, you can still perform manual archiving as described in "Performing Manual Archiving" .
You can enable automatic archiving before or after instance startup. To enable automatic archiving after instance startup, you must be connected to Oracle with administrator privileges (AS SYSDBA), or have the ALTER SYSTEM system privilege.
Ensure that an archived redo log destination and file name format have been specified before enabling automatic archiving. This is described in "Specifying Archive Destinations".
|
Caution: Oracle does not automatically archive log files unless the database is also in |
To enable automatic archiving of filled groups each time an instance is started, include the initialization parameter LOG_ARCHIVE_START in the database's initialization 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 ALTER SYSTEM statement specifying the ARCHIVE LOG START clause. For example:
ALTER SYSTEM ARCHIVE LOG START;
You can optionally include the archiving destination.
Oracle starts additional archiver processes (ARCn) as needed to ensure that the automatic processing of filled redo log files does not fall behind. However, to avoid any runtime overhead of invoking additional ARCn processes, you can specify the number of processes to be started at instance startup using the LOG_ARCHIVE_MAX_PROCESSES initialization parameter. Up to 10 ARCn processes can be started.
This parameter also limits the number of ARCn processes that can be started for the instance. No more than the specified number of processes can ever be started.
The LOG_ARCHIVE_MAX_PROCESSES is dynamic, and can be changed using the ALTER SYSTEM statement. The following statement increases (or decreases) the number of ARCn processes currently running:
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=3;
There is usually no need to change the LOG_ARCHIVE_MAX_PROCESSES initialization parameter from its default value of 2, because Oracle will adequately adjust ARCn processes according to system workload.
You can disable automatic archiving of the online redo log groups at any time. After having disabled automatic archiving, you must manually archive groups of online redo log files in a timely fashion. If you run a database in ARCHIVELOG mode and disable automatic archiving, and if all groups of online redo log files are filled but not archived, then LGWR cannot reuse any inactive groups of online redo log groups. Therefore, database operation is temporarily suspended until you perform the necessary archiving.
You can disable automatic archiving at or after instance startup. To disable automatic archiving after instance startup, you must be connected with administrator privileges or have the ALTER SYSTEM privilege.
To disable the automatic archiving of filled online redo log groups at database startup, set the LOG_ARCHIVE_START initialization parameter to FALSE:
LOG_ARCHIVE_START=FALSE
To disable the automatic archiving of filled online redo log groups without shutting down the current instance, use the SQL statement ALTER SYSTEM with the ARCHIVE LOG STOP parameter. The following statement stops archiving:
ALTER SYSTEM ARCHIVE LOG STOP;
If ARCn is archiving a redo log group when you attempt to disable automatic archiving, ARCn finishes archiving the current group, but does not begin archiving the next filled online redo log group.
The instance does not have to be shut down to disable automatic archiving. If an instance is shut down and restarted after automatic archiving is disabled, however, the instance is reinitialized using the settings of the initialization parameter file, which may or may not enable automatic archiving.
If you operate your database in ARCHIVELOG mode, but do not have automatic archiving enabled, then you must archive inactive groups of filled online redo log files or your database operation can be temporarily suspended.
You can also use manual archiving, even when automatic archiving is enabled, for such action as rearchiving an inactive group of filled online redo log members to another location. In this case, however, it is possible that the instance can reuse the redo log group before you have finished manually archiving, and thereby overwrite the files. If this happens, Oracle will write an error message to the alert file.
To archive a filled online redo log group manually, connect with administrator privileges. Use the ALTER SYSTEM statement with the ARCHIVE LOG clause to manually archive filled online redo log files. The following statement archives all unarchived log files:
ALTER SYSTEM ARCHIVE LOG ALL;
When archiving redo logs, determine the destination to which you will archive and familiarize yourself with the various destination states. Develop a practice of using dynamic performance (V$) views, listed in "Viewing Information About the Archived Redo Log", to access archive information.
The following topics are contained in this section
You must decide whether to make a single destination for the logs or multiplex them. When you multiplex them, you archive the logs to more than one location. You specify your choice by setting initialization parameters according to one of the following methods.
See Also:
|
The first method is to use the LOG_ARCHIVE_DEST_n parameter (where n is an integer from 1 to 10) to specify from one to ten different destinations for archival. Each numerically-suffixed parameter uniquely identifies an individual destination.
You specify the location for LOG_ARCHIVE_DEST_n using these keywords:
If you use the LOCATION keyword, specify a valid path name for your operating system. If you specify SERVICE, Oracle translates the net service name through the tnsnames.ora file to a connect descriptor. The descriptor contains the information necessary for connecting to the remote database. The service name must have an associated database SID, so that Oracle correctly updates the log history of the control file for the standby database.
Perform the following steps to set the destination for archived redo logs using the LOG_ARCHIVE_DEST_n initialization parameter:
SHUTDOWN
LOG_ARCHIVE_DEST_n parameter to specify from one to ten archiving locations. The LOCATION keyword specifies an operating system specific path name. For example, enter:
LOG_ARCHIVE_DEST_1 = 'LOCATION = /disk1/archive' LOG_ARCHIVE_DEST_2 = 'LOCATION = /disk2/archive' LOG_ARCHIVE_DEST_3 = 'LOCATION = /disk3/archive'
If you are archiving to a standby database, use the SERVICE keyword to specify a valid net service name from the tnsnames.ora file. For example, enter:
LOG_ARCHIVE_DEST_4 = 'SERVICE = standby1'
LOG_ARCHIVE_FORMAT initialization parameter, using %s to include the log sequence number as part of the file name and %t to include the thread number. Use capital letters (%S and %T) to pad the file name to the left with zeroes. For example, enter:
LOG_ARCHIVE_FORMAT = arch%s.arc
These settings will generate archived logs as follows for log sequence numbers 100, 101, and 102:
/disk1/archive/arch100.arc, /disk1/archive/arch101.arc,/disk1/archive/arch102.arc/disk2/archive/arch100.arc, /disk2/archive/arch101.arc,/disk2/archive/arch102.arc/disk3/archive/arch100.arc, /disk3/archive/arch101.arc,/disk3/archive/arch102.arc
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 specify an optional secondary archive destination. Whenever Oracle archives a redo log, it archives it to every destination specified by either set of parameters.
Perform the following steps to use method 2:
SHUTDOWN
LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameter (you can also specify LOG_ARCHIVE_DUPLEX_DEST dynamically using the ALTER SYSTEM statement). For example, enter:
LOG_ARCHIVE_DEST = '/disk1/archive' LOG_ARCHIVE_DUPLEX_DEST = '/disk2/archive'
LOG_ARCHIVE_FORMAT parameter, using %s to include the log sequence number as part of the file name and %t to include the thread number. Use capital letters (%S and %T) to pad the file name to the left with zeroes. For example, enter:
LOG_ARCHIVE_FORMAT = arch_%t_%s.arc
For example, the above settings generates archived logs as follows for log sequence numbers 100 and 101 in thread 1:
/disk1/archive/arch_1_100.arc, /disk1/archive/arch_1_101.arc /disk2/archive/arch_1_100.arc, /disk2/archive/arch_1_101.arc
Each archive destination has the following variable characteristics that determine its status:
Several combinations of these characteristics are possible. To obtain the current status and other information about each destination for an instance, query the V$ARCHIVE_DEST view.
The characteristics determining a locations status that appear in the view are shown in Table 8-1. Note that for a destination to be used, its characteristics must be valid, enabled, and active.
The LOG_ARCHIVE_DEST_STATE_n (where n is an integer from 1 to 10) initialization parameter allows you to control the availability state of the specified destination (n). The destination state can have three values: ENABLE,DEFER, or ALTERNATE. The value ENABLE indicates that Oracle can use the destination, whereas DEFER indicates that the location is temporarily disabled. The third value, ALTERNATE, means that the destination is an alternate. It's availability state is DEFER, unless there is a failure of its parent destination, in which case its state becomes ENABLE.
There are two modes of transmitting archived logs to their destination: normal archiving transmission and standby transmission mode. Normal transmission involves transmitting files to a local disk. Standby transmission involves transmitting files through a network to either a local or remote standby database.
In normal transmission mode, the archiving destination is another disk drive of the database server. In this configuration archiving does not contend with other files required by the instance and can complete more quickly. Specify the destination with either the LOG_ARCHIVE_DEST_n or LOG_ARCHIVE_DEST parameters.
Ideally, you should permanently move archived redo log files and corresponding database backups from the local disk to inexpensive offline storage media such as tape. Because a primary value of archived logs is database recovery, you want to ensure that these logs are safe should disaster strike your primary database.
In standby transmission mode, the archiving destination is either a local or remote standby database.
|
Caution: You can maintain a standby database on a local disk, but Oracle strongly encourages you to maximize disaster protection by maintaining your standby database at a remote site. |
If you are operating your standby database in managed recovery mode, you can keep your standby database in sync with your source database by automatically applying transmitted archive logs.
To transmit files successfully to a standby database, either ARCn or a server process must do the following:
Each ARCn process has a corresponding RFS for each standby destination. For example, if three ARCn processes are archiving to two standby databases, then Oracle establishes six RFS connections.
You can transmit archived logs through a network to a remote location by using Oracle Net. Indicate a remote archival by specifying a Oracle Net service name as an attribute of the destination. Oracle then translates the service name, through the tnsnames.ora file to a connect descriptor. The descriptor contains the information necessary for connecting to the remote database. The service name must have an associated database SID, so that Oracle correctly updates the log history of the control file for the standby database.
The RFS process, which runs on the destination node, acts as a network server to the ARCn client. Essentially, ARCn pushes information to RFS, which transmits it to the standby database.
The RFS process, which is required when archiving to a remote destination, is responsible for the following tasks:
STANDBY_ARCHIVE_DEST parameterArchived redo logs are integral to maintaining a standby database, which is an exact replica of a database. You can operate your database in standby archiving mode, which automatically updates a standby database with archived redo logs from the original database.
See Also:
|
Sometimes archive destinations can fail, causing problems when you operate in automatic archiving mode. To minimize the problems associated with destination failure, Oracle provides you with options. Discussions of these options are contained in the following sections:
The optional initialization parameter LOG_ARCHIVE_MIN_SUCCEED_DEST=n (where n is an integer from 1 to 10, or 1 to 2 if you choose to use duplexing) determines the minimum number of destinations to which Oracle must successfully archive a redo log group before it can reuse online log files. The default value is 1.
Using the LOG_ARCHIVE_DEST_n parameter, you can specify whether a destination has the attributes OPTIONAL (default) or MANDATORY. The LOG_ARCHIVE_MIN_SUCCEED_DEST=n parameter uses all MANDATORY destinations plus some number of OPTIONAL non-standby destinations to determine whether LGWR can overwrite the online log.
When determining how to set your parameters, note the following:
MANDATORY for a destination is the same as specifying OPTIONAL.OPTIONAL or MANDATORY.LOG_ARCHIVE_MIN_SUCCEED_DEST=n at least one local destination will operationally be treated as MANDATORY, since the minimum value for LOG_ARCHIVE_MIN_SUCCEED_DEST is 1.MANDATORY destination, including a MANDATORY standby destination, makes the LOG_ARCHIVE_MIN_SUCCEED_DEST parameter irrelevant.LOG_ARCHIVE_MIN_SUCCEED_DEST value cannot be greater than the number of destinations, nor greater than the number of MANDATORY destinations plus the number of OPTIONAL local destinations.DEFER a MANDATORY destination, and Oracle overwrites the online log without transferring the archived log to the standby site, then you must transfer the log to the standby manually.You can also establish which destinations are mandatory or optional by using the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST parameters. Note the following rules:
LOG_ARCHIVE_DEST is mandatory.LOG_ARCHIVE_DUPLEX_DEST is optional if LOG_ARCHIVE_MIN_SUCCEED_DEST = 1 and mandatory if LOG_ARCHIVE_MIN_SUCCEED_DEST = 2.You can see the relationship between the LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_MIN_SUCCEED_DEST parameters most easily through sample scenarios.
In this scenario, you archive to three local destinations, each of which you declare as OPTIONAL. Table 8-2 illustrates the possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=n in this case.
This scenario shows that even though you do not explicitly set any of your destinations to MANDATORY using the LOG_ARCHIVE_DEST_n parameter, Oracle must successfully archive to one or more of these locations when LOG_ARCHIVE_MIN_SUCCEED_DEST is set to 1, 2, or 3.
In this scenario, consider a case in which:
MANDATORY destinations.OPTIONAL destinations.Table 8-3 shows the possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=n.
This case shows that Oracle must archive to the destinations you specify as MANDATORY, regardless of whether you set LOG_ARCHIVE_MIN_SUCCEED_DEST to archive to a smaller number of destinations.
Use the REOPEN attribute of the LOG_ARCHIVE_DEST_n parameter to specify whether and when ARCn attempts to rearchive to a failed destination following an error. REOPEN applies to all errors, not just OPEN errors.
REOPEN=n sets the minimum number of seconds before ARCn should try to reopen a failed destination. The default value for n is 300 seconds. A value of 0 is the same as turning off the REOPEN option. In other words, ARCn will not attempt to archive after a failure. If you do not specify the REOPEN keyword, ARCn will never reopen a destination following an error.
You cannot use REOPEN to specify a limit on the number of attempts to reconnect and transfer archived logs. The REOPEN attempt either succeeds or fails, in which case the REOPEN information is reset.
If you specify REOPEN for an OPTIONAL destination, Oracle can overwrite online logs if there is an error. If you specify REOPEN for a MANDATORY destination, Oracle stalls the production database when it cannot successfully archive. In this situation, consider the following options:
When using the REOPEN keyword, note the following:
REOPEN time was specified or defaulted, ARCn checks to see whether the time of the recorded error plus the REOPEN interval is less than the current time. If it is, ARCn retries the log copy.REOPEN clause successfully affects the ACTIVE=TRUE destination state. The VALID and ENABLED states are not changed.For most databases, ARCn has no effect on overall system performance. On some large database sites, however, archiving can have an impact on system performance. On one hand, if ARCn works very quickly, overall system performance can be reduced while ARCn runs, since CPU cycles are being consumed in archiving. On the other hand, if ARCn runs extremely slowly, it has little detrimental effect on system performance, but it takes longer to archive redo log files, and can create a bottleneck if all redo log groups are unavailable because they are waiting to be archived.
You can specify up to ten ARCn processes for each database instance. Enable the multiple processing feature at startup or at runtime by setting the initialization parameter LOG_ARCHIVE_MAX_PROCESSES=n (where n is any integer from 1 to 10). By default, the parameter is set to 2.
Because LGWR automatically increases the number of ARCn processes should the current number be insufficient to handle the current workload, the parameter is intended to allow you to specify the initial number of ARCn processes or to increase or decrease the current number. Assuming the initial number of ARCn processes was set to 4, the following statement will decrease the number of processes to 2.
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=2;
When decreasing the number of ARCn processes, it is not determinate exactly which process will be stopped. Also, you are not allowed to alter the value of the parameter to 0, so at least one ARCn process is always active. Query the V$ARCHIVE_PROCESSES view to see information about the state of each archive process. Processes that have stopped show as being in the IDLE state.
Creating multiple processes is especially useful when you:
Multiple ARCn processing prevents the bottleneck that occurs when LGWR switches through the multiple online redo logs faster than a single ARCn process can write inactive logs to multiple destinations. Each ARCn process works on only one inactive log at a time, but must archive to each specified destination.
For example, if you maintain five online redo log files, then you may decide to start the instance using three ARCn processes. As LGWR actively writes to one of the log files, the ARCn processes can simultaneously archive up to three of the inactive log files to various destinations. As Figure 8-2 illustrates, each instance of ARCn assumes responsibility for a single log file and archives it to all of the defined destinations.
| See Also:
Oracle9i Database Performance Tuning Guide and Reference for more information about tuning the archiving process |
As discussed in "Trace Files and the Alert File", background processes always write to a trace file when appropriate. In the case of the archivelog process, it is possible to control the output that is generated.
The LOG_ARCHIVE_TRACE initialization parameter can be set to specify a trace level. The following values can be specified:
You can combine tracing levels by specifying a value equal to the sum of the individual levels that you would like to trace. For example, setting LOG_ARCHIVE_TRACE=12, will generate trace level 8 and 4 output. You can set different values for the primary and any standby database.
The default value for the LOG_ARCHIVE_TRACE parameter is 0, and at this level, error conditions still generate the appropriate alert and trace entries.
You can change the value of this parameter dynamically using the ALTER SYSTEM statement. For example:
ALTER SYSTEM SET LOG_ARCHIVE_TRACE=12;
Changes initiated in this manner will take effect at the start of the next archiving operation.
| See Also:
Oracle9i Data Guard Concepts and Administration for information about using this parameter with a standby database |
You can display information about the archived redo logs using the following:
There are several dynamic performance views that contain useful information about archived redo logs.
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
| See Also:
Oracle9i Database Reference for detailed descriptions of data dictionary views |
The SQL*Plus command ARCHIVE LOG LIST can be used to show archiving information for the connected instance. For example:
SQL> ARCHIVE LOG LIST Database log mode Archive Mode Automatic archival Enabled Archive destination D:\ORANT\oradata\IDDB2\archive Oldest online log sequence 11160 Next log sequence to archive 11163 Current log sequence 11163
This display tells you all the necessary information regarding the archived redo log settings for the current instance:
ARCHIVELOG mode.D:\ORANT\oradata\IDDB2\archive.| See Also:
SQL*Plus User's Guide and Reference for more information on the |
|
 Copyright © 2001, 2002 Oracle Corporation. All Rights Reserved. |
|