All topics
55 / 55
Adminadvanced

Monitoring, Alerting & Capacity Planning

Explain how a production OBIEE/OAC deployment is proactively monitored for health and capacity, closing the loop from reactive troubleshooting to preventive operations.

Every other admin topic in this list is fundamentally reactive — something already broke or slowed down, and you diagnose it. This final topic is about the proactive discipline that reduces how often that reactive work is needed in the first place, and interviewers ask about it as a capstone because it demonstrates genuine platform-ownership thinking rather than just report-building or one-off troubleshooting skill.

It's like the difference between a car that only tells you something's wrong when the engine actually stops (purely reactive) versus one with a dashboard tracking oil life, tire wear, and fuel efficiency trends over time, warning you well before a part actually fails and letting you schedule maintenance on your own terms instead of getting stranded on the highway.

Key Concepts

1
System-level monitoring covers the infrastructure OBIEE/OAC runs on: WebLogic managed server health (JVM heap usage, garbage collection pauses, thread pool saturation), BI Server (nqsserver) process health and query queue depth, Presentation Services session counts, and the underlying host/VM's CPU, memory, and disk I/O — typically fed into Oracle Enterprise Manager Fusion Middleware Control for on-premise deployments, or OCI Monitoring/Application Performance Monitoring for OAC, and often forwarded into a broader enterprise monitoring stack (Grafana, Splunk, or similar) so BI isn't monitored in a silo separate from the rest of IT operations.
System-level monitoringnqsserver
2
Application-level monitoring layers on top of this using the Usage Tracking data discussed earlier — tracking trends over time (is average query duration creeping up month over month even though nothing obviously changed? is concurrent user count approaching a previously-tested capacity ceiling?) rather than just reacting to individual slow-query complaints. Alerting should be tiered by severity: a full component outage warrants immediate paging, while a slowly degrading trend (rising average query time, growing cache miss rate) warrants a daily/weekly digest a BI admin reviews proactively rather than an urgent page.
Application-level monitoringAlerting
3
Capacity planning uses this same historical trend data to answer forward-looking questions before they become emergencies: at current growth rates, when will concurrent user counts or data volumes exceed what the current cluster size or aggregate table design was tested for, and what specifically needs to scale first (add a BI Server node? build a new aggregate table? increase a connection pool?) — a senior-level answer explicitly connects capacity planning back to the architecture, caching, and aggregate navigation topics discussed earlier, since "add more hardware" is rarely the first or only correct answer; often a smarter aggregate strategy or better dashboard design defers the need for additional infrastructure entirely.
Capacity planning
Use cases:monitoringcapacity-planningproactive-operations