Сегодня с утра пользователи 1С не смогли попасть в программу, вероятно просто не устанавливалось соединение с базой данных (меня в это время не было на месте, по этому воспроизвожу со слов помошника). Было принято решение произвести перезагрузку SQL сервера, после чего программа заработала.
Сейчас просматриваю логии, в которых до перезагрузки отражались следующие ошибка:

I/O error 21(Устройство не готово.) detected during write at offset 0x0000004b3c4000 in file 'E:\DataBase\sql1c_Data.MDF'.
Эта ошибка записывалась в те моменты когда была попытка выгрузки данных для перифирийной базы (производится по расписаниию)

После перезагрузки следующие сообщения:
Выполнен запуск MS DTC со следующими настройками.


Настройки безопасности (OFF = 0, ON = 1):

     Сетевое администрирование транзакций = (null),

     Сетевые клиенты = (null),

     Распределенные транзакции через внутренний протокол MSDTC = (null),

     Протокол TIP = (null),

     Транзакции XA = (null).

Server Process ID is 1136.
The description for Event ID ( 17176 ) in Source ( MSSQLSERVER ) could not be found. It contains the following insertion string(s): .
1132
18.11.2006 9:05:17
18.11.2006 6:05:17
SQL Server is starting at priority class 'normal'(4 CPUs detected).
SQL Server configured for thread mode processing.
Using dynamic lock allocation. [2500] Lock Blocks, [5000] Lock Owner Blocks.
The description for Event ID ( 1002 ) in Source ( APCPBEAgent ) could not be found. It contains the following insertion string(s): .
"Communications Established"
SuperSocket info: (SpnRegister) : Error 1355.

Analysis of database 'sql1c' (7) is 8% complete (approximately 2 more seconds)
3450 :
Recovery of database 'sql1c' (7) is 0% complete (approximately 56 more seconds) (Phase 2 of 3).

845 transactions rolled forward in database 'sql1c' (7).

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

Что касается причины: то как выяснилось , вчера вечером, мой помошник проявив инициативу решил проверить chkdsk –ом E – диск sql сервера, где как раз и находился файл базы данных, именно с этого момента и пошли ошибки в журнале событий.
Из 1С я запустил тестирование и исправление базы 1С.
Но я не уверен что этого достаточно, какие еще меры предпринять?

(1) Он запускал chkdsk /f /r - не ос тановив службы sql - сервера.

Ну а если с остановленным sql сервером можно проверять диски?

berezdetsky писал(а) 20. Ноября 2006 :: 09:56:

А вот, кстати, такой теоретический вопрос.

Предположим, chkdsk нашел проблему физического носителя как раз в файле базы данных или в файле журнала.
"Исправил" ее.

Сам файл при этом не потерян.
Но и информация в нем не 100% достоверная (ну, это как восстановления файла excel на дискете - bad sector отремапили, но информацию в нем потеряли - файл не открывается).

berezdetsky
Как ты думаешь (или может по опыту).
Как отреагирует sql server? Поместит базу в suspect или вообще начнет падать?
Как эту проблему отдиагностировать средствами sql server? DBCC CHECKDB?

P.S.
Мне бы было не по себе, я бы пошел за архивом...

Точно, про torn page detection я забыл. А без этого действительно - смотря куда пуля попадет, можно сразу и не заметить. Спасибо.

Тогда это нормальная стратегия: torn page detection позволяет отследить  момент, когда диск или контроллер откажет, а дальше - архив.

Вот еще только что нашел, что в sql 2005 возможена проверка контрольных сумм страниц.
Тоже, видимо, отличная возможность.