レポート サーバー上のパスワードは、Unified CVP のインストールの一環として、または Operations Console を使用して作成および更新する必要があります。 パスワードを作成または更新する際に他の手段を使用しないでください。

Unified CVP レポーティングサーバーのパスワードは、OAMP サーバー上にローカルで暗号化された状態で保存され、レポーティングサーバー上で設定されます。 これらのパスワードが同期していない (同一でない) 場合、オペレーション コンソールはレポート サーバーと通信できなくなり、パージなどの制限された操作は失敗します。

パスワード有効期限ポリシーを実装する場合は、データの損失やダウンタイムを回避するために、パスワードの有効期限が切れる前に、オペレーション コンソールを使用してデータベース管理者と データベース ユーザー のパスワードを変更するようにしてください。

（注）	オペレーション コンソールを使用してパスワードを変更し、有効期限が切れる前にパスワードを更新することで、すべての依存関係が同期されます。

注意	オペレーション コンソールの外部でパスワードを変更すると、レポート サーバーとデータベース間の接続が失敗する可能性があります。

レポーティング用パスワードは、Unified CVP のパスワードポリシー およびレポーティングサーバーが稼働しているコンピュータのオペレーティングシステムによって適用されるパスワードポリシーの両方の対象となり、より厳しい方のポリシー要件を満たす必要があります。

Unified CVP では、データベース管理者、アプリケーション ユーザー、レポート ユーザーという 3 つのデータベース ユーザーのカテゴリが定義されています。

重要	CVP レポート ユーザ cvp_dbadmin と cvp_dbuser は、ローカル管理者グループと Informix 管理者グループの両方のメンバーである必要があります。 これらのグループメンバーシップは、データベース管理、管理、およびアプリケーションアクセスのために必要です。 これらのユーザを必要なグループから変更または削除すると、CVP レポート機能が完全に失われ、バックアップとリカバリが失敗し、サービスが停止する可能性があります。 この設定は必須であり、変更しないでください。

オペレーション コンソールを使用すると、ユーザーはデータベース パージを実行する時刻を選択し、データ カテゴリごとに保持するデータ日数を設定できます。 スキーマの作成中に、各データ カテゴリに対してデフォルトのデータ保持値が指定されます。 通話などの上位カテゴリの保持時間を、通話イベントなどの従属カテゴリよりも短くすることはできないことに注意してください。

データベースの空き容量が増えると、Cisco Unified Contact Center Enterprise 向けソリューション設計ガイドに記載されているとおり、データの保持期間が長くなります。

このセクションでは、パージをスケジュールする方法、正午のパージと夜間のパージの違い、緊急パージを実行する方法について説明します。

迅速なスペース管理を可能にするために、Unified CVP Reporting Server のすべてのデータは日付固有のフラグメントに保存されます。 日次で、受信データに対する新しい日次フラグメントが作成されます。 これにより、Unified CVP Reporting Server は、データが存在するディスク フラグメントを削除することで、古いデータをすぐに削除できるようになります。

つまり、保持期間が終了したときにすぐに破棄できるように、新しいフラグメントを定期的に作成する必要があります。 これらすべてはパージによって処理されます。

静かな環境では、パージは 1 秒未満で実行できます。 ビジーな環境では、実行中のプロセスをパージが回避するため、パージにかなり長い時間 (15 ～ 20 分) かかる場合があります。

パージが実行できない状況に備えて、必要になる 2 日前にスペースが割り当てられます。 この割り当ては、日付の境界を超えた後に実行される最初のパージによってトリガーされます。

夜間パージが午前 1 時に実行されるようにスケジュールされている場合、通常はこのタスクが実行されます。 夜間のパージが午後 11:00 に実行されるようスケジュールされている場合、翌日の処理は翌朝 11:00 まで実行されないことになります。これは、プロセスを実行する最適な時間ではない可能性があります。

このため、夜間のパージは深夜以降に実行されるようにスケジュールしてください。

Unified CVP を使用すると、ユーザーはデータ バックアップのスケジュールをオンまたはオフにしたり、オンデマンドでバックアップを実行したりできます。 バックアップはレポート サーバーのローカル ファイル システムに作成されます。 デフォルトでは、スケジュールされたバックアップはオフになっています。

注意	Unified CVP バックアップ スケジューリングはオプションの機能です。 バックアップはユーザーの責任となります。 ユーザーがファイルのバックアップを適切に管理していない場合、データが失われる可能性があります。 同じバージョンおよび同じマシンからのデータベースのバックアップと復元がサポートされています。

