A team has changed how its ORM loads related order lines and wants to know, objectively, whether the change made database performance worse before rolling it out widely. Which approach measures the impact most reliably?
Select an answer to reveal the explanation.
Short Explanation
You can't tell if something got slower unless you know how fast it was before. That's your baseline. Capture plans and metrics before the change, repeat after, and let the numbers decide instead of gut feel.
Full Explanation
Determining the impact of a programming change means comparing objective measurements before and after it under comparable load. The DBA records a baseline for the affected statements, including execution plans, duration, logical reads, CPU time and call counts, plus server-level metrics such as CPU, I/O and wait statistics. After the change is deployed to a test environment with representative data, the same measurements are taken and differences are attributed to specific statements. A changed plan, such as a scan replacing a seek, or a jump in call count from lazy loading, explains why performance moved. Estimating impact from the size of the code diff is unreliable, because a one-line fetch-mode change can multiply queries while a large refactor may change nothing. User perception after release is subjective, arrives too late and cannot isolate which query regressed. Passing unit tests prove functional behavior, not resource usage; most unit tests run against tiny data sets or mocks. Exam caveat: a baseline is only useful if it was captured under similar load and data volume. Operational check: store the baseline plan and metrics for each critical query, rerun them after the change, and flag any statement whose reads or duration rise beyond an agreed tolerance.