|Oracle7 Server Administrator's Guide||
For more information archiving the redo log, see Chapter 22.
This chapter contains several references to Oracle Server Manager. For more information about performing specific tasks using Server Manager/GUI or Server Manager/LineMode, see the Oracle7 Server Manager User's Guide.
Online redo log files are used in a cyclical fashion; for example, if two files constitute the online redo log, the first file is filled, the second file is filled, the first file is reused and filled, the second file is reused and filled, and so on. Each time a file is filled, it is assigned a log sequence number to identify the set of redo entries.
This section describes guidelines you should consider when configuring a database instance's online redo log, and includes the following topics:
To avoid losing a database due to a single point of failure, Oracle can maintain multiple sets of online redo log files. A multiplex online redo log consists of copies of online redo log files physically located on separate disks; changes made to one member of the group are made to all members. If a disk that contains an online redo log file fails, other copies are still intact and available to Oracle. System operation is not interrupted and the lost online redo log files can be easily recovered
Warning: Although the Oracle7 Server allows multiplexed groups to contain different numbers of members, this state should only be temporary, as the result of an abnormal situation such as a disk failure damaging a member of a group. If any group contains only one member, the failure of the disk containing that member could cause Oracle7 to halt.
While multiplexed groups require extra storage space, the cost of this space is usually insignificant compared to the potential cost of lost data (if a disk failure destroys a non-multiplexed online redo log).
If you archive the redo log, spread online redo log members across disks to eliminate contention between the LGWR and ARCH background processes. For example, if you have two groups of duplexed online redo log members, place each member on a different disk and set your archiving destination to a fifth disk. This way, there is never contention between LGWR (writing to the members) and ARCH (reading the members).
Datafiles and online redo log files should also be on different disks to reduce contention in writing data blocks and redo entries.
With multiplex groups of online redo logs, all members of the same group must be the same size. Members of different groups can have different sizes; however, there is no advantage in varying file size between groups. If checkpoints are not set to occur between log switches, make all groups the same size to guarantee that checkpoints occur at regular intervals.
See Also: The default size of online redo log files is operating system-dependent; for more details see your operating system-specific Oracle documentation.
In some cases, a database instance may require only two groups. In other situations, a database instance may require additional groups to guarantee that a recycled group is always available to LGWR. During testing, the easiest way to determine if the current online redo log configuration is satisfactory is to examine the contents of the LGWR trace file and the database's ALERT file. If messages indicate that LGWR frequently has to wait for a group because a checkpoint has not completed or a group has not been archived, add groups.
Consider the parameters that can limit the number of online redo log files before setting up or altering the configuration of an instance's online redo log. The following three parameters limit the number of online redo log files that you can add to a database:
In some cases, you might need to create additional groups or members of online redo log files. For example, adding groups to an online redo log can correct redo log group availability problems. A database can have up to MAXLOGFILES groups.
The following statement adds a new group of redo logs to the database:
ADD LOGFILE ('log1c', 'log2c') SIZE 500K;
Note: Fully specify filenames of new log members to indicate where the operating system file should be created; otherwise, the file is created in the default directory of the database server, which is operating system-dependent. If you want to reuse an existing operating system file, you do not have to indicate the file size.
Using the ALTER DATABASE statement with the ADD LOGFILE option, you can specify the number that identifies the group with the GROUP option:
ADD LOGFILE GROUP 10 ('log1c', 'log2c') SIZE 500K;
Using group numbers can make administering redo log groups easier. However, the group number must be between 1 and MAXLOGFILES; do not skip redo log file group numbers (that is, do not number your groups 10, 20, 30, and so on), or you will consume unnecessary space in the control files of the database.
To create new online redo log members for an existing group, use the Add Logfile Member property sheet of Server Manager, or the SQL command ALTER DATABASE with the ADD LOG MEMBER parameter.
The following statement adds a new redo log member to redo log group number 2:
ADD LOGFILE MEMBER 'log2b' TO GROUP 2;
Notice that filenames must be specified, but sizes need not be; the size of the new members is determined from the size of the existing members of the group.
When using the ALTER DATABASE command, you can alternatively identify the target group by specifying all of the other members of the group in the TO parameter, as shown in the following example:
ADD LOGFILE MEMBER 'log2c' TO ('log2a', 'log2b');
Note: Fully specify the filenames of new log members to indicate where the operating system files should be created; otherwise, the files will be created in the default directory of the database server.
To rename online redo log members, you must have the ALTER DATABASE system privilege. Additionally, you might also need operating system privileges to copy files to the desired location and privileges to open and back up the database.
Before renaming any online redo log members, ensure that the new online redo log files already exist.
Warning: The following steps only modify the internal file pointers in a database's control files; they do not physically rename or create any operating system files. Use your computer's operating system to copy the existing online redo log files to the new location.
Rename online redo log members with the Rename Logfile Member property sheet of Server Manager, or the SQL command ALTER DATABASE with the RENAME FILE parameter.
To Rename and Relocate Online Redo Log Members
The following example renames the online redo log members. However, first assume that:
RENAME FILE 'log1a', 'log2a'
TO 'log1c', 'log2c';
To drop an online redo log group, you must have the ALTER DATABASE system privilege.
Before dropping an online redo log group, consider the following restrictions and precautions:
The following statement drops redo log group number 3:
ALTER DATABASE DROP LOGFILE GROUP 3;
When an online redo log group is dropped from the database, the operating system files are not deleted from disk. Rather, the control files of the associated database are updated to drop the members of the group from the database structure. After dropping an online redo log group, make sure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped online redo log files.
To drop an online redo log member, you must have the ALTER DATABASE system privilege.
Consider the following restrictions and precautions before dropping individual online redo log members:
The following statement drops the redo log LOG3C:
ALTER DATABASE DROP LOGFILE MEMBER 'log3c';
When an online redo log member is dropped from the database, the operating system file is not deleted from disk. Rather, the control files of the associated database are updated to drop the member from the database structure. After dropping an online redo log file, make sure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped online redo log file.
See Also: For information on dropping a member of an active group, see "Forcing a Log Switch" .
However, you can designate that checkpoints are taken more often than when you have log switches, or you can have a checkpoint take place ahead of schedule, without a log switch. You can also have a log switch and checkpoint occur ahead of schedule, or without an accompanying checkpoint.
This section includes the following checkpoint and log switch topics:
Generally, unless your database consistently requires instance recovery on startup, set database checkpoint intervals so that checkpoints occur only at log switches. If you use small online redo log files, checkpoints already occur at frequent intervals (at each log switch).
You can control the frequency of automatic database checkpoints via the values set in the LOG_CHECKPOINT_INTERVAL and LOG_CHECKPOINT_TIMEOUT parameters.
The value of the LOG_CHECKPOINT_INTERVAL is a number of operating system blocks, not Oracle7 data blocks. Therefore, you must know the size, in bytes, of your operating system's blocks. Once you know this, calculate the number of operating system blocks per online redo log file.
As an example, assume the following conditions:
512K/redo log file
__________________ = approximately 1000 blocks/redo log file
512 bytes/OS block
Now that the approximate number of blocks per online redo log file (1000) is known, the LOG_CHECKPOINT_INTERVAL parameter can be set accordingly in the instance's parameter file:
See Also: For information on how to determine operating system block size, see your operating system-specific Oracle documentation.
For more information about tuning Oracle7 regarding checkpoints, see the Oracle7 Server Tuning manual.
For more information about the LOG_CHECKPOINT_TIMEOUT parameter when using the Oracle7 Parallel Server, see the Oracle7 Parallel Server Concepts & Administration manual.
For more information about setting LOG_CHECKPOINT_TIMEOUT when using Trusted Oracle7 in OS MAC mode, see the Trusted Oracle7 Server Administrator's Guide.
To force a log switch, you must have the Alter System privilege.To force a log switch, use either the Switch Logfile menu item of Server Manager, or the SQL command ALTER SYSTEM with the SWITCH LOGFILE option.
The following statement forces a log switch:
ALTER SYSTEM SWITCH LOGFILE;
To force a database checkpoint, you must have the ALTER SYSTEM system privilege. Force a fast database checkpoint with either the Force Checkpoint menu item of Server Manager, or the SQL command ALTER SYSTEM with the CHECKPOINT option.
The following statement forces a checkpoint:
ALTER SYSTEM CHECKPOINT;
Omitting the GLOBAL option allows you to force a checkpoint for only the connected instance, while including it forces a checkpoint for all instances of the database. Forcing a checkpoint for only the local instance is useful only with the Oracle7 Parallel Server. In a non-parallel server configuration, global and local checkpoints are identical.
See Also: For more information on forcing checkpoints with the Oracle7 Parallel Server, see the Oracle7 Parallel Server Concepts & Administration manual.
If you enable redo log block checking, Oracle7 computes a checksum for each redo log block written to the current log. The checksums are written in the header of the block.
Oracle7 uses the checksum to detect corruption in a redo log block. Oracle7 tries to verify the redo log block when it writes the block to an archive log file and when the block is read from an archived log during recovery.
If Oracle7 detects a corruption in a redo log block while trying to archive it, Oracle7 tries to read the block from another member in the group. If the block is corrupted in all members the redo log group, then archiving cannot proceed.
See Also: For information about archiving redo log files, see Chapter 22.
In this situation, you can use the SQL command ALTER DATABASE... CLEAR LOGFILE to clear the corrupted redo logs and avoid archiving them. The cleared redo logs are available for use even though they were not archived.
The following statement clears the log files in redo log group number 3:
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;
If you clear a log file that is needed for recovery of a backup, then you can no longer recover from that backup. Oracle7 writes a message in the alert log describing the backups from which you cannot recover.
Attention: If you clear an unarchived redo log file, you should take another backup of the database.
If you want to clear an unarchived redo log that is needed to bring an offline tablespace online, you must use the clause UNRECOVERABLE DATAFILE in the ALTER DATABASE command.
If you clear a redo log needed to bring an offline tablespace online, you will not be able to bring the tablespace online again. You will have to drop the tablespace or perform an incomplete recovery.
See Also: For a complete description of the ALTER DATABASE command, see the Oracle7 Server SQL Reference.
The following query returns information about the online redo log of a database used without the Parallel Server:
SELECT group#, bytes, members
GROUP# BYTES MEMBERS
---------- ---------- ----------
1 81920 2
2 81920 2
To see the names of all of the member of a group, use a query similar to the following:
WHERE group# = 2;
GROUP# STATUS MEMBER
---------- ----------- --------------
2 STALE LOG2B
If STATUS is blank for a member, the file is in use.
Copyright © 1996 Oracle Corporation.
All Rights Reserved.