1. Disaster Recovery on Oracle Database Appliance Using Oracle Data Guard
  2. Scenario: Configure Oracle Data Guard Manually on the DCS Stack

7 Scenario: Configure Oracle Data Guard Manually on the DCS Stack

This scenario describes setting up Oracle Data Guard on Oracle Database Appliance on the DCS stack.

  • Environment
    Understand the primary and standby database environment topologies used in the subsequent Data Guard setup example using Oracle Database Appliance.
  • Configuring Oracle Data Guard
    Understand the steps to configure Oracle Data Guard manually. it is highly recommended to configure Oracle Data Guard with Oracle Data Guard Broker.

Environment

Understand the primary and standby database environment topologies used in the subsequent Data Guard setup example using Oracle Database Appliance.

Description of manual_dg_configuration.png follows
Description of the illustration manual_dg_configuration.png
Component Primary Oracle Database Appliance Standby Oracle Database Appliance
Appliance Name appliance#1 appliance#2
Host Names proddb1, proddb2 stbydb1, stbydb2
Database Name chicago chicago
Database Unique Name chicago boston
Instance Name chicago1, chicago2 chicago1, chicago2
SCAN Name and IPs proddb-scan (10.1.27.2, 10.1.27.3) stbydb-scan (10.1.27.4, 10.1.27.5)
Grid Infrastructure Software Installation /u01/app/19.21.0.0/grid /u01/app/19.21.0.0/grid
Oracle Database Software Installation /u01/app/odaorahome/oracle/product/19.0.0.0/db_home1 /u01/app/odaorahome/oracle/product/19.0.0.0/db_home1
Database storage ASM ASM
ARCHIVELOG mode Yes Yes
FORCE LOGGING mode Yes Yes

Parent topic: Scenario: Configure Oracle Data Guard Manually on the DCS Stack

Configuring Oracle Data Guard

Understand the steps to configure Oracle Data Guard manually. it is highly recommended to configure Oracle Data Guard with Oracle Data Guard Broker.

Follow these steps:
  1. Create Standby Redo Logs.
    Standby Redo Logs (SRLs) receives redo data from the primary database in real time minimizing transport and apply lag. In advance of the primary standby setup, Oracle recommends that standby redo logs be created on the primary database as well so that it is immediately ready to receive redo data following a Data Guard role transition. Create Standby Redo Logs (SRL) on the primary database. Each thread of the standby redo log must have at least one more redo log group than the corresponding thread of the online redo log. For example:
    SQL> alter database add standby logfile thread 1 group 7 size 1G, group 8 size 1G, group 9 size 1G; 
SQL> alter database add standby logfile thread 2 group 11 size 1G,group 12 size 1G, group 13 size 1G;
    To check the number of online redo logs and their sizes, use the following query:
    SQL> select thread#, group#, bytes/1024/1024/1024 SIZE_IN_GB, status from v$log;

    Note that the size of the standby redo logs must match the size of the redo logs. On the Oracle Database Appliance platform, the standby redo logs must be created on the REDO disk group which resides on the solid state disks. On Oracle Database Appliance Small/Medium/Large and on X8-2 HA models the control file and online logs are stored in RECO diskgroup as there is no REDO disk group. To validate the size of each log file and number of log groups in the standby redo log, use the following query:

     SQL> select group#, thread#, bytes/1024/1024/1024 SIZE_IN_GB from v$standby_log;
  2. Enable archivelog mode on primary database.

    Information:

    Archiving is the process of saving and protecting redo information in the form of archive files before the redo logs of an active database are overwritten in a circular manner. Databases created on Oracle Database Appliance have archiving turned on by default.
    Verify that the primary database is running in ARCHIVELOG mode.
    SQL> archive log list
    If the primary database is not running in ARCHIVELOG mode, then enable ARCHIVELOG mode as follows:
    1. Shut down both instances on Oracle Database Appliance.
      $ srvctl stop database -d chicago
    2. Start and mount one instance in exclusive mode.
      SQL> startup mount exclusive;
    3. Turn on archiving.
      SQL> alter database archivelog;
    4. Shut down the instance.
      SQL> shutdown immediate;
    5. Restart the database.
      $ srvctl start database -d chicago
  3. Enable FORCE LOGGING mode.
    Force logging enables you to capture database operations performed with the NOLOGGING attribute. This ensures integrity of your standby database. Verify if FORCE LOGGING has already been enabled on your primary database.
    SQL> select force_logging from v$database;
    If FORCE LOGGING is not enabled, then enable it using the following commands:
    SQL> alter database force logging;
  4. Configure Flashback Database feature.
    The Oracle Flashback Database feature provides a fast alternative to performing incomplete database recovery. Although using the Flashback Database feature is optional, it can be very useful for faster reinstating of the old primary database after a failover. Thus, if you do a failover to the standby and the old primary can be repaired, you do not have to rebuild the old primary database as a standby database but simply flashback and let Oracle Data Guard resynchronize from that point onwards. Check if the primary database has Flashback Database enabled, and if required, enable it.
    SQL> select flashback_on from v$database; 
