If you know about DBCC CHECKDB then most likely you will know about DBCC CHECKTABLE. Quite simply this command performs primitive system-catalog consistency checks, per-table consistency checks on the single table specified, and cross-table consistency checks on indexed views that reference the specified table. (Page 899 Microsoft SQL Server Internals 2012, Chapter 14, Page 899, Paul Randal)
So I had a corruption issue and I was thinking about running repair but I wanted to know what would potentially get deleted.
Did you know that SQL Server tracks suspect pages and puts the details into the msdb database in a table called suspect_pages? Well it does, but the question I want answering is what happens if the page within the suspect pages table is fixed? Does it automatically get removed/updated or do we as the administrators have to do anything manually?
Who should be running DBCC CHECKDB for Azure SQL Database? Should it be Microsoft or should customers be scheduling it? All official information just tells you that you CAN run it (below shows the green tick) but still no clarity around the question.
I have a SQL Server that is constantly producing “dump” files (with a MDMP File type), these are named SQLDumpxxxx (xxx = numerical value). They are located in the following directory: C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log\ – sound familiar?
Have a look at this screen shot – it’s messy!
Following on from my previous blog post I mentioned that I had to find a solution to the “unable to call into C compiler” message. This meant that the specific SQL Server database in question (that contained in-memory tables) went into recovery pending mode, meaning that recovery needed to run but something was preventing it from even starting.
I got bored (really bored) one weekend I decided to challenge myself. I had corruption within a specific table (localised within a page) with no backups handy only an old image of the data files. The challenge being salvage data without attaching the data files.
A quick video clip where I show two things.
Firstly I show how since SQL Server 2014 SP1+ the snapshot is no longer hidden then finally how I check that DBCC CHECKDB has ran successfully.
My database is in the recovery pending state and I want to get in and extract the data out into a new database, I have NO BACKUPS available so some data (even if it is dodgy) is better than nothing.
The title is adapted from a child-hood movie of mine and is my daily (database-related) WTF moment and it is my entry for this month’s T-SQL Tuesday found: http://www.pontop.dk/single-post/2017/03/07/Announcing-T-SQL-Tuesday-88-%E2%80%93-The-daily-database-related-WTF