???????-?????? : Cisco Unified Contact Center Enterprise

Решите Проблемы UCCE, Когда Данные Не будут Записаны в HDS

18 июня 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Отзыв

Введение

Этот документ описывает, как решить проблему с Cisco Unified Contact Center Enterprise (UCCE) Версия 10.x, когда данные не записаны в Historical Data Server (HDS).

Внесенный паваной Дэйв, специалист службы технической поддержки Cisco.

Проблема

После события чистки (между временем на сервере 0:30 и 0:35), таблица восстановления становится пробелом, и данные больше не заполняют на HDS от регистратора. В некоторых случаях DiffDay на регистраторе больше, чем Сохранить значение при просмотре Пространства Используемая Сводка.

Причина

В этом разделе описывается определить причину проблемы.

 Примечание: Имя копии, которое используется для примеров всюду по этому документу, является лабораторной работой, которой можно обменяться с <экземпляром>.

Для шагов первоначального устранения проблем необходимо проверить состояние базы данных через DBA ICM на регистраторах и дистрибьюторах, которые встречаются с этой проблемой. Необходимо также проверить основные ключи реестра для чисток. Для подтверждения размера базы данных и использования, перейдите к DBA ICM, правый щелчок <экземпляр> _ <компонент>, и нажмите Properties. Проверьте, что это не в или выше 80%. Проверьте эту информацию о регистраторе, HDS и Административной рабочей станции (AW) также.

Затем, можно проверить Сводку Использования Пространства на DBA ICM:

  1. Щелкните правой кнопкой мыши <экземпляр> _ <компонент>.

  2. Перейдите к Данным> Пространство Используемая Сводка из меню около начала страницы.

  3. Анчек флажки Display Empty Tables и Display Temporary Tables.

    Если вы просматриваете HDS, который не содержит текущие данные, прошлый раз, что данные были получены на большинстве таблиц, указывает время, что произошла проблема.

Проверьте основные настройки реестра чистки и репликации на регистраторе:

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\LoggerA\
Recovery\CurrentVersion\Purge\Schedule\Schedule
Class Name: <NO CLASS>
Last Write Time: 12/8/2014 - 1:41 PM
Value 0
Name: Schedule
Type: REG_SZ
Data&colon; 00:30 M,T,W,Th,F,S,Su


Key Name:         HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\LoggerA\
NodeManager\CurrentVersion\Processes\rpl
Class Name:       <NO CLASS>
Last Write Time:  11/15/2014 - 1:15 PM
Value 10
 Name:           ImageArgs
 Type:           REG_SZ
 Data&colon;           /db lab_sideA /server /name ROGGER105A/replicationport 41026
/recoveryport 41028

Проверьте основные настройки реестра чистки и репликации на дистрибьюторе:

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
Distributor\RealTimeDistributor\CurrentVersion\Recovery\
CurrentVersion\Purge\Schedule\Schedule
Class Name: <NO CLASS>
Last Write Time: 2/11/2015 - 11:07 PM
Value 0
Name: Schedule
Type: REG_SZ
Data&colon; 00:30 M,T,W,Th,F,S,Su


Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
Distributor\NodeManager\CurrentVersion\Processes\rpl
Class Name: <NO CLASS>
Last Write Time: 2/11/2015 - 11:07 PM
Value 10
Name: ImageArgs
Type: REG_SZ
Data&colon; /db lab_hds /client /name ROGGER105A /replicationport
41026 /recoveryport 41028

На этом этапе, если данные проверены и корректны, следующий шаг должен вытянуть журналы репликации от дистрибьютора и регистратора. Значение следа установлено в 3 на Диагностическом Портике Платформы, который вытягивает журналы вскоре после. Журналы должны показать данные, подобные следующим двум примерам.

Вот журналы репликации регистратора:

14:40:55:861 la-rpl Trace: No MATCHING entry for table t_Termination_Call_Detail,
FromRecoveryKey = 7369086520649.0 and ToRecoveryKey = 7369085626000.0

