Wednesday, June 12, 2002

Recovering from a deleted log file on SQL Server

Introduction
This document will give instructions on how to recover from a deleted database log file on Microsoft SQL Server. The database this was done on was SQL Server 7 with SQL Server 2000. You will get a suspect beside the name of the database when this happens.

You may be interested in the document if one of the following happened:

  1. You're log file got too big so you decided to shutdown SQL Server,
    then delete the log file.
  2. Salvage data from a damaged SQL data (.MDF) file. ( Someone emailed about this ).

That's the only reason I can think of right now and that is the reason I have come to figuring this out, so here goes.

Instructions
If you have a recent backup of the database, USE IT! Forget about this article and do a normal restore procedure. Otherwise read on. First of all, you are SOL if you want a full recovery. You just can'tget all the data back because the log file itself contained a lot of transactions that may never have made it to the data file.

So anyways, I read just about everything possible on this topic and nothing worked, I mean nothing. I tried going into emergency mode, running stored procedures that did squat, using sp_detach_db, then sp_attach_db, etc, even trying db_rebuild_log() (the rebuild_log thing seems to be an undocumented feature that someone must have figured out... easter egg?? not really since there are some serious warnings against using it, but hey, when you're in dire straits, you'll try anything once, right?).

This restore procedure doesn't seem to be formally documented anywhere. I guess you're just not supposed to be this stupid, but everybody makes mistakes don't they? And hey, I'm no DBA or anything! I just use the damn things. ;-)

Anyways, on to the guts of the article. I am trying to make this as simple
as possible and pulling this from memory so if there is something I am
missing, please post a comment.

There's one thing to note here and if someone could verify it, that would be great. First thing I'd like to verify is if you can just skip to step 9 right off the bat? So as soon as you get a suspect database, can you just start at step 9? Can someone please try that and let me know. SEE

UPDATE: JAN. 6, 2003 BELOW

  1. Backup the data (.mdf) file! Just in case. We take no responsibility
    for anything that happens following this procedure.
  2. EXEC sp_detach_db 'dbname' -- this will detach the database from
    the server
  3. Restart SQL Server
    The database may still be seen in enterprise manager, but just ignore
    it.
  4. Create a new database with the same name or a different name. You
    will have to use a different physical file name, which is fine.
  5. Stop SQL Server.
  6. Rename the new data file that was created to something else (ex: add.bak
    to the end)
  7. Rename the old data file that you want to restore to the name of the
    newly created file (the same name as the file you changed in the step
    above)
  8. Start SQL Server
    Now the db will still be suspect but you now have a log file.
  9. Switch to emergency mode on the database. You do this by doing the
    following:

    1. Right click on the database root node in Enterprise manager and
      bring up the properties.
    2. Under the Server Settings tab, check of "Allow modifications
      to be made directly to the system catalogs".
    3. click ok
    4. Now go to the master database and open the sysdatabases
      table.
    5. Find the suspected database in here and modify the status column,
      setting it to: 32768. This will put it into emergency mode.
    6. stop then start sql server

  10. Now here's the tricky part and I'm not sure how this will work on
    a single install, i was lucky enough to have SQL Server 2000 installed.
    But anyways, open up the Import and Export Data (DTS) program from the
    start menu. And you want to copy data from the old database to a brand
    new one. Just copy tables and views.

And voila, this should work smoothly. Let me emphasize should.

UPDATE: Jan. 6, 2003

I just received an email from someone who tried starting at step 9 and he said it worked. If I can get someone else to confirm that, then I'll get rid of 1-8.

UPDATE: June 18, 2003

It seems that some people can just do 9-10 and some have to do all the steps.

Emails Received in Response to this Article

There have been many emails we have received about this article both sharing their experience and praising the instructions.

Read the emails here

23 Comments:

At Wednesday, November 10, 2004 11:24:00 PM, Travis Reeder said...

I just got this comment in email the other day:
-------
Hi

