ORA-01017 in RAC 12c and above ? Stepwise Permission Fix & Cause identification

  As an Oracle DBA, few things are more frustrating than a sudden loss of remote connectivity right after a routine SYS password reset. You type in the credentials, and bam -- ORA-01017 greets you, even though your local connections work fine. In production RAC environments, this isn’t just about a mistyped password.

Recently, I faced a tricky scenario in an Oracle 19c RAC setup with proper role separation between the grid and oracle OS users. What seemed like a simple password mismatch quickly unraveled into a multi-layered “permission deadlock,” involving rogue listeners, contaminated IPC sockets, and GPnP directory access issues. It took a careful, stepwise approach to restore connectivity across all nodes without compromising the cluster.

Oracle RAC Load Balancing Internals Explained

 Most RAC clusters look healthy until the workload shifts suddenly.

A reporting job starts hammering one node. Connection pools keep sending sessions to the same instance. CPU climbs, gc waits spike, application response times become unpredictable, and suddenly everyone starts blaming storage, SQL plans, or the network.

But many times, the real problem sits in the RAC connection routing layer itself.

I have seen large RAC environments where all nodes were technically UP, yet one instance was drowning while another sat nearly idle. The cluster wasn’t failing. The load balancing strategy was.

Oracle RAC load balancing is often misunderstood because people assume SCAN alone magically distributes workload intelligently. It does not.

Oracle Data Pump Migrations: What Breaks in Real Upgrades

Most DBAs discover the real complexity of Oracle database migrations only after the first large-scale Export/Import cutover goes sideways. On paper, Oracle Data Pump looks straightforward. Export the database, import it into a newer release, validate the objects, switch applications, done.

Reality is usually messier.