Category: Uncategorized

  • The SQL Rally Logo Vote

    I like way that the SQL Rally is being run. Having the community interact with the organizers and try to pick a logo is a great idea.

    The final votes are being taken now, so check out the designs, and vote.

    My pick is this one:

    Speedometer%5B5%5D[1]

    That’s one of the ones I voted for in the first cut of designs. I favor a clean, simpler design, especially one that will look good on a shirt or mug.

    However pick the one you like and cast a vote.

  • SQL Saturday Advice – Keynotes

    Continuing on with my Thursday series of SQL Saturday posts, this time I wanted to talk about keynotes.

    I’ve been to a few events in my time, and one of the things that seems to get many people going in the morning is the keynote session. Even crappy ones, and we’ve had some amazingly crappy ones at the PASS Summit, still manage to get a large turnout.

    Not every SQL Saturday will have a large space to hold a keynote, but you can get creative and casual. If it’s good weather, hold it outside. Note to Patrick LeBlanc, Baton Rouge in August DOES NOT have good weather.

    If there’s a large foyer, have one there. You don’t need a formal room, tons of AV, etc., just a place where people can sit, sip some coffee (or tea, as Brian Kelley would do ), even if they are on the floor or standing, and someone is speaking in the round. Just work with the speaker to manage their expectations.

    I think this is a great way to open the day, and there are some really interesting people in the SQL community that can entertain people for 15 or 20 minutes. They can set the stage for the rest of the day, make a few announcements, and kick the event off right. You don’t need a Steve Ballmer to have a good keynote.

    I’d suggest that you pick one of your good speakers early on and ask them to give a short keynote, no slides, to open your event. I bet most of them would be thrilled to do so. I know I was honored to do so in Charlotte and am looking forward to doing it again in Baton Rouge.

  • Does Column Order Matter in SQL Server

    The short answer is it doesn’t. I guess that’s the long answer as well.

    A few people have posted questions about whether the PK needs to be the first column, and does it matter if you have CHAR or VARCHAR together, should integers be first, etc.

    It doesn’t matter. Fixed width data is stored first, variable length is offset from the end of the page, and LOB data is either in row with variable data, or on another page.

    However since the server reads a page at a time, and has to rip through the row to get the next row anyway, it doesn’t matter where you put the data in design.

    I tend to put the PK first, but I have done things like put a datestamp first, just to make it easier to read when I query the data.

  • SQL Server Backup File Confusion – Log Shipping

    I saw a post recently where a person working with SQL Server had log shipping setup. They were asking if they needed to run separate backups for their database in order to restore this server in the event that it failed. It took a few posts to understand this since it never occurred to me anyone would be confused about this. Maybe it’s because I remember when log shipping was something you had to build, not a wizard or feature of SQL Server.

    There is nothing amazing about log shipping. Nothing special. The “feature” as it’s implemented in SQL Server 2008 is designed to automate and make the process of restoring log backups on another database easy.

    Log shipping is a simple process:

    1. Take a full backup from DB1
    2. Restore the full backup to DB2 with norecovery or standby
    3. Take a log backup on DB1
    4. Restore the log backup on db2 with norecovery or standby
    5. Repeat steps 3 and 4

    That’s it. That’s what is involved, and you can easily do this manually. You set script jobs to do this, or you can use the wizard in SQL Server 2008.  You can also set delays between steps 3 and 4 that give you the chance to recover data that might accidently be changed or deleted on the primary server.

    However you enable it, the backups  (full and log) are normal SQL Server backups. You can use them to restore on the primary database, just as they’re used on the secondary database.

    One last note, you can log ship to the same server instance if you like. You might do this to have a customer service or test instance on the same hardware. Or you might do it to keep a second, delayed copy of your development database to roll back changes.