Меня назначили поддерживать SQL Server с доставкой журналов на нем. Раз в неделю индексы перестраиваются, а затем создается резервная копия. На прошлой неделе план обслуживания, который восстанавливает индексы, не сработал правильно, поэтому резервное копирование не было выполнено. Следующий журнал транзакций был в 4 раза больше, чем была бы резервная копия, заполнил все оставшееся пространство на сервере и отбросил весь наш журнал на один день.
Более подробно изучив журналы транзакций (я разработчик, а не администратор базы данных), я обнаружил, что ошибался, полагая, что резервное копирование остановило огромный размер журнала транзакций после перестроения индекса. Оказалось, что это был сценарий SQL в конце плана обслуживания, который упрощает режим восстановления базы данных, сжимает его, а затем изменяет обратно на полный.
Правильно ли я предполагаю, что это разрывает цепочку журналов транзакций и вызывает первую полную резервную копию, после чего журналы транзакций запускаются из самого себя - и что любое резервное копирование базы данных в течение недели (мы делаем резервное копирование каждое утро) можно игнорировать в пользу простого применения транзакции вместо этого ведет журнал этой еженедельной резервной копии?
Вы правы, изменение уровня ведения журнала на простой и обратно делает недействительной цепочку журналов, требующую создания полной резервной копии.
Вы должны удалить этот переключатель и команду сжатия файла журнала. Просто сделайте резервную копию журнала и внесите изменения в журнал на целевой сервер доставки журналов.
Каждый раз, когда вы меняете модель восстановления базы данных с полной на простую и обратно, операция доставки журналов должна начинаться заново, восстанавливая полную резервную копию. Если вы не измените модель восстановления, вам никогда не потребуется восстанавливать полную резервную копию на целевой сервер после первого раза.