Unified CVP バックアップ スケジュールがオンになっている場合、バックアップは 1 日に 1 回実行されます。 バックアップは、スケジュールされた消去ジョブの 30 分後以降に実行されるようにスケジュールする必要があります。

別のバックアップまたはパージがまだ実行されていない限り、ユーザーはオンデマンドでバックアップを実行できます。 データベースのバックアップはローカル マシンで実行され、保存されます。 スペースの制限により、ローカル マシンでは最大 2 つのバックアップと最小 1 つのバックアップが使用できます。 2 つのバックアップ ファイルを保持することが重要です。 バックアップの書き込み中にシステムに障害が発生し、復元が必要になった場合、復元には古いバックアップ ファイルが必要になります。

次のガイドラインに従ってください。

• 特定のバックアップを少なくとも 2 週間保存します。

• 定期的にバックアップの整合性を確認してください。

• アップグレードの前にバックアップを実行してください。

Unified CVP は、Informix バックアップ ユーティリティ ontape (バックアップと復元の両方) を使用します。

新しいバックアップがスケジュールに従って、または Operations Console からの要求に応じて開始されると、新しいファイルの名前は cvp_backup_data.gz になります。 Unified CVP バックアップ スクリプトは、以前の cvp_backup_data.gz バックアップ ファイルをコピーし、名前を cvp_backup_data.old.gz に変更します。 これにより、ローカル システムに常に 2 つのバックアップ ファイルが残り、Unified CVP 管理者はコピー ジョブをスクリプト化してファイルを移動しやすくなります。 バックアップ スクリプトにより、2 つのバックアップが同時に起動されないようになります。

（注）	バックアップ スクリプトは、パージが進行中の場合はバックアップを起動できないようにし、その逆も同様にします。

ローカル マシンにバックアップを保存しても、そのマシンの障害やサイトの損失から保護されるわけではありません。

重要	cvp_backup_data.old.gz ファイルを別のマシンの別の場所にコピーするジョブを手動または自動で作成する必要があります。 繰り返しになりますが、バックアップ データの管理はユーザーの責任となります。

警告	コピーできるのは cvp_backup_data.old.gz ファイルのみです。 cvp_backup_data.gz ファイルをコピーできません。 cvp_backup_data.gz ファイルをコピーしようとすると、ファイルがロックされ、別のバックアップが実行されなくなります。

データベースのバックアップは、バックアップが完了するとログ ファイルを更新します。 バックアップ中にデータベース サーバーがダウンすると、バックアップ ファイルが破損します。

Informix が起動していることを確認し、バックアップを検証するには、%CVP_Home%\bin\cvpverifybackup.bat にある cvpverifybackup.bat ファイルを実行します。

Please put in Phys Tape 1. Type <return> or 0 to end: Press 0 and press Enter（Phys Tape 1 を挿入してください。終了するには <return> または 0 を入力してください：0 を入力して Enter キーを押します。）

（注）	データベースのサイズに応じて、プロンプトは Tape 2、Tape 3 というように順次変更されます。 このプロセスは検証に長い時間 (データベースのサイズに基づいて) かかり、結果はコンソールに表示されます。

Cisco Unified CVP では、データベースの復元を実行するためのスクリプトがサポートされています。

バックアップイメージの復元は、バックアップイメージ内の過去のデータを回復する必要がある場合に必要です。 また、ハードウェア障害後にマシンを再構築し、データを回復する必要がある場合にも必要です。

（注）	あるレポート サーバーから別のレポート サーバーにバックアップ イメージを復元することは可能ですが、このような復元は CVP 復元プロセスではサポートされていません。

Unified CVP での復元プロセスは次のとおりです。

• CallServer プロセス (レポート サーバー) を停止します。

• スクリプトを実行します: %CVP_Home%\bin\cvprestore.bat。

• CallServer プロセスを再起動します。

注意	サードパーティのバックアップ ユーティリティを使用して Informix データベースをバックアップすることは効果がなく、レポート データベースの整合性に危険を及ぼす可能性があります。 レポート データベースのバックアップを実行する唯一の効果的な方法は、OAMP インターフェイスによって提供されるバックアップ プロセスを使用することです。

バックアップの設定については、Cisco Unified Customer Voice Portal 管理ガイドを参照してください。

