8.1 Compare (and Data) taking longer than previous versions
dwainew
Posts: 59 Bronze 4
I don't think the registration (or compare) process took this long previously.
I'm comparing a live DB (beefy server) to a Redgate full Backup (compression 1) that's local on my workstation (2.4 GHz quad core/ 4 GB RAM, 32 bit, with a local RAID 0 SATA setup)
The BU is 3.4 GB. Schema is pretty light, at 145 tables, 136 views, and about 50 sprocs + functions.
The comparison hangs for several minutes (10+) on "connecting to server" against the BU file. This happens in compare, but even MUCH longer with data compare. Activity is heavily I/O bound, but I don't remember the initial SCHEMA stage taking this long before.
What should be my performance expectations? Could something be fouled up, unusual schema elements, etc.?
The kicker is that this takes so long that it turns out to be quicker to RESTORE to another temp DB and use compare against those.
I'm comparing a live DB (beefy server) to a Redgate full Backup (compression 1) that's local on my workstation (2.4 GHz quad core/ 4 GB RAM, 32 bit, with a local RAID 0 SATA setup)
The BU is 3.4 GB. Schema is pretty light, at 145 tables, 136 views, and about 50 sprocs + functions.
The comparison hangs for several minutes (10+) on "connecting to server" against the BU file. This happens in compare, but even MUCH longer with data compare. Activity is heavily I/O bound, but I don't remember the initial SCHEMA stage taking this long before.
What should be my performance expectations? Could something be fouled up, unusual schema elements, etc.?
The kicker is that this takes so long that it turns out to be quicker to RESTORE to another temp DB and use compare against those.
Comments
The process of registering a backup file shouldn't take any longer than previous versions, but it is not out of the question that it does. We have made some improvements to the reliability of the backup reader, and this could have been at the expense of performance.
Our support for backup files offers more for convenience, than it does to speed improvements over restoring the backup file and comparing the live db. Registering a backup file involves reading the file from disk, uncompressing the data, then writing most of it back to disk as it's not going to fit in memory. Because of this, it's probably not going to be any quicker than restoring the actual backup file to a temp db, but it is a lot more convenient.