August 21, 2019 at 2:02 pm
We are moving from one SQL server to newer SQL with better hardware. Both systems have an identical configuration. We won't like to change any configuration in a newer system. Currently, we are doing some tests to measure throughput, I/O, CPU, and a few others. Ideally, a newer system should work much faster than the old one. But from the recent test, restore takes double time than the older system. Any thoughts or suggestion would be greatly appreciated.
August 22, 2019 at 11:40 am
So, first up, new system, better hardware, but, "we won't like to change any configuration". That's an odd choice.
"We have more memory, but we're going to leave the old memory limits in place."
Stuff along those lines? Absolutely you should be planning on evaluating the system configuration changes that make sense within the new system.
As to why backups are taking longer, either the newer system is not as much better as you say, or something is misconfigured. Probably it's something related to disk or I/O. Reexamine those parts of the system. Further, capture wait statistics to understand what is causing things to slow down. That will give you directions in which to examine more things to identify the issue.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 22, 2019 at 2:07 pm
What are your backups saved on and where are they located, locally or somewhere on the network? Different troubleshooting may be required for each case.
Are the backups compressed? Unless you explicitly either set the default in the Database Settings tab of the instance properties to compressed, or explicitly have the COMPRESSION option in the WITH clause of the BACKUP statement of each database, the default would be uncompressed and result in more I/O and a slower backup and restore.
August 23, 2019 at 12:56 am
The fact the restores take twice as long makes me think the drives may be incorrectly formatted. Assuming NTFS disks, check they are formatted with 64K allocation units and not 4K. I've seen this cause a performance problem regularly.
Leo
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply