In an Oracle Data Guard configuration, the primary and standby databases transmit information in both directions. This requires basic configuration, network tuning, and opening of ports at both the primary and standby databases.

It is vital that the bandwidth exists to support the redo generation rate of the primary database.

Follow instructions in Assessing and Tuning Network Performance for Data Guard and RMAN (Doc ID 2064368.1) to assess and tune the network link between the on-premises and cloud environments.

• Name resolution

  • For ExaDB-C@C, because the clusters reside on the on-premises network, the on-premises DNS should resolve each cluster, and no further configuration should be necessary.

  • For Oracle Exadata Database Service, name resolution between the clusters must be configured.

    This can be done either using a static file like /etc/hosts, or by configuring the on-premises DNS to properly resolve the public IP address of the OCI instance. In addition, the on-premises firewall must have Access Control Lists configured to allow SSH and Oracle Net to be accessed from the on-premises system to OCI.

• Oracle Data Guard in a DR configuration requires access from the Cloud instance to the on-premises database; the primary database listener port must be opened with restricted access from the Cloud IP addresses using features like iptables.

  Because every corporation has different network security policies, the network administrator must perform operations like the cloud-side network configuration shown in Cloud Network Prerequisites.

• Prompt-less SSH from Oracle Cloud to the on-premises machine. This is configured both for on-premises to Cloud during the provisioning process and from the Cloud to on-premises.

• The configuration of the on-premises firewall to allow inbound SSH connectivity from the Cloud to the on-premises machine.

• It is strongly recommended that you complete the network assessment described above in Evaluate Network Using oratcptest. Setting the appropriate TCP socket buffers setting is especially important for ASYNC redo transport.

• It is recommended that the RDBMS software be the same on the primary and standby database for instantiation. If the current on-premises Oracle Database release is not available in Oracle Exadata Database Service, then the primary database must be on the same major database release and the same or lower Release Update (RU).

Most MAA best practices for Data Guard are part of the process described here; however, the Standby Redo Log should be created on the primary database before starting this process.

See Oracle Data Guard Configuration Best Practices for information.

After the networking steps are implemented successfully, run the command below to validate that the connection is successful between all sources and all targets in both directions.

