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 123»»»

Use Backup/Restore to Minimize Upgrade Downtimes Expand / Collapse
Author
Message
Posted Thursday, June 18, 2009 12:07 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Monday, June 23, 2014 11:55 AM
Points: 1,708, Visits: 1,792
Comments posted to this topic are about the item Use Backup/Restore to Minimize Upgrade Downtimes

Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs
Post #737175
Posted Thursday, June 18, 2009 2:57 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Yesterday @ 9:58 AM
Points: 95, Visits: 362
Thanks for the good article, Jonathan.
Post #737287
Posted Thursday, June 18, 2009 4:00 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, February 17, 2014 9:44 AM
Points: 127, Visits: 105
I sincerely appreciate this idea Jonathan...
Post #737348
Posted Thursday, June 18, 2009 5:59 AM
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: Thursday, May 9, 2013 5:05 AM
Points: 772, Visits: 105
Thanks for the article!

Just a thought...steps 1-7 can be done using setting up log shipping and the rest can be done using step 8 onwards when moving on to the new server.



Post #737435
Posted Thursday, June 18, 2009 5:59 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, August 7, 2014 9:08 AM
Points: 57, Visits: 79
I have used this method for years. Even with busy and/or large databases, I can move a database server to a new piece of hardware with only about 10 minutes of downtime. I recently used the same method during migration of a number of legacy SQL 2000 boxes to SQL 2005.


- Jay
Post #737436
Posted Thursday, June 18, 2009 6:59 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, February 11, 2014 4:12 PM
Points: 2,007, Visits: 768
Good article Jonathan, I've used these steps to move databases to new hardware and datacenter with just a few minutes of downtime. The key is making sure that the application(s) that use the databases are good to go. If possible you need to test such applications on the new hardware first to make sure the configurations are set properly... restore a backup of an actual database for such testing, using a "test" database might not reveal potential problems.

The other thing is to make sure that logins have been propagated to the new server.
Post #737492
Posted Thursday, June 18, 2009 7:30 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, August 21, 2014 12:08 PM
Points: 1,414, Visits: 4,540
we're usually not as nice

if we do a side by side upgrade we tell people the cut off for R/O access. then we backup and restore on the new hardware. critical databases are on the SAN and we just point people to a replicated copy of the data while we upgrade the hardware


https://plus.google.com/100125998302068852885/posts?hl=en
http://twitter.com/alent1234
x-box live gamertag: i am null
[url=http://live.xbox.com/en-US/MyXbox/Profile[/url]
Post #737527
Posted Thursday, June 18, 2009 7:41 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 7:04 AM
Points: 1,030, Visits: 2,795
Noel McKinney (6/18/2009)
Good article Jonathan, I've used these steps to move databases to new hardware and datacenter with just a few minutes of downtime. The key is making sure that the application(s) that use the databases are good to go. If possible you need to test such applications on the new hardware first to make sure the configurations are set properly... restore a backup of an actual database for such testing, using a "test" database might not reveal potential problems.

The other thing is to make sure that logins have been propagated to the new server.


The sp_help_revlogin stored proc could be useful for moving the logins.

edited to add URL:

http://support.microsoft.com/kb/246133


Gethyn Ellis

gethynellis.com
Post #737546
Posted Thursday, June 18, 2009 7:48 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Tuesday, May 6, 2014 5:51 AM
Points: 6,266, Visits: 2,028
Ermm... Isn't this just a description of LogShipping ?


* Noel
Post #737554
Posted Thursday, June 18, 2009 8:00 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, August 19, 2014 7:04 AM
Points: 1,030, Visits: 2,795
noeld (6/18/2009)
Ermm... Isn't this just a description of LogShipping ?


Yes it is, using a manual log shipping process to keep a large db up to date prior to the migration date. I used this many times and it does save alot time compared to 'doing it all the day'


Gethyn Ellis

gethynellis.com
Post #737565
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse