2 guest:

-- vo pervih kak sovetoval dba namnogo prosche i TOCHEE zapustit trassirovku dlia sessii.
poscolku file trassirovki sam po sebe TEHNICHESKIY DOKUMENT, kotoriy mogno predyavit
razrabotchikam.

2 Vladimir
-- razrabotchikov v etoi situacii, esli ug poshla takaya pianka, mogno zadavit sovershenno formalno.
(no companiya dolgna resitsia na eto).
1) vidvigalis li razrabotchikami tehnicheskie trebobaniya k parametram bazi dannih.
-- esly da - sopostavit s realnimi paarametrami v kotorih rabota vozmogna
-- esli ne - (eto imteresnee) - togda na testovoi baze ogranichit resursi kak tolko mogno (vkluchaiya RBS)
i zapustit prilogenie s nagruzkoy
esli ono zavalitsia ili ne budet udovletvoriat vremennim harakteristikam ili escho kakim libo predvaritelno zaiyavlennim v dogovore trebovaniyam to:
a) razrabotchiki ne vipolnili trebovaniya ishodnogo dogovora.
b) eto est osnovanie dliya davleniya na nih po povodu ispravleniya situacii (vkluchaya situaciu s RBS)

Razmer RBS NIKOGDA NE ZAVILIT ot kolichestva userov.
TOLKO I ISKLUCHITELNO ot kolichestva i razmera TRANZAKCIY.
(vne zavisimosty ot razmera baza i connectov)

1) Pocemu v razgovore s razrabotchikami kolichestvo i razmer tranzakciy est predmet obsuzdeniya.
2) v sluchae nalichiya dolgoigrauschih tranzakciy pridmetom obsugdeniya moget bit ih tip:
-- obichanaya
-- read only
-- serializaciya
t.k. etot tip moget SUSCHESTVENNO vliyat na razmer, kolichestvo, i vreamya aktivnoy gizni opredelennogo ili vseh
(za isklucheniem system) RBS.
3) v sluchae esli nalichie dlinnoy (bez serrializacii) tranzakcii izvestno vo vremya razrabotki,
a eto kak pravilo izvestno, to v skripte na sozdanie bazi (v tom chisle i osobenno dlia tipovih resheniy)
OBIYAZAN bit sosdan specialniy RBS dlia dannoy(h) tranzakcii i on dolgen naznachatsia komandoy
(SET TRANSACTION USE ROLLBACK SEGMENT ...).
sudya po vsemu imenno eto ne bilo sdelano.

V sluchae serrializacionnih tranzakciy:
-- p.3 ostaesya v sile +
-- dolgno bit opredeleno :
a) vremya gizni (v srednem) serrializacionnih tranzakciy
b) kolichestvo ostalnih RBS * srednee kolichestvo tranzakziy v ed. vremeny * vremya serrializacionnih tranzakciy.

Можно нескромный вопрос: А где этому учили?
Если подобные данные относятся к какой-то конкретной задаче при условии вполне
опереленного размера кажной транзакции (в среднем) может быть эти данные
и имеют смысл для данного приложения только.

В общем случае никакого реального смысла эта информация не несет. Так цифры взятые с потолка.
Как я (в общем случае и коротко) планирую сегменты отката, если характер
работы приложения заранее неизвестен.

1) Оценивается среднее коннектов к базе в единицу времени.
2) По результатам анализа статистики ка какой-то более менее длительный промежуток времени
оценивается :
-- количестро транзакций в ед. времени (v$sysstat(commit_cummulative) + v$sysstat(rollback_cummulative))
-- объем redo log за этот же период v$sysstat( redo_size )
(это конечно не точно соответствует rollback но позволяет оценит средний размер
транзакций, которые могут генерить RBS)
-- далее планируются "ожидаемые по статистике" RBS
а) размер каждого экстента RBS не менее чем = 2.5 * размер redo на среднюю транзакцию
б) количество rbs * OPTIMAL количество экстентов ~ = среднему количеству коннектов + 25-50%
-- далее планируется "Прикрытие Ж.." в случае неожиданно длинных транзакций
которым назначается случайный rbs.

как сие делается:
-- rbs создается в два этапа (по storage parametres):
1 - create rolback segment ...
... storage ( initial /* 2.5 * redo_на_транзакцию */
next /* 2.5 * redo_на_транзакцию */
minextents /* кол_tras / кол_rbs */
optimal /* исходя из кол_tras / кол_rbs + 25%-50% */

2. alter rolback segment ...
изменяю next
next /* 5-10 MB не менее */

Что этим достигается:
-- при "средней" работе все коннекты обеспечены "своими RBS" и у нас нет "дорогих операций" по выделению / освобождению экстентов под rbs
-- если уж нарвались на длинную транзакцию тут уж не жиру, отдавай память сразу
и как можно больше. Она все равно потом сожмется до OPTIMAL c размером ~ соответствующим средней транзакции.

Так что на курсах только мозги пудрили. Но это мое личное мнение.

Да совсем забыл.
Через некоторое время снимается wait статистика по rbs.
При этом отдельно по rbs и отдельно по заголовкам rbs.
Исходя из данных этой статистики перераспределяется количество rbs и размер
OPTIMAL для каждого из них с тем чтобы мимнимизировать конкуренцию за заголовки.