Restoring to a Point In Time

  • Kathi Kellenberger

    SSChampion

    Points: 11811

    Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/kKellenberger/restoringtoapointintime.asp

    Aunt Kathi Data Platform MVP
    Author of Expert T-SQL Window Functions
    Simple-Talk Editor

  • jtango

    SSChasing Mays

    Points: 643

    Great that someone reminds us of this. Although all DBA's should be familiar with restoring to a point in time.

    One thing in the article which I found not so clear is that when you meet a recovery situation the first thing to do is to backup the current log. I would do it before anything else and after that put out alerts to end users etc.

    By the way differential backups may become very handy also when full backup intervall is not so dense. With differential backups you don't have to restore trn-logs only just after the restoration of the last differential backup.

    Also if you make a database maintenance plan (with ent.manager or otherwise) you should also test it, restoration too!

     

    - JARI -

  • Nic Washington

    SSC Veteran

    Points: 256

    I've used the restoring to a point in time a number of times with great success, but I always have to change my regional settings from English to American Date format for it to work.

    Regards,

    Nic Washington

  • Sebastien THOMAS

    SSC Rookie

    Points: 25

    I am surprised that the article does not speak about the necessity to look after the transaction log growth when the database is put in full recovery model.

    I am either surprised that apparently Lite Speed does not encapsulate the transaction logs backup as standard product of the market with less marketing does.

    Regards,

    Seb |:

  • Jason Hall

    Hall of Fame

    Points: 3906

    Can you elaborate on the LiteSpeed part of that response.  Is sounds like you are saying that LiteSpeed does not allow for transaction log backups which it certaintly does.  LiteSpeed also fully supports point in time recovery.

    Nice article Kathy!

     

    I've seen a lot of use out of point in time recovery in development environments.  Its a great way to roll back an hours worth of work if you completely fudge up a stored proc that your working on.  Ideally theres a version control practice in place, but if not, point in time recovery can allow you to roll back changes without too much work.

  • Kathi Kellenberger

    SSChampion

    Points: 11811

    You can do point in time restores with LiteSpeed.

    The article was meant to show how to do point in time recoveries with native SQL commands, not to actually discuss third-party backup tools.   I did mention in the article to check your third-party tool documentation for their commands.  

    If the database is in full recovery mode, you must do transaction log backups on a regular basis.  That should keep the transaction log from growing too large.

    Glad you enjoyed the article.  I was surprised at the number of reads and the response it received. 

     

    Kathi

     

     

     

     

    Aunt Kathi Data Platform MVP
    Author of Expert T-SQL Window Functions
    Simple-Talk Editor

  • Ian Yates

    SSCoach

    Points: 19738

    Good point - not all of us are in the US   (I'm in Australia - we use dd/mm/yyyy)

    Is there a way to change the default for SQL server at the

    a) Server level

    b) database level

    c) logon level?

    I've got an app from the US which fails at one particular point because it submits a date using dd/mm/yyyy but SQL wants mm/dd/yyyy - at all other points it uses the yyyy-mm-dd syntax..  Driving me nuts!   Sorry for irrelevant post - been wasting my time on it lately and this thread reminded me of it

  • Chris Clennon

    SSC Rookie

    Points: 30

    Thanks for the post... this was very helpful.  I'm a little new to the DBA world, and this was the first time I had to perform a critical point-in-time recovery.  MSDN wasn't very helpful (as usual), but this article was just what I needed.

  • Kathi Kellenberger

    SSChampion

    Points: 11811

    Glad to hear that the article helped!

    Aunt Kathi Data Platform MVP
    Author of Expert T-SQL Window Functions
    Simple-Talk Editor

  • Ian Yates

    SSCoach

    Points: 19738

    I had previously added to this thread good point   Still is a good point,

    but rather than following the way of expressing the date as given

    in the article (mm/dd/yyyy) which is ambiguous for those of us outside the

    USA, you should follow the example given in trusty books online

    This example restores a database to its state as of 10:00 A.M. on July 1, 1998,

    and illustrates a restore operation involving multiple logs and multiple backup devices.

    -- Restore the database backup.
    RESTORE DATABASE MyNwind
    FROM MyNwind_1, MyNwind_2
    WITH NORECOVERY
    GO
    RESTORE LOG MyNwind
    FROM MyNwind_log1
    WITH RECOVERY, STOPAT = 'Jul 1, 1998 10:00 AM'
    GO
    RESTORE LOG MyNwind   
    FROM MyNwind_log2   
    WITH RECOVERY, STOPAT = 'Jul 1, 1998 10:00 AM'
    GO

    This example shows that you can express the date in a less ambiguous format.  I imagine (though I haven't tried it) that the widely accepted format of yyyy-mm-dd hh:nn where hh is 24-hrs would also work.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply