Welche Auswirkungen haben Delta-Tabellen und der Statusbaum in einer versionierten Geodatabase auf die Abfrageleistung?

Wir haben eine versionierte arcsde-Geodatabase (arcgis 9.3.1 auf oracle 10g) mit einem ziemlich komplexen Datenmodell, das etwa 100 Feature-Classes und nicht räumliche Tabellen, ein geometrisches Netzwerk und viele Beziehungsklassen enthält.

Die Daten werden täglich von 5 oder 6 Arcmap-Benutzern mithilfe der SDE-Versionierung bearbeitet. Darüber hinaus werden Versionen von automatischen Diensten erstellt, die mit anderen Geschäftssystemen verbunden sind, um Änderungen in der Geodatabase vorzunehmen. Die Abfrageleistung nimmt im Laufe des Tages merklich ab, daher haben wir ein nächtliches Skript implementiert, um eine vollständige Komprimierung zu erreichen. In Fällen, in denen eine relativ große Anzahl von Änderungen durchgeführt wird, kann das System bis nach einer vollständigen Komprimierung unbrauchbar werden.

Es wurde vorgeschlagen, dass das konfigurierte Orakel keine anständigen Ausführungspläne erstellen kann, wenn es mit diesen flüchtigen Delta-Tabellen konfrontiert wird. Ist das eine vernünftige Erklärung? Welcher Ansatz sollte gewählt werden, um das Problem zu lösen?

Update als Antwort auf Kommentare

• Am Ende des Tages ist der Zustandsbaum sehr linear mit nur einer geringen Verzweigung.
• Wir komprimieren jede Nacht (erhalten Sie eine vollständige Komprimierung, indem Sie alle Versionen löschen).
• Business-Tabellen werden regelmäßig analysiert.
• Delta-Tabellen werden nicht analysiert. Sie sind gesperrt (Versuch, den Rückgabefehler "ORA-20005-Objektstatistik ist gesperrt" zu analysieren). Auch die flüchtigen Tabellen im SDE-Schema - STATES, STATE_LINEAGES - sind nicht enthalten.

Die Delta-Tabellen und der Statusbaum wirken sich direkt auf die Leistung Ihrer Abfragen aus.

Zunächst müssen Sie die Versionierung verstehen. Ich habe die Beziehung zwischen dem Statusbaum und den Versionsbezeichnungen in einer anderen Antwort kurz erklärt . Ich denke, es würde Ihnen helfen, darüber nachzudenken.

Nachdem Sie diese Antwort gelesen haben, können Sie feststellen, wie sich ein langer Zweig der Status-ID (von Root zu Status-ID, auf den ein Label verweist, auf die Leistung auswirkt. Warum? Weil Sie komplexere Verknüpfungen haben, um die "aktuelle" Ansicht der Version neu zu erstellen. Da die Komprimierung den Baum schneidet, können die inneren Verknüpfungen von der zugrunde liegenden Datenbank leichter verarbeitet werden, und Ihre ArcMap-Sitzungen werden schneller.

Sehen Sie sich das Dokument zu Versionierungsworkflows von ESRI an, in dem Sie lernen, wie Sie den Versionsstatusbaum unter Kontrolle halten. Verwenden Sie die GDBT , um den Statusbaum vorher und nachher anzuzeigen , damit Sie sehen können, wie sich ein guter Workflow auf den Baum auswirkt.

Zweitens: Wenn Sie es schaffen, das geometrische Netzwerk für die meisten Ihrer Anwendungsfälle nicht zu verwenden, tun Sie dies. Es wird die FeatureClasses verlangsamen , die beteiligt sind , weil sie komplexe Messaging für jede Zeile :: Shop Aufruf verwendet (im Gegensatz zu nur die Zeile in der Tabelle zu speichern und mit ihm getan wird).

Verwenden Sie zum Aktualisieren von Statistiken die Analysefunktion der Datenverwaltungstools (markieren Sie alle). Es wird wissen, wie man mit Delta-Tabellen (und allen anderen Tabellen) umgeht, die notwendig sind.

[Entschuldigung nach dem ersten Beitrag: Dies ist ein Kommentar, keine endgültige Antwort.] Wenn Sie Bearbeitungsversionen haben, die relativ alt sind und nicht veröffentlicht wurden, sollten sie gelöscht, veröffentlicht oder abgeglichen werden. Eine alte nicht abgestimmte Version behält eine alte Standardansicht bei, wodurch verhindert wird, dass Delta-Datensätze, die zu neueren Versionen gehören, in die Basistabellen komprimiert werden. Es kann eine große Anzahl dieser unkomprimierten Delta-Datensätze geben, die an eine alte Version angeheftet sind, und die Leistung wird beeinträchtigt, da alle Versionen Ansichten der Delta-Tabelle und der Basistabelle sind. Die Systemleistung hängt von der Anzahl der Änderungen ab, seit jede Version zuletzt abgeglichen (oder erstellt) wurde. Also kurz gesagt; Wenn es Versionen gibt, die Sie nicht veröffentlichen können, stimmen Sie sie regelmäßig ab und komprimieren Sie sie.