[ОТВЕТИТЬ]
03.10.2006 05:09
isi
 
SM 1.0.24.5 sp5 + oracle 9.2.0.7 БД около 50 Гб файлы БД на RAID10, сервер 2 двухядерных проца AMD

Все операции супермага работают отлично, кроме отчетов, которые исполбзуют таблицы расчета тавародвижения (FF......), Себестоимость считается 1,5 часа против 6 на Oracle 8 (ну и сервак послабже был).

Все параметры БД выставлены по рекомендациям Optimizera от Olegon. и база прогнана оптимизатором неоднократно.

При просмотре ожиданий очень большой показатель в db file sequential read, это если я понимаю, ожидания чтения с диска. Так как опыта немного прошу консультации что посмотреть и где порыть
03.10.2006 07:27
reddevil
 
1. FFMAPREP - секционированная?
2. OPTIMIZER_INDEX_COST_ADJ сколько?
3. План вот этого "SELECT SUM(SALESUM) from FVMAPREP where saledate between 'ДАТЫ ТВОИХ ОТЧЕТОВ'"
4. Каким способом собрана статистика
5. Сколько дисков в рейде?
6. Степень паралелизма FFMAPREp и FFMAPREP_
03.10.2006 10:01
isi
 
1. Нет
2. OPTIMIZER_INDEX_COST_ADJ = 30
3.
Код:
SELECT STATEMENT Optimizer Mode=CHOOSE		
  SORT AGGREGATE		
    VIEW		
      UNION-ALL		  	 	 	 	      	             	 
        FILTER		  	 	 	 	      	             	 
          TABLE ACCESS BY INDEX ROWID	SUPERMAG.FFMAPREP	
            INDEX RANGE SCAN	SUPERMAG.FFMAPREP_SALEDATE	
        FILTER		  	 	 	 	      	
          TABLE ACCESS BY INDEX ROWID	SUPERMAG.FFMAPREP_	
            INDEX RANGE SCAN	SUPERMAG.FFMAPREP_SALEDATE_
4. Optimizerom от Olegon. видимо dbms_stats
5. 5 дисков
6. Это как определить?
03.10.2006 10:29
OlegON
 
4. скорее всего compute statistics, из-за багов dbms_stats я от него отказался.
03.10.2006 10:32
reddevil
 
Цитата:
olegon 4. скорее всего compute statistics, из-за багов dbms_stats я от него отказался.
+1 я правда пока не понял в каких случуях она хуже
03.10.2006 10:37
reddevil
 
изя
1. Задумайся! при 50 гигах уже можно.
3. TABLE ACCESS BY INDEX ROWID SUPERMAG.FFMAPREP - кардинальность и период естественно)))
5. Это как? Или просто один из дисков массива в сбойном режиме?)))
6.select t.table_name, t.degree from all_tables t where t.owner='SUPERMAG' and t.table_name like 'FFMAPREP%'
03.10.2006 10:39
reddevil
 
7. пересоздай FF% с опцией COMPRESS
03.10.2006 10:59
isi
 
3. по 3 соврал, запускас с параметрами а не с реальными датами:
Код:
Operation	Object Name	Rows	Bytes	Cost	Object Node	In/Out	PStart	PStop

SELECT STATEMENT Optimizer Mode=CHOOSE		1  	 	24593  	 	      	             	 
  SORT AGGREGATE		1  	22  	 	 	      	             	 
    VIEW		5 M	121 M	24593  	 	      	             	 
      UNION-ALL		  	 	 	 	      	             	 
        TABLE ACCESS FULL	SUPERMAG.FFMAPREP	5 M	72 M	24592  	 	      	             	 
        TABLE ACCESS BY INDEX ROWID	SUPERMAG.FFMAPREP_	1  	22  	1  	 	      	             	 
          INDEX RANGE SCAN	SUPERMAG.FFMAPREP_SALEDATE_	1
Видимо из за TABLE ACCESS FULL, как от этого избавиться ?


5. можно упустить?, это сисадмин сказал, я в этом не разбирался, просто спросил. Если надо будет, позанимаюсь...

6.
TABLE_NAME DEGREE
FFMAPREP 1
FFMAPREP_ 1
03.10.2006 11:00
OlegON
 
Цитата:
reddevil 6. Степень паралелизма FFMAPREp и FFMAPREP_
Кстати, твои рекомендации насчет этого и parallel_max_servers?
03.10.2006 11:02
isi
 
а на счет 7. оптимайзером от olegon делал
03.10.2006 11:03
OlegON
 
Цитата:
isi а на счет 7. оптимайзером от olegon делал
Оно по умолчанию отключено, после того, как некоторые на Standart-инсталляции начали компрессить... И все падать начало. Если не ошибаюсь, на включение - /enterprise
03.10.2006 11:05
isi
 
ок, сделаю, я думал ключ /optimize это делает
03.10.2006 11:24
reddevil
 
