Voice of the DBA

Category: Editorial

  • 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

  • What’s Your Code Quality?

    The best measure of code quality.

    Today we have an editorial reprinted from Jan 3, 2006 as Steve is on vacation.

    I saw this a piece on code quality recently, specifically mentioning Java development managers and their work on quality. They seem to strive for it and fall short, but I don’t think the results from .NET development managers would be much different.

    The piece talked about most managers not measuring quality or if they do, not starting until the project is over half complete. That’s interesting because in the jobs that I’ve done software development, we were most concerned about timelines, and code was usually graded in one of three ways. Works, doesn’t work, or needs more work. And most things passed through all 3 of these phases during a development project.

    But interestingly enough, I’ve never had quality measured as a DBA. All the T-SQL work either does what it is supposed to do or it doesn’t. And if it doesn’t, we work some more on it 🙂

    There’s never been any measure of code quality for me, and I’m not sure how I’d go about doing it. It seems from the article that they looked at bugs reported v lines of code. I’m not sure that’s the best measurement since I could write some code that works, but is very slow to execute. Or that has hard-coded information that makes maintenance a nightmare.

    I’m not a software expert, especially with regard to quality. To me it either works as I expect it to and well enough or it doesn’t. I kind of use that thumbnail estimation in that a particular item, stored procedure, function, etc. either returns the results it should or it doesn’t, and it works in an acceptable time frame, or it doesn’t. Comparing a method call to calculate interest on a line to a stored procedure that produces a sales by month result is hard, and I’m not sure I could setup concrete ways to do it.

    But I know people are trying. Like the company that sponsored the survey. So I’m wondering, do any of you measure quality? Know of a good way to do it?

    Steve Jones

    (published at http://www.sqlservercentral.com/articles/Editorial/72366/)

  • Have an Extra Beer!

    Fat Tire is Steve's favorite beer

    Today we have an editorial reprinted from Dec 13, 2005 as Steve is on vacation.

    Geeks,

    Have an extra beer tonight. Or your adult beverage of choice to relax and unwind after a long day. After all, it appears that caffeine helps your liver, so don’t worry about damaging it with a couple relaxing frosty mugs.

    The study from the article linked above apparently says that coffee and tea can help reduce the risk of damage from alcohol. So maybe that coffee you drink trying to sober up does more good than just keep you awake?

    As with any study, you should be careful of reading too much into this and don’t go out on some great 12 pint binge and expect a few extra cups of coffee in the morning will repair the damage. After all, in another year we’ll be reading that beer undoes the good that coffee does to your liver 🙂

    But for the geeks in the house that enjoy a cold one, this is certainly welcome news.

    Steve Jones

    (published at http://www.sqlservercentral.com/articles/Editorial/72349/)

  • Slow Fixes

    Moving Slow

    Today we have an editorial reprinted from Jan 15, 2006 as Steve is on vacation.

    There’s an interesting piece at the Washington Post on Microsoft’s delays in releasing patches, with some analysis showing that when the flaw is disclosed to the public, a patch comes out much quicker. After some analysis over the last 3 years and researched the dates Microsoft knew about the issue and the dates that the patches were released.

    Surprise, when everyone knows, the patches come out quicker. It seems that the piece is intended to take a shot at Microsoft’s patching process, and maybe it is, but there are some interesting things in there to talk about. First of all is the time lag.

    Is this any different from any software vendor or even internal corporate software? If your boss knows, or the client knows, don’t you work a little harder and a little quicker? Isn’t it more critical and don’t you rush things in addition to working harder when it’s a “public” patch that is needed?

    I’m sure we all do. And it’s human nature to put more effort into something that’s widely perceived as an issue and less effort if you know that you may have more time. We all do that and our work schedules, effort, and productivity change depending on a variety of things, including the importance of the work.

    The piece also leaves open a number of questions and mentions this, noting that the analysis might be flawed. There’s no mention of if the rushed (or delayed) patches had to be repatched later. There’s concern over patches applying to one area, but other similar flaws found in other parts of the software remaining unpatched. That’s something for sure that should be examined in looking for re-patches or whether things are rushed. There’s also the lack of examination on what else was happening inside Microsoft, and whether people working on other projects had to be pulled off them.

    We all know that delays things as well. They take time to get their head back into code, they may be annoyed, a critical person could be out, etc. Not to mention that the statistical methods might not be the best ones, but I’ll leave that to the mathematicians to figure out.

    Patching is hard. As is finding bugs. I think Microsoft has done a much better job over the last 3-4 years and the quality of software, at least SQL Server, has improved. However there is still definitely room for more improvement.

    Steve Jones

    (published at http://www.sqlservercentral.com/articles/Editorial/72365/)