У меня есть ситуация, которую нелегко выяснить, и я подумал, что я хотел бы спросить на этом форуме, если у других могут быть предложения.
Я использую SQL Server 2008 R2 Standard SP3 на Windows Server 2008R2 Enterprise.
База данных нуждалась в некотором обслуживании, и после этого мне нужно было восстановить ее на другом сервере. У меня есть полное резервное копирование базы данных с COPY_ONLY плюс набор из 4 резервных копий tlog.
- перед запуском создайте tlogbackup1
- переход от
FULLкBULK_LOGGEDмодели восстановления - добавить новую файловую группу
- добавить файл в newfilegroup
- установить новую группу по умолчанию
- выбрать в таблицу (на newfilegroup)
- сбросить оригинальный стол
- удалить оригинальный файл
- удалить оригинальную файловую группу
- изменить имя новой таблицы в соответствии с исходной таблицей
- изменить имя файла newfilegroup в соответствии с исходной файловой группой
- изменить имя файла в каталоге, чтобы оно соответствовало оригинальному имени файла
- изменить имя файла на уровне ОС, чтобы оно соответствовало оригинальному имени файла
- установить файловую группу по умолчанию как оригинал
- принести дб онлайн
- переход от
BULK_LOGGEDкFULLмодели восстановления - После завершения всех шагов создайте 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, и ошибок не было.
Все отзывы приветствуются.
Заранее спасибо,
Нед Оттер
источник
Ответы:
Чтобы понять, почему возникает ошибка 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 ...
Давайте проанализируем ваше сообщение об ошибке, которое включает в себя как:
Я выделил две части данных, которые имеют неравенство, вызывающее ошибку. Вы можете видеть, что наше значение
PageLSNравно 0: 0: 1 (это было найдено в заголовке страницы), а наше значениеPrevPageLSNравно 210388: 122007: 1 (это было найдено в данных в записи журнала, которая пыталась выполнить повтор). Они явно не равны, следовательно, err3456.Таким образом, чтобы выяснить причину этого события, было бы выяснить, почему здесь существует несоответствие. Нам действительно нужно проследить жизненный цикл страницы 4: 8088 и увидеть, где происходит отключение. К сожалению, без дополнительной информации или практического устранения неполадок, я ничего не могу поделать, кроме как дать вам представление об этой операции восстановления и причинах ошибки.
источник