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

Откуда:
Сообщений: 46
Добрый день.

Помогите составить оптимальный план обслуживания для БД ~ в 1Tb и работающей 24/7
Сервер MS SQL 2012

Полагаю что последовательность желательна такая, но если ошибаюсь, то поправьте:
1. Проверка базы
2. Оптимизация индексов
3. Обновление статистики
4. Чистка процедурного кэша.

Как я понимаю Микрософт не рекомендует использовать
sp_msforeachtable N'DBCC DBREINDEX (''?'')'
но не нашел что они предлагают взамен такое же простое и универсальное, а просто отсылают к ALTER INDEX.

Решение от https://ola.hallengren.com/ приводит к сильному увеличению лога транзакций, сколько не давал, всегда не хватает, последний раз превысил 200Гб. При этом в процессе не дает бэкапить и усекать лог транзакций.
Как вариант конечно можно переводить базу в simple режим, но не хотелось бы это делать, т.к. потом с бэкапами придется возиться.

Понимаю что инфы по этой теме очень много, но вероятно слишком много, что не получается найти хорошее решение среди них.
Поделитесь свежими хорошими решениями как можно более универсальными, а не заточенными под конкретную систему.
Заранее спасибо.
14 окт 19, 11:31    [21993523]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
Евгений.
При этом в процессе не дает бэкапить и усекать лог транзакций.

картинку ошибки "бэкап делать не дам" в студию
14 окт 19, 11:58    [21993554]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36968
Оптимизировать индексы надо не все подряд, а только те, для которых это действительно необходимо.
Все бэкапы во время ребилдов/реорганайзов индексов проходят успешно (если хватает iops на это, конечно).
14 окт 19, 12:37    [21993609]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Евгений.
Member

Откуда:
Сообщений: 46
да, это понятно, просто не стал это это расписывать.
Оптимизирую только если размер больше 100 страниц, и при фрагментации >10% реорганизация, при >30% перестроение.

Если бэкап должен делаться, то допускаю что где то накосячил, к сожалению прошло с тех пор достаточно времени и логи потерлись с ошибками.
Попробую повторить процедуру на выходных.

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

И по поводу https://ola.hallengren.com/ все используют это решение или есть что то лучше?
14 окт 19, 12:52    [21993630]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36968
Евгений.,

Евгений
А если все же бэкап логов будет делаться, но учитывая что он теоретически может превысить размер базы, то вопрос, можно ли как то уменьшить вообще количество помещаемых в него записей при оптимизации индексов без переключения базы в simple режим?
Бэкап лога можно делать _между_ ребилдами индексов. Или просто почаще во время ребилда.
14 окт 19, 12:58    [21993639]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
Евгений.
А если все же бэкап логов будет делаться, но учитывая что он теоретически может превысить размер базы, то вопрос, можно ли как то уменьшить вообще количество помещаемых в него записей при оптимизации индексов без переключения базы в simple режим?

можно уменьшить объем того, что уйдет в лог.
переключив базу в bulk logged.
в бэкап лога уйдет полный объем.
14 окт 19, 13:10    [21993656]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Евгений.
Member

Откуда:
Сообщений: 46
Yasha123
можно уменьшить объем того, что уйдет в лог.
переключив базу в bulk logged.
в бэкап лога уйдет полный объем.

Не использовал никогда и забыл про этот режим)
Надо почитать про него.
Спасибо.
14 окт 19, 13:12    [21993661]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36968
Yasha123,

Bulk logged плох тем, что если пока он установлен, что-то случится с файлами данных (а это чуть более вероятно, т.к. при ребилде нагрузка выше), то восстановить базу без потери данных не удастся. Поэтому применимо только если нет никаких бизнес-изменений в это время. Ну и план обслуживания надо начинать с полного бэкапа.
14 окт 19, 13:50    [21993701]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
Гавриленко Сергей Алексеевич,
для человека, у которого перевод в симпл вызывает лишь "дополнительную возню с бэкапами":
автор
Как вариант конечно можно переводить базу в simple режим, но не хотелось бы это делать, т.к. потом с бэкапами придется возиться.

