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 220.127.116.11.0 [oracle@emhost ~]$ $OMS_HOME/bin/emcli version Oracle Enterprise Manager 13c EM CLI Version 18.104.22.168.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.