February 16, 2003 at 3:47 pm
Need to move a 67 gig db from one server to another server.
1. Installed SQL2k on the new server
2. Shut down the old SQL server and moved the master,model,msdb and smaller user dbs over to the new server
3. Remapped the master,model,msdb to the new server via start-up paramaters and deattach/attach
4. Started the server starts fine finds all my other user DBs, my logins, dts and jobs are there
so now I need to move the BIG 67 GIG file over any ideas???
Machines have tape libraries but use different size tapes (great buying our hardware satff did!!!!!!!)
Edited by - notrub on 02/16/2003 3:49:10 PM
February 17, 2003 at 12:48 am
If a copy over the network is not an option, you could use a spare harddrive to transfer the file.
Are there any other issues you have to deal with, like server downtime for example?
February 17, 2003 at 2:41 am
When I did a 28GB database I connected the two servers's network cards using a single network cable and did the copy that way. Still took a long time but it worked.
Far away is close at hand in the images of elsewhere.
Anon.
February 17, 2003 at 5:57 am
Probably faster to zip it first, mdf or bak, both usually compress pretty well.
Andy
February 17, 2003 at 6:11 am
thanks down time is an issue but too late for that it is down
also old and new system use different raid configs
the 67 gig file is on a 72 gig raid and I have no other options/places to zip it too
I hooked both up to 100mbs hub and threw them in a workgoup and let it copy goign in now ti check it out been running 17 hrs!
I also am in NJ and the snow we just got makes it worse -
February 17, 2003 at 8:59 am
I know its too late, but another idea would be to buy one of those cheap 200g IDE drives, plug into server A and copy, then pull and out put the drive in server B. Just like a floppy, only bigger!
Andy
February 18, 2003 at 4:44 pm
thanks - the file copy finally worked 24 hrs later
just had to do db detache/attache once the file was on the new server
so far so good - already seeing benefits
db is a big warehouse of mainframe data - one of the import jobs on the old server took 4.5 hrs matching 1.5 million records to 700,000 new records to check for dup major keys now runs in 57 min!
thanks
February 19, 2003 at 11:24 am
I'm in NJ as well, at least the snow kept some of the users home.
What raid configuration did you go to? Did this alone account for the performance gain? Are you only matching for dup primary then inserting or is there an update on a hit?
quote:
also old and new system use different raid configsI also am in NJ and the snow we just got makes it worse
John Zacharkan
John Zacharkan
February 19, 2003 at 11:42 am
The old server has:
4 x 200mhz Pentium Pro
1 gig ram
1 x 36 gig drive for os/apps/raw ftp files/log
4 x 36 gig RAID 1 for the DBs (72 gig usable space)
New Server:
4 x 1.4mhx P3 XEON
4 gig ram
4 x 18 gig as RAID 10 for os/apps/raw ftps
2 x 69 gig as RAID 1 for tempdb and logs
5 x 69 gig as RAID 5 for DBs (276 gig usable space)
1 x 69 gig as GLOBAL HOT SPARE
The big 4.5 hrs job imports a COMPLETE data set of mainframe data 700,000+ records in a table
then matches to this new data to our history table (1.5 million rows) on majkey
if it is in the history table - deletes it from the history table
then all records left have a bit field set to 0 for active=0 (NO)
then we insert all the data in the new table into the history table
with a default value for active = 1
I think the speed/performance jumps are due to all the changes CPUS, RAM but just more disk space before I had a 67 gig DB on a 72 gig array - no a lot of room left versus now it is 200 gig free space
February 22, 2003 at 11:12 am
Wow...Those times are high. I moved a 38GB DB from one server to another in a little over three hours. One of the advantages I had was that my database uses multiple file groups and my platforms have multiple NICs. I did not transprort the back-up. I used the attach-detach method. in an unattended job that ran off hours.
February 24, 2003 at 9:54 am
Maybe too late to help, but if anyone else has this issue, try looking at SQLLITESPEED, for runnning the backup. I had to move a database to another server, SQLLITESPEED backed up a 55Gb database in 28 minutes and compressed the back up file to 6GB
February 25, 2003 at 6:41 am
I'd be interested to know how you configured your memory. I too have 4Gb ram and I have not been that successful using it.
In my boot.ini I've tried /3GB. SQL still only appears to use 2GB. I've also used /PAE but there must be an address translation overhead with this.
February 25, 2003 at 5:44 pm
We are running Win2k Advanced Server with SQL 2000 Standard Edition and I am confused as to what will/won't work with that combination.
Does /3GB work with Win2K ADV Server and SQL 2000 Standard?
February 25, 2003 at 6:16 pm
Maximum Amount of Physical Memory Supported by the Standard Editions is 2GB.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply