目次

はじめに

前提条件

要件

使用するコンポーネント

問題

解決策

チェックサム問題の解決のために後日実行された手順

検証済み

概要

このドキュメントでは、UCCE Logger A および B が初期化状態のままになっている場合のトラブルシューティングの手順について説明します。

著者：Cisco ソフトウェア エンジニア、Pratham Prakash

前提条件

要件

次の項目に関する知識が推奨されます。

- Cisco UCCE

- Microsoft Structured Query Language（SQL）

使用するコンポーネント

本書の情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。 稼働中のネットワークで作業を行う場合、コマンドの影響について十分に理解したうえで作業してください。

問題

ログ分析により、UCCE Logger A および B が初期化状態のままになっていることが確認されました。  ロガーが両側ともアクティブにならず、例外 bcp 接続が枯渇している状態でロガーがクラッシュし続けます。  この状態のエラー メッセージの例はログ ファイルで確認できます。

14:09:45:286 la-rcv Trace: SQL Server User Error: 2627, State 1, Severity: 14, Message:

Violation of PRIMARY KEY constraint 'XPKPeripheral_Interval'. Cannot insert duplicate key

in object 'dbo.t_Peripheral_Interval'. The duplicate key value is (Jul 3 2015 12:30PM,

5002, 300, 1).

14:09:45:335 la-rcv Trace: Duplicate key ignored because the record already exist in the

database.

14:09:45:335 la-rcv Trace: bcp_done failed

これは、t_Persistent_Variable テーブルに重複キーがあることにより発生する状態です。 Logger A と B のどちらも初期化を完了できません。

解決策

この状態は、UCCE リリース 10.x ThedDefect「CSCuw02024 t_Persistent_Variable テーブルの削除と再追加の記録」で Persistent Variables を使用することにより発生します。

次の回避策を実行してください。

ステップ 1： Logger Side A および Logger Side B に対し、以下のレジストリ キーの値を 1 から 0 に変更します。

HKEY_LOCAL_MACHINE\Software\Geotel\ICR\Customerinstance\LoggerB\Logger\HistoricalData\Persistent

ステップ 2：片側を停止します。

1）停止しているほうの Persistent_VariableTmp1、Persistent_VariableTmp2、および t_Persistent_Variable のテーブルを切り捨てます。

2）アクティブなほうの Persistent_VariableTmp1, Persistent_VariableTmp2 and t_Persistent_Variable のテーブルを切り捨てます。

ステップ 3：Side A と Side B の両方の Logger Service を再起動します。

ステップ 4：ユーザが設定を変更できることを確認するためにテストを行います。

ステップ 5：システムにテスト発信を行い、発信されていることを確認します。

ステップ 6：さらに exit_router を実行する必要がある場合もあります。システムが立ち上がって動作していることが確認され、ルータの両側では、Side A ロガーから設定を取り込むことで状態転送が完了しました。 コンタクト センター システムは動作しており、機能していますが、Side B ロガー db はまだ初期化状態のままです。  これは、Side B ロガーのリカバリ キーが Side A ロガーを大幅に遅延させているために発生したものです。

ステップ 7：A --B へ手動構成 db を実行します。

A --B へ手動構成 db を実行します。

lastUpdatekey は Side A と B で一致しましたが、Logger B clgr はチェックサム エラーとなりました。 チェックサム エラーを避けるため、ICMDBA によって手動ロガー構成 db 同期を実行します。

チェックサム問題の解決のために後日実行された手順

1. DBMaintnenance のレジストリ キーを 1 に変更することにより、構成変更を停止しました。

2. MSSQL の Logger A のデータベースをすべてバックアップしました。 さらに、Logger B サーバに db のバックアップを転送しました。

3. Logger B のデータベースを破棄して作り直しました。

4. Logger A からの db のバックアップにより、Logger B の Logger db を復元しました。

5. Logger B サービス バックアップの電源を入れました。

6. DBMaintenance のレジストリ キーをリセットして 0 にしました。

Verified

1. ルータ rttest が、CLGR、HLGR、RCV などの Logger B プロセスとの MDS 接続を正常に確立しました。

2. Logger B がデータ チェックサム エラーによって MDS から脱落することはありません。

3. Logger B が数日間シャットダウン状態だったため、システムは活発に HDS で履歴データを同期しています。

4. 設定変更はまだ機能しています。