Сазонова Надежда писал(а):После внезапного отключения электричества невозможно войти в путевые листы, выдается сообщение: Аварийное завершение ASB-клиента Список фатальных ошибок: Файл "Путевые листы" (RWayS)(Main) не соответствует файлу регистрации.
Что делать?
Проблему мы исправили.
Произошла довольно редкая ситуация (в нашей практике случается примерно 1 раз в год, т.е. с учетом количества работающих систем, 1 раз в 30 лет), когда, в некоторых случаях, при ненормальном останове сервера, на котором развернута серверная честь системы, оказываются рассогласованы проверочные признаки в файлах, составляющих базу данных.
При работе системы управления базой данных в различные файлы, составляющие базу данных, записывается небольшое количество дублирующей информации. Эта дублирующая информация представляет собой как бы контрольную сумму того, что хранится в базе данных. Эта дублирующая информация записывается довольно редко и поэтому быстродействие не страдает. В случае, когда основная и дублирующая информация рассогласованы, система предполагает потенциальное повреждение данных и выдает критическую ошибку. В таком случае, анализируя данные, причины и обстоятельства сбоя, можно установить, повреждены данные на самом деле и нужно их восстановить из резервной копии, либо испорчены только проверочные признаки и достаточно восстановить только эти признаки с помощью особой утилиты IND.
Применение утилиты описанно в соответствующей статье документации «Восстановление элементов структуры данных»
http://www.autopark.ru/wiki/%D0%92%D0%B ... 1%8B%D1%85. Рекомендация не применять утилиту «без нас» связана с необходимостью проведения глубокого анализа того, что же на самом деле произошло с данными. Сама по себе процедура сброса проверочных признаков тривиальна и утилита выдает справку по её применению.
Как уже было указано, рассогласованность проверочные признаков свидетельствует о потенциальной угрозе повреждения данных в результате различных технических неполадок (неисправные диски, сбои при работе серверного оборудования, порча данных вирусами и т.п.).
Несмотря на то, что серверное оборудование категорически необходимо оснащать источником резервного электропитания, само по себе непредвиденное отключение питания сервера не является причиной повреждения данных. Дело в том, что активно осуществляя кеширование данных, система управления базой данных время от времени сбрасывает кэш на диск по специальному алгоритму, так, что даже если произойдет неожиданный отказ сервера, то это приведет только к утрате изменений последних ведущихся в системе транзакций, все же остальные данные останутся неповрежденными и не потеряются.
Все меняется, когда в результате неправильной настройки серверного оборудования данные, записываемые на диск начинают кешироваться самой операционной системой. Будучи оправданном в случае применения сервера в качестве файлового, этот механизм не следует применять при работе на сервере СУБД. Как уже указывалось, СУБД сама активно занимается кешированием записи, когда это возможно, но в случае необходимости сбросить данные на диск, этому не должна препятствовать операционная система, что происходит с включенной функцией кеширования. В таком случае может произойти то, что данные не будут вовремя сброшены на диск и часть из них будет потеряна.
Вот настройка свойств дискового контроллера, которая в данном случае привела к рассогласованию проверочных признаков при отключении питания сервера.
У вас нет необходимых прав для просмотра вложений в этом сообщении.