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.
Hardening, patching, auditing, automation
Security and operations is where Oracle databases quietly accumulate risk: patches deferred because they're scary, audit settings nobody owns, hardening checklists with 200 items and no priority. These guides cut that down to what actually matters — quarterly patching demystified (CPU vs RU vs RUR), a hardening checklist that isn't busywork, auditing that answers real questions, and the automation that makes all of it repeatable instead of heroic.
Lab Restarting the listener, the usual first reaction, caused a minute of ORA-12514 for every service. ALTER SYSTEM REGISTER closed it at once.
Lab With default settings, a packet capture shows the SQL and the secret in plain text. With encryption REQUIRED on the server, it shows neither.
Lab Privilege Analysis showed the account used 3 of the 12 privileges it was granted, and none of the ANY privileges.
Lab One ORDERS table, three readers, three different answers, enforced inside the database, not in the app.
Lab The clerk saw ****-****-****-0001, but the real card prefix was still in the datafile 161 times. Redaction masks the query, not the disk.
Lab The same canary rows, read straight off disk: 133 hits in the ordinary datafile, none in the TDE-encrypted one.
Lab 3 events triggered, 3 captured: after a flush, UNIFIED_AUDIT_TRAIL held the failed login, the new user and the read of the sensitive table.
Lab A deliberately weak database, scored against the checklist, then hardened until every check flipped from FAIL to PASS.
Lab Only one of the transcripts is actually done: opatch, version_full and DBA_REGISTRY_SQLPATCH all agree on 19.27 with SUCCESS.