Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 помогите оптимизировать insert  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
Всем привет.


RAC 11.2.0.3.0


SQL ID: fjybdrzhsdfjr
Plan Hash: 2705196338
UPDATE ORDERS PARTITION(ORDERS_MAX) SET ORD_GR_ID = :B1 
WHERE
 SETTLEMENT_ID IS NULL AND ORD_GR_ID IN (SELECT COLUMN_VALUE FROM TABLE ( :B2 
  ) )


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     19      0.83       7.24        272       4425      54322        7462
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       20      0.83       7.24        272       4425      54322        7462

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 63     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  UPDATE  ORDERS (cr=30 pr=4 pw=0 time=414634 us)
      9   NESTED LOOPS  (cr=20 pr=0 pw=0 time=953 us)
      9    NESTED LOOPS  (cr=11 pr=0 pw=0 time=534 us cost=33 size=12 card=1)
      2     SORT UNIQUE (cr=0 pr=0 pw=0 time=45 us cost=29 size=4 card=2)
      2      COLLECTION ITERATOR PICKLER FETCH (cr=0 pr=0 pw=0 time=13 us cost=29 size=4 card=2)
      9     PARTITION RANGE ITERATOR PARTITION: KEY KEY (cr=11 pr=0 pw=0 time=618 us cost=2 size=0 card=1)
      9      INDEX RANGE SCAN ORDER_IDX1 PARTITION: KEY KEY (cr=11 pr=0 pw=0 time=591 us cost=2 size=0 card=1)(object id 2772506)
      9    TABLE ACCESS BY GLOBAL INDEX ROWID ORDERS PARTITION: ROW LOCATION ROW LOCATION (cr=9 pr=0 pw=0 time=342 us cost=3 size=10 card=1)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  library cache pin                               3        0.00          0.00
  library cache lock                              2        0.00          0.00
  gc current grant 2-way                        725        0.00          0.19
  Disk file operations I/O                        3        0.00          0.00
  gc current block 2-way                         25        0.00          0.00
  db file sequential read                       272        0.24          5.12
  gc current grant busy                         132        0.00          0.04
  gc cr block congested                           1        0.00          0.00
  gc cr block 2-way                              18        0.00          0.00
  gc current grant congested                      9        0.00          0.00
  gc buffer busy release                          3        0.63          0.64
  gc current block busy                           2        0.00          0.00
  latch: cache buffers lru chain                  4        0.00          0.00
  gc cr grant 2-way                               4        0.00          0.00
  latch: object queue header operation            1        0.00          0.00
********************************************************************************

на поле которое абдейтиться (ORD_GR_ID) есть глобальный индекс:

CREATE INDEX "ORDER_IDX1" ON "ORDERS" ("ORD_GR_ID")
GLOBAL PARTITION BY RANGE ("ORD_GR_ID")
(PARTITION "ORD_IDX1_LS_10M" VALUES LESS THAN (10000000) ,
PARTITION "ORD_IDX1_LS_20M" VALUES LESS THAN (20000000) ,
....
);

новое значение для абдейта берется из сиквенса и добавляется в конец индекса.
Сама таблица активно заполняется балковыми INSERTами (обычно 1 сессия, маловероятно что несколько но в любом случае не более нескольких штук).

Абдейт раниться с одной сессии (джобом 1 раз в 5 мин).

Посмотрел по трейсу какие объекты читает "db file sequential read" - выяснил что более 90% приходиться на UNDO таблспейс.

Помогите плиз правильно трактовать трейс?

1. Не пойму почему так много блоков в режиме current=54322 по сравнению с query=4425. Получается что для получение согласованного по чтению снимка на начало абдейта нужно было query=4425 блоков, а чтобы их проабдейтить current=54322). Это что добавилось сгенеренное UNDO и REDO, или они в это число не входят ?

2. правильно ли я понимаю, что физическое чтение редо могло быть только на этапе query и могло быть вызвано только тем, что другая сессия абдейтила блоки во время абдейта? Хотя по плану физ. чтения появились на шаге абдейта, а не на этапе доступа к таблице. Можно ли как-то уменьшить кол-во читаемых блоков с редо? Думаю что это были блоки индекса, т.к. он пишет новые значения в конец, и новые вставки идут в конец.


