Oracle Database Health and Licensing Checklist

Database / estate: _______________ DBA owner: _______________ Date: _______ Version and edition: _______________ Supported until: _______

1. Licensing — the part that becomes expensive quietly#

• [ ] Edition recorded (Standard / Enterprise) and matched against features actually in use
• [ ] Enterprise-only options and packs checked — partitioning, advanced compression, advanced security, diagnostics and tuning packs
• [ ] Feature usage evidence gathered from the database itself, not from memory
• [ ] Licensing metric understood (processor vs named user) and counted correctly
• [ ] Virtualisation and cluster boundaries reviewed — how the vendor counts cores in your hypervisor is a contractual question, not a technical one
• [ ] Cloud deployments checked against the relevant licensing policy
• [ ] Standby and test environments accounted for
• [ ] Contracts and entitlement records located and readable

🔴 The classic finding is a diagnostics or tuning pack used casually through a monitoring tool on a database licensed without it, for years. Usage accrues silently and surfaces in an audit as a back-dated bill. Check what is enabled as well as what is installed, and get a specialist opinion before an audit rather than during one — this checklist is not legal or contractual advice.

Features in use that require a separate licence: _______________

2. Backup and recovery#

• [ ] Backup strategy documented — full, incremental, archive log
• [ ] Archive log mode appropriate to the recovery requirement
• [ ] Backups stored off the database host
• [ ] Backup integrity verified, not just reported as successful
• [ ] Restore tested on ____ — took ____
• [ ] Point-in-time recovery tested, not assumed
• [ ] Recovery objectives (RPO/RTO) written down and achievable
• [ ] Retention meets any regulatory requirement

A backup that has never been restored is a belief. Fill in the dates.

3. Availability#

• [ ] Standby or replication configured where the requirement justifies it
• [ ] Failover tested, with the time recorded
• [ ] Failback path documented
• [ ] Application behaviour during failover understood — connection handling, in-flight transactions
• [ ] Single points of failure identified

4. Performance#

• [ ] Baseline captured while performance is acceptable, so degradation is detectable
• [ ] Top resource-consuming statements reviewed
• [ ] Statistics gathering scheduled and verified as running
• [ ] Index usage reviewed — unused indexes cost writes and storage
• [ ] Tablespace growth trended, with headroom
• [ ] Automated jobs reviewed for overlap with peak load

Note: several diagnostic and tuning capabilities require separately licensed packs. Confirm entitlement before using them; see §1.

5. Patching and support#

• [ ] Current version's support status known, with the end date
• [ ] Quarterly patch process defined and actually followed
• [ ] Last patch applied: _______
• [ ] Test environment patched first
• [ ] Downtime window agreed with the business

6. Security#

• [ ] Default and sample accounts removed or locked
• [ ] Privileged access reviewed and time-bound where possible
• [ ] Application accounts hold least privilege, not DBA
• [ ] Auditing enabled to a level someone reviews
• [ ] Encryption at rest and in transit decided, with licensing implications checked
• [ ] Database not reachable from untrusted networks
• [ ] Production data in non-production environments masked or removed

7. Operations#

• [ ] Alerting on space, errors and job failures, routed to a person
• [ ] Runbook for the three most likely failures
• [ ] More than one person can perform a recovery
• [ ] Configuration and scripts in version control

Sign-off#

Back to Oracle