This module describes the database archiving mode. In addition, configuration of manual and automatic archiving are described.
This module discusses the following:
Move your mouse over this icon to show all screenshots.
You can also move your mouse over each individual icon to see only the screenshot
associated with it.
There are two things you must consider when you think of "archiving" in your database:
|
The database archiving mode: ARCHIVELOG or NOARCHIVELOG | |
|
The actual archiving of the redo log files if the database is in ARCHIVELOG mode | |
"Archiving" is defined as the operation in which the archiver background process copies filled online redo log files to offline destinations. An offline copy of an online redo log is called an archived redo log. You must operate the database in ARCHIVELOG mode to archive redo log files.
First, let's look at the database archiving mode. The database mode can be ARCHIVELOG or NOARCHIVELOG. By default, the database is created in NOARCHIVELOG mode.
You can verify the database archiving mode by querying the V$DATABASE dynamic view or issuing the ARCHIVE LOG LIST command.
You can query V$DATABASE as follows:
| 1. |
Invoke SQL*Plus. Connect as a user with privileges to query dynamic views.
|
| 2. |
Query the V$DATABASE view: SELECT log_mode FROM v$database;
|
You can use the ARCHIVE LOG LIST command as follows:
| 1. |
Invoke SQL*Plus. Connect as a user with SYSDBA privileges.
|
| 2. |
Use the ARCHIVE LOG LIST command: ARCHIVE LOG LIST;
|
Note: Oracle Enterprise Manager 9.2 was used in the examples.
| 1. |
Select START > Programs > Oracle > OraHome92 > Enterprise Manager Console. Select Launch Standalone and click OK.
|
| 2. |
Expand Databases. Expand your database. Expand Instance and select Configuration. You can see the database archiving mode on the General page:
|
If your database is operating in NOARCHIVELOG mode, then archiving of the online redo log is not required. As soon as a filled redo log group becomes inactive, the group is available for reuse by the log writer process. When your database is in this mode it is protected only from instance failure, not from media failure. Only the most recent changes made to the database, stored in the online redo log files, are available for crash or instance recovery. These changes are sufficient for crash or instance recovery because the log writer process will not overwrite an online log that may be needed until its changes have been recorded in the data files. However, it will not be possible to perform media recovery by applying archived redo logs because they will not be created.
In ARCHIVELOG mode, the archiving of the online redo log is enabled. Information in the control file indicates that the log writer process cannot reuse a group of filled online redo log files until the group has been archived. ARCHIVELOG mode permits complete recovery from disk failure as well as instance failure, because all changes made to the database are permanently saved in an archived redo log. These redo log files are used with backups of your data files to perform media recovery.
Refer to the Changing the Database Archiving Mode module for instructions on how to change your database from NOARCHIVELOG mode to ARCHIVELOG mode.
When your database is operating in ARCHIVELOG mode, the filled online redo log files must be archived before the log writer process can reuse them. This archiving can be performed automatically by the archiver process or manually by issuing an ALTER SYSTEM command. In most cases, you should configure automatic archiving.
You can request automatic archiving at instance startup by setting the LOG_ARCHIVE_START initialization parameter. The number of archiver processes (ARCn) specified by LOG_ARCHIVE_MAX_PROCESSES will be started during instance startup.
The LOG_ARCHIVE_DEST_n (LOG_ARCHIVE_DEST for non-Enterprise Edition users) and LOG_ARCHIVE_FORMAT initialization parameters determine the location and naming of the archived redo log files.
If you are using a text initialization parameter file, you must set the LOG_ARCHIVE_START parameter to TRUE and restart your instance.
If you are using a server parameter file, you can configure automatic archiving at instance startup as follows:
| 1. |
Invoke SQL*Plus and connect as a user with SYSDBA privileges.
|
| 2. |
Issue the ALTER SYSTEM command: ALTER SYSTEM SET log_archive_start=true SCOPE=SPFILE;
|
This value will take effect the next time you start your instance.
You can also start automatic archiving manually by issuing the ALTER SYSTEM command. This does not change the value of the LOG_ARCHIVE_START initialization parameter. This only starts the archiver process(es) for the current instance.
| 1. |
Invoke SQL*Plus.
|
| 2. |
Issue the ALTER SYSTEM command: ALTER SYSTEM ARCHIVE LOG START;
|
You can perform manual archiving by issuing the ALTER SYSTEM command. However, if you choose to perform manual archiving you will need to monitor the filling of the online redo log file groups so that you can archive them on a timely basis. If you fail to archive the filled online redo log file before the log writer process needs to write to it again, database operation will be suspended temporarily while waiting for you to do so.
The manual archiving option is provided so that you can:
|
Archive a group when automatic archiving has been stopped because of a problem (for example, the offline storage device specified as the archived redo log destination has experienced a failure or become full) | |
|
Archive a group in a nonstandard fashion (for example, archive one group to one offline storage device, the next group to a different offline storage device, and so on) | |
|
Re-archive a group if the original archived version is lost or damaged | |
Move your mouse over this icon to hide all screenshots