IT tutorials

Microsoft SQL Server 2012 : Recovery Operations (part 1) - Detecting the Problem , Recovery Sequences

3/12/2014 2:50:55 AM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

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.

To retain more than six Errorlogs, right-click SQL Server Logs in Management Studio, and select Configure.

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

Recovery Model Damaged Database File Damaged Transaction Log
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

If the database uses the bulk-logged recovery model and a bulk-insert operation occurred since the last transaction-log backup, the backup will fail. Transactions that occurred after the transaction-log backup are not recoverable.

Top 10
Technology FAQ
- Microsoft ebs security server configuration
- IIs7 on Windows server 2003
- How to Configure Failover Clusters With Win 2008 Server R2?
- Windows 2008 Network Load Balancing
- Windows Server 2008 - Group Policy Management - Remove Computer Management
- Remove shortcuts possibility in a web page or to put in favorite
- HTA Dynamic Drop Down List
- IIS host header and DNS
- VMware or MS Virtual Server?
- Adobe Acrobat 9 inserting tab pages
programming4us programming4us