It’s 9:40 on a Monday morning. A reporting application has slowed to a crawl, and the first tickets are already coming in. The network looks fine. So do the servers and storage. A call opens, and before long someone asks: is it the host, or is it the database?

Often, the assumption is that giving each team its own monitoring tool provides complete coverage. But when every team checks its own console and confirms its own systems are green, first-level operators in the Network Operations Center (NOC) are left to guess where the ticket belongs. When in doubt, the database usually takes the blame. Tanzania’s ran into the same problem as its banking infrastructure grew. Its story shows how answering that one question quickly changes the way a NOC works.

Why the question is so hard to answer

Modern environments are layered. Applications run on virtual machines, virtual machines share physical hosts, and everything depends on shared storage and databases. A problem in any one layer shows up as a symptom in the layer above it. That creates three familiar problems:

  • Misleading symptoms: An application can look broken when the real cause is an overloaded host underneath.
  • Bounced tickets: Without visibility into those relationships, operators pass tickets between network, server, storage, and database teams.
  • Defensive troubleshooting: Each team gathers evidence to prove its own layer is healthy, which delays the actual fix.

Until someone can see across those layers, every slowdown starts with a guess. This is the moment the webcast is built around: infrastructure signals look healthy, yet the database remains a blind spot.

Step one: rule out the infrastructure

At CRDB Bank, a 24/7 NOC team handles first-level monitoring and escalates to specialist teams for network, server, storage, and database issues. Its SolarWinds dashboards give operators one starting point for every investigation.

That starting point proved its value during a slowdown on a node running Power BI. In a siloed setup, the ticket would likely have gone to an application or database administrator for exploratory analysis. Instead, the NOC looked at the physical host behind the application. The host was running out of memory. The team moved the workload to a host with available resources, skipping hours of investigation in the wrong layer. The ticket reached the right team on the first try, and the database was ruled out before anyone had to open a query plan.

Step two: look inside the database

Of course, the host isn’t always the answer. Sometimes the database really is the bottleneck, and that is where infrastructure monitoring alone falls short. CPU and memory figures show that a database server is busy, but not what its queries are doing. A server at 90% CPU may be running batch jobs efficiently. A server at 15% CPU may be stalled because queries are waiting on disk or blocked by a lock. The utilization number alone can’t tell the two apart.

closes that gap by showing what queries are waiting on:

  • Wait-time analysis: Shows whether queries are waiting on disk, memory, CPU, or locks.
  • Blocking detection: Identifies the lead query holding up other sessions.
  • Tuning advice: Recommends query and index changes to relieve pressure.

At CRDB Bank, database administrators use DPA to investigate SQL Server blocking and elevated wait times. The handoff is then clean. The NOC rules out the host, and the database administrator starts with query-level evidence instead of a vague complaint.

The webcast walks through this same investigation: looking at waits, queries, workload context, and blocking, then improving incident routing and handoffs without requiring infrastructure teams to become DBAs.)

One view, one story

Taken together, the two steps follow the same pattern. The view that cleared the database in one incident gives the database team its evidence in the next.

For the NOC, that means:

  • Accurate routing: Operators send each ticket to the right team with supporting data.
  • Faster resolution: Teams spend less time debating whose layer is at fault and more time fixing the issue.
  • Proactive planning: Teams can spot memory and storage pressure before it affects users.

The question “host or database?” stops being a guess and becomes the first thing the NOC can answer. If your team still answers it by committee, is a practical place to start.

Frequently asked questions about unified IT monitoring

What is unified IT monitoring?

Unified IT monitoring brings performance data from networks, servers, virtual machines, storage, and databases into one console, so teams can see how each layer affects the others.

How does unified IT monitoring help the NOC isolate issues?

It connects applications to their underlying hosts and databases. Operators can then see whether a slowdown comes from the network, a saturated server, or a database lock.

How does wait-time analysis differ from resource monitoring?

Resource monitoring shows how busy hardware is. Wait-time analysis shows what database queries are waiting on, such as disk access, locks, or compute limits.

Why do infrastructure monitors leave a database blind spot?

They track servers and operating systems, but they can’t see which queries are running or which sessions are blocked.

Who is The Database Blind Spot webcast for?

It’s designed for IT operations, infrastructure and observability teams, application support, and database professionals working across complex environments.

Next steps

Tags:
database administrator
database management
database monitoring
dba
devops
information security
security information and event management