Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Большие значения execute в трейсе файле / 8 сообщений из 8, страница 1 из 1
02.08.2016, 14:03:28
    #39284565
жвачкин
жвачкин
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие значения execute в трейсе файле
есть запрос:

 
Код: plsql
1.
2.
3.
4.
SELECT D_ID 
FROM
  cc_table CC WHERE CC.CODE = :B3 AND CC.DIC_CODE = :B2 AND :B1 BETWEEN CC.DAT1 
  AND CC.DAT2 AND NVL(CC.IS_NOT_UNIC, 0) = 0 AND ROWNUM = 1



1.большое количество parse - 1420 для запроса, правда при этом cpu и elapsed на парс чрезвычайно малы.
2. большое значение execute для запроса, 390334 раз...
возможно главное и не увидел (подозреваю, что так и есть)

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse     1420      0.07       0.06          0          0          0           0
Execute 390334     75.55      76.48          0          0          0           0
Fetch   390334     13.32      13.10         54    1555367          0      384365
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total   782088     88.95      89.65         54    1555367          0      384365

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



как это можно оптимизировать? снизить количестве executions?

меня смущают: OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
Код: plsql
1.
Execute 867198    209.63     258.85       6107     178403     407931       30173


в трейсе запросов +100500, но

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       54      0.81       0.89          0        153          2           0
Execute     41    179.88     197.89      12225     191192      42291       15945
Fetch       97      0.09       0.09          1       4083          0         556
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      192    180.78     198.87      12226     195428      42293       16501

Misses in library cache during parse: 24
Misses in library cache during execute: 5

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                      1677        0.11         13.24
  SQL*Net message to client                     149        0.00          0.00
  SQL*Net message from client                   149      189.32        204.86
  log file sync                                   6        0.00          0.00
  SQL*Net more data to client                    39        0.00          0.00
  SQL*Net more data from client                   2        0.00          0.00
  Disk file operations I/O                       30        0.02          0.07
  latch: row cache objects                       16        0.00          0.01
  latch: shared pool                              5        1.08          1.16
  latch: cache buffers chains                     2        0.00          0.00
  db file scattered read                       1343        0.02          2.25
  library cache: mutex X                          2        0.00          0.00
  latch: redo allocation                          2        0.00          0.00
  SQL*Net break/reset to client                   2        0.00          0.00


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse    75903      2.99       3.61          0         20         44           0
Execute 867198    209.63     258.85       6107     178403     407931       30173
Fetch   825081    123.52     136.42       1662    4935026       2448      808175
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total   1768182    336.15     398.89       7769    5113449     410423      838348

Misses in library cache during parse: 159
Misses in library cache during execute: 141

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                      7769        0.18         59.18
  Disk file operations I/O                        4        0.03          0.03
  latch: row cache objects                       38        0.00          0.00
  cursor: pin S                                   8        0.01          0.02
  latch: shared pool                              9        0.25          0.33
  latch: cache buffers chains                     3        0.00          0.00
  library cache: mutex X                         23        0.01          0.01
  enq: SQ - contention                           10        0.00          0.00
  buffer busy waits                              25        0.00          0.00
  row cache lock                                  6        0.00          0.00
  read by other session                           2        0.00          0.00
  enq: TX - index contention                     13        0.02          0.06
  latch: cache buffers lru chain                  2        0.00          0.00
  log file switch (private strand flush incomplete)
                                                  1        0.13          0.13
  latch: redo allocation                          1        0.00          0.00
  latch free                                      1        0.00          0.00
  latch: In memory undo latch                     1        0.00          0.00
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
02.08.2016, 15:55:07
    #39284698
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие значения execute в трейсе файле
Мне в который раз интересно, ты увлекся конкретным запросом, но при этом непрерывно вываливаешь "OVERALL TOTALS FOR ALL % STATEMENTS". Наверное ты что-то этим показать хочешь? Ну так хоть намекни...

Или ты не понимаешь разницу между RECURSIVE и NON-RECURSIVE STATEMENTS ?
Хинт: есть SQL-операторы (включая BEGIN-END), посланные с клиента, а есть вызванные изнутри этих операторов

Что касается конкретного запроса -- конечно, лучше уменьшить количество его выполнений, если есть возможность.
Парсов относительно выполнений совсем чуть, так что здесь все нормально. Но каждый вызов этого запроса приведет к EXECUTE и FETCH

