Voice of the DBA

Tag: disaster recovery

  • The Chance of Failure

    I’ve always worked on the notion that my hardware rarely fails, and while I protect it with backups RAID, etc., I don’t expect failures. That seems to be how most of the RDBMSes are structured, with this idea that things will work well and we have protection mechanisms when they don’t.

    Contrast that with the way Google viewa the world. To them,failure is inevitable at scale, as noted by  Jeremiah Peschaka in The Promise and Failure of Federated Data. At large scales of deployment, Google and other companies assume that there will be a percentage of failures and they have to account for them. This is the same type of accounting that restaurants use (spoilage) and retailers (shrinkage) use for allow for some amount of loss.

    In technology, we account for potential failures with RAID, with HA or DR technologies, and hopefully with substantial testing to ensure that we have properly accounted for potential failures. However it seems that most technology people account for failure as a possibility and not a probability. Many people seem to assume that a serious disaster is not likely in their career.

    I think that a catastrophic, we lost the whole data center, event is unlikely for most of us. As Hurricane Katrina and the recent earthquake in Japan have shown, that is possible. However it’s unlikely for most locations, which is a good thing.

    Failures are inevitable and whether it’s a disk corruption, a server crash, or a building power failure, we have to assume we will experience one and plan for the event. We also have to expect hardware will fail, which means regular checks and monitoring to detect these failures as soon as possible.

    Hope for the best, but plan for the worst.

    Steve Jones

    The Voice of the DBA Podcasts

  • An Overview of SQL Server AlwaysOn

    One of the changes coming in SQL Server v11 (not sure what the name will actually be), also known as “Denali”, is the addition of more High Availability/Disaster Recovery Options. When I first heard about this, I was excited, but the public CTP had limited support for it. I’m hoping the next CTP will substantially improve the feature and this makes it to the RTM.

    In the meantime, here’s a Channel 9 video from Justin Erickson that gives a short explanation of how this works and how it compares with the current Mirroring/Log Shipping/Clustering options.

    SQL Server AlwaysOn

  • Avoiding Logging

    I can avoid this kind of logging, but not SQL Server's kind.

    As I have been studying more about SQL Server internals this year, one of the myths that keeps being debunked is the idea there are operations in SQL Server that are not logged. That’s not true as everything you do in SQL Server is logged to the transaction log in order to ensure that SQL Server remains ACID compliant and cannot end up in an unrecoverable state.

    I’m not sure where this myth started, but I suspect that some version of the telephone game is at fault. I constantly see people asking for a way to insert or delete data from SQL Server without affecting the transaction log. One of these wish list requests likely got transformed into an imaginary feature that many people think has to exist in the product. Surely there is the capability to not log things if they are deemed unimportant.

    There isn’t, and you can’t, and I’m not sure that I’d even want this feature. Logging introduces overhead, and it can slow down processing, but it also provides a tremendous amount of safety and security. Computers will crash, power will get turned off, and hardware will fail. Mr. Murphy will ensure that one of these will occur while a large import of some sort is taking place. I don’t know how the rest of you feel, but personally I would prefer that when my database is restarted, I can be sure that my data is in a consistent state. Transaction log logging ensures this is the case in SQL Server.

    We often make decisions based on the data sets we have, and for the most part we want to be sure that all the data we added, updated, or removed from the system is in a known state. We do not want to accept partial transactions being recorded. We need to be sure that every debit into an account is matched up with a credit out of another account. Too many people seem to think that either their systems will never crash, or that this reliability can be guaranteed without logging.

    Accept the overhead of logging, and be glad that it’s unavoidable. At some point in your career, I’m sure you’ll be grateful.

    Steve Jones

    The Voice of the DBA Podcasts

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