Индексный файл CDX и Windows 2003 Server

709
pablomedok

Мы наблюдаем почти ежедневное повреждение индекса базы данных в Windows Server 2003. Интересно, может ли это быть как-то связано с кэшированием или другими настройками сервера.

Мы запускаем старое приложение, которое использует таблицы DBF / CDX. Все было хорошо целую вечность, но через 6 месяцев после того, как мы установили Advantage Database Server (который разрешает доступ к некоторым таблицам на нашем сайте), у нас начались проблемы с повреждением индекса. И мы не знаем, кого винить. ADS возвращает ошибку: Ошибка 7017: поврежден индекс .ADI, .CDX или .IDX. Название таблицы: RBOOKM

Мы попытались исключить все возможные причины этой коррупции. Теперь все пользователи работают в режиме терминала - поэтому никакие проблемы с сетью не могут вызвать это, OpLocks также не может быть причиной. Мы сменили оборудование, сетевые карты, коммутаторы, переустановили Сервер и даже переехали на новый выделенный сервер. Единственное, что мы не можем исключить, это ADS - потому что оно должно работать.

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

Возможно ли, что эта проблема вызвана импортером файлового сервера или настройками кэширования? Возможно ли, что обычные пользователи используют не кэшированные данные, а ADS использует кэшированные данные? Или наоборот? Возможно ли, чтобы у каждого пользователя терминала был свой кеш? Или, может быть, проблема в том, что кеширование RAID каким-то образом мешает кешированию Windows Server? Или, может быть, есть некоторые специальные настройки для Windows Server для работы с таблицами DBF, которые пишутся одновременно несколькими пользователями терминала? Может быть, есть способ отключить кеширование некоторых файлов, чтобы проверить это?

Иногда мы получаем сбои индекса два раза в день, иногда все нормально в течение 5 дней подряд. Но обычно это происходит ежедневно. Сегодня вечером только один пользователь работал с базой данных (обычно 30-50 пользователей работают одновременно в рабочее время). Так что это почти нулевая нагрузка на сервер. Синхронизация с сайтом выполняется каждые 5 минут в рабочее время и каждые 15 минут вечером и в выходные дни.

Мы провели аудит доступа к файлам, и он показывает, что во время синхронизации веб-сайтов сервер ADS открывает файлы таблиц и индексов для ReadEA и WriteEA, хотя он выполняет только запросы SELECT. ADS выполняет запросы UPDATE / INSERT, но реже - не во время регулярной синхронизации, а только тогда, когда посетитель размещает заказ).

Пожалуйста, помогите мне. Мы боремся с этой проблемой уже почти год и до сих пор не можем найти какой-либо образец или какой-либо ключ к решению этой проблемы.

Вот мой предыдущий вопрос об этой проблеме на DBA: https://dba.stackexchange.com/questions/8646/foxpro-dbf-index-corruption

1
Один из моих клиентов всегда получал повреждение индекса в таблицах DBF / CDX. Это известная проблема с точки зрения поставщика. Только миграция на SQL Server устранила проблему. 11 лет назад 0
спасибо, но я думаю, что должно быть решение, поскольку мы жили без искажений индекса (хорошо, с редкими повреждениями раз в месяц) в течение более 10 лет, даже с большим количеством пользователей сети. pablomedok 11 лет назад 0
Вчера, после очередного сбоя индексации, я сделал резервную копию файла таблицы с прерываниями, а также файла индекса. А позже я решил проверить поврежденный индексный файл. Оказалось, что с этим все в порядке. Я также попытался соединить этот файл с базой данных, и мне это тоже удалось. Я мог бы открыть этот файл и добавить запись. Таким образом, это выглядит как неиндексная проблема, но проблема отказа в доступе - в некоторых случаях индексный файл становится недоступным по какой-то причине. pablomedok 11 лет назад 1
Хорошее устранение неисправностей! Дайте нам знать, если вы приблизитесь к проблеме. 11 лет назад 0

0 ответов на вопрос

Похожие вопросы