By default, Oracle logs all changes made to the database. The generation of redo logs adds a certain amount of overhead. You can suppress redo log generation to speed up specific operations, but doing so means the operation in question won’t be logged in the redo logs and youwill not be able to recover that operation in the event of a failure.
If you do decide to suppress redo logging for certain operations, you would include the NOLOGGING keyword in the SQL statement for the operation. (Note that prior to Oracle8, the keyword was UNRECOVERABLE.) If a failure occurred during the oper-ation, youwould need to repeat the operation. For example, youmight build an index on a table without generating redo information. In the event that a database failure occurs and the database is recovered, the index will not be re-created because it wasn’t logged. You’d simply execute the script originally intended to create the index again.
Deploying Physical Components | 43 To simplify operations in the event of a failure, we recommend that you always take a backup after an unlogged operation if you cannot afford to lose the object created by the operation or youcannot repeat the operation for some reason. In addition to using the NOLOGGING keyword in certain commands, you can also mark a table or an entire tablespace with the NOLOGGING attribute. This will suppress redo information for all applicable operations on the table or for all tables in the tablespace.
Multiplexing redo log files
Oracle defines specific terminology to describe how it manages redo logs. Each Ora-cle instance uses athreadof redo to record the changes it makes to the database. A thread of redo is composed of redo log groups, which are composed of one or more redo log members.
Logically, youcan think of a redo log group as a single redo log file. However, Ora-cle allows youto specify multiple copies of a redo log to protect the all-important integrity of the redo log. By creating multiple copies of each redo log file, you pro-tect the redo log file from disk failure and other types of disasters.
Figure 2-5 illustrates a thread of redo with groups and members. The figure shows two members per group, with each redo log mirrored.
Figure 2-5. A thread of redo
member 1 member 2
Group 1
member 1 member 2
Group 2
member 1 member 2
Group 3
Members in a group are identical
=
=
=
44 | Chapter 2: Oracle Architecture
When multiple members are in a redo log group, Oracle maintains multiple copies of the redo log files. The same arguments used for multiplexing of control files apply here. However, though you can rebuild the static part of a control file if you lose it, there is no way to reproduce a lost redo log file. So, be sure to have multiple copies of the redo file. Simple redundant disk protection is not sufficient for cases in which human error results in the corruption or deletion of a redo log file.
Oracle writessynchronouslyto all redo log members. Oracle will wait for confirma-tion that all copies of the redo log have been successfully updated on disk before the redo write is considered done. If youput one copy on a fast or lightly loaded disk, and one copy on a slower or busier disk, your performance will be constrained by the slower disk. Oracle has to guarantee that all copies of the redo log file have been suc-cessfully updated to avoid losing data.
Consider what could happen if Oracle were to write multiple redo logs asynchro-nously, writing to a primary log and then updating the copies later in the background.
If a failure occurs that brings the system down and damages the primary log, Oracle might not have completed updating all the logs. At this point you have committed transactions that are lost—the primary log that recorded the changes made by the transactions is gone, and the copies of the log are not yet up to date with those changes. To prevent this from occurring, Oracle always waits until all copies of the redo log have been updated.
How Oracle uses the redo logs
Once Oracle fills one redo log file, it automatically begins to use the next log file.
When the server cycles through all the available redo log files, it returns to the first one and reuses it. Oracle keeps track of the different redo logs by using a redo log sequence number. This sequence number is recorded inside the redo log files as they are used.
To understand the concepts of redo log filenames and redo log sequence numbers, consider three redo log files calledredolog1.log,redolog2.log, andredolog3.log. The first time Oracle uses them the redo log sequence numbers for each will be 1, 2, and 3, respectively. When Oracle returns to the first redo log—redolog1.log—it will reuse it and assign it a sequence number of 4. When it moves toredolog2.log, it will initial-ize that file with a sequence number of 5.
Remember that the operating system uses the redo log file to identify the physical file, while Oracle uses the redo log file sequence number to determine the order in which the logs were filled and cycled. Because Oracle automatically reuses redo log files, the name of the redo log file is not necessarily indicative of its place in the redo log file sequence.
Figure 2-6 illustrates the filling and cycling of redo logs.
Deploying Physical Components | 45
Naming conventions for redo logs
The operating system names for the various files that make up a database are very important—at least to humans, who sometimes have to identify these files by their names. If you are not using Oracle Managed Files, you should use naming conven-tions that capture the purpose and some critical details about the nature of the file.
Here’s one possible convention for the names of the actual redo log files shown in Figure 2-6:
redog1m1.log, redog1m2.log, ...
Theredoprefix and.logsuffixes indicate that this is redo log information. Theg1m1 andg1m2character strings capture the group and member numbers. This convention is only an example; it’s best to set conventions that youfind meaningful and stick to them.
Archived redo logs
Youmay be wondering how to avoid losing the critical information in the redo log when Oracle cycles over a previously used redo log.
Figure 2-6. Cycling redo logs
redog1m1.log redog1m2.log
Group 1
redog2m1.log redog2m2.log
Seq# =1
Seq# =2
Seq# =3
redog3m1.log redog3m2.log
Seq# =4
Group 2
Group 3
Sequence number advances as logs fill and cycle
=
=
=
46 | Chapter 2: Oracle Architecture
There are actually two ways to address this. The first is quite simple: you don’t avoid losing the information and you suffer the consequences in the event of a failure. You will lose the history stored in the redo file when it is overwritten. If a failure occurs that damages the datafiles, youmust restore the entire database to the point in time when the last backup occurred. Since no redo log history exists to reproduce the changes made since the last backup occurred, you will lose the effects of those changes. Very few Oracle shops make this choice, because the inability to recover to the point of failure is unacceptable—it results in lost work.
The second and more practical way to address the issue is to archive the redo logs as they fill. To understand archiving redo logs, you must first understand that there are actually two types of redo logs for Oracle:
Online redo logs
The operating system files that Oracle cycles through to log the changes made to the database
Archived redo logs
Copies of the filled online redo logs made to avoid losing redo data as the online redo logs are overwritten
An Oracle database can run in one of two modes with respect to archiving redo logs:
NOARCHIVELOG
As the name implies, no redo logs are archived. As Oracle cycles through the logs, the filled logs are reinitialized and overwritten, which erases the history of the changes made to the database. This mode essentially has the disadvantage mentioned above, where a failure could lead to unrecoverable data.
Choosing not to archive redo logs significantly reduces your options for data-base backups, as we’ll discuss in Chapter 11, and is not advised by Oracle.
ARCHIVELOG
When Oracle rolls over to a new redo log, it archives the previous redo log. To prevent gaps in the history, a given redo log cannot be reused until it is success-fully archived. The archived redo logs, plus the online redo logs, provide a complete history of all changes made to the database. Together, they allow Ora-cle to recover all committed transactions up to the exact time a failure occurred.
Operating in this mode enables tablespace and datafile backups.
The internal sequence numbers discussed earlier act as the guide for Oracle while it is using redo logs and archived redo logs to restore a database.
ARCHIVELOG mode and automatic archiving
Starting with Oracle Database 10g, automatic archiving for an Oracle database is enabled with the following SQL command:
ALTER DATABASE ARCHIVELOG
Deploying Physical Components | 47 If the database is in ARCHIVELOG mode, Oracle marks the redo logs for archiving as it fills them. The full log files must be archived before they can be reused. The ALTER DATABASE ARCHIVELOG command will by default turn on automatic archiving and the archivers are started.
Prior to Oracle Database 10g, log files marked as ready for archiving did not mean they would be automatically archived. You also needed to set a parameter in the ini-tialization file with the syntax:
LOG_ARCHIVE_START = TRUE
Setting this parameter started an Oracle process to copy a full redo log to the archive log destination.
The archive log destination and the format for the archived redo log names are specified using two additional parameters, LOG_ARCHIVE_DEST and LOG_
ARCHIVE_FORMAT. A setting such as the following:
LOG_ARCHIVE_DEST = C:\ORANT\DATABASE\ARCHIVE
specifies the directory to which Oracle writes the archived redo log files, and:
LOG_ARCHIVE_FORMAT = ORCL%t_%s_%r.arc
defines the format Oracle will use for the archived redo log filenames. In this case, the filenames will begin withORCLand will end with .arc. The parameters for the for-mat wildcards are:
%t
Include thread number as part of the filename
%s
Include log sequence number as part of the filename
%r
Include resetlogs ID as part of the filename
If you want the archived redo log filenames to include the thread number, log sequence number and resetlogs ID with the numbers zero-padded, capitalize the parameters and set:
LOG_ARCHIVE_FORMAT = "ORCL%T_%S_%R.arc"
Since the initialization file is read when an Oracle instance is started, changes to these parameters do not take effect until an instance is stopped and restarted.
Remember, though, that turning on automatic archiving does not put the database in ARCHIVELOG mode. Similarly, placing the database in ARCHIVELOG mode does not enable the automatic archiving process.
You should also make sure that the archive log destination has enough room for the logs Oracle will automatically write to it. If the archive log file destination is full, Oracle will hang since it can’t archive additional redo log files.
48 | Chapter 2: Oracle Architecture
Figure 2-7 illustrates redo log use with archiving enabled.
The archived redo logs are critical for database recovery. Just as you can duplex the online redo logs, youcan also specify multiple archive log destinations. Oracle will copy filled redo logs to specified destinations. Youcan also specify whether all cop-ies must succeed or not. The initialization parameters for this functionality are as follows:
LOG_ARCHIVE_DUPLEX_DEST
Specifies an additional location for redundant redo logs.
LOG_ARCHIVE_MIN_SUCCEED_DEST
Indicates whether the redo log must be successfully written to one or all of the locations. Valid values are 1 through 10 if multiplexing and 1 or 2 if duplexing.
See your Oracle documentation for the additional parameters and views that enable and control this functionality.