Many of you are administrators, maybe accidental ones, but you have some responsibility for ensuring your databases run smoothly. Part of ensuring this happens is monitoring resource usage, configuring security, and patching your system. However, the long term health of your database requires some proactive work to ensure things continue to run smoothly. One way of doing this is using checkdb to assess the health of your database's internal structure.

Those of us that are full time focused DBAs likely run checkdb, though potentially not in the best way. There are implications to "offloading" this work to another machine. Those that are accidental DBAs, developers, or someone else with other duties might not think about checkdb as necessary.

Do you think about how you should run checkdb? Do you think about licensing issues? Do you think about the frequency and breadth of where you should run checkdb? I'm wondering what some of you do after I ran across a post from Brent Ozar on offloading this work. If you haven't dug into how checkdb works, you might not realize some of the things that Brent brings up. Even if you think you know how this works, read the post.

I've usually been able to run checkdb in production, but I recognize that more and more environments can't do that. Usually because of the resource contention. When I've had that issue, I've accepted a time lag to getting results. I don't worry about finding out about database corruption a day later. I can probably deal with that. I worry about finding out a month later, when reconstructing data is much, much harder.

This isn't to imply or recommend that you need to run checkdb on each production instance, but rather to get you to think about how checkdb works and choose a strategy that works well for your environment. Even if you have this set up, ensure your configuration still makes sense for your organization. Take a few minutes and read the post and then schedule a review with colleagues of your checkdb philosophy.