Не вдається відновити (помилка 3456)

У мене є ситуація, яку нелегко розібратися, і я подумав, що на цьому форумі я б запитав, чи можуть інші запропонувати пропозиції.

Я запускаю SQL Server 2008 R2 Standard SP3 у Windows Server 2008R2 Enterprise.

Базі даних потрібне було певне обслуговування, і після цього мені потрібно було відновити на іншому сервері. У мене є повноцінне резервне копіювання db, виконане за допомогою COPY_ONLY плюс набір із 4-х резервних копій.

перед запуском створіть tlogbackup1
перехід від FULLдо BULK_LOGGEDмоделі відновлення
додати нову групу файлів
додати файл у новуфайлгрупу
встановити новугрупу за замовчуванням
виберіть у таблицю (у новійфайлгрупі)
падіння оригінальний стіл
видалити вихідний файл
видалити оригінальну файлову групу
змінити назву нової таблиці, щоб вона відповідала оригінальній таблиці
змінити ім'я файлу newfilegroup відповідно до оригінальної файлової групи
змінити ім'я файлу в каталозі, щоб воно відповідало іменному файлу
змінити ім’я файлу на рівні ОС, щоб відповідати оригінальному імені файлу
встановити групу файлів за замовчуванням як оригінал
принести db в Інтернеті
перехід від BULK_LOGGEDдо FULLмоделі відновлення
Після завершення всіх кроків створіть tlogbackup2

Відновлення всіх резервних копій повинно використовуватись З 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.

Msg 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 LOG RESTORE закінчується аномально.

Просто щоб переконатися, що резервна копія повного db була в порядку, я відновив її запуск CHECKDB, і помилок не було.

Всі відгуки вітали.

Спасибі заздалегідь,

Нед Оттер

— NedOtter
джерело

Не могли б ви пояснити, чому ви думаєте, що у вас є нерозривний ланцюг журналів? Щойно ви перевели базу даних у режим BULK_LOGGED і почали возитися зі схемою, усі ставки на те, що ланцюг журналу не розірваний, виключаються.

— Томас Кейсер

Дякую за вашу відповідь, Томасе. Зараз я бачу, що назва моєї посади була неправильною. Мені не потрібне відновлення часу, але повне відновлення до кінця 4-го резервного резервного копіювання. Тож встановлення BULK_LOGGED не повинно викликати жодних проблем із цим. Я не бачу, як те, що я зробив, призвів до виходу з ладу резервного копіювання 2-го tlog - всі команди підтримувались SQL Server, і я виконував такі ж кроки (хоча і не на тих же даних) на меншій базі даних, і міг відновити резервну копію 2-го tlog без проблем.

— NedOtter

Помилка виглядає як корупція. Це внутрішня помилка. Чи можете ви перевірити цілісність усіх файлів резервної копії? Вони з контрольними сумами?

— usr

Я перевірив, що в повному резервному режимі DB було 0 помилок, запустивши CHECKDB. Мені доведеться перевірити, чи використовувався CHECKSUM.

— NedOtter

Якщо для резервного копіювання включена контрольна сума, то для відновлення вам слід використовувати контрольну суму. Тип сторінки 11 - це сторінка PFS, що означає, що ви не можете її виправити, ви можете виконати лише повне відновлення. Крім того, ви не говорите, коли було зроблено резервну копію лише для копіювання. Де була ця резервна копія у часовій лінії?

— Роберт Л Девіс

Щоб зрозуміти, чому буде видалена помилка 3456, нам потрібно зробити трохи крок назад і зрозуміти, як SQL Server обробляє цей куточок відновлення.

Коли SQL Server повторює операцію, і це повтор є модифікацією сторінки, вона робить швидку перевірку. У заголовку сторінки в кінцевому підсумку буде a 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 LOG RESTORE закінчується аномально.

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

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

— Томас Стрінгер
джерело

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

— RThomas