Buffer busy waits : Oracle

Spotlight уже несколько дней ругается на buffer busy waits (>95% в USERS, block class - data block) и вполне обоснованно - у юзеров в это время тормоза с отчетами, карточками и т.п.
Сходу решения проблемы не нашел.
Что в первую очередь смотреть?

Параметры памяти не перекрутил? В своп не сваливается? Посмотри, какой запрос у тебя тормозит. Диски не справляются. А может, db_block_buffers маленький совсем.

Свопа не должно быть при макс. выделении памяти 2.4Гб, cвободной менее 500Мб не бывало.
db_block_buffers=90000, optimizer рекомендует 85000, также shared_pool_size=18000000 вместо 150000000, остальное "в норме"

Параметров висящей сейчас сессии отчета от spotlight что-то не дождаться.

Предположим память не перекрутил, buffer waits могут быть только из-за дисков?

Не понял... Откуда цифра 2.4? Кто кому выделил? PAE+AWE? Или что?
Поставь на время 65000 и 100000000. Это событие достаточно скользкое, как правило, из-за высокого I/O. Если не знаешь, к чему приведет и зачем тебе это надо, зачем перекручиваешь?

2.4 - это peak commit charge из виндового taskmgr, т.е. максимум что было в сумме по всем процессам

Зачем крутил - жалко гиг впустую пропадает
При увеличении block_buffers и pool_size есть связанные параметры, которые обязательно нужно подстраивать?

Почитай, мы тут про PAE уже несколько раз тему поднимали. Связанных параметров вроде нет, тебе хватит возни с подстройкой других, если встанешь на дорожку расширения физических адресов :)

1. 2.4 - это peak commit charge из виндового taskmgr - еще ни истина в последней инстанции.
2. db_block_buffers=90000 при размере блока 8к нормальный размер для базы <100Г хотя зависит от типа базы и еще много чего.
3. shared_pool_size=18м не мало? какой процент использования? и сколько пользователей? (хотя в данном случае это может и не в кассу, но тем не менее)
4.buffer busy waits (>95% в USERS, block class - data block) - ищи эти самые блоки и применяй стандартные рекомендации в зависимости от версии СУБД.

При его параметрах почти полная уверенность в выходе за пределы памяти процесса или свопе.

900000*8=720m(BC)+18m(sp)~800m + еще всякая фигня для верности 200м ~1г
"2.4 - это peak commit charge " значит память у него >=3г и если выставлено /3GB то на PGA остается как миниму 1г.
Да и вообще разговор то не о том))) а автор что то молчит Ж:)

1) Чему нужно верить больше, чем taskmgr ?
По поводу свопа - не видел paged pool больше 300Кб для процесса oracle (taskmgr *16 )

2) Пользователей в среднем 20-35
RAM 4Гб, /3Gb
База 45Гб, 8Кб (что значит тип базы.... 8.1.6, см2000 1024sp5)

shared_pool_size был 180, а не 18м, сейчас 105, используется 60-80%

Если интересно подробнее - .ini
compatible = 8.1.6
db_files = 1024
control_files = ("E:\Oracle\oradata\DBPISH\control01.ctl", "E:\Oracle\oradata\DBPISH\control02.ctl", "E:\Oracle\oradata\DBPISH\control03.ctl")
db_file_direct_io_count=128
db_file_multiblock_read_count = 32
db_block_buffers = 90000
db_block_size = 8192

open_cursors = 100
session_cached_cursors = 30
max_enabled_roles = 30

shared_pool_size = 110000000
large_pool_size = 1228800
java_pool_size = 0

log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
log_buffer = 10485760

processes = 170
sessions = 210
distributed_transactions = 10
max_rollback_segments=99
timed_statistics = true

optimizer_index_caching=90
optimizer_index_cost_adj=30
sort_area_size = 8388608
sort_area_retained_size = 4194304

job_queue_processes=3
job_queue_interval=600

background_dump_dest = E:\Oracle\admin\DBPISH\bdump
user_dump_dest = E:\Oracle\admin\DBPISH\udump
max_dump_file_size = 10240

Тормозит все что связано с остатками, отчет 'остатки по поставщикам' - вообще не работает, остатки в инвентаризационной описи считал час.

А где в spotlight-e самый долго выполняющийся запрос - не вижу *18

из висящего отчета по остаткам в Session information/Open SQL последнее:

SELECT /*+ INDEX(FFMapRep FFMapRep_SaleDate) */COUNT(*)
FROM FFMAPREP
WHERE SALEDATE BETWEEN :b1 AND :b2
SELECT /*+ INDEX_FFS(FFMapRep FFMapRep_Article) */COUNT(*)
FROM FFMAPREP

а в Session details:
waitig for: db file sequential read, SUPERMAG.FFMAPREP (95% - single block read)
Most recent SQL:
INSERT INTO TTRemIncome ( StoreLoc, Article, DocId, DocType, SpecItem, GoodsOwner, ClientIndex, VATRate, DocQuantity, DocSum, DocSumNoVAT, Forced, Quantity )( SELECT StoreLoc, Article, IncomeId, IncomeType, IncomeSpecItem, max(GoodsOwner) GoodsOwner, max(IncomeClientIndex) ClientIndex, max(IncomeVatRate) VatRate, max(IncomeQ) DocQuantity, max(IncomeSum) DocSum, max(IncomeNoVat) DocSumNoVat, ForcedMapping, sum(Quantity) Quantity
FROM ( SELECT /*+ ORDERED USE_NL(S,A) FULL(A) FULL(M.U_MapRep.FFMapRep) */ SaleLocationTo StoreLoc, Article, IncomeId, IncomeType, IncomeSpecItem, GoodsOwner, IncomeClientIndex, IncomeVatRate, IncomeQ, IncomeSum, IncomeNoVat, ForcedMapping, Quantity
FROM FVMapRep
WHERE SaleDate between :i_Start and :i_Stop and SaleLocationTo =2 and SaleLocationTo is not NULL UNION ALL SELECT /*+ ORDERED USE_NL(S,A) FULL(A) FULL(M.U_MapRep.FFMapRep) */ SaleLocationFrom StoreLoc, Article, IncomeId, IncomeType, IncomeSpecItem, GoodsOwner, IncomeClientIndex, IncomeVatRate, IncomeQ, IncomeSum, IncomeNoVat, ForcedMapping, -Quantity
FROM FVMapRep
WHERE SaleDate between :i_Start and :i_Stop and SaleLocationFrom =2 and SaleLocationFrom is not NULL )
GROUP BY StoreLoc, Article, IncomeId, IncomeType, IncomeSpecItem, ForcedMapping HAVING ROUND(sum(Quantity),3) <> 0 )

Вчера ночью optimizer прогонял - ничего кроме предупреждений на buffers/pool не было.
Сегодня buffer busy waits было меньше, зато всяческих db file read....