Expired - アイテムの保留状態が続く原因 - 基本的なアーカイブ処理

問題

アイテムの保留状態が続く原因 - 基本的なアーカイブ処理

解決方法

ア イテムの保留状態が続く原因にはいろいろあります。原因を具体的に列挙するよりも処理のしくみについて理解することが重要です。そうすることで、潜在的な 「障害発生時点」を特定しやすくなります。さまざまな既知の原因については、この文書の最後にある関連文書を参照してください。

注意: 「保留状態」とは、アーカイブ処理中のメールアイテムのことをいいます。これらのアイテ ムのメッセージクラスは IPM.Note.EnterpriseVault.PendingArchive に変更されます。この変更により、メッセージの「封筒アイコン」は、時計の付いた「Vault」アイコンに変わります。

メッセージをアーカイブする際は、メッセージに対して次のような処理が行われます。

1. メールボックスアーカイブでは、メールボックスアーカイブタスクが A3 (タスクを今すぐ実行) キューまたは A5 (スケジュール設定されたタスクを実行) キューにメールボックスオブジェクトを割り当てます。
a. ジャーナルアーカイブでは、ジャーナルタスクが 60 秒ごとにジャーナルメールボックスに接続し、(J3 キューの) 処理対象のアイテムが存在するかどうかを確認します。

