привет.

ну во первых база 100gb не такая уж большая, однако.

вот есть у меня база примерно такого объема - какие выводы и способы решения пока сформировались у меня в голове

совет номер 0: план обслуживания СУБД должен быть настроен однозначно при такой базе, в процессе использования должен дорабатываться с учетом текущего положения дел - и обязательно данный SQL скрипт плана облуживания хранить в чем-то версионном - и бакап будет и история того как и зачем ты его менял.

обновление статистики:

необходимо для начала один раз в день - иначе гарантированно будут "артефакты"
частота реально необходимого обновления статистики выявляется экспериментальным путем - например у меня сейчас во вторник и четверг обновление статистики выполняется в 0 часов, 4 часа и 7 часов утра - связано это с тем что в это время идет активное начало работ в удаленных филиалах (Благовещенск например). в остальные дни в 3 утра - это оказывается достаточно.

то есть ставь пока один раз в день, дальше разберешься походу
примеры "семафора" когда со статистикой не все в порядке:
- появились новые отсутствующие индексы с малым количеством вызовов, а в конфигураторе ничего (почти ничего) не менялось = значит оптимизатор SQL "возможно стал ошибаться" в выборе плана запроса.
- пользователи жалуются, что иногда какой нибудь простенький отчет начинает подтормаживать: определяешь эмпирическим путем, когда по времени это происходит - какая у тебя нагрузка на базу от пользовалеей/фоновых заданий - если массовая вставка, посмотри логическую фрагментацию индексов, если с фрагментацией все в порядке, добавь по времени еще одно обновление статистики.

вообщем почти по рекомендации 1С.


P.S. чтобы сократить количество артефактов связанных со статистикой, можно еще использовать сжатие таблиц - реально помогает. НО:
* при реструктуризации сжатие слетает - так как 1С делает фактически новую таблицу копированием.
* сжатие таблиц появилось в версиях MS SQL 2008 и MS SQL 2008 R2 - ссылка на описание сжатия - проверено что данные 1С сжимаюся в среднем в 2-2.5 раза = в итоге база 100 GB будет менее 50 GB - что реально помогает: и планы запросов выглядят "красивше" и т.д
* естественно чтобы автоматизировать данный по хорошему надо писать SQL запрос и добавлять его в план обсуживания - но у нас пока после реструктуризации просто запускается мастер сжатия данных вручную.

UPD: добавил обработочку, требует GameWithFire 

JohnyDeath писал(а) 12. Июля 2011 :: 10:35:


ну это не совсем развернутый , а простой - включай раз в день

а потом наблюдай и для более детального понимания следует наверное обратиться к первоисточнику http://msdn.microsoft.com/ru-ru/library/ms190397.aspx

помимо всего прочего там есть секция "Определение условий обновления статистики" - ее прочитать обязательно: там есть ссылка на Контрольный список анализа медленно выполняемых запросов

а также очень важная секция: "Создание запросов, эффективно использующих статистику" - если в голове попытаться преобразовать это дело к поведению 1С - многие артефакты связанные со статистикой исчезнут.

И еще вопрос. Такие ресурсоемкие задачи как переиндексация когда лучше делать: до "закрытия месяца" или после? "Закрытие месяца" - это момент времени, где система наиболее нагружена, выполняется много запросов и записывается много новых данных.

Удивительное рядом.... Так уж получилось, что сегодня хотел дать в качестве консультации ссылку на google и поисковую строку "Статистика MSSQL и 1С", а данная тема выводится на 4-ом месте.

Прикольно.....Но я не об этот - для тех кто придет также по поисковику, советую присмотреться к следующим ссылкам

http://blogs.msdn.com/b/blogdoezequiel/archive/2012/09/18/about-maintenance-plan...

Если чуть развернутей:

1. у Microsoft существует отдельные товарищи в каждом регионе которые называются PFE
2. насколько я понял - команды PFE инженеров обязаны вести свои блоги/заметки об исследованных/решенных проблемах
3. точкой входа является http://blogs.msdn.com/b/sql_pfe_blog/

В процессе построения "своего велосипеда" - http://www.silverbulleters.org/eshhe-raz-pro-statistiku-1s-po-sereznomu-v-ramkah... по построению прогнозной модели для построения плана обслуживания наткнулся на статью Португальских товарищей.

http://blogs.msdn.com/b/blogdoezequiel/archive/2011/07/03/adaptive-index-defrag....

По ссылке имеется SQL скрипт который позволяет настроить адаптивное перестроение индексов и пересчета статистики и еще много чего.
Вот уже месяц как использую - "не нарадуюсь". Товарищи его уже как 2 года развивают и накапливают кейсы.
Сам скрипт даже без внедрения полезен как кладезь информации - для тех кто умеет читать T-SQL код.