0444-0446

Previous Table of Contents Next

Page 444

Redo Logs

The Oracle system auditing is affected by the redo logs. There must be a minimum of two redo log files for every database. This section examines maintaining redo log files and multiplexing them.

Creating, Altering, and Dropping Redo Logs

The online redo log files are used to record changes made to the database files. These files also are used in rotation. That is, when one redo log file fills, a checkpoint is performed and entries are written to the other redo log file. After that file fills and the checkpoint on the next is complete, the next file is used. If the checkpoint on a redo log file has not completed, it cannot be used until the checkpoint completes. This process causes the instance to hang temporarily until the checkpoint completes. For this reason, additional redo log files can be created.

TIP
As a general rule, size the redo log files so that a switch from one online redo log file to another occurs roughly every 30 minutes. This method ensures that not too many checkpoints occur. (Remember that, at each checkpoint, the changed database blocks must be written to disk, which causes more disk I/O.) Likewise, the time needed to recover the instance if it fails is not too great; only 30 minutes of changes must be reapplied. Use the Oracle alert file or the V$ dynamic performance views to determine the frequency at which log switches occur.

You can create more than two online redo log files when you create the database or by using the ALTER DATABASE SQL command. Because you are modifying the structure of the database, you must start the instance in a mounted state. Having the instance in a mounted state means that the control file is open; the names of the redo logs are recorded in the control file.

To start up the instance in a mounted state, go into the Instance Manager tool and issue the STARTUP MOUNT command. This assumes that the INIT.ORA parameter file is in the default location and that the name of the database is specified in the INIT.ORA file with the DB_NAME parameter. You use this code, for example:

 STARTUP MOUNT 

To add another online redo log file, enter this code:

 ALTER DATABASE ADD LOGFILE      `/disk03/mydb/log3.rdo' SIZE 512K; 

When you restart the instance, the log writer background can write to three online redo log files, which reduces the chance of having to wait for a checkpoint process to occur.

Page 445

To move the redo log files, first make sure that the instance has been started in a mounted state. Use an operating system file copy command, and make a copy of the file you want to rename or move to a new location. Then issue the following command:

 ALTER DATABASE RENAME FILE      `/disk03/mydb/log3.rdo' TO      `/disk04/mydb/log4.rdo'; 

This command records the new name and location of the redo log file in the control file. Note that it always is necessary to copy the files manually to the new names or locations. Oracle does not make a copy of the files for you.

To drop an online redo log file, first make sure that the instance has been started in a mounted state. Use your operating system's file delete command to remove the file manually from disk. To notify Oracle that the control file must be updated because the redo log file no longer can be used, issue the following statement:

 ALTER DATABASE DROP LOGFILE MEMBER      `/disk04/mydb/log4.rdo'; 
TIP
The redo log files should all be the same size.


CAUTION
Make sure that there are always two or more online redo log files. Otherwise, you will not be able to restart the instance.

Multiplexing Redo Logs

The redo log files protect the database files in cases of failure. If you lose the changes in the SGA, you can reapply them from the online redo log files for the committed transactions. Similarly, if the database has been set up to run in Archive Log mode, the changes made to the database file since the last backup can be reapplied automatically to a backup of the file, thereby protecting against media failure.

If the online redo log files are lost, however, you run the risk of losing committed work. For this reason, it is a good idea to mirror redo log files by using redo log groups. Essentially, multiple copies of the online redo log files are kept. If one copy is lost, there is always an exact mirror copy that the instance can use. You might think that this would slow down the instance. In fact, the opposite is often the case, because the LGWR background process needs to receive a success signal from only one of the copies. If one of the copies of the redo log files in a redo log group cannot be used, the file is marked as invalid and the instance continues to run as normal.

Page 446

You can mirror the redo log files when you create the database or by using the ALTER DATABASE command. A redo log group consists of one or more redo log file members, which are the redo log files. All the members of the group have the same information recorded in them; they are mirror copies of one another. The redo log groups are numbered sequentially, starting at 1. To see which group each of the existing files belongs to, access the v$log dynamic view.

In the default setup, a database has two redo log file groups, each of which has one member. This means that there are only two redo log files; the instance writes cyclically from one to the other.

When you mirror an existing redo log file, you create another redo log file member of a redo log group. The following command adds another file to redo log group 1:

 ALTER DATABASE ADD LOGFILE MEMBER      `/disk04/mydb/log11.rdo' TO GROUP 1; 

The command to drop a redo log file is similar. To drop an entire group, issue the following command:

 ALTER DATABASE DROP LOGFILE      GROUP 3; 

Control Files

The control file is used in the second stage of instance startup to find out the names and locations of the database files and the redo logs. Losing this file causes a major headache in recovery. Recovery options restore the control file from a previous backup or use the CREATE CONTROL FILE SQL command to create it directly. You can set up a further level of protection by having the Oracle instance keep more than one copy of the control file always updated. This ensures that you always have another copy if one copy is lost.

Multiplexing Control Files

To make the Oracle instance update more than one copy of the control file, follow these steps:

  1. Use SHUTDOWN NORMAL to bring down the instance.
  2. Use an operating system utility to copy the existing control file to a different name.
  3. In the CONTROL_FILES INIT.ORA parameter, specify both control files. Separate them with a comma.
  4. Bring up the instance. The instance now maintains the two control files.

If you make a copy of the control file, keep the other control file on a disk different from the original to guard against losing the entire disk drive. To provide an extra level of protection, make more than two copies. The extra overhead of keeping extra copies of the control file is negligible compared to the extra protection they provide.

Previous Table of Contents Next


Oracle Unleashed
Oracle Development Unleashed (3rd Edition)
ISBN: 0672315750
EAN: 2147483647
Year: 1997
Pages: 391

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net