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