Онлайн восстановление страницы достигло предела 1000


13

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

Мне дали старую (~ 3 недели) полную резервную копию и серию журналов транзакций ... однако отсутствуют журналы транзакций, поэтому я могу восстановить только до определенной даты. Примерно 2,5 недели данных отсутствуют (и в эту базу данных постоянно добавляется много данных).

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

Я попробовал типичные DBCC CHECKDBкоманды (до сих пор нет repair_allow_data_loss, это будет моим последним средством, если ничего не работает).

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

Чтобы сделать это, я создал скрипт, который создает множество RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'команд из DBCC CHECKDBвывода (в основном, регулярное выражение и отличное) ... пока все хорошо, это работало до такой степени, что он сказал, что достиг предела в 1000 страниц за файл (в этой базе данных 8 файлов) за команду восстановления.

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

Я пробовал, RESTORE DATABASE <foo> WITH RECOVERYно это тоже не сработало, оно запрашивает у меня журнал, которого у меня нет.

У кого-нибудь есть какие-нибудь советы о том, как я могу попытаться восстановить что-нибудь отсюда? Или как «завершить» онлайн-восстановление, чтобы я мог продолжать пытаться восстановить больше страниц? Будет ли у меня такая же проблема, если я попробую автономное восстановление (в основном добавление WITH NORECOVERYко всему, а затем попытаться вернуть его в конце?)

Обработка базы данных вручную, в основном, невозможна ... существуют сотни таблиц с миллионами строк, и нет никакого ясного смысла в том, что из этого есть. Поврежденная БД потерпит неудачу при SELECTзапросах после нескольких миллионов строк, но я не уверен, что смогу где-нибудь разобраться. Я попытался перестроить все некластеризованные индексы, но есть поврежденные страницы с данными строк, так что это тоже не сработало.

Некоторая потеря данных была бы приемлемой, но согласованность БД должна, по крайней мере, быть достигнута.

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

Это SQL Server 2014 Enterprise

PS: я не администратор баз данных ... Я программист, но клиент попробовал некоторые "экспертные" службы аварийного восстановления sql, и они отказались, поэтому меня попросили взглянуть на это и посмотреть, смогу ли я Делать что-нибудь.


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

Ответы:


16

Стандартная процедура будет:

  1. Получите идентификаторы страниц, которые необходимо восстановить.
  2. Начните восстановление страницы с полной базы данных.
  3. Примените самую последнюю разностную резервную копию.
  4. Примените последующие резервные копии журнала.
  5. Создать новую резервную копию журнала.
  6. Восстановите новую резервную копию лоба.

После применения новой резервной копии журнала восстановление страницы завершается, и страницы можно использовать.

Пример восстановления

RESTORE DATABASE <database> PAGE='1:57, 1:202, 1:916, 1:1016'  
   FROM <file_backup_of_file_B>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;   
BACKUP LOG <database> TO <new_log_backup>;   
RESTORE LOG <database> FROM <new_log_backup> WITH RECOVERY;  
GO  

Ссылка: страницы восстановления (SQL Server) (документы Microsoft) Ссылка: инструкции RESTORE (Transact-SQL) (документы Microsoft)

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


Вы находитесь в сложной ситуации.

  1. В вашей базе данных есть поврежденные страницы, и ваша компания постоянно добавляет новые данные в базу данных с проблемами. Это может привести к полному времени простоя базы данных. У вас хотите рисковать?

  2. Кто-то будет нести ответственность, и чем больше вы пытаетесь это исправить, тем больше руководство может решить, что в конечном итоге вы будете именно этим человеком. У вас хотите рисковать?

  3. Вы ставите себя в сложное положение, принимая на себя роль, на которую не работали. Вы пытаетесь достичь того, на что не способны ни администраторы базы данных вашей компании, ни ваш внешний консультант. Хотя это может показаться благородным жестом, вы подвергаете себя риску. Вы могли бы «неявно пообещать» что-то, что вы никогда не сможете выполнить. У вас хотите рисковать?

  4. Когда кто-то, работающий с базой данных, запрашивает поврежденные данные, он может получить сообщение об ошибке. Ежедневная работа уже подвергается воздействию. Чем дольше вы будете ждать с неизбежным, тем больше будет производительность. У вас хотите рисковать? (Этот вопрос также может быть поднят с руководством)

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

Лучшая рекомендация, которую я могу вам дать, - остановить производство и позвонить в Microsoft! Или, по крайней мере, позвонить в Microsoft и, возможно, остановить производство.

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

Чем дольше вы ждете, тем дороже может стать восстановление.


Что касается ограничения на восстановление страниц, здесь цитата из официальной документации:

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

( акцент мой)

Ссылка: Операторы RESTORE - Аргументы (Transact-SQL) (Документы Microsoft)


Когда все вернется к нормальному состоянию, администраторы баз данных и / или внешние консультанты могут рассмотреть возможность реализации другой политики / процедуры резервного копирования / восстановления для вашей базы данных. Так как он должен быть размером 7x24, вы не можете рисковать созданием процедуры резервного копирования, которая не обеспечивает адекватных возможностей восстановления в любой ситуации.


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

1

Я вижу, вы пробовали разные методы, включая работу с «экспертами» по восстановлению данных, чтобы восстановить эту поврежденную базу данных, особенно размером более 1 ТБ. Это значительно усложняет процесс и ведет к гонкам со временем. Как опытный администратор баз данных, я сталкивался с подобными ситуациями, когда в большинстве случаев есть хорошие резервные копии, которые можно восстановить. В случае наследования плохих резервных копий и поврежденной базы данных я в значительной степени опирался на сторонний инструмент под названием Stellar Phoenix SQL Database Repair Tool . Этот инструмент хорошо известен для восстановления поврежденных баз данных (.mdf и .ndf). Ниже приведены некоторые функциональные возможности инструмента:

  • Восстанавливает поврежденные файлы базы данных SQL (.mdf & .ndf)
  • Восстанавливает таблицы, триггеры, индексы, ключи, правила и хранимые процедуры
  • Выполняет восстановление удаленных записей из базы данных SQL

  • Сохраняет результат сканирования базы данных для выполнения восстановления на более поздней стадии

  • Позволяет сохранить восстановленный файл в форматах MSSQL, HTML, XLS & CSV
  • Поддерживает MS SQL Server 2016, 2014, 2012,2008 и более ранние версии

Средство требует, чтобы файлы .mdf и .ndf находились в автономном режиме, поэтому отлично работает, если у вас есть копия поврежденной базы данных PROD, и вам не нужно останавливать службы SQL Server.

Лучшая часть заключается в том, что пробная версия предоставляет вам полную функциональность инструмента, за исключением того, что восстановленная база данных не может быть экспортирована / сохранена. Вы по-прежнему сможете просматривать все восстановленные объекты базы данных и обширный файл журнала восстановления, в котором содержатся подробные сведения о различных этапах процесса восстановления.

Не стесняйтесь загружать и видеть, помогает ли это. Скачать здесь

Я также написал блог о том, как этот инструмент работает на этом сайте: samosql blogs

Спасибо и HTH, чтобы сделать вас героем дня!

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.