注意:
a. ［メッセージキュー (Message Queuing）］-［プライベートキュー (Private Queues)］は、［コンピュータの管理］、［サービスとアプリケーション］、［メッセージキュー (Message Queuing）］で見つけることができます。
b. タスクごとにキューが存在し、それぞれ役割を担っています。(つまり、EV に 2 つのメールボックスアーカイブタスクが存在する場合、A1 から A6 までの「A」キューが ２ セット存在することになります)
c. タスクを削除して再作成する場合、古いキューは自動的に削除されません。 また、孤立したキューにオブジェクトが存在する場合、これらのオブジェクトは処理されません。
d. 最新情報が表示されるように、常にページを更新することを推奨します。
e. ［キューフォルダ (Queue Folder)］(左側)、［キューメッセージ (Queue Messages)］を展開し、キュー内のアイテムを選択すると、アイテムがいつキューに配置されたかに関する詳細情報を確認できます。

2. メールボックスオブジェクトにアクセスすると、アーカイブタスク / ジャーナルタスクのワーカスレッドがメールボックスのスキャンを開始し、処理対象となるアイテムを探します。

3. 処理対象となるアイテムのメッセージクラスを IPM.Note から IPM.Note.EnterpriseVault.PendingArchive に変更するため、MAPI を介して Exchange に呼び出しが行われます。
a. ジャーナルアーカイブでは、処理対象のアイテムを保留状態に変更し、これらのアイテムへの参照を J2 キューに追加して処理を行います。

注意: アイテムの正確なメッセージクラスを特定するため、Outlook で列を作成してメッセージクラスフィールドを追加できます。

4. EV Server Storage Service の状態が読み書きモード (HKLM\Software\KVS\EnterpriseVault\Storage\EnableArchive = 1) になっていることが確認され、保留状態に変更されたアイテムが Storage Archive のメッセージキューに追加されます。

注意:
a. この段階では、ストレージデバイスにコピーが送信されます。
b. Enterprise Vault が読み取り専用の状態になっていないことを確認します。詳しくは、関連文書にある article 308566 を参照してください。
c. キューとその目的について詳しくは、『Enterprise Vault 管理者ガイド』を参照してください。

5. ストレージに追加されると、以下の更新が行われます。
a. 関連付けられているボルトストアデータベースで、アイテム固有のエントリ (Saveset ID) が Saveset テーブルに追加されます。
b. 類似したエントリがボルトストアのデータベースである JournalArchive テーブルに追加されます。
i. バックアップ後にセーフコピーを削除するように設定している場合、エントリは WatchFile テーブルにも追加されます。
c. 固有のトランザクション識別子 (IdTransaction) が、メールボックスにある保留中の元のアイテムに追加されます。

注意:保留中のアイテムを大量にキャンセルする方法について詳しくは、関連文書の記事 273157 と 287877 を参照してください。

6. ストレージに追加される際、検索が行えるようにアイテムも読み込まれてインデックスが付けられます。 アイテムに正常にインデックスが付けられると、 JournalArchive テーブル内のエントリは ( Indexcommited が 0 から 1 に) 変更されます。

7. ボルトストアが バックアップ後にセーフコピーを削除する ように構成されている場合、ストレージデバイスでバックアップが実行されるまでアイテムの処理は保留されます。
格納済みアイテムのアーカイブビットが更新されていることが StorageFileWatch の処理で特定されると、アイテムがバックアップされていることが示されるように、対応する Saveset エントリを変更 ( BackupComplete を 0 から 1 に) するため、 JournalArchive テーブルが呼び出されます。

a. アーカイブ中のアイテムのセーフコピーをボルトストアが処理する方法については、VAC (Vault Administration Console) で確認できます。
i. VAC を開きます。
ii. ［Enterprise Vault］、［<サーバー名> のディレクトリ］、［<サイト名>］、［ボルトストア (Vault Stores)］の順に展開します。
iii. ［ボルトストア (Vault Store)］を右クリックし、［プロパティ (Properties)］で［セーフコピーを削除 (Remove safety copies)］を設定します。

注意:
a. EMC Centera ストレージを使用している場合、「バックアップ」処理は Centera の内部レプリケーション処理に含まれるため、自動的に行われると見なされます。
b. コレクションを有効にして EMC Centera ストレージを実行している場合、アイテムがコレクション場所から収集されるまでアイテムは BackupComplete = 0 のままになります。
c. ジャーナルアイテムは通常、この値がすでに設定されています (ジャーナルボルトストアデータベースでは通常、アーカイブの直後にセーフコピーを削除するように設定されています)。
d. ボルトストアデータベースのプロパティで［セーフコピーを削除 (Remove safety copies)］をどのように設定しているかによって、SQL でのアイテムの処理方法が決まります。
i. ［バックアップ後 (After backup)］が設定されているときは、アイテムへの参照が WatchFile テーブルと JournalArchive テーブルに配置されます (これらのテーブル間には制約があります)。
ii. ［アーカイブ後すぐ (Immediately after archive)］が設定されているときは、アイテムへの参照は JournalArchive テーブルにのみ配置され、WatchFile テーブルはスキャンされなくなります。

注意: セーフコピーを削除する方法を［バックアップ後 (After backup)］から［アーカイブ後すぐ (Immediately after archive)］に変更する場合は、タスクのスケジュール設定 (メールボックスアーカイブ) を無効にするか、タスクをリポートモード (ジャーナルアーカイブ) に設定する必要があります。これにより、これらのテーブルにその他のアイテムは追加されないようになります。これらの両方のテーブルで残りのアイテムすべ ての処理が終了すると、この機能は安全に変更できるようになります。WatchFile テーブルに未処理のアイテムが残っているときにこのオプションを変更すると、これらのエントリに関連付けられたアイテムの後処理が完了せずに保留状態のま まロックされます。また、アイテムの後処理が行われ、保留中のアイテムが増加する場合もあります。

8. BackupComplete 値が 1 になると、アイテムは「後処理」が可能になったと識別されるようになります。

注意:
a. Indexcommited と BackupComplete がどちらも 1 になると、これらのアイテムは JournalArchive テーブルと WatchFile テーブルから削除されます。
b. このプロセスは、V 6.0 SP3 から一部変更されました。当初は、アイテムにインデックスが付けられて (Indexcommited = 1) バックアップが行われると (BackupComplete = 1)、EV で後処理が開始されました。EV 6.0 SP3 以降、インデックス付けはアイテムの後処理を開始するための必要条件ではなくなりました。

9. アイテムが「バックアップ済み」として登録されると、リストが作成されて A1 / J1 キュー内のメッセージキューで参照されるようになります。

10. アーカイブタスク / ジャーナルタスクのワーカースレッドによって A1 / J1 キューから各アイテムがプルされると、EV は後処理の段階に入り、元のメールボックスにコールバックしてアイテムを「削除」し、セーフコピーを除去して、アイテムのメッセージクラスを IPM.Note.EnterpriseVault.PendingArchive から IPM.Note.EnterpriseVault.Shortcut に変更します。

注意:
a. タスク制御サービスを開始してアーカイブタスク / ジャーナルタスクを実行する必要があります。
b. ジャーナルアーカイブではショートカットは作成されず、アーカイブ後にアイテムが削除されます。

トラブルシューティングの例:
- JournalArchive テーブルと WatchFile テーブルが空の場合は、バックアップまたはインデックス付けを行う対象が存在しないと考えて問題ありません。バックログのメッセージについては、 Storage Archive のキューを調べてください。
- A1 / J1 キューに何もない場合、前提条件が揃って後処理が開始できるのを Enterprise Vault が待機している可能性があります。確認するには、 JournalArchive テーブルを調べてください。

アーカイブ処理を監視するときの推奨事項:

JournalArchive テーブル
処理を待機しているアイテムのリストを取得するには、次の Select スクリプトを実行します。

A) SELECT * FROM JournalArchive WHERE Indexcommited = '0'
- インデックス付けを待機しているアイテムの数。

B) SELECT * FROM JournalArchive WHERE BackupComplete = '0'
- バックアップを待機しているアイテムの数。

