Добрый день.
При попытке подключения к статистике GPRS модемов возникает ошибка.
Причиной ошибки является то, что ваша СУБД не отвечает за отведенный период времени. Если увеличение времени ожидания ответа от БД не помогает, значит вам стоит проанализировать причину столь долгого ответа от БД и устранить их. Это может быть как нехватка производительности компьютера, на котором расположена СУБД, так и некорректная работ отдельных его элементов. Например, у вас может быть установлен HDD, скорость работы которого по современным меркам очень маленькая и это часто приводит к проблемам с своевременным ответом различных приложений, в особенности СУБД, так как при большом объеме данных, которые записываются и считываются в/из файла БД, скорость работы жесткого диска крайне важна. Также может быть нехватка других ресурсов.
Вам стоит обратиться к специалисту, обслуживающему работу компьютеров и/или СУБД в вашей организации и решить с ним данный вопрос. Если подобного сотрудника в вашей организации нет, вы можете пригласить стороннего специалиста.
P.S. Исходя из присланного журнала ошибок увеличение времени ожидания ответа от БД вами не производилось. По умолчанию у параметра CommandTimeout=‘60’ и в ваших запросах именно такое значение данного параметра. Попробуйте увеличить время ожидания.
Обращаю ваше внимание, что увеличение времени ожидания является способом обхода данной ситуации, а не ее решением.
Этот отчет очень тугой. Если модемов много и таблица GprsControllerSession очень большая, отчет будет туго прогружаться.
Да, отчет емкий из-за большого обьема информации. Его нужно как то “подрезать”.
Вы можете уменьшить срока хранения журнала GPRS-соединений в настройках обслуживания базы данных в системных параметрах (раздел Журналы), что позволит уменьшить количество записей, хранящихся в данной таблице, по выполнении обслуживания БД после изменения данных настроек.
Добрый день.
Разобрались с вопросом - большой обьем данных связанных с работой модемов.
Пробовали уменьшить срока хранения журнала GPRS-соединений в настройках обслуживания базы данных в системных параметрах. ЛЭРС. Ставим “Выполнить очистку БД сразу после сохранения параметров”, но ЛЭРС не выполняет действия по очистке, приходится вручную чистить, но это очень долго. Как то можно ускорить процесс?
ЛЭРС УЧЕТ на самом деле выполняет очистку, но порциями по 10000 записей. Если данных очень много и при этом Сервер ЛЭРС УЧЕТ полноценно работает по другим задачам, то удаление может происходить очень медленно. Возможно в ходе выполнения операции очистки возникли какие то ошибки, в результате чего она была остановлена. В этом случае ее стоит запустить еще раз.
Как следствие из описанного выше, для ускорения операции очистки вам стоит остановить все ресурсоемкие операции (автоопрос, формирование отчетов и т.д.), чтобы Сервер выполнял только очистку базы, а также не создавал нагрузку на железо (Процессор, Жесткий диск). Также стоит учитывать, что ЛЭРС УЧЕТ отправляет команды очистки SQL Server и фактически очисткой занимается СУБД, поэтому ей должно хватать ресурсов для своевременного выполнения операций. В случае если Сервер ЛЭРС УЧЕТ и СУБД SQL Server находятся на одном компьютере, это очень важно.
