DBA NAVIGATOR

  Converting a Physical Standby Database to a Snapshot Standby: A Step-by-Step Guide A snapshot standby database is a powerful feature in Oracle Data Guard that allows you to temporarily convert a physical standby database into a read-write database for testing or development purposes, while preserving the ability to revert back to a synchronized physical standby later. This blog post demonstrates the step-by-step process of converting a physical standby database to a snapshot standby. Prerequisites Primary database (testpri) and physical standby database (testsby) are properly configured with Data Guard Appropriate privileges to perform administrative commands Log archiving is properly configured between primary and standby The Conversion Process Step 1: Defer Log Shipping from Primary Database Before converting the standby database to a snapshot standby, it's a good practice to temporarily defer log shipping from the primary to avoid conflicts during the conversion proc...

🌐 ORA-24247: Network Access Denied by ACL in Oracle – Explained & Resolved When working with Oracle debugging features like DBMS_DEBUG_JDWP , you might encounter the following error: ORA-24247: Network access denied by access control list (ACL) ORA-06512: at "SYS.DBMS_DEBUG_JDWP", line 68 ORA-06512: at line 1 This blog will walk you through the cause and step-by-step resolution of this issue using Oracle Access Control Lists (ACLs). ❓ What Is Causing This Error? ACL Restriction: The database user is trying to initiate a network connection (e.g., for debugging), but no ACL grants access to the specified IP and port. Missing Privileges: The user may lack the connect or resolve privilege in the ACL linked to that host/port. Example Failing Statement: CALL DBMS_DEBUG_JDWP.CONNECT_TCP('10.1.1.1', '62918'); ✅ Step-by-Step Solution 🔧 1. Create a New ACL BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL( acl => 'd...

Renaming a hostname in an Oracle Real Application Clusters (RAC) environment requires careful execution to ensure database continuity. This guide demonstrates how to rename the hostname in a two-node RAC cluster (devdb-01, devdb-02) by modifying devdb-01 to devdb-new-01. RAC User = DB HOME Owner GI User = GI HOME Owner or root Step 1: Remove the DB Instance from the Old Node On devdb-01 , connect as the RAC user and remove the running database instance: a. srvctl disable instance -db <db_unique_name> -instance <inst_name> b. srvctl stop instance -db <db_unique_name> {-node <old_node_name> | -instance <inst_name>} -stopoption NORMAL -failover c. srvctl remove instance -db <db_unique_name> -instance <inst_name> -force Step 2: Deconfigure Oracle Clusterware on the Old Node On devdb-01 , connect as the root user and execute: $GI_HOME/crs/install/rootcrs.sh -deconfig -force Step 3: Remove the Node from the Cluster On devdb-02 , connect as the root...

  Ever tried to drop a database in an Oracle RAC environment only to hit a frustrating error? You're not alone! Oracle Real Application Clusters (RAC) offers amazing high availability and scalability benefits, but it also introduces some interesting challenges for DBAs when performing certain administrative tasks. In this guide, I'll walk you through one of those common headaches: dropping a database in RAC—and share the exact solution that will save you hours of troubleshooting! Let's dive in! 🏊‍♂️ 💡 PRO TIP: Always make sure you have valid backups before proceeding with any database drop operation. Better safe than sorry! 🚫 The Challenge: That Dreaded ORA-01586 Error Picture this scenario: You need to drop a database in your RAC environment, you run the command and BAM! You hit this error: SQL> DROP DATABASE; DROP DATABASE * ERROR at line 1: ORA-01586: database must be mounted EXCLUSIVE and not open for this operation Frustrating, right? 😤 This happens bec...

  Resolving OPatch Error OUI-67064: OPatchSession Cannot Load Inventory When applying patches using OPatch on Oracle Database or Grid Infrastructure, you may encounter error OUI-67064. This post explains the troubleshooting steps to resolve this common issue. The Error OUI-67064: OPatchSession cannot load inventory for the given Oracle Home /opt/oracle/product/19.3.0/db_1. Possible causes are: - No read or write permission to ORACLE_HOME/.patch_storage - Central Inventory is locked by another OUI instance - No read permission to Central Inventory - The lock file exists in ORACLE_HOME/.patch_storage - The Oracle Home does not exist in Central Inventory This error indicates that OPatch is unable to read or interact with the Oracle Inventory, which is critical for patching operations. Root Cause Analysis After examining the logs and directory structures, a mismatch in ownership within the central inventory directory  /opt/app/oraInventory  was identified. The directory list...

Oracle Real Application Clusters (RAC) provide high availability, scalability, and manageability for databases. One of the most powerful tools for managing RAC databases is srvctl , a command-line utility that allows administrators to control various database services. This blog explores essential srvctl commands to help you efficiently manage Oracle RAC environments. 1. Checking Database Configuration and Status  List all available databases on the host:                  srvctl config database   Check the status of a specific database and its instances:                    srvctl status database -d <database_name>   Retrieve detailed status information about a database, including its instances and states:                    srvctl status database -d <database_name> -v 2. Stopping and Starting Databases   ...

  Oracle Database Manual Switchover: A Comprehensive Guide Database high availability is critical for enterprise applications. Oracle's Data Guard provides robust disaster recovery capabilities, including the ability to perform planned switchovers between primary and standby databases. This blog post walks through the process of manually switching over from a primary database (DC) to a standby database (DR) and then switching back. Environment Details Primary Database (DC): testpri Standby Database (DR): testsby Pre-Switchover Verification Before initiating a switchover, it's essential to verify the current database state and ensure log shipping synchronization. Step 1: Check Active Sessions First, check for active database sessions that might be affected during the switchover: There should not be not active session, if there are any check with application team and kill those sessions. set time on col machine for a30 select MACHINE, count(*), status from v$session gr...