|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Daily Coping Tip Look up at the sky. Remember we are all part of something bigger I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
Do You Think About CheckDB? 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 work well. Part of this 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 after 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. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
