<\/HEAD>
現在、当県でParcel Fabricを実装するための開発およびテスト段階にあり、誰も解決策を持っていない極端なパフォーマンス問題に直面しています。<\/P>
<\/P>
簡単な背景として：数ヶ月前に、過剰な頂点を削除し、大部分を2点線に平面化することで線形作業を簡素化し（ただし、水系などの自然地物に沿った少数の区画境界はlinestringsのまま残しました）、区画の長期的なクリーンアッププロセスを完了しました。このクリーンアップで1000万以上の余分な頂点が削除されました。クリーンアップされた区画および分譲地データはさらに処理され、ESRI提供のステージングスキーマ（FGDB）にロードされ、すべてのトポロジーエラー／問題が修正され、その後新しいFabric（FGDB）に最終的にロードされました。このソースFabric FGDBは、その後Copy Parcel Fabricツールを介して当社のDevelopment SDE（ArcSDE 10.3.1 | Oracle 11.2.0.3）データベースにロードされました。<\/P>
<\/P>
最初のパフォーマンス問題はFabricをバージョン管理登録しようとした際に発生しました。バージョン管理プロセスは登録前にFabricオブジェクト／テーブルすべてに対して一連の「analyzes」を実行するため、この処理はハングしているように見えますが、実際には完了まで非常に長い時間がかかっています。当方の場合、「非常に長い時間」とは「Parcels」と「Lines」フィーチャクラスそれぞれが4～5時間かかったことを意味します。テーブル（および作成された各種インデックス）をざっと見たところ、「Lines」フィーチャクラスだけで290万本のライン／レコードがあります。私にはやや驚異的ですが、ESRI側からこれが異常だという指摘はありませんでした。<\/P>
<\/P>
登録が完了した後、基本的な編集テストを開始し、主に区画分割などの単純なParcel Fabricワークフローに焦点を当てました。ワークフロー内でConstructionツールが有効になるポイントで、カーソル／クロスヘアが非常に遅延し、マップウィンドウ上で移動するとポインターが砂時計になり（激しい処理が行われているかのように）、マウス操作を止めると10～15秒後にクロスヘアが戻ります…しかし再度動かそうとするとまた砂時計になります。反応しないポインターをConstructionラインフィーチャのスナップ距離内で待つと、クロスヘア復帰時にスナップしたかのように振る舞います。この状態でゆっくりカーソルを既にスナップされたフィーチャ上で動かすとクロスヘアは維持されますが、速く動かすかスナップ環境の許容範囲（10ピクセル）を超えると再び砂時計になります。十分我慢してこの間にラインフィーチャ構築を始めると、頂点追加や対応するラインフィーチャへのスナップ中ずっと同様の挙動が続きます。完了後は通常通り構築したフィーチャをビルドできます。<\/P>
<\/P>
追加テストで、「Classic Snapping」環境（TOC内でどのレイヤーやフィーチャタイプがスナップ可能か制御できる旧来の環境）をオンにし、すべてのレイヤーからスナップをオフにするとパフォーマンス問題は消えました。この時点でもFabric自体へのスナップは強制されており（必要なため）、すべてのレイヤーがスナップ不可でも機能します。しかしLines FCをオンに切り替えた瞬間、パフォーマンスは急激に低下します。<\/P>
<\/P>
興味深いことに、この挙動はFGDBでは発生しません。これはArcMap、SDE、およびOracleデータベース間でLines FCというデータ集約型フィーチャクラス特有の相互作用があることを示唆しています。ESRIはFabricテーブルの直接SQLによる再分析や空間インデックス再生成など複数手段を提供しましたが改善せず、SDE InterceptやOracleトレースファイルでも明確なボトルネックは特定されていません…これはI/O問題でもSQL処理問題でもないようです。<\/P>
<\/P>
Linesフィーチャクラス内の膨大なレコード数について懸念していますが、それが妥当な懸念かどうか裏付ける方法はありません。ArcMapはリアルタイムでLinesデータと対話する能力で明らかにつまずいていますが、それ以外には説明できません。FGDBはこの大規模フィーチャクラス用に独自の空間インデックス等を作成していますが滑らかに動作します。一方Oracleは300万レコード程度ならより堅牢なはずですが、このケースではパフォーマンスがひどく悪いです。したがって問題は単なるデータベースではなくアプリケーション側で何か起きていると考えています。<\/P>
<\/P>
もし同様の経験や洞察がおありでしたら、大変ありがたく思います！<\/P>
<\/P>
Gavin<\/P><\/BODY><\/HTML>
