Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
Shurikane
Starting Member
3 Posts |
Posted - 2009-10-29 : 12:31:11
|
I'm performing disaster recovery on a database. Somewhere during the day, the server experienced a hardware failure and a data recovery team salvaged the data and sent it to me. I now have an SQL Sever 2005 MDF database file. The last backup is unfortunately so old that recovering the DB is seen as a wanted outcome, come hell or high water.However, when I attempt to attach the file on my machine, I get the following error:Error: 824, Severity: 24, State: 2.SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:155564; actual 0:0). It occurred during a read of page (1:155564) in database ID 14 at offset 0x0000004bf58000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\myDatabase.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.Said error log has given me no further information - only a repeat of the message above (great, an error log telling me to check itself.) Google led me to a bunch of old forum threads with no answer to them.Now, I cannot run DBCC CHECKDB since the database can't even be attached, and as far as I know, I can't run this command on just a filename. Flushing the log file did not help either. At this point, I am not certain of the options I've got.Can the database even be recovered at this point? |
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2009-10-29 : 14:03:55
|
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=78376 |
|
|
GilaMonster
Master Smack Fu Yak Hacker
4507 Posts |
Posted - 2009-10-29 : 15:53:34
|
Yes, but you'll have to hack it into the server. The procedure's half-detailed here:http://sqlinthewild.co.za/index.php/2009/06/09/deleting-the-transaction-log/If you have or can get the ldf file, use that as well, it'll make things easier.Once you get the DB 'attached', see if it'll come online. If so, run the following and post the full output. If not, set the DB into emergency mode then run the command below and post all output.DBCC CHECKDB (<Database Name>) WITH NO_INFOMSGS, ALL_ERRORMSGS --Gail ShawSQL Server MVP |
|
|
Shurikane
Starting Member
3 Posts |
Posted - 2009-10-29 : 16:28:51
|
After shoving the DB into place and trying all the tricks Google & Co. brought us, all attempts at DBCC CHECKDB commands (plus variants) resulted in the exact same error described above, eventually culminating in SQL Server itself declaring the DB to be broken beyond repair and that restoring from a backup is the only possible option. Whatever happened to it followed Murphy's Law with unprecedented bravado.After some discussion, we agreed to simply bite the bullet for this time, re-enter the most crucial data the old-fashioned way, and review our backup strategies. |
|
|
GilaMonster
Master Smack Fu Yak Hacker
4507 Posts |
Posted - 2009-10-30 : 04:03:20
|
quote: Originally posted by Shurikane ... and review our backup strategies.
Good idea.--Gail ShawSQL Server MVP |
|
|
Shurikane
Starting Member
3 Posts |
Posted - 2009-10-30 : 09:43:28
|
Indeed.Well, as they say: "You do that sort of mistake once, you look like a complete idiot... and you never do it again." |
|
|
|
|
|
|
|