Доброго времени суток!

Столкнулись с проблемой на сервере:
firebird.log

Долго гуглил, нашел, что похожая проблема была исправлена в 2012 году r57063 (у нас был старый сервер). Попробовали поставить свежий вариант версии 2.1.6-Release (2.1.6.18547) . Однако проблема осталась.

Проблема проявляется в следующем случае:
Если базы находятся в режиме Read_Only , сервер запущен как служба в режиме SuperServer и происходит множественные обращения к одной и той же базе разными пользователями (так, чтобы сервер не отпускал базу, не отсоединялся от нее), то через некоторое время (в зависимости от частоты обращений) выдается вышеописанная ошибка. При этом сервер больше не может к данной базе обратиться пока: либо все не закроют приложения (коннекты к данной базе), либо не будет перезапущен сервер.

При интенсивной работе более 2-х пользователей с базой на сервере, данная ошибка проявляется минут через 40. Если количество пользователей около 5-ти, то база "залипает" уже минут через 15-20.

Настройки сервера выставлены по умолчанию. Сервер Firebird 2.1.6 запущен на WindowsXP SP3, однако, не думаю что с этим может быть связана проблема.

Спасибо за Вашу помощь

Симонов Дениснадо было ставить Classic. Хотя вряд ли эта ошибка связана с супером.

C Classic вообще как-то странно себя программа ведет при работе нескольких пользователей... Но это другая проблема.

Dimitry SibiryakovСимонов Денисвряд ли эта ошибка связана с супером.
Скорее с тем, что база в read-only.

Это определенно связано с RO базами, но это вынужденная необходимость, без такого рода баз, они жутко тормозят с flash накопителей. Сейчас выкручиваемся тем, что людям с серверами поставляются RW базы, а тем, у кого они работают без сервера (не многопользовательский доступ), поставляются в RO. Но сами понимаете, это не хорошо, поставлять разные варианты одной и той же базы...

Хотелось бы решить проблему с сервером, чтобы он адекватно работал с RO базами...

kdvPincher1519либо не будет перезапущен сервер.
при этом новые коннекты нормально работают? база не битая?
Все верно. Как только сервер отпустит базу, то он ее снова поднимает и корректно с ней работает до очередного времени "Ч".

Dimitry SibiryakovPincher1519без такого рода баз, они жутко тормозят с flash накопителей.
А вы самому файлу БД флаг read only на уровне файловой системы выставляете?

Конечно нет. Базу переводил в режим RO через утилиту GFix.exe или через gbak.exe (в принципе разницы нет).

hvladПроблема в том, что у read-only БД счётчик тр-ций исправно растёт, но новые страницы в TIP не выделяются.
Поэтому, когда Next выйдет за границы последней имеющейся страницы TIP, получаем указанный багчек 165.
Спасибо за развернутый ответ.
hvladЯ был уверен, что исправлял эту старую багу, но не могу найти этого в трекере...
Возможно она до сих пор с нами.
Было бы славно, если бы нашли и мы бы смогли воспользоваться данным исправлением.

Dimitry SibiryakovPincher1519Конечно нет.
А зря. Там может быть разница.
Может я что-то не понимаю, но сервер не может подключаться к базам данных, если он не получает права к ним на запись, будь то атрибут "только чтение" или "ограничения прав на уровне NTFS".
Поясните свою точку зрения, пожалуйста.

pastorВы ни разу не пробовали подключаться к БД на сидюке?

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

hvlad, Не подскажите, а в 2.5 сервере данная проблема устранена?.. За два дня тестирования пока не удалось добиться данной проблемы, возможна ли такая ситуация, что с 2.5 сервером все будет в порядке и нам есть смысл перейти на него?..

hvladPincher1519hvlad, Не подскажите, а в 2.5 сервере данная проблема устранена?.. Не помню. Проверить легко - нужно стартовать и завершить более page_size * 4 тр-ций в одном коннекте, если не будет багчеков, значит скорее всего исправлено
К сожалению, проблема также осталась...

Версия сервера: WI-V2.5.3.26778 Firebird 2.5
Размер страницы: 8192
Класс сервера: SUPER SERVER
База в режиме RO: True
Ошибка выполнения запроса
=>Исключение при вызове "ExecuteNonQuery" с "0" аргументами: "internal Firebird consistency check (cannot find tip page (165), file: tra.cpp line: 2375)"
Номер итерации: 27339