ジオデータベースの圧縮処理
ジオデータベースの圧縮処理により、バージョンおよびバージョン対応の編集を追跡しているシステム テーブルから不要なステートおよび行を削除します。
ヒント: 圧縮を理解するには、まずバージョニングの仕組みを理解する必要があります。この概念に詳しくない場合は、「バージョニングの概要」をご参照ください。
圧縮処理とは
圧縮操作で、バージョンに参照されなくなったステートを削除し、差分テーブルの行をビジネス テーブルに移動することができます。圧縮操作を実行できるのは ArcSDE の管理者だけです。圧縮操作は、バージョンの所有者にかかわらず、ジオデータベースのすべてのステートに対して実行されます。
ジオデータベースが編集されるに従って、差分テーブルのサイズとステートの数が増えていくため、圧縮処理を行う必要があります。テーブルのサイズとステートの数が増えるにつれ、バージョンの表示や検索のたびに ArcGIS が処理しなければならないデータは増えていきます。パフォーマンスに最も大きな影響をおよぼすのは、バージョンの数ではなく、各バージョンの差分テーブルに含まれている変更の量です。各バージョンへの変更の量によって、バージョンの表示や検索のクエリ応答時間が異なる可能性があります。
データベースのパフォーマンスを維持するために、ArcSDE 管理者は圧縮処理を定期的に実行して、使用されなくなったデータを削除する必要があります。
ArcCatalog の [圧縮] コマンド、[圧縮] ジオプロセシング ツール、または Python スクリプトを使用して、ジオデータベースを圧縮することができます。[圧縮] コマンドを ArcCatalog で使用可能にする方法の詳細については、「ArcCatalog への [圧縮] コマンドの追加」をご参照ください。また、ジオプロセシング ツールまたはスクリプトの詳細については「圧縮」をご参照ください。
圧縮処理の仕組み
圧縮処理では、まず、メモリ内でインスタンスのステート ツリー構成を走査します。この情報に基づいて、バージョンの系統に属していないステートをすべて削除します。ステートを削除すると、そのステートに関連付けられている差分テーブルの行もすべて削除されます。
圧縮処理の次のステップは、候補系統のステートを 1 つのステートにまとめることです。候補系統とは、特定バージョンのテーブルの論理表現に影響を与えずに 1 つのステートに圧縮できる、ステートのコレクションです。
最後のステップでは、可能であれば差分テーブルの行をベース テーブルに移行します。
圧縮処理の各ステップで、テーブルを圧縮するたびにデータベース トランザクションが開始および終了されます。トランザクションは、圧縮処理の各ステップでテーブルの整合性を確認します。
圧縮処理はトランザクション的に一貫性を維持するように設計されているため、実行中に停止または終了することができます。このため、圧縮処理でエラーが発生したり不意に終了したりしても、圧縮しているバージョン対応のテーブルは、どのバージョン表現に関しても論理的に正確です。圧縮処理を停止する理由の 1 つとして、ユーザがジオデータベースに接続しているときに圧縮処理を実行し、圧縮に非常に多くのシステム リソースが消費されていることに気づいた場合があります。この場合、圧縮処理を停止し、接続しているユーザが少ししかいない、またはまったくいないときに圧縮処理を実行します。
最長時のトランザクションに十分に対応できるサイズの論理ログを作成してください。一般的に、ジオデータベースを圧縮するときは、長時間のトランザクションが発生します。onformix onconfig ファイルの LTXHWM パラメータで定義されているロング トランザクション上限基準点の比率に達する前に、論理ログをバック アップしておく必要があります。Informix Spatial DataBlade の振舞いを熟知している Informix の技術サポート エクスパートの同意を得ずに、LTXHWM または LTXEHWM パラメータのどちらかを変更しないでください。ロング トランザクション上限基準点に達したために、トランザクションが終了できずにロールバックされる場合、論理ログのサイズが十分でないことを意味します。
大きなジオデータベースの圧縮中に、Informix データベースでは利用できるロックが不足することがよくあります。 これを防ぐために、圧縮している間、テーブルは占有モードでロックされます。ArcSDE 9 の場合、ユーザが接続していても圧縮を実行することができます。ユーザの接続を維持したままの圧縮を可能にするには、圧縮中の占有ロックを無効にしておく必要があります。USE_EXCLUSIVE_LOCKING DBTUNE パラメータを false に設定して、同時に接続しているユーザが圧縮を実行できるようになります。sdedbtune による変更操作をして USE_EXCLUSIVE_LOCKING パラメータの値を変更することができます。sdedbtune コマンドの使用方法については、『ArcSDE コマンド リファレンス』をご参照ください。
ジオデータベースの完全圧縮
完全に圧縮されたジオデータベースでは、差分テーブルに行がなく、ステート ツリーは 0 になっています。ジオデータベースが完全に圧縮された場合、パフォーマンスが最も最適な状態になります。これを実行するには、次の手順を実行します。
*ArcIMS サービス（ArcIMS マップ サービスを除く）はステートのロックを取得しないため、圧縮処理に影響を与えません。ArcIMS マップ サービスを含む ArcGIS クライアントはロックを取得するため、圧縮に影響を与えます。
各圧縮処理の結果は、ジオデータベースの COMPRESS_LOG テーブルで確認することができます（SQL Server および PostgreSQL データベースの場合は SDE_compress_log テーブル）。VERSIONS テーブル（SQL Server および PostgreSQL データベースの場合は SDE_versions テーブル）をオンにして、DEFAULT バージョンのステート ID が 0 に戻っているかどうかを確認することもできます。ステート ID が 0 で、未処理のバージョンが他に残っていない場合は、完全圧縮が完了しています。
圧縮処理を開始する前に、バージョンをリコンサイル、ポスト、削除し、すべてのユーザを切断することが常に可能であるとは限りません。たとえば、バージョンを使用して履歴を管理している、またはプロジェクトの設計バージョンを維持する必要がある場合、履歴バージョンと設計バージョンはステート ツリーのステートを参照したままです。したがって、ジオデータベースを圧縮しても、これらのステートは削除されません。ただし完全圧縮を実行しなくても圧縮を行うことは可能であり、パフォーマンスを向上させることができます。
圧縮処理の実行方法については、「ArcGIS Server Enterprise でライセンスされる ArcSDE ジオデータベースの圧縮」をご参照ください。
圧縮処理の頻度
圧縮処理を実行する頻度は、ジオデータベースで実行される編集の量に基づきます。編集の量が多い場合は、おそらく 1 日に 1 回ジオデータベースを圧縮する必要があります。編集の量が平均的または少ない場合でも、通常は週に 1 回程度ジオデータベースを圧縮します。
注意:圧縮処理の間隔を空けすぎないことが重要です。バージョン対応の編集操作の量が多ければ多いほど、ジオデータベースの圧縮にかかる時間も長くなります。ジオデータベースを最低でも週に 1 回圧縮しないと、編集量によっては圧縮に数時間かかることがあります。
ジオデータベースの圧縮後の操作
圧縮処理を実行した後は、ジオデータベースの統計を更新する必要があります。統計情報の更新の詳細は、「解析を使用したジオデータベースの統計情報の更新」およびお使いの DBMS（Database Management System）に関するトピックをご参照ください。