PL / SQL Logging - Как контролировать?

Question

Я собираюсь ввести каркас ведения журнала в наше существующее приложение Oracle, чтобы заменить использование DBMS_OUTPUT.

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

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

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

Я посмотрел несколько существующих с открытым исходным кодом и другие фреймворки \ функциональность для вдохновения:

log4plsql (http://log4plsql.sourceforge.net/)

Обзор APC здесь особенно под приемлемым воздействием вызывает у меня беспокойство.

Проект OraLog (http://oralog.sourceforge.net)

Нет обновлений с 2007 года

PL / VISION ( здесь )

Выглядит довольно старым, никаких изменений со времен Oracle 8i?

Спросите Тома Instrumentation ( здесь )

Обновление 01/04/2014 Tom Kyte теперь рекомендует Tyler Muth's Logger

Мне было бы очень интересно услышать ваш опыт, если вы ввели некоторую форму входа в свое приложение Oracle, как вы реализовали это и особенно, как вы им управляете.

Answer 1

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

Вы по-прежнему можете добавить собственную пару имя / значение в PLSQL_CCFLAGS и сделать так, чтобы код вашего приложения выполнил относительно легкий запрос параметра v $, чтобы определить, включено ли ведение журнала. Самая грубая реализация была бы одной парой имя / значение, но вы могли бы расширить это, чтобы иметь разные пары, которые были бы специфичны для модуля, так что регистрация могла бы быть включена с большей детализацией.

[Изменить] Вот очень простой пример в ответ на ваш комментарий / запрос - вы, очевидно, захотите быть более изощренным в разборе строки PLSQL_CCFLAGS в случае, если она содержит другую существующую информацию, возможно, заключена в функцию и т. Д.:

create or replace procedure ianc_cc
is
cc_flag_val varchar2(4000);
begin 
-- need direct select grant on v_$parameter for this...
select value into cc_flag_val 
  from v$parameter where name = 'plsql_ccflags';
if (cc_flag_val = 'custom_logging:true') then
  dbms_output.put_line('custom logging is on'); 
else  
  dbms_output.put_line('custom logging is off'); 
end if;
end;
/

Теперь, как пользователь, имеющий право выдавать ALTER SYSTEM:

ALTER SYSTEM set PLSQL_CCFLAGS = 'custom_logging: true';

и переключиться обратно на:

ALTER SYSTEM set PLSQL_CCFLAGS = '';

Answer 2

Рассматривая ту же проблему и обнаружив, что следующий проект все еще активен, https://github.com/tmuth/Logger---A-PL-SQL-Logging-Utility

Answer 3

В нашем приложении мы интенсивно используем инструментарий Debug.f от Ask Tom. Одна вещь, которую я быстро заметил, заключалась в том, что «debugtab» получал слишком много запросов, чтобы посмотреть, была ли запись в журнал для каждого отдельного сообщения журнала. Я взломал его, чтобы проверять таблицу только один раз каждые 100 сообщений журнала, и теперь она работает довольно хорошо.

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

Answer 4

Не проще ли настроить контекст и добавить к нему пару «имя-значение»? Вы можете изменить значение в контексте, используя триггер в вашей таблице отладки.