Oracle Data Guard vs. RAC

Discussion created by Andreas_Sprosec_7439 on Jul 28, 2017
Note: this is an extract of our AWA Installation Guide V12 which is available in our download center.

Installation Scenarios

Scenario 1: RAC

The Automation Engine is not fully RAC enabled, as it only benefits from the increased availability of an RAC system. Its performance, however, does not improve by using RAC technology. On the contrary, you need to make sure that your system only communicates with one node of the RAC system in order to minimize data traffic through the Cluster Interconnect and administrative workload. In doing so, you also reduce the likelihood of deadlocks that might occur in the database because of database nodes that try to access the database concurrently.

Within an RAC node, Oracle generally uses row-level locking. However, block-level transfer and
resource locking is used between the RAC nodes.To make sure that the AE is always only connected
to one node, Automic recommends using Cluster Managed Services. You need to configure them in a
way that the service only runs on one node and that the cluster software moves it to the second node if

Scenario 2: Data Guard

The characteristics of Oracle Data Guard configuration that are relevant for use with the AE are described below. The configuration that you will use depends on the available infrastructure and your requirements.

Configuration 1 (Maximum Protection - Guaranteed Protection Mode)

The primary database will only register a transaction as committed when this transaction was also committed to at least one standby database. If the transaction could not be committed to a standby
database, the primary database stops. The advantage of this configuration is that production can continue immediately after a short manual intervention when the primary database has failed. Check whether the standby database was
synchronized with the primary database at the time it failed. If so, you can activate the standby database and continue.

Configuration 2 (Maximum Availability - Instant/Rapid Protection Mode)

This configuration ensures that the standby database(s) is/are synchronized in a timely manner. However, the primary database starts processing the next transaction even it has not yet been confirmed that the previous transaction was also committed to at least one standby database. Therefore, the primary database does not stop when no standby database is available anymore. Changes made in the primary database are automatically updated in the standby database as soon as it is available again. In this configuration, you must always check manually whether the standby database was synchronized with the primary database at the time of failure.

Configuration 3 (Maximum Performance)

In this configuration, changes will only be transferred to the standby database when the online redo log is changed. Therefore, you cannot expect that the standby database includes up-to-date data when the primary database fails. You always need to manually check all the AE activities that have taken place since the log has been changed the last time.

Comparison of Data Guard Configurations

As a general rule, all the configurations require the same quantity of user data to be transferred between
primary and standby databases. The required workload when the primary database fails is always
different. The lower the workload during a failure, the higher the load in the form of longer response times
during day-to-day operation.
For the reasons mentioned above, it must be calculated for each case how the demand on availability can
be realized with the infrastructure that is currently available.

For a single instance, the availability is always minimal compared to a Data Guard solution. However, performance is almost not affected. On the contrary, for Data Guard in maximum availability mode, the availability is very high but the negative effect on performance is also at the maximum level. When you intend to install AE Data Guard ,Automic' recommends focusing on your available infrastructure in order to ensure that you won't have to deal with performance bottlenecks.