Voice of the DBA

Category: Editorial

  • An Azure Outage

    SQL Azure
    Azure was down recently

    There was a Windows Azure outage on Feb 29, which resulted in the management service being down for about 8 hours. The actual virtual machines that most customers had were unaffected, but the ability to perform management functions was down for a number of customers.

    That’s distressing for customers, and embarrassing for Microsoft, who is spending a lot of resources to promote cloud computing and their Azure services. It lends credence to the fears and concerns of many technology professionals that outsourcing parts of their infrastructure to a cloud provider is a problem.

    However is it a big problem? I’ve had outages in nearly every company I’ve worked, often because of problems in the architectures that are built by those same IT people that disparage the cloud. I’ve found that a few outages were from vendor patches, a few from failures, and a good portion were stupid mistakes, often from a lack of testing. We worked hard to fix things, but we often weren’t able to give management much more of an idea when things would be working than a good status page for Azure would provide.

    It’s easy to disparage outsourced services as less reliable than in-house services, but I’m not sure that’s true. There is definitely a loss of control, but that comes at a cost savings, and the balance between them is something that each company needs to decide. However I think lots of management might prefer in-house infrastructure for a simple reason: it gives them a specific neck to choke, and possibly replace, when things go wrong.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Consistency Debate

    How consistent do your systems really need to be?

    One of the questions I constantly see asked about on SQLServerCentral is how can you scale out the database. How can you easily keep multiple copes if your data in sync with one another on different servers, and allow clients to read from any of those servers. The Always On features in SQL Server 2012 will allow readable secondaries, something that wasn’t possible in database mirroring, giving you up to date reads of your data, which is in sync with your primary database.

    However is that really necessary for many applications? The largest applications in the world, Google’s search engine, Facebook, and more, are turning to NoSQL databases and storage to handle their loads. I ran across a nice piece on Ars Technica that talks about how these companies handle the large data storage challenges they have. The one very interesting thing in the piece is the way the consistency challenges are talked about. These phrases, “designed with less concern for consistency of data across the system”, “jobs in progress will still hit stale data”, and “(it) is entirely okay with serving up stale data”, would scare most DBAs I know.

    But should they? For some applications, it is important that we maintain consistency across nodes. The classic bank account example requires that a withdrawal and a deposit between accounts are totally committed or rolled back to ensure the proper balances. However that doesn’t mean that every node in the banking system knows your balance. Only those times when a transaction affects the balance, do we need to be sure of the actual value. Deposits are sometimes not reflected immediately on another node, say a remote ATM. Withdrawals are sometimes approved, even with modern checking machines, when there are insufficient funds, resulting in bounced checks.

    In many of our applications, we are told we need consistency, but I think that’s a goal. It’s like 100% uptime, which is rarely met, and almost never funded. Think about a report. A User might run the report, assuming that the data is accurate, and it may be, but 14ms later it might not be because of changes. If the report had been run 14ms earlier, it might have missed other changes. Most people understand that, even if they are asking for consistent behavior of the system.

    With that in mind, should we be looking for more distributed architectures in our applications? I think that replication and service broker, both excellent techniques for scaling out, should become a more regular tool for our applications, and should receive more attention in future versions of SQL Server. We are only acquiring more and more data, and while hardware continues to get more powerful, we are outpacing the developments in storage bandwidth. We should start thinking about how to anticipate future challenges in application load, not reacting to them later.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Great Developers

     

    Are you on track to be a great developer?

    Is a great software developer worth 100 average ones? On one hand I think there are some good arguments that it’s not true. One developer certainly can’t write the amount of code that 100 average ones can. However there’s another way to look at things. A great developer can do things that the 100 will never think of, or never consider. He might not write the code that does as many things as 100 people, but I think a great developer could easily write code that performs a hundred times faster than the code 100 developers write.

    That’s why you always have an open position available for a great developer. If one is available, and they rarely are, you hire them if they want to work for you. You can always find things for them to do, and they can make improvements in code that your other 5, 10, or 20 developers will never come up with. I’d make sure they fit in your team and get along with others. You can get less work done if you have someone that is too difficult to deal with or too critical of others. While a great developer can accomplish things that others can’t, or won’t, they can’t do all the work.

    Ultimately I think that managing great developers is hard, and they are unlikely to stay with your company for a long period of time. However they are rarely available, and for a few years, they might jump start the evolution of your software, and potentially build something that makes your software great. I’d always have an open spot in my team for a great developer, and hire them as soon as they came available, if I thought they would fit in well with the rest of the team.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Old, but stable

    SQL Server 2000 was a great platform

    I had another poll planned for today, but then I saw Paul Randal’s blog on SQL Server 2000 and it inspired me. I spent many years working on SQL Server 2000 systems, and I liked the platform. It very very stable, reliable, and effective for the companies in which I worked. This was pre-cool SQL Server logo, pre-SSRS, pre-64-bit hardware. SQL Server 2000 was the release that I spent the most time working on to that point in my career.

    Today we have an easy poll, and I’d love to get your answer, and I’m sure Paul would as well, so feel free to put your answer here and on his blog:

    Are you still running SQL Server 2000 in production and why?

    It’s 2012, we have now had 4 releases of SQL Server since SQL Server 2000, but I know there are still plenty of SQL Server 2000 instances out there. It’s not being actively supported or patched, but many companies still continue to use it. Why?

    The reasons often come down to money. I know a few friends that have SQL Server 2000 instances running some proprietary software and their companies do not want to spend the money on an upgrade. With a stable database platform that doesn’t have issues, would you? Is it worth upgrading to the latest version of the platform when what you have works?

    I think you upgrade when you see an advantage to doing so. If that means you want readable secondaries that provide HA, DR, and reporting, then you are probably planning on a SQL Server 2012 upgrade now. If you have to run a key card system that checks people in and out of a building, SQL Server 6.5 probably works fine.

    Let us know today if you still run SQL Server 2000, and how it’s working for you.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.