Exercise 2: sar vs. a top -b Log — Possible Solution
====================================================================

WHAT sar -u TELLS YOU
------------------------------
Per this chapter, sar's historical logging "confirms a genuine 92% CPU
spike at 2:10 AM" - it tells you a system-wide CPU spike happened, and
exactly when, but sar's own -u output is an aggregate system-wide
figure. It doesn't identify which individual process was responsible.

WHAT A top -b LOG TELLS YOU
------------------------------
Per this chapter, "a top -b log, if one was already running, or a
targeted historical process-accounting tool, fills that gap" -
grepping the log for the same timestamp revealed "a nightly database
reindex job, running at exactly 02:10." A top -b log captures the full
per-process breakdown at each sampled moment, which is what actually
names the specific responsible process.

WHY BOTH TOGETHER, NOT JUST ONE
------------------------------
Per this chapter, the two are "two independent sources of evidence,
checked separately, agreeing on the same answer." sar answers "when
did something happen system-wide," while the top -b log answers "which
specific process was running at that exact moment." Neither alone
answers both questions - sar has no per-process detail, and a top -b
log without knowing the right timestamp to search would require
manually scanning through potentially hours of samples rather than
jumping straight to the relevant moment.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly distinguishes what each tool actually reports (system-wide
aggregate vs. per-process detail), and explains why using sar's
timestamp to narrow the top -b log search is more efficient and more
confidently correct than relying on either tool alone.