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