... по крайней мере, я так думаю.
Недавно я обновил процедуру резервного копирования на своем сервере разработки. Я создал план обслуживания для пользовательских баз данных, который выполнял несколько задач еженедельной очистки, ежедневное полное резервное копирование и резервное копирование журнала транзакций в ключевые моменты в течение дня.
Все работало хорошо до сегодняшнего дня, когда я получил электронное письмо с уведомлением о сбое резервного копирования в обеденное время. Средство просмотра журналов не показало ничего, кроме того, что определенное количество БД было успешно скопировано, прежде чем завершить запись журнала с помощью:
[snipped] Source: ... The package execution fa... The step failed.
Не совсем показательно
Мне пришло в голову, что единственным изменением предыдущих попыток было то, что я сегодня утром создал новую (маленькую и ничем не примечательную) базу данных.
Я перезапустил агент SQL Server и попытался вручную повторно запустить шаг (резервное копирование журнала транзакций), но это снова не удалось.
Однако запуск шага полного резервного копирования (таким образом, создавая первую полную резервную копию для моей новой БД) работал - кроме того, повторный запуск шага резервного копирования журнала транзакций снова также работал.
Похоже, что резервное копирование журнала транзакций затруднялось из-за отсутствия полной резервной копии или предыдущей резервной копии журнала транзакций.
Это ожидаемое поведение? С одной стороны, на примитивном уровне это имеет смысл, но на самом деле я ожидал, что он справится с таким сценарием более изящно.
Если да, есть ли способ автоматически справиться с этим? Это случится не так часто, но я не могу не забывать о резервном копировании БД при ее создании, тем более, что это только на ранних стадиях разработки.
Если нет, то какова вероятная причина такого поведения? Могу ли я этого избежать?
Да, это ожидаемое поведение. Чтобы журналы транзакций были полезными, необходима полная резервная копия, которую можно использовать в качестве отправной точки для отката.
Не беспокойтесь об этом слишком сильно. Если вы создадите новую базу данных, в первый же день вы получите эту ошибку. Резервное копирование журналов для других БД, как вы видели, будет успешным, но эта ошибка просто заставит его ВЫГЛЯДИТЬ, как если бы шаг не удался, когда на самом деле только одна БД не удалось. Затем той же ночью (или когда-нибудь) он сделает полную резервную копию. После этого резервные копии журналов транзакций будут успешными для новой БД. По сути, у вас будет один день или ошибки при создании новой БД до выполнения задания полного резервного копирования.
Я поставил флажок в моем списке DBS для резервного копирования, который указывает на то, что резервное копирование выполнено. Сценарий резервного копирования не будет выполнять резервное копирование Txn, пока оно не станет равным 1. В моем сценарии полного резервного копирования я установил флаг в 1. Presto, никаких сбоев.