MSSQL Уменьшить размер журнала резервного копирования / транзакции, сохраняя восстановление на момент времени
В настоящее время основная проблема с размерами резервных копий - у меня много вопросов, но я нахожу конфликтующие сценарии. У меня есть несколько баз данных с одной и той же проблемой, но на примере одной из них представлены компоненты файла резервной копии (26,2 ГБ):
- Данные 5 ГБ
- Индексы 1.2ГБ
- Журнал транзакций 20 ГБ
Я делаю резервное копирование журнала транзакций каждые 6 часов, это 1 база данных из 6, которая управляет веб-приложением достаточно большого объема. Каждое воскресенье мы перестраиваем индексы, кажется, что каждый раз, когда это происходит, журнал транзакций увеличивается еще на 5%. Кроме того, резервная копия журнала транзакций совсем не уменьшает его размер.
Системе нужна возможность восстановления между резервными копиями на определенный момент времени, более того, кажется, что перестройка индексов приводит к увеличению размера журнала транзакций, я не вижу большого преимущества в резервном копировании или хранении индексов. журнал транзакций, учитывая, что они могут быть построены на восстановление. Можно ли это обойти?
В конечном счете, я ищу очень низкий размер резервной копии журнала транзакций для оперативного использования, который просто облегчает восстановление во время резервного копирования. Я не думаю, что хочу иметь индексы в моем журнале транзакций, и я не беспокоюсь о том, что они находятся в моих файлах резервных копий - это наивно? Кроме того, я хотел бы знать, как лучше управлять размером этого журнала транзакций - следует ли мне чаще делать его резервные копии, есть ли причина, по которой он не уменьшается в размере?
Возможно, я здесь упускаю смысл или ищу утопию, но сейчас я остро нуждаюсь в помощи с этой стратегией!
РЕДАКТИРОВАТЬ: Не уверен, если это имеет какое-либо значение, но зеркальное отображение базы данных активно, все резервные копии и т. Д. Выполняются на основной.
1 ответ
У вас нет такого детального контроля над тем, что входит в журнал транзакций. Вы можете переключаться между режимами FULL и BULKINSERT. Но есть риск, это дополнительная вещь, которой вы должны будете управлять, и я бы этого не делал.
Резервное копирование журнала транзакций не уменьшит размер журнала транзакций. Вы можете вручную сжать журнал транзакций. Повторные циклы роста / сжатия имеют тенденцию фрагментировать файлы, что не рекомендуется из-за негативного влияния на производительность.
Если вы хотите контролировать размер резервных копий журнала, я бы посоветовал вам:
Резервные копии журналов выполняйте чаще, чем раз в шесть часов. Это даст вам больше файлов, но они должны быть в среднем меньше. В большинстве систем, которые я запускаю в полном режиме, резервные копии журналов выполняются каждые несколько минут. Если у вас есть автоматизированные способы обработки резервных копий tlog, увеличение количества файлов не должно быть большой проблемой. Обратите внимание, что для задания агента SQL можно настроить более одного расписания. Например, вы можете указать одну резервную копию tlog на шесть часов, когда дела идут медленно, и раз в десять минут, когда дела заняты.
Посмотрите на сжатие ваших файлов резервных копий. Некоторые последние версии SQL Server имеют встроенную функцию сжатия файлов резервных копий, и вы всегда можете воспользоваться сторонним продуктом, таким как SQL Lightspeed.