Voice of the DBA

Author: way0utwest

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

  • Are There That Many GUIDs?

    Do a lot of people actually use GUIDs as Primary Keys? I haven’t used them much, and I would have thought that more people chose identity keys. It seems that most of the demos and examples I see from bloggers and speakers are constantly using identities.

    However an informal survey from Peter Bromberg showed that four times as many people actually had GUIDs as their primary keys. The blog actually says that GUIDs are not a good choice, but I’m not sure I agree with that. You can use sequential GUIDs, and you can avoid making them the clustered key, so I think they can work as well as anything.

    There’s nothing inherently wrong with GUIDs, and they should be unique across all of your rows. There have been some reported cases of duplicates, but for most practical purposes, especially in database work, you ought to be able to count on a GUID as unique. They even have the nice capability of being generated by clients, removing the need for an extra round trip when a client needs to insert multiple rows.

    I typically don’t use them because they’re long, hard to remember and type, and hard to view on the screen. I can’t easily compare rows in multiple tables, and it’s easier for me to work with integers.  I don’t recommend them, but if you are going to use them, be sure you understand the pros and cons, and use them appropriately.

    Steve Jones

  • Downtime

    Someone sent me a note recently asking about how to handle unexpected downtime. In an editorial I mentioned that a 7TB database isn’t that large, and this person told me that they had an issue with a 1TB database and running DBCC resulted in a 4 hours of unexpected downtime. The person asked if small businesses needed to accept downtime for serious maintenance.

    I think that it’s rare you run into DBCC issues that require downtime, but when you do, then that downtime is needed. I’m not sure what else you can do since DBCC repair issues often indicate some fundamental hardware issue. I suppose that you could move to new hardware, but you still need to ensure that your database is intact and working.

    A restore from backup might be quicker in these situations, but that will requires some downtime, and it’s something that you have to live with. We still have systems that will fail and need rebuilding, and probably always will.

    I know some companies can afford redundant hardware and failover to secondary systems when they need to check their primary servers. A second copy of the database may or may not allow you to continue to function if you had corrupt pages on your primary, depending on how the data is moved over.

    Most of us, however, just have to live with downtime. If anyone has other ideas or stories on dealing with unexpected maintenance downtime, I would be interested in hearing them in the discussion below.

    Steve Jones