Capacity, Performance and Database Management

Capacity, performance and database management. This lesson covers keeping systems fed with resources, and keeping the powerful people who run databases in check. Two surprises in one review, both the finding.

First surprise: the main system ran out of storage last quarter and stopped, and the response was to buy more disk after the outage, the third time this year the same thing has happened. Second surprise: a database administrator has been correcting figures by editing the production tables directly, because it is quicker than going through the application. Both feel like pragmatic operations. Both are the finding.

Start with capacity. The key point is that capacity management looks forward. It is proactive, not reactive: it provides the resources, processing, storage, memory, network, before they run out, not after the system has already stopped.

So what does proactive actually mean. It means monitoring utilisation trends and forecasting future demand, so resources are provided before they are exhausted. Watching storage climb toward its limit and expanding it in advance is capacity management working. Discovering the limit because the system stopped, and buying disk afterwards, is not capacity management at all, it is incident response to a shortage that planning should have prevented.

Alongside it sits performance management: monitoring response times and throughput against expected baselines and thresholds, so degradation is spotted and investigated before it becomes an outage. A system drifting slower over weeks is often the early warning of a capacity problem ahead.

Now the database, and why editing it directly is dangerous. The database sits underneath the application. Everything Domain three said about application controls, input validation, processing checks, an audit trail, is enforced by the application. When a D-B-A changes a value straight in the table, the change goes around all of it.

What does it escape. First, input validation, so the value could be out of range, malformed, or leave related records unbalanced.

And second, the processing controls and the audit trail, so totals and dependent data may no longer reconcile, and there is often no application record of who changed what, or why. So direct data changes are tightly restricted, and where genuinely necessary, they are authorised, logged and reviewed, never a routine shortcut because it is quicker.

Which brings us to privileged access. A D-B-A’s access is necessarily powerful: they can read, alter or delete almost any data and change the database itself. That power is required for the role, and precisely because of it, D-B-A activity is logged and independently monitored. The reviewer is someone other than the D-B-A, so the powerful access is accountable to a second pair of eyes.

And this is not a judgement about D-B-As personally. It is the same principle that governs any highly privileged access: the greater the power, the greater the need for its use to be traceable and independently reviewed. Logs that only the D-B-A can see, or that no one ever reads, are not a control.

So both habits in our review are findings. Reactive capacity management treats a resource running out as an operational hiccup, when the exam wants forward-looking, trend-based planning that prevents the shortage. And direct database edits look like harmless efficiency but bypass the application’s controls entirely, letting bad or unauthorised data enter with no trace.

So carry this away. Capacity management is forward-looking, built on trend analysis to meet future demand. And a D-B-A’s direct data change bypasses the application’s validation and audit trail, which is why privileged database access is logged and independently reviewed.