Comments
Sort by recent activity
Hi,
When you choose a comparison key, Data Compare uses this to determine the order in which to retrieve the rows, either from the SQL Server or the backup file.
If it's from a SQL Server, then it's just a case of constructing an appropriate ORDER BY clause, which means we can use anything you like, with the proviso that an ORDER BY matching an index will be significantly faster.
However, when retrieving from a backup file, we don't have the power of SQL Server to do the sorting for us, but rather have to do it ourselves. If we use an order that matches that of an index, we can deterministically return the rows from the backup without having to do a sort.
Allowing custom comparison keys would mean we'd have to do an in-memory, or more likely on-disk, sort of the table before returning any rows for comparison.
It's something we're considering for the future, but technically it'll be much more challenging to achieve in a way that allows us to get decent performance and maintain scalability.
Hope that helps,
Robert / comments
Hi,
When you choose a comparison key, Data Compare uses this to determine the order in which to retrieve the rows, either from the SQL Server or the backup file.
If it's from a SQL Server, then it'...
Hi,
All the settings you've described are part of the project file. These can be found in the folder shown at the top of the "Comparison Projects" dialog, and by default are located in: C:\Documents and Settings\<username>\Local Settings\Application Data\Red Gate\SQL Data Compare 6
You can just copy these project files (with a .sdc extension) to another machine, and all the settings should be persisted.
Hope that helps,
Robert / comments
Hi,
All the settings you've described are part of the project file. These can be found in the folder shown at the top of the "Comparison Projects" dialog, and by default are located in:C:\Documents...
Hi Andrew,
Thanks for the encouraging comment :-). And don't worry about the nagging - it's really useful to know what's causing people pain, so we can then do something about it!
Cheers,
Rob / comments
Hi Andrew,
Thanks for the encouraging comment :-). And don't worry about the nagging - it's really useful to know what's causing people pain, so we can then do something about it!
Cheers,
Rob
Hi,
Just a quick update - Data Compare 6.1 is now released, so you should be able to compare in a matter of minutes now :-)
Robert / comments
Hi,
Just a quick update - Data Compare 6.1 is now released, so you should be able to compare in a matter of minutes now :-)
Robert
We've been doing some work on this recently, and the performance has been significantly improved.
Andrew kindly provided us with a copy of his database, and on our internal builds, that which used to take several hours now takes under ten minutes for the whole database - about 45 millions rows of it!
These improvements will be included in SQL Data Compare 6.1, which should be released in Q1 2008. / comments
We've been doing some work on this recently, and the performance has been significantly improved.
Andrew kindly provided us with a copy of his database, and on our internal builds, that which used ...
Morning,
If it's not chewing up CPU any more, then I guess it must be I/O bound somewhere - I think you said you're now running everything off the local disk, so it's not a slow network link. That said, I've seen some disks perform quite badly when seeking around - in particular one of the NAS boxes we have.
Rob / comments
Morning,
If it's not chewing up CPU any more, then I guess it must be I/O bound somewhere - I think you said you're now running everything off the local disk, so it's not a slow network link. That ...
Morning,
Well, I'm amazed it took that long, I have to say... how big is the backup file you're using, and is it SQL Backup or native? Are you accessing it over the network, or is it on the local disk?
Did you manage to find out whether you're using a non-clustered index or a clustered one as the comparison key on the particularly large table? As I said before, this can have a huge effect on performance.
As for the timeouts... I'm confused. Especially since it was only on one side, despite the fact they're identical controls!
Thanks,
Robert / comments
Morning,
Well, I'm amazed it took that long, I have to say... how big is the backup file you're using, and is it SQL Backup or native? Are you accessing it over the network, or is it on the local d...
If you get a moment (and you can stand it), could you just have a quick look and see what the CPU usage is doing during the compare (the main "body" of the compare, not the registering databases) bit? In other words, are we maxing out the CPU, or is it I/O bandiwidth somewhere that's the bottleneck?
Thanks,
Rob / comments
If you get a moment (and you can stand it), could you just have a quick look and see what the CPU usage is doing during the compare (the main "body" of the compare, not the registering databases) b...
Hmm... that obviously shouldn't be happening if the keys do actually match. What datatype are the columns that make up your comparison key?
Also, am I right in thinking you're comparing two live databases here, rather than backups?
Thanks,
Robert / comments
Hmm... that obviously shouldn't be happening if the keys do actually match. What datatype are the columns that make up your comparison key?
Also, am I right in thinking you're comparing two live da...
Hi,
There's two things to check: firstly, have a look in the textual difference viewer (double click on one of the "different" values). This should give you a better idea of exactly where we think the data differs, which might give you some more clues.
Secondly, have you checked whether the two columns are the same collation on both databases? This can certainly affect what's considered equal.
Hope that helps,
Robert / comments
Hi,
There's two things to check: firstly, have a look in the textual difference viewer (double click on one of the "different" values). This should give you a better idea of exactly where we think ...