REISSUE THE SECOND QUERY IN STEP 10 TO CONFIRM THAT THE STATUS OF ALL YOUR LOG FILE GROUP MEMBERS IS NOW NULL

12. Reissue the second query in Step 10 to confirm that the status of all your log file group members is now null.

Archivelog Mode and the Archiver Process

Oracle guarantees that your database is never corrupted by any instance failure, through the use of the online redo log files to repair any inconsistencies caused by an instance failure. This is automatic, and unavoidable, no matter what caused the failure: perhaps a power cut, rebooting the server machine, or issuing a SHUTDOWN ABORT command. But to guarantee no loss of data following a media failure, it is necessary to have a record of all changes applied to the database since the last backup of the database; this is not enabled by default.The online redo log files are overwritten as log switches occur; the transition to archivelog mode ensures that no online redo log file group is overwritten unless it has been copied as an archive log file first. Thus there will be a series of archive log files that represent a complete history of all changes ever applied to the database. If a datafile is damaged at any time, it will then be possible to restore a backup of the datafile and apply the changes from the archive log redo stream to bring it up-to-date.By default, a database is created in noarchivelog mode; this means that online redo log files are overwritten by log switches with no copy being made first. It is still impossible to corrupt the database, but data could be lost if the datafiles are damaged by media failure. Once the database is transitioned to archivelog mode, it is impossible to lose data as well—provided that all the archive log files generated since the last backup are available.Once a database is converted to archivelog mode, a new background process will start, automatically. This is the archiver process, ARCn. By default Oracle will start four of these processes (named ARC0, ARC1, ARC2, and ARC3), but you can have up to thirty. In earlier releases of the database it was necessary to start this process either with a SQL*Plus command or by setting the initialization parameter LOG_ARCHIVE_START, but an 11g instance will automatically start the archiver if the database is in archivelog mode.TIP In archivelog mode, recovery is possible with no loss of data up to and including the last commit. Most production databases are run in archivelog mode.The archiver will copy the online redo log files to an archive log file after each log switch, deriving a unique name each time, thus generating a continuous chain of log files that can be used for recovering a backup. The name and location of these archive log files is controlled by initialization parameters. For safety the archive log files can and should be multiplexed, just as the online log files can be multiplexed, but eventually they should be migrated to offline storage, such as a tape library. The Oracle instance takes care of creating the archive logs with the ARCn process, but the migration to tape must be controlled by the DBA, either through operating system commands or by using the recovery manager utility RMAN (described in later chapters) or another third-party backup software package.The transition to archivelog mode can be done only while the database is in MOUNT mode after a clean shutdown, and it must be done by a user with a SYSDBA connection. It is also necessary to set the initialization parameters that control the names and locations of the archive logs generated. Clearly, these names must be unique, or archive logs could be overwritten by other archive logs. To ensure unique filenames, it is possible to embed variables such as the log switch sequence number in the archive log filenames (see Table 14-3).The minimum archiving necessary to ensure that recovery from a restored backup will be possible is to set one archive destination. But for safety, it will usually be a requirement to multiplex the archive log files by specifying two or more destinations, ideally on different disks served by different controllers.

Variable

Description

%d

A unique database identifier, necessary if multiple databases are being

archived to the same directories.

%t

The thread number, visible as the THREAD# column in V$INSTANCE.

This is not significant, except in a RAC database.

%r

The incarnation number. This is important if an incomplete recovery has

been done, as described in Chapters 16 and 18.

%s

The log switch sequence number. This will guarantee that the archives

from any one database do not overwrite each other.

Table 14-3

Variables That May Be Used to Embed Unique Values in Archive Log File Names

From 9i onward, it is possible to specify up to ten archive destinations, giving you ten copies of each filled online redo log file. This is perhaps excessive for safety. One archive destination? Good idea. Two destinations? Sure, why not. But ten? This is to do with Data Guard. For the purposes of this book and the OCP exam, an archive log destination will always be a directory on the machine hosting the database, and two destinations on local disks will usually be sufficient. But the destination can be an Oracle Net alias, specifying the address of a listener on a remote computer. This is the key to zero data loss: the redo stream can be shipped across the network to a remote database, where it can be applied to give a real-time backup. Furthermore, the remote database can (if desired) be configured and opened as a data warehouse, meaning that all the query processing can be offloaded from the primary database to a secondary database optimized for such work.PART III