Эквивалент трассировки SQL Server для Oracle 10g? - PullRequest
3 голосов
/ 16 сентября 2011

У меня проблема с дублированием кода, из-за которой мы не можем сказать, какие версии пакетов / процедур используются.то есть у меня разные пакеты с процедурами с одинаковым именем, и мне нужно быть уверенным, какие пакеты на самом деле не вызываются.

Я пытаюсь удалить процедуры / пакеты с тем же именем, которые больше не вызываются,Я хотел бы запустить трассировку в течение нескольких недель, объединить данные и запросить к ним метаданные и найти кандидатов для дальнейшего изучения и деактивации.

Я ищу эквивалент sp_trace_create SQL Server с sp_trace_setevent42, чтобы отслеживать событие SP: Starting - это позволило бы мне увидеть все хранимые процедуры, которые были вызваны, а затем сравнить их со всем списком хранимых процедур, чтобы увидеть, какие из них следует сначала исследовать на предмет их устаревания.Я использовал DBMS_MONITOR.DATABASE_TRACE_ENABLE для генерации файлов трассировки, но я не нашел ничего, что объясняло бы, как использовать TKPROF для анализа этих файлов ни для чего, кроме производительности - и мне даже не безразличны сами операторы, какие подпрограммы используются.

Ответы [ 4 ]

3 голосов
/ 24 сентября 2011

Не думаю, что ILO поможет (она делает больше, чем просто устанавливает модуль и действие и регистрирует время где-нибудь?), Поскольку Cade Roux придется модифицировать каждый пакет и функцию в базе данных.

Один из вариантов - включить трассировку в базе данных,

 ALTER SYSTEM SET sql_trace = true SCOPE=MEMORY;

и используйте команду script, чтобы получить уникальный список всех имен выполненных пакетов, хотя ПРЕДУПРЕЖДЕНИЕ - это сгенерирует много выходных данных и очень быстро заполнит дисковое пространство - возможно, вы захотите создать файл из процедур, выполняемых каждый день, а затем удалите файлы trc и затем объедините результаты вместе, чтобы определить, какие из них используются.

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

 alter system set max_dump_file_size=unlimited;
 alter system set timed_statistics=false;

Если я посмотрю на необработанные файлы трассировки, созданные из трассировки Oracle, каждый вызов процедуры вызова пакета для конкретного приложения выглядит следующим образом

=====================
PARSING IN CURSOR #2 len=69 dep=0 uid=102 oct=47 lid=102 tim=1316845390611021 hv=273704950   
 ad='b0d4c728' sqlid='01qnrr4850tzq'
BEGIN REIM_MATCH_SQL.INIT_SUMMARY_MATCH(:1, :2, :3, :4, :5, :6); END;
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,plh=0,tim=1316845390611021

так что вы можете использовать grep для получения списка вызовов пакетов, подобных этому, в каталоге (возможно, вам придется немного подправить вывод в зависимости от используемой ОС, если вывод tkprof отличается)

find . -name "*.trc" -exec grep "BEGIN " {} \; | cut -d" " -f4 | cut -d"(" -f1 | sort -u > ~/called_procedures.txt

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

Я выполнил это в каталоге, содержащем 9818 файлов трассировки общим объемом 19 ГБ на диске, и это заняло 10 минут на тестовом компьютере под управлением Oracle Enterprise Linux 5 с 2 ядрами и 12 ГБ памяти - эти файлы трассировки только из повторных тестовых прогонов одной программы, чтобы вы могли представить, как быстро они будут созданы, если вы создаете все для рабочей машины.

Затем вы можете получить список всех пакетов / процедур в базе данных из sqlplus для конкретной схемы, которая вас интересует

