Monitoring, Alerts, and Troubleshooting
What the exam tests
This domain tests alert interpretation, health checks, log and task triage, and escalation boundaries.
Core rules
- NDB alerts cover server health, agent status, SLA failures, capacity, and task failures. Prism alerts cover the underlying cluster, storage, and VM layer.
- Check the NDB task detail first for orchestration failures; then check the agent and Prism for the underlying cause.
- Agent heartbeat loss usually points to network, DNS, NTP, or VM power state, not the database engine.
- Snapshot or backup failures often trace to Prism task errors, storage container capacity, or snapshot retention conflicts.
- Notification channels should route critical alerts to an owned queue; an unread dashboard is not monitoring.
- Keep NDB server, agent, and database logs for troubleshooting, and correlate timestamps across them.
Worked example
A nightly backup SLA reports failure for one Oracle database. The NDB alert shows a failed snapshot task. The administrator opens the task, sees a Prism snapshot error, checks the storage container, and finds it nearly full. After capacity is reclaimed, the next snapshot succeeds. The database itself was healthy; replacing the agent would not have fixed the storage issue.
Traps
Do not treat every NDB alert as an NDB server bug. Do not troubleshoot only the database when the failed task is at the storage layer. Do not ignore time skew, because log correlation and certificates depend on it. Do not close an alert without confirming the next scheduled run succeeds.