What you will learn
A retired database may still be referenced by clients, jobs, monitoring, or Data Guard. The removal runbooks are consolidated into one workflow. Broad ASM deletion is replaced by identity checks and the supported database-removal tool, while backup retention remains a separate decision.
Before you begin
Use an isolated Oracle Database 19c Linux lab with a certified patch level. Names host1.sample.com and host2.sample.com identify distinct lab hosts; replace them consistently with your own addresses. Use oracle for database software and grid for Grid Infrastructure where ownership is separated. Connect through local operating-system authentication or a configured wallet; no example includes a password. Preserve a tested backup and record the database identity before changes. Practice only on a disposable DEMO_OLD database. Prove it is neither the active primary nor a required standby. Record DBID, unique name, services, file ownership, and retention requirements. Keep a tested backup outside the files to be removed.
1. Capture exact identity
SELECT name,dbid,db_unique_name,database_role,open_mode FROM v$database;
SELECT name FROM v$datafile;
SELECT member FROM v$logfile;
SELECT name FROM v$tempfile;
srvctl config database -db DEMO_OLD
srvctl config service -db DEMO_OLD
srvctl status database -db DEMO_OLD
Match SQL identity with registration and migration records. Names can be reused. For a CDB inventory all PDBs before considering whole-database removal.
2. Prove replacement acceptance
Verify application writes and reads through the new service, backups, monitoring, and the required recovery protection. Repoint jobs and integrations. Deliberately update Data Guard dependencies before retirement instead of deleting a still-required standby.
3. Stop and observe
srvctl stop database -db DEMO_OLD -stopoption IMMEDIATE
srvctl status database -db DEMO_OLD
Run after the retirement window begins and clients drain. Observe for forgotten consumers before deletion. Update monitoring to reflect the planned stop while preserving evidence of unexpected dependency failures.
4. Use supported database removal
After recovery and retention gates pass, use Database Configuration Assistant from the correct home to select the exact retired database. Review affected files and resources. Inspect remaining registration, services, initialization files, and directories afterward. Shared homes, disk groups, and unrelated backups must remain. Avoid wildcard ASM deletion.
5. Read the example output
The following is illustrative, normalized output, not a transcript from a customer system. Values depend on your release and lab state.
Identity and DBID: matched
Replacement tests: passed
Retained backup restore: tested
Old service consumers: none observed
Exact removal: reviewed
Other databases: unaffected
Database removal is irreversible without a usable recovery copy; a checklist does not replace it.
Verify the result
Verify the old service is unavailable, the intended registration is removed after deletion, and other databases remain healthy. Confirm retained backup access and expiry independently.
Troubleshooting
Unexpected connections during observation reveal unresolved dependencies. Pause retirement and identify them. Leftover files are not safe to delete solely because their names resemble the retired database.
Recovery and next steps
Before deletion a stopped database may be restarted if configuration remains. After deletion recovery requires backup and configuration evidence. Keep the replacement mapping and restore instructions until retention expires.