Невозможно восстановить (ошибка 3456)

9

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

Я использую SQL Server 2008 R2 Standard SP3 на Windows Server 2008R2 Enterprise.

База данных нуждалась в некотором обслуживании, и после этого мне нужно было восстановить ее на другом сервере. У меня есть полное резервное копирование базы данных с COPY_ONLY плюс набор из 4 резервных копий tlog.

  1. перед запуском создайте tlogbackup1
  2. переход от FULLк BULK_LOGGEDмодели восстановления
  3. добавить новую файловую группу
  4. добавить файл в newfilegroup
  5. установить новую группу по умолчанию
  6. выбрать в таблицу (на newfilegroup)
  7. сбросить оригинальный стол
  8. удалить оригинальный файл
  9. удалить оригинальную файловую группу
  10. изменить имя новой таблицы в соответствии с исходной таблицей
  11. изменить имя файла newfilegroup в соответствии с исходной файловой группой
  12. изменить имя файла в каталоге, чтобы оно соответствовало оригинальному имени файла
  13. изменить имя файла на уровне ОС, чтобы оно соответствовало оригинальному имени файла
  14. установить файловую группу по умолчанию как оригинал
  15. принести дб онлайн
  16. переход от BULK_LOGGEDк FULLмодели восстановления
  17. После завершения всех шагов создайте tlogbackup2

Для восстановления всех резервных копий необходимо использовать WITH MOVE из-за изменения буквы диска на сервере восстановления.

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

RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup1.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup2.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

Окончательное восстановление журнала Tlog достигает 100%, а затем завершается с ошибкой 3456:

Обработано 368 страниц для базы данных «SomeDB», файл «SystemData» для файла 1.

Обработано 7656520 страниц для базы данных «SomeDB», файл «SystemDataPDS» для файла 1.

Обработано 172430 страниц для базы данных «SomeDB», файл «SystemData_log» для файла 1.

Сообщение 3456, уровень 16, состояние 1, строка 1
Не удалось повторить запись журнала (210388: 123648: 232), для идентификатора транзакции (0: 1016710921), на странице (4: 8088), база данных «SomeDB» (идентификатор базы данных 6) , Страница: LSN = (0: 0: 1), тип = 11. Журнал: OpCode = 4, контекст 11, PrevPageLSN: (210388: 122007: 1). Восстановление из резервной копии базы данных или восстановление базы данных. Сообщение 3013, уровень 16, состояние 1, строка 1 RESTORE LOG завершается ненормально.

Просто чтобы убедиться, что с полной резервной копией БД все в порядке, я восстановил ее CHECKDB, и ошибок не было.

Все отзывы приветствуются.

Заранее спасибо,

Нед Оттер

sql-server  sql-server-2008-r2  recovery  restore 
— NedOtter
источник
1
Не могли бы вы уточнить, почему вы думаете, что у вас есть непрерывная цепочка бревен? В тот момент, когда вы перевернули базу данных в режим BULK_LOGGED и начали возиться со схемой, все ставки на неразрывную цепочку журналов отключены.
— Томас Кейсер
Спасибо за ваш ответ, Томас. Теперь я вижу, что заголовок моего поста был неверным. Мне не нужно время восстановления, но полное восстановление до конца 4-й резервной копии журнала. Поэтому установка BULK_LOGGED не должна была вызывать каких-либо проблем с этим. Я не понимаю, как то, что я сделал, привело к сбою 2-го резервного копирования tlog - все команды были поддержаны SQL Server, и я выполнил те же самые шаги (хотя и не с теми же данными) в меньшей базе данных и смог восстановить 2-й бэкап тлог без проблем.
— НедОттер
Ошибка выглядит как коррупция. Это внутренняя ошибка. Можете ли вы проверить целостность всех файлов резервных копий? Они с контрольными суммами?
— USR
Я проверил, что полное резервное копирование БД было 0 ошибок, запустив CHECKDB. Я должен проверить, использовался ли CHECKSUM.
— НедОттер
1
Если для резервных копий включена контрольная сумма, то для восстановления также следует использовать контрольную сумму. Тип страницы 11 - это страница PFS, а это значит, что вы не можете это исправить, вы можете сделать только полное восстановление. Кроме того, вы не говорите, когда была сделана только резервная копия. Где была эта резервная копия на временной шкале?
— Роберт Л Дэвис,

Ответы:

9

Чтобы понять, почему возникает ошибка 3456, нам нужно сделать небольшой шаг назад и понять, как SQL Server справляется с этим углом восстановления.

Когда SQL Server повторяет операцию, и это повторение является модификацией страницы, выполняется быстрая проверка. В конечном итоге в заголовке страницы будет находиться знак PageLSN, который указывает на последний номер LSN, который изменил эту страницу, записанный этой страницей. Подумайте об этом так, страница отслеживает последний номер LSN, который внес в него изменения. Это PageLSN.

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

Подумайте об этом так ... Ваша машина должна поработать над этим. Механик Джон работает на вашем автомобиле, а в моторном отсеке есть небольшая метка, а механик Джон пишет: «Джон работал над этим автомобилем последним». Затем в следующий раз, когда вы отвезете свою машину в другой магазин, Механик Марк заглядывает в моторный отсек и видит, что Механик Джон работал над этой машиной в последний раз. В своем паспорте он пишет эту информацию. Та же идея с SQL Server.

Это может быть несколько запутанным, поэтому посмотрите на это изображение , ниже на последовательных изменений страниц, и как PageLSNи PrevPageLSNсвязаны:

введите описание изображения здесь

Давайте вернемся назад, так как все это вступает в игру, когда вам нужно повторить операцию на странице (восстановление, восстановление, HA и т. Д.). Когда SQL Server необходимо повторить операцию страницы, он проверяет работоспособность, чтобы увидеть, соответствует ли PageLSNна странице то, PrevPageLSNчто включает в себя запись журнала. Если это не равно, то вы увидите ошибку 3456.

Имеют ли PageLSN равна PrevPageLSN ? Нет ??? Остановить и поднять ошибку 3456 ...

Давайте проанализируем ваше сообщение об ошибке, которое включает в себя как:

Не удалось повторить запись журнала (210388: 123648: 232) для идентификатора транзакции (0: 1016710921) на странице (4: 8088), база данных «SomeDB» (идентификатор базы данных 6). Страница: LSN = (0: 0: 1) , тип = 11. Журнал: OpCode = 4, контекст 11, PrevPageLSN: (210388: 122007: 1) . Восстановление из резервной копии базы данных или восстановление базы данных. Сообщение 3013, уровень 16, состояние 1, строка 1 RESTORE LOG завершается ненормально.

Я выделил две части данных, которые имеют неравенство, вызывающее ошибку. Вы можете видеть, что наше значение PageLSNравно 0: 0: 1 (это было найдено в заголовке страницы), а наше значение PrevPageLSNравно 210388: 122007: 1 (это было найдено в данных в записи журнала, которая пыталась выполнить повтор). Они явно не равны, следовательно, err3456.

Таким образом, чтобы выяснить причину этого события, было бы выяснить, почему здесь существует несоответствие. Нам действительно нужно проследить жизненный цикл страницы 4: 8088 и увидеть, где происходит отключение. К сожалению, без дополнительной информации или практического устранения неполадок, я ничего не могу поделать, кроме как дать вам представление об этой операции восстановления и причинах ошибки.

— Томас Стрингер
источник
Я знаю, что это было некоторое время, но все же ... хорошие вещи, спасибо за подробное объяснение!
— RThomas
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.