Voice of the DBA

Category: Editorial

  • No Overtime

    This editorial was originally published on Dec 5, 2011. It is being re-run as Steve is out of town.

    It’s been a long time since I received overtime at any job. Most of my IT work has been with a salary, and the expectation that I would work as needed to accomplish my assignments. Early in my career I worked as a contract for an hourly rate, and while it didn’t necessarily lower the hours I worked, I did receive a little more pay on long weeks. From there I worked for a company that provided “comp time” when the hours exceeded 20 hours in a month. That seemed to help reduce hours more than anything.

    There’s a bill that’s in the US Congress that adds some new job classifications to the exemptions for overtime pay. In addition to the system administrative jobs, it now includes database and network professionals. I’m not sure how many people this affects as the overtime requirements disappear once you make more than $27.63 an hour. That equates to about an annual salary of 57,491, without the benefits. If you make less than this, you should be getting overtime.

    Does overtime pay matter to most IT workers? I don’t know. There are lots of workers who make more than US$60,000 a year, and are exempt, but I suspect there are many others who make less than this amount and work long hours without any extra compensation. This bill is aimed squarely at reducing pay for those people in the industry that make the least amount of money.

    I struggle with whether the benefits and abuses of a salary. On one hand salaries provide a level of security to workers, along with a guarantee of payment for work that cannot easily be measured in terms of output per unit of time. On the other hand, employers sometimes see a salary as a way to push workers to their limits, burn them out, and impose strict requirements on the work needed for deadlines, themselves often arbitrary.

    I like the idea of allowing businesses to pay salaries, and stabilize their cost structures, but I do think we ought to implement a few bumpers that prevent abuses. Limiting hours across a month or quarter and ensuring that employees can take their vacations would be limits that I’d like to see implemented. This bill doesn’t affect those and I’m not sure we’ll see any limits implemented, but I do think it’s up to each person to stand up to their employer and ensure they are not overworking themselves.

    Steve Jones

  • Examining SQL Server 2016

    SQL Sever 2016 is getting close to release. The updates are coming fast and furious, causing issues in some cases as many people look to test the new features in different environments. Personally, I’m struggling a bit to determine which of my environments to update and test, and which to skip. It’s also hard to keep track of those items that work in newer environments, and those I need to keep working on old systems with older code.

    We saw CTP 3.3 this year in January, with both RC0 and RC1 coming in March. I expect we will see an RTM soon, though it’s possible we have more Release Candidates before then. I know there are still some bugs in RC1, so I’m hoping we get at least one more release to show that both the core platform, as well as SSMS, are stable and working well.

    I know many of you won’t be upgrading any production systems, and maybe not even development systems, anytime soon. However are you looking to work with the platform and understand how it’s changed? I think SQL Server 2016 deserves a look, even if it’s curiosity. There are quite a few changes and it’s possible you’ll find some things in there that may make an upgrade worthwhile.

    Even if you don’t find anything valuable for your organization, it’s a neat release, with quite a few enhancements and additions. There are features you are just interesting and exciting to experiment with. Certainly there is plenty to learn as well, with the chance to see how new features, like temporal tables, work, or test the new T-SQL functions against your current code and see if you can beat them.

    Looking at a new bit of software can be invigorating to your career, as you try to grow your knowledge and build new skills. Given that most of us perform work that requires thought, just exercising your brain with the SQL Server 2016 eval might enhance your thought processs and let you enjoy your job just a bit more.

    Steve Jones

    The Voice of the DBA Podcast

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

  • 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.

  • 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.