Oracle DBA interview question and answer 2026

 What is the primary problem Oracle Database Vault solves?

• Answer: It stops privileged account abuse and insider threats. In standard Oracle databases, a SYSDBA or DBA user can view all application tables. Database Vault blocks these powerful administrative accounts from viewing application data while still allowing them to perform operational tasks like backups, patching, and tuning

Q1: What is Oracle Database Vault, and how does it change traditional DBA privileges in Oracle 19c?

• Answer: Oracle Database Vault is an embedded security feature that restricts highly privileged database users from accessing sensitive application data. 
• Key Mechanism: Traditionally, a user with the DBA role or SYSDBA system privilege can see all data in all tables. With Database Vault enabled, it strips the implicit data-viewing power from administrators. The DBA can still maintain the infrastructure (backups, tuning, patching), but they cannot query restricted application data tables. 

Q2: What are the primary components used to implement Database Vault restrictions?

• Realms: Logical zones created around specific database schemas, tables, or roles. Only explicitly authorized users or application contexts can access objects inside a realm. 
• Command Rules: Controls placed over SQL commands (e.g., DROP TABLE, ALTER SYSTEM, CREATE USER). They determine under what exact conditions a command can run. 
• Factors: System contexts or attributes used to establish a trusted path (e.g., Client IP address, Database User, Time of Day, or Client Program). 

Q3: Explain "Separation of Duties" under Oracle Database Vault. Which specific accounts are created?

Database Vault removes complete control from a single monolithic DBA account by introducing specialized administrative roles: 

• Database Vault Owner (DV_OWNER): Manages the Database Vault configurations, defines realms, and grants access to those realms. 
• Database Vault Account Manager (DV_ACCT_MGR): Manages database user accounts and profiles. Crucially, a standard DBA can no longer create or drop database users once Database Vault is active. [
• Database Administrator (DBA): Retains purely operational duties like performance management, storage management, and database upgrades without access to the business data. 

---

Scalability Strategy: Managing 100+ Databases

Q4: How do you implement and maintain Database Vault efficiently across an estate of 100 databases?

Managing 100 separate databases requires centralization, automation, and standardization. The enterprise strategy involves:

• Centralized Policy Management: Use Oracle Enterprise Manager (OEM) Cloud Control to centrally design, package, and monitor policies. Policies can be defined as a master blueprint and pushed across the database fleet.
• Infrastructure as Code (IaC) & Automation: Use the provided Oracle PL/SQL APIs (such as DBMS_MACADM) to wrap realm configurations, command rules, and factors into standardized scripts. These scripts are deployed through automation pipelines (like Ansible, Terraform, or Oracle Fleet Patching and Provisioning).
• Multitenant Architecture Integration: In an Oracle 19c Container Database (CDB) environment housing multiple Pluggable Databases (PDBs), Database Vault can be configured at the PDB level. This stops a central cloud/CDB administrator from spying on data held within isolated tenant PDBs.
• Central Auditing via AVDF: Couple the fleet deployment with Oracle Audit Vault and Database Firewall (AVDF). This aggregates security violations and Database Vault audit trails from all 100 databases into a single dashboards for real-time monitoring. 

---

Scenario-Based & Technical Questions

Q5: A DBA needs to perform an urgent application schema change inside a protected Realm. How is this allowed under Database Vault?

• Answer: The Database Vault Owner (DV_OWNER) must grant temporary authorization to the DBA or deployment account using the DBMS_MACADM.AUTHORIZE_PDB_DDL or DBMS_MACADM.AUTHORIZE_REALM APIs.
• Best Practice: Tie this authorization to a rigid Command Rule that mandates a "trusted path". For example, the modification is only permitted if it originates from a specific deployment server IP address and occurs during an approved maintenance window. 

Q6: How do you verify if Database Vault is properly running on a specific database instance?

• Answer: You can check the current system registration by querying the database options view. Run the following SQL query: 

sql

SELECT PARAMETER, VALUE FROM V$OPTIONS WHERE PARAMETER = 'Oracle Database Vault';

• Result: If it returns TRUE, the option is enabled. You should also check DBA_DV_STATUS to verify if the security enforcement is actively working for the runtime environment. 

Q7: Does Oracle Database Vault encrypt data stored on disk?

• Answer: No, Oracle Database Vault does not encrypt data. It provides access and operational controls.
• Complementary Tech: To protect data on physical storage or backups from being compromised outside the database engine, you must use Transparent Data Encryption (TDE). Database Vault and TDE are complementary features that represent the foundation of Oracle's Defense-in-Depth security framework.

Q3: What is a Realm and what are its components?

• Answer: A Realm is a logical security zone or "firewall" wrapped around database schemas, specific tables, or roles. It consists of:
  • Secured Objects: The schemas or tables you want to protect (e.g., HR.EMPLOYEES).
  • Authorized Users: The specific application accounts explicitly allowed to access those secured objects. Unauthorised users (including SYS or DBA) are instantly blocked. 

Q4: What are Factors and Command Rules?

• Answer:
  • Factors: System attributes that establish a user's context, such as Client IP Address, Session User, Program Name, or Time of Day.
  • Command Rules: Context-aware security policies attached to SQL commands (e.g., DROP TABLE, ALTER SYSTEM). They validate defined Factors before allowing the command to execute. [

Q5: How do you verify if Oracle Database Vault is enabled in 19c?

• Answer: Query the V$OPTIONS view. If enabled, the parameter returns TRUE:
  sql

  SELECT parameter, value FROM v$options WHERE parameter = 'Oracle Database Vault';
  

  
  

---

Part 2: Protecting Data Across 100 Databases

To secure 100 databases efficiently without managing 100 individual security strategies, you must leverage Oracle 19c Multitenant Architecture alongside centralized automation. 

Architectural Blueprint

• Consolidation Strategy: Group your databases into Multitenant Container Databases (CDBs) hosting multiple Pluggable Databases (PDBs). For instance, 4 production CDBs holding 25 PDBs each. 
• Isolation Control: Enable Database Vault locally at the PDB level. This prevents a Common CDB DBA from peeking into individual PDB customer application data. 
• Automation Workflow:
  1. Write your Database Vault configuration policies as unified PL/SQL scripts.
  2. Use Oracle Enterprise Manager (OEM) Cloud Control or Ansible playbooks to deploy the scripts across all 100 PDB endpoints simultaneously.
  3. Route all security logs to a centralized target via Oracle Audit Vault and Database Firewall (AVDF) for centralized auditing and compliance. 

---

Part 3: Implementation Example (Protecting HR Data)

This script creates a custom security realm to isolate human resources data from database administrators.

Execute this configuration as the DV_OWNER account: 

sql

-- Step 1: Create a secure protection zone (Realm)
BEGIN
  DBMS_MACADM.CREATE_REALM(
    realm_name    => 'HR_Data_Protection_Realm',
    description   => 'Shields sensitive HR records from administrative access',
    enabled       => DBMS_MACUTL.G_YES,
    audit_options => DBMS_MACUTL.G_AUDIT_ON_FAILURE
  );
END;
/

-- Step 2: Bind the sensitive HR schema to the Realm
BEGIN
  DBMS_MACADM.ADD_OBJECT_TO_REALM(
    realm_name  => 'HR_Data_Protection_Realm',
    object_owner=> 'HR',
    object_name => '%', -- Protects all tables inside the HR schema
    object_type => 'TABLE'
  );
END;
/

-- Step 3: Explicitly authorize only the trusted Application Server account
BEGIN
  DBMS_MACADM.ADD_AUTH_TO_REALM(
    realm_name  => 'HR_Data_Protection_Realm',
    grantee     => 'HR_APP_USER', -- The functional runtime software user
    rule_set_name=> NULL
  );
END;
/

Part 4: Testing & Verification Case

This validation test proves that standard administrative users cannot bypass Database Vault restrictions.

Test Setup

Ensure you have three distinct runtime sessions ready:

1. HR_APP_USER: The authorized software account.
2. SYSTEM or SYS: The powerful infrastructure DBA account. 

Execution Steps & Expected Results

• Scenario A: The App Server accesses data
  sql

  -- Connect as the authorized Application Server Account
  CONNECT hr_app_user/password@pdb_name;
  
  SELECT COUNT(*) FROM hr.employees;
  

  • Expected Result: Success. The query executes normally and returns a count because this specific account is explicitly permitted inside the realm. 
• Scenario B: The DBA attempts to access data
  sql

  -- Connect as the powerful Infrastructure Database Administrator 
  CONNECT system/password@pdb_name;
  
  SELECT COUNT(*) FROM hr.employees;
  

  • Expected Result: ORA-47400: Command Blackout / Realm Violation. Database Vault intercepts the transaction and completely denies the SYSTEM admin access, even though they hold global DBA privileges. 
• Scenario C: Checking the Audit Trails
  sql

  -- Connect as the Security Auditor or DV_OWNER to check breaches
  SELECT username, action_name, return_code 
  FROM unified_audit_trail 
  WHERE return_code = 47400;
  

  • Expected Result: A system record identifying that SYSTEM attempted an unauthorized read on HR.EMPLOYEES, logging the exact time, terminal, and database command used

Question : How to app patch OMS/OEM

To patch an OMS (Oracle Management Service) or OEM (Oracle Enterprise Manager) Agent, you must verify your utility versions, run prerequisite analyses to check for conflicts, perform rolling or downtime patching using omspatcher or agentPatcher, and validate the inventory. 

1. Interview Questions, Answers & Examples

Q: What is your approach to applying a Release Update (RU) or patch in the OMS environment?

Answer: I follow a structured, phased approach recommended by Oracle. I first take full backups of the OMS and Repository, download the latest OMSPatcher and OPatch utilities, and review the patch README for specific prerequisites. Next, I run the analyze command, shut down the OMS processes, apply the patch, and run post-patch verification. 

Example: "In our last patching cycle for OEM 13.5, I downloaded the latest Release Update and one-off patches. Before applying anything to production, I simulated the installation using the analyze command to ensure there were zero conflicts. After a successful simulation, I stopped the OMS services with ./omstop and applied the patch using omspatcher apply." 

Q: How do you handle patch conflicts between OMS and Plugins?

Answer: Patch conflicts occur when a one-off patch alters a file that has already been modified or patched by a prior Release Update. I check the OMSPatcher analyze log to identify the conflicting sub-patches. Then, I check My Oracle Support (MOS) for merge patches, or contact Oracle Support for a holistic patch that resolves the conflict.

Example: "During an RU upgrade last quarter, omspatcher apply -analyze threw a prerequisite error due to a pre-existing plugin patch. I viewed the conflict details, reviewed the error in the omspatcher log, and searched MOS for a merged patch to resolve the overlap before proceeding." 

Q: What are the primary commands you use for OMS and Agent patching?

Answer:

• omspatcher apply -analyze (Validates conflicts and system requirements without altering the system)
• omspatcher apply (Applies the system patch to the OMS platform home)
• agentPatcher apply (Applies the required fixes to the Management Agent home)
• omspatcher lspatches / agentPatcher lspatches (Verifies the patches were successfully registered) 

---

2. Example Test Cases (Pre & Post-Patch Verification)

These test cases demonstrate how you validate the integrity of your OEM environment before and after patching.

Pre-Patching Test Case: Analyze and Environment Check

• Objective: Ensure the environment is prepared and conflict-free before applying patches.
• Steps:

1. Export the correct ORACLE_HOME path for the OMS.
2. Ensure OPatch and OMSPatcher are upgraded to the minimum version specified in the patch README.
3. Run the command: omspatcher apply -analyze <PATCH_LOCATION>
4. Review the generated logs in $ORACLE_HOME/cfgtoollogs/omspatcher/ to confirm there are no prerequisite failures or conflict alerts. 

Post-Patching Test Case: OMS Verification

• Objective: Verify that the OMS software has been successfully updated and services are healthy.
• Steps:

1. Execute the verification command: omspatcher lspatches
2. Verify the output displays the correct patch ID (e.g., Release Update number) and that the status reads Success.
3. Restart OMS services using emctl start oms.
4. Validate the OMS status using emctl status oms -details.
5. Log in to the OEM Console and verify that the core components show as Up in the Target Homepage. 

Post-Patching Test Case: Agent Synchronization

• Objective: Ensure the patched Management Agent successfully uploads its payload to the OMS.
• Steps:

1. Navigate to the agent home directory and execute: agentPatcher lspatches
2. Ensure the patch version corresponds with the OMS patch.
3. Start the agent: emctl start agent
4. Run a secure upload to the OMS: emctl upload agent
5. Check upload status: emctl status agent and ensure there are no queued payloads. 

Question : How to configure resource manger in 19c Database.

Managing resources via the Oracle Database Resource Manager (DBRM) in an Oracle 19c database involves grouping database sessions into Consumer Groups, creating a Resource Plan, and establishing Plan Directives to enforce specific resource allocations. 

To manage Input/Output (I/O), Oracle 19c offers parameter-based limits (MAX_IOPS and MAX_MBPS) at the Pluggable Database (PDB) level, as well as threshold-driven actions (SWITCH_IO_REQS and SWITCH_IO_MEGABYTES) at the session/consumer group level. 

---

1. Conceptual Framework & Core Q&A

Q1: What are the main components required to set up DBRM?

• Pending Area: A scratchpad workspace used to create, modify, and validate resource manager objects before committing them to the data dictionary. 
• Consumer Groups: Logical buckets that group user sessions based on their resource demands (e.g., OLTP_GROUP, REPORT_GROUP). 
• Resource Plan: The overarching container configuration that defines how CPU, I/O, and parallel execution limits are distributed. 
• Plan Directives: The specific rules mapping a Consumer Group to a Resource Plan, determining exact resource throttles or switch behaviors. 

Q2: How does Oracle 19c manage database I/O using Resource Manager?

• PDB Level (Hard Limits): Using the initialization parameters MAX_IOPS (Input/Output Operations Per Second) and MAX_MBPS (Megabytes Per Second throughput) inside a Pluggable Database. These act as physical limits that throttle the entire PDB regardless of concurrent demand. 
• Session/Consumer Group Level (Runaway Control): Using parameters such as SWITCH_IO_REQS and SWITCH_IO_MEGABYTES. When a specific database session crosses these I/O thresholds, DBRM automatically downgrades it to a low-priority group or cancels the statement entirely. 

---

2. Practical Configuration: End-to-End Example

The following practical exercise sets up a resource plan named IO_MANAGEMENT_PLAN to isolate online transaction processing sessions (OLTP_CG) from heavy reporting sessions (REPORT_CG). It implements an automatic downgrade rule for reporting sessions that exceed 1000 I/O requests. 

Step 1: Create the Pending Area

All configurations must start by initializing the workspace. 

sql

EXEC DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

Step 2: Define Consumer Groups

Create distinct categories for different transactional workloads. 

sql

EXEC DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(consumer_group => 'OLTP_CG', comment => 'OLTP Transactions');
EXEC DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(consumer_group => 'REPORT_CG', comment => 'Reporting Workloads');

Step 3: Define the Resource Plan

Establish the root container plan. 

sql

EXEC DBMS_RESOURCE_MANAGER.CREATE_PLAN(plan => 'IO_MANAGEMENT_PLAN', comment => 'Plan to limit runaway I/O workloads');

Step 4: Map Directives with I/O Management Controls

Create rules allocating CPU shares and setting explicit session-level I/O switch limits. 

• OLTP Group: Assigned high CPU priority (80%).
• Reporting Group: Assigned lower CPU priority (20%). If any single query exceeds 1,000 I/O requests, it automatically switches to OTHER_GROUPS (low priority) for the remainder of that call. 

sql

-- Directive for OLTP_CG
EXEC DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( -
    plan => 'IO_MANAGEMENT_PLAN', -
    group_or_subplan => 'OLTP_CG', -
    comment => 'OLTP Priority Directives', -
    mgmt_p1 => 80);

-- Directive for REPORT_CG with runaway I/O management
EXEC DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( -
    plan => 'IO_MANAGEMENT_PLAN', -
    group_or_subplan => 'REPORT_CG', -
    comment => 'Report Directives with I/O limits', -
    mgmt_p1 => 20, -
    switch_group => 'OTHER_GROUPS', -
    switch_io_reqs => 1000, -
    switch_for_call => TRUE);

-- Directive for default system tracking (Mandatory)
EXEC DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE( -
    plan => 'IO_MANAGEMENT_PLAN', -
    group_or_subplan => 'OTHER_GROUPS', -
    comment => 'Catch-all group', -
    mgmt_p2 => 100);

Step 5: Validate and Submit Configuration

Submit the structural definitions to activate them permanently in the database. 

sql

EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

Step 6: Map Users to Groups and Enable Plan

Assign target schemas to their respective workload buckets and activate the system plan. 

sql

-- Map schema 'BI_USER' to the Reporting Consumer Group
EXEC DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING( -
    attribute => 'ORACLE_USER', -
    value => 'BI_USER', -
    consumer_group => 'REPORT_CG');

-- Enable the plan instance-wide
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'IO_MANAGEMENT_PLAN' SCOPE=MEMORY;

3. Alternative: Multi-Tenant PDB-Level I/O Throttling

If operating inside an Oracle 19c Multitenant architecture (CDB/PDB), you do not need a complex PL/SQL pending area to limit absolute infrastructure consumption. You can throttle maximum throughput by running an ALTER SYSTEM command directly inside the specific PDB:

sql

-- Connect to the target PDB (e.g., HRPDB)
ALTER SESSION SET CONTAINER = hrpdb;

-- Enforce hard cap limits on physical disk I/O metrics
ALTER SYSTEM SET MAX_IOPS = 500 SCOPE=BOTH;
ALTER SYSTEM SET MAX_MBPS = 50 SCOPE=BOTH;

4. Test Cases and Verification

Test Case 1: Verifying active plan status

• Action: Check if the plan is loaded and running in the memory structure.
• SQL Query:
  sql

  SELECT name, is_top_plan FROM v$rsrc_plan;
  

  Expected Result: IO_MANAGEMENT_PLAN should appear with IS_TOP_PLAN marked as TRUE. 

Test Case 2: Mapping Validation

• Action: Connect to the database as BI_USER and view active session routing.
• SQL Query:
  sql

  SELECT username, resource_consumer_group FROM v$session WHERE username = 'BI_USER';
  

  Expected Result: The session's RESOURCE_CONSUMER_GROUP must show REPORT_CG.

Test Case 3: Simulating and Verifying an I/O Runaway Switch

• Action: Execute an unindexed, heavy Full Table Scan query as BI_USER that requires more than 1,000 disk blocks.
• SQL Query:
  sql

  SELECT COUNT(*) FROM bi_user.massive_historical_data;
  

  Validation Query (Run from a DBA session while the long query runs):
• sql

  SELECT username, resource_consumer_group, current_consumer_group 
  FROM v$session 
  WHERE username = 'BI_USER';
  

  Expected Result: RESOURCE_CONSUMER_GROUP (initial group) will remain REPORT_CG, but CURRENT_CONSUMER_GROUP will dynamically switch to OTHER_GROUPS once the 1,000 I/O request limit is exceeded. 

---

5. Summary Check

Resource Manager Enabled & I/O Managed 

text

The Oracle 19c database will now prioritize low-overhead transactions, isolate reporting pools, and automatically throttle runaway sessions or PDB volumes based on predefined resource metrics.

Question : How to manage and configure observer in data guard in 19c database question and answer with example and test cases 

Managing and configuring the Data Guard Observer in Oracle 19c is essential for enabling Fast-Start Failover (FSFO), which automates database failover when the primary site goes down. The Observer acts as a continuous tracking client process that runs outside the primary and standby database nodes. 

---

Part 1: Conceptual Questions & Answers

Q1: What is the primary purpose of the Oracle Data Guard Observer?

• A: The Observer continuously monitors the availability and health of a Data Guard configuration. It works alongside the Data Guard Broker to safely initiate an automatic, zero-data-loss failover to a pre-designated standby target when contact with the primary database is unexpectedly lost. 

Q2: Where should the Observer process be physically installed and hosted?

• A: It must be deployed on a third separate machine (Host 3). It should never share hardware infrastructure with the primary or standby databases. This prevents a single site or network crash from taking down both a database node and the observer simultaneously. 

Q3: What new Oracle 19c features enhance Observer reliability?

• A: Oracle 19c allows you to deploy multiple observers per configuration (one designated as Master and up to two others as Backups). It also introduces Observe-Only Mode, letting you evaluate if a failover would have occurred without actually changing database roles. 

---

Part 2: Step-by-Step Configuration Example

This setup assumes an existing Oracle 19c Data Guard Broker configuration consisting of primary database PROD and standby database STBY. 

Primary Database Node  (Host 1): PROD
Standby Database Node  (Host 2): STBY
Observer Machine Node  (Host 3): OBS_NODE

Step 1: Install and Configure Network Connectivity on Host 3

You only need a lightweight Oracle Database Client Administrator installation or an Instant Client on OBS_NODE to access the DGMGRL command-line utility. 

Configure your local $ORACLE_HOME/network/admin/tnsnames.ora on OBS_NODE to point to both systems: 

text

PROD =
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=TCP)(HOST=host1-ip)(PORT=1521))
    (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=PROD)))

