Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
Добрый вечер. Ищу ответ на вроде бы элементарный вопрос: Есть ли разница в нагрузке на диск / процессор / ОЗУ при использовании полной модели восстановления и простой модели восстановления? Интересует именно процесс работы, а не затрачиваемые ресурсы на регулярный бэкап журнала транзакций. Может быть есть какая-то ссылка, которую можно изучить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2019, 16:09 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
morohon Есть ли разница в нагрузке на диск / процессор / ОЗУ при использовании полной модели восстановления и простой модели восстановления? Если таких операций вами не предусмотрено, то без разницы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2019, 16:59 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
alexeyvg, А вы не можете кинуть в меня ссылкой, где про это почитать можно подробнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 09:27 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
morohon alexeyvg, А вы не можете кинуть в меня ссылкой, где про это почитать можно подробнее? Влияние на операции с индексами: Выбор модели восстановления для операций с индексами Вот ещё перевод от Александра Гладченко: Руководство по производительности загрузки данных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 11:11 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
alexeyvg, Спасибо огромное! А подскажите еще момент пожалуйста, касательно как раз второй ссылки: https://docs.microsoft.com/ru-ru/previous-versions/sql/sql-server-2008-r2/ms191484(v=sql.105) Правильно ли я понимаю, что здесь идет речь о том, что при полной модели восстановления и выполнения процедуры реиндексации (как частный пример) будет резкий рост журнала транзакций и, чтобы этого избежать, рекомендуется на время выполнения этой операции необходимо переводить базу данных в простую модель восстановления, а по окончании обратно? Или я неправильно понимаю? Цепочка бэкапов при этом не нарушится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 16:54 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
morohon Правильно ли я понимаю, что здесь идет речь о том, что при полной модели восстановления и выполнения процедуры реиндексации (как частный пример) будет резкий рост журнала транзакций и, чтобы этого избежать, рекомендуется на время выполнения этой операции необходимо переводить базу данных в простую модель восстановления, а по окончании обратно? Или я неправильно понимаю? Но выбирать модель нужно исходя из требований к восстановлению, а не для снижения нагрузки на лог. Если вам нужно иметь возможность восстановить данные на любой момент времени, то выбирайте FULL модель, если достаточно только на момент бакапа - то SIMPLE. И никак иначе, никаких "переключений на время перестроения". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 17:00 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
morohon Цепочка бэкапов при этом не нарушится? Плюс будут тратиться ресурсы DBA на поддержку этого нестандарта, не стоит оно того. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 17:02 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
alexeyvg, И снова спасибо за ответ. Вопрос касательно заполнения журнала транзакций при перестроении индексов не относился к тематике производительности различных моделей восстановления. Я просто часто в работе сталкиваюсь с базами MSSQL в полной модели восстановления и огромным журналом транзакций. И в большинстве своем это связано с тем, что после перестроения индексов журнал транзакций вырастает до немыслимых размеров. Может быть Вы в курсе как решать эту проблему правильно? У меня есть примеры, где файл базы данных весит 40-50 гб, а журнал транзакций весит от 250 гб. Хочется и использовать полную модель восстановления и иметь приемлемый размер журнала транзакций с учетом его постоянного резервного копирования (раз в полчаса/час/два). Сейчас в msdn нашел статью: https://docs.microsoft.com/ru-ru/sql/relational-databases/indexes/transaction-log-disk-space-for-index-operations?redirectedfrom=MSDN&view=sql-server-ver15 и там говорится о сортировке результатов в tempdb для уменьшения нагрузки на журнал транзакций - насколько сильно это помогает? Или тут только тесты? Может быть есть какие-то полезные статьи, чтобы понять как решаются такие проблемы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 17:05 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
morohon Правильно ли я понимаю, что здесь идет речь о том, что при полной модели восстановления и выполнения процедуры реиндексации (как частный пример) будет резкий рост журнала транзакций и, чтобы этого избежать, рекомендуется на время выполнения этой операции необходимо переводить базу данных в простую модель восстановления, а по окончании обратно? Или я неправильно понимаю? Цепочка бэкапов при этом не нарушится? конечно нарушится. чтобы не раздувать лог, переводят в bulk logged. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 17:08 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
Yasha123, И Вам спасибо за ответ. картинка складывается благодаря Вашим ответам, ответам alexeyvg и документации microsoft. Получается общая методика полной модели восстановления такая: Регулярно с некоторой периодичностью (раз в неделю, месяц, два (в зависимости от требований системы)) делаем полный бэкап базы данных. Постоянно делаем бэкап журнала транзакций (каждые полчаса, час, два), чтобы добиться его усечения. При массовых операциях (таких как перестроение индекса) необходимо перевести модель восстановления базы в полную модель с неполным протоколированием, выполнить операцию и вернуть полную модель восстановления. При таком подходе цепочка бэкапов не будет нарушена? Или я все же не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 17:16 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
morohon Я просто часто в работе сталкиваюсь с базами MSSQL в полной модели восстановления и огромным журналом транзакций. И в большинстве своем это связано с тем, что после перестроения индексов журнал транзакций вырастает до немыслимых размеров. Может быть Вы в курсе как решать эту проблему правильно? У меня есть примеры, где файл базы данных весит 40-50 гб, а журнал транзакций весит от 250 гб. Хочется и использовать полную модель восстановления и иметь приемлемый размер журнала транзакций с учетом его постоянного резервного копирования (раз в полчаса/час/два). Сейчас в msdn нашел статью: https://docs.microsoft.com/ru-ru/sql/relational-databases/indexes/transaction-log-disk-space-for-index-operations?redirectedfrom=MSDN&view=sql-server-ver15 и там говорится о сортировке результатов в tempdb для уменьшения нагрузки на журнал транзакций - насколько сильно это помогает? Про п. 3 как раз написал Yasha123 Ещё можно во время выполнения обслуживания запускать дополнительные бакапы лога. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 17:19 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
morohon При массовых операциях (таких как перестроение индекса) необходимо перевести модель восстановления базы в полную модель с неполным протоколированием, выполнить операцию и вернуть полную модель восстановления. При таком подходе цепочка бэкапов не будет нарушена? "Необходимо" - сильное слово. Можно перевести в такую модель, чтобы снизить размер лога транзакций, и соглашаясь с последствиями такого перевода. Последствие следующее: Цепочка не будет нарушена, но нельзя будет восстановиться на момент времени, который попадает в бэкап лога транзакций, содержащий минимально протоколируемую операцию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 17:29 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
Minamoto, Спасибо огромное! Я понимаю, что задаю глупые вопросы и все ответы есть в документации - извините! Все ответы помогли найти нужные ссылки в документации и понять механизм работы. Еще раз спасибо, будем пробовать и чаще обращаться к документации! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 17:34 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
morohon Получается общая методика полной модели восстановления такая: Регулярно с некоторой периодичностью (раз в неделю, месяц, два (в зависимости от требований системы)) делаем полный бэкап базы данных. Постоянно делаем бэкап журнала транзакций (каждые полчаса, час, два), чтобы добиться его усечения. И объём хранения таким образом увеличивается (представляете, сколько будет логов, еслри у вас только от одного обслуживания получилось 250 гигов на 50 гиг базу?) Нужно делать полный бакап раз в сутки, а бакапы логов чаще (час, полчаса) morohon чтобы добиться его усечения Главное для базы, и для DBA - что бы не пропали данные, даже в случае краха серверов!!! morohon При массовых операциях (таких как перестроение индекса) необходимо перевести модель восстановления базы в полную модель с неполным протоколированием, выполнить операцию и вернуть полную модель восстановления. При таком подходе цепочка бэкапов не будет нарушена? Вот ещё некоторые ссылки: Модели восстановления Резервное копирование с использованием модели восстановления с неполным протоколированием ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 17:36 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
Есть очень простое решение по переиндексации, не вызывающее большого прироста журнала - выполнять растянуто по времени, не в один приём, а в течение недели, скажем. И лучше не заменять перерасчет статистик переиндексацией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 18:23 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов Есть очень простое решение по переиндексации, не вызывающее большого прироста журнала - выполнять растянуто по времени, не в один приём, а в течение недели, скажем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 20:28 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
alexeyvg Да, общее желание выполнить переиндексацию "всего" за один раз вызвано, видимо, инерцией мышления. Насколько помню всегда рекомендовалось выполнять переиндексацию в период минимальной нагрузки на систему, а это, как правило, ночные часы в конце недели. "Размазывать" переиндексацию на неделю наверное можно, но может сложится ситуация, при которой индексам таблиц, перестроенных в понедельник, к субботе снова потребуется переиндексация, при том что останутся таблицы, до которых очередь еще не дошла. По поводу раздутых логов - если после первой переиндексации размер лога стал, скажем 100 ГБ, в течении недели не изменился, после второй переиндексации все еще 100 ГБ - то, видимо, это размер, необходимый для нормального функционирования базы. Все, что надо сделать - позаботиться, что бы на диске было достаточно свободного места для размещения лога такого размера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2019, 23:50 |
|
||
|
Разница в нагрузке в зависимости от модели восстановления
|
|||
|---|---|---|---|
|
#18+
flexgen может сложится ситуация, при которой индексам таблиц, перестроенных в понедельник, к субботе снова потребуется переиндексация, при том что останутся таблицы, до которых очередь еще не дошла. Тут нужно правильно выбирать период, ИМХО именно он важен, а не день недели. Вот правильное время минимальной нагрузки действительно может быть возможно выбрать только на определённый день недели, тут уж ничего не поделаешь... flexgen По поводу раздутых логов - если после первой переиндексации размер лога стал, скажем 100 ГБ, в течении недели не изменился, после второй переиндексации все еще 100 ГБ - то, видимо, это размер, необходимый для нормального функционирования базы. Все, что надо сделать - позаботиться, что бы на диске было достаточно свободного места для размещения лога такого размера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2019, 00:48 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39885882&tid=1686999]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
53ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 413ms |

| 0 / 0 |
