Хочется начать с небольшой истории.
Когда я только начинал работать системным администратором, нам в конторе дали указание. Переходим с файлового варианта базы 1С на SQL вариант. Ну в чем проблема, поставил SQL 2008, запустил его, создал базу какую то, по быстрому настроил резервное копирование и забыл про это. И это была ошибка! Ох какая ошибка.
Где то через три-четыре месяца 1С начала тормозить. Но ведь я ничего не делал, значит проблема не с моей стороны. А вот и нет. База SQL без обслуживание становится всё более и более запутанной растет в размерах, и начинает с каждым днем всё медленнее работать. Таким образом запросы, которые поступают от 1С всё дольше и дольше работают.
В SQL существует статистика, из которой строится план выполнения запроса. И вот эту статистику надо периодически обновлять, вот например в таблице есть 100 записей, потом пользователь добавляет еще 10000 записей, но статистика осталась старой, и SQL сервер считает, что в таблице все еще 100 записей, таким образом будет построен неверный план запроса. Так же существует такая вещь, как индексы, которые со временем устаревают и дефрагментируются, что в свою очередь так же замедляет выполнение запросов от 1С.
Что же делать?
Необходимо настроить план обслуживания на сервере MS SQL.
Что необходимо включить в план обслуживания? Я предлагаю свою схему этого плана, она основана на рекомендациях с различных форумов и статей, а так же мой личный опыт подсказывает, что эта схема работает исправно.
Что же делает этот план?
Вначале проверяется целостность БД, это операция на мой взгляд обязательна, после этого я провожу процедуру перестроения индекса, можно конечно же использовать реорганизацию индексов(эта операция проходит быстрее, но я выполняю план раз в день, когда никто не работает и поэтому делаю именно перестроение индекса). Когда индексы перестроены, я обновляю статистику Базы Данных, и следующим шагом удаляю кэш статистики. Зачем это делать? Из приведенного выше примера про статистику я упустил небольшой шаг, после того как запрос отработал, сервер SQL кладет статистику по конкретной таблице в кэш, и в следующий раз будет обращаться именно к кэшу, и если там хранится неверная статистика, то и браться она будет постоянно неверной. Т.е. статистика то обновлена, но запрос всё равно строится не правильно, потому что статистические данные берутся из кэша. Поэтому необходимо после обновления статистики сбросить кэш, это делается очень просто - нужно добавить новую инструкцию T-SQL:
DBCC FREEPROCCACHE
После этого делаем резервную копию, в моём случае это Простой вариант восстановления для всех баз, и делаю я Полный бекап раз в день. Т.е. копия у нас будет уже переиндексированная, целая и с обновленной статистикой. Далее идет очистка после обслуживания, которая удаляет старые копии БД, и очистка журнала, что бы там тоже не копились лишние записи.
В таком режиме БД не превратится в медленную, распухшую от пустых ссылок базу данных, а LOG файл не будет вырастать в безумные размеры.
2)Перестроение\реорганизация индексов
3)Обновление статистики
4)Сброс кэша
5)Бэкап!
6)Очистка после обслуживания
7)Очистка журнала
Всем удачи!
Вот еще народная мудрость: главное не просто иметь бекап БД, но так же и уметь его восстановить.
Когда я только начинал работать системным администратором, нам в конторе дали указание. Переходим с файлового варианта базы 1С на SQL вариант. Ну в чем проблема, поставил SQL 2008, запустил его, создал базу какую то, по быстрому настроил резервное копирование и забыл про это. И это была ошибка! Ох какая ошибка.
Где то через три-четыре месяца 1С начала тормозить. Но ведь я ничего не делал, значит проблема не с моей стороны. А вот и нет. База SQL без обслуживание становится всё более и более запутанной растет в размерах, и начинает с каждым днем всё медленнее работать. Таким образом запросы, которые поступают от 1С всё дольше и дольше работают.
В SQL существует статистика, из которой строится план выполнения запроса. И вот эту статистику надо периодически обновлять, вот например в таблице есть 100 записей, потом пользователь добавляет еще 10000 записей, но статистика осталась старой, и SQL сервер считает, что в таблице все еще 100 записей, таким образом будет построен неверный план запроса. Так же существует такая вещь, как индексы, которые со временем устаревают и дефрагментируются, что в свою очередь так же замедляет выполнение запросов от 1С.
Что же делать?
Необходимо настроить план обслуживания на сервере MS SQL.
Что необходимо включить в план обслуживания? Я предлагаю свою схему этого плана, она основана на рекомендациях с различных форумов и статей, а так же мой личный опыт подсказывает, что эта схема работает исправно.
Что же делает этот план?
Вначале проверяется целостность БД, это операция на мой взгляд обязательна, после этого я провожу процедуру перестроения индекса, можно конечно же использовать реорганизацию индексов(эта операция проходит быстрее, но я выполняю план раз в день, когда никто не работает и поэтому делаю именно перестроение индекса). Когда индексы перестроены, я обновляю статистику Базы Данных, и следующим шагом удаляю кэш статистики. Зачем это делать? Из приведенного выше примера про статистику я упустил небольшой шаг, после того как запрос отработал, сервер SQL кладет статистику по конкретной таблице в кэш, и в следующий раз будет обращаться именно к кэшу, и если там хранится неверная статистика, то и браться она будет постоянно неверной. Т.е. статистика то обновлена, но запрос всё равно строится не правильно, потому что статистические данные берутся из кэша. Поэтому необходимо после обновления статистики сбросить кэш, это делается очень просто - нужно добавить новую инструкцию T-SQL:
DBCC FREEPROCCACHE
После этого делаем резервную копию, в моём случае это Простой вариант восстановления для всех баз, и делаю я Полный бекап раз в день. Т.е. копия у нас будет уже переиндексированная, целая и с обновленной статистикой. Далее идет очистка после обслуживания, которая удаляет старые копии БД, и очистка журнала, что бы там тоже не копились лишние записи.
В таком режиме БД не превратится в медленную, распухшую от пустых ссылок базу данных, а LOG файл не будет вырастать в безумные размеры.
Резюмируем:
1)Проверка целостности2)Перестроение\реорганизация индексов
3)Обновление статистики
4)Сброс кэша
5)Бэкап!
6)Очистка после обслуживания
7)Очистка журнала
Всем удачи!
Вот еще народная мудрость: главное не просто иметь бекап БД, но так же и уметь его восстановить.
Нормальный план обслуживания для "чайников", но уж слишком шаблонный. Народ эти планы будто с одной тетради пишет! Никакой фантазии )). Если база большая, то такой план не подойдет, нужно уже анализировать степень дефрагментации индексов по таблицам, ну и прочие избирательные плюшки, вместо таких "прямолинейных" планов обслуживания, где работает принцип ломай-строй. Вот как вам, например, будет работать ваш план на базе размером в 300+ Гб с 3 тысячами таблиц, которая висит в онлайн режиме круглосуточно, вот же где засада (сам вот голову сломал, как для неё план состряпать, вот что нужно выкладывать(не в обиду автору, ибо сам не осилил выложить свой гайд по обслуживанию той самой базы в 300 гб, хотя определенные положительные шаги были сделаны, может сподоблюсь когда нибудь).
ОтветитьУдалить