InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 21 May 2013 12:41:47 GMT20http://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxAs you write there no backup. Then there is no tips trick for repair SQL database manually in my knowledge. In corruption stage, you need a third party tool like [url=http://www.mssqlserverrecovery.net/]MDF file repair tool[/url]. As a good suggest, please don’t use any kind of tips on MDF file otherwise might you may loss data for ever because may the MDF overwrite or disturbed with that trick. If you really think your data is important for you then use MDB file repair tool.Thu, 10 May 2012 23:48:32 GMTpostforum7http://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxhi is the database have a (suspect)Sat, 29 Oct 2011 23:46:43 GMTmansour4cshttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxGila,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.aspxI 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.Thu, 17 Jun 2010 09:06:35 GMTDave Coatshttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxBesides, 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.Sat, 09 Jan 2010 02:53:54 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspx[quote]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?www.red-gate.comThey 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 [/quote]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.Fri, 08 Jan 2010 17:04:35 GMTJoie Andrewhttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspx[quote][b]bhoward 86472 (1/8/2010)[/b][hr]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?www.red-gate.comThey have trials...no pun intended ...[/quote]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.Fri, 08 Jan 2010 16:36:56 GMTJeffrey Williams 3188http://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxGetting 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?www.red-gate.comThey have trials...no pun intended ...Fri, 08 Jan 2010 15:38:01 GMTbhoward 86472http://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxThere 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.Thu, 07 Jan 2010 08:03:46 GMTsparky-407434http://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxI 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!JackWed, 06 Jan 2010 11:25:23 GMTjmartinez-847815http://www.sqlservercentral.com/Forums/Topic841472-146-1.aspx[quote][b]pankaj.baluni (1/5/2010)[/b][hr]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.....[/quote]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.Tue, 05 Jan 2010 08:26:15 GMTsteveb. http://www.sqlservercentral.com/Forums/Topic841472-146-1.aspx[quote][b]pankaj.baluni (1/5/2010)[/b][hr]if not then I'm sorry to say that the DB is gone now.....[/quote]That is not necessarily true. There are ways to repair a SQL database with varying amounts of data loss. Until they have been tried you cannot say that the DB is gone. Recommending to delete the mdf without being 1000% sure that it is completely irreparable is very poor advice.I'm still waiting for the output of CheckDB to see exactly what's wrong. Sudhakara, can you run the CheckDB statement I gave you above and post the results?Tue, 05 Jan 2010 08:02:43 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxDo 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.....Tue, 05 Jan 2010 07:35:21 GMTpankaj.balunihttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxAre your other databases backed up ?This might help show holes in your backup strategy:[url]http://www.mssqltips.com/tip.asp?tip=1601[/url]Tue, 05 Jan 2010 06:49:51 GMThomebrew01http://www.sqlservercentral.com/Forums/Topic841472-146-1.aspx[quote][b]Grant Fritchey (1/4/2010)[/b][hr][quote][b]sudhakara (1/4/2010)[/b][hr][quote][b]Jack Corbett (1/4/2010)[/b][hr]Sorry to say that you are basically screwed since you have no backups. Your only option is to run DBCC CHECKDB or CHECKTABLE with one of the repair options, probably REPAIR_ALLOW_DATA_LOSS which does exactly what you it says, it fixes the corruption, but you will most likely lose data. Check out [url=http://www.sqlskills.com/BLOGS/PAUL/]Paul Randal's blog[/url] and look at the CHECKDB and Corruption tags.[/quote] After attaching the user databases in the server, i will apply the some data patches and fixes application related, after completing this process only i will take the backup of the database.But unfortunately after completing this data patches and fixes database got corrupted. [/quote]Take a backup before, take a backup after, heck, depending on how extensive the number of changes you're performing, take a backup in the middle. If you're mucking with production data, it's difficult to be overly paranoid.[/quote]In agreement with Grant - It is better to be overly paranoid, than ill-prepared.Mon, 04 Jan 2010 17:57:28 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspx[quote]Those steps 'should not' corrupt the database.Can you post the output from running CHECKDB ?[/quote]It is hard to say since none of us know the entire situation involved, but first guess I would have to agree with this assessment. What errors does DBCC CHECKDB come back with?Mon, 04 Jan 2010 17:44:50 GMTJoie Andrewhttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspx[quote][b]sudhakara (1/4/2010)[/b][hr][quote][b]Jack Corbett (1/4/2010)[/b][hr]Sorry to say that you are basically screwed since you have no backups. Your only option is to run DBCC CHECKDB or CHECKTABLE with one of the repair options, probably REPAIR_ALLOW_DATA_LOSS which does exactly what you it says, it fixes the corruption, but you will most likely lose data. Check out [url=http://www.sqlskills.com/BLOGS/PAUL/]Paul Randal's blog[/url] and look at the CHECKDB and Corruption tags.[/quote] After attaching the user databases in the server, i will apply the some data patches and fixes application related, after completing this process only i will take the backup of the database.But unfortunately after completing this data patches and fixes database got corrupted. [/quote]Take a backup before, take a backup after, heck, depending on how extensive the number of changes you're performing, take a backup in the middle. If you're mucking with production data, it's difficult to be overly paranoid.Mon, 04 Jan 2010 08:58:46 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxThose steps 'should not' corrupt the database.Can you post the output from running CHECKDB ?Mon, 04 Jan 2010 08:52:02 GMTsteveb. http://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxAnd previous backups? You know, the ones you've been taking on a daily or weekly basis since you became responsible for this database?Mon, 04 Jan 2010 08:51:46 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspx[quote][b]Jack Corbett (1/4/2010)[/b][hr]Sorry to say that you are basically screwed since you have no backups. Your only option is to run DBCC CHECKDB or CHECKTABLE with one of the repair options, probably REPAIR_ALLOW_DATA_LOSS which does exactly what you it says, it fixes the corruption, but you will most likely lose data. Check out [url=http://www.sqlskills.com/BLOGS/PAUL/]Paul Randal's blog[/url] and look at the CHECKDB and Corruption tags.[/quote] After attaching the user databases in the server, i will apply the some data patches and fixes application related, after completing this process only i will take the backup of the database.But unfortunately after completing this data patches and fixes database got corrupted. Mon, 04 Jan 2010 08:45:38 GMTsudhakarahttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxWhy on earth is there no backup?Please run this and post the full and complete output.[code]DBCC CHECKDB (<Database Name>) WITH NO_INFOMSGS, ALL_ERRORMSGS[/code]Without a database backup, the database cannot be recovered from the log file alone. The log file does not necessarily contain the record of all changes made to the DB, especially if the DB is in simple recovery or there has never been a backup made.Mon, 04 Jan 2010 08:25:20 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxAnd I was actually questioned about why I would bother [url=http://www.sqlservercentral.com/articles/Editorial/69116/]posting today's editorial[/url].Why aren't you taking backups of the system?Mon, 04 Jan 2010 08:17:32 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxSorry to say that you are basically screwed since you have no backups. Your only option is to run DBCC CHECKDB or CHECKTABLE with one of the repair options, probably REPAIR_ALLOW_DATA_LOSS which does exactly what you it says, it fixes the corruption, but you will most likely lose data. Check out [url=http://www.sqlskills.com/BLOGS/PAUL/]Paul Randal's blog[/url] and look at the CHECKDB and Corruption tags.Mon, 04 Jan 2010 08:05:48 GMT Jack Corbetthttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspx[quote][b]tosscrosby-60625 (1/4/2010)[/b][hr]Restore from a vaild backup, provided you have one?[/quote]No .... i do not have back up of the database.Mon, 04 Jan 2010 08:05:46 GMTsudhakarahttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxRestore from a vaild backup, provided you have one?Mon, 04 Jan 2010 07:52:48 GMT tosscrosbyhttp://www.sqlservercentral.com/Forums/Topic841472-146-1.aspxHi Everybody, One of my sql server 2005 database file (mdf) has corrupted and do not have back up of the database. but there is no problem in log file it seems. Please let me know the steps how do to recover the data file(mdf) with data base log file without any third party tool. Thanks in Advance.Mon, 04 Jan 2010 07:46:14 GMTsudhakara