Произошел сбой одного диска в RAID 10 на сервере 1С и SQL. На дисках базы 1С. Сейчас пользователи могут работать в базе, но не проводятся ряд документов (вылетает в ошибку и просит перезагрузить 1С).
Текст ошибки.
The operating system returned error 23(Ошибка в данных (CRC).) to SQL Server during a прочитать at offset 0x00000037b60000 in file 'E:\DATA\upp_2014.mdf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Копия средствами Sql или 1С не делается (ошибка).
Подскажите как лучше действовать. С какими ключами запускать проверку DBCC CHECKDB.

Версии ПО:
Microsoft SQL Server 2008 R2 (SP3) - 10.50.6220.0 (X64)
Управление производственным предприятием, редакция 1.3 (1.3.83.1) База РИБ (филиал)
1С:Предприятие 8.3 (8.3.8.1675)

Таблицу уже определили?

DBCC CHECKTABLE (таблица, REPAIR_ALLOW_DATA_LOSS)

Сделай бекап только (хоть даже останови сервер и скопируй файлы БД)

Шаг номер ноль: сиквел стоп, делам физическую копию базы и журнала

шаг 1 восстанавливаем рэйд (согласуем). должно хватить.
шаг 2 выясняем причину сбоя по данным рэйд контроллера.
шаг 3 проверяем диски.


до DBCC CHECKDB Вам еще далеко

(3) Ну думается, что рейд уже восстановили!? Иначе о чем речь может быть, о каком продолжении работы?

восстановите резервную копию  
в новую бд

(1) Таблицу не определил.

(5) если бы заметил это вчера утром, то восстановил бы без проблем. Архив есть с выходных. Сегодня ночью архив уже не создался.
Поэтому попробую сначала исправить базу.

(6) определяешь какие документы не пашут, обработкой "СтруктураБД" или как-то так определяешь какие таблицы связаны с этим документом - и их лечишь. Но будут потери данных. Если это таблица движений - то придется пересчитывать итоги/перепроводить документы. Если это сам документ или табличная часть - то сам документ восстанавливать. Их может быть много, даже может оказаться что реальней взять бекап с выходных, смотря сколько наработать успели.

Вот обработка: http://catalog.mista.ru/public/147147/
Но поищи так, она много где валяется.

(2) спорный совет. где гарантии, что база потом приаттачится?

(9) лучше чем не делать бекап вовсе.

(10) зависит от того - какой свежести есть целый бэкап

ldf не накрылся и модель восстановления full, то можно накатить журнал на резервную копию.

что то похожее было в практике. в один прекрасный момент пришло на почту оповещение, что бэкап рабочей базы не был сделан. ну ладно. мало ли. может место закончилось. запустил вручную. на 60% упало с ошибкой i/o. ясен красен, что винту стало плохо. тоже советовали отсоединить базу. не стал рисковать. развернул свежий бэкап и перетащил из "битой" базы данные через скуль (так как simple). отсоединил "битую" базу. а обратно - фиг. при этом пользователи могли спокойно работать в "битой" базе

Попробовал перезагрузить сервер, диск в Raid все еще с ошибкой, ищу замену.
Так как обмены идут с ЦБ сделал выгрузку и решил перезагрузить сервер. После перезагрузки sql сделал бекап. Восстановил в копию. сейчас буду смотреть что-там в копии восстановилось.