1. As the oracle OS user on all nodes of the on-premises environment, use curl to test connectivity between all on-premises and all cloud nodes.

   [oracle@on-prem1]$ curl -v telnet://<FQDN-CLOUD-HOST1>:22 (or other available port)
   * Rebuilt URL to: telnet://<FQDN-CLOUD-HOST1>:22/
   *   Trying <CLOUD-HOST1-IP>...
   * TCP_NODELAY set
   * Connected to <FQDN-CLOUD-HOST1> (<CLOUD-HOST1-IP>) port 22 (#0)
   SSH-2.0-OpenSSH_8.0
   ^C
   [oracle@on-prem1]$

2. As the oracle OS user on all nodes of the cloud environment, use curl to test connectivity between all cloud and all on-premises nodes.

   [oracle@cloud-exadata1]$ curl -v telnet://<FQDN-ON-PREM-HOST1>:22 (or other available port)
   * Rebuilt URL to: telnet://<FQDN-CLOUD-HOST1>:22/
   *   Trying <ON-PREM-HOST1-IP>...
   * TCP_NODELAY set
   * Connected to <FQDN-ON-PREM-HOST1> (<ON-PREM-HOST1-IP>) port 22 (#0)
   SSH-2.0-OpenSSH_8.0
   ^C
   [oracle@cloud-exadata1]$

If curl connection is successful, proceed to the next step.

This mount point exists in cloud platforms in /var/opt/oracle/dbaas_acfs. If there is no existing ACFS mount point for the primary cluster create one using the steps in Creating an Oracle ACFS File System. (An existing ACFS mount point can be used)

While it is strongly recommended that the on-premises database also be encrypted, leaving the primary database unencrypted as part of a hybrid Data Guard configuration can be configured and is better supported by new parameters in Oracle Database 19c (19.16) and later releases.

For all TDE configurations with Oracle Data Guard, the encryption wallet must be created on the primary database and the master key must be set whether or not the primary database will be encrypted with TDE.

The parameters required for TDE configuration differ depending with Oracle Database releases. The values may be different for each database in the Data Guard configuration.

• In Oracle Database release 19c (19.16) and later, the parameters TABLESPACE_ENCRYPTION, WALLET_ROOT, and TDE_CONFIGURATION are required to properly configure TDE.
• For Oracle Database 19c releases before 19.16, set parameters WALLET_ROOT, TDE_CONFIGURATION, and ENCRYPT_NEW_TABLESPACES.
• For releases earlier than Oracle Database19c, set parameters ENCRYPTION_WALLET_LOCATION and ENCRYPT_NEW_TABLESPACES.

In the following table use the links to find references for setting the primary and standby database parameters.

To configure Transparent Data Encryption using a TDE wallet follow the steps in Setup Guide for Wallet Based Transparent Data Encryption.

During the process the wallet is copied to the standby database. The master key stored in the wallet will be used by the standby database for encryption.

In the event of a switchover where the cloud standby database becomes the primary database, the key is used by the unencrypted on-premises database to decrypt the encrypted redo from the cloud database.

Failure to set the master key will result in failure of Data Guard managed recovery.

To confirm the master key is set properly:

• Verify that the MASTERKEYID column in V$DATABASE_KEY_INFO matches a key existing in V$ENCRYPTION_KEYS on the source database.

  In a multitenant container database (CDB) environment, check CDB$ROOT and all the PDBs except PDB$SEED.

Follow these best practices for sizing the online redo logs on the primary database before instantiation.

• All online redo log groups should have identically sized logs (to the byte).
• Online redo logs should reside on high performing disks (DATA disk groups) and on high redundancy disk groups if possible.
• Create a minimum of three online redo log groups per thread of redo on Oracle RAC instances.
• Create online redo log groups on shared disks in an Oracle RAC environment.
• Do not multiplex online redo logs (multiple members per log group) unless they are not placed on high redundancy disk groups.
• Size online redo logs to switch no more than 12 times per hour (every ~5 minutes) during peak workloads.

You can determine the peak rate by running the query below for a time period that includes the peak workload.

The peak rate could be seen at month-end, quarter-end, or annually. Using the guidance above, size the redo logs to handle the highest rate +10% in order for redo apply to perform consistently during these workloads.

SQL> SELECT thread#,sequence#,blocks*block_size/1024/1024 MB,
(next_time-first_time)*86400 sec,
 blocks*block_size/1024/1024)/((next_time-first_time)*86400) "MB/s"
 FROM v$archived_log
 WHERE ((next_time-first_time)*86400<>0)
 and first_time between to_date('2015/01/15 08:00:00','YYYY/MM/DD HH24:MI:SS')
 and to_date('2015/01/15 11:00:00','YYYY/MM/DD HH24:MI:SS')
 and dest_id=1 order by first_time;

   THREAD#  SEQUENCE#         MB        SEC       MB/s 
---------- ---------- ---------- ---------- ---------- 
         2       2291 29366.1963        831  35.338383 
         1       2565 29365.6553        781 37.6000708 
         2       2292 29359.3403        537  54.672887 
         1       2566 29407.8296        813 36.1719921 
         2       2293 29389.7012        678 43.3476418 
         2       2294 29325.2217       1236 23.7259075 
         1       2567 11407.3379       2658 4.29169973 
         2       2295 29452.4648        477 61.7452093 
         2       2296 29359.4458        954 30.7751004 
         2       2297 29311.3638        586 50.0193921 
         1       2568 3867.44092       5510 .701894903 

Choose the redo log size based on the peak generation rate with the following chart.

Without Flashback Database enabled, the old primary database would have to be recreated as a standby after a failover. If flashback database has not already been enabled, enable it now.

To enable flashback database, make sure you have sufficient space and I/O throughput in your Fast Recovery Area or RECO disk group, and evaluate any performance impact.

As the oracle OS user on the first node of the on-premises environment, run the command below to enable flashback database on the primary if it is not already enabled.

[oracle@on-prem1]$ echo "alter database flashback on;" | sqlplus -SILENT "/ as sysdba"

Database altered.

As the root OS user on the first node of the on-premises environment, use Oracle Trace File Analyzer to analyze all of your logs across your cluster to identify recent database errors.

The Event Summary gives you a real-time report the database status.

[root@on-prem1]# tfactl events -component RDBMS -database [DBname] -last 7d


Output from host : on-prem1
------------------------------

Event Summary:
INFO    :0
ERROR   :0
WARNING :0

Event Timeline:
No Events Found


Output from host : on-prem2
------------------------------

Event Summary:
INFO    :0
ERROR   :0
WARNING :0

Event Timeline:
No Events Found

As the root OS user on the first node of the on-premises environment, create the ACFS mount point required to execute prepareForStandby.

[root@on-prem1]# $(grep ^crs_home /etc/oracle/olr.loc |
 cut -d= -f2)/bin/crsctl stat res -w "TYPE == ora.acfs.type" |grep NAME
