Voice of the DBA

Author: way0utwest

  • If or When?

    I saw this post recently about security and preparing for a data breach. The title caught my eye because it implies that we’re all doomed. Do the rest of you think that? Is it a question of when we’ll have a security breach not if?

    Given the headlines, the news we find out about companies not disclosing security issues, the back doors and poor code in much software, is it any wonder that people think it’s a “when” and not an “if”? Given the lack of realization from many companies that suffer incidents that they were even attacked, perhaps that’s an assumption worth making.

    We’ve been hacked at SQLServerCentral in the past. I don’t think we’ve been hacked in many years, but I also have no way of knowing. That’s the difficult part of dealing with bits. If they get copied, there’s not necessarily a trace of anything amiss. It’s quite possible that many of us have no idea that our bits are being copied. Every read is a copy of data and how long did the NSA read data without most of us being aware? How sure are we that they, or some other organization, hasn’t been reading much more than was disclosed?

    I’d hate to think that our systems are so porous that we’re all likely to get hacked at some point. It’s probably technically possible, but hopefully not likely for most of us. However we should consider that it will happen and ensure we have some handle on our data security. It’s hard, and complex for most of us, and I’d like to think that Microsoft will recognize this and build better controls and features into future versions of Windows and SQL Server that enable easier auditing, granular permissions, and separation of duties.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Vote for me at SQLBits

    SQL Bits XII is coming this July to Telford in the UK and voting is underway for sessions. I’ve submitted a few and am hoping to get accepted to go back. You can help.

    You can log into the site and vote for the sessions you’d like to see. I’d prefer you vote for me because I’d like to go see friends and meet new people, but feel free to vote for the sessions you’d like to see.

    The ones I’ve submitted are:

    I’m not sure how long voting lasts, but take a few minutes today and pick your ten favorite sessions.

  • Problems with Big Data

    Big Data is constantly in the news. We’ve been asked at SQLserverCentral to try and develop some articles, perhaps even a stairway to explain what Big Data is and how we might use it. I’m still trying to grasp the concepts myself, and unlike the amorphous cloud, I’m still looking for some good examples of what Big Data really is.

    When I ran across this piece warning that Big Data isn’t the final solution to all our questions in the world, I wasn’t surprised. The piece notes that Google Flu hasn’t been very accurate in its predictions of outbreaks. At first glance, this gives lots of credence to the idea that the good, solid data analysis and mining techniques we’ve used for years are just as good as any new Big Data fad.

    However as I read more about the piece, it’s not that big data and the analysis of large quantities of information is flawed, it’s that a solid hypothesis matters. Researchers need to be willing to evolve their algorithms as they learn more about a problem. Probably they should also assume their algorithms are not correct until they’ve proven their ability to predict actual trends for some period of time.

    We’ll constantly be searching for ways to better interpret information and make better decisions. No new technology or product is going to magically solve our problems. Good solid understanding of the problem domain will continue to matter as much as the data itself.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • T-SQL Tuesday #53–Why So Serious?

    tsqltuesdayIt’s an interesting topic this month for T-SQL Tuesday #53. When I read Matt Velic’s invitation, I became intrigued. I like jokes. I like messing with people, and I was thinking about the recent April Fool’s jokes I’d written and those in the past that have been fun. I’m going to enjoy this.

    You can participate as well on any month. Just write a blog post and publish it on the second Tuesday of the month, linking back to that month’s invitation. Follow the #tsql2sday tag on Twitter or set a reminder and Google on the first Tuesday of the month.

    If you hurry, you can participate this month.

    Not So Serious

    The number one rule is know your audience. I’d be very careful who I might play this joke on. Note that this is also a bit of a abuse of privileged accounts.

    There are a few utilities from Sysinternals (owned by Microsoft) that are very useful for administrators. However they have also been very handy for practical jokes as well. Specifically I’ve used the PsExec and PSKill to amuse myself.

    I once worked in a group that had four administrators to run our systems. We lost one of our people to a better job and the corporate management decided to "promote" an internal employee to replace him. This new person was a "paper MCSE", who had studied for the exams. He was making an effort to grow his career and that was something to admire.

    However he was a jerk.

    He had the mistaken impression, as many people that have achieved something they set out to do, that they know more than they do. In this case, much of his "book learning" and boot camp work wasn’t appropriate for the real world. What’s more, when we would work with him to teach him how things worked differently for us, or explain why the book recommendation wouldn’t work, he was arrogant and dismissive of us.

    After suffering through a few months of his dismissive attitude and desire to avoid learning more in the real world, we decided to play a few jokes on him. We downloaded the sysinternals tools and also wrote a few scripts to command line launch tools with specific scripts or settings.

    One day when he picked up the phone to work on a call, we watched him start to connect to a server. Using PSList and PSKill, we’d kill his connection. Then we’d quickly use PSExec to launch another connection to a different server. At times we could be creative and redirect him to a development server instead of a production server. He’d swear he was fixing something for a user, but since he was on the wrong server, the user didn’t see the item working correctly.

    We were sporadic in our efforts, only causing issues a few times a day when we felt the problem wasn’t too critical. Eventually my manager realized what a few of us were doing and had us stop.

    It was a bit mean, and not something we should have done maliciously. I was young, and let myself get irritated. In later years, I out grew some of this childishness and limited jokes to people that I genuinely liked, changing settings, altering wall paper, creating aliases that pointed to different systems, and even unplugging people mice and connecting my own in an adjacent cube.

    Joking around at work can be fun, but remember that it shouldn’t be malicious and it can’t prevent people from getting work done. We certainly don’t want to get someone fired, as much as we might like to at times.