Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Евгений. Member Откуда: Сообщений: 50 |
Добрый день. Помогите составить оптимальный план обслуживания для БД ~ в 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] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1955 |
картинку ошибки "бэкап делать не дам" в студию |
||
14 окт 19, 11:58 [21993554] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37143 |
Оптимизировать индексы надо не все подряд, а только те, для которых это действительно необходимо. Все бэкапы во время ребилдов/реорганайзов индексов проходят успешно (если хватает iops на это, конечно). |
14 окт 19, 12:37 [21993609] Ответить | Цитировать Сообщить модератору |
Евгений. Member Откуда: Сообщений: 50 |
да, это понятно, просто не стал это это расписывать. Оптимизирую только если размер больше 100 страниц, и при фрагментации >10% реорганизация, при >30% перестроение. Если бэкап должен делаться, то допускаю что где то накосячил, к сожалению прошло с тех пор достаточно времени и логи потерлись с ошибками. Попробую повторить процедуру на выходных. А если все же бэкап логов будет делаться, но учитывая что он теоретически может превысить размер базы, то вопрос, можно ли как то уменьшить вообще количество помещаемых в него записей при оптимизации индексов без переключения базы в simple режим? И по поводу https://ola.hallengren.com/ все используют это решение или есть что то лучше? |
14 окт 19, 12:52 [21993630] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37143 |
Евгений.,
|
||
14 окт 19, 12:58 [21993639] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1955 |
можно уменьшить объем того, что уйдет в лог. переключив базу в bulk logged. в бэкап лога уйдет полный объем. |
||
14 окт 19, 13:10 [21993656] Ответить | Цитировать Сообщить модератору |
Евгений. Member Откуда: Сообщений: 50 |
Не использовал никогда и забыл про этот режим) Надо почитать про него. Спасибо. |
||
14 окт 19, 13:12 [21993661] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37143 |
Yasha123, Bulk logged плох тем, что если пока он установлен, что-то случится с файлами данных (а это чуть более вероятно, т.к. при ребилде нагрузка выше), то восстановить базу без потери данных не удастся. Поэтому применимо только если нет никаких бизнес-изменений в это время. Ну и план обслуживания надо начинать с полного бэкапа. |
14 окт 19, 13:50 [21993701] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1955 |
Гавриленко Сергей Алексеевич, для человека, у которого перевод в симпл вызывает лишь "дополнительную возню с бэкапами":
потеря данных явно не проблема |
||
14 окт 19, 14:25 [21993744] Ответить | Цитировать Сообщить модератору |
Евгений. Member Откуда: Сообщений: 50 |
Если нравится к словам цепляться, то это на здоровье. И конечно потеря терабайтной базы совсем не проблема. А если по делу, то ежедневный ПОЛНЫЙ бэкап базы такого размера не то, что хотелось бы делать по многим причинам. Поэтому логично что переключать каждый раз simple\full не вариант. |
||||
14 окт 19, 15:45 [21993848] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8316 |
Евгений., если Вы переключите в simple, то вообще потеряете 24/7 функционал. Бэкапы будут просто мелочью. |
14 окт 19, 16:15 [21993885] Ответить | Цитировать Сообщить модератору |
Евгений. Member Откуда: Сообщений: 50 |
Если можно, чуть подробнее поясните что вы имеете ввиду. |
||
14 окт 19, 16:49 [21993929] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1955 |
при чем тут цепляние к словам? перевод в балк логгед не требует никаких дополнительных полных бэкапов. перед переводом и сразу после него выполняете бэкап лога и имеете возможность восстановить базу на любой момент времени, кроме промежутка времени, пока база была в балк логгед. а вы рассматриваете возможность перевода вообще в симпл, и останавливает вас только "лишний полный бекап". так переведя в симпл вы тем более не сможете восстановить базу на все время, что она пребывала в симпле. но ведь не по этой причине вы не переводите в симпл... |
||
14 окт 19, 17:11 [21993952] Ответить | Цитировать Сообщить модератору |
Евгений. Member Откуда: Сообщений: 50 |
1 раз прокомментирую, а в дальнейшем игнорирую подобные посты т.к. не вижу практической пользы в подобной переписке и захламлении форума. Если не заметили, то ответ был на совершенно другой ваш пост, где речь о bulk logged не велась. А если конкретно, то это ваши слова, а не мои: для человека, у которого перевод в симпл вызывает лишь "дополнительную возню с бэкапами" Про "лишний полный бекап" базы в 1Tb который делается каждый день даже не хочется комментировать. Ну и незачем мне привязывать как будто я настаиваю на переводе базы в simple, если в первом же посте написал что это не желательно. |
||
14 окт 19, 17:36 [21993976] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1955 |
о да блин, вы пишете, что нежелательно, а не исключаете это как возможность. это означает, в вашей системе допустима потеря данных за период. Гавриленко говорит: в балк логгед можно часть данных потерять. еще раз и не буду больше повторять: а у вас и так допустимо потерять, иначе о переводе в симпл речи не было бы вообще. не "нежелательно", а "категорически нет" было бы про простую модель |
||
14 окт 19, 17:45 [21993983] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8316 |
Вы не сможете восстановить состояние базы на любой момент времени. Пока база будет в простой модели вы рискуете потерять все изменения. Плюс простая модель недопустима для реализации высокой доступности, которая требуется для 24/7. |
||||
14 окт 19, 17:46 [21993984] Ответить | Цитировать Сообщить модератору |
Евгений. Member Откуда: Сообщений: 50 |
Это все понятно, спасибо. О переводе в simple написал лишь потому что встречается как решение данной проблемы на просторах интернета, и что бы сразу отсечь подобные советы. |
||||
14 окт 19, 17:51 [21993986] Ответить | Цитировать Сообщить модератору |
Евгений. Member Откуда: Сообщений: 50 |
Я никогда ничего не исключаю как возможность. Кроме восстановления данных средствами бэкапа sql, есть еще несколько вариантов - не хочу вдаваться в детали системы в целом, поэтому допустимо какое то время отсутствие бэкапа, но как и сказал это не желательно. Вы просто зацепились зачем то к конкретным словам "нежелательно" "категорически нет", а тема поста была совсем в другом. |
||||
14 окт 19, 18:01 [21993996] Ответить | Цитировать Сообщить модератору |
Minamoto Member Откуда: Москва Сообщений: 1162 |
Евгений., по поводу дефрагментации индексов рекомендую почитать, для информации: https://www.brentozar.com/archive/2019/08/dba-training-plan-10-managing-index-fragmentation/ И, мне кажется, чистка процедурного кэша тоже совет из разряда "так себе". Я встречался со случаями, когда это было полезно, но это прикрывание проблемы, а не ее исправление. Но я не DBA, так что уверять в правильности своего мнения не буду. |
14 окт 19, 18:20 [21994005] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8316 |
Евгений., я тоже читал советы по переводу базы в простую модель, но число практических сценариев, при которых это допустимо, как мне кажется, исчисляется единицами. Больше всего такие советы похожи на "индусский код". Фактически перерасчет статистик на базе 700гб, состоящей из 700 таблиц занимает до 4-х часов с 30% сэмплами. Для обслуживания используется код с https://ola.hallengren.com. |
14 окт 19, 18:56 [21994034] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
|
||
14 окт 19, 19:29 [21994063] Ответить | Цитировать Сообщить модератору |
Евгений. Member Откуда: Сообщений: 50 |
Владислав Колосов, Спасибо. Попробую снова решение от ola hallengren, вероятно с советом о bulk logged, т.к. иначе размер логов превышает возможности по хранению бэкапов. |
15 окт 19, 11:57 [21994451] Ответить | Цитировать Сообщить модератору |
Гавриленко Сергей Алексеевич Member Откуда: Moscow Сообщений: 37143 |
|
||
15 окт 19, 11:59 [21994453] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1955 |
размер логов о бэкапов лога? в лог уйдет значительно меньше, но в бэкапе лога будут все ваши перестроенные индексы. неясно, какая связь между логами и "возможностями по хранению бэкапов"? у вас бэкапы хранятся на дисках, куда сложены логи баз? |
15 окт 19, 12:01 [21994458] Ответить | Цитировать Сообщить модератору |
Евгений. Member Откуда: Сообщений: 50 |
Связь вероятно такая, что бэкап лога транзакций делается туда же куда и бэкап базы. Если это не очевидно, то извините.
Если уж вы любите докапываться к словам, то куда простите вы складываете логи баз что бы это ни значило в вашей интерпретации? |
||||
15 окт 19, 16:40 [21994817] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |