Исходные данные: Axapta 3.0 SP3 CIS, SQL server 2000 SP3a. База около 6Гб. AOS, толстый клиент.
В определенный момент (вчера) на некоторых операциях (в частности обработке закупок) система входит в ступор (типа зависает), SQL server отжирает много от каждого процессора, кучу памяти и т.п. Попутно порождается куча блокировок в общем работа становится невозможной.
Был проведен комплекс мероприятий по борьбе сданной проблемой
в ходе которого выяснилось: проблема в базе и скорее всего с индексами. Целостность данных не пострадала.
Первым порывом было обновить статистики (автообновление статистики для базы отключено). DBCC DBREINDEX некоторых таблиц и sp_updatestats не помогли.
После чего скриптом был сделан перебор всех таблиц и
DBCC DBREINDEX +
update statistics [table] with fullscan, all. После этого все пришло в норму.
Это было вчера вечером. С утра (сегодня) ситуация в точности повторилась. Запуск описанного выше скрипта проблему решил.
Во временном промежутке между лечением и новым возникновением проблемы никто из пользователей с базой не работал, единственная активность - стандартный (давно заведенный) Maintenance Plan в котором, кроме бэкапа базы и лога, есть процедуры database optimisation с reorganise data and index pages и update statistics с sample = 10% (стандартным).
Понятно, что особого труда создать job, который будет осуществлять вышеописанную процедуру скажем раз в неделю не составляет - вопрос в другом.
Получается, что есть некие значения размера таблицы/индекса и sample ratio для обновления статистики, которые приводят к разрушению(?) индексов для Аксапты? Насколько часто стоит обновлять статистики для базы Axapta (добавление данных не низкой, но очень высокой интенсивности) - ежедневно/раз в несколько дней/раз в неделю/реже? Ну и наконец (хотя наверное это из области религиозных предпочтений) что лучше - использовать стандартный Maintanence plan для обновления статистики с sample ratio 100% или все-же запускать переиндексацию/обновление статистик руками?