Выполнение операций обновления данных при резервном копировании большой базы данных SQL Server

9

У меня есть большая (из десятков миллионов записей) база данных, для которой я собираюсь выполнить полное резервное копирование базы данных .

Однако база данных достаточно велика, чтобы транзакции могли начинаться до и во время, а также фиксироваться во время и после выполнения резервного копирования.

Например:

T0 = Transaction A start
T1 = Full database backup start
T2 = Transaction B start (will not deadlock with A)
T3 = Transaction A commit/rollback (does not matter, does it?)
T4 = Full database backup end
T5 = Transaction B commit/rollback (again, does not matter, does it?)

T0          T1          T2          T3          T4          T6
||----------||----------||----------||----------||----------||---------->

Насколько я понимаю, во время резервного копирования блокировки не используются (хотя могут возникнуть другие проблемы с производительностью, скажем, из-за высокого ввода-вывода) , но я не уверен, что я могу гарантировать, что будет зафиксировано или нет.

Кроме того, меня беспокоит не то, что база данных будет в несовместимом состоянии, а скорее, каким будет это состояние (даже если оно не является детерминированным, если есть набор правил, которые можно последовательно применять) и как оно туда попало ( например, какая часть файла данных используется вместе с журналом транзакций для создания файла резервной копии)?

— casperOne
источник

Я удалил свой первый комментарий и расширил его до ответа. Я все еще пытаюсь выяснить, как найти точную дату окончания чтения данных из резервной копии.

— Саймон Ригартс

7

По сути, резервная копия будет в состоянии базы данных, когда она завершит часть резервного копирования для чтения данных (поэтому все данные будут сохранены), плюс любой объем журнала транзакций, необходимый для обеспечения согласованности транзакций (начало время включенного журнала есть MIN(most recent checkpoint time, oldest active transaction start time)). Пол Рэндал освещает это здесь (с помощью диаграммы, которая делает все это намного проще). В вашем примере Aбудет зафиксировано (или откатано, если ROLLBACK TRANSACTIONвместо a было выдано a COMMIT) и Bвыполнено откат (независимо от конечного результата этой транзакции).

(Другая причина, по которой вы пытаетесь выполнять резервное копирование в спокойное время, кроме конфликта ввода-вывода, заключается в том, что весь журнал транзакций, созданный во время резервного копирования, обычно должен быть включен в резервную копию.)

Этап восстановления базы данных восстанавливает все зафиксированные транзакции из журнала, включенного в резервную копию, применяет их к базе данных и откатывает все незафиксированные транзакции. (Вот почему WITH RECOVERY/ WITH NORECOVERYважно. WITH RECOVERYИ вы можете использовать базу данных, но вы не можете применять дополнительные резервные копии журналов, вам нужно восстановить ееWITH NORECOVERY чтобы выполнить резервное копирование журналов. Восстановление разрывает цепочку журналов, откатывая незафиксированные транзакции. )

Дальнейшее чтение:

— Саймон Ригартс
источник

4

Полная резервная копия будет восстановлена к моменту времени, когда будет завершена часть чтения резервной копии данных, за исключением любых незавершенных транзакций в это время.

Как вы упомянули, база данных остается в сети и доступна для записи во время резервного копирования. Как это работает, система резервного копирования выполняет резервное копирование несогласованного набора страниц данных (поскольку для чтения данных требуется ненулевое количество времени) - она берет копию каждой страницы данных по мере ее поступления, в каком бы состоянии она ни находилась в. Полное резервное копирование также включает в себя записи журнала транзакций, начиная с начала самой старой активной транзакции в начале резервного копирования, до последней записи журнала, когда часть чтения данных завершается.

Когда резервная копия восстановлена, данные и журнал восстанавливаются как есть (помните, что страницы данных находятся в несогласованном состоянии), тогда процесс повторного выполнения происходит с начала резервного копирования журнала транзакций (опять же, внутри полной резервной копии) до самого конца; Затем, если вы восстановили с RECOVERY, откат происходит откат незавершенных транзакций во время резервного копирования завершено. Операция отмены - это то, что оставляет базу данных в транзакционно-согласованном состоянии, готовой к использованию. Восстановление с NORECOVERYпропусками отмены процесса , позволяя вам восстановить дополнительные резервные копии (разностный или журнал транзакций).

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

— Джон Сайгель
источник