Ability to handle large number of database objects

Visualizes SQL Server object dependencies.

Moderators: David Atkinson, Anu Deshpande

Ability to handle large number of database objects

Postby Martin_P » Thu Apr 14, 2011 4:18 pm

Hi, I'm running version 2.6.1.47 and am trying to product a diagram from one of our data warehouses.

The warehouse contains approx 3500 tables and 3000 stored procedures.

I only want to produce a diagram for a small set of these tables.

What I find is when adding objects to the project that the selection of table names is very slow (via the UI) and that generating the model can take several hours !

I am running Win 7 on a well speced desktop.

I would really like to use this product for reporting and documentation, but the perform is hindering me at the moment
Martin_P
 
Posts: 3
Joined: Thu Jul 22, 2010 4:07 pm

Postby chriskelly » Fri Apr 15, 2011 5:34 pm

Unfortunately, given that you are attempting to feed over 6500 objects into the tool, I think that it is expected to take some time. Whether 'several hours' is right, I cannot be sure, but I wouldn't be surprised.

The engine behind the tool need to read and parse the entire schema and calculate the dependencies which are then rendered to the UI as the resulting diagram.

If you believe that there is an error or problem which is slowing down the process, then please get in touch directly at support@red-gate.com.
chriskelly
 
Posts: 330
Joined: Mon Apr 19, 2010 1:44 pm
Location: Cambridge, UK

DT Needs Cached Schemas Option

Postby EdCarden » Fri Aug 05, 2011 5:48 pm

I face this same duration issue since our primary accounting database (used by our accounting software) consists of over 2000 tables alone (don’t ask how many other objects we have) . This problem could be easily over come for most scenarios by enabling some form of schema cache.

Suggestions:

1) Allow for storing the layout of an already queried DB Schema so that when the user goes to work on a project or start a new one they can opt to use a cached copy of the schema thereby greatly reducing the time to get the schema.
2) Allow the user to restrict the schema query to specific objects types (i.e. all tables) and perhaps even to specific schemas (i.e. all dbo schema objects) so as to cut down on the number of objects the app has to load.

The main goal should be to offer greater control of schema retrieval operations which currently is limited to selecting a specific DB on a server instance.

Had I realized in advance it was going to take this long to start Dependency Tracker every time I used it I might not have purchased it.
EdCarden
 
Posts: 90
Joined: Tue Nov 25, 2008 6:26 pm


Return to SQL Dependency Tracker 2

Who is online

Users browsing this forum: No registered users and 1 guest