According to Paul Randal who wrote DBCC CHECKDB,
"you're dead in the water. The database cannot be opened at all without the
boot page. There is no way to repair this or work around it without a
backup."
Paul's Blog:
http://www.sqlskills.com/blogs/paul/...astResort.aspx
http://www.sqlskills.com/blogs/paul/...x#commentstart
Thanks Paul, now at least I can stop beating my head against bricks and just
move on.
The moral of the story...Practice what you preach and backup your databases.
Josh
"Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.co m> wrote in
message news:eqD5FdAvIHA.420@TK2MSFTNGP02.phx.gbl...
> Hmm, I thought that emergency mode would let you in to the database... Are
> 100% certain that you set the correct database? If so, I guess MS Support
> is the next stop (unless someone else has an idea...).
>
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
>
> "Joshua A. Booker" <josh@newsgroups.nospam> wrote in message
> news:%23qdx21$uIHA.3564@TK2MSFTNGP03.phx.gbl...
>> Tibor,
>>
>> I've done that allready and after I SET EMERGENCY
>> SELECT state_desc FROM sys.databases still returns RECOVERY_PENDING and
>> DBCC says please wait until after recovery is complete.
>>
>> Is there something else I can try?
>>
>> Thanks,
>>
>> Josh
>>
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.co m> wrote
>> in message news:%237uFGW9uIHA.2292@TK2MSFTNGP03.phx.gbl...
>>>> I'm willing to put up with what ever I can get.
>>>
>>> I see. So whatever you get is better than restoring from your old
>>> backup, and you will be able to work your way from there. OK.
>>>
>>> First, I encourage you to check out Kevin's ("TheSQLGuru") advice.
>>> I think you will be able to get into the database by creating a new
>>> database, stop your SQL server, delete this database's files and "slide
>>> in" your corrupt mdf file instead of your new database's mdf file. The
>>> database will be suspect (or similar) on startup, but you now set the
>>> database to emergency mode. Now all bets are off and you take full
>>> responsibility. :-)
>>>
>>> --
>>> Tibor Karaszi, SQL Server MVP
>>> http://www.karaszi.com/sqlserver/default.asp
>>> http://sqlblog.com/blogs/tibor_karaszi
>>>
>>>
>>> "Joshua A. Booker" <josh@newsgroups.nospam> wrote in message
>>> news:OVGL9C5uIHA.1316@TK2MSFTNGP06.phx.gbl...
>>>> I'm willing to put up with what ever I can get. Yes I would be happy
>>>> to export and inspect if someone can tell me how to get started in this
>>>> direction.
>>>>
>>>> Thanks,
>>>> Josh
>>>>
>>>> "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.co m>
>>>> wrote in message
>>>> news:BDF34D0F-65B9-4F7B-B8C7-D55DD94DFC78@microsoft.com...
>>>>> How much damage and inconsistent data are you willing to put up with,
>>>>> compared to restoring? Can you for instance work with close to zero
>>>>> trust of the data, export it to a new database and inspect that data
>>>>> for correctness? Those are the questions you have to ask yourself when
>>>>> you consider getting into a corrupt database compared to restoring
>>>>> from a clean backup.
>>>>>
>>>>> --
>>>>> Tibor Karaszi, SQL Server MVP
>>>>> http://www.karaszi.com/sqlserver/default.asp
>>>>> http://sqlblog.com/blogs/tibor_karaszi
>>>>>
>>>>>
>>>>> "Joshua A. Booker" <josh@newsgroups.nospam> wrote in message
>>>>> news:%23DPArV1uIHA.4876@TK2MSFTNGP02.phx.gbl...
>>>>>> My last backup was 10/2/2007. I know, I should practice what I
>>>>>> preach.
>>>>>>
>>>>>> I'm trying everything I can to fix this file. It's all I have to
>>>>>> work with.
>>>>>>
>>>>>> Is there anything else I can try? Documented or not I'll try it.
>>>>>> Please .
>>>>>>
>>>>>> Thanks,
>>>>>> Josh
>>>>>>
>>>>>> "Uri Dimant" <urid@iscar.co.il> wrote in message
>>>>>> news:u1j26Q1uIHA.1240@TK2MSFTNGP02.phx.gbl...
>>>>>>> Hi
>>>>>>> Do you have a last good backup?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "Joshua A. Booker" <josh@newsgroups.nospam> wrote in message
>>>>>>> news:%23VIabO1uIHA.4736@TK2MSFTNGP04.phx.gbl...
>>>>>>>> Hi There,
>>>>>>>>
>>>>>>>> I get the following error when I try to attach a database in SQL
>>>>>>>> 2005. In fact I can't even try to attach because I get this error
>>>>>>>> upon seleting the file bfore attaching in the UI. I understand the
>>>>>>>> torn page (1:9) is the database boot page. Is there any way to fix
>>>>>>>> this? Please don't club me over the head for not backing up...I'm
>>>>>>>> brused enough as is.
>>>>>>>>
>>>>>>>> Background: I had a corrupt system partion on the server so I had
>>>>>>>> to reinstall the OS. This file was on another partition which was
>>>>>>>> apparently ok. Safe to say SQL Server was not shut down properly.
>>>>>>>> The new server has a different name and domain than before. File
>>>>>>>> permissions don't appear to be an issue. SQL 2005 SP2 and updates.
>>>>>>>> Windows 2003 STD, PDC.
>>>>>>>>
>>>>>>>> Is there any way to run dbcc if the db cannot be attached? Any
>>>>>>>> other way of extracting the data from this file?
>>>>>>>>
>>>>>>>> TIA,
>>>>>>>>
>>>>>>>> Josh
>>>>>>>>
>>>>>>>> Msg 824, Level 24, State 2, Line 1
>>>>>>>>
>>>>>>>> SQL Server detected a logical consistency-based I/O error: torn
>>>>>>>> page (expected signature: 0xaaaaaaaa; actual signature:
>>>>>>>> 0x56aaaaaa). It occurred during a read of page (1:9) in database ID
>>>>>>>> 7 at offset 0x00000000012000 in file 'D:\Program Files\Microsoft
>>>>>>>> SQL Server\MSSQL.1\MSSQL\Data\ICS.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.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>