Restoring to a Point In Time

Question

Restoring to a Point In Time

Kathi Kellenberger

SSChampion

Points: 11811
More actions
May 27, 2005 at 5:56 pm

#167351

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

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

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

jtango SSChasing Mays Points: 643 More actions · Answer 1

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 Old Hand Points: 366 More actions · Answer 2

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 More actions · Answer 3

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 More actions · Answer 4

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 More actions · Answer 5

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 More actions · Answer 6

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 More actions · Answer 7

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 More actions · Answer 8

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 More actions · Answer 9

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.