Обнаружил на тестовом сервере БД, недоступную пользователями. Когда на этом сервере умер жёсткий диск, большую часть баз я перенёс, какие-то просто убил за ненадобностью, а про эту, получается, просто забыл.
Проблема с этой БД была в том, что раньше у неё журнал транзакций лежал на диске E, теперь такого диска на этом сервере не было в принципе, а журнал транзакций располагался по тому же пути, но на диске D.
С помощью ALTER DATABASE hd_ts MODIFY FILE (name = 'hd_ts', filename = 'D:\bases\hd_ts_log.ldf') я показал, что журнал транзакций теперь живёт в другом месте. Файл этот, к сожалению был повреждён и база данных упала в SUSPECT.
Я выполнил ALTER DATABASE hd_ts SET EMERGENCY и SET SINGLE_USER, после чего с hd_ts появилась возможность делать хоть что-то. Выполнив DBCC CHECKDB ('hd_ts') WITH NO_INFOMSGS, я увидел, что ошибок не обнаружено, но при попытке сделать ALTER DATABASE hd_ts SET ONLINE, БД снова упала в suspect.
Тут я сделал глупость и удалил сам файл журнала транзакций, после чего ни о каком EMERGENCY речь уже не шла. Почитав форумы, я понял, что DBCC CHECKDB ('hd_ts', REPAIR_ALLOW_DATA_LOSS), скорее всего спасло бы меня. Но, что делать сейчас, было непонятно.
Сделать DETACH БД SQL Server не давал, а останавливать сервер на котором крутится десяток других тестовых баз ради того чтобы спасти никому ненужную БД, было бы не логично. В принципе, если бы я мог остановить сервер - потом можно было бы сделать CREATE DATABASE FOR ATTACH_REBUILD_LOG, либо attach_single_file_db и проблема была бы решена. И вот, наткнулся на такую "недокументированную" возможность ALTER DATABASE:
ALTER DATABASE hd_ts REBUILD LOG ON (name = 'hd_ts_log', filename = 'd:\bases\hd_ts_log.ldf'). Вуаля, база жива.
Комментариев нет:
Отправить комментарий