Dans une géodatabase versionnée, quel impact les tables delta et l'arborescence d'état ont-elles sur les performances des requêtes?

Nous avons une géodatabase arcsde versionnée (arcgis 9.3.1 sur oracle 10g) avec un modèle de données assez complexe qui comprend environ 100 classes de fonctions et tables non spatiales, un réseau géométrique et de nombreuses classes de relations.

Les données sont éditées quotidiennement par 5 ou 6 utilisateurs arcmap utilisant le versioning sde. De plus, les versions sont créées par des services automatiques qui s'interfacent avec d'autres systèmes d'entreprise pour effectuer des modifications dans la géodatabase. Les performances des requêtes dégénèrent sensiblement au cours de la journée, nous avons donc implémenté un script nocturne pour obtenir une compression complète. Parfois, lorsqu'un nombre relativement important de modifications est effectué, le système peut devenir inutilisable jusqu'à une compression complète.

Il a été suggéré qu'Oracle, tel qu'il était configuré, ne pouvait pas proposer de plans d'exécution décents lorsqu'il était confronté à ces tables delta volatiles. Est-ce une explication raisonnable? Quelle approche faut-il adopter pour le résoudre?

Mise à jour en réponse aux commentaires

• À la fin de la journée, l'arbre d'état est très linéaire, avec seulement une petite ramification.
• Nous compressons tous les soirs (obtenez une compression complète en supprimant toutes les versions).
• Les tableaux d'entreprise sont analysés régulièrement.
• Les tableaux Delta ne sont pas analysés. Ils sont verrouillés (Tentative d'analyse renvoie l'erreur "Les statistiques des objets ORA-20005 sont verrouillées"). Les tables volatiles du schéma sde non plus - STATES, STATE_LINEAGES.

Les tables delta et l'arborescence des états ont un impact direct sur les performances de vos requêtes.

Tout d'abord, vous devez comprendre le contrôle de version; J'ai fait une brève explication de la relation entre l'arbre d'état et les étiquettes de version dans une réponse différente . Je pense que cela vous aiderait à y revenir.

Après avoir lu cette réponse, vous pouvez alors comprendre comment une branche d'ID d'état long (de la racine à l'ID d'état référencé par une étiquette aurait un impact sur les performances. Pourquoi? Parce que vous avez des jointures plus complexes pour recréer la vue "actuelle" de la version. Étant donné que la compresse coupe l'arbre, les jointures internes deviennent plus faciles à traiter par la base de données sous-jacente et vos sessions ArcMap deviennent plus rapides.

Jetez un coup d'œil au document sur les flux de travail de version d'ESRI qui vous apprendra comment garder l'arborescence de l'état des versions sous contrôle sain. Utilisez le GDBT pour regarder l'arbre d'état avant et après afin de voir comment un bon flux de travail affecte l'arbre.

Deuxièmement, si vous pouvez vous en tirer sans avoir à utiliser le réseau géométrique pour la plupart de vos cas d'utilisation, faites-le. Il va ralentir les FeatureClasses qui sont impliqués , car il utilise la messagerie complexe pour chaque ligne :: appel magasin (par opposition à un stockage de la ligne dans la table et se fait avec elle).

Pour mettre à jour les statistiques, utilisez la fonction d'analyse des outils de gestion des données (marquez-les toutes). Il saura comment gérer les tables delta (et toutes les autres tables) qui sont nécessaires.

[Excuses du premier message: il s'agit d'un commentaire et non d'une réponse définitive.] Si vous avez des versions modifiées relativement anciennes et qui n'ont pas été publiées, elles doivent être supprimées, publiées ou rapprochées. Une ancienne version non rapprochée conserve une ancienne vue par défaut, ce qui empêche les enregistrements delta appartenant aux versions plus récentes d'être compressés dans les tables de base. Il peut y avoir un grand nombre de ces enregistrements delta non compressés épinglés à une ancienne version et les performances sont affectées car toutes les versions sont des vues sur les tables delta et de base. Les performances du système sont liées au nombre de modifications depuis la dernière réconciliation (ou création) de chaque version. Donc en bref; s'il existe des versions que vous ne pouvez pas publier, réconciliez-les régulièrement et compressez.