Enabling Archive Logs in a RAC Environment

Enabling Archive Logs in a RAC Environment

by Jeff Hunter, Sr. Database Administrator

Whether a single instance or clustered database, Oracle tracks (logs) all changes to database blocks in online redolog files. In an Oracle RAC environment, each instance will have its own set of online redolog files known as a thread. Each Oracle instance will use its set (group) of online redologs in a circular manner. Once an online redolog fills, Oracle moves to the next one. If the database is in "Archive Log Mode", Oracle will make a copy of the online redo log before it gets reused. A thread must contain at least two online redologs (or online redolog groups). The same holds true for a single instance configuration. The single instance must contain at least two online redologs (or online redolog groups).

The size of an online redolog file is completely independent of another intances' redolog size. Although in most configurations the size is the same, it may be different depending on the workload and backup / recovery considerations for each node. It is also worth mentioning that each instance has exclusive write access to its own online redolog files. In a correctly configured RAC environment, however, each instance can read another instance's current online redolog file to perform instance recovery if that instance was terminated abnormally. It is therefore a requirement that online redo logs be located on a shared storage device (just like the database files).

As already mentioned, Oracle writes to its online redolog files in a circular manner. When the current online redolog fills, Oracle will switch to the next one. To facilitate media recovery, Oracle allows the DBA to put the database into "Archive Log Mode" which makes a copy of the online redolog after it fills (and before it gets reused). This is a process known as archiving.

The Database Creation Assistant (DBCA) allows users to configure a new database to be in archive log mode, however most DBA's opt to bypass this option. In cases like this where the database is in no archive log mode, it is a simple task to put the database into archive log mode. Note however that this will require a short database outage. From one of the nodes in the Oracle RAC 10g configuration, use the following tasks to put a RAC enabled database into archive log mode. For the purpose of this article, I will use the node racnode1 which runs the racdb1 instance:

1. Login to one of the nodes (i.e. racnode1) and disable the cluster instance parameter by setting cluster_database to FALSE from the current instance:

   $ sqlplus "/ as sysdba" SQL> alter system set cluster_database=false scope=spfile sid='racdb1';

2. Shutdown all instances accessing the clustered database:

   $ srvctl stop database -d racdb

3. Using the local instance, MOUNT the database:

   $ sqlplus "/ as sysdba" SQL> startup mount

4. Enable archiving:

   SQL> alter database archivelog;

5. Re-enable support for clustering by modifying the instance parameter cluster_database to TRUE from the current instance:

   SQL> alter system set cluster_database=true scope=spfile sid='racdb1';

6. Shutdown the local instance:

   SQL> shutdown immediate

7. Bring all instance back up using srvctl:

   $ srvctl start database -d racdb

8. (Optional) Bring any services (i.e. TAF) back up using srvctl:

   $ srvctl start service -d racdb

9. Login to the local instance and verify Archive Log Mode is enabled:

   $ sqlplus "/ as sysdba" SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 83 Next log sequence to archive 84 Current log sequence 84

After enabling Archive Log Mode, each instance in the RAC configuration can automatically archive redologs!

About the Author

Jeffrey Hunter is an Oracle Certified Professional, Java Development Certified Professional, Author, and an Oracle ACE. Jeff currently works as a Senior Database Administrator for The DBA Zone, Inc. located in Pittsburgh, Pennsylvania. His work includes advanced performance tuning, Java and PL/SQL programming, developing high availability solutions, capacity planning, database security, and physical / logical database design in a UNIX, Linux, and Windows server environment. Jeff's other interests include mathematical encryption theory, programming language processors (compilers and interpreters) in Java and C, LDAP, writing web-based database administration tools, and of course Linux. He has been a Sr. Database Administrator and Software Engineer for over 17 years and maintains his own website site at: http://www.iDevelopment.info. Jeff graduated from Stanislaus State University in Turlock, California, with a Bachelor's degree in Computer Science.