Вообще никаких бакупов нету ? БД не участвует в репликации SQLRemote как удаленная ?

P.S. Ошибка означает или сбой носителя или файловой системы. Какая кстати ОС и ФС ?

Сильно большая по обьему БД ?

Да уж. Я вот тоже буквально недавно переводил клиента на свой проект на ASA с другого проекта ASA, так для меня было шоком, что у них 2 года крутилась и работала база еще на ASA 9.0.0 вообще без какого либо резервного копирования. Не представляю себе сколько бы они набодались и сколько денег потеряли, если бы рухнула база или носитель, с учетом того, что бизнес у них онлайн и круглосуточный.

VovakaА dbvalid что говорит ?
Да ничего он не говорит, просто валится :) Везет же michael_ на такие ситуации, я вот за последние 2 года ни разу у себя или клиентов такого не получил, даже поюзать нечего, чтобы поразбираться :( Правда условий подходищих нет, все на NTFS W2K/XP/2003 и бакупы ежедневно делаются, тут наверное по закону подлости срабатывает.

Dim2000А это особый вид профессионализма - сломать то, что, казалось бы,
сломать невозможно
Ну это же клиенты - я на своей жизни много видел "чудес", которые творили пользователи там, где они просто не возможны. Хотя честно говоря не понятно, почему на момент инсталяции программы michael_ не запросить бы сразу путь для бакупа и жестко на автопилоте евентами нарезать каждый день инкременты, делая раз в месяц полный в новую подпапку.

А UNLOAD TABLE ... ORDER OFF тоже валит базу ?

Марсель ASCRUSДа ничего он не говорит, просто валится :) Везет же michael_ на такие ситуации, я вот за последние 2 года ни разу у себя или клиентов такого не получил, даже поюзать нечего, чтобы поразбираться :( Правда условий подходищих нет, все на NTFS W2K/XP/2003 и бакупы ежедневно делаются, тут наверное по закону подлости срабатывает.
Поюзать говоришь :)
Думаю, если возмешь тестовую БД (и .log) c сhecksum и откроешь как бинарник и где-нить в середине файла (главное чтоб попало на рабочие страницы) поменяешь "буковки", как раз получешь тоже самое.
Как раз уже юзаю :)

Значитсь.

Ну во первых, проверка БД на чексуммы не обрушивает БД, а очень даже красиво и корректно возвращает в виде набора данных сообщения об ошибке:

Во вторых после обнаружения ошибки контрольной суммы любой сессией, сервер автоматически для всех остальных сессий останавливает работу и новые сессии не могут подключаться - это есть правильно, так как БД битая и изменения в ней уже не должны быть разрешены, пока не будет произведен откат базы до небитого состояния. Так что операция включения контрольных сумм полезная и нужная, вызываемая по шедулеру эта проверка позволяет быстрее обнаружить разрушение БД и уведомить по мылу администраторов/разработчиков и остановить работу с БД пользователей во избежания потери последних транзакций.

В третьих, как только БД остановилась, мы всегда можем взять последний полный бакуп и наложить на него лог файлы инкрементных бакупов и разрушенной БД:
DBENG9.EXE C:\Data\Project.db -a D:\Backup\Project.log
таким образом мы восстановим все завершенные транзакции на момент остановки БД.

В четвертых, для сохранности бакупов, неплохо бы их делать на внешние устройства резервирования и/или по сети на другие компьютеры.

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

Все - хоть убейся, при соблюдении этих 5-и пунктов никакая DBCC не понадобится в принципе, даже если они настолько упертые, что крутят БД на FAT или без упсы, просто чаще восстанавливать БД будут. Причем все эти пункты можно автоматизировать до уровня визуальной утилиты визарда в комплекте приложения, где после падения БД, клиент ее запустит, пройдет несколько шагов и снова сможет работать со своей любимой БД. По идее, любой тиражный проект должен иметь ее на борту в инсталяции как само собой разумеющееся.

Ну и вдогонку - выполнение оператора "VALIDATE CHECKSUM" перед выполнением "BACKUP DATABASE DIRECTORY" обязательно, иначе сделаем бакуп, в котором будут те же разрушенные страницы.