DR for Oracle Database Leveraging Data Guard Broker (DGMGRL)
Overview
This document provides a technical solution guide for integrating Oracle Data Guard Broker (DGMGRL) with the Kyndryl Bridge AIOps-based resiliency platform. The Kyndryl Bridge platform enables organizations to manage business continuity and cyber resiliency for multiple IT applications and databases through a unified Platform-as-a-Service (PaaS) model.
The integration uses the DGMGRL Command-Line Interface instead of SQL*Plus-based orchestration. Ansible roles and tasks are used to connect to Oracle Data Guard Broker nodes via SSH and execute DGMGRL commands to perform switchover, switchback and failover operations. The integration aims to automate key tasks and configuration activities using the Kyndryl Bridge (AIOps) platform, enhancing efficiency, scalability and reliability across IT environments.
Objective
Oracle Disaster Recovery (DR) solutions implemented with Oracle Data Guard Broker (DGMGRL) are designed to ensure the availability, reliability and continuity of critical databases during disasters or unexpected failures.
Key objectives include the following:
Business continuity
- Minimize downtime: Reduce business disruption by minimizing database recovery times using DGMGRL-managed transitions.
- Maintain access: Ensure continuous data and service availability during unplanned incidents.
Data protection
- Preserve data integrity: Prevent data loss and corruption across primary and standby databases through broker-managed replication.
- Ensure consistency: Synchronize changes between primary and standby environments, monitored via TRANSPORT-ON / APPLY-ON status in the DG configuration.
Disaster Recovery
- Enable fast recovery: Support rapid failover to standby databases using the DGMGRL FAILOVER TO command.
- Ensure redundancy: Deploy geographically dispersed standby databases to safeguard against localized outages and major failures.
High availability
- Enhance fault tolerance: Improve system resilience using Oracle Data Guard Broker-managed primary and physical standby databases.
- Balance load: Distribute database workloads across nodes to maintain performance and prevent bottlenecks.
Scalability
- Horizontal scaling: Expand capacity by adding standby databases to the broker configuration.
- Vertical scaling: Improve performance by scaling Oracle nodes based on demand.
Flexibility
- Support configuration modes: Supports MaxPerformance, MaxProtection, and MaxAvailability Data Guard protection modes.
- Provide configuration options: Support both synchronous and asynchronous replication to meet specific organizational requirements.
Automated management
- Simplify management with DGMGRL: Streamline configuration, monitoring, and maintenance of DR environments via the Data Guard Broker CLI.
- Utilize monitoring tools: Collect show configuration and show database outputs to monitor performance and health of primary and standby databases.
Compliance and security
- Support compliance: Align with regulatory requirements for data availability, integrity, and retention.
- Ensure secure communication: Implement SSH-based authentication and encrypted Oracle connections between primary and standby systems.
Architecture diagram, explanation with the required port number and network flow
The Oracle Data Guard Broker Disaster Recovery (DR) solution ensures business continuity for applications running on the Oracle database. It protects data by replicating redo log streams from the production site to a remote DR site, coordinated through the DGMGRL broker process.
This replication and orchestration process is automated using Kyndryl Resiliency Orchestration (Ansible Automation Platform), which simplifies management and keeps the DR database continuously synchronized with the production environment through the broker.
Architecture network flow diagram
Required Ports
Risk, Assumptions, Constraints and Dependencies (RACD)
This section defines the operational expectations, environmental prerequisites, and design boundaries for integrating Intelligent Recovery Service with Oracle Data Guard Broker. It is intended to promote consistent governance, delivery readiness and reliable steady-state operations.
Assumptions
The following conditions are expected to be true in the customer environment for the solution to function reliably:
- Secure, stable network connectivity exists between the automation execution point (Jump Host) and the Oracle Primary (PR) and Disaster Recovery (DR) servers.
- A customer-approved Jump Host is available and used as the execution point for data collection, insights, prechecks and orchestration workflows.
- Oracle Data Guard Broker is already configured and operational. The dgmgrl binary is available and accessible from the Oracle $ORACLE_HOME/bin/ directory on both PR and DR servers.
- Required host-level entries and access controls permitting automation (Jump Host → PR/DR) are in place.
- The automation OS user has the necessary permissions to:
- Execute Oracle DGMGRL command-line utilities.
- Access $ORACLE_HOME and $ORACLE_SID environment variables on the target servers.
- The database user assigned for automation has the necessary privileges (SYSDG or SYSDBA) to connect to the Data Guard Broker and execute DGMGRL commands.
- Oracle Database version 19c or later is deployed; versions below 19c are unsupported and will fail discovery/validation.
- The PR and DR operating system and database credentials are the same across both nodes. This is the user's responsibility.
- The ORACLE_HOME and ORACLE_SID environment variables are correctly configured on both PR and DR servers and are resolvable by the automation OS user.
Dependencies
The solution relies on the availability and correct operation of the following components:
- A customer-provided Jump Host with verified SSH connectivity to PR and DR servers, configured as a two-hop proxy in CACF AAP. Ansible Automation Platform (CACF AAP) with:
- Job templates
- Inventories
- Credentials (OS credentials and Oracle DB credentials as custom credential types)
- Execution Environments configured for Oracle DGMGRL workflows
- A reachable Git repository containing automation playbooks and roles (kyndryl.dr_oracle_dgmgrl, kyndryl.dr_custom_actions, kyndryl.dr_output_json).
- An operational Oracle Data Guard Broker process (dgmgrl) on both PR and DR servers, capable of returning configuration status and replication health information.
- The show configuration and show database DGMGRL commands must return parseable output for discovery and validation operations.
Constraints
The solution is bounded by the following architectural and operational constraints:
- Supports only Oracle Data Guard Broker (DGMGRL) for replication and orchestration of:
- Failover
- Switchover
- Switchback
- (including associated prechecks for each operation)
- Workload targeting relies on:
- pr_db_name and dr_db_name mappings defined in the input JSON
- Any inconsistency in these names compared to the broker configuration will cause workflow failures.
- The solution requires a functioning DGMGRL installation accessible from $ORACLE_HOME/bin/ on both PR and DR Oracle servers.
- Oracle versions below 19c are outside the supported scope and will not pass discovery or validation.
- The PR and DR OS credentials must match. Separate OS credentials per node are not supported.
Risks
The following risks are inherent to DGMGRL-based orchestration and require operational vigilance:
- Network and access risk: Connectivity issues or firewall restrictions between the Jump Host and PR/DR servers may block SSH access (Port 22), preventing discovery, monitoring, and failover operations.
- Configuration drift risk:Any mismatch in Oracle Data Guard Broker configuration (e.g., DG mode, database names, transport services) may disrupt replication and break orchestration workflows.
- Credential and privilege risk: Incorrect or expired OS/DB credentials, or insufficient DGMGRL privileges, will cause all operations to fail. The PR and DR credentials must be identical.
- Application write-activity risk: If applications continue writing to the primary during switchover/switchback windows, validations may fail or recovery timelines may be extended.
- Replication lag / RPO risk: Excessive replication lag may lead to unacceptable RPO deviations and impact failover outcomes.
- Repository dependency risk: Changes or unavailability of the Git repository containing automation assets (kyndryl.dr_oracle_dgmgrl) may break workflow execution.
- Input correctness risk: Incorrect pr_db_name / dr_db_name values or mismatches with the broker configuration can lead to targeting failures or false error conditions.
Typical mitigations include comprehensive prechecks, credential validation, maintaining consistent Oracle installation paths, enforcing operational sequencing, validating application shutdown before transitions and conducting regular DR drills using standardized runbooks and error-handling guidelines.
Jumphost
In many customer environments, direct connectivity to endpoints within the customer's network is not available. In these cases, a jumphost serves as a secure access point, enabling connectivity to systems located behind firewalls or within other restricted network environments.
The Oracle DG Broker automation uses the resiliency_host (Jump Host) as the intermediary for all SSH connections to PR and DR servers. It must be configured as a two-hop proxy in CACF AAP by the AAP administrator.
For more information, go to: Jumphost Jumphost module installation guide for Intelligent Recovery Service.
Supported versions
OS and Platforms | Storage (Database/File System) | Protection Scheme (Replication) |
|---|---|---|
Oracle Enterprise Linux 7.3 | Oracle Logs 19c/21c (64 bits) | Data Guard Broker (DGMGRL) 19c/21c (64 bits) |
RHEL 7.0 / 8.0 / 8.4 / 8.6 / 9.2 | Oracle Logs 19c/21c (64 bits) | Data Guard Broker (DGMGRL) 19c/21c (64 bits) |
Oracle versions below 19c are not supported and will fail discovery and validation.
Minimum privileges
- The database user must have `SYSDG` or `SYSDBA` privileges to connect to the Oracle Data Guard Broker via DGMGRL.
- The operating system user must have sudo permissions (or equivalent) to execute Oracle tools such as dgmgrl.
- The automation OS user must be able to resolve ORACLE_HOME and ORACLE_SID environment variables on both PR and DR servers.
Database access and write-location requirements
- The database user must have `SYSDG` or `SYSDBA` privileges to connect to the Oracle Data Guard Broker via DGMGRL.
- The operating system user must have sudo permissions (or equivalent) to execute Oracle tools such as dgmgrl.
- The automation OS user must be able to resolve ORACLE_HOME and ORACLE_SID environment variables on both PR and DR servers.
Database access and write-location requirements
Database Access Requirements
The DGMGRL-based automation requires the ability to connect to the Data Guard Broker and execute commands. The database user must have the following privileges at minimum:
Privilege | Type | Required For |
|---|---|---|
SYSDG | System | Connect to DGMGRL and execute broker commands (preferred least-privilege role). |
SYSDBA | System | Full DGMGRL access (used as alternative when SYSDG is not available). |
DGMGRL commands used during automation:
DGMGRL Command | Purpose |
|---|---|
show configuration | Validate broker configuration status and DG mode. |
show database <db_name> | Retrieve database role, transport, and apply status. |
failover to <db_name> | Execute failover to standby. |
switchover to <db_name> | Execute switchover to standby. |
switchover to <db_name> | Execute switchback to original primary. |
Required write-access locations
The automation OS user must have the ability to access the following paths:
- `$ORACLE_HOME/bin/` — Execute access to dgmgrl binary.
- `$ORACLE_HOME/lib/` — Read access to Oracle runtime libraries.
- `/tmp/` — Write access for temporary working files and script artifacts generated during automation.
Server permissions and library requirements
Operating system permissions required
Permission | Path | Access Level | Purpose |
|---|---|---|---|
Execute | $ORACLE_HOME/bin/dgmgrl | Execute (x) | Execute DGMGRL CLI for broker operations. |
Read | $ORACLE_HOME/lib/ | Read (r) | Access Oracle runtime and client libraries. |
Read | $ORACLE_HOME/bin/ | Read (r) | Access Oracle binary path. |
Read/Write | /tmp/ | Read/Write (rw) | Create temporary working files and spool outputs. |
Environment variables required
Variable | Example Value | Purpose |
|---|---|---|
ORACLE_HOME | /u01/app/oracle/product/19c | Specifies Oracle installation path; used to locate dgmgrl binary. |
ORACLE_SID | PRODDB | Identifies the target Oracle instance for DGMGRL connection. |
PATH | $ORACLE_HOME/bin:$PATH | Enables access to dgmgrl and other Oracle utilities. |
LD_LIBRARY_PATH | $ORACLE_HOME/lib:$LD_LIBRARY_PATH | Ensures Oracle shared libraries are discoverable. |
These variables are fetched dynamically from the target servers during automation execution via the get_oracle_env custom action task.
Summary of access levels
- OS User
- Must be a member of oinstall and dba groups.
- Requires read/execute access to $ORACLE_HOME/bin/dgmgrl.
- Database User
- Must have SYSDG or SYSDBA privilege for DGMGRL connectivity.
- The same DB credentials must be used for both PR and DR servers.
- Automation Service Account
- Requires SSH access to PR and DR servers.
- Must be able to resolve Oracle environment variables (ORACLE_HOME, ORACLE_SID).
- Sudo Configuration
- For automation execution, configure:
automation_user ALL=(oracle) NOPASSWD: /u01/app/oracle/product/19c/bin/dgmgrl
Features of the solution
The solution supports the following features:
Insights
- Data collection: Collects DB role, DG status, configured DG mode, transport and apply status from both PR and DR servers using DGMGRL show database commands.
- RPO calculation: Provides guidance and visibility into Recovery Point Objectives based on DGMGRL replication lag data.
- Data copy (Data Lag): Calculates the data lag between the production site and the disaster recovery (DR) site.
- Metrics: Evaluates the server status to determine whether replication is active or has stopped (TRANSPORT-ON / APPLY-ON).
- RPO batch: Executes the RPO data collection workflow on a scheduled basis to gather replication lag information and calculate Recovery Point Objective (RPO) metrics for reporting and visualization.
- Data copy batch: Executes the data lag collection workflow on a scheduled basis to measure the synchronization gap between the production and disaster recovery (DR) databases and generate data copy metrics.
- Metrics batch: Executes the replication health monitoring workflow on a scheduled basis to collect transport and apply status information and determine the operational state of Data Guard replication.
- Aggregate insights: Collects metrics, RPO, and data lag in a single combined playbook (aggregate_insights_oracledgmgrl.yml).
Automation
- Failover dry run: Checks whether the DR database is ready for failover (Ready for Failover: Yes).
- Failover: Initiates a DGMGRL FAILOVER TO <dr_db_name> operation.
- Switchover dry run: Validates DG configuration status, database roles, and switchover readiness on both PR and DR servers.
- Switchover: Initiates a DGMGRL SWITCHOVER TO <dr_db_name> operation (operation code: DGB_SO).
- Switchback dry run: Validates DG configuration status and switchback readiness on both PR and DR servers.
- Switchback: Initiates a DGMGRL switchover back to the original primary (operation code: DGB_SB).
Benefits of the solution
Performs advanced prechecks on all automation to ensure triggers only execute when the system is in the correct state (validates DG configuration status, database roles and switchover/failover readiness before executing).
- Conducts automatic post-operation validation of database roles on both PR and DR servers after every switchover, switchback and failover operation.
- Uses the DGMGRL show configuration and show database commands to provide real-time broker-level visibility into configuration health.
- Detects idempotent states, if the system is already in the target state (e.g., already failed over), the playbook reports success without re-executing the operation.
- Executes DR operations only when the DG configuration status confirms broker readiness (no gap, transport active).
- Displays real-time metrics and alerts on the dashboard.
Supported alerts, conditions and descriptions
Alert / Condition | Description |
|---|---|
TRANSPORT-ON | Primary database is actively shipping redo logs to the standby. |
APPLY-ON | Standby database is actively applying redo logs from the primary. |
Ready for Failover: Yes | DR database is ready to accept a DGMGRL failover command. |
DG Configuration SUCCESS | Broker configuration is healthy and all members are in expected state. |
Database Role PRIMARY | Database is operating as the primary instance. |
Database Role PHYSICAL STANDBY | Database is operating as a physical standby instance. |
DG Mode MaxPerformance | Data Guard is configured in maximum performance mode |
DG Mode MaxProtection | Data Guard is configured in maximum protection mode. |
DG Mode MaxAvailability | Data Guard is configured in maximum availability mode. |
The automation flow/tasks within the automation
Precheck tasks
Switchover Precheck (`oracle_dgmgrl_switchover_precheck.yml`)
- Initialize variables from resources list (all hosts).
- Get credentials from AWX.
- Validate input parameters (validate_oracledgmgrl_input.yml).
- Fetch Oracle home directory from environment on PR and DR servers (get_oracle_env).
- Set oracle_home and oracle_sid facts.
- Validate DG configuration status on DR server (show_configuration.yml).
- Validate database role status on PR server — expected: PRIMARY.
- Validate database role status on DR server — expected: PHYSICAL STANDBY.
- Validate database switchover readiness on PR server (get_validate_db_status.yml).
- Validate database switchover readiness on DR server (get_validate_db_status.yml).
- Generate final switchover precheck output.
Switchback Precheck (`oracle_dgmgrl_switchback_precheck.yml`)
- Initialize variables from resources list (all hosts).
- Get credentials from AWX.
- Validate input parameterS.
- Fetch Oracle home directory from environment on PR and DR servers.
- Validate DG configuration status on DR server.
- Validate database role status on DR server, expected: PRIMARY (post-switchover state).
- Validate database role status on PR server, expected: PHYSICAL STANDBY (post-switchover state).
- Validate database switchback readiness on PR and DR servers.
- Generate final switchback precheck output.
Failover Precheck (`oracle_dgmgrl_failover_precheck.yml`)
- Initialize variables from resources list (all hosts).
- Get credentials from AWX.
- Fetch Oracle home directory from environment on DR server.
- Validate DR database is ready for failover — checks Ready for Failover: Yes
- Generate final failover precheck output.
Automation task flow
Switchover (`oracle_dgmgrl_switchover.yml`)
- Initialize switchover runtime variables.
- Get credentials from AWX.
- Validate input parameters.
- Fetch Oracle home on PR and DR servers.
- Get database role status on PR and DR servers (parallel).
- Detect if setup is already in switched-over state (PR=PHYSICAL STANDBY, DR=PRIMARY).
- Execute run_switchover.yml task on DR server (operation: DGB_SO), skipped if already switched over.
- Validate post-switchover database role on PR server, expected: PHYSICAL STANDBY.
- Validate post-switchover database role on DR server, expected: PRIMARY.
- Generate final switchover output.
Switchback (`oracle_dgmgrl_switchback.yml`)
- Initialize switchback runtime variables.
- Get credentials from AWX.
- Validate input parameters.
- Fetch Oracle home on PR and DR servers.
- Get database role status on PR and DR servers (parallel).
- Detect if setup is already in switched-back state (PR=PRIMARY, DR=PHYSICAL STANDBY).
- Execute run_switchback.yml task on PR server (operation: DGB_SB), skipped if already switched back.
- Validate post-switchback database role on PR server, expected: PRIMARY.
- Validate post-switchback database role on DR server, expected: PHYSICAL STANDBY.
- Generate final switchback output.
Failover (`oracle_dgmgrl_failover.yml`)
- Initialize failover runtime variables.
- Get credentials from AWX.
- Fetch Oracle home on DR server.
- Get database role status on DR server.
- Detect if setup is already in failover state (DR=PRIMARY).
- Execute run_failover.yml task on DR server, skipped if already failed over.
- Validate post-failover database role on DR server, expected: PRIMARY.
- Generate final failover output.
Known limitations and prerequisites
The following prerequisites and limitations define the supported operational boundaries, configuration requirements and environmental dependencies for the Oracle Data Guard Broker integration. Understanding these considerations helps ensure successful deployment, reliable automation execution and consistent disaster recovery operations.
Known limitations
- OS authentication is not validated.
- The solution has been tested and validated only for users with the SYSDBA or SYSDG role.
- The PR and DR operating system and database credentials must be identical. Separate credentials per node are not supported.
- A custom credential type must be created in AWX/CACF AAP for Oracle DB credentials (oracle_user, oracle_password) and OS credentials (os_username, os_password).
Unsupported scenarios
- Multi-site Data Guard environments (more than one standby).
- Fallback scenarios.
- Reverse failover (failover back to the primary site after an unplanned failover without a switchback).
- Data Guard environments not managed by the DGMGRL Broker.
Prerequisites
- Oracle Data Guard Broker nodes must be configured to allow connectivity between the DG server and the Jump Host. They must also be set up as a two-hop proxy in CACF AAP. This configuration is performed by the CACF AAP administrator.
- Oracle DG Broker nodes must support SSH access (Port 22).
- The Oracle DG server's IP address or fully qualified domain name (FQDN), along with OS username and Oracle DB username/password, must be provided. The primary and disaster recovery (PR and DR) OS and database credentials must be the same.
- Port 1521 (default) must be open to allow DG node connectivity between PR and DR.
- The dgmgrl binary must be installed and accessible at $ORACLE_HOME/bin/dgmgrl on both PR and DR servers.
- ORACLE_HOME and ORACLE_SID environment variables must be configured on the target Oracle servers.
- The Oracle hosts (PR and DR) must be added to the AAP inventory.
- Credential labels for both the primary and DR Oracle servers must be created in Ansible Tower or CACF AAP.
- The Ansible roles kyndryl.dr_oracle_dg_mgrl, kyndryl.dr_custom_actions, and kyndryl.dr_output_json must be available via the roles/requirements.yml and the configured Git source control project.
Setting up the solution
For detailed instructions on the onboarding process, refer to the general Intelligent Recovery Service onboarding guide.
Inputs for onboarding
The following variables are commonly used across the operations:
Variable | Description | Sample Value | Fixed | Mandatory |
|---|---|---|---|---|
pr_db_server | Primary database server IP address or FQDN | 192.168.X.XX | Yes | Yes |
dr_db_server | Disaster recovery database server IP address or FQDN | 172.168.X.XX | Yes | Yes |
os_username | Operating system username (same for PR and DR) | oracle | No | Yes |
os_password | Operating system password (same for PR and DR) | ***** | No | Yes |
oracle_user | Oracle database username | sys | No | No |
oracle_password | Oracle database password | ***** | No | No |
pr_db_name | Primary database name (as registered in DG Broker) | orcl_pr | Yes | Yes |
dr_db_name | DR database name (as registered in DG Broker) | orcl_dr | Yes | Yes |
oracle_pr_db_role | Oracle database role for primary | SYSDG | Yes | Yes |
oracle_dr_db_role | Oracle database role for DR | SYSDG | Yes | Yes |
pr_db_port | Primary database listener port | 1521 | Yes | Yes |
dr_db_port | Disaster recovery database listener port | 1521 | Yes | Yes |
resiliency_host | CACF jump server used for connecting to the Oracle servers | localhost | Yes | Yes |
resiliency_no_log | Suppress sensitive output in Ansible logs | true | No | No |
| | | | |
Inputs for automation
The following variables are used for all supported automation playbooks:
Variable | Description | Sample Value | Fixed | Mandatory | Recommendations |
|---|---|---|---|---|---|
pr_db_server | Primary database server host IP address or FQDN | 192.168.X.XX | Yes | Yes_1 | — |
dr_db_server | Disaster recovery database server host IP address or FQDN | 172.168.X.XX | Yes | Yes | — |
os_username | OS username (same for PR and DR) | oracle | No | Yes | — |
os_password | OS password (same for PR and DR) | ***** | No | Yes | — |
oracle_user | Oracle database username | sys | No | No | — |
oracle_password | Oracle database password | ***** | No | No | — |
pr_db_name | Primary database name | orcl_pr | Yes | Yes | Must match broker-registered DB name exactly |
dr_db_name | DR database name | orcl_dr | Yes | Yes | Must match broker-registered DB name exactly |
oracle_pr_db_role | Oracle database role for primary | SYSDG | Yes | Yes | — |
oracle_dr_db_role | Oracle database role for DR | SYSDG | Yes | Yes | — |
pr_db_port | Primary database port | 1521 | Yes | Yes | — |
dr_db_port | Disaster recovery database port | 1521 | Yes | Yes | — |
resiliency_host | CACF jump server used to connect to the Oracle servers | localhost | Yes | Yes | Use consistent credential naming across PR and DR servers |
resiliency_no_log | Suppress sensitive output in Ansible logs | true | No | No | Set to false for debugging only |
| | | | | |
Example input JSON (`input.json`):
{
"workload_id": "workload-546f4528-91e0-4761-8829-121e99acde76",
"bac_id": "112233",
"workload_name": "Oracle",
"os_username": "oracle",
"os_password": "*****",
"resiliency_no_log": false,
"resources": [
{
"pr_db_server": "192.xx.xx.xx",
"dr_db_server": "172.xx.xx.xx",
"pr_db_name": "orcl_pr",
"dr_db_name": "orcl_dr",
"oracle_user": "sys",
"oracle_password": "*****",
"oracle_pr_db_role": "SYSDG",
"oracle_dr_db_role": "SYSDG",
"pr_db_port": 1521,
"dr_db_port": 1521
}
]
}Project creation
A project is a construct/structure used only for the discovery and configuration of workload. You can use it as a filter to navigate across the discovery and configuration menus. A project has a start date and expected end date that help the user track the onboarding time. For detailed instructions on how to create a project, see Project.
For this solution, while selecting the blueprint when creating a project, select DR-OracleDB-leveraging-DataGuard-Broker from the Blueprint drop-down of the Project Configuration panel.
For this solution, while selecting the blueprint when creating a project, select DR-OracleDB-leveraging-DataGuard-Broker from the Blueprint drop-down of the Project Configuration panel.
Discovery
After mapping the blueprint with the project, the user performs the discovery of all the workloads under the specific blueprint. For detailed instructions on Discovery, see Discovery.
For this solution, during the data collection in the discovery phase, the user needs to provide the details for the following parameters:
- Primary DB name \*
- Primary DB Port \*
- Primary DB Role \*
- Primary Nodes Host Group \*
- DR DB name \*
- DR DB Port \*
- DR DB Role \*
- DR Nodes Host Group \*
- Enter DR Node Group
- Credentials Label \*
- Automation Target Group \*
- Automation Execution Environment
- Automation Target host \*
Resourcing
You can create a workload for a specific project and the associated blueprint by selecting a resource on the Resource screen. After discovering a specific blueprint, users can view all the discovered resources mapped with the blueprint on the Resource page. After selecting a workload, click Configure.
The user is taken to the Onboard screen, where they can add Insights and Automation. For detailed instructions on the Resource, see Resource.
Onboarding
The onboard page is used to list the created workloads. The user needs to provide additional configurations that can be used for monitoring and automation. For detailed instructions on the Onboard screen, see Onboard.
Add Insights and Automation, configure the basic parameters under the Basic tab and validate the provided inputs. Users do not need to configure the parameters appearing under the Insights and Automation tab.
Troubleshooting
The following troubleshooting guidance helps identify and resolve common issues that may occur during Oracle Data Guard Broker discovery, data collection, validation, monitoring and recovery operations.
SFS upload failed during data collection
- Verify that the SFS upload URL is correct.
- Confirm that the required upload permissions are granted.
Data collection succeeded, but resources are not displayed on the Intelligent Recovery Service UI
- Ensure the extension service is up and running.
- Check for any issues in the data streaming pipeline.
DGMGRL connection fails
- Verify that ORACLE_HOME and ORACLE_SID are correctly set on the target server.
- Confirm that the dgmgrl binary exists at $ORACLE_HOME/bin/dgmgrl and is executable by the automation OS user.
- Confirm that the Oracle listener is running on Port 1521 and is accessible from the Jump Host.
Precheck fails with unexpected database role
- Verify that the pr_db_name and dr_db_name values match the database names registered in the DG Broker configuration (show configuration output).
- Confirm that the PR database is in PRIMARY role and the DR database is in PHYSICAL STANDBY role before initiating switchover or switchback.
Error codes and recommendations
Error Code | Description |
|---|---|
8400 | pr_db_server, dr_db_server, oracle_listener_port, oracle_db_role, and Oracle database name are not configured. |
8401, 8406, 8408, 8410, 8412, 8414, 8417 | ORA error in the output due to misconfiguration. Please validate the inputs provided correctly. |
8402 | Failed to get the intended state of the database (TRANSPORT-ON or APPLY-ON). |
8403 | Failed to get the database role status (PRIMARY or PHYSICAL STANDBY). |
8404 | Unable to get the database configuration status — it should be SUCCESS. |
8405 | Expected database status does not match with the current status. |
8407 | Oracle Database configuration status is not in the correct state. |
8409 | Database failover operation failed. |
8411 | Database switchover operation failed. |
8413 | Failed to get the database configuration status. |
8415 | Failed to get apply log detail from the database server. |