导读：
See Also :
Part III, " Automated File and Storage Management "for information about creating an archived redo log that is both created and managed by the Oracle Database server
Oracle Real Application Clusters Administrator's Guidefor information specific to archiving in the Oracle Real Application Clusters environment
What Is the Archived Redo Log?
Oracle Database lets you save filled groups of redo log files to one or more offline destinations, known collectively as the archived redo log, or more simply the archive log. The process of turning 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 filled members of a redo log group. It includes the redo entries and the unique log sequence number of the identical member of the redo log group. For example, if you are multiplexing your redo log, and if group 1 contains identical member files a_log1and b_log1, then the archiver process (ARCn) will archive one of these member files. Should a_log1become corrupted, then ARCncan still archive the identical b_log1. The archived redo log contains a copy of every group created since you enabled archiving.
When the database is running in ARCHIVELOGmode, the log writer process (LGWR) cannot reuse and hence overwrite a redo log group until it has been archived. The background process ARCnautomates archiving operations when automatic archiving is enabled. The database starts multiple archiver processes as needed to ensure that the archiving of filled redo logs does not fall behind.
You can use archived redo logs to:
Recover a database
Update a standby database
Get information about the history of a database using the LogMiner utility
See Also:
The following sources document the uses for archived redo logs:
Oracle Data Guard Concepts and Administrationdiscusses setting up and maintaining a standby database
Oracle Database Utilitiescontains instructions for using the LogMiner PL/SQL package
Choosing Between NOARCHIVELOG and ARCHIVELOG Mode
This section describes the issues you must consider when choosing to run your database in NOARCHIVELOGor ARCHIVELOGmode, and contains these topics:
The choice of whether to enable the archiving of filled groups of 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 ARCHIVELOGmode. The archiving of filled redo log files can require you to perform extra administrative operations.
Running a Database in NOARCHIVELOG Mode
When you run your database in NOARCHIVELOGmode, you disable the archiving of the redo log. The database 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.
NOARCHIVELOGmode protects a database from instance failure but not from media failure. Only the most recent changes made to the database, which are stored in the online redo log groups, are available for instance recovery. If a media failure occurs while the database is in NOARCHIVELOGmode, you can only restore the database to the point of the most recent full database backup. You cannot recover transactions subsequent to that backup.
In NOARCHIVELOGmode you cannot perform online tablespace backups, nor can you use online tablespace backups taken earlier while the database was in ARCHIVELOGmode. To restore a database operating in NOARCHIVELOGmode, you can use only whole database backups taken while the database is closed. Therefore, if you decide to operate a database in NOARCHIVELOGmode, take whole database backups at regular, frequent intervals.
Running a Database in ARCHIVELOG Mode
When you run a database in ARCHIVELOGmode, you enable the archiving of the redo log. The database control file indicates that a group of filled redo log files cannot be reused by LGWR until the group is archived. A filled group becomes available for archiving immediately after a redo log switch occurs.
The archiving of filled groups has these advantages:
A database backup, together with online and archived redo log files, guarantees that you can recover all committed transactions in the event of an operating system or disk failure.
If you keep an archived log, you can use a backup taken while the database is open and in normal system use.
You can keep a standby database current with its original database by continuously applying the original archived redo logs to the standby.
You can configure an instance to archive filled redo log files automatically, or you can archive manually. For convenience and efficiency, automatic archiving is usually best. Figure 7-1illustrates how the archiver process (ARC0 in this illustration) writes filled redo log files to the database archived redo log.
If all databases in a distributed database operate in ARCHIVELOGmode, you can perform coordinated distributed database recovery. However, if any database in a distributed database is in NOARCHIVELOGmode, recovery of a global distributed database (to make all databases consistent) is limited by the last full backup of any database operating in NOARCHIVELOGmode.
Figure 7-1 Redo Log File Use in ARCHIVELOG Mode
Description of the illustration admin056.gif
Controlling Archiving
This section describes how to set the archiving mode of the database and how to control the archiving process. The following topics are discussed:
See Also:
your Oracle operating system specific documentation for additional information on controlling archiving modes
Setting the Initial Database Archiving Mode
You set the initial archiving mode as part of database creation in the CREATE DATABASEstatement. Usually, you can use the default of NOARCHIVELOGmode at database creation because there is no need to archive the redo information generated by that process. After creating the database, decide whether to change the initial archiving mode.
If you specify ARCHIVELOGmode, you must have initialization parameters set that specify the destinations for the archive log files (see "Specifying Archive Destinations").
Changing the Database Archiving Mode
To change the archiving mode of the database, use the ALTER DATABASEstatement with the ARCHIVELOGor NOARCHIVELOGclause. To change the archiving mode, you must be connected to the database with administrator privileges (AS SYSDBA).
The following steps switch the database archiving mode from NOARCHIVELOGto ARCHIVELOG:
Shut down the database instance.
SHUTDOWN
An open database must first be closed and any associated instances shut down before you can switch the database archiving mode. You cannot change the mode from ARCHIVELOGto NOARCHIVELOGif any datafiles need media recovery.
Back up the database.
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 NOARCHIVELOGmode and can be used if something goes wrong during the change to ARCHIVELOGmode. See Oracle Database Backup and Recovery Basicsfor information about taking database backups.
Edit the initialization parameter file to include the initialization parameters that specify the destinations for the archive log files (see "Specifying Archive Destinations").
Start a new instance and mount, but do not open, the database.
STARTUP MOUNT
To enable or disable archiving, the database must be mounted but not open.
Change the database archiving mode. Then open the database for normal operations.
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
Shut down the database.
SHUTDOWN IMMEDIATE
Back up the database.
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 NOARCHIVELOGmode.
See Also:
Oracle Real Application Clusters Administrator's Guidefor more information about switching the archiving mode when using Real Application Clusters
Performing Manual Archiving
To operate your database in manual archiving mode, follow the procedure shown in "Changing the Database Archiving Mode ". However, when you specify the new mode in step 5, use the following statement:
ALTER DATABASE ARCHIVELOG MANUAL;
When you operate your database in manual ARCHIVELOGmode, you must archive inactive groups of filled redo log files or your database operation can be temporarily suspended. To archive a filled redo log group manually, connect with administrator privileges. Ensure that the database is mounted but not open. Use the ALTER SYSTEMstatement with the ARCHIVE LOGclause to manually archive filled redo log files. The following statement archives all unarchived log files:
ALTER SYSTEM ARCHIVE LOG ALL;
When you use manual archiving mode, you cannot specify any standby databases in the archiving destinations.
Even when automatic archiving is enabled, you can use manual archiving for such actions as rearchiving an inactive group of filled redo log members to another location. In this case, it is possible for the instance to reuse the redo log group before you have finished manually archiving, and thereby overwrite the files. If this happens, the database writes an error message to the alert file.
Adjusting the Number of Archiver Processes
The LOG_ARCHIVE_MAX_PROCESSESinitialization parameter specifies the number of ARCnprocesses that the database initially invokes. The default is two processes. There is usually no need specify this initialization parameter or to change its default value, because the database 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 ARCnprocesses, you can set the LOG_ARCHIVE_MAX_PROCESSESinitialization parameter to specify up to ten ARCnprocesses to be started at instance startup. The LOG_ARCHIVE_MAX_PROCESSESparameter is dynamic, and can be changed using the ALTER SYSTEMstatement. The database must be mounted but not open. The following statement increases (or decreases) the number of ARCnprocesses currently running:
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=3;
Specifying the Archive Destination
Before you can archive redo logs, you must determine the destination to which you will archive and familiarize yourself with the various destination states. The dynamic performance (V$) views, listed in "Viewing Information About the Archived Redo Log", provide all needed archive information.
The following topics are contained in this section:
Specifying Archive Destinations
You can choose whether to archive redo logs to a single destination or multiplexthem. If you want to archive only to a single destination, you specify that destination in the LOG_ARCHIVE_DESTinitialization parameter. If you want to multiplex the archived logs, you can choose whether to archive to up to ten locations (using the LOG_ARCHIVE_DEST_nparameters) or to archive only to a primary and secondary destination (using LOG_ARCHIVE_DESTand LOG_ARCHIVE_DUPLEX_DEST). The following table summarizes the multiplexing alternatives, which are further described in the sections that follow.
See Also:
Oracle Database Referencefor additional information about the initialization parameters used to control the archiving of redo logs
Oracle Data Guard Concepts and Administrationfor information about using the LOG_ARCHIVE_DEST_ninitialization parameter for specifying a standby destination. There are additional keywords that can be specified with this initialization parameter that are not discussed in this book.
Method 1: Using the LOG_ARCHIVE_DEST_ n Parameter
Use the LOG_ARCHIVE_DEST_nparameter (where nis 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_nusing the keywords explained in the following table:
If you use the LOCATIONkeyword, specify a valid path name for your operating system. If you specify SERVICE, the database translates the net service name through the tnsnames.orafile 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 the database 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_ninitialization parameter:
Use SQL*Plus to shut down the database.
SHUTDOWN
Set the LOG_ARCHIVE_DEST_ninitialization parameter to specify from one to ten archiving locations. The LOCATIONkeyword 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 SERVICEkeyword to specify a valid net service name from the tnsnames.orafile. For example, enter:
LOG_ARCHIVE_DEST_4 = 'SERVICE = standby1'
Optionally, set the LOG_ARCHIVE_FORMATinitialization parameter, using %tto include the thread number as part of the file name, %sto include the log sequence number, and %rto include the resetlogs ID (a timestamp value represented in ub4). Use capital letters (%T, %S, and %R) to pad the file name to the left with zeroes.
Note:
If the COMPATIBLEinitialization parameter is set to 10.0 or higher, the database requires the specification of resetlogs ID (%r) when you include the LOG_ARCHIVE_FORMATparameter. The default for this parameter is operating system dependent. For example, this is the default format for UNIX:
LOG_ARCHIVE_FORMAT=%t_%s_%r.dbf
The incarnation of a database changes when you open it with the RESETLOGSoption. Specifying %rcauses the database to capture the resetlogs ID in the archive log file name, enabling you to more easily perform recovery from a backup of a previous database incarnation. See Oracle Database Backup and Recovery Advanced User's Guidefor more information about this method of recovery.
The following example shows a setting of LOG_ARCHIVE_FORMAT:
LOG_ARCHIVE_FORMAT = arch_%t_%s_%r.arc
This setting will generate archived logs as follows for thread 1; log sequence numbers 100, 101, and 102; resetlogs ID 509210197. The identical resetlogs ID indicates that the files are all from the same database incarnation:
/disk1/archive/arch_1_100_509210197.arc,
/disk1/archive/arch_1_101_509210197.arc,
/disk1/archive/arch_1_102_509210197.arc
/disk2/archive/arch_1_100_509210197.arc,
/disk2/archive/arch_1_101_509210197.arc,
/disk2/archive/arch_1_102_509210197.arc
/disk3/archive/arch_1_100_509210197.arc,
/disk3/archive/arch_1_101_509210197.arc,
/disk3/archive/arch_1_102_509210197.arc
Method 2: Using LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST
To specify a maximum of two locations, use the LOG_ARCHIVE_DESTparameter to specify a primary archive destination and the LOG_ARCHIVE_DUPLEX_DESTto specify an optional secondary archive destination. All locations must be local. Whenever the database archives a redo log, it archives it to every destination specified by either set of parameters.
Perform the following steps the use method 2:
Use SQL*Plus to shut down the database.
SHUTDOWN
Specify destinations for the LOG_ARCHIVE_DESTand LOG_ARCHIVE_DUPLEX_DESTparameter (you can also specify LOG_ARCHIVE_DUPLEX_DESTdynamically using the ALTER SYSTEMstatement). For example, enter:
LOG_ARCHIVE_DEST = '/disk1/archive'
LOG_ARCHIVE_DUPLEX_DEST = '/disk2/archive'
Set the LOG_ARCHIVE_FORMATinitialization parameter as described in step 3for method 1.
Understanding Archive Destination Status
Each archive destination has the following variable characteristics that determine its status:
Valid/Invalid: indicates whether the disk location or service name information is specified and valid
Enabled/Disabled: indicates the availability state of the location and whether the database can use the destination
Active/Inactive: indicates whether there was a problem accessing the destination
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_DESTview.
The characteristics determining a locations status that appear in the view are shown in Table 7-1. Note that for a destination to be used, its characteristics must be valid, enabled, and active.
Table 7-1 Destination Status
The LOG_ARCHIVE_DEST_STATE_n(where nis an integer from 1 to 10) initialization parameter lets you control the availability state of the specified destination (n).
ENABLEindicates that the database can use the destination.
DEFERindicates that the location is temporarily disabled.
ALTERNATEindicates that the destination is an alternate.
The availability state of the destination is DEFER, unless there is a failure of its parent destination, in which case its state becomes ENABLE.
Specifying the Mode of Log Transmission
The two modes of transmitting archived logs to their destination are normal archiving transmissionand standby transmissionmode. 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.
Normal Transmission Mode
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_nor LOG_ARCHIVE_DESTparameters.
It is good practice to move archived redo log files and corresponding database backups from the local disk to permanent inexpensive offline storage media such as tape. A primary value of archived logs is database recovery, so you want to ensure that these logs are safe should disaster strike your primary database.
Standby Transmission Mode
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 synchronized with your source database by automatically applying transmitted archive logs.
To transmit files successfully to a standby database, either ARCnor a server process must do the following:
Recognize a remote location
Transmit the archived logs in conjunction with a remote file server(RFS) process that resides on the remote server
Each ARCnprocess has a corresponding RFS for each standby destination. For example, if three ARCnprocesses are archiving to two standby databases, then Oracle Database establishes six RFS connections.
You transmit archived logs through a network to a remote location by using Oracle Net Services. Indicate a remote archival by specifying a Oracle Net service name as an attribute of the destination. Oracle Database then translates the service name, through the tnsnames.orafile, 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 the database 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 ARCnclient. Essentially, ARCnpushes 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:
Consuming network I/O from the ARCnprocess
Creating file names on the standby database by using the STANDBY_ARCHIVE_DESTparameter
Populating the log files at the remote site
Updating the standby database control file (which Recovery Manager can then use for recovery)
Archived 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:
Oracle Net Services Administrator's Guidefor information about connecting to a remote database using a service name
Managing Archive Destination Failure
Sometimes archive destinations can fail, causing problems when you operate in automatic archiving mode. Oracle Database provides procedures to help you minimize the problems associated with destination failure. These procedures are discussed in the sections that follow:
Specifying the Minimum Number of Successful Destinations
The optional initialization parameterLOG_ARCHIVE_MIN_SUCCEED_DEST=ndetermines the minimum number of destinations to which the database must successfully archive a redo log group before it can reuse online log files. The default value is 1. Valid values for nare 1 to 2 if you are using duplexing, or 1 to 10 if you are multiplexing.
Specifying Mandatory and Optional Destinations
The LOG_ARCHIVE_DEST_nparameter lets you specify whether a destination is OPTIONAL(the default) or MANDATORY. The LOG_ARCHIVE_MIN_SUCCEED_DEST=nparameter uses all MANDATORYdestinations plus some number of nonstandby OPTIONALdestinations to determine whether LGWR can overwrite the online log. The following rules apply:
Omitting the MANDATORYattribute for a destination is the same as specifying OPTIONAL.
You must have at least one local destination, which you can declare OPTIONALor MANDATORY.
When you specify a value for LOG_ARCHIVE_MIN_SUCCEED_DEST=n, Oracle Database will treat at least one local destination as MANDATORY, because the minimum value for LOG_ARCHIVE_MIN_SUCCEED_DESTis 1.
If any MANDATORYdestination fails, including a MANDATORYstandby destination, Oracle Database ignores the LOG_ARCHIVE_MIN_SUCCEED_DESTparameter.
The LOG_ARCHIVE_MIN_SUCCEED_DESTvalue cannot be greater than the number of destinations, nor can it be greater than the number of MANDATORYdestinations plus the number of OPTIONALlocal destinations.
If you DEFERa MANDATORYdestination, and the database overwrites the online log without transferring the archived log to the standby site, then you must transfer the log to the standby manually.
If you are duplexing the archived logs, you can establish which destinations are mandatory or optional by using the LOG_ARCHIVE_DESTand LOG_ARCHIVE_DUPLEX_DESTparameters. The following rules apply:
Any destination declared by LOG_ARCHIVE_DESTis mandatory.
Any destination declared by LOG_ARCHIVE_DUPLEX_DESTis optional if LOG_ARCHIVE_MIN_SUCCEED_DEST = 1and mandatory if LOG_ARCHIVE_MIN_SUCCEED_DEST = 2.
Specifying the Number of Successful Destinations: Scenarios
You can see the relationship between the LOG_ARCHIVE_DEST_nand LOG_ARCHIVE_MIN_SUCCEED_DESTparameters most easily through sample scenarios.
Scenario for Archiving to Optional Local Destinations
In this scenario, you archive to three local destinations, each of which you declare as OPTIONAL. Table 7-2illustrates the possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=nin this case.
Table 7-2 LOG_ARCHIVE_MIN_SUCCEED_DEST Values for Scenario 1
This scenario shows that even though you do not explicitly set any of your destinations to MANDATORYusing the LOG_ARCHIVE_DEST_nparameter, the database must successfully archive to one or more of these locations when LOG_ARCHIVE_MIN_SUCCEED_DESTis set to 1, 2, or 3.
Scenario for Archiving to Both Mandatory and Optional Destinations
Consider a case in which:
You specify two MANDATORYdestinations.
You specify two OPTIONALdestinations.
No destination is a standby database.
Table 7-3shows the possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=n.
Table 7-3 LOG_ARCHIVE_MIN_SUCCEED_DEST Values for Scenario 2
This case shows that the database must archive to the destinations you specify as MANDATORY, regardless of whether you set LOG_ARCHIVE_MIN_SUCCEED_DESTto archive to a smaller number of destinations.
Rearchiving to a Failed Destination
Use the REOPENattribute of the LOG_ARCHIVE_DEST_nparameter to specify whether and when ARCnshould attempt to rearchive to a failed destination following an error. REOPENapplies to all errors, not just OPENerrors.
REOPEN=nsets the minimum number of seconds before ARCnshould try to reopen a failed destination. The default value for nis 300 seconds. A value of 0 is the same as turning off the REOPENattribute; ARCnwill not attempt to archive after a failure. If you do not specify the REOPENkeyword, ARCnwill never reopen a destination following an error.
You cannot use REOPENto specify the number of attempts ARCnshould make to reconnect and transfer archived logs. The REOPENattempt either succeeds or fails.
When you specify REOPENfor an OPTIONALdestination, the database can overwrite online logs if there is an error. If you specify REOPENfor a MANDATORYdestination, the database stalls the production database when it cannot successfully archive. In this situation, consider the following options:
Archive manually to the failed destination.
Change the destination by deferring the destination, specifying the destination as optional, or changing the service.
Drop the destination.
When using the REOPENkeyword, note the following:
ARCnreopens a destination only when startingan archive operation from the beginning of the log file, never duringa current operation. ARCnalways retries the log copy from the beginning.
If you specified REOPEN, either with a specified time the default, ARCnchecks to see whether the time of the recorded error plus the REOPENinterval is less than the current time. If it is, ARCnretries the log copy.
The REOPENclause successfully affects the ACTIVE=TRUEdestination state. The VALIDand ENABLEDstates are not changed.
Controlling Trace Output Generated by the Archivelog Process
Background processes always write to a trace file when appropriate. (See the discussion of this topic in "Monitoring the Database Using Trace Files and the Alert File".) In the case of the archivelog process, you can control the output that is generated to the trace file. You do this by setting the LOG_ARCHIVE_TRACEinitialization parameter 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_TRACEparameter is 0. At this level, the archivelog process generates appropriate alert and trace entries for error conditions.
You can change the value of this parameter dynamically using the ALTER SYSTEMstatement. The database must be mounted but not open. 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:
Oracle Data Guard Concepts and Administrationfor information about using this parameter with a standby database
Viewing Information About the Archived Redo Log
You can display information about the archived redo logs using the following sources:
Dynamic Performance Views
Several dynamic performance views contain useful information about archived redo logs, as summarized in the following table.
For example, the following query displays which 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$DATABASEview:
本文转自
http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10739/archredo.htm
See Also :
Part III, " Automated File and Storage Management "for information about creating an archived redo log that is both created and managed by the Oracle Database server
Oracle Real Application Clusters Administrator's Guidefor information specific to archiving in the Oracle Real Application Clusters environment
What Is the Archived Redo Log?
Oracle Database lets you save filled groups of redo log files to one or more offline destinations, known collectively as the archived redo log, or more simply the archive log. The process of turning 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 filled members of a redo log group. It includes the redo entries and the unique log sequence number of the identical member of the redo log group. For example, if you are multiplexing your redo log, and if group 1 contains identical member files a_log1and b_log1, then the archiver process (ARCn) will archive one of these member files. Should a_log1become corrupted, then ARCncan still archive the identical b_log1. The archived redo log contains a copy of every group created since you enabled archiving.
When the database is running in ARCHIVELOGmode, the log writer process (LGWR) cannot reuse and hence overwrite a redo log group until it has been archived. The background process ARCnautomates archiving operations when automatic archiving is enabled. The database starts multiple archiver processes as needed to ensure that the archiving of filled redo logs does not fall behind.
You can use archived redo logs to:
Recover a database
Update a standby database
Get information about the history of a database using the LogMiner utility
See Also:
The following sources document the uses for archived redo logs:
Oracle Data Guard Concepts and Administrationdiscusses setting up and maintaining a standby database
Oracle Database Utilitiescontains instructions for using the LogMiner PL/SQL package
Choosing Between NOARCHIVELOG and ARCHIVELOG Mode
This section describes the issues you must consider when choosing to run your database in NOARCHIVELOGor ARCHIVELOGmode, and contains these topics:
The choice of whether to enable the archiving of filled groups of 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 ARCHIVELOGmode. The archiving of filled redo log files can require you to perform extra administrative operations.
Running a Database in NOARCHIVELOG Mode
When you run your database in NOARCHIVELOGmode, you disable the archiving of the redo log. The database 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.
NOARCHIVELOGmode protects a database from instance failure but not from media failure. Only the most recent changes made to the database, which are stored in the online redo log groups, are available for instance recovery. If a media failure occurs while the database is in NOARCHIVELOGmode, you can only restore the database to the point of the most recent full database backup. You cannot recover transactions subsequent to that backup.
In NOARCHIVELOGmode you cannot perform online tablespace backups, nor can you use online tablespace backups taken earlier while the database was in ARCHIVELOGmode. To restore a database operating in NOARCHIVELOGmode, you can use only whole database backups taken while the database is closed. Therefore, if you decide to operate a database in NOARCHIVELOGmode, take whole database backups at regular, frequent intervals.
Running a Database in ARCHIVELOG Mode
When you run a database in ARCHIVELOGmode, you enable the archiving of the redo log. The database control file indicates that a group of filled redo log files cannot be reused by LGWR until the group is archived. A filled group becomes available for archiving immediately after a redo log switch occurs.
The archiving of filled groups has these advantages:
A database backup, together with online and archived redo log files, guarantees that you can recover all committed transactions in the event of an operating system or disk failure.
If you keep an archived log, you can use a backup taken while the database is open and in normal system use.
You can keep a standby database current with its original database by continuously applying the original archived redo logs to the standby.
You can configure an instance to archive filled redo log files automatically, or you can archive manually. For convenience and efficiency, automatic archiving is usually best. Figure 7-1illustrates how the archiver process (ARC0 in this illustration) writes filled redo log files to the database archived redo log.
If all databases in a distributed database operate in ARCHIVELOGmode, you can perform coordinated distributed database recovery. However, if any database in a distributed database is in NOARCHIVELOGmode, recovery of a global distributed database (to make all databases consistent) is limited by the last full backup of any database operating in NOARCHIVELOGmode.
Figure 7-1 Redo Log File Use in ARCHIVELOG Mode
Description of the illustration admin056.gif
Controlling Archiving
This section describes how to set the archiving mode of the database and how to control the archiving process. The following topics are discussed:
See Also:
your Oracle operating system specific documentation for additional information on controlling archiving modes
Setting the Initial Database Archiving Mode
You set the initial archiving mode as part of database creation in the CREATE DATABASEstatement. Usually, you can use the default of NOARCHIVELOGmode at database creation because there is no need to archive the redo information generated by that process. After creating the database, decide whether to change the initial archiving mode.
If you specify ARCHIVELOGmode, you must have initialization parameters set that specify the destinations for the archive log files (see "Specifying Archive Destinations").
Changing the Database Archiving Mode
To change the archiving mode of the database, use the ALTER DATABASEstatement with the ARCHIVELOGor NOARCHIVELOGclause. To change the archiving mode, you must be connected to the database with administrator privileges (AS SYSDBA).
The following steps switch the database archiving mode from NOARCHIVELOGto ARCHIVELOG:
Shut down the database instance.
SHUTDOWN
An open database must first be closed and any associated instances shut down before you can switch the database archiving mode. You cannot change the mode from ARCHIVELOGto NOARCHIVELOGif any datafiles need media recovery.
Back up the database.
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 NOARCHIVELOGmode and can be used if something goes wrong during the change to ARCHIVELOGmode. See Oracle Database Backup and Recovery Basicsfor information about taking database backups.
Edit the initialization parameter file to include the initialization parameters that specify the destinations for the archive log files (see "Specifying Archive Destinations").
Start a new instance and mount, but do not open, the database.
STARTUP MOUNT
To enable or disable archiving, the database must be mounted but not open.
Change the database archiving mode. Then open the database for normal operations.
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
Shut down the database.
SHUTDOWN IMMEDIATE
Back up the database.
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 NOARCHIVELOGmode.
See Also:
Oracle Real Application Clusters Administrator's Guidefor more information about switching the archiving mode when using Real Application Clusters
Performing Manual Archiving
To operate your database in manual archiving mode, follow the procedure shown in "Changing the Database Archiving Mode ". However, when you specify the new mode in step 5, use the following statement:
ALTER DATABASE ARCHIVELOG MANUAL;
When you operate your database in manual ARCHIVELOGmode, you must archive inactive groups of filled redo log files or your database operation can be temporarily suspended. To archive a filled redo log group manually, connect with administrator privileges. Ensure that the database is mounted but not open. Use the ALTER SYSTEMstatement with the ARCHIVE LOGclause to manually archive filled redo log files. The following statement archives all unarchived log files:
ALTER SYSTEM ARCHIVE LOG ALL;
When you use manual archiving mode, you cannot specify any standby databases in the archiving destinations.
Even when automatic archiving is enabled, you can use manual archiving for such actions as rearchiving an inactive group of filled redo log members to another location. In this case, it is possible for the instance to reuse the redo log group before you have finished manually archiving, and thereby overwrite the files. If this happens, the database writes an error message to the alert file.
Adjusting the Number of Archiver Processes
The LOG_ARCHIVE_MAX_PROCESSESinitialization parameter specifies the number of ARCnprocesses that the database initially invokes. The default is two processes. There is usually no need specify this initialization parameter or to change its default value, because the database 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 ARCnprocesses, you can set the LOG_ARCHIVE_MAX_PROCESSESinitialization parameter to specify up to ten ARCnprocesses to be started at instance startup. The LOG_ARCHIVE_MAX_PROCESSESparameter is dynamic, and can be changed using the ALTER SYSTEMstatement. The database must be mounted but not open. The following statement increases (or decreases) the number of ARCnprocesses currently running:
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=3;
Specifying the Archive Destination
Before you can archive redo logs, you must determine the destination to which you will archive and familiarize yourself with the various destination states. The dynamic performance (V$) views, listed in "Viewing Information About the Archived Redo Log", provide all needed archive information.
The following topics are contained in this section:
Specifying Archive Destinations
You can choose whether to archive redo logs to a single destination or multiplexthem. If you want to archive only to a single destination, you specify that destination in the LOG_ARCHIVE_DESTinitialization parameter. If you want to multiplex the archived logs, you can choose whether to archive to up to ten locations (using the LOG_ARCHIVE_DEST_nparameters) or to archive only to a primary and secondary destination (using LOG_ARCHIVE_DESTand LOG_ARCHIVE_DUPLEX_DEST). The following table summarizes the multiplexing alternatives, which are further described in the sections that follow.
See Also:
Oracle Database Referencefor additional information about the initialization parameters used to control the archiving of redo logs
Oracle Data Guard Concepts and Administrationfor information about using the LOG_ARCHIVE_DEST_ninitialization parameter for specifying a standby destination. There are additional keywords that can be specified with this initialization parameter that are not discussed in this book.
Method 1: Using the LOG_ARCHIVE_DEST_ n Parameter
Use the LOG_ARCHIVE_DEST_nparameter (where nis 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_nusing the keywords explained in the following table:
| Keyword | Indicates | Example |
|---|---|---|
LOCATION | A local file system location. | LOG_ARCHIVE_DEST_1 = 'LOCATION=/disk1/arc' |
SERVICE | Remote archival through Oracle Net service name. | LOG_ARCHIVE_DEST_2 = 'SERVICE=standby1' |
If you use the LOCATIONkeyword, specify a valid path name for your operating system. If you specify SERVICE, the database translates the net service name through the tnsnames.orafile 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 the database 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_ninitialization parameter:
Use SQL*Plus to shut down the database.
SHUTDOWN
Set the LOG_ARCHIVE_DEST_ninitialization parameter to specify from one to ten archiving locations. The LOCATIONkeyword 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 SERVICEkeyword to specify a valid net service name from the tnsnames.orafile. For example, enter:
LOG_ARCHIVE_DEST_4 = 'SERVICE = standby1'
Optionally, set the LOG_ARCHIVE_FORMATinitialization parameter, using %tto include the thread number as part of the file name, %sto include the log sequence number, and %rto include the resetlogs ID (a timestamp value represented in ub4). Use capital letters (%T, %S, and %R) to pad the file name to the left with zeroes.
Note:
If the COMPATIBLEinitialization parameter is set to 10.0 or higher, the database requires the specification of resetlogs ID (%r) when you include the LOG_ARCHIVE_FORMATparameter. The default for this parameter is operating system dependent. For example, this is the default format for UNIX:
LOG_ARCHIVE_FORMAT=%t_%s_%r.dbf
The incarnation of a database changes when you open it with the RESETLOGSoption. Specifying %rcauses the database to capture the resetlogs ID in the archive log file name, enabling you to more easily perform recovery from a backup of a previous database incarnation. See Oracle Database Backup and Recovery Advanced User's Guidefor more information about this method of recovery.
The following example shows a setting of LOG_ARCHIVE_FORMAT:
LOG_ARCHIVE_FORMAT = arch_%t_%s_%r.arc
This setting will generate archived logs as follows for thread 1; log sequence numbers 100, 101, and 102; resetlogs ID 509210197. The identical resetlogs ID indicates that the files are all from the same database incarnation:
/disk1/archive/arch_1_100_509210197.arc,
/disk1/archive/arch_1_101_509210197.arc,
/disk1/archive/arch_1_102_509210197.arc
/disk2/archive/arch_1_100_509210197.arc,
/disk2/archive/arch_1_101_509210197.arc,
/disk2/archive/arch_1_102_509210197.arc
/disk3/archive/arch_1_100_509210197.arc,
/disk3/archive/arch_1_101_509210197.arc,
/disk3/archive/arch_1_102_509210197.arc
Method 2: Using LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST
To specify a maximum of two locations, use the LOG_ARCHIVE_DESTparameter to specify a primary archive destination and the LOG_ARCHIVE_DUPLEX_DESTto specify an optional secondary archive destination. All locations must be local. Whenever the database archives a redo log, it archives it to every destination specified by either set of parameters.
Perform the following steps the use method 2:
Use SQL*Plus to shut down the database.
SHUTDOWN
Specify destinations for the LOG_ARCHIVE_DESTand LOG_ARCHIVE_DUPLEX_DESTparameter (you can also specify LOG_ARCHIVE_DUPLEX_DESTdynamically using the ALTER SYSTEMstatement). For example, enter:
LOG_ARCHIVE_DEST = '/disk1/archive'
LOG_ARCHIVE_DUPLEX_DEST = '/disk2/archive'
Set the LOG_ARCHIVE_FORMATinitialization parameter as described in step 3for method 1.
Understanding Archive Destination Status
Each archive destination has the following variable characteristics that determine its status:
Valid/Invalid: indicates whether the disk location or service name information is specified and valid
Enabled/Disabled: indicates the availability state of the location and whether the database can use the destination
Active/Inactive: indicates whether there was a problem accessing the destination
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_DESTview.
The characteristics determining a locations status that appear in the view are shown in Table 7-1. Note that for a destination to be used, its characteristics must be valid, enabled, and active.
Table 7-1 Destination Status
| STATUS | Characteristics | Meaning | ||
|---|---|---|---|---|
| Valid | Enabled | Active | ||
VALID | True | True | True | The user has properly initialized the destination, which is available for archiving. |
INACTIVE | False | n/a | n/a | The user has not provided or has deleted the destination information. |
ERROR | True | True | False | An error occurred creating or writing to the destination file; refer to error data. |
FULL | True | True | False | Destination is full (no disk space). |
DEFERRED | True | False | True | The user manually and temporarily disabled the destination. |
DISABLED | True | False | False | The user manually and temporarily disabled the destination following an error; refer to error data. |
BAD PARAM | n/a | n/a | n/a | A parameter error occurred; refer to error data. |
The LOG_ARCHIVE_DEST_STATE_n(where nis an integer from 1 to 10) initialization parameter lets you control the availability state of the specified destination (n).
ENABLEindicates that the database can use the destination.
DEFERindicates that the location is temporarily disabled.
ALTERNATEindicates that the destination is an alternate.
The availability state of the destination is DEFER, unless there is a failure of its parent destination, in which case its state becomes ENABLE.
Specifying the Mode of Log Transmission
The two modes of transmitting archived logs to their destination are normal archiving transmissionand standby transmissionmode. 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.
Normal Transmission Mode
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_nor LOG_ARCHIVE_DESTparameters.
It is good practice to move archived redo log files and corresponding database backups from the local disk to permanent inexpensive offline storage media such as tape. A primary value of archived logs is database recovery, so you want to ensure that these logs are safe should disaster strike your primary database.
Standby Transmission Mode
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 synchronized with your source database by automatically applying transmitted archive logs.
To transmit files successfully to a standby database, either ARCnor a server process must do the following:
Recognize a remote location
Transmit the archived logs in conjunction with a remote file server(RFS) process that resides on the remote server
Each ARCnprocess has a corresponding RFS for each standby destination. For example, if three ARCnprocesses are archiving to two standby databases, then Oracle Database establishes six RFS connections.
You transmit archived logs through a network to a remote location by using Oracle Net Services. Indicate a remote archival by specifying a Oracle Net service name as an attribute of the destination. Oracle Database then translates the service name, through the tnsnames.orafile, 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 the database 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 ARCnclient. Essentially, ARCnpushes 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:
Consuming network I/O from the ARCnprocess
Creating file names on the standby database by using the STANDBY_ARCHIVE_DESTparameter
Populating the log files at the remote site
Updating the standby database control file (which Recovery Manager can then use for recovery)
Archived 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:
Oracle Net Services Administrator's Guidefor information about connecting to a remote database using a service name
Managing Archive Destination Failure
Sometimes archive destinations can fail, causing problems when you operate in automatic archiving mode. Oracle Database provides procedures to help you minimize the problems associated with destination failure. These procedures are discussed in the sections that follow:
Specifying the Minimum Number of Successful Destinations
The optional initialization parameterLOG_ARCHIVE_MIN_SUCCEED_DEST=ndetermines the minimum number of destinations to which the database must successfully archive a redo log group before it can reuse online log files. The default value is 1. Valid values for nare 1 to 2 if you are using duplexing, or 1 to 10 if you are multiplexing.
Specifying Mandatory and Optional Destinations
The LOG_ARCHIVE_DEST_nparameter lets you specify whether a destination is OPTIONAL(the default) or MANDATORY. The LOG_ARCHIVE_MIN_SUCCEED_DEST=nparameter uses all MANDATORYdestinations plus some number of nonstandby OPTIONALdestinations to determine whether LGWR can overwrite the online log. The following rules apply:
Omitting the MANDATORYattribute for a destination is the same as specifying OPTIONAL.
You must have at least one local destination, which you can declare OPTIONALor MANDATORY.
When you specify a value for LOG_ARCHIVE_MIN_SUCCEED_DEST=n, Oracle Database will treat at least one local destination as MANDATORY, because the minimum value for LOG_ARCHIVE_MIN_SUCCEED_DESTis 1.
If any MANDATORYdestination fails, including a MANDATORYstandby destination, Oracle Database ignores the LOG_ARCHIVE_MIN_SUCCEED_DESTparameter.
The LOG_ARCHIVE_MIN_SUCCEED_DESTvalue cannot be greater than the number of destinations, nor can it be greater than the number of MANDATORYdestinations plus the number of OPTIONALlocal destinations.
If you DEFERa MANDATORYdestination, and the database overwrites the online log without transferring the archived log to the standby site, then you must transfer the log to the standby manually.
If you are duplexing the archived logs, you can establish which destinations are mandatory or optional by using the LOG_ARCHIVE_DESTand LOG_ARCHIVE_DUPLEX_DESTparameters. The following rules apply:
Any destination declared by LOG_ARCHIVE_DESTis mandatory.
Any destination declared by LOG_ARCHIVE_DUPLEX_DESTis optional if LOG_ARCHIVE_MIN_SUCCEED_DEST = 1and mandatory if LOG_ARCHIVE_MIN_SUCCEED_DEST = 2.
Specifying the Number of Successful Destinations: Scenarios
You can see the relationship between the LOG_ARCHIVE_DEST_nand LOG_ARCHIVE_MIN_SUCCEED_DESTparameters most easily through sample scenarios.
Scenario for Archiving to Optional Local Destinations
In this scenario, you archive to three local destinations, each of which you declare as OPTIONAL. Table 7-2illustrates the possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=nin this case.
Table 7-2 LOG_ARCHIVE_MIN_SUCCEED_DEST Values for Scenario 1
| Value | Meaning |
|---|---|
| 1 | The database can reuse log files only if at least one of the OPTIONAL destinations succeeds. |
| 2 | The database can reuse log files only if at least two of the OPTIONAL destinations succeed. |
| 3 | The database can reuse log files only if all of the OPTIONAL destinations succeed. |
| 4 or greater | ERROR: The value is greater than the number of destinations. |
This scenario shows that even though you do not explicitly set any of your destinations to MANDATORYusing the LOG_ARCHIVE_DEST_nparameter, the database must successfully archive to one or more of these locations when LOG_ARCHIVE_MIN_SUCCEED_DESTis set to 1, 2, or 3.
Scenario for Archiving to Both Mandatory and Optional Destinations
Consider a case in which:
You specify two MANDATORYdestinations.
You specify two OPTIONALdestinations.
No destination is a standby database.
Table 7-3shows the possible values for LOG_ARCHIVE_MIN_SUCCEED_DEST=n.
Table 7-3 LOG_ARCHIVE_MIN_SUCCEED_DEST Values for Scenario 2
| Value | Meaning |
|---|---|
| 1 | The database ignores the value and uses the number of MANDATORY destinations (in this example, 2). |
| 2 | The database can reuse log files even if no OPTIONAL destination succeeds. |
| 3 | The database can reuse logs only if at least one OPTIONAL destination succeeds. |
| 4 | The database can reuse logs only if both OPTIONAL destinations succeed. |
| 5 or greater | ERROR: The value is greater than the number of destinations. |
This case shows that the database must archive to the destinations you specify as MANDATORY, regardless of whether you set LOG_ARCHIVE_MIN_SUCCEED_DESTto archive to a smaller number of destinations.
Rearchiving to a Failed Destination
Use the REOPENattribute of the LOG_ARCHIVE_DEST_nparameter to specify whether and when ARCnshould attempt to rearchive to a failed destination following an error. REOPENapplies to all errors, not just OPENerrors.
REOPEN=nsets the minimum number of seconds before ARCnshould try to reopen a failed destination. The default value for nis 300 seconds. A value of 0 is the same as turning off the REOPENattribute; ARCnwill not attempt to archive after a failure. If you do not specify the REOPENkeyword, ARCnwill never reopen a destination following an error.
You cannot use REOPENto specify the number of attempts ARCnshould make to reconnect and transfer archived logs. The REOPENattempt either succeeds or fails.
When you specify REOPENfor an OPTIONALdestination, the database can overwrite online logs if there is an error. If you specify REOPENfor a MANDATORYdestination, the database stalls the production database when it cannot successfully archive. In this situation, consider the following options:
Archive manually to the failed destination.
Change the destination by deferring the destination, specifying the destination as optional, or changing the service.
Drop the destination.
When using the REOPENkeyword, note the following:
ARCnreopens a destination only when startingan archive operation from the beginning of the log file, never duringa current operation. ARCnalways retries the log copy from the beginning.
If you specified REOPEN, either with a specified time the default, ARCnchecks to see whether the time of the recorded error plus the REOPENinterval is less than the current time. If it is, ARCnretries the log copy.
The REOPENclause successfully affects the ACTIVE=TRUEdestination state. The VALIDand ENABLEDstates are not changed.
Controlling Trace Output Generated by the Archivelog Process
Background processes always write to a trace file when appropriate. (See the discussion of this topic in "Monitoring the Database Using Trace Files and the Alert File".) In the case of the archivelog process, you can control the output that is generated to the trace file. You do this by setting the LOG_ARCHIVE_TRACEinitialization parameter to specify a trace level. The following values can be specified:
| Trace Level | Meaning |
|---|---|
| 0 | Disable archivelog tracing. This is the default. |
| 1 | Track archival of redo log file. |
| 2 | Track archival status for each archivelog destination. |
| 4 | Track archival operational phase. |
| 8 | Track archivelog destination activity. |
| 16 | Track detailed archivelog destination activity. |
| 32 | Track archivelog destination parameter modifications. |
| 64 | Track ARCn process state activity. |
| 128 | Track FAL (fetch archived log) server related activities. |
| 256 | Supported in a future release. |
| 512 | Tracks asynchronous LGWR activity. |
| 1024 | RFS physical client tracking. |
| 2048 | ARCn/RFS heartbeat tracking. |
| 4096 | Track real-time apply |
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_TRACEparameter is 0. At this level, the archivelog process generates appropriate alert and trace entries for error conditions.
You can change the value of this parameter dynamically using the ALTER SYSTEMstatement. The database must be mounted but not open. 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:
Oracle Data Guard Concepts and Administrationfor information about using this parameter with a standby database
Viewing Information About the Archived Redo Log
You can display information about the archived redo logs using the following sources:
Dynamic Performance Views
Several dynamic performance views contain useful information about archived redo logs, as summarized in the following table.
| Dynamic Performance View | Description |
|---|---|
V$DATABASE | Identifies whether the database is in ARCHIVELOG or NOARCHIVELOG mode and whether MANUAL (archiving mode) has been specified. |
V$ARCHIVED_LOG | Displays historical archived log information from the control file. If you use a recovery catalog, the RC_ARCHIVED_LOG view contains similar information. |
V$ARCHIVE_DEST | Describes the current instance, all archive destinations, and the current value, mode, and status of these destinations. |
V$ARCHIVE_PROCESSES | Displays information about the state of the various archive processes for an instance. |
V$BACKUP_REDOLOG | Contains information about any backups of archived logs. If you use a recovery catalog, the RC_BACKUP_REDOLOG contains similar information. |
V$LOG | Displays all 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 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$DATABASEview:
本文转自
http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10739/archredo.htm
487
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