Спасибо.
26 ноя 15, 18:58    [18477852]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 5151
niv76,

Чтоб обновить строки Оракл сначала должен получить необходимые consistent версии для конкретной сессии/scn для применения фильтра,
а потом обновить необходимые current блоки.
Неудивительно, что для получения согласованной версии он идет в undo.
Немного про механизм - Consistent Gets – 2.

PS. Лучше уж update называть insert как в заголовке чем "Абдейт". Это ппц.
26 ноя 15, 20:22    [18478266]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
ora601
Member

Откуда:
Сообщений: 750
niv76,
Тюнь db_file_sequential_reads, надо остальными моментами можешь не заморачиваться, это стандартное поведение. Количество current gets всегда будет больше чем consistent обновляемых блоков. Если взять обьяснение Кайта : https://asktom.oracle.com/pls/asktom/f?p=100:11:1246473491052725::::P11_QUESTION_ID:878847787577

То примерный механизм delete ну или update is :
  for x in ( select rowid from emp )   --- CONSISTENT GETS
  loop
     delete from emp where rowid = x.rowid;  --- CURRENT MODE GETS
  end loop;


А значит количество current mode gets будет равно количеству обновляемых строк.


З.Ы. redo не измеряеться в блоках (а в entries/size) и не читается при DML.
26 ноя 15, 22:30    [18478734]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
Спасибо.

Еще вопрос. Выяснил что у нас эту таблицу модифицируют две процедуры в двух сессиях. Чтобы избавиться от чтения UNDO добавил в них DBMS_LOCK вызовы, чтобы они одновременно не выполнялись . Чтобы одна ждала пока закомитит другая, и только потом стартовала сам. Но ничего от этого не поменялось.
Все равно примерно тоже кол-во сиквеншинал ридов (более 90% по UNDO сегменту).

Из-за чего это может быть? Если никто с момента старта запроса не менял блоки, значит лезть в сегмент отката не зачем, или я чего-то не понимаю?
Напомню что у нас RAC и вокруг этих колов много ивентов gc current grant busy и gc current block 2-way. Может как-то связано....

Спасибо.

Вот типичный кусок трейса и полный трейс в атаче:

file#=2 - смотрит на UNDO таблспейс.

