CftClub.ru
Клуб специалистов ЦФТ-Банк

Странности в поведении Runtime 6 + Oracle 11.2.0.3

 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA
Предыдущая тема :: Следующая тема  
Автор Сообщение
Serj
Профи
ОИКБ Русь


Вступление в Клуб: 02.08.2007
СообщениеПн Dec 26, 2011 05:41   Странности в поведении Runtime 6 + Oracle 11.2.0.3 Ответить с цитатой
Полезность: Нет оценки
См. вложениеДата архива: 22.01.2014 01:02
Размер архива: 6.32 КБ

В общем есть отчетик report_0102114.rdf - "Справка по кассовым оборотам", - после перезда на 11 версию отчет стал выполняться вместо минуты - 30 минут, а то и 40 - отчет пустяковый. План выполнения нормальный, вполне но в событиях ожидания преобладают одноблочные чтения(индексный доступ) -
Код:

pread(258, "06A2\0\002\n1D14 "8B15 9".., 8192, 0x143A28000) = 8192
lseek(12, 0, SEEK_CUR)                          = 8341239
write(12, " W A I T   # 1 8 4 4 6 7".., 126)    = 126
write(13, " N ? m S 2 ~ 1 4 - 1\n", 11)         = 11
write(12, "\n", 1)                              = 1
pread(258, "06A2\0\002\n1D17 "8B15 9".., 8192, 0x143A2E000) = 8192
- трассировка процесса в Solaris - кажет по-блочные чтения из файлов данных - кстати выполняются они медленно,хотя работают в паре pread+lseek (должно в теории быть быстрее чем read+seek). Пробовал делать привязку плана через baseline к запросу - толку нет. Первый раз выполняется долго запрос отчета - последующие разы быстро, проходит час где то и снова первое выполнение идет долго. Пробовал чистил разделяемый пул и кэш буферов - все равно после "быстрого" выполнения даже чистка пула и кэша не влияет - 1 минута выполнение.Что смущает в трассировке не видно вызова KAIO - может каким то образом асинхронный ввод-вывод отключается именно на этом отчете в 6-ом клиенте Runtime - ? - Но почему повторное выполнение(план тот же) происходит гораздо быстрее?.

Код:

select  :"SYS_B_00" num_kassa , max ( cur_short ) cur_short , code_iso ,
  R_BAD_MONEY , max ( cur_name ) cur_name , max ( cur_name || :"SYS_B_01" ||
  code_iso || :"SYS_B_02" || decode ( R_BAD_MONEY , :"SYS_B_03" , :"SYS_B_04"
  , :"SYS_B_05" ) ) cur_name_long , max ( cur_name || decode ( R_BAD_MONEY ,
  :"SYS_B_06" , :"SYS_B_07" , :"SYS_B_08" ) ) cur_name_with_bad , sum (
  db_count ) db_count , sum ( db_sum ) db_sum , sum ( db_sumcur ) db_sumcur ,
  sum ( kr_count ) kr_count , sum ( kr_sum ) kr_sum , sum ( kr_sumcur )
  kr_sumcur , :"SYS_B_09" dummy
from
 ( select lpad (  C_NUM_KS , :"SYS_B_10" ) num_kassa , rpad (  C_CUR_SHORT ,
  :"SYS_B_11" ) cur_short , nvl ( C_CODE_ISO , :"SYS_B_12" ) code_iso ,
  C_FINTOOL cur_id ,  C_CUR_NAME cur_name , decode ( c_dt , :"SYS_B_13" ,
  :"SYS_B_14" , :"SYS_B_15" ) db_count , nvl ( decode ( c_dt , :"SYS_B_16" ,
  C_SUMMA_NAT ) , :"SYS_B_17" ) db_sum , nvl ( decode ( c_dt , :"SYS_B_18" ,
  C_SUMMA ) , :"SYS_B_19" ) db_sumcur , decode ( c_dt , :"SYS_B_20" ,
  C_TO_COUNT , :"SYS_B_21" ) kr_count , nvl ( decode ( c_dt , :"SYS_B_22" ,
  C_SUMMA_NAT ) , :"SYS_B_23" ) kr_sum , nvl ( decode ( c_dt , :"SYS_B_24" ,
  C_SUMMA ) , :"SYS_B_25" ) kr_sumcur , c_BAD_MONEY R_BAD_MONEY from 
  VW_RPT_TURN_KASS  Where  C_FINTOOL=:P_KAS_FINTOOL and upper(C_FILIAL)=
  :"SYS_B_26" and C_FINTOOL=:P_KAS_FINTOOL union all select lpad (
  C_NUM_KASSA , :"SYS_B_27" ) num_kassa , rpad ( C_CUR_SHORT , :"SYS_B_28" )
  cur_short , C_CODE_ISO cur_short , C_CUR_ID cur_id , rpad ( C_CUR_NAME ,
  :"SYS_B_29" ) cur_name , :"SYS_B_30" db_count , :"SYS_B_31" db_sum ,
  :"SYS_B_32" db_sumcur , :"SYS_B_33" kr_count , :"SYS_B_34" kr_sum ,
  :"SYS_B_35" kr_sumcur , :"SYS_B_36" R_BAD_MONEY from VW_RPT_CUR_NOTRADE 
  Where  C_CUR_ID=:P_KAS_FINTOOL and C_CUR_ID=:P_KAS_FINTOOL )   group by
  :"SYS_B_37" , code_iso , R_BAD_MONEY ORDER BY :"SYS_B_38" ASC,:"SYS_B_39"
  ASC,:"SYS_B_40" ASC,:"SYS_B_41" ASC,:"SYS_B_42" ASC,:"SYS_B_43" ASC


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.95       0.99          0          0          0           0
Fetch        1     73.29    2546.83     637046    3148526          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3     74.24    2547.82     637046    3148526          0           1
-кусок трэйса - целиком трэйс запроса в прикрепленном файле - если кому интересно. У кого как работает этот отчет?

XLman
Участник со стажем
Кредитмарт


Вступление в Клуб: 20.02.2008
СообщениеПн Dec 26, 2011 18:48    Ответить с цитатой
Полезность: Нет оценки
ЦФТ сказало, что с Ораклом 11 и репортс 6 будут большие проблемы с отчетами, необходимо ставить сервер отчетов Forms and Reports 11, может быть и 10 подойдет. Может как раз это одна из проблем.
Serj
Профи
ОИКБ Русь


Вступление в Клуб: 02.08.2007
СообщениеВт Dec 27, 2011 06:30    Ответить с цитатой
Полезность: Нет оценки
XLman пишет:
ЦФТ сказало, что с Ораклом 11 и репортс 6 будут большие проблемы с отчетами, необходимо ставить сервер отчетов Forms and Reports 11, может быть и 10 подойдет. Может как раз это одна из проблем.
- вполне возможно, но другие отчеты 6i так себя не ведут Sad
maestro
Профи
Неподтвержденный


Вступление в Клуб: 12.10.2010
СообщениеВт Dec 27, 2011 09:59    Ответить с цитатой
Полезность: Нет оценки
Ну судя по трейсу, у тебя основные затраты уходят на фетч.
Код:

Fetch        1     73.29    2546.83     637046    3148526          0           1

Посмотри, может правда много данных тянет.

У меня планчик примерно такой же. Работает 1-2 минуты.
Serj
Профи
ОИКБ Русь


Вступление в Клуб: 02.08.2007
СообщениеСр Dec 28, 2011 06:56    Ответить с цитатой
Полезность: Нет оценки
maestro пишет:
Ну судя по трейсу, у тебя основные затраты уходят на фетч.
Код:

Fetch        1     73.29    2546.83     637046    3148526          0           1

Посмотри, может правда много данных тянет.

У меня планчик примерно такой же. Работает 1-2 минуты.
- не в плане дело, данных там с гулькин хвост, медленно работает серверный процесс запущенный для Rwrun60, я специально показал кусочек truss с ОС - может тут что скрывается - и планы разные вешал и запрос менял и подсказки разные вешал - в плоть до хинта /*+ RULE */ - от безысходности правда, план разный, а срок выполнения примерно одинаков - первый раз выполняется долго последующие влет- максимум минута, проходит час....и все заново - первый раз висяк на 30-40 минут.
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Рейтинг@Mail.ru