oracle_guard_installation

This is an old revision of the document!


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

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

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

[oracle@enode01 ~]$ sqlplus / as sysdba
SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 12
Current log sequence 14

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

Enable Archivelog

[oracle@enode01 ~]$ srvctl start instance -db eastdb –instance eastdb1
-startoption mount
[oracle@enode01 ~]$ sqlplus / as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Sat Sep 12 15:05:12 2015
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit
Production
With the Partitioning, Real Application Clusters, Automatic Storage
Management, OLAP,
Advanced Analytics and Real Application Testing options
SQL> alter database archivelog;
Database altered.
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 13
Next log sequence to archive 15
Current log sequence 15
SQL> exit
[oracle@enode01 ~]$ srvctl stop database -db eastdb
[oracle@enode01 ~]$ srvctl start database -db eastdb
[oracle@enode01 ~]$

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

Check force logging

[oracle@enode01 ~]$ sqlplus / as sysdba
SQL> SELECT force_logging FROM v$database;
FORCE_LOGGING
--------------------
NO
SQL> ALTER DATABASE FORCE LOGGING;
Database altered.
SQL> SELECT force_logging FROM v$database;
FORCE_LOGGING
--------------------
YES
SQL>

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

SQL> select thread#, group#, bytes/1024/1024 MB from v$log;
THREAD# GROUP# MB
---------- ---------- ----------
1 1 50
1 2 50
2 3 50
2 4 50
SQL> alter database add standby logfile thread 1
group 5 size 50M,
group 6 size 50M,
group 7 size 50M;
Database altered.
SQL> alter database add standby logfile thread 2
group 8 size 50M,
group 9 size 50M,
group 10 size 50M;
Database altered.
SQL> select thread#, group#, bytes/1024/1024 MB from v$standby_log;
THREAD# GROUP# MB
---------- ---------- ----------
1 5 50
1 6 50
1 7 50
2 8 50
2 9 50
2 10 50
6 rows selected.
SQL>

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.

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.

  1. Local Destination (FRA)
  2. Remote Destination (The dataguard service)

So let's do it.

Set Archivelog Destinations

SQL> alter system set
log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST
valid_for=(ALL_LOGFILES,ALL_ROLES) db_unique_name=eastdb' scope=both
sid='*';
System altered.

SQL> alter system set log_archive_dest_state_1='enable' scope=both
sid='*';
System altered.
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=westdb'
scope=both sid='*';
System altered.
SQL> alter system set log_archive_dest_state_2='DEFER' scope=both
sid='*';
System altered.
SQL>
SQL>
SQL> alter system set log_archive_max_processes=4 scope=both sid='*';       <- Set this value to 10 if the env. allows it.
System altered.
SQL>

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

SQL> alter system set standby_file_management='auto' scope=both
sid='*';
System altered.
SQL>

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

SQL> alter system set fal_server='westdb' scope=both sid='*';
System altered.
SQL> exit
[oracle@enode01 ~]$

That concludes the prepartion of the Primary.

  • oracle_guard_installation.1603613285.txt.gz
  • Last modified: 2020/10/25 08:08
  • by andonovj