Мимопроходящий, спасибо.
Но sweep не хочу - у нас ночью происходит backup/restore. А в течении дня sweep для нашей базы - только лишние тормоза.
А вот насчет буферов - вы считаете, что это принципиально? Здесь есть какая то выгода?

Симонов ДенисТы вместо анализа того что именно происходит просто перебираешь различные варианты конфигов
Я исхожу из того, что архитектура приложения и выбранный вариант конфигурации сервера - это малопересекающиеся сущности. Может быть я не прав. Но эта база и связанные с ней приложения нормально работали в вариантах IB7.5+BDE (SS), IB2009+BDE (SS), FB2.5+BDE (SC - потому что не было многопроцессорного SS) и теперь FB3+BDE (SC). А в FB3+BDE (SS) - не работают.
Из этого я делаю вывод, что в реализации SS в FB3 есть какие то серьезные отличия от него же в IB и что под SS наши программы работают не так как под SC.
Как диагностировать эту проблему со стороны приложения мы придумать не можем - потому, что проблемы возникают не при выполнении каких то действий программы, а через некоторое время стандартной работы программ при стандартной нагрузке. При этом под SS - проблемы есть. Под SC - нет.
С тем, что программы для использования с FB (SS) и c FB (SC) должны чем то серьезно отличаться я ранее не сталкивался.

Ivan_PisarevskyЛибо использовать ту конфигурацию сервера, которая работает
Ну собственно к этому пока и пришли.
Исходники, udf и программисты у нас разумеется есть :).
Но вариант полного рефакторинга базы на 4000 хранимых процедур и пропорциональное количество кода в приложениях не зная чего искать - не вариант. Чтобы что то найти надо или найти в какой момент оно происходит (а оно ни в какой не происходит - происходит в случайный момент по итогам полутора часов работы) или понять ЧТО ИМЕННО при стандартной работе с базой FB3 и BDE может приводить к тотальной загрузке процов под SS и не приводить под SC.

KreatorXXIВ режиме CS работа этого запроса не столь критична
Вот это у меня в голову и не влезает.
Я могу понять какой нибудь плохо написанный запрос, который условно говоря выполняется час и грузит на этот час проц. Но тогда в SC у нас все время были бы пользователи у которых зависает (падает) приложение (ну или не выполняется какая то функция). У нас таких нет.

kdvнебось у приложений с управлением транзакциями все настолько плохо, что принудительная сборка мусора на суперклассике работает, а фоновая на супере - тормозит...
что-то связанное со сборкой мусора и версиями. в SS она фоновая, в SC/CS - явная.
Спасибо. Мне тоже кажется, что это версия значительно более вероятная чем не какая то ошибка в конкретной процедуре или глючная UDF. Но дело в том, что у нас очень "дубовое" BDE-шное приложение. Явное управление транзакциями используется только для бизнес-логики (несколько запросов, которые не удается запихать в одну хранимую процедуру, вызываются в клиенте с явным вызовом StartTransaction и Commit). Во всех остальных случаях все работает как стандартный BDE-шный AUTOCOMMIT. Подход вероятно не оптимальный, но вроде как раньше был допустимым (для того же IB SS).
Но почему фоновая сборка мусора может не справляться? И нельзя ли с ней что то сделать?
И, да, в свое время, еще на IB, когда мы еще не отключали SWEEP, он запускаясь в течении дня тоже все вешал намертво.

Симонов Денис,
но если так, то меня вообще должен спасти SS c настройкой GCPolicy=cooperative? Если в таком режиме сборка мусора будет происходить аналогично тому, как у нас обычно в SC.

Всем спасибо. в особенности уважаемым kdv и Симонов Денис.
Данная проблема решена настройкой GCPolicy = cooperative
Ничего не виснет. Загрузка процов нормальная.