At 10:42 a user accidentally deleted several thousand order rows in a production database that uses the full recovery approach with nightly full backups and transaction log backups every 15 minutes. The business wants the data as it was just before the mistake. What should the DBA do?
Select an answer to reveal the explanation.
Short Explanation
Point-in-time restore is like rewinding a security video to the second before the spill. You replay the full backup plus the logs and stop right before 10:42. A synchronous replica won't save you here; it copied the delete the instant it happened.
Full Explanation
Point-in-time recovery uses a full backup as the base and replays transaction log backups up to a chosen moment. Here the DBA restores last night's full backup and the subsequent log backups with recovery stopped at a time just before 10:42, which yields the database exactly as it was before the delete. Restoring to a separate copy rather than over production avoids discarding the legitimate work done since 10:42; the missing rows are then copied back into production, after which the team confirms counts and dependent data. Restoring the full backup over production would lose every committed change since midnight, far more data than necessary. Restoring only the latest log backup is impossible because a log backup contains a record of changes, not a standalone copy of the data, and it must be applied in sequence on top of a restored base. Failing over to a synchronous replica does not help because synchronous replication applies the delete on the replica as part of the same commit, so the replica holds the same missing rows. Exam caveat: replication and high availability protect against component failure, while backups and restore points protect against logical errors. Operational check: confirm the log chain is unbroken from the full backup through the 10:30 to 10:45 interval before starting.