Pre-Comparison Filtering?

Automate and integrate using the SQL comparison API

Moderator: Chris Auckland

Pre-Comparison Filtering?

Postby raymond.dazo » Wed Apr 28, 2010 7:01 am

Hi Red-Gate Team,

We have a very important task that we need only to compare a limited number of database objects against the source database. Red-Gate does compare every objects first before you could filter the objects to sync, thus the post-comparison filtering.

One of your support posted something about pre-comparison filtering:

http://www.red-gate.com/messageboard/vi ... ght=filter

I would like to ask what is Red-Gate's plan regarding this, would your team implement a pre-comparison filtering? If so, when would be the target date?

Regards,

Raymond Dazo
raymond.dazo
 
Posts: 3
Joined: Wed Apr 28, 2010 4:55 am

Postby David Atkinson » Wed Apr 28, 2010 10:00 am

Hi,

Thanks for the question.

Can I ask which database version you are developing on? For SQL Server 2000 and 2005 we need to read the entire databse to build a dependency tree. For SQL Server 2008, because we it holds accurate dependency information we could in theory provide pre-comparison filtering. There is no timeframe for when this might be, and it would depend on the extent of SQL Server 2008 adoption as well as customer demand.

Is post-comparison filtering not fast enough for you at the moment?

David Atkinson
Product Manager
Red Gate software
David Atkinson
 
Posts: 1124
Joined: Mon Dec 05, 2005 4:54 pm
Location: Twitter: @dtabase

Postby raymond.dazo » Wed Apr 28, 2010 10:24 am

Our product's min requirement is SQL Server 2005 and our existing clients have been using this version.

There's a big performance difference when comparing the full size source database against a trim down target database (where our selected objects are stored).

For example:

We have a full size source database which 3gb in size. Then we have a trim down version (target DB) which is 441mb only. All objects (including the dependencies) in the latter database can be found in the source database.

Comparing the trim down db against the full size source doesn't eat that much time but it's the time registerting the full size source that eats a lot of time.

The larger the database is the longer it takes to register.

Oh, I guess I just realized what's the main issue that we have with your product. I think regardless if you were able to implement the pre-comparison filtering on whichever version of SQL Server, it's the time to register the full size database that kills.
raymond.dazo
 
Posts: 3
Joined: Wed Apr 28, 2010 4:55 am

Postby David Atkinson » Wed Apr 28, 2010 10:56 am

Yes, the number of schema objects will impact the registration time. Have you got plans to upgrade to SQL Server 2008? If so, I suspect you'll achieve better performance.

David
David Atkinson
 
Posts: 1124
Joined: Mon Dec 05, 2005 4:54 pm
Location: Twitter: @dtabase

Postby raymond.dazo » Wed Apr 28, 2010 11:02 am

Does upgrading to SQL Server 2008 will improve registration performance? And how much improvement?
raymond.dazo
 
Posts: 3
Joined: Wed Apr 28, 2010 4:55 am

Postby Simon C » Wed Apr 28, 2010 11:46 am

In SQL Server 2008 we don't need to parse textual objects to load dependency information, we read sys.sql_expression_dependencies instead. So, if you've got lots of textual objects, you will get better population performance with SQL Server 2008

SimonC
Simon C
 
Posts: 140
Joined: Tue Feb 26, 2008 4:56 pm
Location: Red Gate Software


Return to SQL Comparison SDK Previous Versions

Who is online

Users browsing this forum: No registered users and 0 guests