Voice of the DBA

Author: way0utwest

  • Operating in Failure

    This editorial was originally published on Sept 25, 2006.

    This quote is great: “Any large system is going to be operating in failure mode most of the time.”

    It’s from Peter Coffee’s essay on learning from paper based systems and what works in their digital equivalents. Peter examines the conversion of a paper based system for keeping track of Boy Scouts’ work on merit badges as the process moves to an online system. He points out a few flaws in the design matching the process.

    More importantly, he points out that the system fails in a few ways, which is to be expected, but it doesn’t fail gracefully. I think this is a good point and one that most developers fail to take into account. Most systems will “fail” in some way and should be able to handle that failure. Whether it’s data entered incorrectly, a mishmash of keys hit, incomplete data, or something else. We seem to expect that our systems will move along perfectly and that our systems will “force” the users to work in the approved method and process, thereby improving efficiency and ensuring things work well.

    I’ve encountered this in many places, but none more apparent then surveys that we used to send out to customers. We’d require answers to many questions to ensure that we could properly fill the parent and child tables in the database and ensure proper reporting. The developers were happy to run along and build this and make it work as expected. My issue, however, was that the surveys were sometimes long and complicated and we should be sure to capture some information in the event the user stops early or has connectivity issues. In other words, assume we will have issues and plan for them.

    You’ve probably encountered this in other places as well. Every system, especially web based ones, should be expected to fail at some point and you should gracefully deal with those issues. We’re all human and we make mistakes and the systems we build will have bugs, problems, or even unintended uses by our clients.

    So plan to fail and you’ll be better off.

    (This editorial is published at: http://www.sqlservercentral.com/articles/Editorial/72149/)

  • iPhone or Android?

    With the announcement of the iPhone on Verizon, I’m getting ready to switch carriers. I’ve had decent luck with a jailbroken iPhone on T-Mobile, but my coverage is spotty, I’ve been working with the two-gees on an Edge network, and I’m ready to pick something up that’s more modern and powerful.

    I was hoping for an LTE iPhone on Verizon, but that didn’t happen. It might happen with the iPhone 5, but I’m not sure. My guess is Verizon is going to see how their new Android phones work on LTE and gauge capacity first. Then we might see one in the fall.

    So my choices boil down to:

    • iPhone 4 on Verizon (3G)
    • 4G Android on Verizon
    • 4G Android on Spring

    I suppose I should consider a Windows Phone 7 device, but honestly I don’t know that I’ll get the app support I want. To me the differences between iOS and Android are non-existant on the hardware. Sure one phone might be slightly more powerful, but not by a lot. The interfaces are similar, I can get a real keyboard on Android, but the rest is just noise. The marketplace is important, and music sync is something I want.

    I looked around a bit and it seems that music sync is something that could work with Android, and I have a few choices there. So really it’s a question of the various apps I use working on Android. It seems that many of them are either on Android, or there are similar ones. So I could make it work on Android, and I wouldn’t necessarily need to re-invest a lot to move to Android.

    Ultimately I’m not sure that I want to move away from iOS if I don’t gain much. I am definitely leaning towards an iPhone 4, and living with the slower 3G speed. Heck, it will be an upgrade for me in cities, and out near the ranch it won’t matter. No 4G is coming here anytime soon. Half the time we can’t get 3G.

    I saw an interesting article about the iPhone on Verizon and how it’s not their best smartphone. I question if that’s true, since the raw hardware specs don’t mean everything. I have a few weeks to think about it and research a bit, so that’s what I’ll do.

  • Resource Governer–Memory Limits

    I had looked at the Resource Governor early on when it was being developed and first released on SQL Server 2008, but I hadn’t spent a lot of time on it. It was the first cut at a throttle that I had been asking for since 2001 or 2002 when I saw IIS get a CPU throttle. I loved the idea of being able to slow down the amount of CPU that an individual query could take, which I thought would really help limit the amount of damage that a particular query could do on your system.

    However I hadn’t spent much time on the memory limits. While studying for the MCM, I downloaded this white paper and watched the Paul Randal video from Technet. In it, I was reminded that the memory limits you set apply to the query memory, not the buffer pool memory.

    What does this mean? It means that while you can limit the memory that a query uses for it’s data, for it’s plans, etc., you can’t prevent a query from flushing the buffer pool when it causes a lot of reads from disk.

    This is a limitation of the Resource Governor, and we might see this changed later, but it’s a good thing to remember that you cannot use Resource Governor as a way to guarentee predictable performance from your SQL Server. The engine is still a shared resource and one person can still affect it’s operation. Resource Governor does allow you to limit the damage, and it can be used to prevent someone from bringing the instance to a standstill. However it does not provide the complete control that you might assume is implied from the name.

  • The Importance of My Cloud Data

    I recently rebuilt my laptop, and when I installed Office, there was an offer to sync my Office data up to the cloud. I declined since I already use Live Mesh to sync data across multiple machines, a Windows Home Server for local backups, and Dropbox for remote ones. It’s not that I don’t like the cloud, but that I’m not sure I, Steve Jones, can trust the cloud.

    There was an outage at Hotmail recently that involved SQL Server. That’s bound to happen as the larger you are, the more likely it is that you will have some sort of failure.  It’s inevitable, and hopefully you have done enough planning to recover quickly. I don’t know where the Hotmail team failed, but they certainly failed somewhere.

    The cloud works because it provides some great economies of scale, a much more efficient use of computing resources. For many people, that means it can also be a much cheaper way to get the services they need. Even companies could do find advantages in using cloud-based services.

    However this outage shows one of my major concerns. It’s not that I find Hotmail unreliable, or that I worry about security. It’s that when something breaks, and it will, I’m not sure Hotmail will care a lot about my data. If Steve Jones, Inc., a company paying Microsoft $1000 a year for mail, Office, etc.,  winds up losing 3 days of service and 1 week’s worth of data, will Microsoft care? What if the same failures affect a large company, one that pays Microsoft $1,000,000 a year? Whose data will they work harder to restore?

    Ultimately economics and realities set in. Microsoft, and every single other cloud provider out there, will worry about the larger customers first, and perhaps not even bother to finish restoring data for the smallest ones if there is not enough cost benefits. They might even refund the payments of someone to compensate them.

    If it’s my data, however, I’m not sure that’s good enough. I’m also not sure it’s a risk I want to take.

    Steve Jones

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

    Podcasts