21

DBMS_OUTPUT の使用を置き換えるために、既存の Oracle アプリケーションにロギング フレームワークを導入しようと考えています。

フレームワークは、主にデバッグを支援するために使用され、x プロシージャの開始、パラメーターの詳細、プロシージャ x の終了などの詳細を示します。また、すべてまたは 1 つのプログラム ユニット、さまざまなレベルのトレースに対して有効にする機能も備えている必要があります。実際、ほとんど標準的なロギング機能です。

これらの要件の実装は比較的簡単ですが、この機能をオフまたはオンにする最善の方法を教えてください。私が達成しようとしているのは、トレースがオフになっているときのパフォーマンスへの影響を最小限に抑えることです。うまくいけば、ほとんどの場合はそうなるはずです!

アプリケーションは 10g リリース 2 を使用しているため、最初はロギング メカニズムを条件付きコンパイル内にラップして、通常の操作中にロギング フレームワークが表示されないようにする外観が気に入りました。残念ながら、ほとんどのアプリケーションはスタンドアロンのプロシージャと関数を使用して構築されているため、このアイデアをしぶしぶ放棄する必要がありました。そのため、ログ機能をオンにすると多くのコードが無効になる可能性があります。

インスピレーションを得るために、いくつかの既存のオープンソースと他のフレームワーク\機能を調べました。

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

ここでのAPCのレビューは 、特に許容できる影響の下で、私に懸念を与えます.

OraLog プロジェクト ( http://oralog.sourceforge.net )

2007年以降更新なし

PL/VISIONこちら

かなり古いように見えますが、Oracle 8i から変更はありませんか?

Tom Instrumentationに問い合わせる(ここ)

更新 01/04/2014 Tom Kyteが Tyler Muth のLoggerを推奨

なんらかの形式のログインを Oracle アプリケーションに導入した場合、それをどのように実装したか、特にどのように制御したかについて、その経験をお聞きしたいと思います。

4

4 に答える 4

8

カスケード無効化の可能性があるため、条件付きコンパイルのアイデアを破棄することに言及しました-有効にするための再コンパイルを伴わないロギング/トレースが必要なPL/SQLソースに触れても構わないと思っている場合、多少似たアプローチがあります。

独自に選択した名前と値のペアを PLSQL_CCFLAGS に追加し、アプリケーション コードで v$parameter の比較的軽量なクエリを実行して、ロギングが「オン」になっているかどうかを判断できます。最も粗雑な実装は 1 つの名前と値のペアになりますが、これを拡張してモジュール固有の異なるペアを作成し、より細かい粒度でログ記録をオンにすることができます。

[編集] コメント/リクエストに応じた非常に単純な例を次に示します。 PLSQL_CCFLAGS 文字列に他の既存の情報が含まれている場合、おそらく関数にラップされている場合などに備えて、 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='';

于 2009-08-05T13:07:44.713 に答える
3

このアプリケーションでは、Ask Tom の debug.f インストルメンテーションを多用しています。私がすぐに気づいたことの 1 つは、'debugtab' へのクエリが多すぎて、ログ メッセージごとにログがオンになっているかどうかを確認できないことでした。100 ログ メッセージごとに 1 回だけテーブルをチェックするように変更を加えましたが、今ではかなりうまく機能しています。

私のポイントは、各ログメッセージのテーブルをチェックして、出力する必要があるかどうかを確認することを避けようとすることです。多くの場合、長時間実行されているプロセスの途中でログをオンにしたいので、それができることが重要です。私の場合、ロギングがオンになっていることに実際に気付く前に、100 回のロギング呼び出しが経過するまで数秒待つことにしました。

于 2009-08-05T12:24:22.983 に答える
1

コンテキストをセットアップしてそれに名前と値のペアを追加する方が簡単ではないでしょうか? debugtab テーブルでトリガーを使用して、コンテキスト内の値を変更できます。

于 2010-01-14T23:48:33.737 に答える