*別の方法として、リストでなく単にアイテム数を返す次のスクリプトを実行できます。

SELECT COUNT(*) FROM JournalArchive WHERE Indexcommited = '0'
SELECT COUNT(*) FROM JournalArchive WHERE BackupComplete = '0'

メッセージキュー

未処理のアイテムが残っているかどうかを確認するには、「A」キューと「J」キューを調べます。

最も一般的なキュー:

A1 = 後処理
A3 = アーカイブを「今すぐ実行」するメールボックスのリスト
A5 = アーカイブがスケジュール設定されているメールボックスのリスト
A6 = 同期要求

J1 = ジャーナルの後処理
J2 = 処理対象の個々のアイテム

Storage Archive = ストレージに追加されるアイテムのリスト

キューでジャーナルを有効にすることで、アイテムが正常に処理されていることをキューを通して一時的に確認できます。
a. ［メッセージキュー (Message Queuing)］を展開します。
b. キューを右クリックし、[プロパティ (Properties)]、[全般 (General)]タブをクリックします。
c. [ジャーナル (Journal)]セクションで[有効化 (Enabled)]* を選択します。

キューで「ジャーナルされた」オブジェクトは、キューの下にあるジャーナルメッセージのサブフォルダで参照されます。

注意:
a. Storage Service が代替 EV サーバーに存在する場合は、アイテムをストレージサーバーに送信する際、発信キューを調べて保留になっているアイテムがないことを確認してください。
b. キューでジャーナルを有効にしている場合、これらのアイテムは自動的に削除されず、MSMQ のストレージ領域を消費し続けます。
c. ジャーナルオプションは長期間有効にしないでください。結果を確認したら、このオプションを無効にしてジャーナルメッセージキューをパージしてください。
d. Windows 2003 SP2 より前のバージョンでは、MSMQ のストレージは 8 GB に設定されていました。Windows 2003 SP2 では、このデフォルト値が 1 GB に変更されています。この制限 (イベント警告 3249) について詳しくは、関連文書を参照してください。

ストレージ

a. バックアップ後にアーカイブビットが「反転」されていることを確認してください。
b. EMC Centera ストレージでは、「バックアップ」処理は Centera の内部レプリケーション処理に含まれるため、自動的に行われると見なされます。レプリケーションが適切に処理されていることを確認します。
c. EMC Centera ストレージでは、コレクションを有効にしている場合*、コレクションの場所がバックログされていないこと、またイベントログにストレージベースのエラーが発生していないことを確認してください。
d. 「アーカイブ」属性を使用しないその他の非 NTFS ベースのストレージデバイス (NetApp ファイラなど) については、関連文書の IgnoreArchivebitTrigger.txt の使用に関する説明を参照してください。

注意:
a. コレクションの状態はボルトストアパーティションごとに制御されます。この値は VAC で設定されます。VAC で［ボルトストア (Vault Stores)］、［<ボルトストア名>］、［<パーティション名>］、［プロパティ (Properties)］、［コレクション (Collections)］タブの順にクリックします。
b. いったんパーティションでコレクションを有効にすると、無効にすることはできません。

イベントログ
通常、前の晩に発生した可能性があるエラーの原因究明に最も役立ちます。

注意: EV 6.0 以降では、article 273157 の解決策 3 を実行する際、［ジャーナルポリシー (Journal Policy)］、［詳細設定 (Advanced)］、［保留中のショートカットのタイムアウト (Pending shortcut timeout)］を特定の値 (1 日など) に設定できます。

保留中のアイテムを「まとめて」キャンセルできるようにするため、この値に ０ 以外の時間間隔を設定しないでください。