потеря данных явно не проблема
14 окт 19, 14:25    [21993744]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Евгений.
Member

Откуда:
Сообщений: 46
Yasha123
Гавриленко Сергей Алексеевич,
для человека, у которого перевод в симпл вызывает лишь "дополнительную возню с бэкапами":
автор
Как вариант конечно можно переводить базу в simple режим, но не хотелось бы это делать, т.к. потом с бэкапами придется возиться.

потеря данных явно не проблема


Если нравится к словам цепляться, то это на здоровье.
И конечно потеря терабайтной базы совсем не проблема.

А если по делу, то ежедневный ПОЛНЫЙ бэкап базы такого размера не то, что хотелось бы делать по многим причинам.
Поэтому логично что переключать каждый раз simple\full не вариант.
14 окт 19, 15:45    [21993848]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7754
Евгений.,

если Вы переключите в simple, то вообще потеряете 24/7 функционал. Бэкапы будут просто мелочью.
14 окт 19, 16:15    [21993885]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Евгений.
Member

Откуда:
Сообщений: 46
Владислав Колосов
Евгений.,

если Вы переключите в simple, то вообще потеряете 24/7 функционал. Бэкапы будут просто мелочью.


Если можно, чуть подробнее поясните что вы имеете ввиду.
14 окт 19, 16:49    [21993929]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
Евгений.
Если нравится к словам цепляться, то это на здоровье.
И конечно потеря терабайтной базы совсем не проблема.

А если по делу, то ежедневный ПОЛНЫЙ бэкап базы такого размера не то, что хотелось бы делать по многим причинам.
Поэтому логично что переключать каждый раз simple\full не вариант.

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

так переведя в симпл вы тем более не сможете восстановить базу на все время,
что она пребывала в симпле.
но ведь не по этой причине вы не переводите в симпл...
14 окт 19, 17:11    [21993952]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Евгений.
Member

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

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


1 раз прокомментирую, а в дальнейшем игнорирую подобные посты т.к. не вижу практической пользы в подобной переписке и захламлении форума.

Если не заметили, то ответ был на совершенно другой ваш пост, где речь о bulk logged не велась.
А если конкретно, то это ваши слова, а не мои:
для человека, у которого перевод в симпл вызывает лишь "дополнительную возню с бэкапами"

Про "лишний полный бекап" базы в 1Tb который делается каждый день даже не хочется комментировать.

Ну и незачем мне привязывать как будто я настаиваю на переводе базы в simple, если в первом же посте написал что это не желательно.
14 окт 19, 17:36    [21993976]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
Евгений.
Ну и незачем мне привязывать как будто я настаиваю на переводе базы в simple, если в первом же посте написал что это не желательно.

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

Гавриленко говорит: в балк логгед можно часть данных потерять.
еще раз и не буду больше повторять:
а у вас и так допустимо потерять,
иначе о переводе в симпл речи не было бы вообще.
не "нежелательно", а "категорически нет" было бы про простую модель
14 окт 19, 17:45    [21993983]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7754
Евгений.
Владислав Колосов
Евгений.,

если Вы переключите в simple, то вообще потеряете 24/7 функционал. Бэкапы будут просто мелочью.


Если можно, чуть подробнее поясните что вы имеете ввиду.


Вы не сможете восстановить состояние базы на любой момент времени. Пока база будет в простой модели вы рискуете потерять все изменения. Плюс простая модель недопустима для реализации высокой доступности, которая требуется для 24/7.
14 окт 19, 17:46    [21993984]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Евгений.
Member

Откуда:
Сообщений: 46
Владислав Колосов
Евгений.
пропущено...


Если можно, чуть подробнее поясните что вы имеете ввиду.


Вы не сможете восстановить состояние базы на любой момент времени. Пока база будет в простой модели вы рискуете потерять все изменения. Плюс простая модель недопустима для реализации высокой доступности, которая требуется для 24/7.


