March 21, 2014 at 6:10 pm
Hello guru,
Recently our hard drive crash and it doesn't look like we can recover the data any longer.
Now we SQL server can't start, error message was missing .mdf and .ldf file. Tried searching manually, found master.mdf and tempdb.mdf, but the database .mdf is nowhere to be found.
The error message when loading SSMS :
******************************
TITLE: Microsoft SQL Server Management Studio
------------------------------
Failed to retrieve data for this request. (Microsoft.SqlServer.Management.Sdk.Sfc)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&LinkId=20476
------------------------------
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
------------------------------
Unable to open the physical file "D:\XYZ.mdf". Operating system error 2: "2(The system cannot find the file specified.)".
Database 'XYZ' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.
File activation failure. The physical file name "D:\XYZ_log.LDF" may be incorrect. (Microsoft SQL Server, Error: 5120)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.00.1600&EvtSrc=MSSQLServer&EvtID=5120&LinkId=20476
------------------------------
BUTTONS:
OK
------------------------------
******************************************
When ran DBCC CheckDB, the error message was :
*********************************
Msg 945, Level 14, State 2, Line 1
Database 'XYZ' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.
*********************************
The system has plenty of disk space and memory.
Is it possible to recreate the database .mdf and .ldf file?
Sorry for the long post, hopefully enough information.
Windows Server 2008 Standard
Windows SQL Server 2008
Any help is greatly appreciated.
Thanks,
Howard
March 22, 2014 at 8:17 am
Restore from backup.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 24, 2014 at 12:35 am
Make sure installation files of SQL Server are not corrupt. Also best way is to restore from previous backup as mention by Gila.
---------------------------------------------------
"Thare are only 10 types of people in the world:
Those who understand binary, and those who don't."
March 24, 2014 at 11:20 am
Hi All,
Thank you for the reply. The hard drive that crashed was actually the DATA drive.
And the backup is corrupted as well, plus it is a .bak file. It doesn't have .mdf and .ldf file.
Sorry, a total noob here.
Thanks,
Howard.
March 24, 2014 at 2:02 pm
How do you know the .bak is corrupt?
How recent is it?
And do you know what kind of recovery model the database was using?
March 24, 2014 at 2:30 pm
hwp (3/24/2014)
Sorry, a total noob here.
If the data is valuable, then I suggest you stop all efforts and get a local pro in there to help you. This is not the time for a "total noob" to learn by doing... it's time to learn by watching.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 24, 2014 at 3:06 pm
hwp (3/24/2014)
Thank you for the reply. The hard drive that crashed was actually the DATA drive.
If you've lost the data drive and you have no usable backups, you're pretty much out of luck. You can try sending the drive to a data recovery company, they're not cheap. Otherwise see if you have an old copy anywhere on a test or dev server.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 24, 2014 at 3:22 pm
Because before the drive failed, I have seen a couple of times that the bak file is only a couple of Kbyte while it should be around 200 MB. At that time I ran the backup manually then I could get a good backup.
So, no I don't know 100% that the backup it corrupted but since the data hard drive had gone bad and for the fact that it had backup problem before I think most likely the bak file is corrupted too.
Sorry I don't know about the recovery model.
Thanks,
Howard.
March 24, 2014 at 3:31 pm
I did find an old bak file, that was about half the size of the current bak.
So If possible I tried not to use the old bak file.
Thank you,
Howard.
March 24, 2014 at 3:33 pm
Try restore the backup you suspect is damaged. Worse case it won't restore, you're no worse off that way.
As for the old backup, if it's a choice between that and nothing, surely the old backup is the better option?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
March 24, 2014 at 3:43 pm
hwp (3/24/2014)
Because before the drive failed, I have seen a couple of times that the bak file is only a couple of Kbyte while it should be around 200 MB. At that time I ran the backup manually then I could get a good backup.So, no I don't know 100% that the backup it corrupted but since the data hard drive had gone bad and for the fact that it had backup problem before I think most likely the bak file is corrupted too.
Sorry I don't know about the recovery model.
Thanks,
Howard.
Your latest full sized .bak file might be as good as you can get.
Hopefully it was saved somewhere safe.
Like Gail and Jeff mentioned, you should get some qualified local help.
Especially if this was a real important database.
Part of that should include more planning for just such a disaster.
Lucky is it never happening.
Good is being able to handle it with little business impact.
March 25, 2014 at 6:26 am
As someone else has already stated if this data is valuable I would seriously consider bringing in a seasoned SQL Server pro to handle this. No offense intended but you do not have a clue, leave it to someone who can recover your database(s) for you. Also, have your contractor savior review the current backup and recovery plan and change it as needed.
March 25, 2014 at 6:47 am
Is this production server? Do not try things on prod and make scenario worst. Do all your restore and R&D on junkbox.
---------------------------------------------------
"Thare are only 10 types of people in the world:
Those who understand binary, and those who don't."
March 25, 2014 at 6:48 am
Grumpy DBA (3/25/2014)
As someone else has already stated if this data is valuable I would seriously consider bringing in a seasoned SQL Server pro to handle this. No offense intended but you do not have a clue, leave it to someone who can recover your database(s) for you. Also, have your contractor savior review the current backup and recovery plan and change it as needed.
Also hardware redundancy. We monitor things like disks, and use raid / SAN to minimize disruptions like you are experiencing.
It is hindsight, but had you (or someone else) dug in deeper at your first sign of trouble, you may have been able to avoid most of this.
Most servers have some kind of health monitoring for things like this.
March 26, 2014 at 2:06 pm
Thank you very much for all the recommendation and suggestion.
We are currently looking for expert help in recovering our database. If anyone has any suggestion or do provide service please PM me.
We are located in Los Angeles.
Thank you,
Howard.
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply