August 12, 2007 at 10:27 am
Can anyone recommend any SQL SERVER Recovery Tools? Server crashed with bad drive, no external SQL Server backups and the dump on the databases was made after the Drive went bad. There are hundreds of errors when doing a DBCC CHECKDB, we have done a REPAIR_FAST and REPAIR_REBUILD and a REPAIR_ALLOW_DATA_LOSS and we still have errors. Just as a disclaimer, I was not the person in charge of the server backups. Any help would be greatly appreciated!!!!!
August 13, 2007 at 12:23 pm
Bad Disk and no backups ?!?!?!?
There are only two SPs I know of that can help in that specific situation:
exec sp_update_resume
exec sp_distribute_resume
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
August 13, 2007 at 1:04 pm
Well thank goodness, I am not responsible for either the server or the database. I am just trying to help out a co-worker and we are actually getting it recovered with the vendors help. I would still like to find a good SQL Server Recovery Tool that someone has used. I found several on the internet but I would like to know how they have worked for others.
August 14, 2007 at 5:43 am
The leader in recovery is SonaSoft.
Disclaimer- Please note that neither myself nor the company I work for is affiliated with SonaSoft. Just trying to point to the right direction.
August 14, 2007 at 5:50 am
Thank You!
August 14, 2007 at 8:55 am
Not sure Sonasoft will help with bad disks. If the disks are bad, you need a recovery service for the disks.
If you can read the disks somewhat, call Microsoft. PSS is the best recovery team you can ask for.
August 14, 2007 at 9:22 am
Thanks, we got the disk replaced and talked with Microsoft. It was RAID 5 but there was something else going on that caused the DB to get corrupt.
They had us continue to run DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS until there were no errors showing. I think it was run about 20 - 30 times. We have the system back up now and we trying to determine what data is lost. Not the best situation to be in but still better than losing the whole DB. The Vendor is looking at the DB to see if they can help us.
August 15, 2007 at 2:08 pm
ouch; i had a similar issue where a controller card went bad and was writing bad data for hours before the db was too corrupted to use, but I had regular backups to step back into;
lost a days worth of processing, because the transaction logs and backups were corrupted due to the hardware, but not insurmountable for our applicaiton.
Lowell
August 16, 2007 at 4:20 am
Please try to be serious about the data you have. Ask the DBA to have solid backup plan. I have seen so many issues where the DBAs are not serious about the backup plan which is the primary job of a DBA.
Please follow the steps the PSS (MS) have asked to do and regulary check the hardware for any disk related issues.
Minaz.
"More Green More Oxygen !! Plant a tree today"
August 16, 2007 at 6:08 am
Please do not blame the DBA!!!! It was not the DBA's fault it was the System Administrator that did not backup the server. The database was being backed up to the server. It was the server that was not being backed up and this has been corrected.
August 16, 2007 at 6:48 am
Sorry to say, I disagree. It is the DBA's job to make sure that what happened does not. I suspect that the DBA knew the situation, but chose to take the risk. Also, who in their right mind backs up a DB to the same server as their database? That's just passing the buck... "It's not my job"
August 16, 2007 at 8:14 am
Actually in SQL Server, a system backup of the host Windows system wouldn't get the databases. The files would be locked, so without a database backup plan by the DBA, things would still be gone.
I agree with Bob, it's the DBA's responsibility to verify with the sysadmin the data is being backed up. And more importantly, he should have done at least one restore to be sure the tape system could bring the file back.
I'm surprised you ran "allow data loss". Paul Randal, Storage Engine Lead for SS2K5 and SS2K spoke at TechEd. He said don't run it. Ever, ever, ever, ever.
August 17, 2007 at 10:41 am
I don't trust anyone with my backups. Period. Full stop. They were using a backup agent when I arrived (they had not had a DBA prior to me starting here). There was plenty of available disk space, so I told them to stop using the agent (I don't trust 'em). I back up frequently throughout the day to the server's disk, then I repeat the backup to our SNAP server. That is theoretically backed up twice an hour to our off-site location, but that is then beyond my responsibility. They back up the servers nightly.
(not using the agent anymore also saves us $1000 a year for the license)
I have reasonable confidence in my SNAP backups through testing, and the only thing the off-site backups would be good for is if our data center goes up in flames.
Yes, the system admin totally dropped the ball by not backing up the server, but the DBA should have been hounding him to make sure the server got backed up. I hounded my network guys because their backup procedure didn't reset the archive bit, and that was the easiest way for me to see that the data was being backed up, they eventually changed it so that the bit did clear, but I think it's not clearing again. I should check on that.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
September 12, 2007 at 6:33 pm
"I'm surprised you ran "allow data loss". Paul Randal, Storage Engine Lead for SS2K5 and SS2K spoke at TechEd. He said don't run it. Ever, ever, ever, ever."
Not quite - there is a case when you *have* to run it - no backups and no other way to fix up the damage to the database.
Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005
September 12, 2007 at 6:47 pm
Here's my take:
no backups are a sign of an in-experienced DBA, or a developer who happens to have to wear the DBA hat. Unfortunately, he's been lucky up till now hiding that in-experience. Getting bitten by that mistake makes you take the time to read BOL and find out how simple it is to do a backup.
anyone with any experience would have a backup plan in place, as well as local bacups on his dev machine from testing restores.
Lowell
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply