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:
- You're log file got too big so you decided to shutdown SQL Server,
then delete the log file. - 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.
UPDATE: JAN. 6, 2003 BELOW
- Backup the data (.mdf) file! Just in case. We take no responsibility
for anything that happens following this procedure. - EXEC sp_detach_db 'dbname' -- this will detach the database from
the server - Restart SQL Server
The database may still be seen in enterprise manager, but just ignore
it. - 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. - Stop SQL Server.
- Rename the new data file that was created to something else (ex: add.bak
to the end) - 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) - Start SQL Server
Now the db will still be suspect but you now have a log file. - Switch to emergency mode on the database. You do this by doing the
following:
- Right click on the database root node in Enterprise manager and
bring up the properties. - Under the Server Settings tab, check of "Allow modifications
to be made directly to the system catalogs". - click ok
- Now go to the master database and open the sysdatabases
table. - Find the suspected database in here and modify the status column,
setting it to: 32768. This will put it into emergency mode. - stop then start sql server
- Right click on the database root node in Enterprise manager and
- 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.
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.


23 Comments:
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!
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
Got this one a while ago: 9/29/2004
FYI, I skipped step1-8 and it worked.
THANK YOU SO MUCH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
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..
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...
Thank a ton buddy. I was stuck with a similar issue and your solution solved the issue in one go. Thanks again.
Thank a ton buddy. I was stuck with a similar issue and your solution solved the issue in one go. Thanks again.
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
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
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
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
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
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
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!
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
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.
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.
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
Faye: Either set the column to allow nulls or turn on auto-increment identity for that column.
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!
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!!!
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
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