September 21, 2011 at 10:23 am
Hi,
I need to move a large TB Database to another server, please let me know the best to handle this, thanks
Dave
September 21, 2011 at 10:26 am
Backup / restore.
Maybe you can do a copy with the san. Ask the san admin.
P.S. What do you mean by move? Make a copy for dev / test server or upgrade to a new prod server?
September 21, 2011 at 10:51 am
Upgrading to the new server
September 21, 2011 at 11:06 am
What changes? Hardware, sql & windows version, 32 to 64 bit?
Is hte new server a VM or physical?
September 22, 2011 at 4:17 am
Assuming you want to minimize downtime, you might want to look into setting up log shipping so that you can get the TB worth of data moved over and only have a small amount of logs to move when it's time to actually make the switch.
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
September 22, 2011 at 4:43 am
As explained above, if you do not have space issue go with LS. This will help you to minimize the donwtime too.
---------------------------------------------------
"Thare are only 10 types of people in the world:
Those who understand binary, and those who don't."
September 22, 2011 at 7:16 am
thanks All, I have good information shared by you all
I also did some research also and easily able to talk in my coming meeting
thanks again
Dave
September 23, 2011 at 7:37 am
Dave, what other ways did you find? Others might want to know more possible solutions to solve their problems as well.
September 23, 2011 at 8:17 am
If you are moving to a new server running the same version of SQL Server Log shipping will work. If you are moving to a new server that is running a higher level of SQL Server I don't think you can log ship to a higher level......
Anyone want to chime in on this?
Last week we moved a SQL Cluster from one data center to another.. same hardware but different back end storage obviously. I simply shutdown SQL Server and copied all of the files to a USB drive, then once the servers were hooked up to new back end storage I file copied the data back. The main db was 450gig. We were able to get a 24 hour outage window to accomplish all of this as it required moving 10 application servers as well.
September 23, 2011 at 8:48 am
You should be able to log ship to a higher version. Backup/restore definitely should work back a version or two (http://msdn.microsoft.com/en-us/library/ms186858.aspx). It's just a restore, though if you switch over, it's a one way restore. AFAIK, SQL 2008 R2 can restore back to SQL 2000 backups.
As far as minimal time to move. If you can, log shipping, or manual movement is the way to minimize downtime. I've done this in the past (manual or automated with LS).
1. Take full backup on old instance
2. Copy full backup to new instance, restore
3. Take diff backup on old instance (could be while restore is happening)
4. copy and restore diff on new instance
5. Take log backup on old instance (could be during diff restore)
6. Restore log backup on new instance
7. Repeat 5 and 6 until you have minimal transactions and can tolerate the downtime from the last log backup/copy/restore time.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
September 23, 2011 at 10:09 am
When we moved to a new data center and upgraded from SS 2000 to 2005, I had to develop a custom log-shipping solution because the built-in could not be set up because of going to a higher version. It wasn't difficult though.
September 23, 2011 at 10:12 am
Chuck Hottle (9/23/2011)
When we moved to a new data center and upgraded from SS 2000 to 2005, I had to develop a custom log-shipping solution because the built-in could not be set up because of going to a higher version. It wasn't difficult though.
I'm really no expert here but log shipping is just a fancy word for "take a log backup, copy in somewhere and restore with norecovery, automatically".
Most backup jobs already do #1 & 2. #3 is not a big issue to code, especially if you already have a dr scenario in place ;-).
April 24, 2014 at 1:48 pm
If this is already on VMWARE your vmadmin can do this, or else you can use spindisk software to take the full system image or just SQL file copy or Disk level and it will catch up with the delta data too once you are migrated the initial copy ... AND NO DOWN TIME ABSOLUTELY.
@JayMunnangi
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply