Voice of the DBA

Tag: Backup/Recovery

  • A Full Backup can Impact a Log Backup–MCM Prep

    In the early days of SQL Server you could not run a log backup while a full backup was running. In fact,you tried to schedule them apart from each other early in my career to prevent collisions. Nothing bad happens, but it does cause failures in your monitoring and those are annoying.

    In modern versions of SQL Server, you can run log backups and simultaneous full backups. They don’t collide or block each other, but there is a way that the full backup impacts a log backup.

    If you start a full backup, once all data pages are written to the backup device, the log records that were created since the start of the full backup are added to the full backup file. This allows the redo/undo process to complete and this gives you a full backup set that is intact as of the point in time in which the data pages finish writing.

    If you run a log backup, typically the log records are written out, and then the VLFs in the log file that were written to disk are marked as inactive.

    However since those log records are needed for the full backup to be complete, the log backup cannot clear those VLFs when the log backup finishes. That process still occurs, and technically this is part of the log backup, but it is deferred until the full backup completes.

  • SQL Server Recovery–MCM Prep

    I always have to think about what happens during the recovery process in SQL Server after a restore. I’ve always known the process as roll forward and roll back, which is how the items are noted in the SQL Serve error log. Transactions are rolled forward or rolled back.

    But which comes first?

    If you think about it, you want to roll forward the committed transactions, which were not written to the data files. Then you roll back the changes made to the data files which were not committed. How you get transactions in these states is for another day.

    However I found an easier way to remember. While studying for the MCM, I heard these processes referred to as redo and undo, which apply to roll forward and roll back, respectively. If you use these terms and place them in alphabetical order, you get redo, undo.

    Or redo before undo.

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

  • The Institute for Backup Trauma

    This is an editorial reprinted from April 27, 2005.

    It’s viral marketing, but it’s not bad. Livevault produced a short video starring John Cleese as the director for this institute that seeks to counsel those that have had problems with tape backups. “Such an unreliable medium”, this one is straight out there. An advertisement for Livevault, a little silly, satirical, but not that bad.

    It’s an interesting concept and one that I’ve debated with various colleagues over the years. Tape v disk. Which one is better for securing and ensuring the integrity of your data, which one is better for business continuity, which one works for your budget.

    When I started in this business, it was a no brainer. Disk was way more expensive than tape and there wasn’t even a choice. Nowhere I worked could afford to backup their data to disk. On top of that, the technology for managing disk backups wasn’t great. I remember working for a small company and we couldn’t afford a VCS system. At least, I couldn’t pry money out of my boss for one, despite the fact that the business lived and died based on the code that was written. So we setup 5 folders on the network: Monday, Tuesday, Wednesday, Thursday, and you guessed it, Friday. Under each one, the other developer and I each had our own folder and a batch job that would copy data off our desktops to the appropriate folder on the appropriate day. We erased everything older than 5 days, though we still had tapes if we needed them.

    Today, with disk being nearly as cheap and much, much faster than tape, and the need to go back more than one version in a business environment being fairly rare, it makes some sense to use disk. Microsoft released their own software, that helps with data recovery on disk, so there must be either some growth or a very high profit margin in this area 🙂

    Personally, I think that the idea is a good one, but like many new technologies that change the way a user works, this one will take some time to get used to. I’m all for users being able to recover their own data without calling an admin, especially when the admin is me, but I’m sure that there will be lots of calls on how to find the files, which version, I forgot to save it, but my machine crashed and I want to go back 3 versions, annoyed calls when the last version on disk rolls off, etc.

    But I wouldn’t give up my tape. At J.D. Edwards, we backed up the databases to disk, then to tape that night, with two copies of the tapes being made. One went offsite and one was in a rotation on site. The triple protection served me well and we never had issues getting data off disk or one of the two tapes.

    Of course, that was expensive, so it’d not an option I’ve had often. Still, one disk and one tape worked out well and these days having disk be so cheap, a second copy on disk is something I’d shoot for.

    Steve Jones