WAIT #140594070557496: nam='gc current grant busy' ela= 177 p1=104 p2=10477145 p3=33619969 obj#=52958 tim=1448892099105558
WAIT #140594070557496: nam='gc current block 2-way' ela= 193 p1=104 p2=10490212 p3=33554433 obj#=2772521 tim=1448892099106006
WAIT #140594070557496: nam='gc current block 2-way' ela= 184 p1=52 p2=19832 p3=16777217 obj#=2723413 tim=1448892099106361
WAIT #140594070557496: nam='gc current grant busy' ela= 157 p1=104 p2=10477477 p3=33619969 obj#=52958 tim=1448892099106676
WAIT #140594070557496: nam='gc current grant busy' ela= 147 p1=104 p2=10477480 p3=33619969 obj#=52958 tim=1448892099107014
WAIT #140594070557496: nam='db file sequential read' ela= 600 file#=2 block#=1322 blocks=1 obj#=0 tim=1448892099107847
WAIT #140594070557496: nam='gc current grant busy' ela= 159 p1=104 p2=10477496 p3=33619969 obj#=52958 tim=1448892099108322
WAIT #140594070557496: nam='gc current grant busy' ela= 216 p1=104 p2=10477504 p3=33619969 obj#=52958 tim=1448892099108726
WAIT #140594070557496: nam='gc current grant busy' ela= 207 p1=104 p2=10477510 p3=33619969 obj#=52958 tim=1448892099109110
WAIT #140594070557496: nam='gc current grant busy' ela= 147 p1=104 p2=10477511 p3=33619969 obj#=52958 tim=1448892099109427
WAIT #140594070557496: nam='gc current grant busy' ela= 284 p1=104 p2=10477512 p3=33619969 obj#=52958 tim=1448892099109896
WAIT #140594070557496: nam='gc current grant busy' ela= 232 p1=104 p2=10477513 p3=33619969 obj#=52958 tim=1448892099110401
WAIT #140594070557496: nam='gc current grant busy' ela= 178 p1=104 p2=10477528 p3=33619969 obj#=52958 tim=1448892099110777
WAIT #140594070557496: nam='gc current grant busy' ela= 173 p1=104 p2=10477544 p3=33619969 obj#=52958 tim=1448892099111159
WAIT #140594070557496: nam='gc current grant busy' ela= 175 p1=104 p2=10477559 p3=33619969 obj#=52958 tim=1448892099111612
WAIT #140594070557496: nam='gc current grant busy' ela= 158 p1=104 p2=10477560 p3=33619969 obj#=52958 tim=1448892099111971
WAIT #140594070557496: nam='gc current grant busy' ela= 184 p1=104 p2=10477575 p3=33619969 obj#=52958 tim=1448892099112335
WAIT #140594070557496: nam='gc current grant busy' ela= 162 p1=104 p2=10477576 p3=33619969 obj#=52958 tim=1448892099112692
WAIT #140594070557496: nam='gc current grant busy' ela= 159 p1=104 p2=10477584 p3=33619969 obj#=52958 tim=1448892099113053
WAIT #140594070557496: nam='gc current grant busy' ela= 160 p1=104 p2=10477591 p3=33619969 obj#=52958 tim=1448892099113396
WAIT #140594070557496: nam='gc current grant busy' ela= 285 p1=104 p2=10477592 p3=33619969 obj#=52958 tim=1448892099114182
WAIT #140594070557496: nam='gc current grant busy' ela= 164 p1=104 p2=10477605 p3=33619969 obj#=52958 tim=1448892099114537
WAIT #140594070557496: nam='gc current grant busy' ela= 168 p1=104 p2=10477606 p3=33619969 obj#=52958 tim=1448892099114903
WAIT #140594070557496: nam='gc current grant busy' ela= 158 p1=104 p2=10477607 p3=33619969 obj#=52958 tim=1448892099115235
WAIT #140594070557496: nam='db file sequential read' ela= 390 file#=2 block#=1323 blocks=1 obj#=0 tim=1448892099115982
WAIT #140594070557496: nam='gc current grant busy' ela= 167 p1=104 p2=10477615 p3=33619969 obj#=52958 tim=1448892099116415
WAIT #140594070557496: nam='gc current grant busy' ela= 168 p1=104 p2=10477623 p3=33619969 obj#=52958 tim=1448892099116778
WAIT #140594070557496: nam='gc current grant busy' ela= 240 p1=104 p2=10477624 p3=33619969 obj#=52958 tim=1448892099117400
WAIT #140594070557496: nam='gc current grant busy' ela= 153 p1=104 p2=10477639 p3=33619969 obj#=52958 tim=1448892099117755
WAIT #140594070557496: nam='gc current grant busy' ela= 281 p1=104 p2=10477640 p3=33619969 obj#=52958 tim=1448892099118449
WAIT #140594070557496: nam='gc current grant busy' ela= 176 p1=104 p2=10477656 p3=33619969 obj#=52958 tim=1448892099118817
WAIT #140594070557496: nam='gc current grant busy' ela= 183 p1=104 p2=10477671 p3=33619969 obj#=52958 tim=1448892099119194
WAIT #140594070557496: nam='gc current grant busy' ela= 166 p1=104 p2=10477685 p3=33619969 obj#=52958 tim=1448892099119614
WAIT #140594070557496: nam='gc current grant busy' ela= 559 p1=104 p2=10477687 p3=33619969 obj#=52958 tim=1448892099120371
WAIT #140594070557496: nam='gc current grant busy' ela= 181 p1=104 p2=10477695 p3=33619969 obj#=52958 tim=1448892099120828
WAIT #140594070557496: nam='gc current grant busy' ela= 169 p1=104 p2=10477697 p3=33619969 obj#=52958 tim=1448892099121188
WAIT #140594070557496: nam='gc current grant busy' ela= 157 p1=104 p2=10477702 p3=33619969 obj#=52958 tim=1448892099121533
WAIT #140594070557496: nam='gc current grant busy' ela= 148 p1=104 p2=10477703 p3=33619969 obj#=52958 tim=1448892099121863
WAIT #140594070557496: nam='gc current grant busy' ela= 170 p1=104 p2=10477704 p3=33619969 obj#=52958 tim=1448892099122300
WAIT #140594070557496: nam='gc current grant busy' ela= 203 p1=104 p2=10477719 p3=33619969 obj#=52958 tim=1448892099122718
WAIT #140594070557496: nam='gc current grant busy' ela= 239 p1=104 p2=10477728 p3=33619969 obj#=52958 tim=1448892099123156
WAIT #140594070557496: nam='gc current grant busy' ela= 161 p1=104 p2=10477737 p3=33619969 obj#=52958 tim=1448892099123493
WAIT #140594070557496: nam='gc current grant busy' ela= 187 p1=104 p2=10477751 p3=33619969 obj#=52958 tim=1448892099123896
WAIT #140594070557496: nam='db file sequential read' ela= 612 file#=2 block#=1324 blocks=1 obj#=0 tim=1448892099124651
WAIT #140594070557496: nam='gc current grant busy' ela= 179 p1=104 p2=10477754 p3=33619969 obj#=52958 tim=1448892099125100
WAIT #140594070557496: nam='gc current grant busy' ela= 172 p1=104 p2=10477755 p3=33619969 obj#=52958 tim=1448892099125456
WAIT #140594070557496: nam='gc current grant busy' ela= 179 p1=104 p2=10477768 p3=33619969 obj#=52958 tim=1448892099125827
WAIT #140594070557496: nam='gc current grant busy' ela= 166 p1=104 p2=10477776 p3=33619969 obj#=52958 tim=1448892099126301
WAIT #140594070557496: nam='gc current grant busy' ela= 166 p1=104 p2=10477782 p3=33619969 obj#=52958 tim=1448892099126655
WAIT #140594070557496: nam='gc current grant busy' ela= 176 p1=104 p2=10477804 p3=33619969 obj#=52958 tim=1448892099127105
WAIT #140594070557496: nam='gc current grant busy' ela= 149 p1=104 p2=10477808 p3=33619969 obj#=52958 tim=1448892099127443
WAIT #140594070557496: nam='gc current grant busy' ela= 151 p1=104 p2=10477815 p3=33619969 obj#=52958 tim=1448892099127792
WAIT #140594070557496: nam='gc current grant busy' ela= 281 p1=104 p2=10477835 p3=33619969 obj#=52958 tim=1448892099128262
WAIT #140594070557496: nam='gc current grant busy' ela= 388 p1=104 p2=10477846 p3=33619969 obj#=52958 tim=1448892099128858
WAIT #140594070557496: nam='gc current grant busy' ela= 152 p1=104 p2=10477895 p3=33619969 obj#=52958 tim=1448892099129210
WAIT #140594070557496: nam='gc current grant busy' ela= 144 p1=104 p2=10477897 p3=33619969 obj#=52958 tim=1448892099129534
WAIT #140594070557496: nam='gc current grant busy' ela= 145 p1=104 p2=10477899 p3=33619969 obj#=52958 tim=1448892099129876
WAIT #140594070557496: nam='gc current grant busy' ela= 145 p1=104 p2=10477910 p3=33619969 obj#=52958 tim=1448892099130225
WAIT #140594070557496: nam='gc current grant busy' ela= 151 p1=104 p2=10477914 p3=33619969 obj#=52958 tim=1448892099130566
WAIT #140594070557496: nam='gc current grant busy' ela= 143 p1=104 p2=10477963 p3=33619969 obj#=52958 tim=1448892099130892
WAIT #140594070557496: nam='gc current grant busy' ela= 148 p1=104 p2=10477975 p3=33619969 obj#=52958 tim=1448892099131213


