Voice of the DBA

Category: Editorial

  • Patch Problems

    I ran across this article a week or so ago, but hadn’t had a chance to put anything out. There were three patches put out in July for various products that caused issues with other software, one of which was SQL Server.  can cause issues with SQL Server 2012, though it looks like the patch was pulled. Be careful if you have administrators that tend to apply the monthly security patches.

    Overall, despite the tone of the article, I’m not sure how bad this is in terms of patches. While the errors are problematic and annoying, I’m not sure these are critical issues. These aren’t causing reboots or re-installations of Windows. I’ve certainly seen worse patches released, though not in quite some time. The most disturbing item in the piece was the fact that the Windows 8/RT servicing stack update cannot be uninstalled. That’s a bit of an issue, and it concerns me as we move towards a more automated, bulk patch process.

    It’s one thing for me to uninstall an application on my phone and reinstall a patched one when there’s an issue. I’ve had this happen, with vendors releasing a new version in a day or two (or for all I know, the old version), that I can reinstall. It’s quite another thing for a large vendor like Microsoft to release a patch that cripples large numbers of devices. It’s easy to pick on Microsoft, but imagine Apple, Verizon, Dropbox, etc. releases a version that crashes machines or devices. It might be significantly harder to even reconnect these devices to recover from patches that crashed core, kernel level software.

    Software has bugs, and it will always have bugs. Patches will always be needed, and IMHO, should be included as part of some warranty for digital goods. However I think patching needs to be considered at the beginning, with installation and removal, as well as user option-to-install, built into all software for sale.

    Steve Jones

    Video and Audio versions

    Today’s 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.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 17.5MB) feed

    MP4 iPod Video ( 20.8MB) feed

    MP3 Audio ( 4.2MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Review Your Code

    I hope that SQL Injection becomes a disease of the past at some point in the future, one that is eradicated from the world except for very rare, isolated cases. However that’s not the state of the world now, and probably not what we’ll see anytime soon. I don’t often see large scale attacks, but I wasn’t surprised when a piece from Denny Cherry appeared recently.

    What was disconcerting was the attack he referenced, which was automated and self-spreading, but injecting code into hacked sites that more and more users would end up with code that joins their system to a botnet.

    What’s worse? Most virus detectors didn’t pick up the code.

    What’s really, really bad? Bored hackers, criminals, or anyone else could get details of the exploit on the Internet and start searching for injected machines they could easily alter or take control of in their own creative way.

    In Denny’s piece, he gives advice that’s easy to follow, and shouldn’t delay development time. Most developers could easily build templates to use when writing queries, or formatted the parameterized queries. Not doing so is laziness or ignorance, and it’s dangerous.

    It’s 2013. I’d say that if you write code after today that’s susceptible to SQL Injection, you ought to be fired. Plenty of people would argue that if you’ve written code in the last couple of years you should be let go, but I’m offering amnesty. Go buy Denny’s book. Go read about secure coding. Learn how to write code that doesn’t make this kind of attack easy.

    Steve Jones

    Video and Audio versions

    Today’s 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.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 14.6MB) feed

    MP4 iPod Video ( 17.9MB) feed

    MP3 Audio ( 3.6MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Would You Choose SQL Server?

    I recently wrote a piece on the limitations of the Standard Edition (SE) of SQL Server and got an interesting comment from Brent Ozar. He asked me a question as a businessperson that I found intriguing and it’s one I thought might be worth thinking about it a bit.

    Imagine that you are a manager or director or a firm, or even the founder/owner of a small startup business. You are looking to build some application. Maybe you’ll sell it, maybe it’s a service you sell on the web or with a mobile application. You have people that are good .NET developers, and hopefully a DBA, and you need to choose a database to store data and allow you to run reports. The database is important to the application; no flat files or XML stand-ins. The question Brent asked me, and I’m asking you is:

    Would you use SQL Server?

    Before you answer, remember that you need to buy 4 cores worth of licensing for SQL Server. For Standard Edition, that’s $8,000 at list price. You might find discounts, but since an SE-maxed out, 64GB RAM server can be had for a little over $2,000. If you needed a second server, those prices double. If you want more than 4 cores (8 are common in many servers), the cost goes way up.

    I think SQL Sever is a fantastic product, but it can be expensive. Back when SQLServerCentral started, we considered MySQL or PostgreSQL as alternatives, strictly because of licensing. $10k for software licensing is a lot for a small company, and it can substantially impact a budget. However the cost of working with another platform might be significant as well. A developer can cost more than $10,000 a month, and if you lose much time in building your software (or administering the server) because of the platform, that $10k in licensing costs could evaporate quickly.

    As much as I like SQL Server, and I’d like to use it, I’d consider alternatives such as PostgreSQL for a simple, core database back end. That’s if I weren’t tackling any problems that needed subsystems like SSIS or SSRS. The more features I’d use in SQL Server, the more likely I think the licensing isn’t a huge cost. However when budgets matter, and you have staff that won’t be overly challenged in managing other platforms, I’d consider another platform with the high, per core cost of SQL Server.

    Steve Jones

    Video and Audio versions

    Today’s 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.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 20.4MB) feed

    MP4 iPod Video ( 24.3MB) feed

    MP3 Audio ( 4.8MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Balloons and Data

    We see a lot of questions at SQLServerCentral repeated over the years as workers new to the platform encounter some of the issues that many of us have dealt with repeatedly over the years. One of the more common questions that I see in the SQLServerCentral forums has to do with tempdb growth.

    Many people coming to the SQL Server platform realize tempdb is a workspace, but they don’t always understand how it works. Many times I see questions where people don’t understand why tempdb will grow from it’s default size. Even more surprising is that they don’t understand why it doesn’t shrink back to the default size. After all, it contains temporary information, and when it’s not being used, the size should shrink, right?

    If only that were true, it would make administration simpler, though performance might be worse. Many people view the files in a computer like balloons. We add data and they grow. We remove data, and they shrink. However that’s not the model for SQL Server files. Our mdf/ldf/ndf files are allocations, and once we allocate space, we don’t remove it if no data is present. The allocations are available for the next time we need them, minus the time we spent requesting and receiving the allocation from the Operating System.

    The space you need for tempdb is the peak space you need for the largest set of temporary operations in your workload. Even if all your data sets are small, say 100kb, if you have 1000 of them occurring at once, you’ll need 100MB of space. With sorts, intermediate worktables, and more, you could easily have an average data set above 10kb, which is why your tempdb size might need to grow.

    Just like with any other database, you need to monitor the size and load for tempdb. Adjust it as needed, based on your requirements, so that it will be properly sized each time to start the instance. The administration level isn’t high for tempdb, as long as you have monitoring in place and you periodically perform the administration to appropriately size your system.

    Steve Jones

    Video and Audio versions

    Today’s 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.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 14.9MB) feed

    MP4 iPod Video ( 17.7MB) feed

    MP3 Audio ( 3.6MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center