ディレクトリに保存される破損通知については非常に複雑なため、ビジネスでうまく利用されていない場合があります。いくつかのディレクトリ製品とは異なり、Novell eDirectoryではオブジェクト間の参照整合性が確保されています。たとえば、グループAにユーザBというメンバが登録されている場合、ユーザBが削除されるとディレクトリでは自動的にグループAからユーザBへの参照が削除されます。破損通知は、eDirectoryによってオペレーショナル属性としてオブジェクトに保存されます。これにより、削除、移動、リネーム、復元、およびその他の操作中に、二重に参照整合性が確保されます。
破損通知には大きく分類して3つの種類があります。
トラッキング破損通知以外の破損通知は、次の同期ステータスのセットを使用して移動する必要があります。
ステータスは破損通知属性のフラグフィールドで記録されます。破損通知が次のステータスに進む前に、現在のステータスは必ず実オブジェクトのすべてのレプリカに同期されます。リング内のすべてのレプリカが破損通知ステータスを与えられているかどうかを判断するために、遷移ベクトルからベクトルが計算されます。eDirectory 8.6以降では、保存されていない破損通知ベクトルが使用されます。以前のバージョンのeDirectoryでは、パージベクトルが使用されます。破損通知の変更タイムスタンプ(MTS)が破損ベクトルよりも古い場合、担当サーバは該当する破損通知を次のステータスに進めることができます。
「バックリンク」のセカンダリ破損通知の場合、該当する破損通知を含むオブジェクトのマスタレプリカを持つエージェントがステータスを進めます。「使用中」のセカンダリ破損通知の場合、レプリカが存在している間は該当する破損通知を作成したエージェントがステータスを進めます。レプリカが存在しない場合、パーティションのマスタを保持しているエージェントが「使用中」の破損通知のステータスを進めます。「ツリーの移動」の破損通知の場合、ルートパーティションのマスタがステータスを進めます。
プライマリ破損通知は、すべてのセカンダリ破損通知が最後のステータスまで進められた後でのみ、ステータスを進めることができます。プライマリ破損通知が最後のステータスまで進んだ後で、そのステータスがリング内のすべてのサーバに同期されると、残っているのは属性を持たないオブジェクトであるオブジェクトハスクのみとなり、これらはシステムのパージプロセスによってパージされます。トラッキング破損通知は、プライマリ破損通知の削除の準備が完了した後か、Inhibit_moveの場合はプライマリ破損通知がマスタレプリカのOBF_NOTIFIEDステータスに移動された後で削除されます。
破損通知の処理を担当するレプリカは、指定したパーティションがインバウンド同期サイクルを終了した後で、パーティションごとにスケジュールされているバックグラウンド処理(破損通知処理)を実行します。パーティションにその他のレプリカがない場合、アウトバウンドレプリケーション処理がハートビート間隔でスケジュールされたままになります。その後、アウトバウンドレプリケーション処理によって破損通知処理が開始されます。破損通知処理は手動ではスケジュールできず、また、その必要もありません。同期化が実行されると、遷移ベクトルが更新され、パージベクトルおよびObitベクトルを進めます。これらのベクトルが進められると、破損通知のステータスを進めることができます。これと同時に、インバウンド同期に自動スケジュールが実行されると、破損通知処理サイクルが完了します。すなわち、破損通知処理の起動要因はオブジェクト同期です。
削除されたオブジェクトの場合、「停止」のプライマリ破損通知に関連するすべての破損通知が最後のステータス(パージ可能)まで進められ、そのステータスがすべてのレプリカに同期された後で、新しい処理がデータベースに残っているエントリハスクの削除を担当します。これらのハスクを削除するために、パージ処理が自動的に実行されます。パージ処理のスケジュールおよび自動スケジュール間隔の調整は、iMonitorのエージェント環境設定ページを使用して手動で設定することができます。