Восстановление журнала транзакций

У нас очень большая база данных (~ 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(заняло около 13 часов), который был успешным. Скажем так, мы все узнали о важности резервного копирования базы данных (и предоставления менеджерам проектов доступа к серверу ...).

Никогда не отсоединяйте базу данных Suspect. В любом случае, как вы прикрепили базу данных после ее отключения? Вы использовали 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перестроением журнала и проверять базу данных на наличие ошибок целостности.

Также второй (изменить базу данных) не будет работать, если были активные транзакции (не записанные на диск), когда файл журнала был потерян. При запуске или подключении 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) в документации по продукту.

Также см. Этот пост в блоге Пола С. Рэндала :

Аварийно-восстановительный режим: самое последнее средство