Voice of the DBA

Author: way0utwest

  • 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

  • Disaster Recovery Docs–Offsite

    Years ago I worked at an ISO certified organization, where we took our administration and planning seriously. We ensured everything was backed up, we had backup drills, we each practiced recovering systems, loading tapes, even calling the company that rotated our tapes from an offsite location.

    One of our administrators was very conscientious and documented everything. He had screen images, copies of vendor documentation, all linked and labeled in a great folder on our network. We used this documentation constantly while restore systems from mistakes or drills and updated it regularly. It contained vendor contact information and account numbers. Each of us could access is remotely, and I had used it a few times from home while working on a problem with a system.

    One day our auditor came in and in the course of examining our details remarked on the comprehensive documentation and said it was great. Then he reached over and turned off our very detail-oriented administrator’s monitor.

    “Now show me your documentation,” he said.

    Our administrator was a little shocked. All the documentation was on the network. We’d accessed it from home. We accessed it from other corporate locations. We had restored it from tapes.

    We’d never thought it would be unavailable.

    It was a sobering lesson, one that had interns printing off copies that afternoon, dating them and binding them into books, one of which was always rotated offsite to the tape vendor’s facility.

    As for the tape vendor information itself? After overcoming his embarrassment, our administrator made wallet sized cards with the vendor company, phone number, address, and account number. He laminated those and gave us each one to keep on our person at all times.

    Make sure you have copies of the stuff you need offsite. It’s easy not with the “cloud”, though you better secure the data with encryption and limit the key access to a few people. You never know what you’ll need to recover, but you never should  find yourself in a position of not being able to recover your documentation.