Мы столкнулись с неприятной ситуацией когда «случайно» был удален файл логов базы данных MS SQL dbname_log.ldf. А работоспособность базы нужно восстанавливать, потому как актуальных резервных копий нет… Конечно не излишне будет повториться, что актуальные резервные копии важных баз, как впрочем и любой другой информации, должны быть всегда и лучше в избытке)
Первое, что было сделано — служба SQL Server была остановлена, и скопирован оставшийся файл данных базы.
После база была удалена и было испробовано приаттачить файл с данными к новой базе dbname без файла логов
EXEC sp_attach_db @dbname = N'dbname', @filename1 = N'D:\SQLDATA\dbname.mdf'
На что была получена ошибка
Сообщение 5120, уровень 16, состояние 101, строка 1
Не удалось открыть физический файл «E:\SQLLOG\dbname_log.ldf». Ошибка операционной системы 32: «32(Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.)».
Сбой при активации файла. Возможно, физическое имя файла «E:\SQLLOG\dbname_log.ldf» неправильное.
Не удается перестроить журнал, поскольку во время завершения работы базы данных существовали открытые транзакции или подключенные пользователи, для базы данных отсутствуют контрольные точки либо она доступна только для чтения. Эта ошибка может возникать, если журнал транзакций был удален вручную или оказался потерян в результате сбоя оборудования или аварии.
Сообщение 1813, уровень 16, состояние 2, строка 1
Невозможно открыть новую базу данных «dbname». Операция CREATE DATABASE прервана.
Второе, что было сделано. Была создана новая, одноименная с удаленной, база данных dbname. Служба SQL Server была остановлена и вновь созданный с базой файл данных dbname.mdf был заменен на прежний. Служба сервера запущена.
Далее выполняем запрос
use master
go
sp_configure 'allow updates', 1 reconfigure with override
go
alter database dbname set emergency
go
alter database dbname set single_user
go
dbcc checkdb ('dbname', REPAIR_ALLOW_DATA_LOSS)
go
alter database dbname set multi_user
Видим длинный лог, который оканчивается
CHECKDB обнаружил 0 ошибок размещения и 0 ошибок согласованности в базе данных «dbname».
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.
То есть мы имеем работоспособную базу MS SQL. Далее было сделано следующее. Поскольку эта база являлась базой программы 1С, из самой 1С был выполнен экспорт «Выгрузить информационную базу…» который прошел успешно. SQL база была удалена, создана одноименная новая, подключена к 1С. В 1С был выполнен импорт через «Загрузить информационную базу…».
Завершающим шагом стала настройка регулярного резервного копирования.