When an application team requests to delete or drop a database, I would never do it immediately. Dropping a database is a high‑risk, irreversible operation, so I follow a controlled, auditable, and business‑safe process.
Below is the step‑by‑step approach I follow as a Database Architect/DBA.
1. Validate the Request (Do Not Trust Verbal or Email Only)
First rule: No action without formal approval.
I ensure:
- ✅ Official request exists (ServiceNow / Jira / Change Request)
- ✅ Database name, environment (DEV/UAT/PROD) clearly mentioned
- ✅ Reason for deletion documented (decommissioned app, migration completed, duplicate DB, etc.)
- ✅ Business owner and application owner identified
Why:
Databases often contain business‑critical or compliance‑required data, even if an application is retired.
2. Confirm Business & Compliance Approval
Before deletion, I verify approvals from:
- ✅ Application Owner
- ✅ Business Owner / Data Owner
- ✅ InfoSec / Compliance (if applicable)
- ✅ Change Management (for PROD)
For regulated environments (SOX, GDPR, PCI), deletion without approval can be a compliance violation.
✅ If approvals are missing → Reject or hold the request
3. Verify Environment & Impact
I double‑check:
- 🔍 Is this DEV / UAT / PROD?
- 🔍 Any other applications using the DB?
- 🔍 Any ETL, reporting, batch jobs, or integrations?
- 🔍 Any replication, standby, DR, or backups associated?
- 🔍 Any legal data‑retention requirements?
For PROD, I also:
- Review CMDB dependencies
- Check last connection timestamps
- Check storage & server dependencies
4. Take Final Backup (Non‑Negotiable)
Even if the team says “backup not required” — I still take one.
Backup types:
- ✅ Full online backup
- ✅ Restore test (optional but recommended for critical systems)
- ✅ Secure backup storage with retention (e.g., 30–90 days)
I document:
- Backup location
- Backup timestamp
- Backup checksum/status
🟡 In many organizations, backup before drop is a mandatory control
5. Consider Safer Alternatives First
Before dropping, I may recommend:
- 🔒 Make DB READ‑ONLY
- 🔒 Revoke application access
- 🔒 Rename database (e.g.,
APPDB_DECOM_2026JAN) - 🔒 Put DB on cheaper storage tier
- 🔒 Disable jobs and connections
This acts as a cool‑off period in case of accidental requests.
6. Execute Deletion During Approved Window
Only after: ✅ Approvals
✅ Backup taken
✅ Change window approved
Actions:
- Stop application connections
- Disable scheduled jobs
- Drop database or delete instance
- Clean up associated:
- Users
- Tablespaces/schemas
- Filesystems
- Monitoring alerts
- Backup jobs
Execution is done:
- In change window
- With rollback plan
- With peer review (for PROD)
7. Post‑Deletion Validation
After deletion:
- ✅ Confirm DB is removed
- ✅ Ensure no errors in application or jobs
- ✅ Verify monitoring alerts are cleared
- ✅ Update CMDB / inventory
- ✅ Close request with evidence
8. Documentation & Audit Trail
I attach to the ticket:
- Approval evidence
- Backup details
- Deletion timestamp
- Executor name
- Change ID
This protects:
- ✅ Organization
- ✅ DBA team
- ✅ Me personally
🚫 What I Will NEVER Do
❌ Drop PROD DB on verbal request
❌ Skip backup
❌ Assume "no one is using it"
❌ Perform deletion without approvals
❌ Execute outside change window
When an application team requests to drop a database, I first validate the request through a formal change process, confirm business and compliance approvals, assess dependencies, and take a final backup. I consider safer alternatives like making the database read‑only before deletion. Only after approvals and in an approved change window do I drop the database, followed by validation and documentation to ensure audit compliance.
No comments:
Post a Comment