Overview

In this section we will configure a dataguard as a RAC dataguard to a RAC Primary database. That configuration is known also as MAA (Maximum Availability Architecture). We will use RMAN and I will skip the boring steps with the installation of the software only and Grid infrastructure.

These steps can be checked in the Grid Infrastructure and Oracle Database sections. So let's assume a configuration in which we have 2 sets of 2 servers. The first set(enode1, enode2) is where a typical Oracle RAC database resides with Oracle Grid Infrastructure, prividing the ASM storage, called EASTDB.

The second set(wnode3 and wnode4) is where only the Grid infrastructure is installed with ASM prividing the storage again, but the software only database is installed.

So, our goal is to bring it to:

So, let's get going

Preration Primary

First, we have to prepare the primary. Primary database needs to have the following features / attributes:

Archivelog Mode Enabled

Has Force logging

Has Standby Redo log Groups

Modify FAL_Server and other database configs

Enable Archivelogs

In RAC environment, the Archivelog is enabled by bringing the database down, starting one instance, enable it and then restart the whole database with all instances. Therefore we need a downtime, just like with a normal database. You are changing the static section of the controlfile after all.

Check archivelog

So, we don't have it for now, so let's change it.

Enable Archivelog

Enable Force Logging

Then, as we said, we have to check the Force logging feature.

Check force logging

Create Standby Redo log Groups for Primary

Then we have to create Standby Redo log groups on the primary, which will be THE SAME as teh Redo log groups. That is important to avoid a particular bug in oracle.

Create Standby Redo log Groups

We had 4 Redo log groups each with 1 member (file) with 50 MB of size, so we created the same for the Standby Redo Log groups.

Modify the Archivelgo Destinations

Oracle can have up to 31 archivelog destinations. That means we can send our redo log file copies to up to 31 destinations. For the purposes of this training, we need only 2.

Local Destination (FRA)

Remote Destination (The dataguard service)

So let's do it.

Set Archivelog Destinations

It is also good to enable the Automatic File management on the primary in case of a role reversal. In that case, any manupulation of the OS files of the Primary ,will be automatically replicated on the Standby as well.

Set Automatic File Management

Lastly, we have to set the FAL server. FAL or First Archivelog Server is the location where the Standby will search for the archivelogs in case they are needed. In an environment with multiple dataguards and one primary. That location should be changed when the primary also changes. But in our case, we ALWAYS KNOW, that the Primary will always be the other database. So if EASTDB will become standby, the primary will always be WESTDB and vice versa.

Set FAL_Server

That concludes the prepartion of the Primary.

Prepare Standby

Now it is time to prepare the standby. As we said before. Here we have ASM providing the storage on nodes; wnode3 and wnode4 and the database software only binaries installed on both nodes. Of course you have the tnsnames.ora and listener.ora configured for the primary, but that goes without saying :) To prepare the standby we need to:

Create oratab entries and adump directory for the new Standby Database

Copy & Import the password file from the Primary Database

Modify and start Listener Configuration

Create a pfile and start an instance

Prepare the Environment

Firstl, we need to add the oratab entriesfor the new database:

Add Oratab Entries

Copy the Password File from Primary

To copy the password file from the primary we need to login as grid (Grid Infrastructure owner) on the primary and extract it from the ASM.

Extract, Copy and Import the Password File

Modify and Start the Listener on the standby

The Global Listeners in RAC, also known as SCAN (Single Client Access Name) listeners, are started from the Grid user, therefore the configuration should be in the Grid Infrastructure Home. Modify the listener.ora file to contain the following records:

Configuration of the Global Listener

P.S. FORMATING IS IMPORTANT, don't forget some space, otherwise you will have issues.

Start standby Instance

We will prepare a pfile for one instance for the standby. Standby will firsly reside only on ONE instance and then we will add more. As Oracle user on wnode3:

Create pfile & Start the instance

Oracle can start with literally a db_name only, but we need also db_unique_name for our example. We have also domain for the global name.

Restore teh Primary for Standby

Now that we have a started instance we can start the restore from the primary. Again assure you can tnsping from PRIMARY → Standby and from Standby → Primary

Restore the primary for Standby

Completing the Standby Configuration

Now that we have a standby database, we have to integrate it in the Grid Infrastructure, so we can take advantage of all these nice features. However before that, we have to enable it and check if it works correctly. So in this part we will:

Enable the log_archive_dest_2 & Check archivelog apply

Add the Clusterware entries

Enable The archivelog destination & Check archivelog apply

Remember, that we set the second archivelog destination on the primary as DEFER :) Well, I sure do, that means that Oracle won't send the archivelog on the service. We have to change that

On Primary

After that, we have to verify the application

Verify Application

Now that we checked and verified that the archivelogs are being applied, we have to re-create the spfile. Remember that the spfile was re-created during the duplicate procedure and it contains data referring to the primary.

Modify the pfile

Phew, that was something, now that we are done with the modifications, we have to shutdown the standby, prior adding it to the grid.

Shutdown the Standby

Add Clusterware entries for the Standby

Adding entries to the clusterware registeries is rather simple:

On standby

It is important they to be added as the owner of the resource. Otherwise, you might not be able to start it later, due to profile restrictions.

Finally, we can start and verify the standby:

On Standby

Verify Replication

To verify replication, we can simply check 2 things. Is the MRP process on the Standby Running, is the archivelogs being applied. Don't forget that the Data Guard in general can be either:

Physical Guard (up to Read Only - Active Data Guard)

Logical Guard (up to Read Write)

The Physical Guard is using the MRP process to apply the logs, where the Logical Guard is using the LSP. The difference is pretty simple:

MRP - Keeping the Database in constant state of Recovery

LSP - Generate SQL from the archivelog files, which then, it applies to the database.

Because of that there are limitation of the Logical Guard. But we will address that in the Logical Guard section, enough side ways :)

So, to verify the application we can do the following:

Verify Apply