К сообщению приложен файл (01.zip - 65Kb) cкачать
30 ноя 15, 19:17    [18494059]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
niv76, блоки сам update меняет. И блоки таблицы и блоки индекса. Еще небось записи между секциями перемещаются и если другие индексы есть, то они тоже меняются.
30 ноя 15, 22:07    [18494513]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
Попробуй делать update меньшими порциями. Например, по 100 случайных записей, чтобы они в один блок не долбили. Commit между update вряд-ли повлияет на производительность твоей процедуры.
30 ноя 15, 23:05    [18494667]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
mcureenab
niv76, блоки сам update меняет. И блоки таблицы и блоки индекса. Еще небось записи между секциями перемещаются и если другие индексы есть, то они тоже меняются.


mcureenab
Попробуй делать update меньшими порциями. Например, по 100 случайных записей, чтобы они в один блок не долбили. Commit между update вряд-ли повлияет на производительность твоей процедуры.


Спасибо mcureenab.
Между секциями перемещаються, но думаю плюс минус 20% строк (хотя точно эту статистику не проверял). новое значение берется из сиквенса, индекс глобальный range 1млн. Меняются в большинстве новые строки.


Можешь в двух словах объяснить насчет меньшего кол-ва строк? Почему это может сработать?
пока плохо понимаю общую картину, как оно работает сейчас. Зачем Оракл вообще ролбечит блоки которые сам абдейтит (он должен откатывать только то что меняли транзакции с большим SCN. Наш запрос не мог ничего удалить из того, что он не должен видеть)? Эти updatы запускаются в рамках одной сессии.
И почему не срабатывает буфер для только что измененных UNDO блоков? Они же должны быть еще в буфере по идее?

