http://ib-aid.com/en/articles/firebird-performance-degradation-tests-myths-and-truth/ for details you can look at SQL texts of actual stored proceduresТынц на них нужен (и на DDL таблиц)... В где он ?
И еще:
1) чего это так мало индексов ? Они PK'шки, и еще какой-то загадочный customer_last (с хреновой селективностью :))
2) скока часов шла молотьба над базой в 1.7 Тб ? я вижу, что в гигантской таблице order_lines всего 409 версий... Зело странно!
3) 20 коннектов - это не мало, а ОЧЕНЬ мало. ИМХО.
4) с каким firebird.conf шли тесты (что менялось в нём), что там с FW и page_size ? (хотя она, наверняка, 16 К?)

Alexey Kovyazinне читает смотрю никто, сразу смотрят на графики. :)Как раз на графики я меньше всего смотрел. Меня детальки и нюансики интересуют :-)
Надо бы DDL табличек и процедурки эти глянуть...
И что значит "умеренно плохой конфиг" ?

ЗЫ. Крикунов результатами молотьбы 20 аттачей не убедить. Это явно мало для сегодняшних реалий. Времена ларьков позади, мы уже несколько лет в эпохе гипермаркетов . Так что надо было бы на 200-300 коннектах проверять.

Alexey KovyazinА реально проблемы - в неграмотности.Не только. На сегодня мало средств, позволяющих докопаться до причин падения произв-сти.
Трейсом я могу отловить "проблемные запросы" (по порогу длительности их вып-я), но как понять, почему они тормозят ?
Ну да, я вижу в каком-то запросе хреновый план вып-я (вместо нужного индекса идёт по natural'у или еще хуже - вообще по другому индексу) - ну так что привело его к этому ? Перекошенные данные и отсутствие сведений об их распределении ? Или же просто оптимизатор "не допёр" до правильного плана ввиду навороченности запроса ?
Далее. Есть некий запрос, план тривиален (но с SORT), а выполняется долго. Трейсом вижу, что НЕТ никаких reads'ов и expung'ов, т.е. всё в страничном кеше. Чего он тогда клинит ? А оказывается, он вынужден делать сортировку по 200 полям (так надо по бЫзнес-логике, не избавиться от этого!) и выкидывает в своп. Т.е. просто TempCecheLimit'a не хватило. Но это никак не отражается в статистике!
Далее. Есть некие "тайные эвристики", не описанные в dataaccesspaths, и вообще нигде. Но влияющие на построение плана. Я говорю об inner-джойне "просто" таблицы и вьюхи, или derived-таблицы, DDL которой содержит group_by, например. Не зная этой грабли, можно запросто поиметь тормоза на всю голову.
И еще пример: вот есть таблица, на ней висит дюжина индексов. Кто их делал и для чего - нет сведений, "иных уж нет а те далече". Как понять, какой индекс *НЕ* используется в запросах, т.е. никогда не участвует ни в одном из создаваемых планов ? Да, я понимаю, что надо аудит запускать на неделю и смотреть потом. Но! его надо на ВСЕ запросы запускать, а не только на "проблемные" (свыше 1 сек, например). А такой аудит будет тормозить работу усеров (проверено!).