バージョン対応のジオデータベースで、デルタテーブルと状態ツリーはクエリのパフォーマンスにどのような影響を与えますか？

バージョン化されたarcsdeジオデータベース（oracle 10gのarcgis 9.3.1）には、約100のフィーチャクラスと非空間テーブル、ジオメトリックネットワーク、および多くのリレーションシップクラスを含むかなり複雑なデータモデルがあります。

データは、sdeバージョン管理を利用して5人または6人のarcmapユーザーによって毎日編集されます。さらに、バージョンは、ジオデータベースで編集を実行するために他のビジネスシステムと連動する自動サービスによって作成されます。クエリのパフォーマンスは1日の間に著しく低下するため、完全な圧縮を実現するために毎晩スクリプトを実装しました。比較的多数の編集が実行される場合、システムは完全に圧縮されるまで使用できなくなる可能性があります。

設定されたoracleは、これらの揮発性デルタテーブルに直面した場合、まともな実行計画を立てることができないことが示唆されています。これは合理的な説明ですか？それを解決するためにどのようなアプローチを取るべきですか？

コメントに応じて更新

• 1日の終わりまでに、状態ツリーは非常に線形であり、分岐はほとんどありません。
• 毎晩圧縮します（すべてのバージョンを削除して完全な圧縮を取得します）。
• ビジネステーブルは定期的に分析されます。
• デルタテーブルは分析されません。それらはロックされています（分析しようとすると、エラー「ORA-20005オブジェクト統計がロックされています」が返されます）。sdeスキーマの揮発性テーブルもありません-STATES、STATE_LINEAGES。

デルタテーブルと状態ツリーは、クエリに直接的なパフォーマンスの影響を与えます。

まず、バージョン管理を理解する必要があります。別の答えで、状態ツリーとバージョンラベルの関係について簡単に説明しました。それを乗り越えるのに役立つと思います。

その回答を読んだ後、（ルートからラベルによって参照される状態IDへの）長い状態IDブランチがパフォーマンスにどのように影響するかを理解できます。なぜですか？バージョンの "現在の"ビューを再作成するためのより複雑な結合があるためです。圧縮によってツリーがトリミングされるため、内部結合は基になるdbによって処理しやすくなり、ArcMapセッションが高速になります。

見てみましょうバージョニングのワークフロー方法正気の制御下で、バージョン状態ツリーを保つためにお教えしますESRIから文書を。GDBTを使用して状態ツリーの前後を調べ、適切なワークフローがツリーにどのように影響するかを確認します。

次に、ほとんどのユースケースでジオメトリックネットワークを使用する必要がない場合は、それを実行します。それはされます、それはすべての行::ストア呼び出しのための複雑なメッセージングを使用しているため（だけでテーブルの行を格納し、それを行われているとは対照的に）関与しているのフィーチャクラスをスローダウン。

統計を更新するには、データ管理ツールの分析機能を使用します（すべてにマークを付けます）。必要なデルタテーブル（およびその他のテーブル）の処理方法を知っています。

[最初の投稿の謝罪：これは決定的な回答ではなくコメントであることを意味します。]比較的古く、投稿されていない編集バージョンがある場合は、削除、投稿、または調整する必要があります。古い未調整のバージョンでは、古いデフォルトのビューが維持されるため、新しいバージョンに属するデルタレコードがベーステーブルに圧縮されません。すべてのバージョンがデルタテーブルとベーステーブルのビューであるため、古いバージョンに固定されたこれらの非圧縮デルタレコードが大量に存在する可能性があり、パフォーマンスが影響を受けます。システムのパフォーマンスは、各バージョンが最後に調整（または作成）されてからの編集数に関連しています。要するに、投稿できないバージョンがある場合は、定期的に調整して圧縮します。