Он что берет первую строчку, лезет в индекс, смотрит что блок не менялся, делает update (меняет блок). Затем берет вторую строчку из того же блока индекса, видит что блок сам поменял и теперь сам его откатывает (для получение конситентного блока)? И почему он уже не в буфере? Тут конечно генерируется очень много редо, из-за этого? может можно как-то сделать, чтобы не так быстро с буфера сбрасывались на диск?

Думаю может на оборот, проблема в том что блоки меняются в разном порядке, и пока доходит до повторного просмотра блока, undo уже на диске? Может их сортонуть по rowid? Хотя опять же, зачем вообще откатывать свои изменения?



Спасибо.
1 дек 15, 00:03    [18494802]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
niv76
Можешь в двух словах объяснить насчет меньшего кол-ва строк? Почему это может сработать?
Новый запрос выполняется с новым SCN (если не включать уровень изоляции SERIALIZABLE), поэтому нет нужды слишком глубоко погружаться в UNDO.

>>> И почему не срабатывает буфер для только что измененных UNDO блоков? Они же должны быть еще в буфере по идее?
Я не вижу чтобы UNDO с диска читался.

>>>Зачем Оракл вообще ролбечит блоки которые сам абдейтит

Шаг:
TABLE ACCESS BY GLOBAL INDEX ROWID ORDERS PARTITION: ROW LOCATION ROW LOCATION

лезет в таблицу. Видит, что блок изменился. Из UNDO восстанавливает исходный образ блока, сравнивает текущее и исходное состояние строки. Если версии строк совпадают, то можно сделать обновление. Если образы разные, нужно откатывать оператор и повторять попытку обновления с новым SCN.
Та же петрушка с блоками индекса.

Тут тоже нужно получить исходный образ блока.
INDEX RANGE SCAN ORDER_IDX1 PARTITION: KEY KEY

А потом, если запись прошла все фильтры, обновить ключ, что тоже сопровождается восстановлением блоков из UNDO.
1 дек 15, 09:02    [18495221]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
mcureenab
Я не вижу чтобы UNDO с диска читался.

Это же с диска?

WAIT #140594070557496: nam='db file sequential read' ela= 600 file#=2 block#=1322 blocks=1 obj#=0 tim=1448892099107847
...
WAIT #140594070557496: nam='db file sequential read' ela= 390 file#=2 block#=1323 blocks=1 obj#=0 tim=1448892099115982
...
WAIT #140594070557496: nam='db file sequential read' ela= 612 file#=2 block#=1324 blocks=1 obj#=0 tim=1448892099124651
...


db file sequential read - это же одноблочное чтение с диска? file#=2 смотрит на UNDO таблспейс (проверял запросом

select *
from dba_extents
where file_id=2;
Результат - все блоки вида:


OWNER	SEGMENT_NAME	                SEGMENT_TYPE	TABLESPACE_NAME	EXTENT_ID	FILE_ID	BLOCK_ID	BYTES	BLOCKS	RELATIVE_FNO
SYS	_SYSSMU44_2846871887$		TYPE2 UNDO	UNDOTBS1	1	        2	9       	65,536	8	2
SYS	_SYSSMU86_1126243620$		TYPE2 UNDO	UNDOTBS1	1	        2	17	        65,536	8	2
....


запрос
select *
from dba_extents
where block_id in (1322 ,1323,1324) and file_id=2;

