Voice of the DBA

Author: way0utwest

  • Quality Over Timing

    Is quality job one?

    Is quality really the number one job of software developers? I think we’d all like this to be the case, but I suspect that in many companies it’s not. This piece is a few years old, and it talks about how quality has become more important at many large software vendors. Looking back across the five years since the article was written, do you agree?

    Whether you are a commercial software company, or building applications for internal use by a company, there are so many external pressures to finish or ship an application that quality becomes a second, or even third, tier goal. The need to have people begin using the software, with those last minute features added, means that quality gets cut in some areas.

    We build software with the best of intentions, and I understand that there must be a deadline for the software to start being used. However I think that the balance between finding a finishing point for a version of software and quality is leaning a bit too often towards the deadline taking priority.

    In my ideal world, we would pick a stopping point, and then ensure that the development and testing of everything in progress before the stopping point is completed. In other words, we can’t pick a ship date, but we can pick a design end date, and from there work through the proper build and test from that point forward to a well built piece of software.

    I don’t know if we’ll ever get to the point where the overall image of software is that it is mostly well built, but I can hope we do.

    Steve Jones

    The Voice of the DBA Podcasts

  • Wow, where did the month go?

    It’s T-SQL Tuesday again, and I’m not prepared (again). I missed all the tweets last week while I was at the MVP Summit, so now I need to try and find time today to knock out a post.

    It’s work, and effort, but I enjoy participating in this party, so I’ll be digging trough my mental inventory of stuff for this month later today.

  • An Overview of SQL Server AlwaysOn

    One of the changes coming in SQL Server v11 (not sure what the name will actually be), also known as “Denali”, is the addition of more High Availability/Disaster Recovery Options. When I first heard about this, I was excited, but the public CTP had limited support for it. I’m hoping the next CTP will substantially improve the feature and this makes it to the RTM.

    In the meantime, here’s a Channel 9 video from Justin Erickson that gives a short explanation of how this works and how it compares with the current Mirroring/Log Shipping/Clustering options.

    SQL Server AlwaysOn

  • Avoiding Logging

    I can avoid this kind of logging, but not SQL Server's kind.

    As I have been studying more about SQL Server internals this year, one of the myths that keeps being debunked is the idea there are operations in SQL Server that are not logged. That’s not true as everything you do in SQL Server is logged to the transaction log in order to ensure that SQL Server remains ACID compliant and cannot end up in an unrecoverable state.

    I’m not sure where this myth started, but I suspect that some version of the telephone game is at fault. I constantly see people asking for a way to insert or delete data from SQL Server without affecting the transaction log. One of these wish list requests likely got transformed into an imaginary feature that many people think has to exist in the product. Surely there is the capability to not log things if they are deemed unimportant.

    There isn’t, and you can’t, and I’m not sure that I’d even want this feature. Logging introduces overhead, and it can slow down processing, but it also provides a tremendous amount of safety and security. Computers will crash, power will get turned off, and hardware will fail. Mr. Murphy will ensure that one of these will occur while a large import of some sort is taking place. I don’t know how the rest of you feel, but personally I would prefer that when my database is restarted, I can be sure that my data is in a consistent state. Transaction log logging ensures this is the case in SQL Server.

    We often make decisions based on the data sets we have, and for the most part we want to be sure that all the data we added, updated, or removed from the system is in a known state. We do not want to accept partial transactions being recorded. We need to be sure that every debit into an account is matched up with a credit out of another account. Too many people seem to think that either their systems will never crash, or that this reliability can be guaranteed without logging.

    Accept the overhead of logging, and be glad that it’s unavoidable. At some point in your career, I’m sure you’ll be grateful.

    Steve Jones

    The Voice of the DBA Podcasts