Всем утра. На заметку.
У нас база довольно большая, около 300 ГБ и кол-во пользователей около 400 онлайн в ней. И вот вчера случился локальный армагедон. База встала колом. В итоге расследований оказалось, что в ночном задание на SQL сервере перестало делаться обновление статистики. В этом задании была цепочка из стандартных процедур, чек - статистика-кэш-логи-бэкап. И на последнем этапе отправка письма админу, что бэкап ок. Но переходы были безусловные, то есть не отправлялась письмо сделано или нет задания внутри. А корректность выполнения проверялась только по последней задаче. В общем очередное кровавое правило, следить за всем пошагово.

хм вроде как правило древнее - каждый сам следит за месячными своих подруг

(1) Ну как любое правило в ППД основано на крови, так и тут 4 года работало все штатно.

(2)
> 4 года работало все штатно
Откуда это известно, если "переходы были безусловные, то есть не отправлялась письмо сделано или нет задания внутри" ?)

(3) с другой стороны и сабжевая ситуация штатная, т.к. штатно "переходы были безусловные..."

т.е. за 4 годы было лениво логи заданий почитать хоть раз?

База 300 на гигов говорит, что она уже не так молода и за ней надо приглядывать лучше

(6) 300 гигов - это вообще малютка....

И что из одного пропущенного обновления стаистики база встала колом ?
Что за ?

Вообще по рекомендациям майкрософт
>> Рекомендуется не обновлять статистику слишком часто, поскольку необходимо найти баланс между выигрышем в производительности за счет усовершенствованных планов запросов и потерей времени на перекомпиляцию запросов.
<<
Т.е. в 0 - лажа

(0) Проверь, может у вас закончилось дисковое пространство :)

(8) учитывая, что на больших таблицах сама по себе статистика обновляется только при изменении 20% строк - то запросто, особенно, если в предыдущий день были какие-то операции затрагивающие множество строк в какой-нибудь жирной таблице, типа регистра бухгалтерии.
(9) ну, тащемта, надо учитывать какое количество планов вообще повторно используется. В моей базе 90% планов используются всего 1 раз, а 98% - не более 4-х раз. Оставшиеся два процента на картину вообще никак не повлияют.

(11)
Тогда если  90% планов используются всего 1 раз - частое только ухудшит.

В любом случае - от того, что пара запросов будет выполняться не с самым оптимальным планом - база колом не встанет
Только если они месяц статистику не обновляли, да она еще при этом и не автообновлялась.
Но вместо поиска реальной причины - нашли невыполневшееся задание - и свалили все на него

(2) ППД? Не, не слышал

у кого это в Ижевске такая база?

(8) Как ни странно да. Вернее конечно не колом, работа шла но очень медленно.

(10) Нет, ночью проделал операции вручную и проконтролировал, что прошло обновление и все стало гуд.

Ну вот ты обновил статистику.
Сервер понял что в физ табл регистр бухгалтерии не 10 млн записей , а 10.5 млн.
Что в табл соотв. спр организаций не 30, а 35 записей.
Что различных значений в столбце "счета" рег бухгалтерии(физ табл) их не 300 а 330, на "62.01" приходится 500 000, а не 458 000 записей

Как это кардинально повлияет на работу ?
Все индексы фиксированы.

(17)Что бы не спорить, сошлюсь на эту статью http://kb.1c.ru/articleView.jsp?id=13
и её часть
- Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем. Рекомендуется обновлять статистики не реже одного раза в день.

(18) И да в этой статье идет речь о контроле кстати :)

(17) И еще можно узнать о размере вашей базы 1С и плане её обслуживания, тогда что ли :)

А я сошлюсь на
http://www.sql.ru/articles/mssql/2005/081301statisticsinsqlserver2005.shtml
это как устроено, а не как один 1С ник сказал и все дружно перепосты делают и читают доку из 2 стр "статистика для чайников"

Зачем SQL серверу статистика.
Ты соеденяешь 2 таблицы - ему нужно понять какая маленькая какая большая.Или выборка по столбцам. Или какой из конкурирующих индексов использовать.
Обновляй хоть каждый час - регистр бухгалтерии меньше спр сотрудников не станет. Поэтому автообновление у майкрософта и стоит на 20% - на случай резкого изменения соотношений размеров таблиц

(21) Увы для вас, я буду доверять официальной рекомендации 1С и буду делать обновлении статистики каждый день, тем более на личном опыте понял что значит пропустить один рабочий день в обновлении.
Если вы предпочитаете для своих баз 1С делать раз в неделю, ваш выбор

(22)
Почему Увы для меня - ?
Да ради бога хоть каждый час делайте.
Вроде как официальные рекомендации Майкрософт - только защищаю ?

Только потом на досуге для себя самого поинтересуйтесь - для чего вы это делаете и к чему это приводит.
И почему у Вас упала производительность

Напоследок на пальцах

