Перебудова журналу транзакцій

У нас дуже велика база даних (~ 6 ТБ), файл журналу транзакцій був видалений (поки SQL Server був закритий. Ми намагалися:

1. Від'єднання та повторне приєднання бази даних; і
2. Скасування скасування файлу журналу транзакцій

... але поки нічого не працювало.

Зараз ми працюємо:

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

... але, враховуючи розмір бази даних, це, ймовірно, займе кілька днів.

Запитання

• Чи є різниця між командою вище та наступною командою?

  DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

• Чи слід виконувати REPAIR_ALLOW_DATA_LOSSзамість цього?

Варто зазначити, що дані отримані з інших джерел, щоб база даних могла бути відновлена, проте ми підозрюємо, що відновити базу даних буде набагато швидше, ніж знову вставити всі дані.

Оновлення

Для тих, хто ALTER DATABASE/REBUILD LOGведе рахунок: команда виконується приблизно через 36 годин і повідомляє:

Попередження: Журнал бази даних 'dbname' був відновлений. Трансакційна консистенція втрачена. Ланцюг RESTORE був порушений, і сервер більше не має контексту для попередніх файлів журналів, тому вам потрібно буде знати, що вони були.
Вам слід запустити DBCC CHECKDB для перевірки фізичної узгодженості. База даних була переведена в режим dbo-only. Коли ви будете готові зробити базу даних доступною для використання, вам потрібно буде скинути параметри бази даних та видалити зайві файли журналу.

Ми тоді побігли DBCC CHECKDB(взяли приблизно 13hrs), який був успішним. Скажімо, що ми всі дізналися про важливість резервного копіювання баз даних (і надання менеджерам проектів доступу до сервера ...).

Ніколи не відривайте базу даних підозрюваних. У будь-якому випадку, як ви приєднали базу даних після її від'єднання? Ви використовували CREATE DATABASEз FOR ATTACH_REBUILD_LOGопцією?

Ці команди повинні були виконати трюк:

ALTER DATABASE recovery_test_2 SET EMERGENCY;   
ALTER DATABASE recovery_test_2 SET SINGLE_USER;  

DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) 
WITH NO_INFOMSGS, ALL_ERRORMSGS;

Я написав пост для цієї ситуації:

Процедура відновлення бази даних SQL 2005/2008 - файл журналу видалено (частина 3)

Ви запитували про різницю між:

• DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) і
• ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

Вся справа в тому, що ви можете запустити обидва для відновлення файлу журналу, але разом з цим CHECKDBвідновіть журнал і перевірте базу даних на наявність помилок цілісності.

Також другий (база даних alter) не працюватиме, якщо були втрачені файли журналу, коли були активні транзакції (не записані на диск). При запуску або вкладенні SQL Server захоче виконати відновлення (відкат і відкат) з файлу журналу, якого там немає. Це трапляється, коли відбувається збій диска або відбувається несподіване відключення сервера, а база даних не є чистою. Я здогадуюсь це не було вашою справою, і все розібралось добре для вас.

1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)запустити базу даних в аварійному стані перевіряє базу даних на наявність невідповідностей, намагається спочатку використовувати файл журналу, щоб відновити будь-які невідповідності. Якщо цього немає, журнал транзакцій відновлюється.

2. ALTER DATABASE REBUILD LOG ON...є бездокументованою процедурою і потребує подальшого DBCC CHECKDBвиправлення будь-яких помилок.

Так, це дві різні заяви, кожен з яких робить дуже різні речі.

В залежності від стану бази даних , коли файл був видалений, ви можете бути в змозі отримати і працює шляхом приєднання бази даних і відновлення журналу за допомогою:

EXEC sp_attach_single_file_db 'dbname here', 'file path and name here'

Дивіться sp_attach_single_file_db (Transact-SQL) в документації на продукт.

Також дивіться цю публікацію в блозі Пола С. Рандала :

Ремонт в режимі ЕНЕРГЕНТНОСТІ: саме, дуже остання можливість