Управление базами данных — различия между версиями

Версия 18:05, 27 апреля 2011

Задействовать ограничение на количество одновременных потоков пакетной обработки БД

Устанавливает режим, при котором внутри комплекса производится принудительное разграничение доступа к БД с использованием очереди. Пропускная способность (количество потоков) задается параметром. Включение режима рекомендуется во избежание регламентированного замедления работы ядра MS SQL SERVER, если его версия имеет ограничение на количество потоков (Desktop Edition и Personal Edition). В случае интенсивной работы с доступом к БД (например прогрессивный набор номеров на значительном числе каналов) возможна блокировка ресурсов и замедление работы, что сказывается на стабильности работы системы и появлении пауз. Ситуация усугубляется тем, что блокировка ресурсов, происходящая в замедленных подключениях может приводить и к торможению выполнения запросов основных 5-8 потоков. Подробнее об ограничениях в документации к MS SQL Server.

Удалить несуществующие связи (проекты, задачи, операторы) из пространственной БД с сохранением статистики

Осуществляет очистку списков операторов, проектов и задач в пространственной БД. Удаляются те элементы, которые уже удалены из основной базы (не присутствуют в списках операторов, проектов и задач соответственно). Статистика пространственной БД, связанная с удаляемыми элементами, остается не затронутой. Однако привязка осуществлена уже быть не может. Доступным остается только построение сводных отчетов.

Удалить статистику call-центра из пространственной БД, связанную с уже несуществующими ресурсами

Осуществляет очистку списков операторов, проектов и задач в пространственной БД. Удаляются те элементы, которые уже удалены из основной базы (не присутствуют в списках операторов, проектов и задач соответственно). Удаляется также статистика из пространственной БД, связанная с удаляемыми элементами. Становится невозможным получить даже сводные показатели. Например, при удалении статистики по удаленному проекту становится невозможным получить корректные сведения о средней загрузке линий за тот период, где осуществлялась работа с удаленным проектом.

Операция может занять значительное время и ресурсы сервера баз данных. Относится к перечню операций обслуживания БД (единовременно сервером может производиться не более одной такой операции).

Очистка оперативной статистики по задачам

Осуществляет очистку оперативной базы данных от информации, связанной с работой задач. Аналогично вызову команды «Очистить оперативную статистику» для каждой задачи.

Операция может занять значительное время и ресурсы сервера баз данных. Относится к перечню операций обслуживания БД (единовременно сервером может производиться не более одной такой операции).

Автоматическая профилактика базы данных

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

Операция может занять значительное время и ресурсы сервера баз данных. Относится к перечню операций обслуживания БД (единовременно сервером может производиться не более одной такой операции).

ВНИМАНИЕ! При реализации массовых кампаний рекомендуется регулярно пользоваться режимом профилактики.

ВНИМАНИЕ! Не стоит только лишь уповать на автоматику. При плотной работе необходимо размещать базу на нескольких жестких дисках, использовать средства ускорения доступа к жестким дискам (RAID5, RAID10), разносить базу по файловым группам, регулярно производить оценку состояния базы, сохранять резервные копии, очищать данные при возможности, перемещать неактуальные данные на другие серверы и т.д. Без принятия описанных мер при сильном разрастании базы снижается производительность системы, и в отдельных особых случаях возможно появление некорректных ситуаций в АТС.

Автоматическая профилактика базы данных и очистка

Помимо вышеописанного режима профилактики производит очистку таблиц для снижения общего размера базы данных. Подобная фукнция может потребоваться при реализации массовых кампаний для сохранения скорости обработки информации в БД. В случае необходимости удаляемые данные можно предварительно переносить в сторонние БД.

Операция может занять значительное время и ресурсы сервера баз данных. Относится к перечню операций обслуживания БД (единовременно сервером может производиться не более одной такой операции).

Резервное копирование основной базы данных

Осуществляет создание резервной копии основной базы данных, где хранятся настройки, данные по звонкам и задачам (без статистики колл-центра). Файлы архивных копий размещаются в каталоге Backup корневого каталога серверной службы и называются db_[дата].bak.

Операция может занять значительное время и ресурсы сервера баз данных. Относится к перечню операций обслуживания БД (единовременно сервером может производиться не более одной такой операции).

Резервное копирование сценариев

Осуществляет создание архива с резервными копиями всех сценариев системы (только структур самих сценариев без файлов-вложений). Файлы архивных копий размещаются в каталоге Backup корневого каталога серверной службы и называются scr_[дата].zip.

