Voice of the DBA

Author: way0utwest

  • Dexterity Matters

    I typo things. I make mistakes in the QOD, checking the wrong box. Even in a browser at times there’s a button or hot area too close to the bookmarks bar and instead of completing an action, like checking my VSTS control panel, I’ll end up on some other website. It’s really annoying, but it’s also an issue that occurs when my muscle memory takes over with my fingers not moving as expected, or moving quicker than the system expects.

    In Star Trek or media, we see these flat, touch interfaces similar to smartphones, but there’s never any mention about the missteps or mistakes that could be made by users selecting the wrong item. As we move further from hardware controls to software selections, are we worried about issues? Is this something we run into with our interfaces?

    I certainly think so. No matter how often I can do something correctly, I make mistakes. Often simple mistakes, born of impatience. This is especially apparent in Azure and online interfaces where the control, or the browser, might not respond as quickly as I expect. As a result, I might click something multiple times, spawning more actions than I expect. Or I might have an unexpected action occur.

    This is one of the great arguments from me for having local software. The interface interactions tend to be more reliable and expected. If nothing else, a local process can allow control of the input buffer, discarding or limiting the multiple clicks that cause issues.

    As we move forward, software designers should expect that users will make mistakes and ensure there are ways to cancel or undo accidental mistakes made in an interface. This isn’t always possible, and certainly there are some actions that might not be easily undone, but as we become more dependent on software, we need to consider the potential mistaken actions that users will make and provide methods to correct issues. Especially where data is involved.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.0MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • SQL Nexus in Copenhagen

    The Nordic SQLNexus conference is taking place in Copenhagen on May 2-4. I’ve never been to the event, or the country, but I was accepted to speak, so I embark on another multi-city, multi day trip.

    SQLNexus has quite a lineup, and I suspect a few of these people will be travling alongside me, in Copenhagen at the beginning of the week and Liverpool at the end.

    • Joseph Sirosh, Microsoft Vice President
    • Troils Peterson, Professor of Particle Physics at the Niels Bohr Institute
    • Allan Hirt
    • Itzik Ben Gan
    • Denny Cherry
    • and more

    I’m looking forward to the event, and if you want to come to a SQL Server conference packed with content, think about making your way to Denmark on May 2-4, 2016.

    Hopefully I’ll see some of you there.

  • Protecting sa

    Built in accounts are both a help and and a hindrance. Years ago I was working on a SQL Server 4.2 system, where I was an administrator. The database was very unstable, and we were trying to determine if it was something being done by the application or the platform itself. While I was a local administrator, I couldn’t access other, remote SQL 4.2 instances at other locations for our company. Since we ran the same code (supposedly), we wanted to test how various parts of the system performed between the two systems.

    One late night, while actually reading the manual, I discovered the “probe” account, which was a built in account for early Sybase/SQL Server versions. I used this to query remote instance and compare settings and performance. This helped us narrow down the the problems, though it wasn’t the way I would have wanted the system to work.

    Any built in account allows some ease of getting an application working, but it also provides a known backdoor to your system if it is not properly secured. The “sa” account is one of those well known accounts for SQL Server that can cause issues. This account has complete control over SQL Server, and even though it can be renamed, simple queries can discover what the new name is and mount attacks. This is one reason why many people like to only enable Windows Authorization, preventing anyone from logging in with this account?

    However, is this enough? I don’t think so, as a simple administration action could enable mixed mode authentication. I would say that everyone should set a long, random password for “sa” on all instances, but what do most of you think? Do you provide any other protections for the sa account? Let us know today.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8MB) podcast or subscribe to the feed at iTunes and LibSyn. 

  • Default Data Masking

    Dynamic Data Masking is a neat new feature in SQL Server 2016. I didn’t think much of it when it was introduced in Azure SQL Database, but since then I realize there is some value here. Even if it’s just making life simpler for developers.

    I’ve been experimenting with this a bit, learning how it works, and one of the options we have for masking data is to use the default option. However, what seems misleading to me here is that this doesn’t use a default from the column. Instead it replaces the values with

    • 4 x’s (xxxx) if the column size is > 4 characters (same for numerals)
    • the number of x’s that fit in the column if the size is < 4.
    • 0 for numbers

    This makes some sense, but not completely. I think I’d prefer to set a default mask for all types, so that I don’t disclose a value is a number or string (or date or anything).  I also see that NULLs are disclosed, another potential area I’d prefer to keep hidden.

    I also think the name is misleading. I’ d prefer to see this called something like xmask, or defaultmask, not default.

    If you want to learn more, you can look at a piece I’ve written to cover how this works, details on the default mask, or check out our list of resources at SQLServerCentral.