Відновлення веб-сторінки на рівні 1000 меж

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

Мені було надано старе (~ 3 тижні) повне резервне копіювання та ряд журналів транзакцій ... однак відсутні журнали транзакцій, тому я можу відновитись лише до певної дати. Не вистачає 2,5 тижнів даних (і в цю базу даних постійно додається багато даних).

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

Я спробував типові DBCC CHECKDBкоманди (все ще ні repair_allow_data_loss, це буде моєю останньою інстанцією, якщо нічого іншого не вийде).

Після того, як багато хто приходить і переходить до бази даних (db - це 1,5 терабайтний маленький монстр, і все, що я роблю, повільно і займає певний час), я намагався відновити Інтернет-сторінку з останнього відомого хорошого резервного копіювання для пошкоджених сторінок.

Для цього я зробив сценарій, який створює багато RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'команд з DBCC CHECKDBвиводу (базічно регулярний вираз і виразний) ... поки що добре, це спрацювало до моменту, коли він сказав, що я досяг границі в 1000 сторінок на файл (на цьому db є 8 файлів) на команду відновлення.

Тож він просить мене "завершити відновлення в Інтернеті", але я втрачаю те, як це зробити ... У мене немає журналу хвоста або нічого більш повного, ніж повне резервне копіювання, з якого я починаю, так Я взагалі не знаю, як завершити відновлення, щоб продовжувати намагатися з рештою сторінок.

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

Хтось має поради, як я можу спробувати відновити що-небудь звідси? Або як "завершити" відновлення в Інтернеті, щоб я міг намагатися відновити більше сторінок? Чи буде у мене така ж проблема, якщо я спробую відновити офлайн (в основному додаю WITH NORECOVERYдо всього, а потім намагаюся повернути його в кінці?)

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

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

Пошкоджена база даних - це все-таки в Інтернеті, і клієнти працюють над нею (тому він постійно отримує нові дані), тому будь-який процес, який я роблю на лавці лабораторії, повинен бути відтвореним у виробничій базі даних згодом (час простою буде важким для цього).

Це SQL Server 2014 Enterprise

PS: Я не DBA ... Я програміст, але клієнт випробував кілька "експертних" служб відновлення аварійних ситуацій, і вони відмовилися, тому мене попросили подивитися і подивитися, чи зможу я зробити що-небудь.

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

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

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 Docs)

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

Ви знаходитесь у складній ситуації.

1. У вашій базі даних є пошкоджені сторінки, і ваша компанія постійно додає нові дані до бази даних із проблемами. Це може призвести до загального простою бази даних. У вас хочете ризикувати?

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

3. Ви ставите себе у скрутну ситуацію, беручи на себе роль, яку ви не працювали. Ви намагаєтесь досягти чогось, на що не змогли ні ваші юридичні особи компанії, ні ваш зовнішній консультант. Хоча це може здатися благородним жестом, ви піддаєте себе ризику. Можливо, ви "неявно пообіцяли" те, чого ви ніколи не зможете виконати. У вас хочете ризикувати?

4. Коли хтось, що працює з базою даних, запитує пошкоджені дані, можливо, вони отримають повідомлення про помилку. Щоденна робота вже впливає. Чим довше ви чекаєте неминучого, тим більше буде впливати на продуктивність. У вас хочете ризикувати? (Це питання також може бути порушено з керівництвом)

5. Процедура резервного копіювання вашої компанії здається помилковою (інакше як би не було резервних копій TLOG?), І ви все ще запускаєте свою виробничу базу даних, як ніби проблем не було. У вас хочете ризикувати?

Найкраща рекомендація, яку я можу дати вам, - зупинити виробництво та зателефонувати в Microsoft! Або принаймні зателефонуйте до Microsoft і, можливо, зупиніть виробництво.

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

Чим довше ви чекаєте, тим дорожчим може стати відновлення.

Щодо обмеження на відновленні сторінки, то тут цитата з офіційної документації:

Максимальна кількість сторінок , які можуть бути відновлені в будь-який один файл в послідовності відновлення становить 1000 . Однак якщо у вас є більше невеликої кількості пошкоджених сторінок у файлі, подумайте про відновлення цілого файлу замість сторінок.

^{( наголос мій)}

Довідка: RESTORE Заяви - Аргументи (Transact-SQL) (Microsoft Docs)

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

Я бачу, ви спробували різні методи, включаючи роботу з експертами з відновлення даних, щоб відновити цю корумповану базу даних, особливо розміром понад 1 ТБ. Це робить процес набагато складнішим і гонка проти часу. Як досвідчений менеджер DBA, я стикався з подібними ситуаціями, коли більшу частину часу є хороші резервні копії для відновлення. У випадку успадкування поганих резервних копій та пошкодженої бази даних я значною мірою покладався на інструмент сторонніх розробників, який називається інструментом відновлення бази даних Stellar Phoenix SQL . Цей інструмент добре відомий для відновлення пошкоджених баз даних (.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. Коли ця шторм закінчиться, не забудьте сказати керівництву, що потрібно здійснити капітальний ремонт їх резервних процедур, особливо для такої бази даних. Повторення цього сценарію абсолютно неприпустимо! :)