Day 22 of 31 Days of Disaster Recovery: Which DBCC CHECK Commands Update Last Known Good DBCC

The end of the day is quickly approaching as I finish this blog post. This is day 22 in my series 31 Days of Disaster Recovery, and I want to examine which DBCC CHECK commands update the last known good DBCC check that is tracked in the header of the database. To check this value, I could either dump the header page using DBCC PAGE() or I could just output he header info using DBCC DBINFO(). Both of these functions
read more

Day 18 of 31 Days of Disaster Recovery: How to CHECKDB Like a Boss

Day 18 of my 31 Days of Disaster Recovery series is drawing to a close. It’s 11:22 PM here, and I’ve been working feverishly to finish today’s post before the calendar flips over to tomorrow. This started out as sharing a simple script I use for running DBCC CHECKDB against all databases on a server, and like I tend to do, I thought of lots of things I wanted to add to it. I spent a several hours customizing my
read more

Day 15 of 31 Days of Disaster Recovery: Running DBCC CheckTable in Parallel Jobs

Welcome back to my 31 Days of Disaster Recovery series. Today is day 15, and I want to answer a question I was asked a while back. Paul Randal (blog|@PaulRandal) wrote a blog post explaining alternative options for checking integrity of a very large database if you are not able to run the full CHECKDB process, and the question was borne out of one of the recommendations by Paul. One of the tactics Paul recommends is breaking the process up
read more

Day 6 of 31 Days of Disaster Recovery: Dealing With Corruption in Allocation Pages

Day 6 of 31 Days of Disaster Recovery: Dealing With Corruption in Allocation Pages Yesterday, I covered corruption in nonclustered indexes, the easiest type of corruption to handle. Today, I’m going to move on to something slightly more complex, yet still really simple to manage. Today, I’m going to talk about what to do when you encounter corruption of an allocation page. Allocation pages cannot be repaired not can they be single-page restored. If you have corruption of an allocation
read more

Day 5 of 31 Days of Disaster Recovery: Dealing With Corruption in a Nonclustered Index

Welcome to day 5 of my series on disaster recovery. I want to start digging into some corruption scenarios. We’ll start off with the easiest form of corruption to fix, a nonclustered index. The generic steps we will go through for any corruption scenario are as follows: Identify the corruption (DBCC CheckDB) Identify the objects and types of objects involved Take the appropriate steps to correct Sadly, one of the biggest mistakes people make is to jump straight to the
read more

Day 1 of 31 Days of Disaster Recovery: Does DBCC Automatically Use Existing Snapshot?

Day 1 of 31 Days of Disaster Recovery: Does DBCC Automatically Use Existing Snapshot? Welcome to my series on Disaster Recovery. I will spend the entire month of January focusing on all things related to disaster recovery including topics like corruption, data integrity, data loss, DBCC commands, and more. For my first post of this month, I want to take a look at the myth that the DBCC CHECK commands will automatically use an existing database snapshot if one exists
read more

SQLU DBA Week – Be an Efficient DBA

SQLU DBA Week – Be an Efficient DBA Welcome back for another day of Administration Week 1 for SQL University. This is day four, and I want to focus in on a term that I hear quite a bit, lazy dba. DBAs are anything but lazy, but the term seems to have come about by the way that we are always lookign for the simplest and quickest way to do something. That’s not being lazy, that’s being efficient. Don’t be
read more