PL / SQL Logging-как управлять?

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

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

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

поскольку приложение использует 10G release 2, мне изначально понравился внешний вид обертывания механизма ведения журнала внутри условной компиляции, чтобы logging framework даже не виден во время нормальной работы. К сожалению, мне пришлось неохотно отказаться от этой идеи, поскольку большая часть приложения построена с использованием процедур и функций stand-a-lone, поэтому включение функции ведения журнала может потенциально аннулировать много кода.

Мне пришлось посмотреть несколько существующих OpenSource и других фреймворковfunctionality для вдохновения:

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

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

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

нет обновлений с 2007

PL / VISION (здесь)

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

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

обновление 01/04/2014 Тома Кайт теперь рекомендует Тайлер Мут регистратор

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

19
instrumentation oracle oracle10g plsql

4 ответов

вы упомянули об отказе от идеи условной компиляции из - за потенциальных каскадных недействительности-существует подход, который несколько похож, если вы хотите коснуться источника 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=";

6

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

5

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

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

3

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

1