STBY =
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=TCP)(HOST=host2-ip)(PORT=1521))
    (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=STBY)))

Step 2: Configure Fast-Start Failover (FSFO) Settings 

Log into the broker from the primary site or the observer node using DGMGRL and adjust timeout metrics:

sql

dgmgrl sys/your_password@PROD

-- 1. Set the target standby for automatic failover
DGMGRL> EDIT DATABASE PROD SET PROPERTY FastStartFailoverTarget = 'STBY';
DGMGRL> EDIT DATABASE STBY SET PROPERTY FastStartFailoverTarget = 'PROD';

-- 2. Define the ping failure threshold (in seconds) before failover begins
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 30;

-- 3. Enable Flashback on both databases (Mandatory requirement for automated reinstatement)
-- Ensure 'ALTER DATABASE FLASHBACK ON;' has been run at SQL level on both nodes.

Step 3: Launch the Observer on Host 3

Run the observer process in the background using Linux nohup or native DGMGRL background capabilities to keep it running after your shell session disconnects: 

bash

# Executing on OBS_NODE (Host 3)
nohup dgmgrl sys/your_password@PROD "START OBSERVER obs_master FILE='/u01/app/oracle/fsfo_obs.dat'" -logfile /u01/app/oracle/observer.log &

Note: The FILE parameter tracks the synchronization configuration state on disk. []

