Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
Ora_ngutang
Guest
Сына
ORAngutang
основные таблички прокэшированы:

ALTER TABLE Masy6.TempGsrInput1 CACHE;

ALTER TABLE Masy6.FreieLiq CACHE;

Дык это не спасет от выталкивания из кэша


да? А что тогда спасет?
22 окт 07, 20:32    [4824692]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
Сынка
Guest
Ora_ngutang
Сына
ORAngutang
основные таблички прокэшированы:

ALTER TABLE Masy6.TempGsrInput1 CACHE;

ALTER TABLE Masy6.FreieLiq CACHE;

Дык это не спасет от выталкивания из кэша


да?

Есть сомнения?
22 окт 07, 21:03    [4824756]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
evostr
Member

Откуда: Екатеринбург
Сообщений: 1278
2 ORAngutang
Боюсь показаться назойливым , но все же хотелось бы взглянуть на "плохой" вариант выполнения процедуры.

p.s. А у Вас случаем кеш файловой системы не включен? а то какие-то больно быстрые db file sequential read, да и flush cache Вы говорите, роли не играет ;-)
22 окт 07, 21:12    [4824778]     Ответить | Цитировать Сообщить модератору
 Какая версия Оракла?  [new]
Sergei.Agalakov
Member

Откуда:
Сообщений: 575
Какое значение у параметра optimizer_dynamic_sampling?
22 окт 07, 23:31    [4825010]     Ответить | Цитировать Сообщить модератору
 Re: Какая версия Оракла?  [new]
