Voice of the DBA

Category: Editorial

  • Data Worms

    The FLAME malware
    Are we going to see more and more targeted cyberwarfare attacks in corporations? I wouldn’t be surprised.

    Effective data administration include backups. I would argue this is the most important part of managing your data since no matter what happens, backups give you the ability to recover your system. Whether it’s an accidental data modification by a user, a hardware failure, a natural disaster or some other event, having a copy of your data (or log) on some other system or media can be the difference between getting back to work and having to go find other work.

    For the most part we’ve been concerned over disasters that are random, and while they may be destructive, their effect is usually limited in scope. SQL injection attacks often affect a single system, and with a good backup, you can usually recover your data quickly. However that may be changing as the world grows closer together.

    The Shamoon malware has been causing problems lately and making companies rethink their incident response. The worm has wiped workstations and destroyed data. Destructive software is nothing new, but as more and more cyber warfare takes places at the government level, it’s likely that retaliation might target civilian targets, especially successful companies. I’d hate to think that destructive malware might target databases, but I’m sure it will. The SQL Slammer worm was a complete disruption of our database services for days at JD Edwards almost a decade ago, but it could have been much worse if that malware had been written to be destructive.

    We don’t have default names and passwords in SQL Server, but we should make sure all accounts have strong passwords. There’s also some value in not configuring all systems identically. It makes management easier, but it also makes a successful attack that much more successful.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Dress Like Steve

    I hate wearing suits and ties. One of my early jobs in technology required them, and my least favorite part of that job was the dress code. Almost as bad was a company that required a uniform: same pants and shirt every day. I didn’t mind a few jobs that required khaki pants and a collared shirt since I could have a little variety, but my ideal job, which I have now, lets me wear what I want. T-shirts, shorts, sandals, jeans, and more are acceptable in my office.

    These days when I put on a collared shirt, it’s usually one with with design of some sort on it. I have a nice collection of colorful shirts, and I often wear them to events. Can you find me in the picture below?

    SQL in the City Staff
    One of these things doesn’t look like the other…

    As we were planning the US tour of SQL in the City and talking about things we might giveaway, someone suggested adding a few shirts to the list of books, pens, balls, etc. I thought that if I were to give away some cool SQLServerCentral shirts to attendees, I ought to make sure that I was modeling one of the prizes all day. My boss agreed, and I got permission to go shopping.

    At each of the US SQL in the City tour stops, I’ll be wearing a new Hawaiian shirt. At the end of the day at each event, I’ll also be giving away 3 of the same shirt to three lucky attendees. You can’t win one if you don’t come, so if you are in any of the cities we are visiting, be sure to register and come get a free day of presentations from Grant, me, and a number of other speakers. I’ve got a series of blog posts on the events, and if you want to run with me in the mornings before an event, drop me a note on Twitter.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Compress Everything

    zettabyte
    Suddenly a TB doesn’t look so large.

    We are gathering more and more data all the time. There’s no end in sight, and even as storage becomes more dense and cheaper per GB, we are needing more and more of it all the time. I saw a note recently that estimated in 2011 we gathered 1.8ZB worldwide. Not TB, not PB, but ZB. That is crazy. There are estimates that say some industries have more data per company than the US Library of Congress.

    Our own databases are constantly growing, and even though many of them are relatively small, we keep multiple copies of the data. We have production, we have test, we have multiple development copies. Some companies have UAT, some have customer service environments. Overall, we may have a lot of data in our companies that’s redundant, but necessary.

    Managing all this storage can be a hassle for DBAs. It can be a pain for developers that need more drives for their environments. It can lead to arguments with SAN adminstrators for those servers that need additional storage to match production. Time becomes a factor as well when looking to restore, copy, move, or just query the systems.

    An obvious solution is compression. There is data compression built into SQL Server, which works well in some data distributions. Third party products exist to compress backups, or even whole databases. Virtual restores can eliminate the need to have enough space for a backup and the data expanded in an MDF. There are solutions out there, and often they can return a very strong ROI against their costs.

    If you have a storage crunch, take a look at the various third party products out there. You might something that makes your job easier, and perhaps even gets the SAN administrator to smile.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Three Rules for Database Development

    shared database development
    Do you have rules for database development?

    I’ve always followed a few maxims over the years that have guided me well. One of those is that we must all agree on how we are going to perform any process and then all work that way. We can define whatever standards, rules, frameworks, processes, etc. that the group wants, but once we decide, we all need to work along in the manner we’ve prescribed. That’s worked well for me, and when everyone follow the rules we’ve agreed on, things run smoother.

    I ran across this post on three rules for database work from Scott Allen, a developer that has a lot of experience writing software. The three rules are never use a shared database server for development, always have an authoritative source for your schema, and always version your database. The last two rules are things I’ve always followed in the past since I think these are extremely important for maintaining control over the environment. Not control as a way to ensure developers are hamstrung, but control in that at any point in time you are aware of the state of the database.

    The first rule, never using a shared database, isn’t something I’ve usually done. Most of the time I’ve worked with small enough teams that people are working on separate sections of the database, and they almost never run into any conflicts with each other. A shared database server means changes from one person appear almost immediately to others is valuable. It allows development that is dependent on other changes to take place right away. That was in the past. These days with a tool like SQL Source Control (or custom scripting), you could simulate this on separate databases for separate developers.

    As with most rules in the database world, I think the answer to whether you follow these particular rules in your environment depends. It depends on what your resources are, your needs, your team structure and more. You can choose the framework that works best, whatever it is. You just need to make sure that everyone works within whatever you decide.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.