Vraag
Het tekenen van Feature Classes uit een Enterprise Geodatabase in volledige extent, de navigatie op de kaart of het uitvoeren van queries verloopt traag. Wat is de oorzaak hiervan en hoe kan ik de performance verbeteren?

Oorzaak
Er zijn verschillende oorzaken voor onvoldoende performance van Feature Classes uit een Enterprise Geodatabase. Dit artikel beschrijft een aantal vaak voorkomende oorzaken van performanceproblemen en mogelijke oplossingen.

Antwoord
Hier volgen een aantal vaak voorkomende oorzaken:

• De statistieken en indexen zijn niet up-to-date
  
  Actuele indexen en database statistieken zijn cruciaal bij het werken met data in een database. Onder http://support.esri.com/en/knowledgebase/techarticles/detail/24518 staan scripts voor het actualiseren van relevante database statistieken en indexen voor Oracle en SQL Server. Voor het uitvoeren van deze scripts zijn dba rechten nodig. Om zonder dba rechten voor een specifieke Feature Class database statistieken te laten berekenen, kun je in ArcGIS Desktop of ArcGIS Pro, ingelogd als de eigenaar van de data, de ‘Analyze’ tool gebruiken. Ook bestaat er een ‘Analyze Datasets’ tool waarmee je statistieken voor alle tabellen en in een gebruikerschema kunt laten berekenen. Als je ingelogd bent als de Geodatabase administrator, kun je ook voor de Geodatabase repository tabellen (tabellen van de schema owner SDE) statistieken laten berekenen. Dit is van belang bij het werken met versioning.
  
  Indexen van een feature class kun je actualiseren met behulp van een script (zie bovenstaande link) of met de ‘Rebuild Indexes’ tool in ArcGIS Desktop of ArcGIS Pro.
  
  Het actualiseren van indexen en statistieken kan ook met Python geautomatiseerd worden, zie ook http://desktop.arcgis.com/en/arcmap/latest/tools/data-management-toolbox/rebuild-indexes.htm#C_GUID-85C3554A-4265-44FE-9CF7-329C9EDCA651 en http://desktop.arcgis.com/en/arcmap/latest/tools/data-management-toolbox/analyze.htm#C_GUID-53439A74-F488-4FDF-A56B-EACE85DEF977.
  
  
• De versioning workflow is niet optimaal
  
  Bij het werken met geversionde data (‘Register as Versioned’) en een groot aantal edits, kan de performance van de database achteruit gaan. Onderstaand zijn een aantal aanbevelingen genoemd om de performance optimaal te houden:
  
  • De performance in een geversionde database is sterk afhankelijk van het aantal states en het aantal records in de adds en deletes tabellen. Voer daarom op regelmatige basis een compress uit. Hiermee verwijder je niet meer benodigde states, en verplaats je de records van de adds en deletes tabellen die gelijk zijn in alle versies naar de base tabellen. Voor het uitvoeren van een compress kun je de ‘Compress’ tool uit ArcToolbox gebruiken.
  • Als de workflow het toelaat kun je de database op regelmatige basis compressen naar state 0 en de adds en deletes tables helemaal leeg maken. Om een database te kunnen compressen naar state 0, moeten alle versies gereconciled en gepost worden met de DEFAULT versie, en vervolgens verwijderd worden. De hierop aansluitende compress zal alle records uit de adds en deletes tables terug brengen naar de base tables. Een handleiding hiervoor staat onder http://support.esri.com/en/knowledgebase/techarticles/detail/29160. Is het vanwege de workflow niet mogelijk alle versies te posten naar de DEFAULT versie? Voer dan in ieder geval een reconcile uit van alle bestaande versies met de DEFAULT versie. Hierdoor maak je de bewerkingen die gemaakt zijn in de DEFAULT versie ‘bekend’ bij alle andere versies, en kunnen in ieder geval de bewerkingen die zijn uitgevoerd in de DEFAULT versie gecompressed worden naar de base table.
  • Verwijder versies die aangemaakt zijn om te testen, of niet meer benodigde versies. Deze versies kunnen de compress van states tegen houden en de performance hierdoor negatief beïnvloeden.
  • Als het mogelijk is, houdt dan de versie boom ‘plat’. Maak dus niet ‘een child versie van de child versie van de child versie’ aan.
  • Zorg ervoor dat na het uitvoeren van bulk edits deze records zo snel mogelijk naar de base tables gecompressed worden. Reconcile en post hiervoor de bewerkte versie met de DEFAULT versie. Reconcile vervolgens alle andere versies met de DEFAULT versie, en voer aansluitend een compress uit.
  
  Het reconcilen, posten en verwijderen van versies en het uitvoeren van een compress kan helemaal geautomatiseerd worden, zie ook http://desktop.arcgis.com/en/arcmap/latest/manage-data/geodatabases/using-python-scripting-to-batch-reconcile-and-post-versions.htm.
  
  
• Er worden statistieken berekend op de sde logfile tables
  
  De inhoud van de logfile tabellen (SDE_LOGFILE_DATA) verandert snel en is heel dynamisch. Het berekenen van statistieken over de inhoud van deze tabellen tijdens het uitvoeren van selecties heeft een negatieve invloed op de performance. Wij adviseren om op de SDE_LOGFILE_DATA tabellen geen statistieken te laten berekenen, en bestaande statistieken te verwijderen. De procedure hiervoor staat beschreven onder http://support.esri.com/en/knowledgebase/techarticles/detail/37841. 
  
  Een andere optie is om de SDE log file tables als global temporary tables aan te maken. Dit kan de performance nog eens verbeteren omdat er geen redo log and backup informatie gegenereerd wordt. Volg de handleiding onder http://support.esri.com/en/knowledgebase/techarticles/detail/32161 om de log file tables als global temporary tables aan te maken. Vanaf ArcGIS 10.5 worden in SQL Server en PostgreSQL databases standaard temporary log file tables gebruikt. Voor eerdere ArcGIS versies kan de handleiding onder http://support.esri.com/en/knowledgebase/techarticles/detail/32161gebruikt worden. 
  
  Als de performance nog steeds achterblijft bij het uitvoeren van selecties, dan bestaat er nog de optie om selecties niet in de database, maar op de client computer op te slaan. Standaard worden tot 100 geselecteerde records op de client gecached. Selecties van meer dan honderd records worden in de SDE_LOGFILE_DATA tabellen opgeslagen. Je kunt het aantal records dat op de client gecached wordt verhogen. Dit kan met behulp van een registry setting. Voor een stappenplan voor het aanmaken van deze registry key bestaat een technisch artikel van Esri Inc.: http://support.esri.com/en/knowledgebase/techarticles/detail/22668.
  
  
• Er wordt gebruik gemaakt van views met complexe where clauses
  
  De performance van views met complexe where clauses blijft weleens achter. Een optie kan zijn om in ArcMap, in de properties van de layer in het tabblad ‘Definition Query’, de optie ‘Attribute First’ aan te zetten. Deze instelling heeft ook effect als er geen definition query gebruikt wordt. Hierdoor wordt éérst de attribute query van de view uitgevoerd en dan pas de ruimtelijke query zoals een pan of zoom. Als de performance van views niet voldoende is dan adviseren wij het gebruik van materialized views. Maak een materialized view aan en vergelijk de performance met je gewone view. Onder http://www.esri.nl/support/technische-artikelen/arcgis-for-server-vragen#225 stellen wij een handleiding ter beschikking voor het aanmaken van een materialized view in Oracle.