Производить ежедневную автоматическую оптимизацию БД

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

Для режима актуальны предупреждения, указанные выше в описании действия «Автоматическая профилактика базы данных».

Операция может занять значительное время и ресурсы сервера баз данных. Относится к перечню операций обслуживания БД (единовременно сервером может производиться не более одной такой операции).

Описываемые ниже свойства предоставляют возможность снизить плотность обращений к серверу баз данных за счет исключения некоторых направлений и видов работ. По умолчанию все работы активированы. Однако в объемных базах данных, где не производится периодическая архивация данных, отсутствуют ускоряющие работу RAID-массивы, не используются разнесенные файловые группы, каждое лишнее обращение может быть критичным. Торможение базы может сказываться на качестве работ в реальном времени, когда call-центр ведет активную работу со множеством абонентов. При возникновении заметных торможений можно воспользоваться и отключить некоторые из перечисленных режимов работы с БД.

Активировать расчет пространственной таблицы состояний операторов

Расчет пространственной таблицы состояний операторов в базе данных call-центра производится для обеспечения call-центра статистикой по операторам. Расчет производится с определенными интервалами времени, обеспечивая статистикой, максимально приближенной к статистике реального времени. При работе сервером выполняется ряд быстрых процедур по сохранению измененных состояний пользователей (операторов) в различных модулях системы. В одно и то же время оператор может находиться в call-центре, быть занят в задаче, осуществлять разговор с другим оператором. Каждый из модулей системы заносит информацию при учитываемой им смене состояния пользователя. Сложность выполняемой процедуры заключается в синтезе совокупных данных, учитывающих данные из нескольких таблиц, и просчитывающих время нахождения в каждом элементарном состоянии.

Получаемая в итоге статистика доступна для внешних отчетных систем, используется в статистических модулях Oktell таких как «Ресурсы», «Индикаторы», «Отчеты».

Одна итерация расчета данных может длиться до 20-30 секунд и существенно увеличивать загрузку процессора на сервере баз данных. Дорогостоящей операцией в ходе процесса является обращение к таблицам на выборку данных.

Подробно о пространственной таблице состояний операторов в разделе Структура пространственной БД.

Период таймера обработки БД call-центра

Расчет пространственной таблицы состояний операторов в базе данных call-центра производится по умолчанию один раз в минуту. Этот процесс при достаточно большом числе операторов происходит в течение заметного времени (до 20-30 секунд) с увеличением загрузки процессора на сервере баз данных. В большинстве случаев это не сказывается на работе системы, однако с помощью данного свойства можно увеличить промежуток между расчетами. Это отразится на индикаторах и статистике, строящихся на базе пространственной таблицы состояний операторов, включающих еще не рассчитанное время.

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

Активировать расчет пространственной таблицы состояний очереди

Расчет пространственной таблицы состояний очереди производится для обеспечения call-центра статистикой по состояниям очередей всех задач. Каждое точечное изменение очереди (изменение числа операторов, изменение числа абонентов) вызывает сохранение в пространственную таблицу новой строки. При достаточно большой нагрузке на call-центр и большом количестве задач использование этой процедуры может сказываться на качестве работы. Если статистика по состоянию очередей не используется или ей можно пожертвовать, снятием этого флага можно исключить обращение к БД на сохранение данных.

Подробно о пространственной таблице состояний очередей в разделе Структура пространственной БД.

Способ внесения данных о состоянии очереди в БД

Пространственная таблица, хранящая состояния очереди всех задач, претерпевает изменения данных (вставку) при каждом изменении в состоянии очереди каждой задачи - количества операторов, абонентов. В особых случаях ее заполнение можно производить в асинхронном режиме, чтобы блокировка базы данных при попытке обращения к таблице не сказывалась на работе пула входящей задачи. Синхронный режим заполнения таблицы подразумевает приостановку пула на время вставки данных в таблицу.

Сохранять в БД статистику сценариев диалога

Сохранение статистики сценариев диалога производится для обеспечения данными встроенного модуля Отчеты сценариев в режиме построения диаграмм на основе элементов управления диалоговых форм. Даже если не используется модуль, каждый запуск диалогового сценария тем не менее инициирует обращение в БД с размещением информации о начале и завершении работы сценария.

Производить сохранение уведомлений

