Disk Crash Recover - Won't Recover my SQL Database

My client had a hard disk crash, was running SQL 7.0. The disk engineers were
able to recover the MDF and NDF for a particular database, and I was trying
to attach the MDF back to our new server (SQL 2000). However, because the LDF
transaction log is missing, it is refusing to do so. We were using a "simple"
log model, so I'm not sure if the transaction log even had anything to useful.
I've tried "fooling" SQL server, like copying a good LDF file of a similary
named database, but it knows it's not part of the set and wont recover it.
Also, barring the inability to restore it, is there a tool to break apart a
big MDF file and get to the underlying tables that make it up, so at least
perhaps I can recover some of the data in some of the tables?
Thanks,
Bill Rosman
Chicago,IL
Have you tried sp_attach_single_file_db?
Paul Randal
Lead Program Manager, Microsoft SQL Server Storage Engine
http://blogs.msdn.com/sqlserverstorageengine/default.aspx
This posting is provided "AS IS" with no warranties, and confers no rights.
"Rosman Computing" <RosmanComputing@.discussions.microsoft.com> wrote in
message news:6049E918-795A-47A5-9716-AF3A627E313C@.microsoft.com...
> My client had a hard disk crash, was running SQL 7.0. The disk engineers
> were
> able to recover the MDF and NDF for a particular database, and I was
> trying
> to attach the MDF back to our new server (SQL 2000). However, because the
> LDF
> transaction log is missing, it is refusing to do so. We were using a
> "simple"
> log model, so I'm not sure if the transaction log even had anything to
> useful.
> I've tried "fooling" SQL server, like copying a good LDF file of a
> similary
> named database, but it knows it's not part of the set and wont recover it.
> Also, barring the inability to restore it, is there a tool to break apart
> a
> big MDF file and get to the underlying tables that make it up, so at least
> perhaps I can recover some of the data in some of the tables?
> Thanks,
> Bill Rosman
> Chicago,IL
|||Yes I have tried sp_attach_single_file, but it still keeps on looking for the
LDF transaction log file.
bill r.
"Paul S Randal [MS]" wrote:

> Have you tried sp_attach_single_file_db?
> --
> Paul Randal
> Lead Program Manager, Microsoft SQL Server Storage Engine
> http://blogs.msdn.com/sqlserverstorageengine/default.aspx
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Rosman Computing" <RosmanComputing@.discussions.microsoft.com> wrote in
> message news:6049E918-795A-47A5-9716-AF3A627E313C@.microsoft.com...
>
>
|||try using sp_attach_db, attaching .MDF and .NDF files only, no need to
attach .LDF file, it will create a new one.
"Rosman Computing" wrote:
[vbcol=seagreen]
> Yes I have tried sp_attach_single_file, but it still keeps on looking for the
> LDF transaction log file.
> bill r.
> "Paul S Randal [MS]" wrote:
|||Well, if you know the database was shutdown cleanly (e.g. by detaching it
while SQL Server is running) then the log file won't be needed as there's
nothing to recover.
Paul Randal
Lead Program Manager, Microsoft SQL Server Storage Engine
http://blogs.msdn.com/sqlserverstorageengine/default.aspx
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:e3gxb3pHHHA.1912@.TK2MSFTNGP03.phx.gbl...
> Whether or not a log file is needed when you attach (or similar) a
> database depends on whether there is recovery work to do in the database.
> Every time a database starts, it will see whether it has to perform
> recovery work. Recovery work include REDO and UNDO of log records. This it
> has to do because transactions might have been in flight when the database
> was shut down. If SQL Server determines that there is recovery work to be
> done, it *need* the log file.
> SQL Server will not allow you to use an inconsistent database (as in the
> case of missing log file and it need to do recovery work).
> I.e., you never know whether SQL Server can create the log file - so you
> should *never* rely on this. (Paul - I welcome elaborations and/or
> corrections to this statement... :-). )
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Celal" <Celal@.discussions.microsoft.com> wrote in message
> news:EF5EC77E-2AFA-42BA-8CEE-A5242D4AD0AF@.microsoft.com...
>
|||How would you check the bit in the file header - there's no documented way
to do so :-) and you'd have to have the database attached or know the file
header row structure.
Paul Randal
Lead Program Manager, Microsoft SQL Server Storage Engine
http://blogs.msdn.com/sqlserverstorageengine/default.aspx
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eaL4mWuHHHA.1264@.TK2MSFTNGP06.phx.gbl...
> Ahh, I tend to forget about the detach/offline cases. I guess my sceptism
> about these things isn't as much technical or mistrust, but more from
> these newsgroups. All the posts where SQL Server cannot create the log
> file. "I *did* detach the database first". Perhaps the simple truth is:
> a) The poster (not in this thread, I should add), claims that detach was
> performed even though it wasn't performed. ...In some vain hope that
> claiming that fact would somehow change things.
> b) I'm polluted by posts where log files cannot be created, and I just
> don't keep track of which cases detach (or offline) actually happened.
> I wish there could be some type of "FK"/link in NTFS so SQL Server could
> enforce that we cannot delete log files unless it was shutdown cleanly
> (even when SQL Server is stopped). Also, there would be nice if we could
> investigate this bit(?) in the mdf file header(?).
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
> news:eM0AAPuHHHA.1240@.TK2MSFTNGP03.phx.gbl...
>