SQL> alter database flashback on;
    Note that enabling Flashback Database requires additional space consumption in the Fast Recovery Area, that is, RECO disk group. The space used by flashback logs can be controlled by setting the parameter DB_FLASHBACK_RETENTION_TARGET to a desired value. This value is specified in minutes. For example:
    SQL> alter system set DB_FLASHBACK_RETENTION_TARGET=120 scope=both sid='*';
  5. Enable standby file management.
    When the primary database adds or drops a datafile, the corresponding action must also be automatically taken on the standby database. This operation can be enabled using automated standby file management.
    SQL> alter system set STANDBY_FILE_MANAGEMENT=AUTO scope=both sid='*';
  6. Create the database home on the standby if it does not exist. For example:
    [root@stbydb1]# odacli create-dbhome -v 19.14.0.0.220118

    The database home version on the standby must be identical to database home version on the primary.

  7. Setup TNS entries and listeners.
    Oracle Net Service Names must be configured to enable redo transportation across the databases. Update tnsnames.ora file to include the TNS alias for both primary and standby databases. Note that in the Oracle Database Appliance, the tnsnames.ora file is located in the network/admin directory of the Oracle database home.
    $ vi $ORACLE_HOME/network/admin/tnsnames.ora
Primary
chicago = 
(DESCRIPTION = 
 (ADDRESS = (PROTOCOL = TCP)(HOST = proddb-scan)(PORT = 1521))
 (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = chicago.oracle.com) 
  ) 
 )

boston = 
(DESCRIPTION = 
 (ADDRESS = (PROTOCOL = TCP)(HOST = stbydb-scan)(PORT = 1521)) 
 (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = boston.oracle.com) 
  ) 
 ) 
Standby
chicago = 
(DESCRIPTION = 
 (ADDRESS = (PROTOCOL = TCP)(HOST = proddb-scan)(PORT = 1521)) 
 (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = chicago.oracle.com) 
  ) 
 ) 
boston = 
(DESCRIPTION = 
 (ADDRESS = (PROTOCOL = TCP)(HOST = stbydb-scan)(PORT = 1521)) 
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = boston.oracle.com) 
 ) )
  8. Setup Redo Transport Service in deferred mode. This step is not needed if Oracle Data Guard Broker is configured.
    The Oracle Data Guard redo transport mechanism uses Oracle Net connections to send the redo between the databases. Redo transport is enabled by setting the LOG_ARCHIVE_DEST_n parameter. For example, the following setup enables log shipping and uses LGWR based transmission in asynchronous mode.
    SQL> alter system set log_archive_dest_2='SERVICE=boston LGWR ASYNC REGISTER VALID_FOR=(online_logfile,primary_role) 
