0513-0516

Previous Table of Contents Next

Page 513

Figure 22.3.
Oracle redo logs.

NOTE

The more information the database processes, the more often the redo logs are cycled. You can control this to a certain extent by the size and the number of the redo logs. Even so, don't overlook this point when you deal with backup and recovery procedures.

Archive Logs

Consider this disaster scenario: You encounter an internal error that causes a running Oracle RDBMS instance to terminate abnormally. While attempting to bring up the database, you discover that a media failure has occurred on the disk that contains the SYSTEM tablespace. The last backup of the system occurred more than four days ago, and the redo logs have cycled several times since then. Oracle cannot do the necessary recovery from its redo logs to mount and open the database. What do you do?

Although extreme, scenarios like this one aided Oracle in developing online redo log archiving. All Oracle instances, by default or by design, run in Archive Log mode or in NOARCHIVELOG mode. (See Figure 22.4.) Each mode has its advantages and disadvantages.

Page 514

Figure 22.4.
Archive Log mode.

Archive Log Mode

A database running in Archive Log mode functions exactly like one in NOARCHIVELOG mode. The only exception occurs when the database completely fills one redo log and begins to write information to the next. If the redo log contains information from a previous cycle ”which is true in all cases except the first cycle ”an offline copy of the redo log is made. After this copy is made, the redo log is emptied and the database resumes its normal processing by writing information to the redo log. This enables you to recover a database by using the last backup even if it precedes the earliest information in the redo logs. Note, however, that the offline redo logs must be physically accessible to the RDBMS.

Offline redo logs, commonly called archive logs, are simple in concept, but involve many overhead considerations, which the administrator must decide prior to implementation. Some concerns, such as the volume of transactions processed by the database, affect others, such as how large to make the archive destination and whether to use automatic or manual archiving.

By default, the Oracle RDBMS instance runs in NOARCHIVELOG mode. To determine what mode a database instance is currently running in, issue the archivelog list command from within the Oracle Server*Manager. For example:

 % svrmgrl SVRMGR> connect internal Connected. SVRMGR> archive log list Database log mode             No Archive Mode Automatic Archival            Disabled Automatic Destination         $ORACLE_BASE/admin//norm/arch/arch.log Oldest online log sequence    2088 Current log sequence          2093 

To set the archive mode of a database, the database must be mounted but not open. After the database is in this state, the DBA needs only to issue the alter database archivelog or alter database noarchivelog command from Oracle Server*Manager. In the following code, the

Page 515

DBA mounts a database that has been shut down normally, changes the database to Archive Log mode, and completes the startup by opening the database:

 % svrmgrl SVRMGR> connect internal Connected to an idle instance SVRMGR> startup mount ORACLE instance started Total System Global Area        95243632 bytes Fixed Size                         46384 bytes Variable Size                   70588480 bytes Database Buffers                24576000 bytes Redo Buffers                       32768 bytes Database mounted. SVRMGR> alter database archivelog; Statement processed. SVRMGR> alter database open; Statement processed. 

The database runs in ARCHIVELOG mode until the DBA disables it. Even abnormal termination of the database instance or an instance shutdown or startup does not take the database out of Archive Log mode. This is because the information about whether the database is in Archive Log mode is stored in the instance's control files, along with other crucial database information.

Parameters within the INIT.ORA parameter file control various aspects of the archive process. They are

 LOG_ARCHIVE_BUFFER_SIZE LOG_ARCHIVE_BUFFERS LOG_ARCHIVE_DEST LOG_ARCHIVE_FORMAT LOG_ARCHIVE_START 

The LOG_ARCHIVE_BUFFER_SIZE and LOG_ARCHIVE_BUFFERS parameters are useful primarily in database tuning.

The LOG_ARCHIVE_DEST parameter specifies the output location (such as /var/offline) or device (such as /dev/rmt/0hc) where the archive logs will be written. It must include a filename as part of the parameter ”for example, /u10/admin/norm/arch/redo.

LOG_ARCHIVE_FORMAT specifies the format, or mask, used when writing archive logs to the location specified in LOG_ARCHIVE_DEST. Here is a brief list:

%s Log sequence number
%S Log sequence number (zero padded )
%t Thread number
%T Thread number (zero padded)

Page 516

The value of LOG_ARCHIVE_START is either TRUE or FALSE. A value of TRUE indicates that automatic archiving should be used, and FALSE indicates manual archiving.

The values of these parameters vary among operating systems and environments. The DBA should configure the settings so that they best suit the database environment.

If archiving is not successful, the database suspends further operations, including SELECT and CONNECT, until the DBA takes corrective action. The rationale for this is simple: Because all the data is needed for recovery in ARCHIVELOG mode, Oracle stops operating until it can successfully retain the data. It is important, therefore, to address the issues of the size and availability of the archive destination before you place a database in ARCHIVELOG mode.

If users report errors from the database that deal with archiving, one of the quickest and best sources of information on the error is the ALERT.LOG file, whose location is indicated by the BACKGROUND_DUMP_DEST parameter in the INIT.ORA parameter file. The ALERT.LOG file records all major activity within the database. The following code contains several lines extracted from an actual ALERT.LOG file that a DBA might see in the event of a problem:

 Beginning database checkpoint by background Thread 1 advanced to log sequence 1760     Current log# 1 seq# 1760 mem# 0: /u09/oradata/norm/redolb.log     Current log # 1 seq# 1760 mem# 0: /u16/oradata/norm/redo1c.log Thu Jun  8 10:21:57 1995 ARCH: Archival stopped, error occurred.  Will continue retrying Thu Jun  8 10:21:57 1995 ORACLE instance norm - Archival Error Thu Jun  8 10:21:57 1995 ORA-00255: error archivelog log 2 of thread 1, sequence # 1759 ORA-00312: online log 2 thread 1: `/u09/oradata/norm/redo02a.log' ORA-00312: online log 2 thread 1: `/u16/oradata/norm/redo02b.log' ORA-00272: error writing archive log ARCH:   ORA-00255: error archiving log 2 of thread 1, sequence # 1759 ORA-00312: online log 2 thread 1: `/u09/oradata/norm/redo2a.log' ORA-00312: online log 2 thread 1: `/u16/oradata/norm/redo2b.log' ORA-00272: error writing archive log Thu Jun  8 10:22:07 1995 Completed database checkpoint by background Thu Jun  8 10:24:45 1995 Beginning database checkpoint by background 

Common problems that you might encounter when you work with archiving include

• Insufficient storage space to write the log
• Media failures or other events that render the physical device unavailable
• Conflicting archive log names
• Abnormal termination of the ARCH process that did not subsequently terminate the rest of the background processes

Conflicting archive log names are rare. They generally occur when two or more instances write to the same file system and directory with the same naming convention.

Previous Table of Contents Next