場合によっては、バックアップまたはパージがスケジュールどおりに実行できないことがあります。 たとえば、パージの実行がスケジュールされているときにオンデマンド バックアップが実行中の場合、パージは実行されません。

スケジュールされたバックアップまたはパージの再試行は、次のルールに従って実行されます。

（注）	オンデマンド バックアップでは再試行は行われません。

• スケジュールされたバックアップは、最大 4 時間、10 分ごとに再試行されます。

• パージは最大 6 時間、10 分ごとに再試行されます。

• 4 時間 (バックアップの場合) または 6 時間 (パージの場合) が経過しても操作が成功しなかった場合は、再試行が停止し、SNMP アラートが送信されます。

• バックアップとパージの両方が同時に再試行される場合、どちらの操作が最初に実行されるかは保証されません。

• ロック (バックアップまたはパージの実行を防止するメカニズム) が 12 時間以上経過している場合、システムはそれをクリアします。

Unified CVP データベース リカバリにより、データベースは最新の完全なバックアップの状態に戻ります。 たとえば、ユーザーが 01:00 にバックアップをスケジュールし、同じ日の 23:00 にデータベースを復元した場合、復元されたデータベースは 01:00 時点の状態になります。

データベースの復元中、復元操作の間データベースはオフラインになります。

（注）	レポート サーバーがオフになり、メッセージ バスが一時的な永続性能力を超えると、データ損失が発生します。

注意	データベースの復元を実行する前に、次の手順を実行する必要があります。 復元する前に、スケジュールされたタスク (バックアップ、パージ) を無効にします。 復元後、スケジュールされたタスクを再度有効にします。

レポート サーバーに障害が発生した場合、レポート サーバー宛てのメッセージは、コール サーバーによってメモリ内に最大 200,000 件のメッセージがバッファリングされます。 その制限に達すると、すべての新しいメッセージの詳細情報が削除されます。

データベース接続が失敗すると、レポート サーバーは SNMP アラートを送信し、ユーザーが指定した制限までメッセージをファイルに保存し始めます。 この間、レポート サーバーは 稼働中のままになります。 指定された制限の 75% に達すると、ログ ファイルに警告が書き込まれます。 制限値の 100％ に達すると、SNMP アラートが送信され、レポーティングサーバーは [部分サービス（Partial Service）] 状態になります。この状態では、新しいメッセージが破棄される可能性があります。

データベース接続が復旧すると、レポーティングサーバーは復旧モードに入り、まだその状態でない場合は、その状態を [部分サービス（Partial Service）] に変更します。 次に、ファイルからメッセージを読み取り、データベースにコミットします。 ファイルのサイズによっては、すべてのデータをデータベースにコミットするのに長い時間 (場合によっては数時間) かかることがあります。 回復中に受信した新しいメッセージはすべてメモリにバッファリングされます。 ただし、レポート サーバーがバッファリングできるメッセージの数には制限があります。 これは、モードや状態に関係なく当てはまります。バッファリングされたメッセージの数が 100,000 に達すると、SNMP アラートが送信され、ユーザーに警告します。 200,000 に達すると、別の SNMP アラートが送信され、すべての新しいメッセージの詳細情報が削除され、通話、通話イベント、セッション情報などの基本データのみが保持されます。 さらに 200,000 に達すると、レポーティングサーバーは、まだその状態でない場合、その状態を [部分サービス（Partial Service）] に変更します。 バッファリングされたメッセージの合計数が 300,000 に達すると、別の SNMP アラートが送信され、その時点以降のすべての新しいメッセージは削除されます。

メモリ内のメッセージ数が再び 50,000 未満に減少すると、キューサイズが通常に戻ったことを知らせる SNMP アラートが送信され、レポーティングサーバーの状態は [サービス中（In Service）] に戻ります。

起動時に永続ファイルが存在する場合、レポーティングサーバーは [部分サービス（Partial Service）] のままとなり、前述のとおり復旧モードに入ります。

データベースの消去操作中、レポート サーバーはデータベースから切断され、消去が完了するまでメモリ内にメッセージをバッファリングし始めます。 この場合も、前述と同じメモリ制限が適用されます。

注意	レポート サーバーが 部分サービス の状態の場合、新しいメッセージが保持され、データベースにコミットされるという保証はありません。 可能な限り多くのデータがメモリにバッファリングされますが、ある時点で一部または全部が削除される可能性があります。