A maintenance window on a production database will include four tasks: a full backup, rebuilding several fragmented indexes, updating optimizer statistics, and purging rows older than the retention period. Which task should run first?
Select an answer to reveal the explanation.
Short Explanation
Before you start knocking down walls, you photograph the house. The backup is that photo: if anything in the maintenance window goes wrong, you've got a clean point to return to. A purge first sounds efficient, but if it removes the wrong rows, you've got nothing to roll back to.
Full Explanation
Maintenance that changes data or structures should begin with a verified backup so the team can recover if a task fails or produces unexpected results. The purge deletes data permanently, and index rebuilds modify large structures and can fail partway through, so having a fresh recovery point before either runs is the basic safeguard. Starting with index rebuilds to make the backup smaller or tidier puts structural changes ahead of the safety net; if a rebuild fails or exhausts space, the only recovery point is older. Running the statistics update before the rebuilds is the wrong order between those two tasks: a rebuild typically refreshes statistics on the rebuilt index anyway, so statistics maintenance normally follows index work, and in any case neither should precede the backup. Purging first to shrink the backup is the riskiest order, because an incorrect predicate or a misunderstood retention rule would permanently delete data with no recent backup to restore from. Exam caveat: many teams also run an integrity check before or with the backup so they know the recovery point is clean; the essential principle is that a reliable recovery point exists before change. Operational check: confirm the backup completed and its hash validates, then run the purge in controlled batches, rebuild indexes, update remaining statistics, and record durations for planning the next window.