Добрый день.

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

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

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

может поможет
http://www.ravepoint.narod.ru/aticles/tecnology/2methodics/2_8.htm

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

Но, как правило, там другие проблемы :)

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

(3) в (0) я на эту статью и ссылался

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

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

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

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

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

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

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

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

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

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

(15) Можно на глазок, сопоставить объем информации, получение выходных данных. Так же обратить внимание на конструкции...
<ЭтотОбъект.РеквизитКонтрагента.РеквизитОдин.РеквизитДва.и т.д.> :)

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

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

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

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

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

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

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

(19) +1

тут http://catalog.mista.ru/public/308762/ нашел "Самые тяжелые запросы". выполнил, получил http://savepic.net/7529020.htm
Какой из них плохиш?

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

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

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

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