AnsweredAssumed Answered

Slow - 10.4 Client with Sql Spatial Views

Question asked by cgishack on Apr 15, 2016
Latest reply on Feb 1, 2018 by mbalxnder

Like • Show 3 Likes3
Comment • 43

Hello,

We have recently upgraded our ArcMap instances to 10.4 and are now having performance issues with our SQL Spatial Views.

Querying on the database side is fine, its when the views are loaded into ArcMap 10.4 when the slowness starts. If I fiddle with the view I can make it perform better but its hit and miss. The 10.4 client is doing something because in 10.3 clients the views perform as expected.

Our SDE Geodatabase has also been upgraded to 10.4 and is running on SQL Server 2012 (64 bit)

One additional note: If I create the exact same view as a "Query Layer" in ArcMap the data performs as expected. Its only when its compiled as a SQLSpatial View when the slowness starts.

Has anyone else had this problem or have a solution?

Drew

vangelo-esristaff

Apr 15, 2016 11:52 AM

Correct Answer

Query Layers and registered spatial views are very different creatures. The registered views know the expected geometry type and expected data envelope due to metadata stored in the sde.sde_layers table. This allows the Direct Connect DLL to avoid using a spatial query constraint if it would be inefficient (e.g., it wouldn't significantly reduce the number of features).

You've also had some significant trauma to your database due to the various upgrades. Rebuilding all the indexes and all the index statistics would be a good course of action at this point. If you have any large (250k+ row) tables that are performing poorly, you should consider spatially sorting them into a new table, and measuring for spatial query performance.

In the future, please use specific time intervals in performance questions (e.g "17.3 minutes"), and include the topology type (point/line/poly) and the number of rows involved.

- V

See the reply in context

1 person had this question

Outcomes

43 Replies

vangelo-esristaff Apr 15, 2016 11:52 AM
Unmark Correct
Correct Answer
Query Layers and registered spatial views are very different creatures. The registered views know the expected geometry type and expected data envelope due to metadata stored in the sde.sde_layers table. This allows the Direct Connect DLL to avoid using a spatial query constraint if it would be inefficient (e.g., it wouldn't significantly reduce the number of features).

You've also had some significant trauma to your database due to the various upgrades. Rebuilding all the indexes and all the index statistics would be a good course of action at this point. If you have any large (250k+ row) tables that are performing poorly, you should consider spatially sorting them into a new table, and measuring for spatial query performance.

In the future, please use specific time intervals in performance questions (e.g "17.3 minutes"), and include the topology type (point/line/poly) and the number of rows involved.

- V
6 people found this helpful
Like • Show 3 Likes3
Actions
- cgishack @ vangelo-esristaff on Apr 15, 2016 1:28 PM
  Mark Correct
  Correct Answer
  Thanks for the reply Vince.
  The one key thing is that the spatial views work fine in a ArcMap 10.3 but slow in 10.4.
  
  I am doing testing on a Polygon feature class (parcels to be specific) and it takes about 12 minutes to load into ArcMap in 10.4 and maybe 15 seconds in 10.3 --- using the exact same sql spatial view. The parcels data is about 200,000 records.
  Inside the view is a very simply join to ownership data. I have seen this same issue on other sql spatial views with only 200 records.
  
  Thanks,
  
  Drew
  Like • Show 0 Likes0
  Actions
  - vangelo-esristaff @ cgishack on Apr 15, 2016 8:27 PM
    Mark Correct
    Correct Answer
    But they're different instances, with different database releases (?? - this wan't clear), right? Therefore 10.3/10.4 is not the only variable.
    
    What tweaks were you making to change view performance?
    
    In the end, you'll need to determine the optimizer query plan, and figure out why the query is processed so inefficiently.
    
    - V
    1 person found this helpful
    Like • Show 0 Likes0
    Actions
    - cgishack @ vangelo-esristaff on May 10, 2016 6:31 AM
      Mark Correct
      Correct Answer
      Sorry for the delayed reply. I just got caught up with other things.
      They are the same Database instance just different ArcMap Clients.
      
      10.4 = Slow
      10.3 = Fast
      Same data source, same query, same computer specs.
      
      We have noticed this on many different SQL Spatial views.
      We will be looking into it further in the coming days to see if we can see what is happening.
      
      Once last note, the same issue appears in ArcGIS Server also. Our 10.4 services renders the data very slow where 10.3 is blazing.
      1 person found this helpful
      Like • Show 0 Likes0
      Actions
      - bixb0012 @ cgishack on May 10, 2016 7:35 AM
        Mark Correct
        Correct Answer
        Are these spatial views being created new or were they created under <= 10.3.x and carried over? If the latter, have you tried deleting the views and re-creating them natively in 10.4?
        Like • Show 0 Likes0
        Actions
- mjarman-esristaff @ vangelo-esristaff on Dec 8, 2016 6:16 AM
  Mark Correct
  Correct Answer
  A new technical article has been created that sounds similar to this geonet thread - changes in the transaction model at 10.4 result in slower performance with joined views if the joined columns not being indexed properly.
  Problem: Performance of SQL Server views degrades after upgrading to ArcGIS 10.4
  4 people found this helpful
  Like • Show 2 Likes2
  Actions
Supriya_Khadke-esristaff May 12, 2016 8:54 AM
Mark Correct
Correct Answer
Hey Drew,

You mentioned that you also upgraded the geodatabase from 10.3 to 10.4. In SQL Server, this process should adjust the geodatabase properties to enable READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION, but if the user upgrading the geodatabase doesn't have the appropriate permissions it might not make that adjustment. Can you verify these two options are set to TRUE? See the link below for more information:

What's new in ArcMap—ArcGIS Help | ArcGIS for Desktop

Best,
Supriya
1 person found this helpful
Like • Show 0 Likes0
Actions
stevecaswell Jun 16, 2016 8:01 PM
Mark Correct
Correct Answer
Hi,

Did you ever solve this? We have exactly the same thing happening here. SQL Spatial Views created in 10.3 are terribly slow in Arcmap 10.4, i.e. a spatial view loaded into Arcmap 10.3.1 takes around 20 seconds to load, the same view takes 19 minutes to load in ArcMap 10.4.

As a test, I've created a fresh SQL database using the tools in ArcGIS 10.4, imported only the couple of datasets involved in the spatial view and freshly created the spatial view in this new database. Exactly the same result, seconds to load in 10.3.1, minutes in 10.4.

Like Drew, our web services using these spatial views with ArcGIS Server 10.4 are so terribly slow I have had to remove the spatial views and use other datasets to keep them up and running.

Both old and new SQL databases are SQL Server 2012, both have READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION enabled.

Any advice?

Thank you.

Steve
1 person found this helpful
Like • Show 0 Likes0
Actions
- cgishack @ stevecaswell on Jun 17, 2016 6:04 AM
  Mark Correct
  Correct Answer
  Hello Steve,
  We have not figured it out yet a full solution yet, but a patch is to actually paste the views SQL Code into ArcGMap as a Query Layer. It's messy but it keeps our AGS Services up and running without copies of the data.
  
  I checked the settings that Supriya suggested and everything looked good. ArcMap is doing something.
  We hope to open a ticket in the near future but just have not had the time to get a full demo up and running to send to ESRI.
  
  I hope this helps in the short term.
  
  Drew
  2 people found this helpful
  Like • Show 0 Likes0
  Actions
joonpark2 Aug 12, 2016 10:47 AM
Mark Correct
Correct Answer
Lately I've upgraded from ArcMap 10.2 to ArcMap 10.4 and have similar with "Add Layer" from layer file performance for SQL server. It got 5 times slower.
- I thought this was ArcObject issue but it's ArcMap itself. It seems it try to make new reconnect to SQL Server whenever reload same layer in same session. Something got worse and waiting response from ESRI.

If there is more information about this , please let me know .

Thanks guys
Like • Show 0 Likes0
Actions
Supriya_Khadke-esristaff Aug 22, 2016 2:19 PM
Mark Correct
Correct Answer
This issue might be related to the following bug that was recently logged:
BUG-000097186: Data displays slower in ArcGIS 10.4 for Desktop..
3 people found this helpful
Like • Show 6 Likes6
Actions
- bixb0012 @ Supriya_Khadke-esristaff on Aug 23, 2016 5:27 AM
  Mark Correct
  Correct Answer
  Thanks for the reference and link, it is always helpful. Given the bug is still "New" after 2+ months, it appears an Esri Development team hasn't even reviewed it yet. My guess, even if the root cause is found for 10.4.x, a patch won't be released. Think about installing 10.5 when it gets released.
  Like • Show 0 Likes0
  Actions
- tchapin @ Supriya_Khadke-esristaff on Nov 10, 2016 1:20 PM
  Mark Correct
  Correct Answer
  I have a support case connected to this bug as well. Getting in on this thread to keep up with any developments. Some SQL Server views work fine in 10.3, slow in 10.4.1, Pro 1.3.1 (some views are find in both, it depends on what they're doing). We did a lot of database design and even custom Pro SDK development around these views, so they're critical to us.
  Like • Show 0 Likes0
  Actions
- mkralarcdata-cz-esridist @ Supriya_Khadke-esristaff on Feb 2, 2017 12:33 AM
  Mark Correct
  Correct Answer
  Hi.
  
  Our customer had some simillar issue.
  By tracing display of same feature class (2.8M points) at ArcMAP 10.2.1 (display~40 seconds)/10.4.1 (display~100 seconds) we found that our problem is in fetching records from cursor.(same as is writen BUG-000097186: Data displays slower in ArcGIS 10.4 for Desktop)
  ArcMAP 10.4.1 simply fetches records in many 100 records buffers. (10.2.1 fetches everything at once)
  
  Trying same approach as 10.4.1 with just one call of exec sp_cursorfetch with total number of feature class records in SSMS we get to time 50 seconds (which would be fine) .
  By setting SDE_SERVER_CONFIG parameter MAXARRAYSIZE we were able to change size of record buffer from 100 to just 250 (setting higher had no effect) so the time of display improved slightly to aprox 75 seconds.
  Unfortunately from esri support came, that they do not know how to sett it (for further testing) any higher then those 250.
  Anyway I am alo convinced that setting it very high would help, but should be then thoroughly tested (it could also have some negative side effects by my opinion)
  
  Regards
  5 people found this helpful
  Like • Show 0 Likes0
  Actions
rozekc_washtenaw Oct 27, 2016 9:39 AM
Mark Correct
Correct Answer
This may be related, but I'm unable to publish a spatial view (from SQL server 2012) to our 10.4.1 ArcGIS Server. I can view it fine in ArcMap 10.4.1, and it publishes to our 10.3.1 ArcGIS Server without problems. The error I get when publishing to 10.4 is "Packaging succeeded, but publishing failed. ERROR 001487: Failed to update the published service with the server-side data location."
Like • Show 0 Likes0
Actions
- c_r_b @ rozekc_washtenaw on Nov 10, 2016 11:21 PM
  Mark Correct
  Correct Answer
  We are running into a very similar situation with ArcGIS Server v10.4.1: published map services in v10.4.1 with a query layer are extremely slow so as to be unusable, whereas the same MXD published to a v10.3.1 AGS instance -- using the same data layers in the same SDE instance (v10.2.2 on SQL Server 2014) -- perform as expected.
  When using the AGS JS API to browse the map services (pan, zoom, etc), each containing the same, single query layer, the following browse times are observed in Chrome Dev tools and SQL Server Profiler:
  
  - v10.4.1:
  o time for round trip in browser: 4m 36s
  o duration of time in database query: 349ms
  o number of database reads: 559,555
  
  - v10.3.1:
  o time for round trip in browser: 3.2s
  o duration of time in database query: 2.02s
  o number of database reads: 830,292
  
  Ignoring the differences (by a factor of 6) for the duration of the database query (since the db times are a small fraction of the total time w/ v10.4.1), it's pretty obvious that the bulk of the time of the request to v10.4.1 is spent in the AGS tier. At the time of the request, CPU and memory on the GIS server were not under strain and were not variable.
  
  In other map services that had multiple layers, when one of them was a query layer, the map services were equally slow, as were ALL map services on the v10.4.1 instance at the time the map service with the query layer was running. When the query layer was removed from the map service, performance returned to normal.
  The query itself references tables all within the same database and runs in 4s in SSMS for all features:
  SELECT Addresses.[LocationAddressID]
  , Addresses.[HouseNumberStreetNameFull]
  , Addresses.[ParcelID]
  , Locations.LocationPointID
  , Locations.Shape
  FROM [GIS].[Addresses_All] Addresses
  INNER JOIN [GIS].[LOCATIONPOINT] Locations
  ON Locations.LocationPointID = Addresses.LocationPointID
  WHERE Addresses.[LocationAddressID] IN
  (SELECT MIN(LocationAddressID) FROM [GIS].[Addresses_All] GROUP BY LocationPointID)
  
  The noted bug (BUG-000097186) refers only to ArcGIS Desktop -- not ArcGIS Server.
  
  ESRI: Is this also a known issue with ArcGIS Server? This should be simple to reproduce -- have you been able to do so? Other than downgrading to v10.3, what are my options?
  Like • Show 2 Likes2
  Actions
  - bixb0012 @ c_r_b on Nov 11, 2016 7:26 AM
    Mark Correct
    Correct Answer
    What patches have you applied to your 10.4.1 server? Although the ArcGIS for Server Publishing Patch doesn't seem to address thi issue directly, I wonder if it does address it nonetheless.
    Like • Show 0 Likes0
    Actions
    - cgishack @ bixb0012 on Nov 11, 2016 8:35 AM
      Mark Correct
      Correct Answer
      We tried this patch.. nothing changed.
      Our only fix is to use the Spatial View SQL code as the query layer instead of referencing the view itself.
      Like • Show 0 Likes0
      Actions
      - c_r_b @ cgishack on Nov 11, 2016 6:37 PM
        Mark Correct
        Correct Answer
        Thanks for the reply Drew.
        
        We actually already tried using the SQL from the spatial view in our query layer -- that's the code included in my post above. Before we did that, our query layer was (effectively) a simple 'SELECT * FROM OUR_SPATIAL_VIEW', and OUR_SPATIAL_VIEW had the SQL code above. Pulling the SQL into the query layer seemed to help at first, but subsequently performed poorly for us. The performance stats noted above were using the "full" SQL in our query layer.
        
        Would love to hear from Esri on this.
        Like • Show 0 Likes0
        Actions
        vangelo-esristaff @ c_r_b on Nov 16, 2016 7:31 AM
        Mark Correct
        Correct Answer
        If you want to hear from Esri on a topic, you should create a Tech Support incident. Second choice (but not nearly as effective) is to try to contact your local marketing rep, who has access to techincal resources for ad-hoc queries.
        
        While plenty of Esri staff participate in GeoNet, very few are authorized to speak for Esri, so the moment you write "Would love to hear from Esri on this" you discourage any further participation from Esri staff (which probably wasn't your intent).
        
        - V
        Like • Show 0 Likes0
        Actions
        c_r_b @ vangelo-esristaff on Nov 16, 2016 8:34 AM
        Mark Correct
        Correct Answer
        Got it. My expectations have been correspondingly lowered. (Again)
        Like • Show 2 Likes2
        Actions
        tchapin @ vangelo-esristaff on Nov 16, 2016 8:54 AM
        Mark Correct
        Correct Answer
        Vince, your comments are contrary to what I've been hearing from Esri at DevSummit and geodev meetups. I hope (and think Jim Barry would agree) that asking for Esri employee feedback in this forum is acceptable and encouraged. A bug has already been referenced above, so obviously people are using tech support. This thread has been an invaluable supplement to a tech support incident I've logged.
        
        BTW, there are other groups in Esri that use Geonet heavily. For example, the Pro SDK team asked their users to post questions on their content area, and they respond daily. It's been a huge help both with and without an official tech support incident.
        1 person found this helpful
        Like • Show 4 Likes4
        Actions
        vangelo-esristaff @ tchapin on Nov 16, 2016 1:18 PM
        Mark Correct
        Correct Answer
        Employee feedback is different than corporate feedback. Asking for an "Esri" response in a place where those with authority to respond on behalf of Esri do not participate does not increase the response rate. If the issue is a known bug without a resolution, there isn't much response that is possible.
        
        GeoNet is not intended to be a replacement for Tech Support. If you contact Tech Support, Esri has a better idea of the number of folks with a problem, and can notify you directly if/when a hot-fix or other resolution is found. If the bugfix does not resolve all issues, then this is something which should be caught earlier than later, and not participating in the process extends the time to response. Using GeoNet as a supplement to bug reports is one of the main reasons that GeoNet exists.
        
        - V
        Like • Show 0 Likes0
        Actions
tchapin Nov 16, 2016 8:57 AM
Mark Correct
Correct Answer
Hey Chris Beaudette and others experiencing this SQL view performance problem. I had luck adding an index to the attribute involved in the JOIN in my query. So Chris, try indexing your LocationAddressID field. I have no idea why 10.3.1 performs the same with and without the index, but for me, adding the attribute index brought 10.4.1 and Pro 1.3.1 performance down to the same speed as 10.3.
2 people found this helpful
Like • Show 0 Likes0
Actions
- c_r_b @ tchapin on Nov 16, 2016 10:44 AM
  Mark Correct
  Correct Answer
  Thanks Ted, good advice! An index should have existed on that table already, but didn't.
  
  Some interesting results this morning:
  - Before adding the index, querying the layer took ~3.7s in the browser (it was unusually fast this morning for some reason)
  - Added a unique, clustered index on Addresses.LocationAddressId (used in the WHERE clause): query took 43s.
  
  Completely counter-intuitive!
  
  Restarted the GIS service: 4.6 minutes
  
  Even less intuitive!
  
  While I was at it, I added a non-unique, non-clustered index to Addresses.LocationPointId (used in the JOIN) and a unique, non-clustered index on Locations.LocationPointId (also used in the JOIN). (Note that there was already a clustered index on OJBECTID in the Locations table, so I was forced to create a non-clustered index).
  
  Result (after restarting the map service): 4.5m
  Time spent in DB on "exec sp_cursorexecute ..." (the business end of the query with 554K reads): 381 ms
  
  For the balance of the duration of the request, the database is executing "exec sp_cursorfetch" commands twice per second, e.g. "exec sp_cursorfetch 180150129,2,1,100", until the response is returned to the browser, at which point the "exec sp_cursorfetch" commands cease.
  
  If I remove all indexes and restart the map service, a single request still took 4.5m.
  
  This is a development environment and I'm the only one hitting both the GIS server and the database. A SQL Profile trace confirms this.
  
  Note that my tests consist of panning a map service with a single query layer in it using the JS API in a Web browser.
  
  I suspect yours and my situations are different for environmental reasons unknown. Wish I could get this to work in a reliable manner, but it looks like my only option is to downgrade to AGS v10.3x.
  Like • Show 0 Likes0
  Actions
  - tchapin @ c_r_b on Nov 16, 2016 12:42 PM
    Mark Correct
    Correct Answer
    How did you add the index? Directly in SQL Server or using ArcCatalog?
    Like • Show 0 Likes0
    Actions
    - c_r_b @ tchapin on Nov 16, 2016 12:44 PM
      Mark Correct
      Correct Answer
      SQL
      Like • Show 0 Likes0
      Actions
      - tchapin @ c_r_b on Nov 16, 2016 12:54 PM
        Mark Correct
        Correct Answer
        Try creating the index with ArcCatalog in the feature class properties Index tab. That's how I did it. Now I'm curious to look under the hood and see what kind of index that creates.
        1 person found this helpful
        Like • Show 0 Likes0
        Actions
        c_r_b @ tchapin on Nov 16, 2016 1:28 PM
        Mark Correct
        Correct Answer
        That helped -- when adding the indexes via ArcCatalog, all round-trip requests to/from the browser were about 4-8s, depending on the zoom level. Remove the indexes, and requests took 4.5m again. Add them back in (via ArcCatalog), and they returned to 4-8s. Unfortunately that's still too slow for our purposes, especially when compared to v10.3 which is consistently about 2s regardless of scale.
        
        Thanks Ted Chapin! That's a good tip to know regarding adding indexes via ArcCatalog. We've got scripts that use SQL to add indexes to feature classes -- we're going to have to modify them to use the ArcPy methods to do so.
        
        Andrew Timmins: If you used SQL and not ArcCatalog to create your indexes, try using ArcCatalog and see if you get different results.
        Like • Show 0 Likes0
        Actions
cgishack Nov 16, 2016 10:25 AM
Mark Correct
Correct Answer
Just to add.. I tested our Views in the latest 10.5 release available on my.esri.com and the issue still exists.

I did try what Ted suggested about the index but no luck for us at this time.
1 person found this helpful
Like • Show 0 Likes0
Actions
- c_r_b @ cgishack on Nov 17, 2016 11:50 AM
  Mark Correct
  Correct Answer
  Sorry to hear this bug still exists at v10.5. Looks like we're stuck at 10.3.1 for a while. I've submitted a support request with the intention of getting this bug fixed.
  Like • Show 1 Like1
  Actions
  - cgishack @ c_r_b on Nov 17, 2016 12:12 PM
    Mark Correct
    Correct Answer
    I did try to create the index used in our JOIN though ArcCatalog today, there was no improvement for us.
    Thanks for the tip though.
    Like • Show 0 Likes0
    Actions
  - cswadner @ c_r_b on Mar 3, 2017 5:57 AM
    Mark Correct
    Correct Answer
    are you still having performance issues ?
    Like • Show 0 Likes0
    Actions
cgishack Aug 3, 2017 5:32 AM
Mark Correct
Correct Answer
Well its been just about a year since I posted the original question and I think we have finally fixed our problem.
Our views were not the most simple and there was a lot of areas to explore but in the end it all came down to data types.
We had a mix of varchar and nvarchar in some of our tables. These columns participated in the particular joins we had issues with. Once we redefined the columns needed to be varchar things go fast again! Just like the old 10.3 days

This is a huge relief for us as we have been holding all our desktop users back on 10.3 because of this.

I hope this helps others out there,

Drew
10 people found this helpful
Like • Show 5 Likes5
Actions
- WiscRapids @ cgishack on Dec 7, 2017 9:05 AM
  Mark Correct
  Correct Answer
  Is the specific relevant tech article for that solution Problem: Display performance of ArcSDE spatial views could be slow when the definition of join fields is different in pa… ?
  1 person found this helpful
  Like • Show 2 Likes2
  Actions
- rwelikal @ cgishack on Jan 9, 2018 12:33 PM
  Mark Correct
  Correct Answer
  Another way I was able to resolve this was using a versioned view as the left table (for a spatial view via a left outer join). The right table can be either view or standard table/feature class. Basically, the layer you're getting the geometry from has to be the versioned view. Even if it's not versioned, you can enable SQL Access through Catalog and still use the view. I think most newer versions of SDE automatically creates the view now anyway.
  2 people found this helpful
  Like • Show 3 Likes3
  Actions
  - c_r_b @ rwelikal on Jan 9, 2018 2:24 PM
    Mark Correct
    Correct Answer
    Good to know, thanks Ruchira Welikala. The versioned view gets created automatically by SDE when versioning or enabling archiving for a feature class. I don't think it gets created otherwise.
    
    Regarding this issue, we're still at v10.3.1 and hoping Esri fixes it by v10.5.x since that's our planned upgrade path.
    Like • Show 0 Likes0
    Actions
    - rwelikal @ c_r_b on Jan 9, 2018 5:58 PM
      Mark Correct
      Correct Answer
      Unfortunately, I'm on 10.5.1 and it's still not fixed, hah. From what I understand, it's not a bug, so I don't know if it'll ever be "fixed". But the method of using the database/versioned view seems to work lightning quick.
      Like • Show 0 Likes0
      Actions
      - cgishack @ rwelikal on Jan 9, 2018 6:17 PM
        Mark Correct
        Correct Answer
        Just in case you missed anything, did you check all your data types that are in your join and ensure they are the same data type? Also, does copy and pasting the view as a Query Layer fix the issue too?
        Like • Show 0 Likes0
        Actions
        rwelikal @ cgishack on Jan 9, 2018 6:30 PM
        Mark Correct
        Correct Answer
        They were both NVARCHAR. However, one had a field length of 30, and the other had a field length of 37. Initially before trying the versioned view method, I tried analyzing the tables as well as rebuilding indexes. For my spatial view using the versioned view, I kept the query the same as before (i created it using SSMS) but just swapped out the table name to reference the view rather than the base tables. Worked like a charm. The right table is a base table and not a view.
        Like • Show 0 Likes0
        Actions
- mbalxnder @ cgishack on Jan 29, 2018 1:52 PM
  Mark Correct
  Correct Answer
  I was having the same exact problem in 10.5, SQL 2016 and it was giving me a headache. Didn't even think to look at the data types. This made a HUGE difference - nightmare over! Thanks for posting!
  Like • Show 0 Likes0
  Actions
  - tpcolson @ mbalxnder on Feb 1, 2018 6:29 AM
    Mark Correct
    Correct Answer
    I've had great luck with https://www.red-gate.com/simple-talk/sql/learn-sql-server/sql-server-indexed-views-the-basics/ in increasing view performance
    Like • Show 0 Likes0
    Actions
    - mbalxnder @ tpcolson on Feb 1, 2018 12:39 PM
      Mark Correct
      Correct Answer
      Thanks Thomas, I'll take a look into that! Looks like the feedback on it was very positive. Appreciate the suggestion!
      Like • Show 0 Likes0
      Actions

GeoNet

The Esri Community

Slow - 10.4 Client with Sql Spatial Views

Outcomes

Related Content

Recommended Content

Incoming Links