Skip to main content

Recover from corrupt SQL LDF transaction log file

Another favourite this month. A fault on one of our client's servers caused it to restart once every 10 minutes for 2 hours - the result was a corrupt LDF transaction log file for the main application database.

It is surprisingly simple to recover from this situation:

1. Stop the SQL Server service
2. Copy the affected database (both LDF and MDF files) out of the main data folder.
3. Restart the SQL Server service
4. Create a new database of the same name and location as the database affected in step 2 - it is critical the filenames and paths are identical.
5. Stop the SQL Server service.
6. Copy the original MDF file (copied in step 2) in to replace the new MDF file created in step 4
7. Start the SQL Server service - the database will show as being suspect.
8. Now you need to recover the database, working from Query Analyser or SQL Management Studio:

Use master

sp_configure 'allow updates', 1
reconfigure with override

select status from sysdatabases where name = '{{DBName}}'
-- Make a note of the status - in case you need to restore the value.

update sysdatabases set status = 32768 where name = '{{DBName}}'

9. Restart SQL Server - the database should now show up in emergency mode.
10. Delete the LDF file for the database.
11. Rebuild the transaction log:

DBCC REBUILD_LOG ('{{DBName}}', '{{Full path to the LDF file}}')
-- SQL Server will confirm: Warning: The log for database '' has been rebuilt.

12. If all appears to be OK:

USE {{DBName}}

13. If all still appears to be OK:

sp_dboption '{{DBName}}', 'single_user', 'false'

Use master

sp_configure 'allow updates', 0


Skodaddy said…
Query soesn't work, in SQL2005/2008, you can't just update the sysdatabases:

Ad hoc updates to system catalogs are not allowed.
Slogicus said…
I agree with Skodaddy - this post was written for SQL 2000.

Popular posts from this blog

Ad hoc access to OLE DB provider has been denied

Using post SP2 SQL 7 (+ 2000 etc) attempting to access an OLEDB data source using OPENROWSET can produce the slightly spurious error: Ad hoc access to OLE DB provider 'MSDASQL' has been denied. You must access this provider through a linked server. In usual Microsoft style the message doesn't really mean what it says. From SQL 7 SP2 onwards MS by default blocked ad hoc query access with OLEDB. As the message suggests you could setup a linked server but that can be a real pain. Alternatively if you need ad hoc access server wide you could turn on ad hoc access for the SQL server you are using, explained in MS speak here: Ah, but it's not that simple. A little more witchcraft is required. The following registry settings can be used to enable ad hoc access: REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers] "DisallowAdhocAccess"=dword:00000000 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLSer

Take website screenshot using ASP.NET

Utilising a hidden web browser control it is possible to take a screenshot of any website. The code shown below is based on an article at  (sorry the site now appears to be offline May 2012) but I have translated it from VB.NET to C# and will work in .NET so theoretically for any Windows or ASP.NET web project. using System; using System.Drawing; using System.Drawing.Imaging; using System.Windows.Forms; using System.Diagnostics; namespace WebsiteScreenshot { public class GetImage { private int s_Height; private int s_Width; private int f_Height; private int f_Width; private string myURL; public int ScreenHeight { get { return s_Height; } set { s_Height = value; } } public int ScreenWidth { get { return s_Width; } set { s_Width = value; } } public int ImageWidth { get { return f_Width; } set { f_Width = value; } } public int ImageHeight { get { return f_Height; } set { f_Height = value; } } public string Websit