3. Сколько дней период все таки?
5. если райд 1+0 то дисков должно быть четное число!!! 5 дисков может быть либо рэйд 0 или 5 или 50
6.по паралелизму степень AVG(CPU, число шпинделей), parallel_max_servers CPU*число шпинделей(естественно все это при CPU >=2)
03.10.2006 11:31
isi
 
3. 180 дней примерно
5. четыре винта и на рейде сконфигурированно если один сдохнет то этот пятый его автоматом заменит
03.10.2006 11:34
isi
 
т.е. мои действия дальше alter ... compress и compute statistics
03.10.2006 11:37
reddevil
 
create as select ....
drop ......
create compress....
03.10.2006 11:42
isi
 
спасибо за наставление на путь истинный, вечером займусь...
03.10.2006 11:44
reddevil
 
сдается мне что за полгода - FULL SCAN будет быстрей чем индекс, так что план строиться нормально.
Надо рыть ы другую сторону- параметры хранения в 8 и в 9 совпадают?
ну парелелизм и компрессию посмотри
03.10.2006 11:49
isi
 
Есть ощущение, что план исполнения не стабильный, за два дня несколько раз поаторялась ситуация когда отчеты то летают, то за всесь день не выполняются, смотрел с вечера план запроса визуально в DBA тормоза были в БД, утром пришел, явно другой план и скорость нормальная, в понедельник с самого утра (было 3 пользователя в бд) тормоза опять
03.10.2006 11:55
isi
 
Цитата:
reddevil сдается мне что за полгода - FULL SCAN будет быстрей чем индекс, так что план строиться нормально.
Надо рыть ы другую сторону- параметры хранения в 8 и в 9 совпадают?
ну парелелизм и компрессию посмотри
за месяц тоже FULL SCAN, по индексу начинает использоваться только меньше 5 дней
04.10.2006 04:05
isi
 
Индексы и таблицу пересоздал с Compress, после расчета статистики все равно идет Full Scan даже за маленький период, удалил статистику с таблицы, пошел по индексу и все прекрасно стало работать, но не всем отчетам по FFMAPREP это помогло *11
09.10.2006 06:22
isi
 
- лог оптимизатора olegon
Таблицы пересозданы с опцией move compress
индексы пересозданы с rebuild compress
Статистика по таблицам расчитана
имею тормоза с отчетами
Подскажите что ещё можно проверить?

запрос типа
Код:
SELECT EVENT,
       AVERAGE_WAIT
FROM   V$SYSTEM_EVENT
WHERE  EVENT LIKE 'db file s%'
возвращает:
db file sequential read 1
db file scattered read 2

Значит ли что мне нужно установить параметр OPTIMIZER_INDEX_COST_ADJ = 50?
09.10.2006 10:06
isi
 
Помогите разобраться...
09.10.2006 10:11
OlegON
 
Давай тогда ловить конкретный запрос? Что тормозит? И каким местом (проц/винт)?
09.10.2006 10:19
isi
 
например, как предлагал reddevil:

SELECT SUM(SALESUM) from FVMAPREP where saledate between '01.10.2006' and '09.10.2006' выполняется более 10 минут.

Конфигурацию повторюсь 2 двухядерных AMD, 4 ГБ памяти, raid 5 (2x2+1 резерв для замены одного из вышедших из строя)

План запроса привести? и здесь лог оптимизатора.
09.10.2006 10:20
isi
 
вот его план запроса:

Код:
Operation	Object Name	Rows	Bytes	Cost	Object Node	In/Out	PStart	PStop

SELECT STATEMENT Optimizer Mode=CHOOSE		1  	 	17605  	 	      	             	 
  SORT AGGREGATE		1  	22  	 	 	      	             	 
    VIEW		257 K	5 M	17605  	 	      	             	 
      UNION-ALL		  	 	 	 	      	             	 
        TABLE ACCESS BY INDEX ROWID	SUPERMAG.FFMAPREP	257 K	2 M	17604  	 	      	             	 
          INDEX RANGE SCAN	SUPERMAG.FFMAPREP_SALEDATE	257 K	 	687  	 	      	             	 
        TABLE ACCESS BY INDEX ROWID	SUPERMAG.FFMAPREP_	1  	22  	1  	 	      	             	 
          INDEX RANGE SCAN	SUPERMAG.FFMAPREP_SALEDATE_	1
09.10.2006 10:22
isi
 
ещё если собрать статистику по таблице FFMAPREP, запросы начинают выполняться ещё намного дольше , при этом по FFMAPREP fullscan, поэтому сейчас статистику удалил
09.10.2006 10:32
OlegON
 
Это не лог оптимизатора. Ты его даже не запускал, не говоря уж о моем недоверии к тексту. А вот с конфигурацией ты попал... Зачем тебе AMD сдался? И машина загаженная...
09.10.2006 10:34
isi
 
это я собрал сведеня о настройках БД.
я его сегодня в ночь запускал с параметром /optimize. отработал нормально, сругался на пару пакетов от TOAD, а в остальном все нормально
09.10.2006 10:34
isi
 
что в ней загаженного? и в чем проблема с AMD может быть?


Опции темы


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

 

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