A capacity planning report must state how much work the database completes each second during the evening peak so that it can be compared with the expected growth in orders. Which metric should the DBA report?
Select an answer to reveal the explanation.
Short Explanation
Think of a checkout lane: latency is how long one customer waits, throughput is how many customers get through per minute. When the question says 'how much work per second,' you want the second one. Open sessions are just people standing in the store; they don't tell you how many actually checked out.
Full Explanation
Throughput measures the volume of work a system completes per unit of time, typically expressed as transactions per second or queries per second for a database. It is the natural metric for capacity planning against growth in business volume, because it can be related directly to orders or requests and compared over time to show headroom. Latency measures how long an individual request takes; it is crucial for user experience and often rises as throughput approaches capacity, but a single latency figure does not say how many requests the system finished in a second. Buffer cache hit ratio describes the proportion of page reads satisfied from memory rather than disk; it is an efficiency indicator for memory sizing and says nothing direct about the amount of work completed. Concurrent connections count open sessions, many of which may be idle; a server with a high connection count can have low throughput, and connection pooling can make throughput high with few connections. Exam caveat: throughput and latency should be reported together, since throughput gains that come with unacceptable latency do not represent usable capacity. Operational check: collect transactions or queries per second at short intervals across the peak period, record the maximum sustained value alongside response times, and compare with the projected order growth to estimate when capacity will be exceeded.