set heading off
set trimspool on
set pagesize 0
set feedback off
spool all_procedures.txt 
SELECT DISTINCT p.object_name||'.'||p.procedure_name
  FROM all_procedures p
  JOIN all_objects o ON (o.owner = p.owner AND o.object_name = p.object_name AND o.object_type =
 where p.owner='&owner'
 order by 1
spool off

и, наконец, проведите различие между ними, чтобы получить список кандидатов

diff all_procedures.txt called_procedures.txt

Не забудьте отключить трассировку, когда закончите

ALTER SYSTEM SET sql_trace = false SCOPE=MEMORY;

Кроме того, вы должны быть осторожны с процедурами, которые могут выполняться только в определенные периоды, такие как конец месяца или конец года - они могут показаться неиспользуемыми, но вы не можете быть уверены, если каждый бизнес-процесс не будет завершен в то время, когда вы ведем мониторинг.

Надеюсь, это поможет.

1 голос
/ 25 сентября 2011

Работающая база данных Oracle отслеживает количество выполнений для всех объектов базы данных.Доступ к нему можно получить через представление v $ db_object_cache.

select * from v$db_object_cache
where type in ('PROCEDURE');

Те, которые вам не нужны, либо вообще не будут отображаться в списке (никогда не загружены), либо будут перечислены с 0 выполнениями.

0 голосов
/ 20 сентября 2011

Вы можете автоматизировать это, вызвав DBMS_PROFILER из триггера LOGON и LOGOFF схемы.

--Run this script to install the profiler objects for the user
@...\RDBMS\ADMIN\proftab.sql


--Create some objects for testing
create or replace function test1 return varchar2 is
begin return 'test1'; end;
/

create or replace function test2 return varchar2 is
begin return test1(); end;
/

create or replace package test3 is
    function test4 return varchar2;
    function test5 return varchar2;
end;
/

create or replace package body test3 is
    function test4 return varchar2 is begin return test2(); end;
    function test5 return varchar2 is begin return 'test5'; end;
end;
/

--Create the LOGON trigger to start profiling
create or replace trigger profiler_logon after logon on test_schema.schema
begin
    dbms_profiler.start_profiler(run_comment => sysdate);
end;
/


--Create the LOGOFF trigger to write the profiling data
create or replace trigger profiler_logoff before logoff on test_schema.schema
begin
    dbms_profiler.stop_profiler();
    dbms_profiler.flush_data();
end;
/


--Logon, run this:
select test3.test4() from dual;
select test3.test5() from dual;
--Logoff, logon, run this:
select test1() from dual;
--Logoff, logon to see results



--The data is stored in these tables.
select * from plsql_profiler_runs;
select * from plsql_profiler_units;
select * from plsql_profiler_data;


--Use a query like this to find the most common objects.
--But total_occur is both too low and too high:
--  It records at the object level, test4 and test5 are combined.
--  It seems to double many counts - maybe an extra call for initializing?
select unit_type, unit_owner, unit_name, sum(total_occur) total_occur
from plsql_profiler_units
join
(
    --Get max number of times any line number was called.
    select runid, unit_number, max(total_occur) total_occur
    from plsql_profiler_data
    where total_occur > 0
    group by runid, unit_number
) profiler_data
    on plsql_profiler_units.unit_number = profiler_data.unit_number
    and plsql_profiler_units.runid = profiler_data.runid
where plsql_profiler_units.unit_type <> 'ANONYMOUS BLOCK'
group by unit_type, unit_owner, unit_name
order by total_occur desc, unit_type, unit_owner, unit_name;


UNIT_TYPE       UNIT_OWNER      UNIT_NAME   TOTAL_OCCUR
---------       ----------      ---------   -----------
FUNCTION        TEST_SCHEMA     TEST1       4
FUNCTION        TEST_SCHEMA     TEST2       2
PACKAGE BODY    TEST_SCHEMA     TEST3       2

Но здесь есть много проблем:

  1. Производительность - Профилирование добавляет много накладных расходов?Я никогда не использовал его раньше таким образом, я не думаю, что он был предназначен для долгосрочного использования в производстве.Возможно, вам придется периодически удалять или обрезать данные.Или, возможно, изменить некоторые таблицы в proftab.sql;например, удалить некоторые индексы и внешние ключи.(Хотя я не пробовал этого, это может ухудшить ситуацию!)

  2. Тихая ошибка - если что-то не может быть профилировано, оно просто не будет отображаться.Вы должны быть очень осторожны, чтобы он работал правильно для всех схем и объектов.Из ссылки: "Профилировщик собирает данные только для блоков, для которых пользователь имеет привилегию CREATE; вы не можете использовать пакет для профилирования блоков, для которых был предоставлен доступ только EXECUTE ONLY. В общем, если пользователь может отлаживать блоктот же пользователь может профилировать его. Однако модуль может быть профилирован независимо от того, был ли он откомпилирован DEBUG. Oracle рекомендует, чтобы профилируемые модули были откомпилированы DEBUG, поскольку это предоставляет дополнительную информацию о модуле в базе данных. "

  3. Нет простого способа определить, какая функция или процедура внутри пакета использовалась.Чтобы получить эту информацию, вам нужно сравнить номера строк от dba_source.line до plsql_profiler_data.line #.К сожалению, эти запросы могут быть безумно сложными, потому что вам нужно проанализировать PL / SQL.В зависимости от того, насколько чист и прост ваш код, может быть проще вручную выполнить код и создать таблицу с соответствующими номерами функций и начала и конца строки.

  4. Проблемы сеанса- триггеры выхода из системы иногда терпят неудачу?Если соединение потеряно или имеется серьезная ошибка базы данных, я думаю, что не будет срабатывать триггер выхода из системы.В этом случае информация о профилировщике не будет записана в таблицы.

  5. Вам необходимо настроить это для всех пользователей и объединить их данные.Или, возможно, вы можете заменить таблицы с синонимами на общие таблицы?

  6. Вам придется фильтровать много мусора, например, анонимные блоки и другие странные записи.

0 голосов
/ 16 сентября 2011

Функциональность Oracle Trace была удалена из Oracle 10g. Вместо этого следует использовать функции SQL Trace и TKPROF.

В многоуровневых средах, где операторы передают серверу приложений различные сеансы, может возникнуть сложность отследить отдельный процесс от начала до конца. Чтобы решить эту проблему, Oracle ввела сквозную трассировку приложений, которая позволяет идентифицировать процесс клиента с помощью идентификатора клиента, а не типичного идентификатора сеанса. Каждый фрагмент информации трассировки связан со следующей информацией.

  • Идентификатор клиента - указывает «реального» конечного пользователя. Установить с помощью DBMS_SESSION.SET_IDENTIFIER процедура.
  • Сервис - указывает группу связанных приложений. Создано с помощью процедура DBMS_SERVICE.CREATE_SERVICE.
  • Модуль - Определяет функциональную область или функцию приложения. Установить с помощью процедуры DBMS_APPLICATION_INFO.SET_MODULE.
  • Действие - указывает текущее действие (INSERT, UPDATE, DELETE и т. Д.) в текущем модуле. Установить с помощью Процедура DBMS_APPLICATION_INFO.SET_ACTION.

Справка:

http://www.oracle -base.com / статьи / 10г / PerformanceTuningEnhancements10g.php # tracing_enhancements

...