| Previous | Table of Contents | Next |
ARCHIVELOG mode, or archive redo log files, must be implemented if hot backups are to be performed, if “point-in-time” recovery is desired or if you need to recover database files after a disk crash or other media failure.
NOTE:
The size of the archive redo log is determined by the size of the online redo log being archived.
TIP:
There is no technical reason why the online redo logs have to be the same size, but I recommend that they be the same size to allow more control of the time needed to recover data in the event of media failure.
Automatic Archive redo log mode is easy to implement. The first step is to shut down the database and start up in nomount (exclusive) mode. In svrmgrl, enter the command alter database archivelog. Shut down the database. Edit the INIT.ORA file and uncomment two parameters that control this mode of operation. Uncomment the lines and set their values: log_archive_start = true and set log_archive_dest = <operating system full path name>. The log_archive_format command is optional and is used to change the default naming convention of the archive log file itself (see the Oracle Database Administrator’s guide for format options and advice). Start up the database using this init.ora file with these changes. The directory identified by log_archive_dest should now have an archive redo log file in it. They will be assigned sequential numbers and will only be used during a media-type recovery. The recovery process will prompt the computer operator for these log files by their names.
Mirroring these archive log files is also possible. To implement, simply set log_archive_duplex_dest = <operating system full path name> and restart the Oracle environment for this change to be active. The log_archive_min_succeed_dest parameter can be used to ensure that one or two archive files were successfully written to. The default for this parameter is 1, which means only one of the archive redo logs needs to be available for writing.
The frequency with which these archive log files are created can easily be controlled by the size of the online redo files or by entering the SQL command alter database switch log file. Checkpointing is a process where all database buffers are written to disk and a mark, a checkpoint, is recorded in the log as a quiet point in the database where all transactions are committed or rolled back. The frequency of the checkpoints has a dramatic effect on the speed of recovery. The checkpoint process is resource- intensive. Checkpointing can have a negative performance impact on an active Oracle environment with lots of active users with DML activity. Checkpoint frequency should be balanced against the amount of data in the logs being written. The INIT.ORA parameter LOG_CHECKPOINT_INTERVAL = <integer> controls the frequency of checkpoints. The integer is the number of megabytes written in the online redo logs between checkpoints. A checkpoint always occurs at a log switch, during the process of Oracle having filled one online redo log and beginning to use the next available online redo log. Archive log files are created as a part of the log switch process. The online redo logs need to be large enough to hold complete transactions but small enough to fit recovery time requirements.
TIP:
On active systems, make the online redo logs hold enough data to fit the recovery-time window and set the LOG_CHECKPOINT_INTERVAL (number is in Oracle database blocks) to a size larger than the largest online redo log. This will ensure that checkpointing does not slow down the active system.
There are several SQL commands that will indirectly cause a checkpoint to occur. The obvious ones are any log file switch command, but other commands that will cause a checkpoint are alter tablespace begin backup, alter tablespace offline, and instance shutdown.
Cold backups are done when the Oracle RDBMS is in a down state and all of the physical files and initialization files are backed up. This method can be supplemented with Oracle’s Export and Import utilities to do incremental backups of changed objects, or better yet, supplement Oracle’s ARCHIVELOG mode. If ARCHIVELOG mode is being utilized, all prior archive log files become irrelevant after a successful cold backup of all physical files is complete. This method is an “all-or-nothing” approach to recovery. If ARCHIVELOG mode is not utilized, and no other method is used to capture changes in the database, all changes are lost from the last cold backup.
Hot backups are done at the tablespace level, with the database up and available for reads and writes. Hot backups utilize the archive log files (ARCHIVELOG mode must be implemented) to store all writes while the physical tablespace files are being backed up. During recovery, all noncorrupted tablespaces are online and available. Oracle will prompt an operator for the needed archive logs to restore the tablespace.
NOTE:
Cold backups should include the redo log files for any instance recovery required from the previous shutdown of the database. Hot backups should avoid the redo log files for this very reason. If the database is in an online status, the redo log files plays no role in any future media recovery scenario.
| Previous | Table of Contents | Next |