Your article saved me my home! I almost lost a huge amount of data which would have resulted in losing my job and then my home!!

Your article on rebuilding a database from a missing (coughs embarrassed) SQL ldf file saved my bacon.

Thank you

Regards

Anonymous idiot who promises not to ever do anything so stupid again!

 
At Wednesday, December 15, 2004 10:38:00 PM, Travis Reeder said...

Got this one today:

Hello,

When I had read your domain name, I instantly had hope again that we would be able to salvage our mdf file. This is in response to the rocket science (http://www.spaceprogram.com/knowledge/sqlserver_recover_from_deleted_log.html) that you have provided and it is gratefully appreciated. I don't understand why your posting is buried 12-14 pages deep in a google search. Our hard drive is currently at a data recovery shop and they have been unable to recover data from this file. We tried using the MSSQL Recovery tool from www.officerecovery.com, but bombed out as well. We tried all the sp_attach procedures, the undocumented db_rebuild_log() and/or DBCC REBUILD_LOG and nothing worked. Knowing that we were not alone, I googled and found your posting. I can not thank you enough.

Here is a little background to our situation,

When I came in the nearly 10 days ago, the db box was blue screened.
I tried to restart, it came back with 'error loading os".
I then put the hd in another box so that it could be seen as a second drive.
This caused chkdsk to run and that messed everything up.
It moved things, deleted others and just left us with a mess.
I was able to find and salvage the mdf file and ldf, but the ldf was 107 Gigs and sql server 2000 wouldn't recognize the files.
A co-worker started looking at the mess and he somehow deleted the ldf, and this is where we were at before I found your posting.

After exhaustive trials and failings and a good amount of money spent, again I want to thank you. Maybe you should set up a donations page.

J

 
At Friday, February 18, 2005 4:29:00 PM, Travis Reeder said...

Got this one a while ago: 9/29/2004

FYI, I skipped step1-8 and it worked.

THANK YOU SO MUCH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 
At Monday, March 28, 2005 11:36:00 PM, Travis Reeder said...

And here's another that was received today from D.R.:

Just a thank for having this document available. As you stated, the possibility of some tables/views might
not be copied. Most of my data was recovered using your wonderful article.

I did have a couple tables/views that would begin to copy and then error out (i.e. Error at Source Row 93701, I/O Error (Bad Page ID) detected durign read.

Do you know or could you refer me to someone who could help me with this. I work for a non-profit medical institution but would be more than willing to pay for someone's time (could be on the phone) to help
me get the rest of these tables/views copied over.

Thanks again for your article, it was a life saver..

 
At Tuesday, April 26, 2005 3:20:00 AM, Ong said...

hi all... :( i still not able to attach back my database.my case is same like pat that posted the mess near jan 2004. my database has 1 mdf file, 1 log file, and 2 file with ndf extension n 3 file without extension.

i has able to attach the mdf file. but there are some table that link to the secondary file can not show the data.

can anyone help me????
thanks...

 
At Saturday, August 27, 2005 4:11:00 PM, Anil said...

Thank a ton buddy. I was stuck with a similar issue and your solution solved the issue in one go. Thanks again.

 
At Saturday, August 27, 2005 4:19:00 PM, Anil said...

Thank a ton buddy. I was stuck with a similar issue and your solution solved the issue in one go. Thanks again.

 
At Thursday, September 29, 2005 7:31:00 AM, Razzorx said...

Yo there

there is a little "hint" in case of the growin' of ldf-files...

If u go to DB-Properties u have the possibility to tell SQL-Server the MAXIMUM of your ldf-file... so just deactivate "autogrowing" of the ldf and set a specific amount of max. MB's.

This should give u the possibility to rest in peace ;)

Greez

 
At Friday, September 30, 2005 1:02:00 AM, Razzorx said...

Hey again:

I've wrote a description on how to manage SQL-LDF size.

This should solve the problem with big-sized ldf's cus the sql-server itself manages the MAXIMUM size.

Peace yo


English Version:
http://sqlandcrystalreports.blogspot.com/2005/09/sql-ldf-file-is-too-big-english.html


German Version:
http://sqlandcrystalreports.blogspot.com/2005/09/sql-ldf-file-zu-gross-german.html

 
At Wednesday, December 14, 2005 4:05:00 PM, Travis Reeder said...

Got this one on Oct. 13, 2005:

Just wanted to say thanks for posting the below webpage; this has proved extremely valuable for us today! Worked exactly as you said, and we also extracted stored procedures, triggers, data types and functions too.

http://www.spaceprogram.com/knowledge/sqlserver_recover_from_deleted_log.html

Thanks again,

Will

 
At Thursday, December 15, 2005 4:45:00 PM, Travis Reeder said...

This was from July 26, 2005:

Hi there

First i wanna say, that i have been in great pain when my (and its pretty large) DB crashed and went "suspect"

Ill make this short: i have a MSSQL 7.0 and you little trick worked like a charm, and im VERY happy again, so thanks, you are a life saver (the real problem is, that our backkup guys didnt setup any thing for this particular database - so, for a while there, i was prety screwed)

Kind regards
Daniel L

 
At Friday, March 10, 2006 7:49:00 AM, b1ffa said...

just used these instructions to solve a big problem here :)

agent had stopped for no aparant reason so we didn't have any backups for 3 months. of course we only noticed this after one of our customers requested one of said backups.

anyway we managed to get the MDF (but not the LDF) from the tape backups and this procedure at least allowed me to extract the data.

this should clearly be made into an msdn article

 
At Friday, May 05, 2006 11:14:00 AM, Vishnu said...

Heyyyy Buddy,

You saved my job !!!!!!!!!!!!!

I got 100% of my data back following steps 8-10.....

Thanks a lot, keep up your good service.

Vishnu

 
At Monday, May 08, 2006 5:41:00 PM, Travis Reeder said...

It'a amazing the amount of feedback I've received for this posting and the amount of traffic this particular post gets. But in response to everyone, I'm always happy to help and I'm glad this article has helped so many people. Cheers and good luck!

 
At Tuesday, May 23, 2006 5:29:00 PM, Travis Reeder said...

Another email:

Dear Mr.Travis,
I've read your article in http://www.spaceprogram.com/knowledge/2002/06/recovering-from-deleted-log-file-on_12.html. Just thank you very much for you,Sir!!! standing applause for U!!!!!!
All step worked fine and fruitful.

best regards,
F

 
At Tuesday, June 06, 2006 7:09:00 PM, sburneson said...

Travis,

First off thank you for all the information that you have posted. However I am having problems with a MDF and log file. I can't seem to get them to import, or recover into a new install of SQL 2005. Your help would be oh so greatly appericated.

 
At Sunday, July 02, 2006 2:42:00 AM, laseta said...

Thank You, gracias.

I had spent 3 days looking for a solution. End of month and no data to invoice our clients.

Your solution works. And is as simple as it seems.

Thanks again.

 
At Friday, August 18, 2006 10:43:00 AM, Faye said...

Hi,
This article is verrrrrry helpful. Thanks a lot!
But I got errors when importing data from bad db to the new one:

Error = [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot insert the value NULL into column 'GUID', table ' mydb.owner.mytable'; column does not allow nulls. INSERT fails.
SQLState = 01000, NativeError = 3621.

I have set GUID as NOT NULL unique identifier.

Can anyone give me any hlep on this?
Many thanks again,

Faye

 
At Friday, August 18, 2006 12:55:00 PM, Travis Reeder said...

Faye: Either set the column to allow nulls or turn on auto-increment identity for that column.

 
At Wednesday, October 18, 2006 10:17:00 PM, Bamboo Bends said...

Thanks for the blog, saved my ass!

Here's my addition to your site for the case when a database gets crippled by a raid failure.

How to restore an SQL database lost on a raid drive or NT crash with no viable backup.

I've borrowed parts of this from the blog:

http://www.spaceprogram.com/knowledge/2002/06/recovering-from-deleted-log-file-on_12.html
(this page is really about recreating a lost ldf file...but has useful info to this task)

This article assumes two things:

You have the data file "recovered_database.mdf" and the log file "recovered_database.ldf"

Copy the files off the damaged drive using your favorite disk restore utility,
you do not need the master databasefiles to do this.

In SQL SERVER ENTERPRISE MANAGER:

1.) Create a new database with the name you choose eg "newdatabase"

2.) Open the SQL Query tool and enter:

