Назад | Перейти на главную страницу

Базы данных SQL Server 2008 R2 «Подозрительные» после перемещения журналов

У нас есть клиент, использующий наше программное обеспечение с MSSQL, и мы пытаемся решить за него проблему. Мы больше работаем с MySQL, так что прошу прощения за мое незнание способов MSSQL Server.

У них есть 3 тома на этом физическом сервере: C: \; D: \; и L: \ Том D: \ содержит базы данных SQL, объем L: \ содержит журналы транзакций.

Том L: \ был заполнен из-за действительно ужасной подготовки и управления, и, прежде чем связаться с нами, они остановили SQL, переместили журналы транзакций SQL в D: \, где было место, приступили к созданию нового рейда L: \ с физические диски большего размера, затем переместили журналы транзакций и перезапустили службы SQL.

С этого момента они не могли войти в SQL Management Studio или получить доступ к базам данных.

Мне удалось войти, но все базы данных помечены как (Подозрительные). Я вообще не могу получить какие-либо свойства из баз данных.

Некоторые поисковые запросы в Google предложили запустить несколько запросов к базам данных, чтобы решить эту проблему, но я не хочу их запускать. Похоже, что частично это проверка DBCC по базам данных, но я не знаком с остальным.

ЗДЕСЬ эта ссылка.

Кто-нибудь может посоветовать решить эту проблему или знает, что могло произойти?

Заранее спасибо за помощь,

Аарон

Сделайте резервную копию базы данных (остановите службу, скопируйте .mdf) и запустите этот сценарий. Строка REPAIR_ALLOW_DATA_LOSS потенциально может быть разрушительной.

Сценарий для будущего использования:

EXEC sp_resetstatus [YourDatabase];
ALTER DATABASE [YourDatabase] SET EMERGENCY
DBCC checkdb([YourDatabase])
ALTER DATABASE [YourDatabase] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ([YourDatabase], REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE [YourDatabase] SET MULTI_USER

Если это вас утешает, в нашем продукте используется репликация слиянием, поэтому у нас есть тысячи портативных компьютеров, на которых работает SQL Express, и мы регулярно видим подозрительные базы данных. Запуск именно этого сценария после резервного копирования баз данных устраняет проблему в 99% случаев без каких-либо побочных эффектов.

Что касается причины, трудно сказать, и вам, возможно, придется покопаться в журналах. Скорее всего, если это Express, он будет ограничен тем, что включено для ведения журнала, но возможные причины:

  1. Неправильное завершение работы службы SQL Server (например, завершение работы службы, жесткий перезапуск компьютера)
  2. Аппаратный сбой
  3. Недостаточно места на диске при записи данных
  4. Различные повреждения файла db

Все остальное не удается, восстановите резервные копии, если они есть. Шаги выше должен тем не менее, заставит вас работать в короткие сроки.