Step 4: Turn on Automated Failover Protection

Go back into your broker shell window and toggle active protection status: 

sql

DGMGRL> ENABLE FAST_START FAILOVER;
DGMGRL> SHOW CONFIGURATION;

Part 3: Live Verification & Testing Scenarios

Test Case 1: Routine Verification Checks

• Objective: Ensure the observer is tracking and reporting live heartbeats.
• Execution Command:
  sql

  DGMGRL> SHOW OBSERVER;
  

  Expected Output:
• text

  Configuration - dg_config
    Fast-Start Failover: ENABLED
    Primary            : PROD
    Active Target      : STBY
  
    Observer "obs_master" - Master
      Host Name        : OBS_NODE
      Last Ping to Primary : 0 seconds ago
      Last Ping to Target  : 1 second ago
  

  Test Case 2: Simulating Unplanned Primary Node Outage

• Objective: Verify that the standalone observer performs an unassisted failover to the standby node when the primary instance crashes completely.
• Execution Step: Abruptly abort the primary database engine instance from Host 1.
  bash

  # Execute on Host 1 (Primary Node)
  sqlplus / as sysdba
  SQL> SHUTDOWN ABORT;
  

  Observer Log Reaction (/u01/app/oracle/observer.log):
• text

  [W000 2026-06-22] Primary database cannot be reached.
  [W000 2026-06-22] Fast-Start Failover threshold has expired.
  [W000 2026-06-22] Making a last connection attempt to primary...
  [S002 2026-06-22] Initiating Fast-start Failover to database STBY...
  [S002 2026-06-22] Failover to database "STBY" succeeded.
  

  Expected Result: Checking SHOW CONFIGURATION; via DGMGRL will now demonstrate that STBY automatically transitioned to the Primary processing role. 

Test Case 3: Automatic Reinstatement of Failed Nodes

• Objective: Validate that the old crashed primary server is automatically recovered as a fresh synchronized standby database without manual restoration steps. 
• Execution Step: Start the database back up on Host 1.
  bash

  # Execute on Host 1 (Old Primary Node)
  sqlplus / as sysdba
  SQL> STARTUP MOUNT;
  

  
  
• Expected Result: The running Observer detects that the node is online. It leverages historical Flashback Database tracking parameters to automatically stitch it back into the architecture. Within minutes, SHOW CONFIGURATION; outputs:
  text

  Members:
  STBY - Primary database
  PROD - Physical standby database