dba123
Guest
Sergei.Agalakov
Какое значение у параметра optimizer_dynamic_sampling?
+1
меняется ли план
select /*+ dynamic_sampling(f.f 3) */ nvl( Sum( decode( f.BETRAGTYP, 1, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as 
  B1, nvl( Sum( decode( f.BETRAGTYP, 2, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as 
  B2, nvl( Sum( decode( f.BETRAGTYP, 2, decode( f.ISKnd, 0, nvl( 
  f.BruttoBETRAG, 0 ), 0 ) ) ), 0 ) as B2vers, nvl( Sum( decode( f.BETRAGTYP, 
  2, decode( f.ISKnd, 1, nvl( f.BruttoBETRAG, 0 ), 0 ) ) ), 0 ) as B2knd, 
  nvl( Sum( decode( f.BETRAGTYP, 3, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as B3, 
  nvl( Sum( decode( f.BETRAGTYP, 4, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as B4, 
  nvl( Sum( decode( f.BETRAGTYP, 7, nvl( f.BETRAG, 0 ) ) ), 0 ) as B7, nvl( 
  Sum( decode( f.BETRAGTYP, 8, nvl( f.BETRAG, 0 ) ) ), 0 ) as B8, nvl( Sum( 
  decode( nvl( f.BETRAGTYP, 0 ), 8, decode( f.IsKnd, 0, nvl( f.BruttoBETRAG, 
  0 ), 0 ), 0 ) ), 0 ) as BDebVers, nvl( Sum( decode( nvl( f.BETRAGTYP, 0 ), 
  8, decode( f.IsKnd, 1, nvl( f.BruttoBETRAG, 0 ), 0 ), 0 ) ), 0 ) as BDebKnd 
from
  v_FreieLiqAll  f  where trunc( dt, 'day' ) = trunc( to_date(:xDt) ) and dt 
  < TRUNC( sysdate ) and :xFirstDt is null and :xSecondDt is null 
23 окт 07, 08:59    [4825427]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
Splain
Member

Откуда: Череповец
Сообщений: 924
ORAngutang
OraSRP-анализ здесь:


Ага, все хорошо. Только в отладочном файле нет информации о проблемном запросе. Нужна статистика плана выполнения.

Может тогда еще какие детали всплывут.
23 окт 07, 09:57    [4825678]     Ответить | Цитировать Сообщить модератору
 Re: Какая версия Оракла?  [new]
ORAngutang
Member

Откуда:
Сообщений: 1755
dba123
Sergei.Agalakov
Какое значение у параметра optimizer_dynamic_sampling?
+1
меняется ли план


optimizer_dynamic_sampling = 2.

Нет. План не меняется. (если не считать измененеий Bytes и Сardinality в некоторых узлах плана)

Кста: Oracle 10.2.0.3 (на Linux-Suse-10)
23 окт 07, 11:31    [4826295]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
ORAngutang
Member

Откуда:
Сообщений: 1755
evostr
Боюсь показаться назойливым , но все же хотелось бы взглянуть на "плохой" вариант выполнения процедуры.


возможно НА СЕГОДНЯ я уже "прощёлкал", т.к. запрос

select 'afcpro_ora_' || p.SPID || '.trc' from vsession s, vprocess p
where s.PADDR = p.ADDR and s.SID=211 and rownum<2;

вернул несуществующий trc-файл!
(Процедуру я выполнил из сессии 211) М.б несколько часов позднее будет ещё одно замедление - иначе только завтра...


evostr
p.s. А у Вас случаем кеш файловой системы не включен?

подскажите плиз как бы это проверить?
23 окт 07, 11:56    [4826474]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
ORAngutang
М.б несколько часов позднее будет ещё одно замедление - иначе только завтра...

Напоминаю про чек-лист:
- timed_statistics true
- курсор разобран (hardparse) ПОСЛЕ включения трассировки.
- курсор разобран CBO
- курсор ЗАКРЫТ в процессе трассировки (можно просто закрыть сессию, на выключая трейс)
- трассировка level 8

Ожидаемый результат:
- статистика
- план из .trc
- события ожидания
23 окт 07, 12:07    [4826558]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
нуб
Member

Откуда:
Сообщений: 171
andrey_anonymous
- курсор разобран (hardparse) ПОСЛЕ включения трассировки.

Вот это требование смущает. Нафига hardparse ?

з.ы. еще бы я добавил statistic_level в all, раз уж мучать автора то по полной ;-)
23 окт 07, 13:03    [4826965]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
ORAngutang
Member

Откуда:
Сообщений: 1755
andrey_anonymous
ORAngutang
М.б несколько часов позднее будет ещё одно замедление - иначе только завтра...

Напоминаю про чек-лист:
- timed_statistics true
- курсор разобран (hardparse) ПОСЛЕ включения трассировки.
- курсор разобран CBO
- курсор ЗАКРЫТ в процессе трассировки (можно просто закрыть сессию, на выключая трейс)
- трассировка level 8

Ожидаемый результат:
- статистика
- план из .trc
- события ожидания



Cделал так: очистил (flush) SGA и Buffer Cache.
Дальше запустил (в виде BASH-скрипта) такое:

...
sqlplus -s "/ as sysdba" <<EOF
declare
  lCnt     pls_integer;
  lSid     pls_integer;
  lSerial  pls_integer;
begin
  lSid := $SessId;
  lSecondsToSleep := $SecToSleep; (60)
  select count(*) into lCnt from vsession where sid = lSid;
  if lCnt > 0 then
    select sid,serial# into lSid,lSerial from vsession where sid = lSid;
    execute immediate 'alter system set timed_statistics=true scope=memory';
    sys.dbms_system.set_ev( lSid, lSerial, 10046, 8, '' );
    dbms_lock.sleep( 60 ); 
    execute immediate 'alter system set timed_statistics=false scope=memory';
    sys.dbms_system.set_ev( lSid, lSerial, 10046, 0, '' );
    commit;
  end if;
end;
/
exit;
EOF
...

а в заранее открытой SQL-Plus Worksheet ceccии (241) запустил вызов процедуры. И после выполнения закрыл SQL-Plus Worksheet.
TKProf выдает среди прочего проблемный запрос:
т.е. утренней ситуации (где м.б до 50 сек вместо полученых сейчас 7 сек) я так и не дождался...
Но по методологии то правильно я сделал?


****************************************************************************

select nvl( Sum( decode( f.BETRAGTYP, 1, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as 
  B1, nvl( Sum( decode( f.BETRAGTYP, 2, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as 
  B2, nvl( Sum( decode( f.BETRAGTYP, 2, decode( f.ISKnd, 0, nvl( 
  f.BruttoBETRAG, 0 ), 0 ) ) ), 0 ) as B2vers, nvl( Sum( decode( f.BETRAGTYP, 
  2, decode( f.ISKnd, 1, nvl( f.BruttoBETRAG, 0 ), 0 ) ) ), 0 ) as B2knd, 
  nvl( Sum( decode( f.BETRAGTYP, 3, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as B3, 
  nvl( Sum( decode( f.BETRAGTYP, 4, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as B4, 
  nvl( Sum( decode( f.BETRAGTYP, 7, nvl( f.BETRAG, 0 ) ) ), 0 ) as B7, nvl( 
  Sum( decode( f.BETRAGTYP, 8, nvl( f.BETRAG, 0 ) ) ), 0 ) as B8, nvl( Sum( 
  decode( nvl( f.BETRAGTYP, 0 ), 8, decode( f.IsKnd, 0, nvl( f.BruttoBETRAG, 
  0 ), 0 ), 0 ) ), 0 ) as BDebVers, nvl( Sum( decode( nvl( f.BETRAGTYP, 0 ), 
  8, decode( f.IsKnd, 1, nvl( f.BruttoBETRAG, 0 ), 0 ), 0 ) ), 0 ) as BDebKnd 
from
  v_FreieLiqAll  f  where trunc( dt, 'day' ) = trunc( :xDt ) and dt < TRUNC( 
  sysdate ) and :xFirstDt is null and :xSecondDt is null 


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute    147      0.01       0.01          0          0          0           0
Fetch      147      6.96       6.89      27779     213225          0         147
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      295      6.98       6.91      27779     213225          0         147

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

Rows     Row Source Operation
-------  ---------------------------------------------------
    147  SORT AGGREGATE (cr=213225 pr=27779 pw=0 time=6898162 us)
 904134   FILTER  (cr=213225 pr=27779 pw=0 time=11594135 us)
 904134    HASH JOIN SEMI (cr=213225 pr=27779 pw=0 time=7715642 us)
 931711     TABLE ACCESS BY INDEX ROWID FREIELIQ (cr=180506 pr=27779 pw=0 time=8417750 us)
 931847      INDEX RANGE SCAN IDX_FREIELIQ_TRDT7 (cr=10608 pr=10234 pw=0 time=2568546 us)(object id 121274)
7590249     TABLE ACCESS FULL TEMPGSRINPUT1 (cr=32719 pr=0 pw=0 time=15545586 us)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                     27779        0.01          0.28
***************************************************************************
23 окт 07, 13:13    [4827052]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
dba123
Guest
ORAngutang,
не по теме, но интересно узнать
не используете ли случайно прозрачное шифрование? (TDE)
где-то подобное уже встречал или это куски репликации
23 окт 07, 13:57    [4827452]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
ORAngutang
Member

Откуда:
Сообщений: 1755
dba123
не используете ли случайно прозрачное шифрование? (TDE)


нет.
23 окт 07, 14:13    [4827590]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
Splain
Member

Откуда: Череповец
Сообщений: 924
Все верно, но пока что момент проблемный Вы не поймали. Т.е. у Вас было query = 1 114 893, а сейчас query = 213 225, или в 5 раз меньше. Естественно, и время отличается в 3 раза.
23 окт 07, 14:13    [4827592]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
нуб
andrey_anonymous
- курсор разобран (hardparse) ПОСЛЕ включения трассировки.

Вот это требование смущает. Нафига hardparse ?

йа-йа, что то тут не так :)
если трейс был включен и запрос еще на разбирался с включенной трассировкой (+ CBO env, etc), hard parse обязательно будет.
SQL> alter system flush shared_pool;
 
System altered
 
SQL> select * from t;
 
DUMMY
-----
f
 
SQL> alter session set events '10046 trace name context forever, level 8';
 
Session altered
 
SQL> select * from t;
 
DUMMY
-----
f
 
SQL> alter session set events '10046 trace name context off';
 
Session altered
 
SQL> alter session set events '10046 trace name context forever, level 8';
 
Session altered
 
SQL> select * from t;
 
DUMMY
-----
f
 
SQL> alter session set events '10046 trace name context off';
 
Session altered
PARSING IN CURSOR #24 len=17 dep=0 uid=65 oct=3 lid=65 tim=95493963788 hv=1134051363 ad='2395e978'
select * from t
END OF STMT
PARSE #24:c=0,e=1057,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=95493963782
...
STAT #24 id=1 cnt=1 pid=0 pos=1 obj=74391 op='TABLE ACCESS FULL T (cr=3 pr=0 pw=0 time=80 us)'

...

PARSING IN CURSOR #7 len=17 dep=0 uid=65 oct=3 lid=65 tim=95535473309 hv=1134051363 ad='2395e978'
select * from t
END OF STMT
PARSE #7:c=0,e=101,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=95535473303
...
STAT #7 id=1 cnt=1 pid=0 pos=1 obj=74391 op='TABLE ACCESS FULL T (cr=3 pr=0 pw=0 time=81 us)'

Ну и другие сессии с трассировкой:

PARSING IN CURSOR #4 len=15 dep=0 uid=65 oct=3 lid=65 tim=96104704038 hv=1134051363 ad='238fbf9c'
select * from t
END OF STMT
PARSE #4:c=0,e=106,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=96104704029
...
STAT #4 id=1 cnt=1 pid=0 pos=1 obj=74391 op='TABLE ACCESS FULL T (cr=3 pr=0 pw=0 time=93 us)'
23 окт 07, 14:14    [4827599]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
Timm
нуб
andrey_anonymous
- курсор разобран (hardparse) ПОСЛЕ включения трассировки.

Вот это требование смущает. Нафига hardparse ?

йа-йа, что то тут не так :)

По проблеме автора очевидных версий две:
- "залипает" на парсе (например, ожидания library cache)
- тащит данные с диска.

Хотелось все увидеть в одной трассе :)
23 окт 07, 14:19    [4827658]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
Timm
Member

Откуда: Moscow, Ё-burg
Сообщений: 3696
andrey_anonymous

По проблеме автора очевидных версий две:
- "залипает" на парсе (например, ожидания library cache)
- тащит данные с диска.

Хотелось все увидеть в одной трассе :)

пнятно.
23 окт 07, 14:23    [4827687]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
Splain
Member

Откуда: Череповец
Сообщений: 924
andrey_anonymous

- курсор разобран (hardparse) ПОСЛЕ включения трассировки.


Кстати, этого здесь пока что совершенно не нужно.

Важно поймать проблему, а уже потом разбираться с причинами.

Вполне возможно, у автора меняется план выполнения вследствие bind variable peeking. Особенно учитывая наблюдаемый разброс lio в результатах трассировок.
23 окт 07, 14:28    [4827728]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
злой язык
Guest
ORAngutang
Execute    146      0.01       0.00          0          0          0           0
Fetch      146     16.98      16.60          0    1064209          0         146
 


А вы уверены что проблема вообще на стороне оракла, а не клиента, скажем? :)
23 окт 07, 14:30    [4827743]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
ORAngutang
Member

Откуда:
Сообщений: 1755
нуб
з.ы. еще бы я добавил statistic_level в all, раз уж мучать автора то по полной ;-)


добавил:
alter system set STATISTICS_LEVEL = ALL scope = memory
перед...

и

alter system set STATISTICS_LEVEL = typical scope = memory

после замера.

Получил:


*****************************************************************************

select nvl( Sum( decode( f.BETRAGTYP, 1, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as 
  B1, nvl( Sum( decode( f.BETRAGTYP, 2, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as 
  B2, nvl( Sum( decode( f.BETRAGTYP, 2, decode( f.ISKnd, 0, nvl( 
  f.BruttoBETRAG, 0 ), 0 ) ) ), 0 ) as B2vers, nvl( Sum( decode( f.BETRAGTYP, 
  2, decode( f.ISKnd, 1, nvl( f.BruttoBETRAG, 0 ), 0 ) ) ), 0 ) as B2knd, 
  nvl( Sum( decode( f.BETRAGTYP, 3, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as B3, 
  nvl( Sum( decode( f.BETRAGTYP, 4, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as B4, 
  nvl( Sum( decode( f.BETRAGTYP, 7, nvl( f.BETRAG, 0 ) ) ), 0 ) as B7, nvl( 
  Sum( decode( f.BETRAGTYP, 8, nvl( f.BETRAG, 0 ) ) ), 0 ) as B8, nvl( Sum( 
  decode( nvl( f.BETRAGTYP, 0 ), 8, decode( f.IsKnd, 0, nvl( f.BruttoBETRAG, 
  0 ), 0 ), 0 ) ), 0 ) as BDebVers, nvl( Sum( decode( nvl( f.BETRAGTYP, 0 ), 
  8, decode( f.IsKnd, 1, nvl( f.BruttoBETRAG, 0 ), 0 ), 0 ) ), 0 ) as BDebKnd 
from
  v_FreieLiqAll  f  where trunc( dt, 'day' ) = trunc( :xDt ) and dt < TRUNC( 
  sysdate ) and :xFirstDt is null and :xSecondDt is null 


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     65      0.02       0.01          0          0          0           0
Fetch       64     29.62      29.29       6161      53639          0          64
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      130     29.65      29.30       6161      53639          0          64

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

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                      6391        0.01          0.38
*****************************************************************************
23 окт 07, 14:47    [4827885]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
ORAngutang
Member

Откуда:
Сообщений: 1755
злой язык
ORAngutang
Execute    146      0.01       0.00          0          0          0           0
Fetch      146     16.98      16.60          0    1064209          0         146
 


А вы уверены что проблема вообще на стороне оракла, а не клиента, скажем? :)


проблема (с многократным замедлением после долгого (1 сутки) неиспользования) наблюдается даже на таком "клиенте" как SqlPlus на Database-сервере!
23 окт 07, 14:50    [4827912]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
ORAngutang
Member

Откуда:
Сообщений: 1755
andrey_anonymous
ORAngutang
М.б несколько часов позднее будет ещё одно замедление - иначе только завтра...

Напоминаю про чек-лист:
- timed_statistics true
- курсор разобран (hardparse) ПОСЛЕ включения трассировки.
- курсор разобран CBO
- курсор ЗАКРЫТ в процессе трассировки (можно просто закрыть сессию, на выключая трейс)
- трассировка level 8

Ожидаемый результат:
- статистика
- план из .trc
- события ожидания


выполнил 4 раза. И только не 4 раз закрыл сессию (с искомым запросом) раньше, чем закончился trace-период (поднятый в итоге до 180 сек.)

вот результат Tk-Proof:

*****************************************************************************

select nvl( Sum( decode( f.BETRAGTYP, 1, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as 
  B1, nvl( Sum( decode( f.BETRAGTYP, 2, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as 
  B2, nvl( Sum( decode( f.BETRAGTYP, 2, decode( f.ISKnd, 0, nvl( 
  f.BruttoBETRAG, 0 ), 0 ) ) ), 0 ) as B2vers, nvl( Sum( decode( f.BETRAGTYP, 
  2, decode( f.ISKnd, 1, nvl( f.BruttoBETRAG, 0 ), 0 ) ) ), 0 ) as B2knd, 
  nvl( Sum( decode( f.BETRAGTYP, 3, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as B3, 
  nvl( Sum( decode( f.BETRAGTYP, 4, nvl( f.BruttoBETRAG, 0 ) ) ), 0 ) as B4, 
  nvl( Sum( decode( f.BETRAGTYP, 7, nvl( f.BETRAG, 0 ) ) ), 0 ) as B7, nvl( 
  Sum( decode( f.BETRAGTYP, 8, nvl( f.BETRAG, 0 ) ) ), 0 ) as B8, nvl( Sum( 
  decode( nvl( f.BETRAGTYP, 0 ), 8, decode( f.IsKnd, 0, nvl( f.BruttoBETRAG, 
  0 ), 0 ), 0 ) ), 0 ) as BDebVers, nvl( Sum( decode( nvl( f.BETRAGTYP, 0 ), 
  8, decode( f.IsKnd, 1, nvl( f.BruttoBETRAG, 0 ), 0 ), 0 ) ), 0 ) as BDebKnd 
from
  v_FreieLiqAll  f  where trunc( dt, 'day' ) = trunc( :xDt ) and dt < TRUNC( 
  sysdate ) and :xFirstDt is null and :xSecondDt is null 


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        4      0.00       0.00          0          0          0           0
Execute    439      0.08       0.06          0          0          0           0
Fetch      439    262.19     259.49      71304     569428          0         439
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      882    262.27     259.55      71304     569428          0         439

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

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                     71304        0.01          1.02
  latch free                                      3        0.00          0.00
*****************************************************************************

плюс прикладываю trc прогнанный через OraSRP


P.S. Думаю все Ваши требования теперь выполненны:

1.- timed_statistics true
+

2.- курсор разобран (hardparse) ПОСЛЕ включения трассировки.
- курсор разобран CBO
++ (поскольку перед выполнением я делал Flush SGA !)

3.- курсор ЗАКРЫТ в процессе трассировки (можно просто закрыть сессию, на выключая трейс)
+ (поскольку SqlPlus Worksheet cессию я закрывал!)

4.- трассировка level 8
+

К сообщению приложен файл (vmi_report2.zip - 50Kb) cкачать
23 окт 07, 15:37    [4828259]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
ORAngutang
Member

Откуда:
Сообщений: 1755
andrey_anonymous
Timm
нуб
andrey_anonymous
- курсор разобран (hardparse) ПОСЛЕ включения трассировки.

Вот это требование смущает. Нафига hardparse ?

йа-йа, что то тут не так :)

По проблеме автора очевидных версий две:
- "залипает" на парсе (например, ожидания library cache)
- тащит данные с диска.

Хотелось все увидеть в одной трассе :)


>- тащит данные с диска.
очевидно, что это роли почти не играет. Т.к. любой повторный вызов процедуры замедляется со своих 7 секунд всего лишь на 8 секунд, в случае если "флушнуть" Buffer Cache! (а заодно и SGA)
23 окт 07, 15:41    [4828291]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18339
1) Плана таки нет
2) Не очень понимаю что меряем:
259.49/439=0.59с/запрос
23 окт 07, 15:41    [4828293]     Ответить | Цитировать Сообщить модератору
 Re: ищу правильный подход по теме буферирования данных при вызове процедур PL/SQL пакета.  [new]
ORAngutang
Member

Откуда:
Сообщений: 1755
andrey_anonymous
1) Плана таки нет


да где-ж мне его взять то? Объясните пожалуйста!
23 окт 07, 15:43    [4828303]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
Все форумы / Oracle Ответить