Voice of the DBA

Category: Editorial

  • Happy New Year 2016

    Happy New Year from everyone here at SQLServerCentral and Redgate Software!

    I do hope you’re not working, and enjoying a start to 2016. If you do happen to read this, I hope you are relaxing and have a big smile on your face.

    This year we’ve got a new version of SQL Server coming, and I’m sure lots of exciting new technologies we’ll see released. It’s a new beginning, and a chance to move forward. With that in mind, a simple question today.

    What new technology, language, or skill do you want to improve in 2016?

    Today is a great day to make a resolution and start growing your skills, for fun or profit, in 2016.

    The Voice of the DBA Podcast

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

  • The End of 2015

    I’m off on vacation, so I won’t be able to respond, but I decided to take a few minutes and look back at 2015 before leaving for the year.

    This was a year that seems to have been marked by lots of data loss and breaches. Certainly these were on my mind as I worked on the SQL in the City keynote, but as I’ve been following Troy Hunt, it seems that every week or two he’s uploading more data to HaveIBeenPwned.com. We had some larger ones, with tens or hundreds of millions of account records released. Despite all the press from the Sony hack over a year ago, it seems that few companies have bothered to update their security. In fact, it seems that until they’re hacked, no one bothers to fix fundamental security issues in their systems. Perhaps some companies are doing so in the background, and aren’t being attacked, but I’m not so sure.

    We didn’t have any SQL Server releases this year, but we had lots of news, and an unexpected Service Pack. Service Pack 3 for SQL Server 2012 appeared out of the blue for me. I hadn’t seen much news on it, and had given up on bothering Microsoft about new SPs for versions. Perhaps they’ll continue to build these yearly for supported versions, which is what I hope, but we will see. It does seem that Cumulative Updates have been appearing regularly, with relatively few issues in them, but I’m still wary of using those as the main patching mechanism for critical servers.

    We did have a lot of growth in the SQL Server space, with many features being announced and starting to take shape. If you’re looking to get up to speed, check out our collection of Learning SQL Server 2016 topics, where we try to keep a growing collection of links to help you learn.  I am excited to see some of the growth of SQL Server to include newer features that people want in their data platform. I’m also glad that things like Stretch Database can be used to help manage the ever growing amount of data we have. Of course, encryption is big on my list, and Always Encrypted is something I am hoping gets lots of adoption.

    We’ve also seen Microsoft really pushing the envelope in terms of data analysis. There is a constant set of articles and blogs written about data scientists, and some of us are moving to learn more about how to better analyze data. Microsoft continues to help, with their forays into Machine Learning, the expansion of the Power set of products (Power BI, Power Query, Power View, Power Pivot, etc.), R language integration, and more. I suspect that more and more of us will get the chance to play with some interesting data analysis tools if we want to. Even if you don’t use those to help your business, I have already seen these tools being used to perform index analysis, DBA monitoring, and more. I’d urge you to let your imagination run wild and see what things you might build.

    It does also seem that more companies are starting to realize that their data and its integrity and management are important. Data professionals are becoming more valued, but the skills required are growing. There are more and more services and tools to help us manage systems that I do think the simple DBA that administers backups and security is really on the decline. At some point, our employers will demand more.

    It’s been a good year, and I look forward to 2016. If there are things you want us to help you learn about, leave a comment here, and I’ll review them when I get back from vacation. Have a safe, Happy New Year, and I’ll see you in 2016.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Sharing Code

    This editorial was originally published on Jan 25, 2011. It is being re-run as Steve is on vacation.

    It seems that almost every week I encounter some form of plagiarism it the SQL Server community. Whether its from SQLServerCentral or it’s someone else, it seems that I’m either alerting someone or sending my own takedown notice.  It’s a little sad that I have to even explain the morality of re-publishing someone’s else’s content without giving them credit to anyone over 8 years old, but apparently I do. However this isn’t a piece about plagiarism.

    I have seen people take various additional steps to protect their content, and that’s fine. It’s their right, and I understand that some people derive a level of income from their work. Whether it’s direct or indirect, it doesn’t matter. If someone wants to protect their work and they don’t want you to reuse it, then respect their wishes. If not for legal reasons, for moral ones.

    As we publish information on the web, however, I would think most of us hope our code and ideas are adapted and re-used. Not used in another publishing piece (blog, article, etc.), but used in a piece of production code that makes a system run better. I know when I’ve published code that helps someone track backups or monitor their servers, I was quite honored to hear that someone used my code in their system.

    Sometimes I wonder if  other authors out there feel the same way. Do writers assume their code will be rewritten by someone before it is used. Digital rights and intellectual property are immature fields, and I’m not sure how we ought to best handle the re-use of code. Authors have the right to decide how they want their works to be shared, and should publish their decision. I would hope that others out there would respect that.

    Steve Jones

  • Why Use the Principle of Least Privilege?

    This editorial was originally published on April 12, 2011. It is being re-run as Steve is away on vacation.

    SQL Injection is not the fault of the SQL Server. Brian Kelley pointed that out, and reminded me that SQL Injection isn’t an case of malformed SQL. It’s legitimate code, including SQL commands that we might use from any query connection, especially an administrative one. We regularly issue update and delete commands from our applications, and SQL Injection takes advantage of this to issue an update the we might not be expecting.

    Would you expect this input handwritten injection from an application? Or this table guessing attempt? You wouldn’t, but they can come through data entry in your application if the input isn’t well sanitized. Someone setting all your prices to $0.01 or all of your customers to “W3 0wnz U!” isn’t what you want to happen. You can’t necessarily prevent all of these patterns  or check for every permutation, but you can prevent things like ‘shutdown’ or ‘drop table’ from being run by your application. Even adding a new user to the database system isn’t something I would want to allow.

    Education is the key here. As Andy Leonard (blog | @AndyLeonard) would say, design patterns are important. When developers have an understanding of the issue, many of these things will be avoided. Having standard ways to begin building an application, checking for bad input, and setting up database users and permissions easily, should make this easy for anyone that wants to code against a database. We still have work to do here to build better frameworks, and ORM tools that require elevated permissions to the database are not the answer. They might become the answer, but they aren’t a better solution right now.

    Grant Fritchey wrote a nice piece about developers and DBAS, noting the need that we both have the same goals, but need to learn to communicate better.  This is one area where we ought to make an effort to communicate better, pass along education about security issues, and work to make life easier for developers to work with a database.

    That also means teaching them to work with the minimum privileges needed in order to make an application work, just in case someone plans on submitting some input you didn’t expect.

    Steve Jones