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

34 comments:

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!

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

Travis Reeder said...

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

FYI, I skipped step1-8 and it worked.

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

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

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

Anil said...

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

Anil said...

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

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

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

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

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

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

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

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!

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

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.

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.

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

Travis Reeder said...

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

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!

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!!!

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

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

Travis R said...

Another kudo via email:

hai

REally your tips worked fine I have recovered ny db from an deleted log file Great work keep on going new tips

--
Best Regards,
MOHAMMED R M

Travis Reeder said...

Got this email a couple days ago:

Fantastic guide, saved around 40GB of SQL databases!!!!!

Thank you :)

Rich K
I.C.T. Manager
http://www.encams.org

RobertRowe said...

Thank you so much for this article. It saved one of my customers that had a bad hard drive.

Robert Rowe

kunal said...

Thanks a lot...It saved my time to recover data.
My log file had grown to 16 gb so i created a file with same name and overwritten the existing one...whihc took me in syustpect mode...
I used steps 9 and 10 and created a dummy log file whihc i renamed and copied to existing log file and it worked after reverting the emrgency mode.
Thanks again

damonl73 said...

Brilliant. This worked perfectly. I was able to do this using only one instance of SQL Server 2000, too.

Jimmy said...

Jue,

I have the same problem. Were you able to find a solution? Please post.

thanks!
jimmy

Jimmy said...

DTS Import/Export Wizard Error: Connection failure.

Does anyone know how to resolve this or point me to a fix?

thanks!
jimmy

aung said...

I run a delete statement on a table.
All the records are deleted. My database and log files are still being there. This technique can also be used to recover such records?

P.S: I've to travel to this client if I found a solution to recover their data. That's why I ask such question. If not I'll test it to see it can help or not.

Thanks.

aung said...

Thank you anyway for writing this.

MikeK said...

I have the same problem as Jue and Jimmy...

Error Source: Microsoft OLE DB Provider for SQL Server
Error Description: Connection failure

when trying to use DTS Import/
Export Wizard

Alex said...

I heard about not bad application-sql mdf recovery,repair data from corrupted databases in the MS SQL Server format (files with the *.mdf extension), can process huge databases, their file size can reach 16 TB, supports data extraction via the local area network, you can save recovered data as SQL scripts, it is also possible to split data into files of any size, can save extracted information directly to the SQL server. It allow to recovery SQL Server faster.