Опубликуйте полную резервную копию, как система узнает, какие транзакции следует восстановить из резервной копии журнала транзакций?

Полное резервное копирование не усекает файл журнала транзакций.

Предполагая фол. сценарий:

  1. Полная резервная копия в 6 утра
  2. Бэкап TLog в 10:00
  3. Полное резервное копирование в 13:00
  4. Бэкап TLog в 18:00
  5. Немедленный сбой в следующую секунду (поэтому резервная копия хвостового журнала не требуется)

Шаги по восстановлению:

  1. Восстановить полную резервную копию с точки 3 (содержит данные на 13:00)
  2. Затем восстановите резервную копию tlog с шага 4 (содержит журнал с 10:00 до 18:00).

Вопрос: как во время восстановления система узнает, что в базе данных необходимо воспроизвести только определенную часть файла журнала (после 13:00 [исключить с 10:00 до 13:00])? Проверяет ли он временные метки в резервной копии журнала транзакций, чтобы сравнить ее с полной резервной копией? Или он проверяет LSN?

Точно так же в другом сценарии, скажем, мы делаем полную резервную копию в 10:00, а затем делаем резервную копию журнала транзакций в 12:00. В журнале транзакций будут все транзакции до 12:00 (и даже до 10:00, если предположить, что db существовал до 10:00 и не было предыдущей резервной копии журнала транзакций). Теперь, когда мы восстанавливаем полную резервную копию, а затем применяем резервную копию журнала транзакций, как система узнает, что нужно воспроизвести только транзакции в журнале после 10:00? Поскольку все те, что были до 10 утра, уже будут там как часть полного восстановления резервной копии. Проверяется ли это с помощью временных меток или LSN?


sql-server database-backups database-restore transaction-log
person variable    schedule 01.10.2018    source источник
comment
я не могу это удалить   -  person variable    schedule 18.10.2018
comment
Тогда почему этот вопрос помечен как Этот вопрос не относится к программированию в рамках, определенных в справочном центре. В чем смысл, почему вы не разрешаете удалять это, когда оно бесполезно? Как вы думаете, что здесь полезного?   -  person variable    schedule 31.10.2018

Ответы (2)


arrow_upward
1
arrow_downward

Зависит от причины АВАРИЙНОГО СБОЯ на шаге 5. Если еще возможно сделать резервную копию журнала транзакций, то, скорее всего, он сможет восстановиться до 18:01. Если сбой серьезный, вероятно, будет потеряна 1 минута транзакций между 18:00 и 18:01.

При резервном копировании журнала в 18:00 вы всегда можете восстановиться до 18:00 (или в любой момент между 13:00 и 18:00 с параметрами восстановления STOPAT или STOPATMARK).

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

person Dave Brown    schedule 01.10.2018
comment
Привет, вопрос был следующим: Вопрос: Как во время восстановления система узнает, что только определенная часть файла журнала (после 13:00 [исключить с 10:00 до 13:00]) должна быть воспроизведена в базе данных? Проверяет ли он временные метки в резервной копии журнала транзакций, чтобы сравнить ее с полной резервной копией? - person variable; 01.10.2018

arrow_upward
0
arrow_downward

В вашем примере 2 резервных копии журнала являются отдельными резервными копиями
Каждая резервная копия содержит только действия из последней полной резервной копии, поэтому предыдущая резервная копия журнала не имеет значения из-за полной резервной копии в 13:00.

Как правило... система использовала номера LSN или порядковые номера журналов.

Система считывает начальный и конечный номера LSN из файлов резервных копий и сопоставляет их с номером LSN базы данных. Если они совпадают, используется файл резервной копии. В противном случае вы получите ошибку.

Изменить: Не на основе метки времени

person gbn    schedule 01.10.2018
comment
Итак, это основано не на метке времени, а на LSN. Пожалуйста, вы можете это подтвердить? - person variable; 01.10.2018
comment
stackoverflow.com/questions/1143119 / или rusanu.com /2012/01/17/what-is-an-lsn-log-sequence-number или docs.microsoft.com/en-us/sql/relational -базы данных/ - person gbn; 01.10.2018
comment
Значит, это не основано на метке времени? - person variable; 01.10.2018