NAME=ora.datac1.acfsvol01.acfs

[root@on-prem1]# $(grep ^crs_home /etc/oracle/olr.loc |
 cut -d= -f2)/bin/crsctl stat res ora.datac1.acfsvol01.acfs -f |grep ^MOUNTPOINT_PATH
MOUNTPOINT_PATH=/acfs01

Create a directory for the dbname (oradb1 for this example):

[root@on-prem1]# mkdir /acfs01/oradb1
[root@on-prem1]# chown oracle:oinstall /acfs01/oradb1

Now you are prepared to start the process. First, you will prepare the primary database to become part of a Data Guard configuration. Gather the following information which will be passed to the workflow.

1. As the root OS user on the first node of the cloud environment, collect the standbyScanName and standbyScanPort required to execute dbaasca.

   [root@cloud-exadata1 ~]# $(grep ^crs_home /etc/oracle/olr.loc | cut -d=
    -f2)/bin/srvctl config scan |grep 'SCAN name:' | awk '{print $3}'
   cloud-exadata-scan.clientnet.default.oraclevcn.com,
   
   [root@cloud-exadata1 ~]# dbaascli grid getDetails | grep scanListenerTCPPorts |
    cut -d "[" -f2 | cut -d "]" -f1
    1521 

   Make note of these pieces of information to be passed to the workflow.

2. As the oracle OS user on the first node of the on-premises environment, collect the primary database unique name required to execute dbaasca.

   [oracle@on-prem1]$ echo "select DB_UNIQUE_NAME from v\$database;" |
    sqlplus -SILENT "/ as sysdba"
   
   DB_UNIQUE_NAME
   ------------------------------
   oradb1_onprem

3. As the oracle OS user on the first node of the on-premises environment, set the environment variable ORACLE_HOME pointing to the on-premises database Oracle Home.

   [oracle@on-prem1]$ srvctl config database -home
   oradb1     /u01/app/oracle/product/19.0.0.0/dbhome_1       19.0.0.0.0
   
   [oracle@on-prem1]$ export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_1

4. With that information gathered, run the prepareForStandby work flow with the appropriate replacements.

   As the oracle OS user on the first node of the on-premises environment, run dbaasca operation prepareForStandby with corresponding arguments.

   [oracle@on-prem1]$ 
   
   /var/opt/oracle/dbaastools/dbaasca/bin/dbca \
   -silent \
   -oui_internal \
   -configureDatabase \
   -prepareForStandby \
   -dgTNSNamesoraFilePath /acfs01/oradb1 \
   -sourceDB oradb1_onprem \
   -standbyDBUniqueName oradb1_cloud \
   -standbyScanName cloud-exadata-scan.clientnet.default.oraclevcn.com \
   -standbyScanPort 1521 \
   -standbyDBDomain clientnet.default.oraclevcn.com \
   -blobFileLocation /tmp 
   
   SYS_PASSWORD_PROMPT
   <ENTER_SYS_PASSWORD>
   
   Session ID of the current execution is: 53
   -----------------
   Running Create_dg_services job
   Completed Create_dg_services job
   25% complete
   -----------------
   Running Update_tnsnames_ora_file job
   Completed Update_tnsnames_ora_file job
   50% complete
   -----------------
   Running Update_ifile_entry job
   Completed Update_ifile_entry job
   75% complete
   -----------------
   Running Prepare_blob_file job
   Completed Prepare_blob_file job
   100% complete
   ---------- PLUGIN NOTES ----------
   Successfully created blob file: /tmp/oradb1_2024-11-21_10-59-53AM_137640.tar
   ---------- END OF PLUGIN NOTES ----------
   Look at the log file
    "/u01/app/oracle/cfgtoollogs/dbca/oradb1_onprem/oradb1_onprem.log"
    for further details.

   The workflow creates a zip file with required files to instantiate the standby database. For example, tnsnames.ora, TDE wallet and so on. This tar file is listed in the output of the command and must be copied from the to a location on the standby system.