Это все понятно, спасибо.
О переводе в simple написал лишь потому что встречается как решение данной проблемы на просторах интернета, и что бы сразу отсечь подобные советы.
14 окт 19, 17:51    [21993986]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Евгений.
Member

Откуда:
Сообщений: 46
Yasha123
Евгений.
Ну и незачем мне привязывать как будто я настаиваю на переводе базы в simple, если в первом же посте написал что это не желательно.

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

Гавриленко говорит: в балк логгед можно часть данных потерять.
еще раз и не буду больше повторять:
а у вас и так допустимо потерять,
иначе о переводе в симпл речи не было бы вообще.
не "нежелательно", а "категорически нет" было бы про простую модель


Я никогда ничего не исключаю как возможность. Кроме восстановления данных средствами бэкапа sql, есть еще несколько вариантов - не хочу вдаваться в детали системы в целом, поэтому допустимо какое то время отсутствие бэкапа, но как и сказал это не желательно.
Вы просто зацепились зачем то к конкретным словам "нежелательно" "категорически нет", а тема поста была совсем в другом.
14 окт 19, 18:01    [21993996]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1162
Евгений., по поводу дефрагментации индексов рекомендую почитать, для информации:

https://www.brentozar.com/archive/2019/08/dba-training-plan-10-managing-index-fragmentation/

И, мне кажется, чистка процедурного кэша тоже совет из разряда "так себе". Я встречался со случаями, когда это было полезно, но это прикрывание проблемы, а не ее исправление.
Но я не DBA, так что уверять в правильности своего мнения не буду.
14 окт 19, 18:20    [21994005]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7754
Евгений.,

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

Фактически перерасчет статистик на базе 700гб, состоящей из 700 таблиц занимает до 4-х часов с 30% сэмплами.

Для обслуживания используется код с https://ola.hallengren.com.
14 окт 19, 18:56    [21994034]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
Владислав Колосов
я тоже читал советы по переводу базы в простую модель, но число практических сценариев, при которых это допустимо, как мне кажется, исчисляется единицами. Больше всего такие советы похожи на "индусский код".
Для хранилищ скорее нужно выбирать симпл, чем другие. Не все же базы - OLTP
14 окт 19, 19:29    [21994063]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Евгений.
Member

Откуда:
Сообщений: 46
Владислав Колосов,

Спасибо.
Попробую снова решение от ola hallengren, вероятно с советом о bulk logged, т.к. иначе размер логов превышает возможности по хранению бэкапов.
15 окт 19, 11:57    [21994451]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36968
Евгений.
Владислав Колосов,

Спасибо.
Попробую снова решение от ola hallengren, вероятно с советом о bulk logged, т.к. иначе размер логов превышает возможности по хранению бэкапов.
Бэкапы лога в bulk logged поболее будут, чем то, что пишется в лог. Но, скорее всего, меньше, чем в full.
15 окт 19, 11:59    [21994453]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Yasha123
Member

Откуда:
Сообщений: 1833
размер логов о бэкапов лога?
в лог уйдет значительно меньше, но в бэкапе лога будут все ваши перестроенные индексы.
неясно, какая связь между логами и "возможностями по хранению бэкапов"?
у вас бэкапы хранятся на дисках, куда сложены логи баз?
15 окт 19, 12:01    [21994458]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальный план обслуживания.  [new]
Евгений.
Member

Откуда:
Сообщений: 46
Yasha123
размер логов о бэкапов лога?
в лог уйдет значительно меньше, но в бэкапе лога будут все ваши перестроенные индексы.
неясно, какая связь между логами и "возможностями по хранению бэкапов"?

Связь вероятно такая, что бэкап лога транзакций делается туда же куда и бэкап базы. Если это не очевидно, то извините.
Yasha123
у вас бэкапы хранятся на дисках, куда сложены логи баз?

Если уж вы любите докапываться к словам, то куда простите вы складываете логи баз что бы это ни значило в вашей интерпретации?
15 окт 19, 16:40    [21994817]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить