SQL тормоза. Вручную вызываю dbcc freeproccache #761554

Добрый день. База стала часто тормозить (проведение ОПЗС 3 минуты). Помогает dbcc freeproccache (проведение ОПЗС 5-15 секунд), но хочется понять от чего это? В мануалах от 1С предлагается выполнять чистку процедурного кэша после обновления статистики - это всё в планах обслуживания записано, выполняется ночью. А проблемы наблюдаю днем. Как найти причину? Можно кидать ссылки.

Здесь прочитал про "известную проблему 1С при выборке документов с пустыми датами" - кто-то может пояснить что это за проблема?

К появилась идея: может как-то где-то выполняется обновление статистик (кроме плана обслуживания). Если да- как отследить и повесить ему принудительную очистку процедурного кэша?

может поможет

Переходите на 7.7 + SQL + 1С++ + Прямые запросы с прямыми руками... Там нет тормозов :) Но, как правило, там другие проблемы :)

+ "5 - 15" сек тоже не так уж и мало :)

в я на эту статью и ссылался

Нагуглил: у баз стоит "Автоматическое обновление статиистики=True". Вроде надо отключить. Надо ли?

А джобой это делаете?

в уже писал: обновление статистики и очистка процедурного кеша - раз в день ночью. Так что да, делаем.

а вы проверяли,что выполняется?

Корфа - типовая, без правок? Платформа какая?

если ошибка - настроена рассылка. Рассылки не было. УПП нетиповая

Тогда профайлер и смотри тормозной запрос

Согласно вашим симптомам (dbcc freeproccache мгновенно снимает тормоза), следует искать гениальный запрос при проведении документа

Благодарю. А как примерно искать?

Профайлер, тех. журнал, ЦУП - чем умеете

Можно на глазок, сопоставить объем информации, получение выходных данных. Так же обратить внимание на конструкции...

Эта штука работает только при изменении 20 процентов строк в таблице.

Получается если запрос пошел через sp_executesql, то он один раз формируется и кэшируется. Второй раз план уже не строится, а берется из кэша. То есть с одними параметрами запрос выполняется быстро, а с другими медленно.Ваш кэп)

ну профайлер открывал пару раз. А дальше?

Тогда лучше техжурнал настройте.

жмете провести и смотрите ) Ещё можете замер производительности использовать - проще будет.

Цель - найти самый долгий по времени выполнения запрос

Время запроса - Duration

+1

тут нашел "Самые тяжелые запросы". выполнил, получил Какой из них плохиш?

Зачем так усложнять простое. Открой конфигуратор, да поймешь, что да где :)

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

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

Два раза щелкни по ячейке из колонки "query plan"