4

We have a number of SQL Spatial views each made up of approximately 10 tables (so relatively complex views) and each including a table with a SQL Geometry column. A view could return up to 300-400 thousand records. No SDE involved. We are using a Query Layer (QL) for each spatial view (Select * from the view) to display in ArcMap. Each spatial table has a primary key, spatial grids and uses an SRID of 0. Just to load a QL might take 10-15 seconds. To display with a 100k - 250k data view (maybe 100s of features) takes 10-20 seconds. We previous had these as SDE views (same underlying SQL views w/o the SQL spatial column) in Arc 10 and they loaded and displayed in 1-3 seconds.

Anyone have ideas about why these are SO MUCH SLOWER without using SDE?

Improve this question

3 Answers 3

Reset to default
2

I don't know if this could help but when using Query Layers on ORACLE Views with an SDO column, we had to create Spatial Index on all tables containing Spatial information, and then create a spatial index on the view.

Improve this answer
3
  • 1
    Thanks for the quick response and a good idea. We have indices on the spatial tables but not on the views. In fact we were talking around this point this afternoon. I'll put an index on one of the larger views first thing Monday and let you know.
    – Michael Ciscell
    Commented Mar 3, 2012 at 0:22
  • @MichaelCiscell were you able to create the index on your View?
    – Dom
    Commented Mar 13, 2012 at 17:41
  • No. Sorry fro being away from this so long. We're working with ESRI now on the issue. Our views had issues an Indexed View didn't allow.
    – Michael Ciscell
    Commented May 11, 2012 at 22:40
2

First, it's slower than SDE because ArcMap has no information about the extent and other information that SDE stores and uses in the back-end of a SQL Server database to store such information and use it to speed rendering (did you get the 'calculating extent' dialogue when you tried adding it to the ArcMap pane?)

Second, have you tried accessing the view from a direct connection to your SQL Server database, and consuming it through that connection, rather than building another layer of SQL on top of your existing layer of SQL (ie. the view)? Sounds a bit redundant...

We build (ie. create) spatial views into the database, including ID's, and consume them from the Database Connection tree in Catalog, rather than using query layers.

All in all, using a query layer on top of a query and lack of optimization information used by SDE sounds like the culprit...but we have experienced slow performance due to the latter issue in ArcMap as well.

Improve this answer
1

My suggestion would be cut down on fields you are selecting instead of

Select * from the view

which gives you all the rows and all the columns of the tables in question cut down on what you are selecting:

Select Fruit,Tree,Branch From Orchard Where Tree = 'Apple'

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.