Находим sid и serial# сессии:
select s.username
, s.sid
, s.serial#
, s.osuser
, s.machine
, s.terminal
, p.spid
, last_call_et
, status
from V$SESSION s
, V$PROCESS p
where s.PADDR = p.ADDR
and s.sid='123';
Включить трассировку:
BEGIN
SYS.DBMS_System.Set_Ev(156, 13, 10046, 12, '');
END;
/
Отключить трассировку сессии:
BEGIN
SYS.DBMS_System.Set_Ev(156, 13, 10046, 0, '');
END;
/
Файлы трассировок находятся:
show parameter dump_dest
или так:
select name, value
from v$parameter
where name like '%dump_dest%';
set serveroutput on
exec dbms_output.put_line( scott.get_param( 'user_dump_dest' ) )
В 11g так:
with home
as
(select value home
from v$diag_info
where name = 'ADR Home'
)
select name,
case when value <> home.home
then replace(value,home.home,'$home$')
else value
end value
from v$diag_info, home
/
select c.value || '/' || d.instance_name || '_ora_' ||
a.spid || '.trc' ||
case when e.value is not null then '_'||e.value end trace
from v$process a, v$session b, v$parameter c, v$instance d, v$parameter e
where a.addr = b.paddr
and b.audsid = userenv('sessionid')
and c.name = 'user_dump_dest'
and e.name = 'tracefile_identifier'
/
Обработка файлов трассировки:
Обработка файла трассировки выполняется при помощи утилиты tkprof, поставляемой
в комплекте Oracle Server. Формат вызова команды:
$tkprof trace_file processed_trace_file explain=username/password sort=exeela fchela
где
- trace_file - исходный необработанный файл трассировки;
- processed_trace_file - имя результирующего обработанного файла трассировки;
- username - имя пользователя, под которым работала трассируемая сессия;
- password - пароль пользователя.
Анализ файлов трассировки.
Анализ статистики работы сессии.
Выявление проблемных SQL предложений.
Обработанный файл трассировки состоит из последовательно расположенных
блоков SQL-предложений, выполняемых данной сессией. В конце файла приводится
суммарная статистика по всем SQL-предложениям, выполнявшимся данной сессией.
SQL-предложения в файле располагаются в порядке, зависящем от параметра
sort команды tkprof. Наиболее полезным параметром сортировки является
elapsed time (общее затраченное время). Наибольшее время обычно занимает
процедура выполнения (execute) или выборки (fetch) SQL-предложений,
поэтому используются параметры sort = exeela или sort = fchela соответственно.
tkprof test1_j000_10411.trc test1_j000_10411.prf explain=user/passw@test1 table=user.tun_plan_table sort=(exeela,fchela)
Трассировка сессии
Включение/выключение трассировки. Получение и обработка файлов
Для того чтобы получить файл трассировки заданной сессии необходимо включить
для нее режим трассировки, подождать необходимое для накопления информации
время, выключить режим трассировки и обработать полученный файл.
Иногда может возникнуть необходимость исследования необработанного
файла трассировки. В этом случае для получения более детальной информации
о трассируемом процессе рекомендуется включать трассировку через
Server Manager, используя 12-ый уровень отладки.
Процедура включения / выключения трассировки при помощи SQLPlus
Включение
Для включения трассировки сессии с параметрами SID и SERIAL# необходимо
выполнить из SQLPlus следующую последовательность команд:
SQL>alter system set timed_statistics = true;
SQL>alter system set max_dump_file_size = unlimited;
SQL>exec dbms_system.set_sql_trace_in_session(, , TRUE);
Выключение
Для выключения трассировки сессии с параметрами SID и SERIAL# необходимо
выполнить из SQLPlus следующую последовательность команд:
SQL>exec dbms_system.set_sql_trace_in_session(, , FALSE);
Скрипт: ode.sql
Процедура включения / выключения трассировки при помощи Server Manager
Включение
Для включения трассировки сессии необходимо определить SPID
соответствующего ей процесса и выполнить следующую последовательность
команд:
SVRMGRL> oradebug setospid
SVRMGRL> oradebug unlimit
SVRMGRL> oradebug event 10046 trace name context forever, level 8
или для более детальной информации в необработанном файле трассировки
(в том числе вывода bind переменных и oracle events)
SVRMGRL> oradebug event 10046 trace name context forever, level 12
Выключение
Для выключения трассировки сессии необходимо определить SPID
соответствующего ей процесса и выполнить следующую последовательность
команд:
SVRMGRL> oradebug event 10046 trace name context off
Следует помнить, что остановка трассировки не закрывает созданный файл
в операционной системе, поэтому, если вы начнете трассировку заново,
то информация будет добавляться в уже существующий файл.
При удалении файла трассировки, он не исчезнет до тех пор, пока не будет
принудительно закрыт или не завершится трассируемая сессия.
Для принудительного закрытия файла трассировки следует использовать
следующую команду Server Manager:
SVRMGRL> oradebug setospid
SVRMGRL> oradebug close_trace
Файл трассировки создается в каталоге, указанном в параметре базы данных
background_dump_dest для фоновых процессов или в параметре user_dump_dest
для пользовательскиx процессов.
Имя файла формируется по маске_*_.trc, где
- DBNAME - имя базы данных;
- SPID - идентификатор процесса в UNIX.
Имя файла трассировки также можно узнать, выполнив в Server Manager следующую
последовательность команд:
SVRMGRL> oradebug setospid
SVRMGRL> oradebug tracefile_name
Обработка файла трассировки выполняется при помощи утилиты tkprof, поставляемой
в комплекте Oracle Server. Формат вызова команды:
$tkprof \
explain=/ sort=exeela fchela
где
- - исходный необработанный файл трассировки;
- - имя результирующего обработанного файла
трассировки;
- - имя пользователя, под которым работала трассируемая сес-сия;
- - пароль пользователя.
Анализ файлов трассировки. Анализ статистики работы сессии.
Выявление проблемных SQL.предложений
Обработанный файл трассировки состоит из последовательно расположенных
блоков SQL-предложений, выполняемых данной сессией. В конце файла приводится
суммарная статистика по всем SQL-предложениям, выполнявшимся данной сессией.
SQL-предложения в файле располагаются в порядке, зависящем от параметра
sort команды tkprof. Наиболее полезным параметром сортировки является
elapsed time (общее затраченное время). Наибольшее время обычно занимает
процедура выполнения (execute) или выборки (fetch) SQL-предложений,
поэтому используются параметры sort = exeela или sort = fchela соответственно.
При анализе файла трассировки необходимо обращать внимание на следующие
статистики, сигнализирующие о возможном наличии узких или проблемных мест:
1. Большое общее затраченное время (столбец elapsed).
Большое затраченное процессорное время (столбец cpu) в данном случае
означает, что сессия тратит большое количество процессорного времени
на данную операцию. Возможно проблема в неоптимальном SQL-предложении.
Относительно маленькое затраченное процессорное время (столбец cpu)
означает, что сессия большинство времени простаивает, ожидая выполнения
какого-либо внешнего условия. Необходимо анализировать события ожидания
сессии. Возможно проблема в настройке базы данных.
Большое время, зарачиваемое на разбор (parse) SQL-предложения
сигнализирует о проблемах в настройках памяти базы данных. Возможно
слишком маленький размер shared pool.
2. Большое количество обращений к блокам базы данных (большое суммарное
значение столбцов query и current). Обычно сигнализирует о неверном
плане выполнения SQL-предложения.
3. Большой процент чтений блоков с диска (большое значение отношения
disk/(query + current) может быть вызван неоптимальным планом выполнения
SQL-предложения или неверной настройкой базы данных.
4. Частые разборы SQL-предложений (поле Parse count > 1), скорее всего,
вызваны неверной настройкой размера shared pool.
5. Большое количество вызовов данного SQL-предложения, не согласующееся с
выполняемыми им функциями, возможно вызвано ошибкой в данном программном
модуле.
Наиболее простой и продуктивный метод анализа файла трассировки
- сравнение его с аналогичным файлом трассировки, собранной во время
нормального функционирования программного модуля. Поскольку в различных
файлах обычно содержится информация, накопленная за различное время,
сравнивать следует нормированные значения статистик. Например, можно
поделить все временные статистики SQL-предложения на количество вызовов
той или иной операции, а статистики по обращениям к блокам базы данных
- на количество обработанных записей.
Пример 1
Проблема длительных разборов SQL-предложения.
На 19 разборов было затрачено 691.42 сек. процессорного времени
и прошло 853.79 сек. реального времени. То есть на один разбор
тратится 853/19 = 45 сек. реального времени.
select count(up) from num_calls where up=:up and strt=to_date(:strt,
:d_mask) and dur=:dur and srv_a=:srv_a and ((:num_a is null and num_a is
null) or num_a=:num_a) and ((num is null and :num is null) or num=:num)
and ((:onls='@' and services is null) or :onls=services) and
billpar>:billpar
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 19 691.42 853.79 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 19 691.42 853.79 0 0 0 0
Misses in library cache during parse: 15
Optimizer goal: RULE
Parsing user id: 19 (MTS24E)
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL: RULE
0 SORT (AGGREGATE)
0 PARTITION RANGE (SINGLE) PARTITION:KEYKEY
0 TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'NUM_CALLS'
PARTITION:KEYKEY
0 INDEX (RANGE SCAN) OF 'NUM_CALLS_UP' (NON-UNIQUE)
PARTITION:KEYKEY
Пример 2
Проблема большого количества чтений с диска.
Из файла трассировки следует, что из запрошенных 2157 + 48438 = 50595 блоков
- 7464 прочитано с дисков, что составляет 15% от всего количества.
Кроме того, сильно отличаются elapsed time и cpu time. Это означает,
что сессия простаивает, ожидая выполнения каких либо условий.
В нашем случае - это ожидание чтения блоков с диска.
insert into num_calls (N_BLK, UP ,SRV_A ,SRV_B ,IND_B,STRT ,PTT ,AIR, PTT_TOLL, ptt_toll2,srv_toll,srv_toll2 ,NUM ,DUR ,INCOMING ,OUTGOING ,NUM_A, DIR ,TA, CELL_ID,SERVICES ,STATUS,DSC ,BILLPAR, r_roamfile_seq, AIR_SUB,PTT_SUB, imei,rtype,r_mscid,r_calls_log,utc)
values (decode(:n_blk,:nullnumber,null,:n_blk),:app, decode(:srv_a, :nullnumber,null, :srv_a) ,decode(:srv_b,:nullnumber,null,:srv_b) ,decode(:zoneindex, :nullnumber,null,:zoneindex), to_date(:strt,'yyyymmddhh24miss'), decode(:ptt,:nullnumber,null, round(:ptt,10)) ,decode(:air,:nullnumber,null,round(:air,10)) ,decode(:ptt_toll,:nullnumber,null,round(:ptt_toll,10)) ,
decode(:ptt_toll2, :nullnumber,null, round(:ptt_toll2,10)) ,decode(:srv_toll, :nullnumber,null,:srv_toll) , decode(:srv_toll2, :nullnumber,null, :srv_toll2), :num_b,decode(:dur,:nullnumber,null,:dur) ,decode(:routei,:nullnumber,null, :routei) ,decode(:routeo, :nullnumber, null,:routeo) ,:num_a ,:dir,:ta, :cell_id,:services,'', :dsc,0, decode(:roamfile_seq, :nullnumber,null, :roamfile_seq), decode(:air_sub, :nullnumber,null,:air_sub),null,:imei,:rtype, decode(:r_mscid, :nullnumber,null,:r_mscid), :r_calls_log, decode(:utc,100000,null,:utc))
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 95 13.43 341.97 7464 2157 48438 9500
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 95 13.43 341.97 7464 2157 48438 9500
Поиск причин низкой производительности SQL-предложений.
Анализ планов выполнения SQL-предложений.
Одной из причин замедления работы приложений может быть несоответствие
плана выполнения (Execution Plan) SQL-предложений тому плану, который был
предусмотрен разработчиком при написании программного кода.
В частности, следует обращать внимание на наличие выборок по таблицам в
режиме FULL SCAN, в котором перебираются последовательно все строки таблицы
без использования индекса.
Следует, однако, иметь в виду, что наличие FULL SCAN не является ошибкой
в случаях, когда бизнес-логика запроса действительно требует сканирования
всей таблицы, либо при малом количестве записей в таблице, когда использование
индекса нецелесообразно.
Еще одной из причин несоответствия планов выполнения является наличие
статистики по таблицам и индексам БД. При этом, при отсутствии подсказок
оптимизатор строит план выполнения запроса исходя из данных статистики,
а не в соответствии с правилами разбора SQL-предложений. Т.к. при работе с
приложениями CBOSS предусматривается использование Rule-based optimisation,
то наличие статистики также приводит к искажению планов выполнения.
Также имеет смысл анализировать соответствие плана разбора SQL-предложения
подсказкам оптимизатора, указанным в запросе. Например, если при выполнении
запроса не используются указанные в хинте индексы, то следует проверить
наличие и доступность этих индексов в базе.
Пример:
В данном примере происходит полное сканирование таблицы, содержащей несколько
десятков тысяч строк.
SELECT R_SERVICE
FROM
ENCOURAGEMENTS_TMP WHERE R_APP = :b1 AND COND_ID = :b2 AND ACT_ID = :b3
AND ((:b4 IS NULL AND :b5 BETWEEN FD AND TD ) OR (:b4 IS NOT NULL AND
:b7 IS NULL AND (:b4 < TD AND FD < :b5 )) OR (:b7 IS NOT NULL AND :b7 <
TD )) AND :b12 = SRV_CODE
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 30821 2.83 2.74 0 0 0 0
Fetch 30821 1404.64 1473.50 1604 5035350 123284 13016
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 61642 1407.47 1476.24 1604 5035350 123284 13016
Misses in library cache during parse: 0
Optimizer goal: RULE
Parsing user id: 18 (VOXTEL) (recursive depth: 4)
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL: RULE
0 TABLE ACCESS (FULL) OF 'ENCOURAGEMENTS_TMP'
Анализ необработанных файлов трассировки
Если планируется производить анализ необработанного файла трассировки,
то трассировку сессии следует запускать из Server Manager, используя при
этом 12-й уровень отладки. Полученный таким образом файл будет содержать
кроме обычной статистической информации все переменные, передаваемые
SQL-предложениям и системные события, выполнение которых ожидалось сессией
в процессе ее работы. Кроме того, по необработанному файлу трассировки можно
определить последовательность операций, выполняемых трассируемой сессией.
select s.username
, s.sid
, s.serial#
, s.osuser
, s.machine
, s.terminal
, p.spid
, last_call_et
, status
from V$SESSION s
, V$PROCESS p
where s.PADDR = p.ADDR
and s.sid='123';
Включить трассировку:
BEGIN
SYS.DBMS_System.Set_Ev(156, 13, 10046, 12, '');
END;
/
Отключить трассировку сессии:
BEGIN
SYS.DBMS_System.Set_Ev(156, 13, 10046, 0, '');
END;
/
Файлы трассировок находятся:
show parameter dump_dest
или так:
select name, value
from v$parameter
where name like '%dump_dest%';
set serveroutput on
exec dbms_output.put_line( scott.get_param( 'user_dump_dest' ) )
В 11g так:
with home
as
(select value home
from v$diag_info
where name = 'ADR Home'
)
select name,
case when value <> home.home
then replace(value,home.home,'$home$')
else value
end value
from v$diag_info, home
/
select c.value || '/' || d.instance_name || '_ora_' ||
a.spid || '.trc' ||
case when e.value is not null then '_'||e.value end trace
from v$process a, v$session b, v$parameter c, v$instance d, v$parameter e
where a.addr = b.paddr
and b.audsid = userenv('sessionid')
and c.name = 'user_dump_dest'
and e.name = 'tracefile_identifier'
/
Обработка файлов трассировки:
Обработка файла трассировки выполняется при помощи утилиты tkprof, поставляемой
в комплекте Oracle Server. Формат вызова команды:
$tkprof trace_file processed_trace_file explain=username/password sort=exeela fchela
где
- trace_file - исходный необработанный файл трассировки;
- processed_trace_file - имя результирующего обработанного файла трассировки;
- username - имя пользователя, под которым работала трассируемая сессия;
- password - пароль пользователя.
Анализ файлов трассировки.
Анализ статистики работы сессии.
Выявление проблемных SQL предложений.
Обработанный файл трассировки состоит из последовательно расположенных
блоков SQL-предложений, выполняемых данной сессией. В конце файла приводится
суммарная статистика по всем SQL-предложениям, выполнявшимся данной сессией.
SQL-предложения в файле располагаются в порядке, зависящем от параметра
sort команды tkprof. Наиболее полезным параметром сортировки является
elapsed time (общее затраченное время). Наибольшее время обычно занимает
процедура выполнения (execute) или выборки (fetch) SQL-предложений,
поэтому используются параметры sort = exeela или sort = fchela соответственно.
tkprof test1_j000_10411.trc test1_j000_10411.prf explain=user/passw@test1 table=user.tun_plan_table sort=(exeela,fchela)
Трассировка сессии
Включение/выключение трассировки. Получение и обработка файлов
Для того чтобы получить файл трассировки заданной сессии необходимо включить
для нее режим трассировки, подождать необходимое для накопления информации
время, выключить режим трассировки и обработать полученный файл.
Иногда может возникнуть необходимость исследования необработанного
файла трассировки. В этом случае для получения более детальной информации
о трассируемом процессе рекомендуется включать трассировку через
Server Manager, используя 12-ый уровень отладки.
Процедура включения / выключения трассировки при помощи SQLPlus
Включение
Для включения трассировки сессии с параметрами SID и SERIAL# необходимо
выполнить из SQLPlus следующую последовательность команд:
SQL>alter system set timed_statistics = true;
SQL>alter system set max_dump_file_size = unlimited;
SQL>exec dbms_system.set_sql_trace_in_session(
Выключение
Для выключения трассировки сессии с параметрами SID и SERIAL# необходимо
выполнить из SQLPlus следующую последовательность команд:
SQL>exec dbms_system.set_sql_trace_in_session(
Скрипт: ode.sql
Процедура включения / выключения трассировки при помощи Server Manager
Включение
Для включения трассировки сессии необходимо определить SPID
соответствующего ей процесса и выполнить следующую последовательность
команд:
SVRMGRL> oradebug setospid
SVRMGRL> oradebug unlimit
SVRMGRL> oradebug event 10046 trace name context forever, level 8
или для более детальной информации в необработанном файле трассировки
(в том числе вывода bind переменных и oracle events)
SVRMGRL> oradebug event 10046 trace name context forever, level 12
Выключение
Для выключения трассировки сессии необходимо определить SPID
соответствующего ей процесса и выполнить следующую последовательность
команд:
SVRMGRL> oradebug event 10046 trace name context off
Следует помнить, что остановка трассировки не закрывает созданный файл
в операционной системе, поэтому, если вы начнете трассировку заново,
то информация будет добавляться в уже существующий файл.
При удалении файла трассировки, он не исчезнет до тех пор, пока не будет
принудительно закрыт или не завершится трассируемая сессия.
Для принудительного закрытия файла трассировки следует использовать
следующую команду Server Manager:
SVRMGRL> oradebug setospid
SVRMGRL> oradebug close_trace
Файл трассировки создается в каталоге, указанном в параметре базы данных
background_dump_dest для фоновых процессов или в параметре user_dump_dest
для пользовательскиx процессов.
Имя файла формируется по маске
- DBNAME - имя базы данных;
- SPID - идентификатор процесса в UNIX.
Имя файла трассировки также можно узнать, выполнив в Server Manager следующую
последовательность команд:
SVRMGRL> oradebug setospid
SVRMGRL> oradebug tracefile_name
Обработка файла трассировки выполняется при помощи утилиты tkprof, поставляемой
в комплекте Oracle Server. Формат вызова команды:
$tkprof
explain=
где
-
-
трассировки;
-
-
Анализ файлов трассировки. Анализ статистики работы сессии.
Выявление проблемных SQL.предложений
Обработанный файл трассировки состоит из последовательно расположенных
блоков SQL-предложений, выполняемых данной сессией. В конце файла приводится
суммарная статистика по всем SQL-предложениям, выполнявшимся данной сессией.
SQL-предложения в файле располагаются в порядке, зависящем от параметра
sort команды tkprof. Наиболее полезным параметром сортировки является
elapsed time (общее затраченное время). Наибольшее время обычно занимает
процедура выполнения (execute) или выборки (fetch) SQL-предложений,
поэтому используются параметры sort = exeela или sort = fchela соответственно.
При анализе файла трассировки необходимо обращать внимание на следующие
статистики, сигнализирующие о возможном наличии узких или проблемных мест:
1. Большое общее затраченное время (столбец elapsed).
Большое затраченное процессорное время (столбец cpu) в данном случае
означает, что сессия тратит большое количество процессорного времени
на данную операцию. Возможно проблема в неоптимальном SQL-предложении.
Относительно маленькое затраченное процессорное время (столбец cpu)
означает, что сессия большинство времени простаивает, ожидая выполнения
какого-либо внешнего условия. Необходимо анализировать события ожидания
сессии. Возможно проблема в настройке базы данных.
Большое время, зарачиваемое на разбор (parse) SQL-предложения
сигнализирует о проблемах в настройках памяти базы данных. Возможно
слишком маленький размер shared pool.
2. Большое количество обращений к блокам базы данных (большое суммарное
значение столбцов query и current). Обычно сигнализирует о неверном
плане выполнения SQL-предложения.
3. Большой процент чтений блоков с диска (большое значение отношения
disk/(query + current) может быть вызван неоптимальным планом выполнения
SQL-предложения или неверной настройкой базы данных.
4. Частые разборы SQL-предложений (поле Parse count > 1), скорее всего,
вызваны неверной настройкой размера shared pool.
5. Большое количество вызовов данного SQL-предложения, не согласующееся с
выполняемыми им функциями, возможно вызвано ошибкой в данном программном
модуле.
Наиболее простой и продуктивный метод анализа файла трассировки
- сравнение его с аналогичным файлом трассировки, собранной во время
нормального функционирования программного модуля. Поскольку в различных
файлах обычно содержится информация, накопленная за различное время,
сравнивать следует нормированные значения статистик. Например, можно
поделить все временные статистики SQL-предложения на количество вызовов
той или иной операции, а статистики по обращениям к блокам базы данных
- на количество обработанных записей.
Пример 1
Проблема длительных разборов SQL-предложения.
На 19 разборов было затрачено 691.42 сек. процессорного времени
и прошло 853.79 сек. реального времени. То есть на один разбор
тратится 853/19 = 45 сек. реального времени.
select count(up) from num_calls where up=:up and strt=to_date(:strt,
:d_mask) and dur=:dur and srv_a=:srv_a and ((:num_a is null and num_a is
null) or num_a=:num_a) and ((num is null and :num is null) or num=:num)
and ((:onls='@' and services is null) or :onls=services) and
billpar>:billpar
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 19 691.42 853.79 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 19 691.42 853.79 0 0 0 0
Misses in library cache during parse: 15
Optimizer goal: RULE
Parsing user id: 19 (MTS24E)
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL: RULE
0 SORT (AGGREGATE)
0 PARTITION RANGE (SINGLE) PARTITION:KEYKEY
0 TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'NUM_CALLS'
PARTITION:KEYKEY
0 INDEX (RANGE SCAN) OF 'NUM_CALLS_UP' (NON-UNIQUE)
PARTITION:KEYKEY
Пример 2
Проблема большого количества чтений с диска.
Из файла трассировки следует, что из запрошенных 2157 + 48438 = 50595 блоков
- 7464 прочитано с дисков, что составляет 15% от всего количества.
Кроме того, сильно отличаются elapsed time и cpu time. Это означает,
что сессия простаивает, ожидая выполнения каких либо условий.
В нашем случае - это ожидание чтения блоков с диска.
insert into num_calls (N_BLK, UP ,SRV_A ,SRV_B ,IND_B,STRT ,PTT ,AIR, PTT_TOLL, ptt_toll2,srv_toll,srv_toll2 ,NUM ,DUR ,INCOMING ,OUTGOING ,NUM_A, DIR ,TA, CELL_ID,SERVICES ,STATUS,DSC ,BILLPAR, r_roamfile_seq, AIR_SUB,PTT_SUB, imei,rtype,r_mscid,r_calls_log,utc)
values (decode(:n_blk,:nullnumber,null,:n_blk),:app, decode(:srv_a, :nullnumber,null, :srv_a) ,decode(:srv_b,:nullnumber,null,:srv_b) ,decode(:zoneindex, :nullnumber,null,:zoneindex), to_date(:strt,'yyyymmddhh24miss'), decode(:ptt,:nullnumber,null, round(:ptt,10)) ,decode(:air,:nullnumber,null,round(:air,10)) ,decode(:ptt_toll,:nullnumber,null,round(:ptt_toll,10)) ,
decode(:ptt_toll2, :nullnumber,null, round(:ptt_toll2,10)) ,decode(:srv_toll, :nullnumber,null,:srv_toll) , decode(:srv_toll2, :nullnumber,null, :srv_toll2), :num_b,decode(:dur,:nullnumber,null,:dur) ,decode(:routei,:nullnumber,null, :routei) ,decode(:routeo, :nullnumber, null,:routeo) ,:num_a ,:dir,:ta, :cell_id,:services,'', :dsc,0, decode(:roamfile_seq, :nullnumber,null, :roamfile_seq), decode(:air_sub, :nullnumber,null,:air_sub),null,:imei,:rtype, decode(:r_mscid, :nullnumber,null,:r_mscid), :r_calls_log, decode(:utc,100000,null,:utc))
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 95 13.43 341.97 7464 2157 48438 9500
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 95 13.43 341.97 7464 2157 48438 9500
Поиск причин низкой производительности SQL-предложений.
Анализ планов выполнения SQL-предложений.
Одной из причин замедления работы приложений может быть несоответствие
плана выполнения (Execution Plan) SQL-предложений тому плану, который был
предусмотрен разработчиком при написании программного кода.
В частности, следует обращать внимание на наличие выборок по таблицам в
режиме FULL SCAN, в котором перебираются последовательно все строки таблицы
без использования индекса.
Следует, однако, иметь в виду, что наличие FULL SCAN не является ошибкой
в случаях, когда бизнес-логика запроса действительно требует сканирования
всей таблицы, либо при малом количестве записей в таблице, когда использование
индекса нецелесообразно.
Еще одной из причин несоответствия планов выполнения является наличие
статистики по таблицам и индексам БД. При этом, при отсутствии подсказок
оптимизатор строит план выполнения запроса исходя из данных статистики,
а не в соответствии с правилами разбора SQL-предложений. Т.к. при работе с
приложениями CBOSS предусматривается использование Rule-based optimisation,
то наличие статистики также приводит к искажению планов выполнения.
Также имеет смысл анализировать соответствие плана разбора SQL-предложения
подсказкам оптимизатора, указанным в запросе. Например, если при выполнении
запроса не используются указанные в хинте индексы, то следует проверить
наличие и доступность этих индексов в базе.
Пример:
В данном примере происходит полное сканирование таблицы, содержащей несколько
десятков тысяч строк.
SELECT R_SERVICE
FROM
ENCOURAGEMENTS_TMP WHERE R_APP = :b1 AND COND_ID = :b2 AND ACT_ID = :b3
AND ((:b4 IS NULL AND :b5 BETWEEN FD AND TD ) OR (:b4 IS NOT NULL AND
:b7 IS NULL AND (:b4 < TD AND FD < :b5 )) OR (:b7 IS NOT NULL AND :b7 <
TD )) AND :b12 = SRV_CODE
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 30821 2.83 2.74 0 0 0 0
Fetch 30821 1404.64 1473.50 1604 5035350 123284 13016
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 61642 1407.47 1476.24 1604 5035350 123284 13016
Misses in library cache during parse: 0
Optimizer goal: RULE
Parsing user id: 18 (VOXTEL) (recursive depth: 4)
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL: RULE
0 TABLE ACCESS (FULL) OF 'ENCOURAGEMENTS_TMP'
Анализ необработанных файлов трассировки
Если планируется производить анализ необработанного файла трассировки,
то трассировку сессии следует запускать из Server Manager, используя при
этом 12-й уровень отладки. Полученный таким образом файл будет содержать
кроме обычной статистической информации все переменные, передаваемые
SQL-предложениям и системные события, выполнение которых ожидалось сессией
в процессе ее работы. Кроме того, по необработанному файлу трассировки можно
определить последовательность операций, выполняемых трассируемой сессией.
Комментариев нет:
Отправить комментарий