Мы обследовали проблемы с производительностью и архитектурой приложения
у одного из клиентов:
1 общее описание архитектуры системы :
-- 2 sun 450 сервера (Solaris 7)
-- #1 сервер сервер приложений Web Logic
-- #2 Oracle server 8.1.7.0.0 (без патчей)
-- приложение использует EJB 1.1 с Entity beans consistent manage precistent
!!! это основная проблема поскольку:
-- генерируется жуткое количество SQL запросов (до 2500 на каждый клик в броузере)
сами запросы достаточно оптимизированы.
-- большинство Select идут с FOR UPDATE без всякой нужды.
-- справочные таблицы достаточно маленькие и FOR UPDATE блокирует практически
все строки, которые нужны соседней сессии
-------------------------------------------------------------
Я предложил:
1) применить ON LOGON триггер с тем, чтобы повысить
уровень блокировки до SERIALIZABLE или READ COMMITTED
В этом случае Oracle будет применять блокировку 1 раз а не 2000

2) разбить всю схему (если это возможно) на 2 части только-чтение и чтение-запись .
положить таблицы только-на-чтение в read-only tablespace
Вопрос -- для SELECT ... FOR UPDATE отменяет блокировку для таблиц в read-only tablespace?

ВОПРОС 2: есть ли какие-либо еще идеи.
ТЕКСТ ПРИЛОЖЕНИЯ ТРОГАТЬ НЕЛЬЗЯ.

2 softbuilder@inbox.ru

Для больших таблиц SELECT.....FOR UPDATE не представляло bottleneck т.к. блокировались
разные записи, для справочных таблиц блокировались одни и теже записи, поскольку тестировалась
работа с одними и темеже экранными формами.
"Вообще блокировать с помощью SELECT .... FOR UPDATE более одной группы логически связанных записей - не имеет смысла."
-- ВООБЩЕ ИСПОЛЬЗОВАНИЕ ENTITY BEANS ПРИ РАБОТЕ С ORACLE НЕ ИМЕЕТ СМЫСЛА, НО ЭТО ДАННОСТЬ.
Генерация SQL предложений в ENTITY BEANS EJB 1.1 не зависит от прогрпммиста,
это выполняе EJB слой автоматически и ОЧЕНЬ ПЛОХО.

2 .dba
Я специально писал скрипты, которые снимали статистики с SQL area и sys/ses stat по сессиям до кликов на броузере и после.
Все выполнялось в тестовом окружении и я знал что другие сессии не мешаются.

Poskolku
-- production nelzia bilo trogat
-- ni na production ni na test ne bil ustanovlen stat_pack
(tam voobche nichego ne bilo vkluchaiy dba kak klass, i analize tables vipolnialsya pol goda nazad) -- rezultati ostalis u klienta, nam ih ne dali uvesti
-- posemu, libo priydetsia verit na slovo, libo ne uchastvovat v obsuzdenii

VOPROSI BILI (i ih povtoru)
1) v sluchae esli table razmeschena v rea-only tablespace Oracle budet otmeniat ... FOR UPDATE ili net?
2) kakie escho est idei po borbe s WELL KNOWN PROBLEM specifikacii ejb 1.1 dlia Entity beans consistent manage precistent
pomimo perechislennich v 1 poste

K sozaleniu baza dannih okazalas ORACLE.

Esli ne trogat kod prilogeniya to i ocenivaiu maksimalniy viigrish ne bolee 20-30% (eto bilo bi ochen horosho)
no suschestvuiut voprosi:
1) v sluche povisheniya urobnya default bolkirovki do (SERIALIZABLE / READ COMMITTED)
mi ne smogli ocenit realnuiu chastotu commit na production (ne pustili)
esli chastota commit dostatochno visokaya to mi tolko ugrobim proizvoditelnost
2) nikto ne moget skazat kakie tablici mogut bit obyavleny read-only.

nam dali statistiku uvelicheniya vremeny otklika s production pri uvelichenn kolichestva odnovremennih sessiy

1 - 2.05 min
5 - ~5 min
20 - 15-17 min

za schet obchego tuninga (sort_area, db cache, shared poll, indexes ...) udalos viigrat ~ 25%-30%, no ne bolee
dva vishe perechislennich potencialnih resheniya yavlautsya v obschem sluchae spornimi (prichina poscemu oni na forume)
i oni escho ne primenialis

kardinalnim resheniem yavlyaetsya POLNIY REDISIGN PRILOGENIYA
(otkaz ot Entity beans i perechod na Session bean naprimer, esli uz bez java net gizni)
i kazetsya klient eto ponial
No on ne gotov ostanovit prilozenie priamo seychas - nu eto poniatno

2 dba
v etoi situacii neskolko promahnulsia
perepisivat budut ih sobstvennie programmery.

dopolnenie.
oni sobstvenno eto i napisali

Eto pravilno: "деньги за анализ все равно платятся" kak i za vsiakuyu druguyu rabotu.

No mi ushli ot konkretnich voprosov.

Po povodu za chto dengi platiat, anegdot rasskazat:

" #2 Oracle server 8.1.7.0.0 (без патчей) 2GB memory (+ ~ 1GB v swap)"
-- 80 % etoy pamiaty FREE poskolku:
--------------------------------------------------
shared memory = 700MB (v devicated server mode!!!)
sort_area_size = 40MB (pri sredney dline sortiuemoy viborki ~ 100 strok, maksimalnoy nemnogo > 3000)
otkrito i postoiann dergitsia WedLogic 40 sessiy
large memory = 100MB(v devicated server mode!!!)
maksimalnoe kolichestvo sessiy ocenivaetcia kak 50 srednee 20
-------------------------------------------------
kak anegdot.
vot za eto i dengi platiat.

2 killed

в общем идея размазать справочники на бльшее количество блоков смотрится как
весьма полезная.
поскольку для справочников :

-- full scan table практически никогда не применяется
-- индексы останутся теми-же и значит сохранится связка index by unique + table by rowid

то производительность отдельных запросов не должна ухудшиться
а ожидание buffer waits по идее должно уменшиться пропорционально (или близко)
к увеличению параметра pctfree для справочников.
Это надо пробовать.
Спасибо.

Но с глубокому моему сожалению это все не уменьшит 2500 selects на каждый клик,
а только слегка снизит конкуренцию между сессиями.