Real Application Cluster (RAC) is a widely used Oracle cluster product that provides high availability and scalability for Oracle databases. When configuring Data Guard on RAC databases, there are some points that we need to take into consideration in order to build a proper integration. For a RAC primary database, we may prefer configuring single instance or RAC standby databases. These configurations will be discussed separately. A single instance primary database and RAC standby database configuration is not common and doesn't require any special attention.
Creating a single instance standby database for a RAC primary database is a very frequently encountered configuration. The following points are important when configuring a single instance standby for a RAC primary database:
- The
LOG_ARCHIVE_DEST_nparameter in the primary database, which shows the standby database, must be configured with theSID='*'option. This will enable a redo transport service on all nodes of the primary database. - Every instance of the primary database must be able to resolve the service name specified in the
LOG_ARCHIVE_DEST_nparameter pointing to the standby database. - The number of standby redo log files on the standby database must be calculated according to the number of instances and redo log groups in the primary database. The following formula can be used to determine the number of standby redo logs:
(number of primary redo log groups + 1) * number of threads on primary
For example, if we have three redo log groups for each instance of a two-node RAC primary database, we must create
(3+1)*2=8standby redo log groups on the standby database. The size of the standby redo logs should be equal to that of the primary online redo logs. Use the following statement format to create standby logs:ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 11 SIZE 100M, GROUP 12 SIZE 100M, GROUP 13 SIZE 100M, GROUP 14 SIZE 100M, ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 15 SIZE 100M, GROUP 16 SIZE 100M, GROUP 17 SIZE 100M, GROUP 18 SIZE 100M;
- When the maximum protection mode is used, if one of the instances can't reach the standby for a pre-specified time, that instance will be shut down. Other instances that have connectivity to the standby database will continue to operate. If all instances of the primary database lose connection to the standby database for the pre-specified time, the primary database will be shut down.
- During the switchover operation to a physical standby, only one instance can be opened in the primary database.
Now let's see what we should pay attention to when creating a RAC standby database for a RAC primary database:
- The most important point in this configuration is the fact that recovery cannot be active on all instances of the standby database. Only one instance can be used for recovery.
- The
LOG_ARCHIVE_DEST_nparameters must be configured properly on every instance of the primary and standby databases to show remote archiving destinations. Remote destinations configured on the standby database will be used after a switchover. - Standby redo logs must be created on a shared location, such as a cluster file system or ASM, using the formula and format given in the previous section. All instances of the standby database must be able to access the standby redo logs.
- The local archiving destination of the standby database must be the same and it should be a shared location for all instances.
- The consideration about the maximum protection mode in the previous section is still valid.
- During a switchover, only one primary and one standby instance can be active. Other instances must be shut down.
The integration of Data Guard and RAC was covered under the titles of two different configurations where the standby database is a single instance of a RAC. Using RAC with Data Guard is a common solution that combines high availability and disaster recovery purposes in a dependable way. Oracle recommends this configuration in its maximum availability architecture.