EXEC sp_detach_db @dbname = N'newdatabase'

3.) Shut down MS SQL.

4.) Rename the "newdatabase.mdf" and "newdatabase.ldf" files to something else.

5.) Rename your "recovered_database.mdf" and recovered_database.ldf to
"newdatabase.mdf" and "newdatabase.ldf"

6.) Restart SQL server.

7.) Right click on the "database" root node in Enterprise manager and open properties.

8.) Under the Server Settings tab, check on "Allow modifications to be made directly to the system

catalogs".

9.) click ok

10.) Open the SQL Query tool and enter:

EXEC sp_attach_db @dbname = N'newdatabase',
@filename1 = 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\newdatabase.mdf',
@filename2 = 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\newdatabase.ldf'

This will reattach the database files to the SQL server.

11.) Now go to the master database and open the sysdatabases table.

12.) Find the suspected database in here and modify the status column,
setting it to: 32768.

This will put it into emergency mode.

13.) Stop then start sql server

14.) At this stage you've got a database in emergency mode.

15.) Create another databse with Enterprise manager tool.

16.) Using the "Export" option, export the database in emergency state to the just created
database.

17.) The 2nd newly created database will now have a working database (but no stored procedures).

18.) Create a valid backup of the database while you got it in a pristine state.

19.) YOu can detach the emergency state database, your are through with it.

