Voice of the DBA

Author: way0utwest

  • T Minus Three Days to the MCM Test

    I take the MCM test on Friday. I’ve been watching videos and reading white papers and blogs for the last few weeks and I know that I don’t necessarily know enough. To some extent I have an advantage since I test well on multiple choice tests and I have a broad set of knowledge for SQL Server.

    rockholesBut I don’t know enough. The more I study, the more it becomes painfully clear how much more there is to SQL Server that I don’t understand. Each day I learn something new, but I also learn that there are things I wasn’t aware of

    Often, I find that things I just learned are things that friends already know. The thing that gives me some hope is that they will learn something and tell me, not realizing I already know about it.

    We all have these uneven holes of knowledge, and just because we do, or don’t, know about feature X, doesn’t mean that we don’t know a lot about feature Y. We have un-evenly learned SQL Server since there isn’t a set path on which to learn.

    So I’m nervous, just because it’s a measure of my skill, not because it matters to my career. It will give me a benchmark, and a place from which I can make a plan for how much more I want to learn about SQL Server, and in which areas to work.

  • Archiving Little Used Data

    Old fashioned data archives

    Someone asked the question lately about archiving old data. This person wanted to purge data from old tables and was wondering if there was a way in SQL Server 2005 to detect the last time a table was accessed. While there is some data kept on tables being accessed (plans, potentially missing indexes, etc.) this data is not preserved forever and often is cleared in restarts.

    With no reliable method for determining when someone last accessed a table, what can you do? It’s a question that DBAs face regularly now, and will face more often in the future. With data sets growing quickly, and storage budgets growing more slowly, the need to archive data becomes more prevalent all the time.

    I hope at some point the metadata about table access will get built into SQL Server, but until that time you are on your own. If you can change the application code, you might be able to log this, but ultimately I think that you might end up making some type of guess about whether or not a table, or subset of a table, is still being used.

    Once you do that, there are multiple ways to archive off the data, but no matter how you build a process, make sure that you can do one thing: restore the data. Someone can understand you making a mistake in which data to archive, but they won’t likely understand if you make a mistake in restoring it.

    Steve Jones

    The Voice of the DBA Podcasts

  • Catching Up

    It’s President’s Day in the US, and technically a holiday for me (I think). Hard to tell since my company is a UK company and the holidays get a little weird for me. However it’s a holiday for my wife and kids, so I’ll take part of the day off.

    I do have some things to do, and a ton of messages piled up from vacation, so I need to go through things a bit and get some things done for tomorrow.

    Strange to be back, after being gone for a week and mostly unwired. I took my laptop and checked some email, thinking I might work and write a bit, but didn’t. I did get some MCM studying done, so it wasn’t a complete sit-by-the-pool-and-drink-fest, but not as much as I might have liked. Some notes, and some good questions to run on SQLServerCentral as the Question of the day.

  • Backups after a DR Restore – MCM

    If you have a disaster, and you need to restore to some point in time prior to the last log backup you have, what’s the first thing you should do at this point in time?

    Make a full backup, of course.

    Actually anytime you complete a restore sequence, you want to do a full backup immediately before you turn users loose to do work. Why is that?

    Think about what happens if you complete the restore and then have another issue? You would have to go through the entire restore sequence again from before the first disaster. If that were a full backup, a differential, and a dozen log backups, would you want to explain that delay to your boss again?

    Would you even want to go through it?

    I wouldn’t, and it’s easy to prevent. Once you get done with your restore, start a full backup right away. You might never need it, but then again, you probably said that about the full backup you just restored.