REOPEN=60 DB_UNIQUE_NAME=boston' scope=both sid='*'; 
SQL> alter system set log_archive_dest_state_2='defer' scope=both sid='*';

    For more information about redo log transmission options, see the Oracle Data Guard Concepts and Administration Guide.

  9. Setup Fetch Archive Log Server. This step is not needed if Oracle Data Guard Broker is configured.
    When the database is in standby role and the primary is unable to send any missing log files, then the standby database can use the FAL_SERVER setting to pull those missing log files. The FAL_SERVER parameter is uses the Oracle Net service name.
    SQL> alter system set FAL_SERVER=boston scope=both sid='*';
  10. Create a pfile from the spfile on the primary database.
    [oracle@proddb1]$ export ORACLE_HOME=u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1 
[oracle@proddb1]$ export ORACLE_SID=chicago1 
[oracle@proddb1]$ export PATH=$ORACLE_HOME/bin:$PATH 
[oracle@proddb1]$ sqlplus / as sysdba 
SQL> create pfile='/tmp/chicago.pfile' from spfile;
  11. Add or modify the parameters on the primary and standby.

    Primary:

    *.db_block_checking=FULL 
*.db_block_checksum=FULL 
*.db_lost_write_protect=TYPICAL 
*.db_unique_name=chicago 
*.listener_networks='((NAME=net1)(LOCAL_LISTENER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=primary node0 vip) (PORT=1521)))))','((NAME=net1)(LOCAL_LISTENER=( DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=primary node1 vip)(PORT=1521) ))))','((NAME=net1)(REMOTE_LISTENER=primary scan name:1521))'
*.log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) MAX_FAILURE=1 REOPEN=5 DB_UNIQUE_NAME=chicago ALTERNATE=log_archive_dest_10'
*.log_archive_dest_10='LOCATION=+DATA/chicago/arc10 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago ALTERNATE=log_archive_dest_1'
# if DB is TDE enabled
*.wallet_root='+DATA/CHICAGO'

    Standby:

    *.audit_file_dest='/u01/app/oracle/admin/boston/adump' 
*.db_block_checking=FULL 
*.db_block_checksum=FULL 
*.db_lost_write_protect=TYPICAL 
*.db_unique_name=boston 
*.listener_networks='((NAME=net1)(LOCAL_LISTENER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=standby node0 vip) (PORT=1521)))))','((NAME=net1)(LOCAL_LISTENER=( DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=standby node1 vip)(PORT=1521) ))))','((NAME=net1)(REMOTE_LISTENER=standby scan name:1521))' 
*.log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) MAX_FAILURE=1 REOPEN=5 DB_UNIQUE_NAME=boston ALTERNATE=log_archive_dest_10'
*.log_archive_dest_10='LOCATION=+DATA/boston/arc10 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston ALTERNATE=log_archive_dest_1' 
# if DB is TDE enabled
*.wallet_root='+DATA/BOSTON'

    Set data protection parameters. Refer to My Oracle Support Note 1302539.1 - Best Practices for Corruption Detection, Prevention, and Automatic Repair - in a Data Guard Configuration On ODA Small/Medium/Large On Oracle Database Appliance X8-2-HA models, the controlfile and online logs are stored in the RECO disk group as there is no REDO disk group. Databases use listener_networks instead of local_listener and remote_listener parameters starting from Oracle Database Appliance release 19.6 on bare metal systems.

  12. Create storage structures for the database on the standby.
    [root@stbydb1]$ # odacli create-dbstorage -n chicago -u boston
{ 
"jobId" : "054dac68-9efe-4f0d-a027-5515d46ada8a", 
"status" : "Created", 
"message" : null, 
"reports" : [ ], 
"createTimestamp" : "October 18, 2021 14:14:11 PM CEST", 
"resourceList" : [ ], 
"description" : "Database storage service creation with db name: chicago", 
"updatedTime" : "October 18, 2021 14:14:11 PM CEST" 
} 
[root@stbydb1]# odacli describe-job -i "054dac68-9efe-4f0d-a027-5515d46ada8a"
Job details 
---------------------------------------------------------------- 
ID: 054dac68-9efe-4f0d-a027-5515d46ada8a 
Description: Database storage service creation with db name: chicago 
Status: Success
  13. Copy the password file from the primary database to the first standby system.
    [oracle@proddb1]$ srvctl config database -d chicago |grep Password
