Voice of the DBA

Author: way0utwest

  • 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.

  • SQL in the City – US 2012 Tour

    SITC_headerLast year I had the pleasure of speaking at two SQL in the City events: London and Los Angeles. It was a great time and I was hoping we’d do more events this year.

    We did, with 2 events in London in July of this year and now we’re about to embark on the US portion of our 2012 tour. Over two weeks in September and October the Red Gate crew, including myself and Grant Fritchey, will hit five cities.

    At each event we’ll have a few special guests speaking, people like Adam Machanic and Brent Ozar. The line up changes slightly in each city, so check the agendas.

    We also added another event on Nov 5, 2012, in Seattle, just before the PASS Summit. If you’re planning on going to Seattle that week, think about joining us on Monday for a free day of training.

    All these events are free, and I’m looking forward to them. I wrote a post about my views for each event, and you can check those out if you are interested. If you want to run with me, I’ll be up early in each city on the day of the event, and sometimes the day before.

    This is a free event. FREE to you, with lunch provided, snacks, and a refreshing beverage at the end of the day.

    If you are in any of these cities on this date, I’d be happy for you to attend and shake my hand.

  • 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.

  • The DevConnections Schedule is out

    F12_Web_Interior_SQL_Randal

    It’s preliminary, but the fall 2012 SQL Server Connections schedule at DevConnections is out. I’ll be speaking Tuesday, Oct 30, 2012, along with Grant Fritchey (b | t), on the SQLServerCentral track.

    This is traditionally the “Microsoft day” where sessions are all presented by Microsoft, but this time we’re providing an alternative to those of you attending the conference. I’ll be presenting a session on searching binary data with Full-Text Search and semantic search along with a session on Policy Based Management.

    I’m looking forward to the show, and hope to see some of you there.