Database Reference
In-Depth Information
Non-RAC vs. RAC Database
Before we really jump in and get started on backup and recovery concepts in the RAC environment, let's examine the
architectural differences between a clustered and a nonclustered database.
There are no substantial architectural differences between a single instance and RAC database except that
multiple instances access a single physical database in the RAC environment. Moreover, every instance has its own
undo tablespace, a set of individual redo groups, and thereby generates instance-specific archived logs. No additional
or special skills are required to manage database backup and recovery for a RAC database. In contrast, there is a
significant difference in the way instance, media, or crash recoveries are performed in a RAC database. When an
instance is involved in any sort of recovery operation, and if it requires the redo/archive log generated by the other
instance in the context, the instance that is performing the recovery must have access to the other instance redo/
archive logs to successfully complete the recovery. Therefore, it is strongly advised to put the redo/archive logs at
a shared location so that all instances of the RAC database can have access.
Figure
8-2
depicts the architectural differences between a standalone and a RAC database.
Non-RAC Database
RAC Database
RONDB_1
RONDB_2
RONDB
LG WR
ARCn
DBWn
LGWR
ARCn
DBWn
DBWn
ARCn
LGWR
Online
Redo
logs
Online
Redo
logs
Online
Redo
logs
Archive
logs
Archive
logs
Archive
logs
Figure 8-2.
RAC vs. non-RAC architecture
Shared Location for Redo and Archive Logs
As stated earlier, each instance in a RAC database typically consists of its own set of redo logs and generates individual
archive logs. The redo group and archive logs in a RAC database are solely identified by a distinct thread number to
avoid ambiguity. For example, a redo member and archive log of instance 1 will be identified as thread_1.
Despite each instance having absolute control over its own redo and archive logs, it is essential that all instances
have the privilege to read each other's redo and archive logs to successfully perform various RAC database recovery
tasks, such as instance recovery, crash recovery, and media recovery. It is a requirement for a RAC database to have
the redo logs across all instances on a shared destination, also preferably archive logs, to ensure accessibility between
the instances.
Oracle strongly suggests making use of the Fast Recovery Area (FRA), which is a centralized location for all
backup-related and recovery-related files. The FRA could be configured on an ASM diskgroup, Cluster Filesystem,
or Network File System by configuring the two dynamic database initialization parameters. When there is no FRA
specified during database creation process, the FRA will be automatically set under the Oracle base directory.