5. As the oracle OS user on the first node of the on-premises environment, copy the generated blob file to the first node of the cloud environment.

   [oracle@on-prem1]$ scp
    /tmp/oradb1_2024-11-21_10-59-53AM_137640.tar opc@cloud-exadata1:/tmp

1. First, gather some information that has to be passed to the configureStandby work flow.

   As the oracle OS user on the first node of the on-premises environment, collect the primaryScanIPAddresses, primaryScanPort, and primaryServiceName required to execute dbaascli.

   [oracle@on-prem1]$ $(grep ^crs_home /etc/oracle/olr.loc |
    cut -d= -f2)/bin/srvctl config scan |grep 'SCAN name:' | awk '{print $3}'
   maafra2vm01-oe6ab-scan.clientnet.maafradefault.oraclevcn.com
   
   [oracle@on-prem1]$ srvctl config scan_listener -scannumber 1 |grep Endpoints
   Endpoints: TCP:1521/TCPS:2484
   
   [oracle@on-prem1]$ lsnrctl status | grep oradb1_onprem | cut -d'"' -f 2
   oradb1_onprem.clientnet.maafradefault.oraclevcn.com

2. As the root OS user on the first node of the cloud environment, run dbaascli operation configureStandby with corresponding arguments.

   [root@cloud-exadata1]# 
   
   dbaascli dataguard configureStandby \
   --dbname oradb1 \
   --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_3 \
   --standbyDBUniqueName oradb1_cloud \
   --primaryScanIPAddresses companyxyz.region.com \
   --primaryScanPort 1521 \
   --primaryServiceName oradb1_onprem.companyxyz.region.com \
   --protectionMode MAX_PERFORMANCE \
   --transportType ASYNC \
   --activeDG true \
   --standbyScanIPAddresses cloud-exadata-scan.clientnet.default.oraclevcn.com \
   --standbyScanPort 1521 \
   --standbyBlobFromPrimary /tmp/oradb1_2024-11-21_10-59-53AM_137640.tar
   
   
   Enter PRIMARY_DB_SYS_PASSWORD:
   <ENTER_PRIMARY_DB_SYS_PASSWORD>
   Enter PRIMARY_DB_TDE_PASSWORD:
   <ENTER_PRIMARY_DB_SYS_PASSWORD>
   Enter AWR_ADMIN_PASSWORD:
   <ENTER_AWR_ADMIN_PASSWORD>
   Enter AWR_ADMIN_PASSWORD (reconfirmation):
   <ENTER_AWR_ADMIN_PASSWORD>
   
   Loading PILOT...
   Session ID of the current execution is: 10015
   Log file location:
    /var/opt/oracle/log/oradb1/dataguard/configureStandby/pilot_2024-11-21_11-28-21-AM_270773
   -----------------
   Running Plugin_initialization job
   Enter PRIMARY_DB_SYS_PASSWORD
   *******************
   Enter PRIMARY_DB_TDE_PASSWORD
   ******************
   Enter AWR_ADMIN_PASSWORD
   ********************
   Completed Plugin_initialization job
   -----------------
   Running Validate_plugin_inputs job
   Completed Validate_plugin_inputs job
   -----------------
   Running Default_database_values_initialization job
   Completed Default_database_values_initialization job
   -----------------
   ...
   -----------------
   Running Generate_dgconfig_details job
   Acquiring native write lock: global_dgsystem_details_generation
   Releasing native lock: global_dgsystem_details_generation
   Completed Generate_dgconfig_details job
   Releasing lock: oradb1
   Releasing lock: _u02_app_oracle_product_19.0.0.0_dbhome_3
   -----------------
   Running Cleanup job
   Completed Cleanup job
   
   dbaascli execution completed

   Note:

   The Oracle MAA best practice is for the standby to be open read-only to enable Automatic Block Media Recovery; Use the flag --activeDG true

