Регламентные операции на уровне СУБД для MS SQL Server ч.4

Рубрика: SQL, Памятка

Продолжение статей:

  1. Регламентные операции на уровне СУБД для MS SQL Server
  2. Регламентные операции на уровне СУБД для MS SQL Server ч.2
  3. Регламентные операции на уровне СУБД для MS SQL Server ч.3

Реиндексация таблиц базы данных

Реиндексация таблиц включает полное перестроение индексов таблиц базы данных, что приводит к существенной оптимизации их работы. Рекомендуется выполнять регулярную переиндексацию таблиц базы данных. Для реиндексации всех таблиц базы данных необходимо выполнить следующий SQL запрос:

sp_msforeachtable N'DBCC DBREINDEX (''?'')'

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

После выполнения реиндексации нет необходимости делать дефрагментацию индексов.

Настройка реиндексации таблиц (MS SQL 2005)

В ранее созданном плане обслуживания создайте новый субплан с именем «Реиндексация». Добавьте в него задачу Rebuild Index Task:

 

 

 

 

 

 

 

 

 

 

 

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

Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.

 

 

 

 

 

 

 

 

 

 

 

 

В следующей статье напишу о контроле выполнения регламентных процедур на уровне СУБД.

{lang: 'ru'}


Затвитить пост!

Рейтинг:
1 Star (Еще не оценили)
Загрузка...
Популярность: Просмотров: 813

4 комментария к “Регламентные операции на уровне СУБД для MS SQL Server ч.4”

  • andr_andrey
    13 февраля, 2017, 10:53
    Цитировать

    При модели восстановления «Полная» начинает распухать лог-файл базы и соответственно бекап лога. Например, на базе 90Гб лог файл пухнет без бекапа на 80Гб, а с бекапом надо иметь ввиду, что эти 80Гб могут исчерпать дисковое пространство. Кстати, время выполнения ребилда около 3,5 часов

  • 13 февраля, 2017, 11:02
    Цитировать

    При полной модели восстановления, если регулярно не бекапить и не сжимать лог, то он естественно будет расти, я обычно это делаю, через соответствующий план обслуживания или через job в агенте. Отчеты о выполнении падают на почту.

    Дисковое пространство нынче не так уж и дорого, а долгие бэкапы можно хранить например в облаке для архивов (холодное хранение) у того же mail.ru, сервис называется IceBox и стоит 3 руб./Гб в месяц.

    Каждый в принципе решает для себя сам, насколько бизнесу важны данные и за какой период.

  • andr_andrey
    13 февраля, 2017, 11:09
    Цитировать

    Регулярный бекап с полной моделью размазывает этот восьмидесятимегабайтный лог по кускам, но размер от этого не становится меньше, даже больше, учитывая перекрытия. Куча новичков бегут с советом поменять модель на «Простая», не понимая в чём различия.

  • 13 февраля, 2017, 11:29
    Цитировать

    Так и есть. Чтобы прикрыть тылы, план бэкапа всегда обсуждаю с каждым из заказчиков индивидуально, описываю плюсы и минусы каждого из предложенных вариантов, совместно приходим к какому-то общему решению, подписываем план и только после этого происходит развертывание сервиса. Если бизнесу не критична потеря данных за один операционный день, то я тоже не парюсь, ставлю модель восстановления «Простая» и делаю полные бэкапы каждый день, с глубиной к примеру неделя.

Оставить комментарий или два

--> Яндекс.Метрика Рейтинг@Mail.ru