Voice of the DBA

Tag: syndicated

  • A SQL Azure Customer

    Not me, though I’m not necessarily against Azure in principle. I had a friend ask me for a SQL Server hosting provider the other day, saying they had built a web front end, and had a web host, but were thinking to separate out some data to a separate provider. I have no idea why, or what this was.

    “Have you looked at SQL Azure?” I queried?

    He responded to say he was embarrassed to say he didn’t know what Azure was. I told him that I wasn’t completely sure myself, but it offered SQL Server almost as a web service, and it might work for him.

    “$9.99/mo for a 1GB database? I’m in” was what I heard a bit later. I did caution him to be careful of transactions and transfer. Test locally was my advice.

    We’ll see how he likes it. I’ll follow up in a few weeks and see what he thinks.

  • Backing up the log in simple mode

    Someone posted a note saying that their backups were really large and slow. So they were trying to manage their backup scheme and ensure some level of recovery.  I was going back and forth, along with others, talking about the way your recovery would go and the merits of that particular backup scheme. While posting, the person mentioned at one point that his databases were in simple mode.

    Huh?

    AFAIK, or rather, As-Far-As-I-Remember, you can’t do a log backup in simple mode. I think that’s been a part of the product, but before posting, I decided to test.

    Short answer, if you don’t want to read, is that you can’t backup a transaction log if the database is in simple mode.

    First I grabbed a sample database on my local 2008 instance and set it to simple mode. Actually, first I had to set a database to simple mode, and I didn’t want to use the GUI. This isn’t something I do often, so I had to look up the syntax:

    ALTER DATABASE SET OPTIONS – The first example shows setting to full recovery mode.

    ALTER DATABASE db2 SET RECOVERY SIMPLE

    Once this was set, I created a few transactions and ran a backup.

    CREATE TABLE MyTable (id INT)

INSERT MyTable DEFAULT VALUES
    BACKUP LOG db2 TO DISK = 'db2_log_test.trn'

    This gives me the following error:

    Msg 4208, Level 16, State 1, Line 2

    The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE.

    Msg 3013, Level 16, State 1, Line 2

    BACKUP LOG is terminating abnormally.

    This is what I expect, as there is no backup chain that can be used to build a backup. What about running a full and then a log right away?

    BACKUP DATABASE db2 TO DISK = 'db2_db_test.bak'
BACKUP LOG db2 TO DISK = 'db2_log_test.trn'

    Once again, the error occurs, and there should be no checkpoint after the full backup starts.

    db_simple_log

    So I think that my posted is mis-informed of his environment, which is a dangerous place for a DBA to be, especially with regard to backup and recovery.

  • Coming to SQL Saturday #60 in Cleveland

    It’s just a couple weeks away, on Super Bowl weekend. I can’t believe this is event #60, still in shock that this amazing franchise has grown to large.

    I’ll be at SQL Saturday #60 in Cleveland on Feb 5, 2011, with my good friend Allen White (blog | @SQLRunr), talking about building your brand and the Modern Resume. There are lots of great speakers joining me there, including Aaron Bertrand (blog | @aaronbertrand), Mike Walsh (Blog | @Mike_Walsh), and more.

    I’ve never been to Cleveland, so I’m looking forward to the trip. I don’t know how much time I’ll have to see the city, arriving Fri afternoon and leaving Sun afternoon, but I’m going to try to do something. I know there’s a Sun morning run being set up somewhere, and I’m looking forward to that. It should be about say 879 for me then, so plan on joining us for a short, slow, 2-3 mi one that morning if you want.

    Hopefully I’ll get home in time for the Super Bowl Sun night, but if not, I’ll have it on the DVR and I’ll catch up on it Monday.

  • Disk Partition Alignment–MCM Prep

    Does disk partition alignment matter to SQL Server? Without a doubt. When new disk partitions are created, there could be a reserved set of sectors that could differ across disks because of the way that the hardware interacts. In the white paper, Disk Partition Alignment Best Practices for SQL Server, there is an image that helps to explain this:

    Starting with Windows 2008, the disk partitions are automatically aligned to help improve performance. In a decade, it is unlikely that this will be a problem for most systems as most of the installed systems will be running Windows 2008 or later, at least for SQL Server.

    However now there are still lots of Windows 2003 and Windows 2000 systems out there at this time. For those systems, they could be experiencing a degradation of up to 30% according to the testing done by Microsoft. Which means that you can get a quick performance improvement in your systems, if they are disk I/O bound, if you can realign partitions.

    How can you do this? The hard part is that you must move everything off the partition (all data), delete, and then recreate the partition and restore data. That can be a time consuming exercise, but it is really a time effort. It doesn’t cost anything if you have extra disk to hold your data and can handle the downtime. In the white paper, there is a section that explains how to align your partitions in Windows 2000 and Windows 2003 using diskpar.exe and diskpart.exe, respectively.

    Note that this is mentioned in another white paper on SQL Server Best Practices. This gives you a number of I/O related pre-deployment best practices that you ought to consider before installing SQL Server on your systems. If you are building a system of any importance, this is a great article to understand, and apply many of these practices before SQL Server is installed.

    This can cause a delay in the deployment of a new server, but performing these tests and establishing a baseline cannot be done later, and discovering potential problems early can help you to build a better performing server from day one. Finding these problems later will ultimately result in way more embarrassment and hassle than implementing a short delay before deployment.

    If you have a group of people responsible for installing Windows and possibly SQL Server as part of your build process, have them review the article, or even give them a checklist that will help them to incorporate this testing and benchmarking into their routine.