March 2, 2010 at 9:11 pm
Comments posted to this topic are about the item Fixing DBCC CHECKDB Msg 8992 Errors
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
March 3, 2010 at 7:41 am
March 3, 2010 at 7:43 am
Hey Wayne,
Great article, I was wondering what the resolution to the problem you guys encountered was. I've really enjoyed reading Paul's blog as well he has a lot of great info.
Twitter: @SQLBalls
Blog: http://www.SQLBalls.com
Channel: https://www.youtube.com/@Tales-from-the-Field
March 3, 2010 at 8:15 am
Great Article Wayne! Thanks!
"Then, verify your backup – until you do so, you don’t know if it’s good or not. In case you manage to really mess up the database, you can restore from this backup and start over (or, preferably, proceed with copying the data to a new database)."
This is a great point. Normally when I work with corruption, If possible, I'll restore the database to a test server and go through all the troubleshooting there. If I mess up I've only destroyed a copy of the database and not the production database. Sometimes I'll go through corrective steps 2 or 3 times and document it before I fix the live database.
---------------------------------------------------------------------
Use Full Links:
KB Article from Microsoft on how to ask a question on a Forum
March 3, 2010 at 9:36 am
tstaker (3/3/2010)
Great Article Wayne! Thanks!"Then, verify your backup – until you do so, you don’t know if it’s good or not. In case you manage to really mess up the database, you can restore from this backup and start over (or, preferably, proceed with copying the data to a new database)."
This is a great point. Normally when I work with corruption, If possible, I'll restore the database to a test server and go through all the troubleshooting there. If I mess up I've only destroyed a copy of the database and not the production database. Sometimes I'll go through corrective steps 2 or 3 times and document it before I fix the live database.
Now that is a great idea! Granted that you can't always do this for all types of corruption, but for what this article is about that would definitely be a smarter way to do it.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
March 3, 2010 at 10:22 am
Great article! Just wanted to add that in addition to (sometimes in lieu of) taking a backup of the database before "experimenting", I often shut down SQL and make a physical filecopy of the MDF/NDF/LDF files. If something goes wrong, just move the copied files back overtop of the originals and you're back in business.
Yet another reason to make sure you back up everything *before* upgrading SQL -- even for a service pack install.
March 3, 2010 at 12:51 pm
Nice article Wayne. I've told you that already - but now it is posted with the article too 😀
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
March 3, 2010 at 2:29 pm
Tom, Brad, "tstaker", Randy and Jason: I'm glad you'll liked the article... and I hope you never need to reference it!
@jason: plus, you get a point for doing so. 😉
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
October 31, 2013 at 1:54 pm
Thanks for posting this. This came really handy to address an issue with a vendor DB.
Keep you the good work.
Thanks,
Ram
October 31, 2013 at 8:29 pm
Glad it helped you out Ram.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply