April 23, 2013 at 1:40 pm
Hello,
We recently migrated databases from SQL 2005 to SQL 2008 R2. It's a nice shiny hardware, much better than the old server. It used to take 40 minutes to backup 550 GB database on old crap hardware with SQL 2005 and now it takes 7+ hours. I also tried with RedGate SQL Backup professional and it also takes 7 or more hours for the same backup. Compatibility mode is changed to 100 as well.
Thoughts? Thanks for your help in advance.
April 23, 2013 at 1:53 pm
First question, are the backups being done to local resources (DASD or dedicated SAN storage)?
April 23, 2013 at 2:02 pm
It is done on dedicated SAN storage. Its on the same pool with other disks but the LUN is dedicated to the backup drive. Old severs were not on SAN but didnt have great hardware too.
April 24, 2013 at 6:55 am
What is your connection to the SAN? Are you connecting using iSCSI, or fibre channel. I've seen iSCSI saturated very easily.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
April 24, 2013 at 7:32 am
Cluster is made of Dell R815 server. With Intel x570 10GB NICs connected to Cisco Nexus 5596 Switch through a coper twinex cables. That is connected to EMC VNX 5500 SAN with 10GB fiber. Protocol throughout is iSCSI. SAN is made up of SSDs and capable of over 35000 IOPS/second.
April 24, 2013 at 7:53 am
Is the compress backup is enabled? Also have to tried local backup in off hours to see if that makes any differences.
I have close to 250 GB DB and backup directly to shared network and it takes close to 15 minutes with compress backup enabled.
April 24, 2013 at 8:05 am
Server is going live next week, So there is no traffic at all except me. So, doesnt matter if I test it now or off hours.
I do not have Backup compression enabled. Doing it now and will try to take a backup with that. However, reason I did not enable compression is because we use REDGATE Backup 7.0 which is pretty good. It brings down 500 GB database to 50 GB and usually much faster. That is what is taking 7 hours now instead of 30 minutes on our old servers.
April 24, 2013 at 9:45 am
What do you see while the backup is running?
Are one or more CPUs pegged?
Do you see disk queue length rising?
April 24, 2013 at 9:47 am
Not really. Have 64 CPU and not pegged at all. Queue length is normal too.
April 24, 2013 at 9:49 am
apat (4/24/2013)
Server is going live next week, So there is no traffic at all except me. So, doesnt matter if I test it now or off hours.I do not have Backup compression enabled. Doing it now and will try to take a backup with that. However, reason I did not enable compression is because we use REDGATE Backup 7.0 which is pretty good. It brings down 500 GB database to 50 GB and usually much faster. That is what is taking 7 hours now instead of 30 minutes on our old servers.
What are the differences between old and new hardware, including connections between server and san.
Have you tried a backup without compression?
April 24, 2013 at 9:57 am
Lynn Pettis (4/24/2013)
apat (4/24/2013)
Server is going live next week, So there is no traffic at all except me. So, doesnt matter if I test it now or off hours.I do not have Backup compression enabled. Doing it now and will try to take a backup with that. However, reason I did not enable compression is because we use REDGATE Backup 7.0 which is pretty good. It brings down 500 GB database to 50 GB and usually much faster. That is what is taking 7 hours now instead of 30 minutes on our old servers.
What are the differences between old and new hardware, including connections between server and san.
Have you tried a backup without compression?
Old hardware was Six-Core AMD 24 CPU, 32 GB RAM (Vs 64 CPU, 132 GB RAM on new server). Only difference backup was stored locally as it wasn't on SAN. Now we are moving to SAN. Yes tried backup without compression via native backup and redgate both but same result.
April 24, 2013 at 10:00 am
apat (4/24/2013)
Lynn Pettis (4/24/2013)
apat (4/24/2013)
Server is going live next week, So there is no traffic at all except me. So, doesnt matter if I test it now or off hours.I do not have Backup compression enabled. Doing it now and will try to take a backup with that. However, reason I did not enable compression is because we use REDGATE Backup 7.0 which is pretty good. It brings down 500 GB database to 50 GB and usually much faster. That is what is taking 7 hours now instead of 30 minutes on our old servers.
What are the differences between old and new hardware, including connections between server and san.
Have you tried a backup without compression?
Old hardware was Six-Core AMD 24 CPU, 32 GB RAM (Vs 64 CPU, 132 GB RAM on new server). Only difference backup was stored locally as it wasn't on SAN. Now we are moving to SAN. Yes tried backup without compression via native backup and redgate both but same result.
Do you have the space on the new server to backup locally? If yes, try that and then move the backup file to the san. See what kind of timing that provides.
April 24, 2013 at 10:30 am
Lynn Pettis (4/24/2013)
apat (4/24/2013)
Lynn Pettis (4/24/2013)
apat (4/24/2013)
Server is going live next week, So there is no traffic at all except me. So, doesnt matter if I test it now or off hours.I do not have Backup compression enabled. Doing it now and will try to take a backup with that. However, reason I did not enable compression is because we use REDGATE Backup 7.0 which is pretty good. It brings down 500 GB database to 50 GB and usually much faster. That is what is taking 7 hours now instead of 30 minutes on our old servers.
What are the differences between old and new hardware, including connections between server and san.
Have you tried a backup without compression?
Old hardware was Six-Core AMD 24 CPU, 32 GB RAM (Vs 64 CPU, 132 GB RAM on new server). Only difference backup was stored locally as it wasn't on SAN. Now we are moving to SAN. Yes tried backup without compression via native backup and redgate both but same result.
Do you have the space on the new server to backup locally? If yes, try that and then move the backup file to the san. See what kind of timing that provides.
Do not have space locally. For test, I tried backing it up on C: and indeed huge performance gain. It finished in 3.5 hours instead of 7. It should still be less comparing with our old hardware where it takes only 30 mins. Database has Full text indexes and 3 file groups. As a part of migration I drop and recreated full text indexes. Should I be concerned about that?
April 24, 2013 at 10:58 am
Was this with compress backup enabled or not?
April 24, 2013 at 11:02 am
DevDB (4/24/2013)
Was this with compress backup enabled or not?
No compressed backup was not enabled while I did that using Native backup. But while doing it through REDGATE it was compressed backup.
Viewing 15 posts - 1 through 15 (of 25 total)
You must be logged in to reply to this topic. Login to reply