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.
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.ThanksD |
|
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. |
|
|
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. |
|
|
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. |
|
|
dinakar
Master Smack Fu Yak Hacker
2507 Posts |
|
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.- LumbagoMy blog-> http://thefirstsql.com/2011/07/08/how-to-find-gaps-in-identity-columns-at-the-speed-of-light/ |
|
|
|
|
|
|
|