ничего не вернул на момент запуска. Выполнялся с лагов, поэтому решил, что UNDO уже перетерлось.

А где ты видишь, что UNDO читается с буфера?

И еще вопросик, если вдруг знаешь. А генерация REDO в трейсе как-то отображается? Если да, то как?

Сенькс.
1 дек 15, 10:47    [18495747]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
niv76
А где ты видишь, что UNDO читается с буфера?
И еще вопросик, если вдруг знаешь. А генерация REDO в трейсе как-то отображается? Если да, то как?
Теперь вижу что с диска. Но чтений не много. У тебя ведь RAC? Может с этим связано?

События трассировки тут перечислены: trace-events-in-oracle но REDO пишет отдельный процесс. В сессии пользователя commit ожидает завершением записи REDO.
В сессии можно видеть как блоки изменяются. А изменения блоков обычно сопровождаются созданием REDO.
1 дек 15, 11:19    [18495986]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
mcureenab
Теперь вижу что с диска. Но чтений не много. У тебя ведь RAC? Может с этим связано?

У меня половина времени уходит на эти чтения.
Хочу точно понять их природу и узнать можно ли как-то это убыстрить.
В этой процедуре три одинаковых update-a по 3м аналогичным таблицам. Вот общая картина:

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        0      0.00       0.00          0          0          0           0

Misses in library cache during parse: 0

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  library cache pin                               1        0.00          0.00
  enq: UL - contention                            1        0.00          0.00


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       28      0.00       0.00          0          0          0           0
Execute     93      5.25      18.28       1480      86958     232309       31859
Fetch       49      0.01       0.01          0        112          0          38
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      170      5.26      18.30       1480      87070     232309       31897

Misses in library cache during parse: 0

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  Disk file operations I/O                        7        0.00          0.00
  gc cr block 2-way                              66        0.00          0.01
  gc current block 2-way                        110        0.00          0.02
  gc current grant busy                        3152        0.01          0.67
  db file sequential read                      1480        0.27          7.98
  gc cr block busy                                1        0.00          0.00
  latch: gc element                               1        0.00          0.00
  log buffer space                                4        0.92          1.89
  latch: checkpoint queue latch                   1        0.00          0.00
  latch: object queue header operation            3        0.00          0.00
  latch: cache buffers lru chain                  2        0.00          0.00
  gc cr grant 2-way                               6        0.00          0.00
  gc buffer busy release                          3        0.99          2.05
  gc current grant 2-way                         14        0.00          0.00
  gc current grant congested                      1        0.00          0.00


Вот итоги по db file sequential read (сумма ивентов и elapsed time по obj#):
OBJECT_ID, COUNT, ELA
0,             1456,    7128903 --- UNDO read
53172,       2,         77164
2312926,   1,          40449
2312929,   2,          81329
2312937,   2,          79897
2312941,   2,          25336
2325514,   4,         303782
2325517,   4,         75537
2325518,   4,         154829
2768522,   3,         17547


получается что у меня половина времени (1456 физ. чтений из 1480 за 7.13 сек ) уходит на чтение UNDO.
Вот еще трейс после tkprof

К сообщению приложен файл (01.txt - 32Kb) cкачать
1 дек 15, 12:14    [18496526]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
Только сейчас обнаружил, что еще есть FK на поле, которое updat-иться (ord_gr_id). Возможно изменяется родительская таблица и откатываются блоки для проверки ФК?
1 дек 15, 13:48    [18497180]     Ответить | Цитировать Сообщить модератору
 Re: помогите оптимизировать insert  [new]
niv76
Member

Откуда: Киев
Сообщений: 115
Помоему нашел причину ИО. Проблема из-за включенного flashback-а.


Before an undo block can be recycled it has to be "new"ed (in Oracle-speak). Normalllly this means that Oracle simply creates a new version of the block in memory without reference to the existing block on disc; but if you are running in flashback mode Oracle (usually) has to read the undo block from disc, and write it into the flashback log before newing it. This activity will show up in statistic "physical reads for flashback new" - the combination of the extra reads and the extra volume of flashback log could cause an I/O problem - the latter (as others have commented) being a reason for the database stopping.



https://community.oracle.com/thread/3646492
1 дек 15, 14:54    [18497690]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить