Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Restoring to a Point In Time Expand / Collapse
Author
Message
Posted Friday, May 27, 2005 5:56 PM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Wednesday, July 23, 2014 7:10 AM
Points: 769, Visits: 244
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/kKellenberger/restoringtoapointintime.asp

Aunt Kathi
Microsoft
(Former SQL Server MVP)
Post #185856
Posted Tuesday, June 14, 2005 12:11 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, April 28, 2014 6:11 AM
Points: 223, Visits: 139

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 -




Post #190197
Posted Tuesday, June 14, 2005 1:23 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, July 25, 2006 1:37 AM
Points: 16, Visits: 1

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

Post #190207
Posted Tuesday, June 14, 2005 2:05 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, June 8, 2007 1:53 AM
Points: 1, Visits: 1
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 |:
Post #190218
Posted Tuesday, June 14, 2005 3:05 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Wednesday, October 2, 2013 2:46 PM
Points: 392, Visits: 82

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.

Post #190593
Posted Tuesday, June 14, 2005 6:18 PM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Wednesday, July 23, 2014 7:10 AM
Points: 769, Visits: 244

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
Microsoft
(Former SQL Server MVP)
Post #190619
Posted Thursday, June 16, 2005 7:24 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, January 30, 2014 10:08 PM
Points: 1,038, Visits: 444

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




Post #191246
Posted Friday, June 2, 2006 3:06 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Sunday, June 3, 2012 12:44 AM
Points: 2, Visits: 6
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.
Post #284664
Posted Friday, June 2, 2006 3:10 PM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Wednesday, July 23, 2014 7:10 AM
Points: 769, Visits: 244
Glad to hear that the article helped!

Aunt Kathi
Microsoft
(Former SQL Server MVP)
Post #284665
Posted Saturday, June 3, 2006 8:19 PM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, January 30, 2014 10:08 PM
Points: 1,038, Visits: 444

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.




Post #284732
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse