Voice of the DBA

Category: Editorial

  • 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/)

  • 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

  • NoSQL Basics

    Last year there was quite a bit of press devoted to the NOSQL movement, emphasizing the scalability and power of this class of databases. They have not been well known, but have been used to power some of the very well known Internet companies out there. Companies like Google, Facebook, and others are using NoSQL databases in places, achieving the scalability that many RDBMS’s have struggled to achieve without enormous costs.

    I ran across an article that talks about some of the basics of what is classified as a NOSQL database. It’s written more for managers, and it does a good job of warning them that NOSQL is not the “answer” to all your performance problems. It’s a piece of technology that fits in some places and in some situations.

    Should you care about NOSQL? I think you should, if for no other reason than some manager will ask you about it at some point. Or a developer will want to build an application using a NOSQL database. A flat “no” from the data group is counter-productive,  and is not appropriate. If you are going to rationally argue against a new technology, you should have some basic understanding of how it works, what problems it solves, and engage in a logical debate.

    There are lots of good NOSQL articles out there, and perhaps the first thing you should learn is that there are different types of technologies for solving different problems. Cassandra is not interchangeable with MongoDB, and Voldemort is different from the other two. None of them is a direct replacement for SQL Server (or another RDBMS), but they do work in different areas. If you’ve never seen the CAP triangle, take a look at it now.

    Many of you are data professionals, and SQL Server specialists, and that’s fine. That doesn’t mean you shouldn’t learn a little something about other technologies, and how they might compare and contrast with SQL Server. Here’s a nice basic article from SQL Server Master to get you started.

    Steve Jones

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

    Podcasts:

  • Data Loss or Downtime

    I was watching Kimberly Tripp of SQL Skills talk recently about VLDB disasters and how to recover from them. One of the first things she said in the session was getting a damaged database back online, even without all of the data, was important. Often her clients need to keep working, and it is important that they get the system back online, even without all the data. This allows business applications and business people to get back to work.

    That is interesting. I had always thought of my production OLTP databases as needing to be online, but also needing all the critical data. After Mrs. Tripp’s talk, I had to rethink that a bit and consider that a little data loss might be acceptable.

    To me this is a topic that is worth understanding. At the very least, it will help you make decisions in the event of some disaster for how you will proceed. So for this Friday’s poll:

    So what is more important to you: downtime or data loss?

    My feeling is that most of the people would really rather have the database online, even without all the data so they can continue to work. I realized that most of the time, getting the site back up, having lookup and other types of ancillary data (like products, prices, etc), was the most important thing. Recovering other data such as older orders, was secondary.

    Once the database is up, you can then work on getting other data back and merging it into the production system.

    Let us know what you think this Friday and what’s more important to your business (and why).

    Steve Jones

    Originally Published at http://www.sqlservercentral.com/articles/Editorial/72117/