Здравствуйте.
Версия сервера Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64)
Oct 19 2012 13:38:57
Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
После перезагрузки сервера база ушла в режим (Ожидание восстановления). Пробовал использовать часто встречающийся в поиске скрипт:
ALTER DATABASE scout_storage SET EMERGENCY;
GO

ALTER DATABASE scout_storage SET SINGLE_USER;
GO

DBCC CHECKDB (scout_storage)
GO

ALTER DATABASE scout_storage SET MULTI_USER;
GO

ALTER DATABASE scout_storage SET ONLINE;
В сообщении появляются ошибки:

Сообщение 5120, уровень 16, состояние 101, строка 1
Не удалось открыть физический файл "C:\Program Files\Microsoft SQL Server\MSSQL11.KGKRSQL\MSSQL\DATA\scout_storage.mdf". Ошибка операционной системы 32: "32(Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.)".
Сообщение 5120, уровень 16, состояние 101, строка 2
Не удалось открыть физический файл "C:\Program Files\Microsoft SQL Server\MSSQL11.KGKRSQL\MSSQL\DATA\scout_storage.mdf". Ошибка операционной системы 32: "32(Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.)".
Сообщение 945, уровень 14, состояние 2, строка 2
Не удалось открыть базу данных "scout_storage" вследствие недоступности файлов, нехватки памяти или места на диске. Подробности см. в журнале ошибок SQL Server.
Сообщение 5120, уровень 16, состояние 101, строка 2
Не удалось открыть физический файл "C:\Program Files\Microsoft SQL Server\MSSQL11.KGKRSQL\MSSQL\DATA\scout_storage.mdf". Ошибка операционной системы 32: "32(Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.)".
Сообщение 5120, уровень 16, состояние 101, строка 2
Не удалось открыть физический файл "C:\Program Files\Microsoft SQL Server\MSSQL11.KGKRSQL\MSSQL\DATA\scout_storage.mdf". Ошибка операционной системы 32: "32(Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.)".
Сообщение 5120, уровень 16, состояние 101, строка 2
Не удалось открыть физический файл "C:\Program Files\Microsoft SQL Server\MSSQL11.KGKRSQL\MSSQL\DATA\scout_storage_log.ldf". Ошибка операционной системы 32: "32(Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.)".
Сообщение 5181, уровень 16, состояние 5, строка 2
Невозможно повторно перезапустить базу данных "scout_storage". Возвращение к предыдущему состоянию.
Сообщение 5069, уровень 16, состояние 1, строка 2
Не удалось выполнить инструкцию ALTER DATABASE.

Попробовал метод из статьи http://blog.vb76.com/vosstanovlenie-bazy-ms-sql-posle-udaleniya-fajla-logov-_log-ldf/

Но к сожалению это тоже не дало положительного эффекта. Не могу разобраться как вычислить процесс который мешает выполнить восстановление базы.
Судя по всему проблема возникла из-за выросшего файла логов (вот https://habrahabr.ru/sandbox/40161/ что то похожее описывают) - scout_storage_log.ldf вырос до 4,01 Гб.
Метод из песочницы хабра так же не работает. Ошибка доступа к файлу scout_storage.mdf.

К сожалению этот вариант я пробовал. Кроме самой БД в данный момент с файлом никто не общается.

В оффлайн режим базу перевел. Правда теперь обратно не возращается - выдает ошибку


Приложил лог файл

Вы имеете в виду выполнить такой запрос:

USE master;
GO
CREATE DATABASE scout_storage+
ON PRIMARY (NAME = scout_storage+,
(NAME = 'C:\Program Files\Microsoft SQL Server\MSSQL11.KGKRSQL\MSSQL\DATAscout_storage.mdf);
GO

?

Yasha123в еррорлоге фигурирует еще некая база scout_storage_bad.
уж не на тех же ли она файлах основана?
а то поди она-то и держит эти файлы

база scout_storage_bad моя попытка решить проблему в прошлый раз. Так же сыпались ошибки про занятость в итоге переименовал эту базу. создал новую с таким же именем и развернул бекап свежий. Беда в том что в тот раз я сменил пароль sa, а вот сделать это в скрипте бекапа забыл. Соответственно 2 недели я жил без бекапов, поэтому и пытаюсь воскресить текущую базу scout_storage.

Minamoto,







После очередной перезагрузки и возвращении файлов на место - база перешла в статус подозрительная

Minamoto,

Возможно вы правы, переименование базы в scout_storage_bad проводил через оснастку Ms SQL server management studio. Файлы базы переименовались в scout_storage_bad.mdf и scout_storage_bad_log.ldf
Во всяком случае эти файлы есть в каталоге DATA.
Кстати метод восстановления который до этого ни в какую не работал на scout_storage_bad сейчас отработал нормально и база в нормальном статусе, увы там нет данных за 2 недели и хотелось бы починить текущую.

Minamoto,

Не пойму как выдернуть в виде файла результат и сюда приложить


Написал вам в почту указанную в профиле.

Yasha123,

а откуда появилась связь?
Я же переименовал базу. изменилось имя файла базы и файла логов.
Потом создал новую и развернул в нее бекап из bak файла (тип полная резервная копия). Откуда связь взялась?

Yasha123,
Разобрался вроде бы в чем беда. Но даже если 2 базы смотрят на одни файлы. Но запись приложение вело только в базу scout_storage. Вторая база просто лежала в режиме ожидание восстановления. Могло это повлиять на свеже созданную?

Вывел базу scout_storage_bad в offline
Теперь статус scout_storage стал подозрительный.
Каким скриптом ее теперь починить лучше?

Minamoto,

Ну вот собственно и убедился как руки чайника могут сотворить ситуацию, которую потом не могут повторить спецы.

Еще раз опишу ситуацию с самого начала.
12.02
Приложение перестало работать. Когда запустил менеджер SQL. У базы scout_storage стоял статус подозрительный . Тех поддержка сопровождающая предложение посоветовала выполнить скрипт
EXEC sp_resetstatus [scout_storage];
ALTER DATABASE [scout_storage] SET EMERGENCY
DBCC checkdb([scout_storage])
ALTER DATABASE [scout_storage] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ([scout_storage], REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE [scout_storage] SET MULTI_USER

Но появлялась ошибка - файл занят. Как я полагаю надо было прежде чем запускать скрипт - вывести его в оффлайн режим. Я же только отключил приложение которое писало в эту базу.

В итоге я решил переименовать базу в scout_storage-bad - это мне сделать удалось после очередной перезагрузки сервера. статус базы так и остался ждет восстановления.
Затем я создал в ручную без скрипта новую базу scout_storage и развернул туда последний бекап из bak файла (режим копии полная).

И все работало до перезагрузки спустя 2 недели.

Не могу понять почему при переименовании сменилось имя базы в менеджере, файлы в папке тоже переименовались, а вот ссылки остались на прежние scout_storage. Видимо из-за того что переименовывал тоже руками через менеджер.

Т.е. у меня теперь вот такая ситуация:




Как можно вернуть базу в рабочее состояние?