Voice of the DBA

Tag: syndicated

  • SQL Saturday Advice – Speaker Communication

    Recently I was at an event and a speaker wasn’t able to make a session. There was a minor scramble, and the session ended up being cancelled, which is fine, but it got me thinking about what I would do if I had an emergency.

    I don’t always have the contact information for organizers, and it’s not easily available. In some cases, I’m not sure how I’d get in touch with someone. I usually have an email, but not always, and I think my emergency solution would be to “tweet” that I wouldn’t be there with the hashtag for the event and hope someone picks it up.

    However I think there’s a better solution. In the speaker communication the last week before the event, let all speakers know that they are expected to meet their commitments and give them 2 or 3 phone numbers to call for issues. Make sure those people keep their cell phones handy and can respond.

    I’d also be sure you have address, phone, and map links for all the locations for speakers. I know most should be local, but spending a few minutes including links in the emails will help ensure that speakers have a smooth event and are happy to come back again.

  • Common SQL Server Mistakes – Equals NULL

    One thing that I don’t see a lot, but it still happens with people new to SQL Server is the comparisons they’ll make with NULL values. Often those people new to T-SQL will write this:

    select CustomerID, CustomerName
    from Customers
    where SalesRepID = NULL

    The thought here is they are looking for those customers that don’t have a salesrep assigned. Or they might enclose the NULL in quotes, but this won’t work.

    The correct way to do this is:

    select CustomerID, CustomerName
    from Customers
    where SalesRepID Is NULL

    Note the “Is NULL” that will correctly return those customers who have a NULL value stored in that column.

    Why?

    NULL is an unknown value. We just don’t know what value it is, so it’s not a variable in algebra like “x”. In algebra, x=x, but NULL != NULL. Since we don’t know what the value is, and since each row could potentially have a different value (remember every NULL’s value is unknown) we can’t expect any NULL to equal any other NULL.

    NULL isn’t a placeholder like a blank or space, or even zero. It’s an unknown value, so equals (and not equals) does not apply. Instead you need to use “Is NULL” or “Is Not NULL” for your comparisons.

  • Google Wind

    transmission_270x229[1] I’m not sure Google is a better company than Microsoft or some of the other extremely large companies that get caught up in dominating a market. However they are engaged in some interesting projects, and I have to think that the founders, or someone high up in management is really looking to solve some problems in the world.

    Google is funding a power backbone for offshore wind farms. Essentially an undersea cable to carry electricity from offshore windmills. IT looks like it will go from near my hometown of Norfolk up to the New Jersey/New York area.

    I’m not sold this is the best way to get wind power from the coasts, but it’s worth trying. I worry about the issues of the ocean damaging the equipment over time. I’d love to see more installations along the Eastern Shore first, maybe vertical windmills that might not harm birds.

    I’m glad that Google is willing to make the $5B investment in it and try to jumpstart some offshore farms. Especially as we use more and more power for these digital devices. I know there are some nice coast guard installations about 7mi offshore that I used to dive near.

  • T-SQL Tuesday #12 – Misconceptions

    TSQL2sDay150x150 It’s time for T-SQL Tuesday again, and I’m happy to participate again. This is a monthly blog party started by Adam Machanic (Blog|Twitter )that asks people to write on a particular topic all on the same day.

    This month’s theme is misconceptions in SQL Server, hosted by Sankar Reddy. You can read the rules for the party and get information from his blog.

    The Most Common Misconception

    I read a lot of forum posts, literally hundreds a week on all topics in SQL Server. One thing that I consistently see asked is the dreaded:

    “My transaction log has grown so large it filled the disk”

    That’s a common occurrence, too common in my opinion, and while there are people that forget to setup any backups, I also find in the majority of cases people just don’t understand one thing:

    A full backup does not clear the transaction log.

    Too many people assume that the log will get managed by a full backup. It doesn’t. While some log record get included in a full backup, they do not get marked as “backed up” and the space re-used.

    If there is one thing that I wish everyone managing a SQL Server knew, it would be that they need to make full and log backups to properly manage the disk space usage by their logs.