Archive Process Options

When you identify the location for the archive log files and start the archiving of the redo logs you have only started the archive process. You still have not told the database to actually archive anything. Before we discuss manual and automatic archive log processing, let us review a few important issues:

1. Your database must be in archivelog mode before we can start to archive our redo log files. ARCH will not copy the redo log files if the database is not set to archiving.
2. Your database should be in a consistent state before you enable archiving. Do a normal or immediate shutdown of the database, bring the database back up and then enable archiving.
3. If ARCH fails for any reason and the redo logs fill up, Oracle will hang. By setting the database in archivelog mode, we prevent Oracle from overwriting the online redo log files unless they are archived. This is a valid hang of the database.
4. It is important that the archiving of the redo log files keeps up with the transactional activity of the database. You may either hang the database or slow down other Oracle processes.
5. One important use of archived log files is to manage an up to date standby database. A standby database is a duplicate copy of the database that is stored at a remote site.

The archive logs are files created by the Archive process (ARC) from the redo logs. Once a redo log is full, the database performs a log switch and begins overwriting the next redo log. The ARC process copies the changes from the full redo log to an archive log file.

$ORACLE_HOME/dbs/arch

Lets say that we took a backup of the metadata repository on Monday and on Tuesday an operator deleted one of the data files of the database. We shutdown the database, restore the one missing data file and restart the database.
Oracle will see that the SNC for the restored data files in incorrect and will determine which archive log file has the first change it needs to apply and will begin rolling the data file forward applying each change recorded in the archive logs. The database will continue until the data file is current.
When the ARC process is copying changes to archive logs, the database is in ARCHIVELOG mode. When the installer creates the Metadata Repository database it is created in NOARCHIVELOG mode which means that to recover the database from a backup you must first place it into ARCHIVELOG mode. To place the database in ARCHIVELOG mode using the default log file locations, you must shut it down, partially restart it, switch to ARCHIVELOG mode and finally open the database.

[oracle@appsvr oracle]$ $ORACLE_HOME/bin/sqlplus ?/ as sysdba?
# Change the log_archive_start=true
SQL> alter database set log_archive_start=true scope both;
SQL> shutdown immediate
SQL> startup mount
SQL> alter database archivelog;
SQL> alter database open;

The Metadata Repository database is created in NOARCHIVELOG mode. You must change it to ARCHIVELOG mode to be able to recover and roll forward the database. If the database is in NOARCHIVELOG mode you can only restore the backup file and all changes made since that time will be lost.

If you no longer have the backup, the archive logs for that backup are of no value. Likewise, if you have the backup but have deleted the archive logs, the backup can only be used to restore to the point in time of the backup. The database can not roll forward with out the archive logs. Also, the database can not skip a missing archive log. The database will roll forward until it needs the missing archive log and no further.
Now that we have a basic understanding of how Oracle maintains transaction logs, we need to discuss the methods of backing up the database. The key to having a valid backup is that each file is consistent and did not change during the backup. Now that we know the mechanisms Oracle uses to protect data in the database we need to discuss the how those features are used in backup and recovery. The next lesson is about normal ARCH processing.