How to Use EM CLI to Verify Data Guard Configurations

EM CLI (Enterprise Manager Command Line Interface) allows users to access Enterprise Manager functionality from the operating system instead of from a browser.

Why would you use EM CLI instead of a browser?

It’s more efficient to execute commands from the operating system rather than navigating through various menus and dropdowns.

Also, for large deployments, consisting of 100+ databases across many hosts, using GUI may not be efficient nor scalable.

Here’s the basic syntax for using EM CLI to verify Data Guard configuration:

https://docs.oracle.com/en/enterprise-manager/cloud-control/enterprise-manager-cloud-control/13.4/emcli/dg_verify_config.html

emcli dg_verify_config
      -primary_target_name="<primary target name>"
      -primary_target_type="oracle_database|rac_database"  
      [-primary_db_creds_name="<primary database credential name>"] 
      [-primary_host_creds_name="<primary database host credential name>"]  
      [-reset_inconsistent_props="broker|database"]
      [-create_srls] 
      [-verify_only]

Next, I’ll demonstrate how EM CLI not only verifies Data Guard configuration, but also creates missing standby redo logs (SRLs):

--- The version of emcli is 13.4.0.0.0
[oracle@emhost ~]$ $OMS_HOME/bin/emcli version
Oracle Enterprise Manager 13c EM CLI Version 13.4.0.0.0
[oracle@emhost ~]$

--- Login to Enterprise Manager as sysman
[oracle@emhost ~]$ $OMS_HOME/bin/emcli login -username=sysman
Enter password :
Login successful
[oracle@emhost ~]$

--- Synchronizes the EM CLI client with an OMS
[oracle@emhost ~]$ $OMS_HOME/bin/emcli sync
Synchronized successfully
[oracle@emhost ~]$

--- Find Primary and Standby targets (XXXXXXX = DB_NAME and XXXXXXX_PHOENIX/XXXXXXX_SYDNEY = DB_UNIQUE_NAME)
--- IMPORTANT: If target has domain, then emcli will not work due to BUG.
[oracle@emhost ~]$ cd $OMS_HOME/bin/
[oracle@emhost bin]$ ./emcli get_targets -targets=rac_database -format=name:csv | grep XXXXXXX
1,Up,rac_database,XXXXXXX_PHOENIX
1,Up,rac_database,XXXXXXX_SYDNEY
[oracle@emhost ~]$

--- Verify Data Guard configurations and Create missing SRLS 
[oracle@emhost bin]$ ./emcli dg_verify_config -primary_target_name="XXXXXXX_SYDNEY" -primary_target_type="rac_database" -create_srls
Parsing command line arguments...
Verify Data Guard Configuration procedure VERIFY_DG_CONFIG_20210526091058954 has been submitted for primary database XXXXXXX_SYDNEY.
[oracle@emhost ~]$

--- Check status using procedure name: VERIFY_DG_CONFIG_20210526091058954 
[oracle@emhost bin]$ ./emcli get_instances | grep -B1 VERIFY_DG_CONFIG_20210526091058954
GUID                              Execution GUID                    Type  Name                                Status     Owner   Instance Status
C32FCFCACD2E2650E05317279D0A7830  C32FCFCACD312650E05317279D0A7830  HA    VERIFY_DG_CONFIG_20210526091058954  Running    SYSMAN  Running

[oracle@emhost bin]$ ./emcli get_instances | grep -B1 VERIFY_DG_CONFIG_20210526091058954
GUID                              Execution GUID                    Type  Name                                Status     Owner   Instance Status
C32FCFCACD2E2650E05317279D0A7830  C32FCFCACD312650E05317279D0A7830  HA    VERIFY_DG_CONFIG_20210526091058954  Succeeded  SYSMAN  Succeeded
[oracle@emhost bin]$

--- NOTE: GUID and Execution GUID are not the same.
C32FCFCACD2E2650E05317279D0A7830  
C32FCFCACD312650E05317279D0A7830  

--- After verification has succeeded, use GUID from emcli get_instances to review results: C32FCFCACD2E2650E05317279D0A7830
[oracle@emhost bin]$ ./emcli get_instance_status -instance=C32FCFCACD2E2650E05317279D0A7830 -xml -details -showJobOutput | grep -B50 "Data Guard configuration verification complete."
Processing is 0% complete.
Processing is 0% complete.
Processing is 0% complete.
Initializing
Connected to instance exasydad1x8anz-1nn7a1:XXXXXXX1
Starting alert log monitor...
Updating Data Guard link on database homepage...
Skipping verification of fast-start failover static services check.

Data Protection Settings:
  Protection mode : Maximum Performance
  Redo Transport Mode settings:
    XXXXXXX_PHOENIX: ASYNC
    XXXXXXX_SYDNEY: ASYNC

  Checking standby redo log files.....Done
   (Standby redo log files needed : 4)

Checking Data Guard status
  XXXXXXX_PHOENIX : Normal
  Write operation in progress
  XXXXXXX_SYDNEY : Normal

Checking inconsistent properties

Checking agent status
  XXXXXXX_PHOENIX
    exaphxad3x8na-kvnxa1.dbexaphoad3.phx.oraclevcn.com ... OK
    exaphxad3x8na-kvnxa2.dbexaphoad3.phx.oraclevcn.com ... OK

  XXXXXXX_SYDNEY
    exasydad1x8anz-1nn7a1.excsad1client.syd.oraclevcn.com ... OK
    exasydad1x8anz-1nn7a2.excsad1client.syd.oraclevcn.com ... OK


Checking applied log on XXXXXXX_PHOENIX...OK


Processing completed.

--- SRLS checked:
Standby Redo Log Files
Standby redo log files are recommended for all transport modes. 
They are required for certain features such as real-time apply and elevated protection modes.
Database Host/Cluster Size (MB) Log File Location Thread
XXXXXXX_PHOENIX  Unknown  4000.0  Oracle-managed file  2
XXXXXXX_PHOENIX  Unknown  4000.0  Oracle-managed file  1
XXXXXXX_SYDNEY   Unknown  4000.0  Oracle-managed file  2
XXXXXXX_SYDNEY   Unknown  4000.0  Oracle-managed file  1

--- SRLS created:
Successfully created the required standby redo log files for all databases.
Successfully resolved the issues detected during verification.
Data Guard configuration verification complete.
[oracle@emhost bin]$

In conclusion, it may be more efficient to use EM CLI to verify Data Guard configurations.

It’s also possible to generate EM CLI commands (emcli dg_verify_config) by querying the OEM repository to generate “emcli dg_verify_config” statements (as shown in above examples), saving a lot of time preparing those commands, and allowing you to automate and process their output periodically.