ジオデータベースの圧縮処理
ジオデータベースの圧縮処理により、バージョンおよびバージョン対応の編集を追跡しているシステム テーブルから不要なステートおよび行を削除します。
ヒント: 圧縮を理解するには、まずバージョニングの仕組みを理解する必要があります。この概念に詳しくない場合は、「バージョニングの概要」をご参照ください。
圧縮処理とは
圧縮操作で、バージョンに参照されなくなったステートを削除し、差分テーブルの行をビジネス テーブルに移動することができます。圧縮操作を実行できるのは ArcSDE の管理者だけです。圧縮操作は、バージョンの所有者にかかわらず、ジオデータベースのすべてのステートに対して実行されます。
ジオデータベースが編集されるに従って、差分テーブルのサイズとステートの数が増えていくため、圧縮処理を行う必要があります。テーブルのサイズとステートの数が増えるにつれ、バージョンの表示や検索のたびに ArcGIS が処理しなければならないデータは増えていきます。パフォーマンスに最も大きな影響をおよぼすのは、バージョンの数ではなく、各バージョンの差分テーブルに含まれている変更の量です。各バージョンへの変更の量によって、バージョンの表示や検索のクエリ応答時間が異なる可能性があります。
データベースのパフォーマンスを維持するために、ArcSDE 管理者は圧縮処理を定期的に実行して、使用されなくなったデータを削除する必要があります。
ArcCatalog の [圧縮] コマンド、[圧縮] ジオプロセシング ツール、または Python スクリプトを使用して、ジオデータベースを圧縮することができます。[圧縮] コマンドを ArcCatalog で使用可能にする方法の詳細については、「ArcCatalog への [圧縮] コマンドの追加」をご参照ください。また、ジオプロセシング ツールまたはスクリプトの詳細については「圧縮」をご参照ください。
圧縮処理の仕組み
圧縮処理では、まず、メモリ内でインスタンスのステート ツリー構成を走査します。この情報に基づいて、バージョンの系統に属していないステートをすべて削除します。ステートを削除すると、そのステートに関連付けられている差分テーブルの行もすべて削除されます。
圧縮処理の次のステップは、候補系統のステートを 1 つのステートにまとめることです。候補系統とは、特定バージョンのテーブルの論理表現に影響を与えずに 1 つのステートに圧縮できる、ステートのコレクションです。
最後のステップでは、可能であれば差分テーブルの行をベース テーブルに移行します。
圧縮処理の各ステップで、テーブルを圧縮するたびにデータベース トランザクションが開始および終了されます。トランザクションは、圧縮処理の各ステップでテーブルの整合性を確認します。
圧縮処理はトランザクション的に一貫性を維持するように設計されているため、実行中に停止または終了することができます。このため、圧縮処理でエラーが発生したり不意に終了したりしても、圧縮しているバージョン対応のテーブルは、どのバージョン表現に関しても論理的に正確です。圧縮処理を停止する理由の 1 つとして、ユーザがジオデータベースに接続しているときに圧縮処理を実行し、圧縮に非常に多くのシステム リソースが消費されていることに気づいた場合があります。この場合、圧縮処理を停止し、接続しているユーザが少ししかいない、またはまったくいないときに圧縮処理を実行します。
圧縮トランザクションはきわめて大きなものになる可能性があります。したがって、UNDO 領域を自動的に管理するように設定された Oracle データベースの場合は、ArcSDE 管理者の UNDO_POOL パラメータの値が小さすぎないことと、圧縮処理を実行するのに十分な UNDO 表領域が存在することを確認します。
ジオデータベースの完全圧縮
完全に圧縮されたジオデータベースでは、差分テーブルに行がなく、ステート ツリーは 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）に関するトピックをご参照ください。