20.) Right click on the "database" root node in Enterprise manager and open properties.

21.) Under the Server Settings tab, UNCHECK on "Allow modifications to be made directly to the

system catalogs".

22.) click ok

23.) You've got SQL!

 
At Monday, February 05, 2007 5:14:00 PM, Wayne said...

I'm running SQL 2000 server on windows 2000 server sp4. I tried the steps very religiously, both starting from 9 and starting from one and I am unable to replicate the successful restoration of the MDF file.

I think the reason is that the original database got lost trying to get it to an emergency state by another colleague. Anyway, what I tried to do was create a new database stop the server, rename the MDF I want to restore, start the server back up doing the steps in your guide. Except I add one step before detaching the database, that's creating a new database.

All I have is the MDF and not the defunct database and it does not seem to work with this. If anyone has a solution to this that would be great!!!

 
At Monday, February 26, 2007 11:31:00 AM, Travis Reeder said...

Just got this email:

Hi,


Just a quick email to say thanks for a brilliantly written article....

I scoured the net for days trying to recover a db which had corrupt backups and a corrupt .mdf

All I ever got was a suspect db which gave me torn page errors what ever I tried.

With a corrupt backup and a 40 Gb mdf file that I couldn't use I was close to tears!


Your procedure worked a treat... I've gone over the data and can't see a thing wrong with it...

I'm amazed that the MS people I spoke to just said tough, it's dead, and no where else on the net did I find an answer that worked.


A huge thanks to you for this article....


All the best in everything you do!


Mike B

 
At Wednesday, April 11, 2007 6:22:00 AM, Jue said...

Hi,

I tried all the steps except step 10, but I got DTS Import/Export Wizard Error: Connection failure.

Can anyone help?

Thanks,

Jue

 

Post a Comment

Links to this post:

Create a Link

<< Home