3. As the root OS user on the first node of the cloud environment, run the following commands to monitor the progress of the dbaascli operation configureStandby.

   [root@cloud-exadata1]# export dbName=oradb1
   [root@cloud-exadata1]# export dbUniqueName=oradb1_cloud
   
   [root@cloud-exadata1]# tail -20f `ls -t
    /var/opt/oracle/log/$dbName/dataguard/configureStandby/pilot_* | head -1`
   
   FINE: [2024-11-21 11:43:38.908 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
    -----------------
   FINE: [2024-11-21 11:43:38.910 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
    Running Open_pdbs job
   FINE: [2024-11-21 11:43:42.661 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
    Completed Open_pdbs job
   FINE: [2024-11-21 11:43:42.668 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
    90% complete
   FINE: [2024-11-21 11:43:42.692 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
    -----------------
   FINE: [2024-11-21 11:43:42.697 UTC][pool-334-thread-1][DBCAExecutor$DBCAExecutionProcessHandler.logOutput:96]
    Running Create_services job
   
   [root@cloud-exadata1]# tail -20f `ls -t
    /var/opt/oracle/log/$dbName/dataguard/configureStandby/$dbUniqueName/trace* | head -1`
   
   [pool-3-thread-4] [ 2024-11-21 12:03:55.015 UTC ] [CRSCache.getAttributesFromCRS:155]
     CRS: name: ora.oradb1_cloud.oradb1_oradb1p3.paas.oracle.com.svc, type 1, node: null
   [pool-3-thread-4] [ 2024-11-21 12:03:55.015 UTC ] [CRSCache.getAttributesFromCRS:156]
     attrs: [GLOBAL]
   [pool-3-thread-4] [ 2024-11-21 12:03:55.016 UTC ] [CRSCache.getAttributesFromCRS:163]
     CRS: [<GLOBAL:false>]
   [pool-3-thread-4] [ 2024-11-21 12:03:55.016 UTC ] [CRSNative.genericStartEntity:668]
     [MAJOR EVENT] About to start resource:
    Name: ora.oradb1_cloud.oradb1_oradb1p3.paas.oracle.com.svc, force:false node: null,
    options: 0, filter null
   [pool-3-thread-4] [ 2024-11-21 12:03:55.016 UTC ] [CRSNative.genericStartEntity:678]
     filter = null
   [pool-3-thread-4] [ 2024-11-21 12:03:55.016 UTC ] [CRSNative.genericStartEntity:679]
     node name = null
   
   [root@cloud-exadata1]# tail -20f /u01/app/grid/diag/crs/`hostname`/crs/trace/alert.log 
   
   2024-11-21 12:13:59.362 [CRSD(398369)]
    CRS-2772: Server 'maafra3vm02-qbi0z1' has been assigned to pool
    'ora.oradb1_oradb1_oradb1p3_ro.paas.oracle.com'.
   2024-11-21 12:13:59.363 [CRSD(398369)]
    CRS-2772: Server 'maafra3vm02-qbi0z2' has been assigned to pool
    'ora.oradb1_oradb1_oradb1p3_ro.paas.oracle.com'.
   2024-11-21 12:14:00.420 [CRSD(398369)]
    CRS-2772: Server 'maafra3vm02-qbi0z1' has been assigned to pool
    'ora.oradb1_oradb1_oradb1p4.paas.oracle.com'.
   2024-11-21 12:14:00.421 [CRSD(398369)]
    CRS-2772: Server 'maafra3vm02-qbi0z2' has been assigned to pool
    'ora.oradb1_oradb1_oradb1p4.paas.oracle.com'.