ブランチ履歴は、データセットがブランチ バージョン対応登録されてから、デフォルト バージョンに対する編集を保存および管理するためにビジネス テーブルに追加されたすべての変更の詳細な説明を提供します。
ブランチ バージョニングでは、データ モデルが簡素化されるため、管理ワークフローが効率化されます。ブランチ バージョニングは、時系列 (時間関連) の挿入専用モデルで機能し、すべての編集内容は 1 つのテーブルに記録されます。 挿入専用モデルとは、編集操作ごとに対応するタイムスタンプ付きで挿入処理が行われることを意味し、すべての変更 (削除を含む) の完全な履歴記録を実現します。 この方法により、時間経過に伴い進化するデータの視覚化と解析が可能になります。
差分テーブルを利用して、それを他のシステム テーブルと結合して特定のバージョンのデータを表すトラディショナル バージョニングとは異なり、ブランチ バージョン対応のフィーチャクラスは、単一テーブル モデルを使用した履歴管理をネイティブにサポートするよう設計されています。 データセットがブランチ バージョン対応登録されると、履歴管理が自動的に有効になり、ビジネス テーブルにバージョン間の編集を保存および管理するためのフィールドが追加されます。
すべての編集 (挿入、更新、削除) を管理するために、ブランチ バージョン対応のフィーチャクラスまたはテーブルのビジネス テーブルに 6 つの特定のシステム フィールドが追加されます。
- GDB_BRANCH_ID- 編集が行われたバージョンを識別します。
- GDB_FROM_DATE- 編集が行われた正確な日時を記録します。
- GDB_IS_DELETE- フィーチャが削除されたかどうかをバイナリ値 (削除されていない場合は 0、削除された場合は 1 または 2) を使用して示します。
- GDB_DELETED_AT- フィーチャが削除された日時を記録します。
- GDB_DELETED_BY- フィーチャを削除したユーザーを記録します。
- GDB_ARCHIVE_OID- テーブル内の各行を一意に識別し、すべての編集を個別の ID で追跡します。
注意:
フィーチャクラスまたはテーブルに GDB_DELETED_AT および GDB_DELETED_BY フィールドが追加され、これによって削除の追跡が可能になります。これは、標準の編集情報の記録フィールドと併用されます。
データセットのブランチ バージョン対応登録の要件とプロセスの詳細
履歴管理が有効化されたデータには、次のようなさまざまな用途があります。
- 履歴解析とレポートの実行
- 監査を通じたコンプライアンスの保証
- 特定時点に存在したデータセットのエクスポート
ブランチ履歴のプルーン
ブランチ バージョニング モデルによって、時間経過に伴いビジネス テーブル内のデータは増加します。このモデルは、編集ごとに新しいレコードを挿入することですべての変更を追跡するため、大量のデータが累積する可能性があります。 ブランチ バージョン対応データセットの履歴のプルーンは、不要になった履歴レコードの削除、ストレージの最適化、パフォーマンスの向上などを行います。
時間経過に伴い大量のストレージを消費する可能性がある履歴データの増加を管理するには、プルーンが必要です。 次のような特定の状況下では、データセットから履歴管理レコードをプルーンすることをおすすめします。
- 運用上の目的で履歴データが不要になった場合
- 不要な履歴レコードを削除して格納領域を開放する場合
- ストレージ コストを削減する場合
ArcGIS Pro 3.5 以降では、[ブランチ履歴のプルーン (Prune Branch History)] ジオプロセシング ツールを使用して、ブランチ バージョン対応のデータセットのストレージを管理および最適化できます。 ブランチ履歴のプルーン ツールには詳細な制御機能があり、「日付より前をプルーン」の設定など、設定した条件に基づいて保持する特定のレコードを決定することができます。
ブランチ履歴のプルーン ツールの詳細
ブランチ履歴のプルーン ツールは、履歴データを効果的に管理できるよう設計されています。 その主な機能は次のとおりです。
- 履歴データの削除 - このツールを使用すると、指定した日付に基づいてクラスから履歴データを削除できます。 それより古い廃止されたデータは履歴から削除されます。 廃止された行は、より新しいリプレゼンテーションが存在するアーカイブ内の行か、削除されるフィーチャの最後のリプレゼンテーションの行として定義されます。 つまり、その行はデータの最新バージョンでなくなり、最近の更新によって破棄されたか、削除対象としてマークされています。 これは、最新でなくなった情報や不要な情報を削除してデータベースのサイズを管理するのに特に役立ちます。
- 現在アクティブな行の保持 - [ブランチ履歴のプルーン (Prune Branch History)] ツールの主な機能の 1 つは、アクティブな行が削除されないようにすることです。 アクティブな行は、削除されていないフィーチャの最新のリプレゼンテーションとして定義されます。 この行はデータの現在の状態を表し、削除済みとしてマークされていません。 フィーチャが指定した日付より前に存在し、まだアクティブである場合、そのフィーチャは保持されます。 このツールは、関連性がなくなった履歴データのみを削除することに重点を置いています。
- 参照されるデータの保護 - このツールは、アクティブなバージョンからまだ参照されているデータのプルーンを回避します。 バージョンが古いデータを含むモーメントを指している場合、そのデータは参照されなくなるまでプルーンされません。
- リコンサイル - 長期間存在するバージョンの場合、データを確実にプルーンできるようにリコンサイルする必要がある場合があります。 これは、長期間にわたってシステム内に存在するデータをツールで管理する場合に特に当てはまります。 共通の上位バージョンと前の上位が両方ともプルーン モーメントより前である場合は、バージョンを 2 回リコンサイルする必要があります。
- カスタマイズ可能な履歴保持 - 組織は、保持する履歴データの量を決定できます。 たとえば、過去 2 年または 5 年の履歴を保持し、それを超える履歴はすべてプルーンすることができます。 この適応性によって、貴重な履歴データの保持と、全体的なデータベース サイズの管理のバランスをとることができます。
ブランチ履歴のプルーン ツールは、バージョン非対応の履歴管理データセットでサポートされているアーカイブ履歴の削除ツールに似ています。 しかし、[ブランチ履歴のプルーン (Prune Branch History)] ツールは、ブランチ バージョン対応登録されたデータセットに対して明確に作成されています。 [ブランチ履歴のプルーン (Prune Branch History)] ツールでは、「レポートのみ」パラメーターを使用してレポートを生成できます。これは、実際にはレコードをプルーンしないで、対象となるアーカイブ レコードの合計数を提供します。 さらに、「システム テーブルのみをプルーン」を選択することもできます。 このオプションをオンにすると、コントローラー データセットの対象となる内部システム テーブルのみがプルーンされるかログに記録されます。
ブランチ履歴のプルーンに関する重要な概念と注意事項
ブランチ履歴と [ブランチ履歴のプルーン (Prune Branch History)] ツールに関連するいくつかの概念を理解することが重要です。 次のセクションでは、これらの概念について詳しく説明します。
日付より前をプルーン
[日付より前をプルーン] は、プルーン時のデータを考慮するためのカットオフをマークするユーザー定義の日付/時刻パラメーターです。 [日付より前をプルーン] を設定すると、参照モーメントと競合しなければ、このモーメントより前のすべてのレコードがプルーン操作で削除される候補になります。
[ブランチ履歴のプルーン (Prune Branch History)] ツールを使用する前に、明確な目的を念頭に置いて、法的要件などの特定のニーズを反映した適切な「日付より前をプルーン」を選択することが重要です。
たとえば、[日付より前をプルーン] を 2022 年 1 月 1 日に設定した場合、この時点より古い廃止されたすべてのデータがプルーンの対象になります。
参照モーメント
参照モーメントは、特定のレコードをプルーンしないようにする時点です。 このモーメントは、データ整合性を維持し、必要な履歴レコードが削除されないようにするために重要です。
[ブランチ履歴のプルーン (Prune Branch History)] ツールは、データベース内のフィーチャの履歴レコードを検査します。 ツールが参照モーメントを報告した場合、バージョンまたはフィーチャ サービス レプリカが、リクエストされたプルーン日付より前の参照モーメントを使用していることを意味します。 この参照モーメントによって、データセットからレコードがプルーンされるのを防ぐことができます。 出力ログには、参照モーメント、フィーチャ サービス レプリカ、ツールをブロックしたバージョンなど、使用できる最も古いモーメントが報告されます。
これを解決するには、[日付より前をプルーン] を古い時間に調整するか、バージョンをリコンサイルするか、フィーチャ サービス レプリカを同期します。 この手順により、必要なすべてのレコードが保持され、参照モーメントが回避されます。
たとえば、ブランチ バージョン対応登録されたパーセル データセットに新しいパーセルが 1 年前に追加されたとします。 その後、このパーセルは 6 か月前に更新され、今日再び更新されました。 [日付より前をプルーン] を 3 か月前に設定すると、ツールは更新時間に基づいてプルーンの候補となる行を識別します。 [日付より前をプルーン] の値よりも古く、パーセル データセットの現在のリプレゼンテーションではないパーセルのリプレゼンテーションは削除できます。
フィーチャが更新されると、ツールはフィーチャの現在のリプレゼンテーションがクエリーで返されないようにします。 現在のリプレゼンテーションが削除の場合、プルーン時間の時点で返すことができる現在のリプレゼンテーションはないため、行をプルーンする必要があります。
たとえば、パーセルが 6 か月前に削除された場合、その現在のリプレゼンテーションは削除済みとしてマークされます。 返すことができる現在のリプレゼンテーションがないため、この行はプルーンの候補になります。
名前付きバージョンとリコンサイル
名前付きバージョンが作成されると、このモーメントの日時が記録され、リコンサイルのための共通の上位バージョンとなります。 リコンサイル中に、ツールは初期時間に戻って、デフォルトと名前付きバージョンのどちらで変更が行われたかを判断する必要があります。 このプロセスには、初期時間と新しい時間の記録と、共通の上位バージョンの更新が含まれます。
注意:
ブランチ履歴のプルーン ツールは、デフォルト バージョンから廃止された履歴管理レコードのみをプルーンします。
たとえば、6 か月前に作成された名前付きバージョンがあるとします。 リコンサイル中に、システムはデフォルト ブランチと名前付きバージョンの現在の状態を比較し、どちらで変更があったのかを判断します。 これにより、すべての変更が正確に反映され、参照モーメントを回避できます。
フィーチャ サービス レプリカ
フィーチャ サービス レプリカも参照モーメントを保持し、同期されると時間を前方に移動します。 このツールでは、同期に必要な行はプルーンされません。 これには、競合の検出に必要な履歴レコードの維持も含まれます。
たとえば、フィーチャ サービス レプリカが 1 年前に作成され、複数回同期されている場合、このツールではこれらの同期に必要な行はプローンされません。 これにより、異なるレプリカ間でのデータの整合性が維持されます。
トランザクション モデル
[ブランチ履歴のプルーン (Prune Branch History)] ツールでは、データセットに対する排他的ロックが必要となり、指定した [日付より前をプルーン] より前の日付である候補行はすべて削除されます。 ツールでプルーン操作中にエラーが発生した場合は、エラーを解決してからツールを再実行する必要があります。 このワークフローにより、データベースの一貫性が維持され、履歴レコードにギャップが存在しなくなります。
フィーチャ データセットまたはシステム テーブルをプルーンする場合、操作は個別のオブジェクトに対して実行されるため、それぞれの入力クラスまたはテーブルがコミットされます。 たとえば、ツールでプルーン中にメモリーの問題が発生すると、プロセスが停止します。 その後、問題に対処して解決してから、ツールを再実行すると、停止したところからプルーンが再開されます。
プルーンされている候補行の量に応じて、トランザクションのサイズに効果的に対応するために、ディスク容量などのデータベース リソースを増やす必要がある場合があります。
共通の上位バージョンと前の上位モーメント
共通の上位バージョンと前の上位バージョン プロパティは、ブランチ バージョン対応データの管理、変更履歴の追跡、参照モーメントの回避、およびクエリー中に取得されるフィーチャが正しいバージョンであることの保証に重要です。 これらのバージョン プロパティは、[コンテンツ] ウィンドウからアクティブなマップの Web フィーチャ レイヤーのバージョン ビューを開くと表示できます。 これらの列に表示される情報は、[ブランチ履歴のプルーン (Prune Branch History)] ツールの使用時に、プルーンを妨げる参照モーメントに関連する問題を解決するのにも役立ちます。
- 共通の上位バージョン - 共通の上位バージョンは、2 つのブランチが分岐する前に共有する最後のモーメントをマークし、バージョンが同じモーメントを参照した日時をデフォルトとしてマークします。
- 前の上位 - 前の上位には、バージョンとデフォルト バージョンが同じモーメントを参照した最後のリコンサイルの前の日時のモーメントが表示されます。 これは、新しいリコンサイルが完了した後は、前の共通の上位バージョンになります。
リコンサイル中に競合が検出された場合、共通の上位バージョンと前の上位モーメントは、バージョンとデフォルト バージョンの両方で同じフィーチャに変更が加えられたかどうかを判断するのに役立ちます。
[ブランチ履歴のプルーン (Prune Branch History)] ツールを使用しているとき、バージョンまたはフィーチャ サービス レプリカが特定のレコードを参照している場合、共通の上位バージョンと前の上位モーメントによって、そのレコードのプルーンを防ぐことができます。 これにより、重要な履歴データが間違って削除されなくなります。 [ブランチ履歴のプルーン (Prune Branch History)] ツールが、参照モーメントのために [日付より前をプルーン] が無効であることを示すエラーを返す場合、バージョン マネージャーで共通の上位バージョンと前の上位モーメントを確認します。 バージョン マネージャーでこれらのモーメントを識別すると、特定のレコードをプルーンできない理由を理解するのに役立ち、バージョンのリコンサイルやフィーチャ サービス レプリカの同期などのアクションを実行して、参照モーメントを更新して前に移動することができます。
履歴維持
[ブランチ履歴のプルーン (Prune Branch History)] ツールを実行する前に、次の推奨事項を使用して、履歴データまたはアーカイブされた行を維持してください。
- エンタープライズ ジオデータベースを定期的にバックアップします。
ヒント:
データベースのバックアップと復旧計画を定期的にテストすることもおすすめします。 データベースのバックアップと復旧計画のオプションに関する具体的な詳細と手順については、RDBMS のドキュメントをご参照ください。
- [ブランチ履歴のプルーン (Prune Branch History)] ツールの「レポートのみ」オプションを使用して、プルーン前に潜在的な問題を特定します。
- プルーン前に、エクスポートした履歴レコードを将来の参照用として外部データベースまたはファイルに保存します。
履歴レコードのエクスポート
プルーン前に履歴レコードを保持するために、前のモーメントを使用してアーカイブされたクラス行をエクスポートできます。 履歴レコードをエクスポートするワークフローでは、以下を行います。
- アーカイブ クラスをマップに追加します。
- GDB_FROM_DATE フィールドを使用して、プルーン モーメントよりも古いレコードを並べ替えて識別します。
- 「日付より前をプルーン」より古いレコードをすべて選択してエクスポートします。
[ブランチ履歴のプルーン (Prune Branch History)] ツールを使用するための前提条件とワークフローの詳細については、「ブランチ履歴のプルーン」をご参照ください。