Система написана на C++(алгоритмы распознавания), C# все остальное: служба распознавания, клиент системы.
Всего четыре компа абсолютно одинаковых (SUPERMICRO, SCSI, 2Мб кэш и др фарш). WinXPSP1.
Сервер БД - MSSQL2000DE - отдельный комп. Он же рабочее место оператора. Остальные три компа работают над распознаванием типоразмеров заготовок, идущих по трем конвейерам с частотой 2~6 сек. Для каждой заготовки сохраняется информация о типоразмере, времени прохода, фотография (JPEG ~55KB) и др. При низкой уверенности алгоритма распознавания сохраняется десять фотографий (по пять с каждой из видеокамер) для соответствующей заготовки. Система работает в режиме 24/7. В год генерируется до 6 млн записей. Правда фотографии удаляются через 4 суток. Система хранит все данные кроме фотографий до 5 лет. На данный момент система проработала один год. Размер БД - 4~8Гб в зависимости от качества маркировки партий заготовок.

Возникла необходимость резервирования баз данных с возможностью запросов отчетов из резервной(ых) копии при аварии основного сервера. Попробовал решение в лоб - поставить MSSQL2000DE на каждый комп и резервировать параллельно. И вот какая гадость получилась: оказывается служба сервера MSSQL2000DE может иногда отбирать процессор у остальных процессов на время до 1 сек и более. Несмотря на то, что потоки службы распознавания имеют максимальный приоритет, это происходит и этого достаточно для пропуска заготовки (сигнал стоит 750 мсек). Замерялось с помощью вспомагательного микроконтроллера в системе. Мало того - это происходило не раз, когда на одном из компов распознавания стоял вхолостую (без обращений к нему) MSSQL2000DE, что выяснилось только в процессе этих разборок.

Из всего этого я сделал вывод, что серверный вариант БД мне не подходит. Нужен быстрый встраиваемый движок с поддержкой SQL запросов. Желательно - бесплатный. Синхронизацию многопользовательского доступа к БД могу написать сам - есть заготовки.

Попробовал SQLite 3 - не так уж и плохо, но с ростом записей вставка все медленней и медленней, хотя изначально, в режиме открытой транзакции она примерно равна по времени с MSSQL. При автоматических транзакциях - все совсем грустно: 10 вставок в секунду.

Подскажите варианты.

Спасибо.

Anton Demidov
Далее, под резервированием ты скорее всего называешь репликацию - поддержание копии данных на другом сервере. Это можно сделать как ручками, так и используя встроенные средства СУБД. Если интересно, поищи по словам replication MySQL (SQL Server, etc)


Как бы это ни называлось оно должно работать хотя бы на одном из трех распознающих компах, не мешая процессу.
Для репликации уменя руки не из того места росли - не смог нормально настроить на оффисных компах при разработке. А синхронность баз в моем варианте обеспечивается алгоритмом.

Всем спасибо за время, потраченное на мою проблему.