0

I've got an MDF and LDF file from a dead server that I'm trying to attach to another instance of SQL Server. However running the following create database statement

USE [master]
GO
CREATE DATABASE [DBName] ON 
( FILENAME = N'C:\tmp\DBName.mdf' ),
( FILENAME = N'C:\tmp\DBName_log.ldf' )
 FOR ATTACH
GO

Generates this error.

Msg 1813, Level 16, State 2, Line 1
Could not open new database 'DBName'. CREATE DATABASE is aborted.
Msg 5125, Level 24, State 2, Line 1
File 'C:\tmp\DBName.mdf' appears to have been truncated by the operating system.  Expected size is 675840 KB but actual size is 47160 KB.

From reading the MSDN entry I cant see any options on the create database statement that would allow me to ignore this. Is there any other way to force a restoration ignoring the truncation to retrieve some of the data or is the mdf beyond recovery?

Failing that are there any utilities that will allow me to read the contents of the LDF File?

Robb
  • 103
  • 1
  • 3
  • 2
    You're SOL. There is no way to guarantee any data in the file if there's less than 10% available. –  Nov 04 '10 at 16:45
  • Pretty exactly. Replace database with book and you get the idea. – TomTom Nov 04 '10 at 20:21
  • I had a feeling that would be the case, also order of magnitude fail on my part as somehow I read 67MB vs 47MB and thought I had 70% of the data available. Had I realised at the time it was only 7% I'd have already written it off. – Robb Nov 05 '10 at 09:21

1 Answers1

1

You can create an empty database with the same name and data file names, turn off the SQL service and replace the files with the files from the dead server. Once you bring the SQL service back online it will try to mount the files but more than likely it will come up as suspect and not be readable.

Jason Cumberland
  • 1,579
  • 10
  • 13
  • Thanks for this, gave it a shot and as you expected it came back up as suspect. Looks like this database is beyond recovery. – Robb Nov 05 '10 at 09:40
  • That's too bad, it was worth a shot anyway. – Jason Cumberland Nov 05 '10 at 14:37
  • @Robb this is to be expected when you replace the datafile. The checksum that SQL is expecting is not the same. You can put the db in emergency mode and run checkdb against it but it is a last resort. Read more on Paul Randal's blog here http://www.sqlskills.com/BLOGS/PAUL/post/CHECKDB-From-Every-Angle-EMERGENCY-mode-repair-the-very-very-last-resort.aspx – jgardner04 Nov 10 '10 at 19:59