Password file: +DATA/CHICAGO/PASSWORD/pwdchicago.386.1086365117
[oracle@proddb1 ~]$ asmcmd --privilege sysdba
ASMCMD> pwcopy +DATA/CHICAGO/PASSWORD/pwdchicago.386.1086365117 /tmp/pwdchicago
copying +DATA/CHICAGO/PASSWORD/pwdchicago.386.1086365117 -> /tmp/pwdchicago
[oracle@proddb1]$ scp /tmp/pwdchicago oracle@stbydb1:/u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1
/dbs/orapwchicago
  14. Copy the modified pfile to the first standby host and mount the standby database. Make a note of the path where the standby control file is created.
    [oracle@proddb1]$ scp /tmp/chicago.pfile oracle@stbydb1.oracle.com:/tmp/boston.pfile 
[oracle@stbydb1]$ export ORACLE_HOME=/u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1 
[oracle@stbydb1]$ export ORACLE_SID=chicago1 
[oracle@stbydb1]$ export PATH=$ORACLE_HOME/bin:$PATH 
[oracle@stbydb1]$ cp /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1/dbs/orapwboston /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1/dbs/orapwboston1 
[oracle@stbydb1]$ rman target / 
RMAN> startup nomount pfile='/tmp/boston.pfile'; 
RMAN> restore standby controlfile from service chicago; 
Starting restore at 19-OCT-21 
using target database control file 
instead of recovery catalog 
allocated channel: ORA_DISK_1 
channel ORA_DISK_1: SID=483 instance=boston1 device type=DISK 
channel ORA_DISK_1: starting datafile backup set restore 
channel ORA_DISK_1: using network backup set from service chicago 
channel ORA_DISK_1: restoring control file 
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02 output file name=+FLASH/BOSTON/CONTROLFILE/current.256.1086380745 
Finished restore at 19-OCT-21
  15. Update the Control File parameter Edit the pfile /tmp/chicago.pfile and replace the control_files parameter to show the new path from the previous output. For example:
    control_files= ‘+RECO/BOSTON/CONTROLFILE/current.256.1086380745'
  16. Start the standby instance in nomount mode using the modified pfile. Create the spfile and restart the instance with the spfile.
    [oracle@stbydb1$ export ORACLE_HOME=/u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1
[oracle@stbydb1$ export ORACLE_SID=chicago1 
[oracle@stbydb1$ export PATH=$ORACLE_HOME/bin:$PATH
[oracle@stbydb1]$ sqlplus / as sysdba
SQL> create spfile='+DATA/BOSTON/PARAMETERFILE/spfilechicago' from pfile='/tmp/chicago.pfile'; 
SQL> !echo "spfile='+DATA/BOSTON/PARAMETERFILE/spfilechicago'" > /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1/dbs/initchicago1.ora
SQL> !echo "spfile='+DATA/BOSTON/PARAMETERFILE/spfilechicago'" > /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1/dbs/initchicago2.ora
SQL> startup mount force;
  17. For TDE-enabled databases, copy the TDE wallet from the primary system:
    1. Take a backup of the wallet on the primary. Log in as oracle user. and create an empty keystore.
       mkdir -p /tmp/backup/
[oracle@proddb1$ export ORACLE_HOME=/u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1
[oracle@proddb1$ export ORACLE_SID=chicago1 
[oracle@proddb1$ export PATH=$ORACLE_HOME/bin:$PATH

sqlplus / as sysdba
SQL> administer key management create keystore '/tmp/backup/' identified by "password";
keystore altered.
    2. Merge the keystore of the database into the file system keystore. For example:
      SQL>  administer key management merge keystore '+DATA/db_unique_name/tde/' identified by "password" into existing keystore '/tmp/backup/' identified by "password" with backup;
keystore altered.
    3. Create a new keystore on the standby and merge the keystore of the primary into it.
      mkdir /tmp/backup
scp oracle@primary_db_host:/tmp/backup/* /tmp/backup/
sqlplus / as sysdba

[oracle@stbydb1$ export ORACLE_HOME=/u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1
[oracle@stbydb1$ export ORACLE_SID=boston1 
[oracle@stbydb1$ export PATH=$ORACLE_HOME/bin:$PATH
SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE identified by "password";
    4. Merge the keystore from the primary into the newly-created keystore.
      SQL> administer key management merge keystore '/tmp/backup/' identified by "password" into existing keystore 
'+DATA/MILAN/tde' identified by "password" with backup;
    5. Create auto login.
      SQL> administer key management create auto_login keystore from keystore identified by "password";
keystore altered.
  18. Enable parallelism and set SECTION SIZE=64MB. To use parallelism during the restore, determine the number of CPUs on your server by running the following:
    [oracle@stbydb1]$ grep -c ^processor /proc/cpuinfo
    Make the following RMAN configuration changes on the standby database. The following example uses 8 preconfigured channels for RMAN to use during the recovery process.
    [oracle@stbydb1]$ rman target / 
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK; 
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 8;
  19. Restore the Standby Database from the primary database service Backing up a single large file in parallel, The multi section backup and restore capability in RMAN improves backup and recovery rates. RMAN divides the work among multiple channels and each channel acts upon a file section in a file. If you specify a small section size that would produce more than 256 sections, then RMAN increases the section size to a value that results in exactly 256 sections. The Section size clause depends on various factor such as network bandwidth, number of channels, sizes of data files, and application datafile sizes.
    oracle@stbydb1]$ sqlplus system/welcome1@chicago 
SQL> select TABLESPACE_NAME, bytes/1024/1024/1024 SIZE_IN_GB from dba_data_files;
TABLESPACE_NAME SIZE_IN_GB 
------------------------------ ---------- 
UNDOTBS1 .102539063 
SYSTEM .947265625 
SYSAUX .91796875 
UNDOTBS2 .024414063 
USERS .004882813
    For example, when you run the following command on the standby system, you specify a backup section size of 64MB.
    [oracle@stbydb1]$ rman target / 
RMAN> restore database from service chicago section size 64M; 
RMAM> recover database from service chicago; 
RMAN> backup spfile;
    Note: If the backup spfile failed, then reset CONTROLFILE AUTOBACKUP FORMAT in the control file using the following RMAN command: 
    RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR
  20. Enable log shipping on the primary. Run this step only if you have not configured Oracle Data Guard Broker.
    [oracle@proddb1]$ sqlplus / as sysdba 
SQL> alter system set log_archive_dest_state_2='enable' scope=both;
  21. Enable Flashback Database on the standby and adjust retention as required. Run this step only if you have not configured Oracle Data Guard Broker.
    SQL> alter database flashback on; 
SQL> alter system set DB_FLASHBACK_RETENTION_TARGET=120;
  22. Start managed recovery on the standby. Run this step only if you have not configured Oracle Data Guard Broker.
    [oracle@stbydb1]$ sqlplus / as sysdba 
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
  23. Register the standby database with Oracle Clusterware. Note that the instance name on the primary and standby must be the same. Specify the instance name in the format dbname[0|1] on Oracle RAC databases and dbname for single-instance databases.
    [oracle@stbydb1]$ export ORACLE_HOME=/u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1 
[oracle@stbydb1]$ export PATH=$ORACLE_HOME/bin:$PATH

Example with single-instance Oracle Database:
[oracle@stbydb1]$ srvctl add database -db boston -oraclehome /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1 -dbtype SINGLE -instance chicago -node stbydb1 -dbname chicago -diskgroup 'DATA,RECO,FLASH' -role physical_standby -spfile '+DATA/BOSTON/PARAMETERFILE/spfileboston' -startoption mount -acfspath '/u01/app/odaorahome,/u01/app/odaorabase0,/u01/app/odaorabase1'

Example with Oracle RAC Database:
[oracle@stbydb1]$ srvctl add database -db boston -oraclehome /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1 -dbtype RAC -dbname chicago -diskgroup 'DATA,RECO,FLASH' -role physical_standby -spfile '+DATA/BOSTON/PARAMETERFILE/spfileboston' -startoption mount -acfspath '/u01/app/odaorahome,/u01/app/odaorabase0,/u01/app/odaorabase1' 
[oracle@stbydb1]$ srvctl add instance -db boston -instance chicago1 -node stbydb1 
[oracle@stbydb1]$ srvctl add instance -db boston -instance chicago2 -node stbydb2
  24. Copy the password file to Oracle ASM and verify that the password file points to Oracle ASM.
    [oracle@stbydb1]$ export ORACLE_HOME=/u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1 
[oracle@stbydb1]$ export ORACLE_SID=chicago1 
[oracle@stbydb1]$ export PATH=$ORACLE_HOME/bin:$PATH 
[oracle@stbydb1 ~]$ asmcmd --privilege sysdba
ASMCMD>mkdir +DATA/BOSTON/PASSWORDFILE
ASMCMD> pwcopy /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1/dbs/orapwboston +DATA/BOSTON/PASSWORDFILE/pwdboston --dbuniquename boston 
copying /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1/dbs/orapwboston -> +DATA/BOSTON/PASSWORDFILE/pwdboston 
[oracle@stbydb1]$ srvctl config database -db boston|grep Password

    Note: If the database resides on Oracle ACFS, since the password file format is case-sensitive, it must follow the orapwORACLE_SID format.

  25. Set the parameters and create the Oracle Data Guard Broker configuration.
    Note: Flashback database is required to re-instantiate a failed primary after a failover role transition. Optionally enable flashback on both primary and standby. The standby database can begin using flashback with the PostCR script as follows:
    [oracle@stbydb1]$ sqlplus / as sysdba 
alter system set dg_broker_config_file1='+DATA/BOSTON/dr1.dat' scope=both; 
alter system set dg_broker_config_file2='+DATA/BOSTON/dr2.dat' scope=both; 
alter system set db_flashback_retention_target=120 scope=spfile; 
alter database flashback on; 
alter system set dg_broker_start=true; 
[oracle@stbydb1]$ srvctl stop database -db boston 
[oracle@stbydb1]$ srvctl start database -db boston -startoption mount 
[oracle@stbydb1]$ sqlplus sys/welcome1@chicago as sysdba 
alter system set dg_broker_config_file1='+DATA/CHICAGO/dr1.dat' scope=both; 
alter system set dg_broker_config_file2='+DATA/CHICAGO/dr2.dat' scope=both; 
alter system set dg_broker_start=TRUE;
Wait 1 min 
[oracle@stbydb1]$ dgmgrl sys/welcome1@chicago 
CREATE CONFIGURATION dgconfig AS PRIMARY DATABASE IS CHICAGO CONNECT IDENTIFIER IS CHICAGO; 
ADD DATABASE BOSTON AS CONNECT IDENTIFIER IS BOSTON ; 
ENABLE CONFIGURATION
    If ALTER DATABASE FLASHBACK ON failed with ORA-38788, let the standby sync up and run the following steps to enable flashback after that:
    [oracle@stbydb1]$ sqlplus / as sysdba 
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 
SQL> alter database flashback on; 
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
  26. Verify using SQL*Plus and SRVCTL.
    [oracle@stbydb1]$ srvctl config database -d chicago 
[oracle@stbydb1]$ srvctl config database -d boston 
[oracle@stbydb1]$ sqlplus / as sysdba 
SQL> select FORCE_LOGGING, FLASHBACK_ON, OPEN_MODE, DATABASE_ROLE, SWITCHOVER_STATUS, DATAGUARD_BROKER, PROTECTION_MODE from v$database; 
SQL> select PROCESS,PID,DELAY_MINS from V$MANAGED_STANDBY;
  27. Verify Oracle Data Guard using DGMGRL.
    $ dgmgrl DGMGRL> connect sys/welcome1@boston 
DGMGRL> show configuration verbose 
DGMGRL> show database verbose chicago 
DGMGRL> show database verbose boston 
DGMGRL> validate database chicago 
DGMGRL> validate database boston

    The DGMGRL> show database verbose boston command displays the following: 

    Database Warning(s):
ORA-16789: standby redo logs configured incorrectly
ORA-16789: standby redo logs configured incorrectly
Drop all standby logs on the standby side and recreate them.
SQL> alter database recover managed standby database cancel;
SQL> select group# from v$standby_log;
SQL> alter database drop logfile group X; -- group# is coming from the previous query
SQL> alter database add standby logfile thread 1 group 5 size 1G, group 6 size 1G, group 7 size 1G;
SQL> alter database add standby logfile thread 2 group 8 size 1G, group 9 size 1G, group 10 size 1G;
SQL> alter database recover managed standby database disconnect from session;
  28. Setup Oracle Clusterware Role Based Services. Refer to Client Failover Best Practices for Highly Available Oracle Databases.
  29. Register the databases:
    [oracle@stbydb1]$ dgmgrl sys/welcome1@boston as sysdba 
DGMGRL> edit database 'boston' set state='apply-off'; Succeeded. 
DGMGRL> sql 'ALTER DATABASE OPEN READ ONLY'; Succeeded.
[oracle@stbydb1]# odacli list-databases DCS-10032:Resource database is not found.
[oracle@stbydb1]# odacli register-database -c OLTP -s odb2 -sn boston.oracle.com -nn Public-network -t RAC Job details 
---------------------------------------------------------------- 
ID: 841f99e0-a66f-4b23-b753-b04f992a6c33 Description: Discover Components : db [oracle@stbydb1]# odacli describe-job -i 841f99e0-a66f-4b23-b753-b04f992a6c33
Job details 
---------------------------------------------------------------- 
ID: 9947df75-e9f4-4a42-bcd7-ec23561a2f3f 
Description: Database service registration with db service name: test.com 
Status: Success 
Created: February 18, 2022 12:52:04 PM CET 
Message: Task Name Start Time End Time Status 
---------------------------------------- ----------------------------------- ----------------------------------- ---------- Validate Hugepages For Register DB February 18, 2022 12:52:05 PM CET February 18, 2022 12:52:05 PM CET Success Enable OMF parameters February 18, 2022 12:52:06 PM CET February 18, 2022 12:52:07 PM CET Success Setting db character set February 18, 2022 12:52:07 PM CET February 18, 2022 12:52:07 PM CET Success Move Spfile to right location February 18, 2022 12:52:07 PM CET February 18, 2022 12:52:15 PM CET Success Enable DbSizing Template February 18, 2022 12:52:15 PM CET February 18, 2022 12:53:26 PM CET Success Running DataPatch February 18, 2022 12:53:26 PM CET February 18, 2022 12:53:28 PM CET Success Reset Associated Networks for Databse February 18, 2022 12:53:29 PM CET February 18, 2022 12:53:33 PM CET Success Reset Associated Networks February 18, 2022 12:53:33 PM CET February 18, 2022 12:53:33 PM CET Success
[oracle@stbydb1]# odacli list-databases
ID DB Name DB Type DB Version CDB Class Shape Storage Status DbHomeID 
---------------------------------------- ---------- -------- -------------------- ---------- -------- -------- ---------- ------------ ---------------------------------------- 9139ea53-449d-413a-841b-b157c084f3e0 bikazug RAC 19.14.0.0.220118 false OLTP odb2 ASM CONFIGURED 2afd69ed-f2cd-4345-9860-480f9e21f3ad
[oracle@stbydb1]# odacli describe-database -i fbc4a32e-fec4-403d-b7b8-b08a3c01ab46
Database details 
---------------------------------------------------------------- 
ID: 9139ea53-449d-413a-841b-b157c084f3e0 
Description: chicago 
DB Name: chicago 
DB Version: 19.14.0.0.220118 
DB Type: RAC 
DB Role: STANDBY DB 
Target Node Name: 
DB Edition: EE 
DBID: 1128302500 Instance Only 
Database: false 
CDB: false 
PDB Name: 
PDB Admin User Name: 
SEHA Enabled: false 
Class: OLTP 
Shape: odb2 
Storage: ASM 
DB Redundancy: MIRROR 
CharacterSet: AL32UTF8 
National CharacterSet: AL16UTF16 
Language: AMERICAN 
Territory: AMERICA 
Home ID: 2afd69ed-f2cd-4345-9860-480f9e21f3ad 
Console Enabled: false 
TDE Wallet Management: 
TDE Enabled: false 
Level 0 Backup Day: 
AutoBackup Enabled: true 
Created: February 18, 2022 12:52:02 PM CET 
DB Domain Name: 
Associated Networks: Public-network 
CPU Pool Name:

    For TDE enabled databases, specify the -tp option: 

    # odacli register-database -c OLTP -s odb2 -sn boston.us.oracle.com -nn Public-network -t RAC -tp
Enter SYS, SYSTEM and PDB Admin user password:
Retype SYS, SYSTEM and PDB Admin user password:
Enter TDE wallet password:
Retype TDE wallet password:
{
  "jobId" : "fb2b8a1f-bd5a-4f9b-8ba1-8070ba63c508",
  "status" : "Created",
  "message" : null,
  "reports" : [ ],
  "createTimestamp" : "December 09, 2023 13:45:51 PM CET",
  "resourceList" : [ ],
  "description" : "Database service registration with DB service name: boston.us.oracle.com",
  "updatedTime" : "December 09, 2023 13:45:51 PM CET",
  "jobType" : null
}

    Note that opening the database in read-only mode is a one-time operation required for registration with Oracle Database Appliance and complies with Oracle Active Data Guard licensing permissions.

  30. Enable log shipping again and restart the standby database.
    [oracle@stbydb1]$ dgmgrl sys/welcome1@boston as sysdba 
DGMGRL> edit database 'boston' set state='apply-on';
Succeeded.
[oracle@stbydb1]$ srvctl stop database -db boston 
[oracle@stbydb1]$ srvctl start database -db boston
  31. Verify switchover operation with Oracle Data Guard:
    $ dgmgrl DGMGRL> connect sys/welcome1@boston 
DGMGRL> switchover to boston
DGMGRL> connect sys/welcome1@chicago 
DGMGRL> switchover to chicago;
  32. Verify failover operation with Oracle Data Guard.

    Connect to standby before failover:

    $ dgmgrl DGMGRL> connect sys/welcome1@boston 
DGMGRL> failover to boston 
DGMGRL> reinstate database chicago

    Connect to former primary before failover:

    DGMGRL> connect sys/welcome1@chicago 
DGMGRL> failover to chicago; 
DGMGRL> reinstate database boston

Parent topic: Scenario: Configure Oracle Data Guard Manually on the DCS Stack