Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Неожиданный рост размера лога.  [new]
Egor T.
Member

Откуда:
Сообщений: 3
Коллеги, прошу помочь разобраться.
После некоторых изменений T-log при выполнении плана обслуживания стал увеличиваться до предела диска.

Подробности:
База 1.5 ТБ.
Размер лога обычно: 20 - 40 ГБ. (бэкап и транкейт лога ежедневно)
Ребилд индекса в выходные: лог вырастает до 650ГБ и задача падает.

Что изменилось:
Режим восстановления: simple -> full.
Версия SQL: 2008R2ent -> 2016ent

Режим восстановления изменен на full для AlwaysOn (Сейчас база вне группы)

Каким образом заставить план обслуживания отрабатывать?
Спасибо
29 май 17, 08:56    [20518937]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
aleks2
Guest
Egor T.
Коллеги, прошу помочь разобраться.
После некоторых изменений T-log при выполнении плана обслуживания стал увеличиваться до предела диска.

Подробности:
База 1.5 ТБ.
Размер лога обычно: 20 - 40 ГБ. (бэкап и транкейт лога ежедневно)
Ребилд индекса в выходные: лог вырастает до 650ГБ и задача падает.

Что изменилось:
Режим восстановления: simple -> full.
Версия SQL: 2008R2ent -> 2016ent

Режим восстановления изменен на full для AlwaysOn (Сейчас база вне группы)

Каким образом заставить план обслуживания отрабатывать?
Спасибо


1. Напихать достат.кол. дисков.
2. Перемежать ребилд и бэкап журнала.
29 май 17, 09:19    [20518983]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
aleksrov
Member

Откуда:
Сообщений: 948
Egor T.
Размер лога обычно: 20 - 40 ГБ. (бэкап и транкейт лога ежедневно)

За ким вам полная модель если бекап лога 1 раз в день?
Что значит транкейт? (Многие так обзывают шринк)
Вы делаете ребилд в модели фулл, вот лог и пухнет у вас.
29 май 17, 09:20    [20518988]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
Egor T.
Member

Откуда:
Сообщений: 3
Спасибо за ответы.
Ежедневный бэкап - текущее положение дел, не целевое.
Full требуется ещё и для для AlwaysOn.
Транкейт это транкейт, не шринк.
29 май 17, 09:43    [20519061]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
Basma4
Member

Откуда:
Сообщений: 124
Egor T.,

делайте выборочный ребилд скриптом типа ola или своим велосипедом
дефолтный план трогает все индексы, вы же должны трогать только наиболее вам симпатичные (по размеру, уровню фрагментации и и тд)
29 май 17, 09:47    [20519073]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30711
Egor T.
Транкейт это транкейт, не шринк.
А зачем транкейт, если лог освобождается бакапом лога? И как делается транкейт?
Egor T.
Каким образом заставить план обслуживания отрабатывать?
Ну, либо переводить в симпл на время ребилда индексов, либо делать бакап лога внутри ребилда, между ребилдом отдельных групп индексов.
29 май 17, 10:52    [20519274]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7383
alexeyvg,

поддерживаю, чередуйте ребилд с бэкапом журнала.
Возможно у вас большое число индексов, например, на каждый столбец, отсюда проблема. Перестраивайте рационально, только те, которые требуется перестроить согласно рекомендаций.
29 май 17, 10:59    [20519313]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30711
Владислав Колосов
Возможно у вас большое число индексов, например, на каждый столбец, отсюда проблема. Перестраивайте рационально, только те, которые требуется перестроить согласно рекомендаций.
И вообще это не нужно делать часто. А то, AlwaysOn, и тут индексы в полуторатеррабайтной базе каждый день перестраиваются...
Зачем это, там большинство данных меняется за день или неделю, да ещё и с ращеплением страниц?
29 май 17, 11:02    [20519324]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36686
Egor T.
Каким образом заставить план обслуживания отрабатывать?

Делать бэкап лога чаще, возможно, между ребилдами.
Ребилдить только то, что нужно.
29 май 17, 12:40    [20519707]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
Egor T.
Member

Откуда:
Сообщений: 3
Спасибо за ответы.
Буду разбираться.
29 май 17, 12:54    [20519752]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
человек_ниоткуда
Guest
Egor T.
Размер лога обычно: 20 - 40 ГБ. (бэкап и транкейт лога ежедневно)

Чаще лог бекапь! В период обслуживания - еже-пятиминутно.
В течении рабочего дня бекапь так, чтоб он не рос.
Если грубо потыкай sqlperf, и настрой бекапы так, чтоб больше 75% занятого места небыло в логе.

Egor T.
Режим восстановления: simple -> full.

Вот из-за этого всё! При RM full - ребилд индекса (он скорее всего не нужен тебе, кстати) лог жрёт.

Egor T.
Каким образом заставить план обслуживания отрабатывать?

Есть варианты:
* Убрать rebuild - заменить на reorganize. только статистики обновлять не забывай.
* Поменять перед началом обслуживания RM на Bulk Logged. Правда при включенном AlwaysOn не поможет (на сколько я помню).
* Перед началом обслуживания делать доп. файл лога на бООООльшом диске, а потом удалять. Это геморно и выглядит криво - хотя работает :)
29 май 17, 16:37    [20520721]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
aleksrov
Member

Откуда:
Сообщений: 948
человек_ниоткуда,
* Убрать rebuild - заменить на reorganize. только статистики обновлять не забывай.


Ага, тока лог еще сильнее пухнуть будет, и чем сильнее фрагментирован, тем больше. Пруф
Да, это онлайн операция, но у него ent, он может ребилдить онлайн, хотя это создаст еще большую нагрузку на лог Пруф
И ребилд не замена пересчета статистики.

человек_ниоткуда
* Перед началом обслуживания делать доп. файл лога на бООООльшом диске, а потом удалять. Это геморно и выглядит криво - хотя работает :)

Такого я еще не читал :)
30 май 17, 04:55    [20521767]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
Mr. X
Guest
Egor T.,

Рассмотреть применение секций для больших таблиц.
30 май 17, 08:29    [20521844]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
человек_ниоткуда
Guest
aleksrov
человек_ниоткуда,
* Убрать rebuild - заменить на reorganize. только статистики обновлять не забывай.

Ага, тока лог еще сильнее пухнуть будет, и чем сильнее фрагментирован, тем больше.
Да, это онлайн операция, но у него ent, он может ребилдить онлайн, хотя это создаст еще большую нагрузку на лог

Законно... Согласен. Но если почаще reorganize'ить, то и лог расти не будет.

aleksrov
И ребилд не замена пересчета статистики.

Заменяет. Начиная с SQL11 для секционированных индексов, оно перестало делать FULL_SCAN, но пересчёт имеет место.
Вот тут в разделе Rebuilding Indexes об
том пространно гоаорят.

aleksrov
Такого я еще не читал :)

Я видел это! :)
30 май 17, 12:37    [20522916]     Ответить | Цитировать Сообщить модератору
 Re: Неожиданный рост размера лога.  [new]
o-o
Guest
человек_ниоткуда
aleksrov
И ребилд не замена пересчета статистики.

Заменяет. Начиная с SQL11 для секционированных индексов, оно перестало делать FULL_SCAN, но пересчёт имеет место.
Вот тут в разделе Rebuilding Indexes об
том пространно гоаорят.

при чем тут вообще секционирование и 2012?
ребилд конечно обновляет статистики перестраиваемого индекса.
но он не пересчитывает колоночные статистики.
и поэтому не заменяет пересчет статистик
30 май 17, 14:20    [20523521]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить