Voice of the DBA

Category: Editorial

  • Provisioning

    azurecreate

    At a talk recently, the presenter talked about the time lag for an on-premises server to be installed and configured to be on the order of months. Not that many, but it could easily be six months.

    That seems crazy, but in many companies I’ve worked in, that wasn’t an unusual time frame. From the time someone decided that a purchase was allowed, it could be days for the accounting department to approve the funds. A day or two to place an order, assuming that IT had already provided the specifications. Vendors respond quickly, but it could still take a week or two, possibly even more, for a server to arrive at our company.

    One of the advantages of cloud computing services is that new virtual machines can be bought and enabled in minutes. That might be true, but I wanted to ask many of you if you know how longs it actually takes for you to begin working on a new SQL Server.

    How long does it take to provision a new server?

    Imagine that you were to ask for a database server today, and you management agreed to grant the approval, think about how long would it be before you could sign into a SQL Server. I’m sure some of you have virtual infrastructures available, and that should reduce the time it takes, but let us know if that’s your setup and how long it takes.

    The ultimate service would be a cloud like application inside your organization that allowed you to select a SQL Server template, and send you a server name and login with minutes after an automated build took place. I don’t know many companies that have that yet, but I think many of us would appreciate that capability. Especially if we could choose the hardware we required.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Trusting Systems

    What's the cost of this?
    What’s the cost of this?

    Computer technology has become more and more integrated into all sorts of businesses. These days when I look at the ways in which automation and technology is embedded in business, I’m amazed to think that I worked in businesses that didn’t have any personal computer systems early in my life. Unfortunately this integration comes at the a price: dependence. We depend more and more on our systems working as expected for businesses to continue to operate.

    Most businesses can tolerate some issues and failures in their systems for a short period of time. As much as I want to maintain 5 9s of uptime, I’ve never been in a business that really required that level of stability. I’ve had systems go down that management claimed were critical. They’ve been down for a couple days, and the companies didn’t go out of business. We have a lot more tolerance than management would like to admit. If you work with a 24×7 environment like Amazon’s online store or a banking application that is generating revenue every second, that might not be true, but for most of us, in most organizations, for most systems, we can tolerate some downtime.

    However the effects of some failures can’t easily be measured. American Airlines had computer issues recently and had to delay or cancel 400 flights. I’m sure there were some costs in compensating customers that took other airlines, or received vouchers for services. However, most of the flights were moved to later in the day, and I doubt there were many refunds. The short term costs of this computer issue were probably relatively small. Given the fact that some customers might have skipped or moved flights, with a change fee, there might not have been any absolute short term loss.

    However it’s impossible to know how many other businesses were affected. Sales calls that were missed and not rescheduled, people that missed events that were important to them and they’ll never be able to attend, or even penalties paid on contracts for the failure to deliver something in person. What’s also impossible to know is how many people will reconsider booking flights with American in the future because they lost their trust in that company.

    That’s really the bottom line for most of our management and our businesses. If we can’t provide reliable computer systems, management won’t trust us, and their customers won’t trust them. If that happens too often, we won’t be employed, and at some point in the future, we might find ourselves unemployable if our reputation is such that we can’t keep systems running.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Understanding HA

    51JU2kM8vHL._SL160_PIsitb-sticker-arrow-dp,TopRight,12,-18_SH30_OU01_AA160_I’ve learned a lot about high availability (HA) and disaster recovery (DR) over the last two decades. Some of the things I’ve learned were from studying, some from experimentation and practice, and a few from hard lessons when some part of a system failed. The latter were how I learned the quickest and most effectively, but those were also the most stressful times in my career. Getting called by senior management because a system is down is not the way that I want to improve my skills.

    I know many people struggle with HA and DR, which are two different concepts. They are designed to solve different problems for different situations. SQL Server includes a number of options for how you might handle either HA or DR situations (or both), and the list of options continues to grow over time. We have the AlwaysOn suite of technologies, database mirroring, replication, log shipping, and more.

    All of the technologies that you might use to solve HA and/or DR problems may provide other benefits. The ability scale out, or spread load are a possibility with a few of these features. What I find, however, is that many accidental, junior, or otherwise inexperienced technology professionals that need to manage SQL Servers get confused. They seem to think HA and DR are the same thing, and one technology is somehow better than others.

    Whether you need HR or DR, or some other solution, it’s important the you research, understand, and practice working with the technologies that you will implement. Books Online gives you a good starting point, and there are plenty of online resources where you can ask additional questions or debate the particulars of your situation.

    Disasters rarely occur, but you should take the opportunities to hone your skills at working with the various technologies you may implement before things fail. Schedule failures of systems in your test environment. See if your HA technology keeps the system running if you remove a system, or test that you can recover using your DR techniques. When something actually goes wrong, you’ll be glad you prepared.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • How do you solve T-SQL problems?

    solvetsql

    Six scans, six logical reads. What could be the problem? There’s no problem if you’re always dealing with six rows of data. If you’re dealing with 6mm, however, this is likely to be a performance problem on your server. Many developers might write a query, check the statistics, and see something like that shown above, and think that it’s a good day’s work.

    Solving the problem is only half the job you should do. Solving things in an efficient way is the other half. When you tackle a new T-SQL challenge, what’s your methodology? Do you have one? I don’t need to know, though if you think you have a good one, post a note in the discussion, or perhaps write an article. If you aren’t sure how you begin, other than randomly trying ideas you vaguely understand or have seen others try, perhaps you want to start by reading Kathi Kellenberger’s Step by Step method.

    The image above comes from Kathi’s article, and is indeed the result of her first solution to a complex T-SQL problem. She lists out the basic steps she used to derive the solution, along with the business rules used. All too often I’ve found developers (including myself), start writing code without taking a few minutes to specifically state the business rules. Following that one step might eliminate lots of bugs in coding.

    Her solution worked, but with 6 scans occurring on her 11 rows of data, she knew this would be an issue. Moving forward she asked for help, which is perfectly acceptable way of working in your career. Try to solve it yourself, get a solution working, and then ask if it can be improved. Not only did she end up with a better performing solution, but she learned a bit more along the way. Something we all can do.

    Steve Jones

    The Voice of the DBA Podcasts

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