Мне было поручено попытаться восстановить базу данных, которая пострадала от повреждения (из-за сбоя ввода-вывода, который был исправлен с тех пор). Я не знаком с базой данных или тем, что она содержит.
Мне дали старую (~ 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, и они отказались, поэтому меня попросили взглянуть на это и посмотреть, смогу ли я Делать что-нибудь.
Обновление : после многих тестов постраничное восстановление было бесполезным, поэтому мы отказались от этой идеи. Мы собираемся выполнить восстановление вручную (вручную выбрав отсутствующие записи из поврежденных таблиц и вставив их в последнюю исправную резервную копию), выполнив некоторые автоматизированные инструменты для этого (опять же, есть сотни и сотни таблиц).
Я вижу, вы пробовали разные методы, включая работу с «экспертами» по восстановлению данных, чтобы восстановить эту поврежденную базу данных, особенно размером более 1 ТБ. Это значительно усложняет процесс и ведет к гонкам со временем. Как опытный администратор баз данных, я сталкивался с подобными ситуациями, когда в большинстве случаев есть хорошие резервные копии, которые можно восстановить. В случае наследования плохих резервных копий и поврежденной базы данных я в значительной степени опирался на сторонний инструмент под названием Stellar Phoenix SQL Database Repair Tool . Этот инструмент хорошо известен для восстановления поврежденных баз данных (.mdf и .ndf). Ниже приведены некоторые функциональные возможности инструмента:
Выполняет восстановление удаленных записей из базы данных SQL
Сохраняет результат сканирования базы данных для выполнения восстановления на более поздней стадии
Средство требует, чтобы файлы .mdf и .ndf находились в автономном режиме, поэтому отлично работает, если у вас есть копия поврежденной базы данных PROD, и вам не нужно останавливать службы SQL Server.
Лучшая часть заключается в том, что пробная версия предоставляет вам полную функциональность инструмента, за исключением того, что восстановленная база данных не может быть экспортирована / сохранена. Вы по-прежнему сможете просматривать все восстановленные объекты базы данных и обширный файл журнала восстановления, в котором содержатся подробные сведения о различных этапах процесса восстановления.
Не стесняйтесь загружать и видеть, помогает ли это. Скачать здесь
Я также написал блог о том, как этот инструмент работает на этом сайте: samosql blogs
Спасибо и HTH, чтобы сделать вас героем дня!
PS. Когда этот шторм закончится, не забудьте сообщить руководству, что его процедуры резервного копирования должны быть серьезно пересмотрены, особенно для такой базы данных. Повторение этого сценария совершенно недопустимо! :)
источник