ORA-12514: The Database Is Up. The Listener Just Doesn't Know It.
Lab Restarting the listener, the usual first reaction, caused a minute of ORA-12514 for every service. ALTER SYSTEM REGISTER closed it at once.
Vendor-neutral, field-tested guidance for teams running mission-critical Oracle databases — on-prem and on OCI or Azure. Turning 3am incidents into boring, automated, observable systems.
Why changing an application account's password causes ORA-01017 and then ORA-28000 for every app server, including the ones that already have the new password, and how gradual password rollover (PASSWORD_ROLLOVER_TIME, 19.12 and later) lets the old and new password both work. With a lab: 6 of 6 old-password logins refused and the account locked, versus 0 of 7 with rollover, and the audit query that shows who is still on the old password.
Read the postLab Restarting the listener, the usual first reaction, caused a minute of ORA-12514 for every service. ALTER SYSTEM REGISTER closed it at once.
Lab 10x the TEMP bought 10x the runtime and the same error. Restoring one join predicate made the report need none.
Lab The same 100,000-row update spent 11.9 of its 14.1 seconds waiting for a redo log. Bigger logs: 1.9 seconds, zero waits.
Lab The first bind value decided the plan for everyone. The common value inherited a nested-loops plan at 17 times the work, five runs in a row, and adaptive cursor sharing never stepped in.
Lab Row counts matched 10,000 to 10,000, and the first new order still failed: the target sequence was handing out 9,001 while the table already went up to 10,000.
Lab Deleting 99% of the rows didn't change the full scan's cost at all. SHRINK SPACE cut it 95-fold.
RAC, Data Guard, RMAN, failover & recovery
AWR/ASH, wait events, SQL & optimizer tuning
OCI, Azure, Exadata, 23ai/26ai, on-prem → cloud
Hardening, patching, auditing, automation