Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 Database Design and Application Architecture
 SQL Server 2008 Migration, Replication and Cluster

Author  Topic 

darsh123
Starting Member

3 Posts

Posted - 2012-04-07 : 15:37:11
Hello,

My client currently wants to Migrate SQL Server production instance from an outsourced vendor and bring it to in house. Currently the database is at outsourced location and is running on a clustered environment.

The system details at high level are - SQL Server 2008 sp2 running on Windows Server 2003 Sp2.

Now, my client wants to bring this setup in-house and the plan in nutshell is to create a parallel environment onsite. We are thinking to first cold restore with data files from outsourced location and then set up replication for concurrent synch up of offsite and newly created onsite instance. And then, this replicated new onsite instance need to be brought under clustering.

The question for gurus on this forum, is there any comprehensive, step-by-step style document anywhere that addresses this replication/clustering in detail manner?

Our onsite system configuration will be identical to outsourced location - i.e. SQL Server 2008 sp2 running in Windows Server 2003 sp2.

Thanks

D

russell
Pyro-ma-ni-yak

5072 Posts

Posted - 2012-04-07 : 19:44:20
Setup the cluster first.

I wouldn't use replication for synching, I'd restore differential, then tran log backups.
Go to Top of Page

darsh123
Starting Member

3 Posts

Posted - 2012-04-08 : 03:05:08
Thank you Russell. By "restore differential" do you mean, restore incremental data sets after first big restore from cold backup? Also, please clarify on tran log backups.
Go to Top of Page

jeffw8713
Aged Yak Warrior

819 Posts

Posted - 2012-04-08 : 11:11:40
What is the time available to cutover from the old system to the new system? And, how large are the databases?

If you have the time, I would setup everything locally and restore a copy of the backups from the old system. Test the new system thoroughly to make sure everything is setup correctly (e.g. logins, users, permissions, maintenance plans, etc...).

On the scheduled cutover date, if you have the time window - shut down the application at the old location. Backup all of the databases, copy the backups over to new system, restore databases, switch application to new database system, bring the system up and validate everything is working correctly.

If you don't have the time window, then you restore a copy the day before the cutover. At cutover time - or a couple hours earlier you perform a differential backup and restore on new system, then perform transaction log backups and restore at new system. When you perform the differential will depend on your time window - how large the differential is, etc...

The transaction log backups should be run every 15 minutes - and a final transaction log backup on the old system will be performed at your cutover time.

Another option would be to setup database mirroring from old to new. Then, at cutover time - switch from current principal (old system) to the partner (new system), update connection information in the application to point to new system and you should be up and running. If you go this way, make sure you have your maintenance plans setup and ready to go and turn them on when you switch over to the new system.
Go to Top of Page

dinakar
Master Smack Fu Yak Hacker

2507 Posts

Posted - 2012-04-26 : 19:09:01
Please do not post duplicate questions - http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=173382


Dinakar Nethi
************************
Life is short. Enjoy it.
************************
http://weblogs.sqlteam.com/dinakar/
Go to Top of Page

Lumbago
Norsk Yak Master

3271 Posts

Posted - 2012-04-27 : 05:08:50
I second what jeff and russel are saying. Set up the in-house cluster first, test it thoroughly (!!) then set up log-shipping (google "sql server log shipping" and you'll find TONS of information). Once swapping time comes downtime could be in the seconds if you have done things properly.

- Lumbago
My blog-> http://thefirstsql.com/2011/07/08/how-to-find-gaps-in-identity-columns-at-the-speed-of-light/
Go to Top of Page
   

- Advertisement -