Managing and Monitoring Autonomous Databases
Domain 3: Managing and Monitoring Autonomous Databases
This domain tests day-2 operations: observing performance, scaling, backups, patching, and availability. The exam favors console-based evidence and automated-feature behavior over manual DBA habits.
Core rules and concepts
- Use the OCI Console database details page for metrics and lifecycle actions; use Performance Hub for ASH analytics, SQL monitoring, and AWR/ADDM-style performance diagnosis.
- Automatic maintenance covers patching, statistics, and backup operations within maintenance windows. You monitor and schedule around it; you do not run operating-system patches.
- Auto scaling adjusts compute within limits; you can also scale compute up or down. Storage expands automatically and is managed separately.
- Automatic backups are enabled by default; manual backups and point-in-time restore/clone support recovery. Retention is finite, so long-term retention needs an explicit plan.
- Autonomous Data Guard provides a standby for cross-region or same-region protection, with switchover and failover operations. It is not the same as a backup.
- Monitor CPU, storage, sessions, transaction rate, failed logins, and alert logs; create OCI alarms for thresholds that matter.
Worked example
A monthly report slows sharply while OLTP remains normal. Open Performance Hub, inspect ASH top wait events for the report's time window, then SQL Monitoring for the specific SQL. If the plan shows parallelism waits or a stale statistic, gather statistics or tune the SQL rather than immediately scaling compute. Reasoning: the symptom is workload-specific; scaling would raise cost without proving the bottleneck.
Traps that cost marks
- Assuming Autonomous Database requires manual patching or OS access.
- Treating auto scaling as unlimited or as storage scaling.
- Confusing Data Guard with backup/restore.
- Ignoring maintenance windows when diagnosing transient slowdowns.
- Monitoring only CPU while missing storage or session limits.