Recently we had a new customer contact from someone with a corrupt database. They were getting corruption error #824, which usually indicates there is some type of corruption in the database. Every time they ran a backup of the database there was an error #824 thrown into the SQL log and into the job failure message. When running CheckDB the database being backed up always came back clean.
After some quick investigation we found that the corruption was not in the database being backed up, but rather in some of the tables in MSDB that track the backup messages, and when the backup was run and SQL Server attempted to insert into these tables that is what was causing the message.
In this case we were fortunate it was a quick repair. We were able to truncate some of the backup history tables and the corruption went away. Of course prior to doing that we discussed if it was okay to lose the history of backups if that meant the corruption would go away. If it had been important to keep the data on backup history we could have taken more time to save it all off before attempting the repair.
Here is what the customer had to say after we did the repair.
We were having trouble with incorrect pageid errors only when running backup and restore operations on a certain file. I spent hours trying to resolve the issue to no avail. I ran across one of Steve’s blog posts in my research. His article emphatically stated to *NOT* do all the things I had just done. So I reached out to him to see if he could help. He responded quickly. Within minutes I had him on a remote session on the server and in minutes he completed what I was working hours on. Steve really knows his stuff. I’m keeping his contact info close by. When your SQL DB goes belly up, knowing a guy like Steve is like gold.
More from Stedman Solutions:
Steve and the team at Stedman Solutions are here for all your SQL Server needs.
Contact us today for your free 30 minute consultation..
We are ready to help!