January 5, 2010 at 8:26 am
pankaj.baluni (1/5/2010)
Do you have old .mdf and .ldf files(not of the day when DB got corrupted)? you might have taken file backup on some storage.... so get it and save it some where on this server.If yes, just delete the current .mdf and .ldf as the DB is any which ways useless now.
attach the old .mdf and .ldf files and see if that works.... (as the chances are very less).... if not then I'm sorry to say that the DB is gone now.....
I wouldn't be so quick to delete the .mdf file, there are different types of corruption and it can be possbile to recover the data and the amount of data lost depends on the corruption.
for example a corrupt NC index would not be as big issues as a corrupt Clustered index.
January 6, 2010 at 11:25 am
I am sorry to hear of your data loss. It is standard operating procedure at my company to always take a backup of any database, live or test, before making any changes; and to store the backup to a different server on the network. This is in addition to any regularly scheduled nightly backups. Then, every other weekend, we select a handful of databases in our backup sets to restore to a test server and verify our backups are good. This is all because we lost data several years back. Nothing teaches you paranoia more than data loss!
Jack
January 7, 2010 at 8:03 am
There is a solution outside of SQLServer if the normal database backup method fails. Is there a backup performed of the actual files on the server - e.g C:\ drive contents etc using e.g. Veritas or similar? Or check if there are any Shadow copies of the C:\ drive (right click on C:\ drive, properties, Shadow Copies. If so you can recover to the time of the last back up of the files. If Shadow Copy is not enabled - then enable it for the future - it is a life saver.
January 8, 2010 at 3:38 pm
Getting your nuts busted a bit cause many of us have been there...not me of course 😉
Doesn't Red-Gate have some tools for recovery via the log file? I used them once testing out the suite and was able to recover transactional data. I don't know much, as a programmer, about log files except they fill up the hard drive and make my head hurt, but if it is complete would that work?
They have trials...no pun intended ...
January 8, 2010 at 4:36 pm
bhoward 86472 (1/8/2010)
Getting your nuts busted a bit cause many of us have been there...not me of course 😉Doesn't Red-Gate have some tools for recovery via the log file? I used them once testing out the suite and was able to recover transactional data. I don't know much, as a programmer, about log files except they fill up the hard drive and make my head hurt, but if it is complete would that work?
They have trials...no pun intended ...
These tools only work *if you have a backup* of the database in the first place. Without a backup, you cannot scan the transaction log. If your database is in simple recovery - there might not be anything in the transaction log for you to recover from.
Note: if you have never backed up your database, the transaction log is in a psuedo-simple recovery model and not saved anyways.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
January 8, 2010 at 5:04 pm
bhoward 86472 (1/8/2010)
--------------------------------------------------------------------------------
Getting your nuts busted a bit cause many of us have been there...not me of course
Doesn't Red-Gate have some tools for recovery via the log file? I used them once testing out the suite and was able to recover transactional data. I don't know much, as a programmer, about log files except they fill up the hard drive and make my head hurt, but if it is complete would that work?
They have trials...no pun intended ...
These tools only work *if you have a backup* of the database in the first place. Without a backup, you cannot scan the transaction log. If your database is in simple recovery - there might not be anything in the transaction log for you to recover from.
Note: if you have never backed up your database, the transaction log is in a psuedo-simple recovery model and not saved anyways
I agree. A tool like this will only be able to recover the data from the log file that was written to it. So if you do not have a good mdf file and there were records that were not updated and hence have an entry in the log file, you will not be able to get that data back.
Provided that there is no SQL backup, I think your next best alternative is the one that was provided earlier and see if there is a file system backup or shadow copies on the directories where the mdf/ldf files are stored. If you are lucky there may be an old copy out there. There will be data loss, but at least there would be a consistent database that could be attached.
Joie Andrew
"Since 1982"
January 9, 2010 at 2:53 am
Besides, the redgate tool is SQL 2000 only.
There's a chance that this problem is repairable without any data loss at all. However, seeing as the OP has not bothered to post a checkDB output, it's impossible to say what is wrong and what should be done.
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
June 17, 2010 at 9:06 am
Gila,
Was wondering if you would be able to help with a similar problem with a 2000 db in my post from today:
http://www.sqlservercentral.com/Forums/Topic938934-5-1.aspx
I see the OP never responded with results from CHECKDB but I am interested in your comments in regards to the database still being able to be recovered (with possible data loss). Thanks.
Dave Coats
October 29, 2011 at 11:46 pm
hi
is the database have a (suspect)
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply