Options

SQL Compare v7.1 much slower than v5

purdaddypurdaddy Posts: 3
edited February 5, 2009 5:18AM in SQL Compare Previous Versions
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

Comments

  • Options
    After some additional testing, it appears this may be related to specific source databases. Specifically ones that had many views that did not match.

    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
  • Options
    Have you got any views specified WITH ENCRYPTION? If a database does, and the 'Decrypt encrypted objects on 2005 and 2008 database' option is turned on, then SQL Compare reads the pages containing the object text directly from SQL Server using DDBC PAGE and reads the encrypted text from there. Unfortunately, this takes time proportional to the total number of text objects in your database. You could try turning off this option in the project options screen & see if that improves the population time.

    Simon C
Sign In or Register to comment.