Да и вообще -- ты не указываешь временной промежуток, о чем тут можно судить? Если трейс снят за сутки -- то тут даже смотреть не на что, а если за те же 7 мин, то, собственно, а что ему еще делать, как не работать? Например, среднее обращение к диску занимает 0.007 с, это очень хороший результат. А "SQL*Net message from client" в нерекурсивных операторах говорит о том, что сервер ждал команды от клиента

Не понятен смысл этого трейса
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
02.08.2016, 16:34:40
    #39284743
жвачкин
жвачкин
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие значения execute в трейсе файле
Вячеслав ЛюбомудровМне в который раз интересно, ты увлекся конкретным запросом, но при этом непрерывно вываливаешь "OVERALL TOTALS FOR ALL % STATEMENTS". Наверное ты что-то этим показать хочешь? Ну так хоть намекни...

Или ты не понимаешь разницу между RECURSIVE и NON-RECURSIVE STATEMENTS ?
Хинт: есть SQL-операторы (включая BEGIN-END), посланные с клиента, а есть вызванные изнутри этих операторов

Что касается конкретного запроса -- конечно, лучше уменьшить количество его выполнений, если есть возможность.
Парсов относительно выполнений совсем чуть, так что здесь все нормально. Но каждый вызов этого запроса приведет к EXECUTE и FETCH

Да и вообще -- ты не указываешь временной промежуток, о чем тут можно судить? Если трейс снят за сутки -- то тут даже смотреть не на что, а если за те же 7 мин, то, собственно, а что ему еще делать, как не работать? Например, среднее обращение к диску занимает 0.007 с, это очень хороший результат. А "SQL*Net message from client" в нерекурсивных операторах говорит о том, что сервер ждал команды от клиента

Не понятен смысл этого трейса

Вячеслав, пользователь пожаловался, что " ну 3,14*ц долго " выполняется некий отчёт.
Я снял трейс, получил 790 elapsed seconds in trace file, увидел, что большая часть времени потрачено на
рекурсивные вызовы. Да, выполнялся некий begin-end. Мне бросилось в глаза, что очень много executions.
По времени - это не день, 13 минут..
Пользователь написал руководству, что он такой молодец, всё делает, а " программа висит "
Возник вопрос, куда копать дальше?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
02.08.2016, 18:45:08
    #39284842
JaRo
JaRo
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие значения execute в трейсе файле
жвачкинВозник вопрос, куда копать дальше?Казалось бы очевидно.. Смотреть самому(или просить объяснить программистов), зачем код генерит столько вызовов этого запроса..
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
03.08.2016, 06:50:29
    #39285044
nata44845
nata44845
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие значения execute в трейсе файле
В трассировке план наверное есть...

Смотри план, если сервер ентерпрайз в SQL Monitoring запрос найдешь и можешь прям там у советника попросить подсказку, может подскажет какой индекс создать. Может план подскажет удачный и закрепишь этот план за запросом.

Можно самому план создать и закрепить его за запросом, но это уже надо немного копать интернет, тут видела такую тему.
Может таблицу по дате секционировать, если таблица большая и за много лет (я к этому стремлюсь, но пока страшно).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
03.08.2016, 06:57:31
    #39285046
nata44845
nata44845
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие значения execute в трейсе файле
И звиздец долго понятие относительное, 13 минут для отчета ни о чем, у меня запросы по 9 часов выполнялись, отключила параметр оптимизатора и уговорила разработчика не пихать везде ORDERED, свела их к 6 минутам, пользователи уже счастливы.
А 13 минут это пользователю кофе сходить попить, не постоянно же он его делает.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
03.08.2016, 09:05:37
    #39285087
man-from-36
man-from-36
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие значения execute в трейсе файле
nata44845А 13 минут это пользователю кофе сходить попить, не постоянно же он его делает.

неизвестно о каком отчете идет речь, может и 13 минут это долго. но 390 тысяч вызовов - имхо, перебор.

автор, можете намекнуть на содержание (данные) отчета? может надо просто разработчика попинать?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
03.08.2016, 12:38:39
    #39285271
schi
schi
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большие значения execute в трейсе файле
Кстати, запрос рекурсивный. Ищите функцию/пакет, где он вызывается, сравнивайте количество вызовов
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Большие значения execute в трейсе файле / 8 сообщений из 8, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 582ms
Закрыть
start [/forum/topic.php?fid=52&mobile=1&tid=1887735]:
 0ms
get settings:
 11ms
get forum list:
 16ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 196ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 56ms
get tp. blocked users:
 1ms
others: 281ms
total:  582ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]