SQL Compare v7.1 much slower than v5
purdaddy
Posts: 3
Hello all,
This topic has to do with the comparison performance between the current and past release of SQL Compare.
I'm not sure I'm running a pure apples to apples comparison, but the results I'm getting certainly do not make any sort of sense.
We were previously running v5 of SQL Compare on a VM box with little horsepower (2 core cpu, 4mb RAM, shared storage, etc) and as a part of replacing that database monitoring VM server we now have a physical box, 8 core, 8mb RAM, SAN storage, based server running v7.1 of SQL Compare.
When running v7.1 on the same target databases, for comparison purposes, as we run v5 against, the v7.1 app appears to "lock up" at about 19% for the 1st DB in the comparison, and then at 69% for the 2nd DB, each time and sit there, "reading object text". I've never sat and watched to know how long it really takes v7.1 to finish, although I know it will eventually (usually by the next day).
Running v5 on those same source databases produces completed results within 10 minutes (again, on a "lesser" box).
The calls that appear to be taking so excruciatingly long are DBCC Page executions on the target database pages, which seems like something that wouldn't need to be done to script objects per se, unless that was how the app were to get the object text (still a little odd IMO).
Any ideas? Maybe I'm missing some settings that could cause this in v7.1 since we skipped from v5 to v7.1?
Thanks!
-Patrick
This topic has to do with the comparison performance between the current and past release of SQL Compare.
I'm not sure I'm running a pure apples to apples comparison, but the results I'm getting certainly do not make any sort of sense.
We were previously running v5 of SQL Compare on a VM box with little horsepower (2 core cpu, 4mb RAM, shared storage, etc) and as a part of replacing that database monitoring VM server we now have a physical box, 8 core, 8mb RAM, SAN storage, based server running v7.1 of SQL Compare.
When running v7.1 on the same target databases, for comparison purposes, as we run v5 against, the v7.1 app appears to "lock up" at about 19% for the 1st DB in the comparison, and then at 69% for the 2nd DB, each time and sit there, "reading object text". I've never sat and watched to know how long it really takes v7.1 to finish, although I know it will eventually (usually by the next day).
Running v5 on those same source databases produces completed results within 10 minutes (again, on a "lesser" box).
The calls that appear to be taking so excruciatingly long are DBCC Page executions on the target database pages, which seems like something that wouldn't need to be done to script objects per se, unless that was how the app were to get the object text (still a little odd IMO).
Any ideas? Maybe I'm missing some settings that could cause this in v7.1 since we skipped from v5 to v7.1?
Thanks!
-Patrick
Comments
Comparing other similar databases it seems the the v7.1 release is just as quick, if not more quick, than v5.
But there is a definite difference between v5 and v7.1 for these two databases that have extremely high numbers of differences in their views. Doesn't make sense, as the comparison portion is not what's taking the longest (it's the read object text portion that is), so it's something to think about.
Cheers,
-Patrick
Simon C