Voice of the DBA

Category: Editorial

  • Waits and Queues

    How many of you have read this article: SQL Server Performance Tuning Using Waits and Queues? (PDF) If you haven’t, you might look at a review of the paper from Jeremiah Peschka. There is good advice about which parts to read and which to ignore a decade later. There’s an updated version from Paul Randal and SQLSkills as well.

    This leads me to where you might expect this week, with a question for you. Do you use waits and queues to troubleshoot? (Survey)

    Not every performance problem needs you to dig deeply into the way that the database engine processes your query, but there are no shortage of times when understanding waits and queues can help you determine how to tune your system. This is a well known method of trying to determine where to focus your efforts, so I wonder how many of you have tried this.

    If you have, let us know what’s worked or what hasn’t. If you’ve never tried this, then drop a quick note as well if you have a reason you haven’t used waits and queues.

    Performance tuning is a skill everyone needs, and most everyone can work on. This is often one of the most popular topics for talks and classes, and any help you can get will grow your career. Both in your own self confidence as well as impressive to interviewers when you have an answer or a methodology to give when solving any problems you’re given. Whether in an interview or in your job.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Don’t Get On This Page

    The GDPR has been in effect for over a year. While the press has died down a little, outside of a few record fines, there is still plenty of activity. At Redgate, we have customers that still worry about compliance and are doing their best to ensure they properly handle and secure data. It’s a tough job, but one that many organizations need to continue to focus on.

    And there’s a good reason. Who among you would want their boss to come talk to them about mishandling data? Who wants their boss to come after reading this page, with your organization and fine listed? I’m guessing most of us would prefer to not be on that page, or at least not want our boss to know.

    There have been a lot of fines handed out, though most are relatively small. Still, every amount spent towards a fine is money that could be used for shareholders, investment, or even better security and systems to prevent future issues.

    What’s interesting is that many of these fines aren’t for data breaches, but rather for other issues. There are some security issues (unauthorized access), and some inappropriate storage. There are also quite a few consent fines, where data is used without the appropriate permissions from the data subjects.

    I find the list interesting, and I hope this is the type of thing that does drive change in organizations. Many of these fines might easily be eliminated with a few process and procedure changes and adding some security to prevent unauthorized access. While some companies might be willing to pay fines, I expect that subsequent amounts will rise, and it behooves organizations to change both their behavioral and technical practices.

    This might be building archival processes, which would be one of the few ways that might reduce the amount of data that we need to manage and query. Hopefully, something that might improve performance for your clients.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The First Rule

    A long time ago I read a book called The First Law. It’s a legal thriller, and I’d recommend it. It has nothing much to do with databases, but I was reminded of the book and the rules of any particular process when I saw a post called The First Database Rule.

    The post is from Seth Godin, who is really a marketing individual, but I do think his rule makes a lot of sense for clients. I also think that as both developers and database professionals, we forget that most of our clients would prefer to have our systems follow this rule: it should be as simple to fix an error as it is to make one.

    I’ve worked in many systems, and with many people, that expect data entry or loads to go perfectly. They expect things to work and want to blame the process, the person, the file, or something else when something doesn’t work well. What might be worse sometimes is that we expect some data in the database to be immutable, like a PK, assuming that clients will have and enter all the correct data at once. Most of us do allow changes in our databases, but we don’t make it easy, especially if it’s a piece of data like a primary key.

    This is one reason I dislike many natural keys as PKs. We make mistakes when we enter them. Heck, I’ve probably typed my name a million times on a computer keyboard, and I still make mistakes. Even in data entry forms. What’s worse, I have some auto-fill selections in my browser that are incorrect and I’ll select the wrong one at times.

    Fixing mistakes ought to be easy. We ought to expect that we will get data wrong. We’ll load it wrong, we’ll transform it wrong, and our DBAs will type corrections wrong. Design the system to account for mistakes and ensure that problems can be quickly fixed. Whether by a client or a sysadmin.

    Agility ought not to be just how quickly we can change the software. It needs to include the ability to change the data, which is the most important part.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • IT Staffer Fired

    In the early 2000s, it seemed that many companies were hit with a rash of virus attacks on their networks. Certainly the SQL Slammer worm affected many of us, and it was a memorable week for me. I returned from vacation to get a call late on Sunday night informing me of issues. I spent a long work working with network people and Microsoft to rid our (shut down) network of the worm, a difficult process with a wide deployment of MSDE instances installed in non-standard locations.

    Not long after this, we had another virus invade our network and shut down systems. This was due to a high level manager clicking on an attachment in email, which spread issues to (far too) many others inside the company. Another long night for me patching and cleaning systems, and one where I questioned how someone could be fooled.

    In the last year, a similar rash of incidents have spread around various organizations, this time with ransomware instead of viruses. One Florida city government was hit, with an IT worker being at fault for opening a document they received in email. The result? The city paid a ransom and the employee was fired.

    Is this fair? I’ve seen the Twitter mobs and rapid comment trolls condemning and praising both sides. It appears many people rightly think someone clicking on unknown attachments should be fired, while there is no shortage of others that understand that humans get fooled and termination is too harsh.

    Personally, I don’t know what to think. While most phishing and spam is poorly written, and I often check headers and easily see these notes for what they are. I have seen some very sophisticated and incredibly deceitful emails that might fool most of us.

    If you have a privileged account, you better be really careful about opening any attachments from email. You shouldn’t download pictures by default except from whitelisted senders, and you might even want to stop doing that. Who knows if your co-worker or business partner got fooled.

    It’s disconcerting though not unexpected. Perhaps this person was at fault, perhaps it was  mistake. Being fired is never fun, and all of us should be a little worried about this if we’re not careful.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.