Вот журналы репликации дистрибьютора:

14:29:52:607 dis-rpl Trace: Sent Replicated request to the Server for table
t_Termination_Call_Detail, FromRecoveryKey = 7369086520649.0 and
ToRecoveryKey = 7369085626000.0

Чтобы лучше понять ключи репликации и Никакую СООТВЕТСТВУЮЩУЮ ЗАПИСЬ , которая появляется в журналах, запросы StructuredQuery Language (SQL) (язык структурированных запросов) выполнены для получения дополнительной информации обо всех регистраторах и дистрибьюторах.

Вот SQL-запросы:

select max(RecoveryKey) from t_Termination_Call_Detail
select max(DateTime) from t_Termination_Call_Detail

Вот результаты SQL-запроса:

RogA - 7369086557263
HDSA - 7369086520649
RogA - 2015-04-06 15:01:47.990
HDSA - 2015-04-05 00:28:19.000

Заметьте, что ключи восстановления для Logger A и Дистрибьютор А значительно далее независимо, чем ожидается и, чем это на стороне B. Кроме того, новые данные на Дистрибьюторе приблизительно совпадают с местоположением недостающих отчётов о данных, которые сначала наблюдались. Также обратите внимание на несоответствие в максимальном расстоянии RecoveryKey между таблицей от запросов и журналами.

Можно просмотреть таблицу восстановления для определения ключей, которые сохранены.

Вот SQL-запрос:

select max(RecoveryKey) from Recovery

Вот результаты SQL-запроса:

HDSA - 7369090330048
RogA - EMPTY

В выходных данных вы видите, что Logger A кажется ПУСТЫМ без ключа восстановления. Так как эти данные неожиданны, необходимо тогда проверить данные в Logger таблица восстановления.

Вот SQL-запрос:

select * from Recovery

Когда этот запрос выполнен, результатами является пробел, который указывает, что нет никаких данных в таблице восстановления. На этом этапе необходимо переоценить записи реестра. Когда эти две стороны экспортируются, и сравнение сделано, несоответствие замечено.

Вот записи реестра для Logger A:

Key Name:         HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
LoggerA\Recovery\CurrentVersion\Purge\Retain\System\Recovery
Class Name:       <NO CLASS>
Last Write Time:  12/8/2014 - 1:39 PM
Value 0
 Name:           Days
 Type:           REG_DWORD
 Data&colon;     0X0000001e

Вот записи реестра для Logger B:

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\lab\
LoggerB\Recovery\CurrentVersion\Purge\Retain\System\Recovery
Class Name: <NO CLASS>
Last Write Time: 12/8/2014 - 1:39 PM
Value 0
Name: Days
Type: REG_DWORD
Data&colon; 0X00000e42

Как показано на Logger A, Дневное значение Восстановления установлено для 0x1e, который является шестнадцатеричным (hex) значение для 30. На Logger B, Дневное значение установлено для 0xe42, который является Шестнадцатеричным значением для 3,650. После дальнейшего рассмотрения с записями реестра по умолчанию в лабораторной работе это, кажется, проблема. Это также совпадает с признаком проблемы, которая происходит приблизительно один раз в месяц.

Решение

Примечание: Cisco рекомендует выполнить действия, которые описаны в этом разделе во время периода технического обслуживания.

Для решения этого вопроса необходимо обновить ключ реестра к 0xe42 (3,650), который является ключом по умолчанию:

  1. Установите ключи реестра в 0xE42 (3,650).

  2. Перезапустите сервис для Logger A.

  3. Перезапустите сервис для Дистрибьютора А.

  4. Перезапустите сервисы для Logger и Дистрибьютора Б, если применимо.

Примечание: Эта проблема в настоящее время расследуется командой разработки и отслежена в идентификаторе ошибки Cisco CSCuu26777.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.