Select the product you need help with

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

Article ID: 2653893 - View products that this article applies to.

Microsoft distributes Microsoft SQL Server 2008 R2 Service Pack 1 (SP1) or Microsoft SQL Server 2008 or Microsoft SQL Server 2012 fixes in one downloadable file. Because the fixes are cumulative, each new release contains all the hotfixes and all the security updates that were included with the previous SQL Server 2008 R2 Service Pack 1 (SP1) or SQL Server 2008 or Microsoft SQL Server 2012 update release.

Back to the top | Give Feedback

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.

Back to the top | Give Feedback

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.

Back to the top | Give Feedback

RESOLUTION

Cumulative update information

SQL Server 2012

The fix for this issue was first released in Cumulative Update 1 for SQL Server 2012. For more information about this cumulative update package, click the following article number to view the article in the Microsoft Knowledge Base:

2679368

(http://support.microsoft.com/kb/2679368/LN/ )

Cumulative update package 1 for SQL Server 2012

Note Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2012 fix release. Microsoft recommends that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2692828

(http://support.microsoft.com/kb/2692828/LN/ )

The SQL Server 2012 builds that were released after SQL Server 2012 was released

You must apply a SQL Server 2012 hotfix to an installation of SQL Server 2012.

SQL Server 2008 Service Pack 2

The fix for this issue was first released in Cumulative Update 8 for SQL Server 2008 Service Pack 2. For more information about this cumulative update package, click the following article number to view the article in the Microsoft Knowledge Base:

2648096

(http://support.microsoft.com/kb/2648096/LN/ )

Cumulative update package 8 for SQL Server 2008 Service Pack 2

Note Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2008 fix release. Microsoft recommends that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2402659

(http://support.microsoft.com/kb/2402659/LN/ )

The SQL Server 2008 builds that were released after SQL Server 2008 Service Pack 2 was released

Microsoft SQL Server 2008 hotfixes are created for specific SQL Server service packs. You must apply a SQL Server 2008 Service Pack 2 hotfix to an installation of SQL Server 2008 Service Pack 2. By default, any hotfix that is provided in a SQL Server service pack is included in the next SQL Server service pack.

SQL Server 2008 Service Pack 3

The fix for this issue was first released in Cumulative Update 3 for SQL Server 2008 Service Pack 3. For more information about this cumulative update package, click the following article number to view the article in the Microsoft Knowledge Base:

2648098

(http://support.microsoft.com/kb/2648098/LN/ )

Cumulative update package 3 for SQL Server 2008 Service Pack 3

2629969

(http://support.microsoft.com/kb/2629969/LN/ )

The SQL Server 2008 builds that were released after SQL Server 2008 Service Pack 3 was released

Microsoft SQL Server 2008 hotfixes are created for specific SQL Server service packs. You must apply a SQL Server 2008 Service Pack 3 hotfix to an installation of SQL Server 2008 Service Pack 3. By default, any hotfix that is provided in a SQL Server service pack is included in the next SQL Server service pack.

Cumulative update package 11 for SQL Server 2008 R2

The fix for this issue was first released in Cumulative Update 11. For more information about how to obtain this cumulative update package for SQL Server 2008 R2, click the following article number to view the article in the Microsoft Knowledge Base:

2633145

(http://support.microsoft.com/kb/2633145/ )

Cumulative update package 11 for SQL Server 2008 R2

Note Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2008 R2 fix release. We recommend that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

981356

(http://support.microsoft.com/kb/981356/ )

The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 was released

Cumulative update package 4 for SQL Server 2008 R2 SP1

The fix for this issue was first released in Cumulative Update 4. For more information about how to obtain this cumulative update package for SQL Server 2008 R2 SP1, click the following article number to view the article in the Microsoft Knowledge Base:

2633146

(http://support.microsoft.com/kb/2633146/ )

Cumulative update package 4 for SQL Server 2008 R2 SP1

Note Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2008 R2 SP1 fix release. We recommend that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

2567616

(http://support.microsoft.com/kb/2567616/ )

The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 SP1 was released

Back to the top | Give Feedback

STATUS

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

Back to the top | Give Feedback

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.}

Back to the top | Give Feedback

REFERENCES

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

General information about log sequence numbers

(http://msdn.microsoft.com/en-us/library/ms190729(SQL.90).aspx)

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

(http://blogs.msdn.com/b/psssql/archive/2009/05/21/how-a-log-file-structure-can-affect-database-recovery-time.aspx)

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

General information about the transaction log file

(http://www.sqlskills.com/BLOGS/KIMBERLY/post/Transaction-Log-VLFs-too-many-or-too-few.aspx)

Back to the top | Give Feedback

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.

Back to the top | Give Feedback