KB2653893 - FIX: It takes a long time to restore a database in SQL Server 2008 R2 or in SQL Server 2008 or in SQL 2012

Symptoms

It might take a long time to restore a database in Microsoft SQL Server 2008 R2 or in Microsoft SQL Server 2008 or in Microsoft SQL Server 2012.

Cause

This issue occurs because it takes a long time to build the Virtual Log File (VLF) list when there are many VLFs in the database.

Resolution

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

More Information

You can check the number of VLF segments by reviewing the SQL error log file and then by finding the log sequence number (LSN) in each transaction log backup file. The first digits before the colon symbol in the LSNs correspond to the number of the LSN.

For example, the first number in the first informational message for the LSN is 1. However, the first number in the second informational message for the LSN is 100001. In this scenario, there are 100,000 VLFs that are used between the time of the first informational message and of the second informational message. Therefore, the logged fragmented transaction log that has many Virtual Log Files (VLFs) resembles the following:

{Log was backed up. Database: mydbname, creation date(time): 2010/07/08(12:36:46), first LSN: 1:5068:70, last LSN: 1:5108:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'C:\folder\logbackup1.trn'}). This is an informational message only. No user action is required.

Log was backed up. Database: mydbname, creation date(time): 2010/07/08(15:36:46), first LSN: 100001:5108:1, last LSN: 100002:5108:1, number of dump devices: 1, device information: (FILE=2, TYPE=DISK: {'C:\folder\logbackup2.trn'}). This is an informational message only. No user action is required.}

References

For more information about log sequence numbers (LSN), visit the following MSDN website:

General information about log sequence numbers

For more information about how a log file structure can affect database recovery time, visit the following MSDN website:

How a log file structure can affect database recovery time

For more information about the transaction log VLFs, visit the following MSDN website:

General information about the transaction log file

Workaround

• Wait for the restore or recovery operation to complete
  
  If you have a non-recovered database that is experiencing the slow performance when you restore or recovery the database, you may have to wait for the restore or recovery operation to be completed. For example, you might see the offline status or the recovering status in SQL Server Management Studio (SSMS) for a non-recovered database. Stopping SQL Server usually offers no relief for a slow recovery and may take more time to repeat the same recovery analysis phase, redo phase, or undo phase.

• Avoid restoring the transaction log sequence that contains thousands of VLFs
  
  If you experience the slow performance while you restore and recover a database by using a backup file, you can avoid restoring the transaction log sequences that contain thousands of VLFs. To identify the backup file that has the most the virtual log files recorded, use the following statement to see the FirstLSN and LastLSN columns in the log backup files:
  RESTORE HEADERONLY FROM DISK='C:\folder\file.trn'
  
  You can decide to avoid restoring the log backup files. Or, you can use the STOP AT statement in the RESTORE commands to avoid the highly fragmented parts of the transaction logs. If you do not fully restore the log sequences up to the latest point in time during a failure recovery scenario, data loss occurs in your database SQL Server. This data loss occurs because not all transactions are being kept. Therefore, there is a business tradeoff decision. You can fully restore a highly fragmented transaction log. However, this operation may take many hours. Or, you can use the STOP AT statement in the recovery to stop the recovery before the highly fragmented part of the log. However, any missing transactions that you omit are lost.
  
  Note Without installing this hotfix, there is typically no safe recourse for expedited recovery after you restart SQL Server. SQL Server has to locate the list of VLFs to analyze the log files, to redo completed transactions, and then to undo incomplete transactions to finish recovery to bring the database online safely. You cannot safely skip transactions during recovery.