Вы делаете выборку документов по ИД и Дате в диапазоне
Скл имеет 2 условия не понимет какое первое делать
Смотрит статистику - видит что по Ид одна запись на таблицу на Дату 5000.
Принимает решение по Ид сначала выбирать

Удачи !

(17) дело не только в количестве, но и в распределении этих данных.
Т.е., условно говоря, sql server строит такую гистограмму (для таблицы с 8 млн записей), для индекса по дате в РБ:
01.01.2012 - 40 тыс записей
31.01.2012 - 40 тыс записей
18.02.0212 - 40 тыс записей
11.03.2012 - 40 тыс записей
22.03.2012 - 40 тыс записей
....(ещё 194 периода по 40 тыс)
31.11.2013 - 40 тыс. записей

то он думает, что любой запрос с отбором по периоду с 19.02.2012 по 01.03.2012, вернёт не более 40 тысяч записей, т.е. <= (40000 / 8млн)*100% = 0.5% от общего количества  записей. Поэтому он решает, что можно и использовать index seek.
А ты вчера изменил 1,4 миллиона записей (меньше 20%) и поменял у них период на 20.02.2012 и не обновил статистику - в результате он использует тот же index seek, который при получении 18% записей таблицы в один поток может выполняться просто ппц как долго.
А кроме выбора метода получения данных, SQL Server, может сильно накосячить с выбором метода соединения loop/hash/merge, если не будет знать сколько примерно у него будет данных, что так же запросто может привести к тормозам.
Статистика используется более широко, чем вы говорите в (24).

(21) "Чаще собирайте статистику для возрастающих ключей

Возрастающие ключевые поля, такие как IDENTITY или datetime с реальными timestamps - значениями, могут помешать точному сбору статистики для таблиц, в которых часто происходят вставки - INSERT, и это происходит потому что новые значения оказываются вне гистограммы. Если ваше приложение получает неадекватные планы исполнения запросов с условиями по возрастающим ключевым полям, рассмотрите возможность обновления статистики по таким полям как можно чаще, в задании по расписанию. Частота выполнения таких заданий будет зависеть от вашего приложения. Возможны ежедневные или еженедельные интервалы, или можно это делать и чаще, если это оправдано для вашего приложения."

Из вашей же ссылки. В куче регистров есть индекс ByPeriod, построенный по datetime

(14) +1, тоже интересно

(25)
Абсолютно согласен.
В трех строках сложно описать все использование статистики.
Я не утверждал что ее собирать не надо - только что сомневаюсь что проблема у автора - в одном пропущенном дне сбора
Вряд ли он кардинально менял структуру или массово добавлял/удалял записи.
В конфигурациях 1С все достаточно статично

(28) я один раз нарвался на проблемы связанные именно с необновившейся ночью статистикой и поэтому легко верю, что у автора беда может возникнуть от того же:)

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

(29)
а есть объяснение ?
Например запросы которые для которых стал генерироваться неоптимальный план выполнения

(31) Тяжело запускать профилер и ловить запросы, в момент когда у всех проблемы. Это можно делать когда ты ловишь проблемы в конкретном месте. Тут же было вполне очевидно резкое ухудшение после рабочего дня.Apdex показал падение в 3 раза времени проведения документа. В нашей базе в среднем в день делается 7000 документов, этого мало чтобы достичь 20% от базы, но хватает чтобы скуль справлялся без обновления статистики

(31) да, примерно то, что я описывал в (25). Запрос к РБ сильно ошибался в оценке количества данных, в итоге выполнялся вместо 1 секунды больше чем минуту. А поскольку выполнялся в транзакции, выполнялся он без NOLOCK и "блокировал" кучу пользователей, в итоге "всё вставало колом".

(33)
- вот была "вчерашняя" статистика - по конкретному  ид документа положим 10 записей из 10 млн
по дате дате 40 000.
"Новых" Ид и Дат в статистике нет.

По новым Ид и Датам сервер не может адекватно оценить селективность ?
И например выбирает использовать Дату в отборе сначала, а не Ид ?

(34) вообще не понял вопроса. Если никакого изменения данных не было - конечно, статистику вообще можно не обновлять. В моём случае была проблема с массовым измененим данных, но не дотягивающих для запуска автообновления статистики.

(35)
А, значит все таки было массовое, не обычный рабочий день

Ещё может быть, что SQL обнаруживает, что статистика устарела, из-за дневных изменений, и перестаёт её использовать. А поведение по умолчанию приводит к сканированиям больших таблиц.

(36) понятие "обычный-необычный", оно как бы расплывчатое. Для начала месяца день был обычный.
Расчёт итогов, например, из режима предприятия, при необновлённой ночью статистике по индексам РБ и связанных с ним таблиц, длится больше 2-х часов в любой день, при обновлённой - 3 минуты.
(37) пруф?

(14) (27)
Уралэнерго, я так полагаю.