[ОТВЕТИТЬ]
28.08.2006 14:53
vdm
 
Spotlight уже несколько дней ругается на buffer busy waits (>95% в USERS, block class - data block) и вполне обоснованно - у юзеров в это время тормоза с отчетами, карточками и т.п.
Сходу решения проблемы не нашел.
Что в первую очередь смотреть?
28.08.2006 15:05
OlegON
 
Параметры памяти не перекрутил? В своп не сваливается? Посмотри, какой запрос у тебя тормозит. Диски не справляются. А может, db_block_buffers маленький совсем.
28.08.2006 17:50
vdm
 
Свопа не должно быть при макс. выделении памяти 2.4Гб, cвободной менее 500Мб не бывало.
db_block_buffers=90000, optimizer рекомендует 85000, также shared_pool_size=18000000 вместо 150000000, остальное "в норме"

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

Предположим память не перекрутил, buffer waits могут быть только из-за дисков?
28.08.2006 18:08
OlegON
 
Цитата:
vdm Свопа не должно быть при макс. выделении памяти 2.4Гб, cвободной менее 500Мб не бывало.
Не понял... Откуда цифра 2.4? Кто кому выделил? PAE+AWE? Или что?
Цитата:
vdm db_block_buffers=90000, optimizer рекомендует 85000, также shared_pool_size=18000000 вместо 150000000
Поставь на время 65000 и 100000000. Это событие достаточно скользкое, как правило, из-за высокого I/O. Если не знаешь, к чему приведет и зачем тебе это надо, зачем перекручиваешь?
28.08.2006 22:15
vdm
 
2.4 - это peak commit charge из виндового taskmgr, т.е. максимум что было в сумме по всем процессам

Зачем крутил - жалко гиг впустую пропадает *09
При увеличении block_buffers и pool_size есть связанные параметры, которые обязательно нужно подстраивать?
28.08.2006 23:31
OlegON
 
Почитай, мы тут про PAE уже несколько раз тему поднимали. Связанных параметров вроде нет, тебе хватит возни с подстройкой других, если встанешь на дорожку расширения физических адресов :)
29.08.2006 06:49
reddevil
 
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) - ищи эти самые блоки и применяй стандартные рекомендации в зависимости от версии СУБД.
29.08.2006 07:46
OlegON
 
Цитата:
reddevil 2. db_block_buffers=90000 при размере блока 8к нормальный размер для базы <100Г хотя зависит от типа базы и еще много чего.
При его параметрах почти полная уверенность в выходе за пределы памяти процесса или свопе.
29.08.2006 07:58
reddevil
 
900000*8=720m(BC)+18m(sp)~800m + еще всякая фигня для верности 200м ~1г
"2.4 - это peak commit charge " значит память у него >=3г и если выставлено /3GB то на PGA остается как миниму 1г.
Да и вообще разговор то не о том))) а автор что то молчит Ж:)
29.08.2006 18:23
vdm
 
Цитата:
reddevil 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) - ищи эти самые блоки и применяй стандартные рекомендации в зависимости от версии СУБД.
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....
29.08.2006 18:27
Mtirt
 
Дата последнего сбора статистики по SMCARD и SMSPEC?
29.08.2006 19:13
vdm
 
28.08
Кстати, это оказалось включено встроенное задание полного сбора статистики. Отключил.
29.08.2006 20:20
OlegON
 
Я предпочитаю встроенными заданиями не пользоваться, они слишком универсальны. Уж лучше оптимайзер пускать по планировщику. Видно, чем он занят.
30.08.2006 06:58
reddevil
 
olegon - "Я предпочитаю встроенными заданиями не пользоваться...." - улыбнуло))).

vdm
тип базы - магаз, офис, операт., серв отч.
control_files = ("E:\Oracle\oradata\DBPISH\control01.ctl", "E:\Oracle\oradata\DBPISH\control02.ctl", "E:\Oracle\oradata\DBPISH\control03.ctl") - для чего 3 копии на одном носителе?
если такое с контрольками то рискую преаоложить что нечто подобное и с редо т.е. члены одной группы на одном отказоустойчивом носителе?

над этим надо хорощо подумать
db_file_direct_io_count=128
db_file_multiblock_read_count = 32 - что за система ввода вывода?
если процессоров больще 2-ух (реальных) попорбуй db_writer_proccesses ну скажем 4
это все про buffer_busy

Сличительная ведомость и остатки по поставщикам это вообще -яд))
Им помогает установка optimizer_mode=rule ибо захинтованы по самы гланды (ну любят разробочика index scan и nested loops че тут сделать) и
/*+ INDEX_FFS(FFMapRep FFMapRep_Article) */ - это и есть нескончаемый dbfile sequential read (у себя я этот индекс грохнул совсем кстати)
optimizer_index_cost_adj=30 - могу ошибиться но кажется что не "рыба не мясо" или реально подставлять индексы <20 или уж не капать в мозг оптимизатору и оставить как есть.
30.08.2006 13:10
vdm
 
reddevil,
В типе базы поставь плюсы вместо запятых *08
При этом ВСЕ, система, oracle, база на 1-м raid1... кошмар *11
Но. Почему-то все это до определенного момента работало терпимо *05
Поэтому еще N винтов сразу не дадут.

Проц 1 P4 с HT и смысла трогать writer_processes не вижу.
optimizer еще раз прогнал, с индексами/статистикой все ровно.
30.08.2006 13:58
reddevil
 
"В типе базы поставь плюсы вместо запятых" - и магазин тоже? ухоснах

raid1 - а винтов то сколько? смотри диагностику контроллера и логи ОС твои bbw могут быть следствием каких либо проблем. Ищи твой определнный момент.

ну и по занятым блокам что нить пытался предпринимать?
30.08.2006 15:19
deucel
 
а HT у тебя включен???
если да то он у тебя не правильно расчитывает параметры
добавь:
cpu_count = 1
30.08.2006 19:49
vdm
 
reddevil,
Винтов аж 2 штуки.
С этой стороны все рабочее, ошибок, неисправностей нет.

По блокам - уткнувшись в freelist-ы пока шарахнулся в сторону.

deucel,
Да, HT включен, поставил cpu_count=1

Но ни это, ни rule остаткам по поставщикам не помогло.
Все те-же single block/sequential read

Кроме кручения памяти в последнее время единственное что делал - доп. файл в users добавил.
31.08.2006 06:23
reddevil
 
я конечно извиняюсь но "винтов аж 2 штуки" и "45г" база, то какое вы время ожидаете от остатков по поставщикам, выход видиться только на ночь оставлять авось к утру нарисуется.
от freelist-ов шарахаться не надо, надо добавить листов и групп также проверить initrans.
для сличилки outline можно забацать.
ну и ищем этот "определенный момент" до которого все работало - может изменение каких то параметров, удаление\сбор статистики, метод сбора, удаление\создание индексов их пригодность .....
31.08.2006 10:21
VivatSan
 
Наконец-то мой слабый разум посетила хоть одна мысль *03
каким чудом оно работало до сих пор...

У нас ежемесячно делалось закрытие периода в см2000 (требование бухгалтерии)
А сейчас уже неделю - все открыто, соответственно отчеты шарят по документам за год
31.08.2006 10:27
vdm
 
Упс
Чужой ник был *16
Опции темы


Часовой пояс GMT +3, время: 11:12.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.