Ладно, поделюсь опытом в настройке субж для OLTP системы
Нужно "задирать" и INITRANS, и FREELISTS. В идеальном случае, оба они должны быть больше,
чем одновременно пишущих в базу процессов.
В случае, когда идут только изменения, а не вставки, то достаточно подымать INITRANS.
Кстати, FREELISTS поднять не пересоздав таблицу нельзя. А вот с FREELISTS GROUPS не игрался -- слишком тонкая штучка.

Но эти все рассуждения верны только в том случае, если процессы независимы. Если они могут друг друга блокировать, например пытаются выбрать max(keynum) из таблицы, куда потом будут вставлять запись, то субж тебе не помошник.

И заранее -- дальше ты столкнёшься с тем, что у тебя rollback не хватает, и v$rollstat.waits растёт семимильными шагами. Потом начнёшь делить индексы и таблицы по разным дискам, параллельно думая, а как мне уменьшить число индексов с 15 до хотя бы 10
В общем, та ещё развлекуха.

Кстати, если общий объём базы меньше чем block_buffers*block_size, то жизнь становится ещё веселее. Кстати, надеюсь сервер не пытается каждый раз парсить запрос???

P.S. Любимое дело ждать "LOCK FOR UPDATE", если приложение плохо спроектированно.

Кстати, советую всем сходить по прилагаемой ссылке: очень полезная штука -- этакий рекламный проспект, куда глядеть, если всё вроде хорошо, а опыта в тонкой настройке Оракула нету.

"http://www.njoug.org/Optimizing Update Intensive Tables Using Wait Events - 1.ppt"