Many reasons exist to restore a database, including the following:
- A disk subsystem has failed.
- A sleepy programmer forgot a where clause in a SQL UPDATE statement and updated everyone's salary to minimum wage.
- Zombie apocalypse destroys your primary data center.
- A large import worked but with yesterday's data.
The best reason to restore a database is to
practice the backup/restore cycle and prove that the recovery plan
works. You must perform regular testing of your backup and restore
strategy as a fire drill. Without confidence in the recovery, there's
little point in doing backups. Remember this mantra: Backups are
worthless; restores are priceless.
Detecting the Problem
If a database file is missing, clicking
the database in Management Studio pops up a message saying that the
database is unavailable. To further investigate a problem, check the
SQL Server Errorlog. In Management Studio, you can view the log under
Management ? SQL Server Logs. SQL Server writes errors and events to an
error log file in the \Log directory under the MSSQL
directory. SQL Server creates a new file every time the SQL Server
service starts. The six previous versions of the Errorlog file are
saved in the same directory. Some errors may also be written to the
Windows Application Event Log.
Note
To retain more than six Errorlogs, right-click SQL Server Logs in Management Studio, and select Configure.
Tip
You can also manually “roll the log” by using the stored procedure sp_cycle_errorlog.
This can be helpful if you want to keep the error log's content limited
to a certain time period. For example, you can schedule an agent job to
execute the sp_cycle_errorlog command every day at midnight.
In addition to rolling over the log on a
scheduled basis, you probably want to increase the number of logs to
retain from the default value, as stated in the previous Note. When
configuring the number of logs to retain because the log rolls over
with every service restart, you need to configure a number large enough
for you to accommodate unexpected service restarts along with your
scheduled ones.
Recovery Sequences
The two most important concepts about recovering a database are as follows:
- A recovery operation always begins by restoring a full backup and
then restores any additional differential or transactional backups. The
restore never copies only yesterday's work. It restores the entire
database up to a certain point.
- There's a difference between restore and recover. A restore copies the data back into the database and leaves the transactions open. Recovery
is the process of handling the transactions left open in the
transaction log. If a database-recovery operation requires that four
files be restored, only the last file is restored WITH RECOVERY.
Only logins who are members of the sysadmins fixed server role can restore a database that doesn't currently exist. sysadmins and db_owners can restore databases that do currently exist.
The actual recovery effort depends on the type of damage and the previous recovery plans. Table 1 is a comparative listing of recovery operations.
Table 1 Recovery Sequences
| Simple |
1) Restore full backup.
2) Restore latest differential backup (if needed). |
It is likely there are unapplied transactions lost
with the transaction log and the database is inconsistent. It is
recommended to fall back on your backups and use the steps documented
for “damaged database file.” |
| Full or Bulk-Logged |
1) Back up current transaction log with the NO_TRUNCATE option.*
2) Restore full backup.
3) Restore latest differential backup (if needed).
4) Restore all the transaction-log backups since the last
differential or full backup. All committed transactions will be
recovered. |
1) Restore full backup.
2) Restore the latest differential backup (if needed).
3) Restore all the transaction-log backups since the last differential or full backup.
Transactions made since the last log backup will be lost |
