Собираюсь ли я потерять данные, если беру резервную копию журнала транзакций и усекаю файл журнала?

Question

У меня есть база данных с файлом LDF около 14 ГБ и файлом MDF 12 ГБ.

Никто никогда не выполнял резервное копирование журнала транзакций для этой БД.

Хотя команда всегдапросто выполняйте полное резервное копирование БД каждое утро.

В результате размер файла журнала просто растет и растет.

Теперь, если я возьму его резервную копию журнала транзакций и урезать журналфайл.

Собираюсь ли я потерять какие-либо данные?

Мне любопытно, потому что резервное копирование журнала уменьшает размер файла журнала, я просто хочу убедиться, что они не повлияют на мойMDF-файл или данные, которые мы имеем в БД.

А после создания резервной копии t-log какая стратегия хороша?

Должны ли мы восстановить ее, чтобы проверить, работает ли она нормально?

Если я восстановлю резервную копию t-log,обязательно ли сначала применять полное резервное копирование восстановление на этом сервере тестирования?

[SQL Server 2012]

Answer 1

Короткий ответ: «Вы не потеряете больше, чем обычно». Однако есть несколько обстоятельств, которые могут повлиять на ваше окончательное решение.

Первый вопрос, который ваша команда должна задать себе: «Если мы никогда не делаем резервные копии журналов, почему база данных находится в режиме полного восстановления»? Для баз данных DEV резервное копирование журналов в большинстве случаев не требуется, поэтому переключите его на SIMPLE recovery, введите checkpoint, а затем вы можете обрезать журнал. О, и после этого он не должен сильно расти, если только кто-то не запустит большой пакет изменений за одну транзакцию.

Просто убедитесь, что вы понимаете разницу между режимами усечения. Скорее всего, вам нужно будет использовать как NOTRUNCATE, так и TRUNCATEONLY.

Необходимость регулярного создания резервных копий журналов зависит от вашего рабочего процесса и важности данных. Основные преимущества режима полного восстановления:

1. В случае аварии, вы не потеряете изменения, сделанные после последнего резервного копирования full / diff, только после последнего резервного копирования журнала транзакций (которые обычно короткие, если выполняются регулярно, и, как таковые, создают меньшую нагрузку на сервер) , Однако, если ваш файл журнала транзакций пережил сбой, и вы смогли выполнить резервное копирование хвостового журнала после того, как база данных стала непригодной для использования, вы потеряете Ничего .
2. Вы можете выполнить восстановление базы данных на определенный момент времени, что иногда является критически важной возможностью, например, когда вы расследуете повреждение / потерю данных или любое другое расследование такого рода. Однако, как я уже сказал, базы данных разработки редко бывают такими ценными.

Так что взвесьте эти варианты, примите во внимание ваши особенности, и ответ придет. Если этого не произойдет, я рекомендую обратить ваше внимание на dba.stackexchange.com, так как вопрос в его нынешнем виде на самом деле не о разработке.

Answer 2

ваша модель восстановления базы данных full, что означает sql не перезаписывать на ldf страницы данных, пока вы не создадите резервную копию журнала, а затем перезаписать их, после чего ваш журнал не станет больше, если у вас нетогромная транзакция, поэтому вы можете объявить некоторые задания резервного копирования журналов или изменить модель восстановления на простые, и, конечно, модель полного восстановления лучше, но помните, что вы должны хранить каждую отдельную резервную копию журнала, которую вы делаете после последнего полного резервного копирования