Уведомления служат для информирования пользователей об определенных изменениях на сервере и в клиентском приложении. Далеко не все из них сохраняются в БД. Сохраненные же доступны в разделе Кабинет. Уведомления. Удаление этой статистики не производится в автоматическом режиме, и при росте объема базы данных сохранение может занимать ресурсы сервера БД. Снятием флага производится отключение сохранения всех уведомлений (даже если в компоненте сценария явно установлено свойство «Сохранять в БД») . Уведомления продолжают доставляться в реальном времени авторизованным пользователям.

Производить сохранение статистики контрольных событий

При возникновении в call-центре контрольного события осуществляется связанное с ним действие - уведомление и/или запуск служебного сценария. Факт возникновения КС также сохраняется в БД для возможности последующего доступа к нему из модуля Call-центр. Контрольные события. Сохранение может быть отключено снятием флага.

Обновлять состояния задач при сохранении результатов каждой попытки

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

Обновлять состояния абонентов задачи при каждом обращении к кэшу в БД

При работе сервера с задачами, использующими кэш внутри БД (свойство задач Метод работы с таблицей абонентов), каждое очередное обращение к БД на предмет поиска абонента сопровождается обращением к таблицам с оперативной статистикой по задаче на восстановление состояний (количество отбоев, количество попыток без ответа, дата/время следующей попытки, время в очереди и т.д.). Если задача массовая, и эти сведения некритичны, то снятием флага можно исключить это обращение и привнести снижение нагрузки на БД. Некритичными сведения могут считаться, например, если осуществляется первый проход по таблице, или если не используется установка дат/времени следующего обращения.

Сохранять информацию о пропущенных вызовах

Активация режима приведет к формированию таблицы A_Stat_MissedCalls, содержащей информацию о пропущенных звонках. Пропущенным (не путать с потерянным) для пользователя называется звонок, который поступил на индивидуальный или групповой внутренний номер и не был обработан пользователем. При этом система не делает различий, был ли обработан звонок на этот внутренний номер кем-то другим или получил отказ, был ли это первый вызов в рамках цепочки коммутаций или повторный, был ли пользователь свободен или занят.

Информация о пропущенных звонках доступна пользователям в разделе Офис. Мои звонки.

Сохранять RingTime (время вызова пользователей и операторов)

Активация режима приведет к формированию таблицы A_Stat_RingTime, содержащей информацию о каждой сессии вызова каждого пользователя и/или оператора. Сессия вызова может включать как одного, так и нескольких вызывающих абонентов, при этом обработанным может быть только один - последний. В таблице фиксируется идентификатор линии пользователя и его собственный идентификатор, время начала вызова его внутренней линии, время в миллисекундах, прошедшее до отбоя или снятия трубки, факт снятия/неснятия пользователем трубки. Если за время вызова произошел отбой одного или нескольких абонентов из очереди (были перехвачены другими пользователями, положили трубки, были возвращены в сценарии по таймауту, были отклонены пользователем) - фиксируется количество таких абонентов, находящихся в первой позиции очереди пользователя и сменившихся при текущей сессии вызова. Количество отклоненных вызовов, а также количество вызовов, приведших к таймауту вызова (в рамках первой позиции очереди) также попадает в таблицу. Если настройка системы такова, что при таймауте вызываемый пользователь переводится в состояние «Нет на месте», то этот момент также будет отражен в таблице.

Может применяться при анализе времени ответа пользователями/операторами безотносительно конкретных звонков и вызывающих абонентов.

Подобная независимая от звонков статистика продиктована наличием групповых номеров, различных возможных настроек системы - перехватов, переадресаций, перевода в Off, совмещения нескольких номеров и задач одним пользователем, единой очередью для нескольких пользователей, различными очередями на одного пользователя и всевозможными миксами. В целях соблюдения строгой очередности обслуживания в любых условиях вызов внутреннего пользователя для обработки одного звонка или очереди производится еще до определения конкретного абонента. Поэтому в рамках одной сессии вызова пользователя может быть изменено несколько потенциальных абонентов. И рассматривать время вызова пользователя в рамках одного звонка в общем случае не следует, так как иначе будут объединены случайные независимые величины и их анализ будет существенно затруднен. Взамен предлагается анализировать их отдельно: максимальное время ожидания абонентами в очереди (первая случайная величина), время снятия трубки операторами от начала вызова (вторая случайная величина). Другие факторы, такие как размер и количество очередей, количество пользователей, уровень пересечения разных очередей и разных пользователей, также не стоит объединять с анализом случайных величин.

Сохранять в БД все получаемые по внешним линиям DTMF-символы

При активации режима все поступающие в систему DTMF символы будут сохраняться в таблице основной базы данных A_Stat_DTMF (символ, время, Guid-идентификатор линии).