気づいたら、年の瀬であり、今年も終わってしまいますね。
12月は、ほとんど投稿ができなかったのは反省。年明けは、2-3日に1Postを継続したいな
2012年12月31日月曜日
2012年11月30日金曜日
Oracle Transparent Gateway / Oracle Connectivity→ Oracle Gateway
Oracle Connectivityと呼ばれていた機能が、Oracle Transparent Gatewayと合わさり、Oracle Gatewayという名前に変えて、11gより展開されている。無償という話だが、本当か。
Oracle & MySQLで検証してみるか。
2012年11月27日火曜日
emacs org-mode memo
Emacs23から同梱されたアウトラインエディタ。
ファイルの拡張子を.orgにすることで自動的にモード変更される。
アウトライン編集、箇条書きのリスト化、表入力
[Command]
TAB
M-RET
ファイルの拡張子を.orgにすることで自動的にモード変更される。
アウトライン編集、箇条書きのリスト化、表入力
[Command]
TAB
M-RET
2012年11月22日木曜日
2012年11月21日水曜日
DRIVING_SITE memo
DRIVING_SITE
ヒントを使用すると、問合せが実行されるサイトを指定可能。オプティマイザを無効にする場合は、手動で実行サイトを指定。
データベースリンク間で非効率な実行計画が実行されている場合、本ヒントも有効。
もしくはジョインをどちらかのテーブルに寄せる。 これは設計が元々悪いのか!
2012年11月20日火曜日
スキーマ・オブジェクトの依存性
依存オブジェクトと参照オブジェクトについては良く言われている。
昔の時代は、依存性が正しい形であっても、実行時エラーで落ちるような時代があった認識している。(昔からオラクルを触っているメンバーは、皆そう言う人が多い。)
しかし、今のマニュアルを参照する限り、実行時もしくは参照時に検証、再コンパイル行うの、問題がないと記述されている。但し、その影響として、以下2点があると書かれている。
1. 無効になったオブジェクトが多数ある場合は、初期実行時の待機時間が長時間になる可能性がある。 (但し、逆を言えば、依存性を見つつ、再コンパイルしているということ、と理解している。)
2. 無効になったオブジェクトを別セッションで同時に実行していた場合、以下のORAエラーが発生する。
ORA-04061 -- stringの既存状態は無効になりました。
原因: プロシージャが変更または削除されたため、無効になった既存状態またはストアド・プロ
シージャと矛盾が発生した既存状態を使用して、ストアド・プロシージャの実行を再開しよ
うとしました。
処置: 再試行してください。このエラーでは、すべてのパッケージの既存状態に再初期化が
必要です。
ORA-04064 --- 実行されませんでした。stringは無効になりました
原因: 無効になったストアド・プロシージャを実行しようとしました。
処置: 再コンパイルしてください。
ORA-04065 ---実行されませんでした。stringを変更または削除しています
原因: 変更または削除されたストアド・プロシージャを実行しようとしたため、コール元プロシー
ジャからのコールができません。
処置: その依存関係を再コンパイルしてください。
ORA-04068 ---パッケージstringstringstringの既存状態は廃棄されました。
原因: ストアド・プロシージャを実行しようとして、4060から4067のいずれかのエラーが発生し
した。
処置: アプリケーション状態を完全に再初期化してから、プロシージャを再試行してください。
上のマニュアルを信じる場合、間違ったオブジェクトをUpせず、アプリ処理を無風状態にしておけば、どんなにInvalidが増えても、時間をかければ自動的にValidになるということで、昔の時代の認識は、もう過去のものということになる。本当かな?
あと、コンパイル系の検証、再コンパイルは、DBMS_UTILITY(11gのリンク)、UTL_RECOMP(11gのリンク)が有効。
昔の時代は、依存性が正しい形であっても、実行時エラーで落ちるような時代があった認識している。(昔からオラクルを触っているメンバーは、皆そう言う人が多い。)
しかし、今のマニュアルを参照する限り、実行時もしくは参照時に検証、再コンパイル行うの、問題がないと記述されている。但し、その影響として、以下2点があると書かれている。
1. 無効になったオブジェクトが多数ある場合は、初期実行時の待機時間が長時間になる可能性がある。 (但し、逆を言えば、依存性を見つつ、再コンパイルしているということ、と理解している。)
2. 無効になったオブジェクトを別セッションで同時に実行していた場合、以下のORAエラーが発生する。
ORA-04061 -- stringの既存状態は無効になりました。
原因: プロシージャが変更または削除されたため、無効になった既存状態またはストアド・プロ
シージャと矛盾が発生した既存状態を使用して、ストアド・プロシージャの実行を再開しよ
うとしました。
処置: 再試行してください。このエラーでは、すべてのパッケージの既存状態に再初期化が
必要です。
ORA-04064 --- 実行されませんでした。stringは無効になりました
原因: 無効になったストアド・プロシージャを実行しようとしました。
処置: 再コンパイルしてください。
ORA-04065 ---実行されませんでした。stringを変更または削除しています
原因: 変更または削除されたストアド・プロシージャを実行しようとしたため、コール元プロシー
ジャからのコールができません。
処置: その依存関係を再コンパイルしてください。
ORA-04068 ---パッケージstringstringstringの既存状態は廃棄されました。
原因: ストアド・プロシージャを実行しようとして、4060から4067のいずれかのエラーが発生し
した。
処置: アプリケーション状態を完全に再初期化してから、プロシージャを再試行してください。
上のマニュアルを信じる場合、間違ったオブジェクトをUpせず、アプリ処理を無風状態にしておけば、どんなにInvalidが増えても、時間をかければ自動的にValidになるということで、昔の時代の認識は、もう過去のものということになる。本当かな?
あと、コンパイル系の検証、再コンパイルは、DBMS_UTILITY(11gのリンク)、UTL_RECOMP(11gのリンク)が有効。
2012年11月15日木曜日
Think occasionally
本番機で稼動しているプログラムを参考にプログラムを書くことがある。コーディング規準の形に沿っているので、作業がしやすい為である。ただ、ソースをよく読んでいくと、まったく機能していないエラーハンドリングとかをよく見つける。この開発者は本当にテストを実施してきたのだろうかと疑問に思う。これでイイと思って、ロクにテストもしていないことがわかるプログラム程、いやなものはない。
2012年11月12日月曜日
DataPump 11g R2
11gR2版。TABLE_EXISTS_ACTIONのパラメータの動きに注意。
Oracle Data Pump Import(impdp) のパラメータ
http://docs.oracle.com/cd/E16338_01/server.112/b56303/dp_import.htm#i1010670
Oracle Data Pump Export(impdp) のパラメータ
http://docs.oracle.com/cd/E16338_01/server.112/b56303/dp_export.htm#i1006293
あと、方法としては以下の3つ。通常使うのは1番が多いけど。PL/SQL内で完結させることもできるということがわかった。
Oracle Data Pump Import(impdp) のパラメータ
http://docs.oracle.com/cd/E16338_01/server.112/b56303/dp_import.htm#i1010670
Oracle Data Pump Export(impdp) のパラメータ
http://docs.oracle.com/cd/E16338_01/server.112/b56303/dp_export.htm#i1006293
あと、方法としては以下の3つ。通常使うのは1番が多いけど。PL/SQL内で完結させることもできるということがわかった。
- コマンドライン・クライアントexpdpおよびimpdp
- PL/SQLパッケージDBMS_DATAPUMP
- PL/SQLパッケージDBMS_METADATA
2012年11月5日月曜日
SQL Plan Management
共有SQL領域から実行計画をロードすることも可能。便利だ。
DECLARE
my plan PLS_INTEGER
BEGIN
my plan := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE( sql_id = > 'SQL_ID' );
END;
/
oracle manual
[構文]

DECLARE
my plan PLS_INTEGER
BEGIN
my plan := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE( sql_id = > 'SQL_ID' );
END;
/
oracle manual
[構文]
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE ( sql_id IN VARCHAR2, plan_hash_value IN NUMBER := NULL, sql_text IN CLOB, fixed IN VARCHAR2 := 'NO', enabled IN VARCHAR2 := 'YES') RETURN PLS_INTEGER; DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE ( sql_id IN VARCHAR2, plan_hash_value IN NUMBER := NULL, sql_handle IN VARCHAR2, fixed IN VARCHAR2 := 'NO', enabled IN VARCHAR2 := 'YES') RETURN PLS_INTEGER; DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE ( sql_id IN VARCHAR2, plan_hash_value IN NUMBER := NULL, fixed IN VARCHAR2 := 'NO', enabled IN VARCHAR2 := 'YES') RETURN PLS_INTEGER; DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE ( attribute_name IN VARCHAR2, attribute_value IN VARCHAR2, fixed IN VARCHAR2 := 'NO', enabled IN VARCHAR2 := 'YES') RETURN PLS_INTEGER;
【パラメータ】
2012年10月30日火曜日
Outline & OAF
後で詳細にトレースすること。
OAFで実行されるSQLをStored Outline化し、DBA_OUTLINES、V$SQLを参照して、使われるかどうかを見たが、使われず。一度ログオフして、再度参照するとDBA_OUTLINEのUSE列が変化した。VO側のキャッシュのせいなのだろうか?
OAFで実行されるSQLをStored Outline化し、DBA_OUTLINES、V$SQLを参照して、使われるかどうかを見たが、使われず。一度ログオフして、再度参照するとDBA_OUTLINEのUSE列が変化した。VO側のキャッシュのせいなのだろうか?
ラベル:
Info:OracleEBS12
2012年10月27日土曜日
Migrate From Stored Outline To SQL Plan Management
Stored Outlineは次バージョン以降で廃止が予定されているということで、SQL Plan Management Plan(以下、SPM)をオラクルは今後推奨。また、Stored OutlineからSPMへのi移行を実施するパッケージ・プロシージャが提供されている。
【必要な権限】
DBMS_SPMパッケージに対する実行権限
だと思う。
【移行方法】
【必要な権限】
DBMS_SPMパッケージに対する実行権限
ADMINISTER
SQL
MANAGEMENT
OBJECT権限
だと思う。
【移行方法】
DBA_OUTLINES のMIGRATED列が 'NOT-MIGRATED'のアウトラインが、移行前のアウトラインである。 DBMS_SPM.MIGRATE_STORED_OUTLINE ファンクションを使用してアウトラインを ベースラインに移行するCATEGORY 列を用いて対象を絞り込んで移行するには以下の様に設定する。 ----------------------- DECLARE my_rep CLOB; BEGIN my_rep := DBMS_SPM.MIGRATE_STORED_OUTLINE( attribute_name => 'CATEGORYの列を指定', attribute_value => 'OUTLINE名を指定' ); END; / ----------------------【格納されているベースラインの実行計画を見る方法】
select * from table(dbms_xplan.display_sql_plan_baseline(sql_handle=>'XXXXXX'));
【格納されているベースラインを使用したかどうかを確認する方法】 Stored Outlineでは、DBA_OUTLINESやV$SQLを参照するとアウトラインを使用したかどうかが わかるが、ベースラインでは、そのようなビューは見当たらない。あくませ、Acceptedしている かどうかである。 その場合、 1. set autotrace traceonly explainでNotesを見るか 2. select * from table(dbms_xplan.display_cursor('SQL_ID','CHILD_NUMBER')); でSQL_IDとCHILD_NUMBERを指定してNotesを見るかのどちらかである。'XXXXXX'は、dba_sql_plan_baselinesビューのsql_handle列を指定する。
2012年10月25日木曜日
emacs -- config --
とりあえず。勉強は続ける。
;; ツールバーを非表示
(tool-bar-mode 0)
;; カラム数を表示
(column-number-mode t)
;; TABの表示幅
(setq-default tab-width 4)
;; 時計の表示
(display-time-mode t)
;; 行番号を常に表示する
(global-linum-mode t)
;; Title Bar
(setq frame-title-format "%f")
;; cua-modeの設定
(cua-mode t) ; cua-mode on
(setq cua-enable-cua-keys nil) ; CUAキーバインドを無効
;; ツールバーを非表示
(tool-bar-mode 0)
;; カラム数を表示
(column-number-mode t)
;; TABの表示幅
(setq-default tab-width 4)
;; 時計の表示
(display-time-mode t)
;; 行番号を常に表示する
(global-linum-mode t)
;; Title Bar
(setq frame-title-format "%f")
;; cua-modeの設定
(cua-mode t) ; cua-mode on
(setq cua-enable-cua-keys nil) ; CUAキーバインドを無効
フィルタ述語とアクセス述語
基本をメモ
フィルタ述語: 行頭の番号に対応するオペレーションの実行時に、取得したデータから 対象データを抜粋(フィルタ)する処理
アクセス述語: 行頭の番号に対応するオペレーションの実行時に、表示された述語を使用して データにアクセスしたことを示す。一般にINDEX Scan系の処理の場合に表示される。
アクセス述語の場合、データが選択的に選ばれるため、ブロックアクセス量は少なく、
フィルター処理はデータにアクセスした後に絞込みをかける為、アクセス述語に比べるとブロック数
は多い。
フィルタ述語: 行頭の番号に対応するオペレーションの実行時に、取得したデータから 対象データを抜粋(フィルタ)する処理
アクセス述語: 行頭の番号に対応するオペレーションの実行時に、表示された述語を使用して データにアクセスしたことを示す。一般にINDEX Scan系の処理の場合に表示される。
アクセス述語の場合、データが選択的に選ばれるため、ブロックアクセス量は少なく、
フィルター処理はデータにアクセスした後に絞込みをかける為、アクセス述語に比べるとブロック数
は多い。
2012年10月22日月曜日
問い合わせによる一時変数の置換 --- refactoring ---
一時変数は、一時的でかつローカルな使用の為、メソッドの内容を理解してたどり着く必要がある。つまり、長いメソッドになりがちである。それらを問い合わせメソッドにしてしまうことにより、内容の理解を容易にし、他のメソッドからも呼び出すことが可能になる。
[リファクタリングを行いやすい状況]
・ 一度だけ代入される一時変数
・ 代入される値をつくる式が副作用を起こしにくい。
[Example: from Refactoring by Martin Fowler]
if (baseProce() > 1000)
[リファクタリングを行いやすい状況]
・ 一度だけ代入される一時変数
・ 代入される値をつくる式が副作用を起こしにくい。
[Example: from Refactoring by Martin Fowler]
double basePrice = _itemprice * _quantity;
if (basePrice > 10000)
return basePrice * 0.95
else
return basePrice * 0.98
↓
if (baseProce() > 1000)
return basePrice * 0.95
else
return basePrice * 0.98
double basePrice() {
return _itemprice * _quantity;
}
2012年10月12日金曜日
CURSOR_SHARING Memo
============================================
CURSOR_SHARINGでは、同じカーソルを共有するSQL文の種類を判断。
FORCE
既存のカーソルを共有する場合、またはカーソル・プランが最適ではない場合に、新しいカーソルの作成が許可される。
SIMILAR
リテラルがわずかに異なっても、その他が同じSQL文であれば、
その異なるリテラルがSQL文の意味または計画が最適化される程度のいずれかに
影響しないかぎり、カーソルが共有される。
EXACT
同一のテキストを含む文のみに、前述のカーソルの共有が許可される。
============================================
9i当時はSimilarにすることで、複数のリテラル値でも共有カーソル化されると売りだったが、
現状のオラクルコメントは以下の通り。「優れたカーソル共有」機能には更に分析が必要。
CURSOR_SHARINGでは、同じカーソルを共有するSQL文の種類を判断。
FORCE
既存のカーソルを共有する場合、またはカーソル・プランが最適ではない場合に、新しいカーソルの作成が許可される。
SIMILAR
リテラルがわずかに異なっても、その他が同じSQL文であれば、
その異なるリテラルがSQL文の意味または計画が最適化される程度のいずれかに
影響しないかぎり、カーソルが共有される。
EXACT
同一のテキストを含む文のみに、前述のカーソルの共有が許可される。
============================================
9i当時はSimilarにすることで、複数のリテラル値でも共有カーソル化されると売りだったが、
現状のオラクルコメントは以下の通り。「優れたカーソル共有」機能には更に分析が必要。
CURSOR_SHARING=SIMILARの設定は11.1以降のリリースでは推奨されません。
次のリリース(12.1)ではこの値は廃止される可能性があります。
11.1以降のリリースではCURSOR_SHARING=FORCEを設定し、3.でも紹介した11.1の
新機能「優れたカーソル共有」を利用することが推奨されています
2012年10月9日火曜日
GitHub Manual
とりあえず、ソースを「GitHub」にUpしてみた。使い方は、まだわかっていないが、WWWに転がっている各種ドキュメントを見ながらやると、何だかんだで、できてしまうのが、今の時代の凄さを感じるな、やはり。
http://git-scm.com/documentation
http://git-scm.com/documentation
SQL Developer Custom Report 001 - v$sql_monitor -
SQL Developerでのレポート作成実施。v$sql_monitorからsqlを抽出し、その実行計画を子レポートで出力する。
ダウンロードして、SQL Developerのレポートタブで取り込んでください。
間違っていたりしたら、改善ポイントを御指摘頂けると、嬉しいです
RealtimeSQLMonitor_ExecutePlan.xml
ダウンロードして、SQL Developerのレポートタブで取り込んでください。
間違っていたりしたら、改善ポイントを御指摘頂けると、嬉しいです
RealtimeSQLMonitor_ExecutePlan.xml
2012年9月30日日曜日
CxOとSI
デザイン・パターン、アジャイル、XP、TDD、Continuous Integration、リーン等の開発プロセス改善の進展や、クラウド等の技術改革は、IT業界に居る私にとっては、とてもホットなネタ(古いネタもあるが)ばかりで面白い。
しかし、「CxO」と呼ばれる経営層には、何の興味も沸かない事項だと思う。売上も利益も上昇し、可視化される形で見えないのだから。企業全体の枠組の中において、ITは密接してつながっているのだが、やはり「ツール」、「わからないもの」、「金はかかるが、金を生み出さないもの」としての位置づけにしかなっていない。
在庫が削減されて、かつ在庫高がYTYで減少し、キャッシュフロー計算書にも明確なキャッシュの増額が見えない限り、上記のコンセプトは、全くもって、CxOのココロには響かない。SIerのコストが安くなるぐらいの理解しかしていないんだと思う。
読みやすいコードを書き、カバレッジを最大限満たしたテストを実施し、作らない開発で今までのものを再利用する。それはそれで知見を持ちつつ、ビジネスにインパクトを与えてCxOが面白いと思う話題を提供する必要がある。彼らの世界で生きる必要があるのである。そこで、「達人プログラマー」の話はしてはいけない。あまりにも、ビジネスを見ず、XPそのものに興味を持ってしまう人が多いと思う。 かくいう私も、その傾向はある。
XPそのものに興味を持ちつつも、ビジネスにインパクトを与える為に最も近い道は、結局、自分でサービス、製品を開発して、市場で売っていくしかないと思う。そうしないシステム・インテグレーションは、テック・マニアになるか、 標準プロセスマニアになるか、テックのことを何も知らずに、知らないが故に強みを発揮するビジネスコンサルタントになるしかない。CxOが気にいるのはビジネス・コンサルタントである。何故なら、CxOの興味のある事柄を掘り下げ、分析、考え、提案してくれるからである。
この負け試合を必ずひっくり返してやろうと思っている。
しかし、「CxO」と呼ばれる経営層には、何の興味も沸かない事項だと思う。売上も利益も上昇し、可視化される形で見えないのだから。企業全体の枠組の中において、ITは密接してつながっているのだが、やはり「ツール」、「わからないもの」、「金はかかるが、金を生み出さないもの」としての位置づけにしかなっていない。
在庫が削減されて、かつ在庫高がYTYで減少し、キャッシュフロー計算書にも明確なキャッシュの増額が見えない限り、上記のコンセプトは、全くもって、CxOのココロには響かない。SIerのコストが安くなるぐらいの理解しかしていないんだと思う。
読みやすいコードを書き、カバレッジを最大限満たしたテストを実施し、作らない開発で今までのものを再利用する。それはそれで知見を持ちつつ、ビジネスにインパクトを与えてCxOが面白いと思う話題を提供する必要がある。彼らの世界で生きる必要があるのである。そこで、「達人プログラマー」の話はしてはいけない。あまりにも、ビジネスを見ず、XPそのものに興味を持ってしまう人が多いと思う。 かくいう私も、その傾向はある。
XPそのものに興味を持ちつつも、ビジネスにインパクトを与える為に最も近い道は、結局、自分でサービス、製品を開発して、市場で売っていくしかないと思う。そうしないシステム・インテグレーションは、テック・マニアになるか、 標準プロセスマニアになるか、テックのことを何も知らずに、知らないが故に強みを発揮するビジネスコンサルタントになるしかない。CxOが気にいるのはビジネス・コンサルタントである。何故なら、CxOの興味のある事柄を掘り下げ、分析、考え、提案してくれるからである。
この負け試合を必ずひっくり返してやろうと思っている。
2012年9月18日火曜日
Bloom where God has planted you.
自分はキリスト教でも何でもないが、久しぶりにココロに響いたコトバなので、記しておこう。本は読まないと思うけど、このコトバだけで充分だ。 「あなたが置かれたところで咲きなさい」
渡辺和子さんの著作「置かれた場所で咲きなさい」より
渡辺和子さんの著作「置かれた場所で咲きなさい」より
2012年9月11日火曜日
2012年8月26日日曜日
RAC その①
少しまとめ。
1.HA構成
アクティブ-スタンバイ構成 。CPUライセンスは最小になる可能性は高い。
スタンバイ側はリソースをDLPARで設定して最小限しておく。
2. 共有ディスク構成
シェアード・エブリシング
ノード追加時のI/O競合がネック。H/WのSpecを考慮する。
3. 非共有ディスク構成
シェアード・ナッシング
H/W故障時に一部のデータにアクセス不可。可用性に弱点。
4. RAC(共有ディスク + キャッシュ・フュージョン)
共有ディスク単体に比べれば、一定の数までノードを追加できる。
100ノードまでのスケジュールアウトを実現(オラクル社の公式見解)
キャッシュ・フュージョンは、インターコネクトを使用したメモリ内に展開されているデータの同
期。データファイルではない。
1.HA構成
アクティブ-スタンバイ構成 。CPUライセンスは最小になる可能性は高い。
スタンバイ側はリソースをDLPARで設定して最小限しておく。
2. 共有ディスク構成
シェアード・エブリシング
ノード追加時のI/O競合がネック。H/WのSpecを考慮する。
3. 非共有ディスク構成
シェアード・ナッシング
H/W故障時に一部のデータにアクセス不可。可用性に弱点。
4. RAC(共有ディスク + キャッシュ・フュージョン)
共有ディスク単体に比べれば、一定の数までノードを追加できる。
100ノードまでのスケジュールアウトを実現(オラクル社の公式見解)
キャッシュ・フュージョンは、インターコネクトを使用したメモリ内に展開されているデータの同
期。データファイルではない。
2012年7月31日火曜日
The Agile Dilemma
これは正しいレポートだと思う。あまりにもAgileは喧伝されすぎているし、その背後にある難しさが隠されている。Agileには、一定のガバナンスとルールを制定することが必要だと思う。それは開発者に対してではなく、プロジェクトに対してである。
物議を醸すVokeの報告がAgile採用者に警告
物議を醸すVokeの報告がAgile採用者に警告
ラベル:
Info: methodology
2012年7月27日金曜日
DECODE
DECODE
数値の等価、大小関係を評価するには SIGN 関数。
SIGN ( expr )
Return:[+1:整数、0:ゼロ、-1:負数]
最小 、最大を評価するには、GREATEST関数、LEAST関数
GREATEST ( expr_list )
LEAST ( expr_list )
Return: 最も小さい、大きい数。文字列。
数値の等価、大小関係を評価するには SIGN 関数。
SIGN ( expr )
Return:[+1:整数、0:ゼロ、-1:負数]
最小 、最大を評価するには、GREATEST関数、LEAST関数
GREATEST ( expr_list )
LEAST ( expr_list )
Return: 最も小さい、大きい数。文字列。
2012年7月3日火曜日
PureSystem
メモ。Flex System Managerの2重化は必要ないのか?
Expert Integrated System
PureFlex --- サーバー、ストレージ、ネットワーク、そして仮想化の一元管理、最適管理
power , x86
Storage V7000
Integrated (Flex System Manager)
PowerVM
PureApplication
+ Application -- パターン化による最適化
Expert Integrated System
PureFlex --- サーバー、ストレージ、ネットワーク、そして仮想化の一元管理、最適管理
power , x86
Storage V7000
Integrated (Flex System Manager)
PowerVM
PureApplication
+ Application -- パターン化による最適化
2012年6月27日水曜日
Continuous Integration -001-
「 継続的インテグレーション」の翻訳版が2009年(USでは2007年)に発刊され、昨年は「継続的デリバリー」も発刊された。クライアントの中でも、本で記述された内容まではいかないが、ビルド、デプロイの自動化をスクラッチで実装する事例がでてきた。
今年の目標はRQM + RTCの連携検証にJenkinsを絡めて、トータルな継続的デリバリーの基盤を構築したい。とかく、開発者としての興味がある範囲なので、面白いということが先行するが、目指すところは、ムダの排除だと思っている。ビルドミス、リグレッションテストミス、デプロイミスといったビジネスと関係ないところのミスを最大限低減することである。
今年の目標はRQM + RTCの連携検証にJenkinsを絡めて、トータルな継続的デリバリーの基盤を構築したい。とかく、開発者としての興味がある範囲なので、面白いということが先行するが、目指すところは、ムダの排除だと思っている。ビルドミス、リグレッションテストミス、デプロイミスといったビジネスと関係ないところのミスを最大限低減することである。
2012年6月13日水曜日
FAH-GL Tuning Memo
・ 初期化パラメータの調整
・ 統計情報の最適化(特に初期実行時)
・ 「会計の作成」のパラレル化(CPUスレッド数を意識)、アドオン・コンカレントマネージャの作成。
・ 「会計のプログラム」のプロセッサ数、一回あたりの処理単位の調整(自環境でのベンチマーク実施は必須)
・ バッチ処理実施時における「XLA_EVENTS」の未処理データの扱い。標準プログラムのSQLが未処理データを常に参照する為、本当に必要な範囲で「XLA_EVENTS」に取り込む。取り込み時はバルクAPIを使えるならば、使ったほうがよい。
・ 各コンカレントマネージャのポーリング時間の調整。
・ アドオンの取込の際にFAHのテーブルを見てチェックロジックを入れる場合は、アプリケーションIDとイベント区分を必ず入れること。FAHのテーブルは、その2つでパーティション化されている為。
・ 統計情報の最適化(特に初期実行時)
・ 「会計の作成」のパラレル化(CPUスレッド数を意識)、アドオン・コンカレントマネージャの作成。
・ 「会計のプログラム」のプロセッサ数、一回あたりの処理単位の調整(自環境でのベンチマーク実施は必須)
・ バッチ処理実施時における「XLA_EVENTS」の未処理データの扱い。標準プログラムのSQLが未処理データを常に参照する為、本当に必要な範囲で「XLA_EVENTS」に取り込む。取り込み時はバルクAPIを使えるならば、使ったほうがよい。
・ 各コンカレントマネージャのポーリング時間の調整。
・ アドオンの取込の際にFAHのテーブルを見てチェックロジックを入れる場合は、アプリケーションIDとイベント区分を必ず入れること。FAHのテーブルは、その2つでパーティション化されている為。
ラベル:
Info:OracleEBS12
Clean Coder (Chapter6. Practice)
この本に限ってではないけど、西洋の人達は、「型」とか「乱取り」とか、「サムライ」とか「禅」というコトバが、いつでも好きだな。際限の無い目的思考から離れ、その日常の生活の中での繰り返し(ミニマム)を大事にする。逆に目的をきちんと考えずに説明資料を作成したり、行動を実施する日本人は、西洋人のプレゼン・スタイル、説明スタイルを見習っているのに。。
日本人の自分としては、「Practice」というコトバが好きだ。際限の無い「Practice」を継続的に続けることが、プロフェッショナルとしての1つのルールだと思う。
日本人の自分としては、「Practice」というコトバが好きだ。際限の無い「Practice」を継続的に続けることが、プロフェッショナルとしての1つのルールだと思う。
2012年6月5日火曜日
Clean Coder (Chapter5. TDD)
Clean CoderのTDDの3原則はくどく感じたので、自分なりの解釈を記述してみる。
- ソースコードを記述する前に失敗する単体テストケースを記述すること。ソースコードが完成する直前には、自動化されたテストケースが完成している。(Coverage 90%以上)
- 単体テストケースを記述することは、モジュールの疎結合を目指すことになる。(テストが実施できるソースを開発するようになる為)
- ソースコード完成時に、数分以内に完了するリグレッション・テストが用意可能になる。(変更に対する恐れがなくなる。自動化された単体、受入テストケースが無い場合、結局は大丈夫だと思って実施しないテストケースがでてくるが、その内容が自動化されたテストケースに含まれることになり、より堅牢になる)
2012年5月23日水曜日
Oracle DB Cache Clear
10gからの進歩ですね。忘れずに。
共有プール クリア
(ライブラリキャッシュ<解析済のSQLやPL/SQL等>、データディクショナリキャッシュ)
データベースバッファ キャッシュ クリア(10g~)
(データファイルから読み込まれたデータ・ブロックのコピーが格納される領域)
共有プール クリア
(ライブラリキャッシュ<解析済のSQLやPL/SQL等>、データディクショナリキャッシュ)
ALTER SYSTEM FLUSH SHARED_POOL;
データベースバッファ キャッシュ クリア(10g~)
(データファイルから読み込まれたデータ・ブロックのコピーが格納される領域)
ALTER SYSTEM FLUSH BUFFER_CACHE ;
2012年5月21日月曜日
strings & files
滅多に使うことはないと思うが、stringsコマンド
「ファイルから文字列相当と認識できる部分を探して表示する」
バイナリファイルとかが有効。バイナリファイルがコンパイル時に内部に取り込んだディレクトリとかをgrepと合わせて検索することが可能
$ strings -f /user/bin/*.exe XXXXX.exe | grep .....
みたいな感じかな。今まで数回しか使ったこない。
こちらの方が使うかな。fileコマンド。
指定されたファイルを分析して、ファイルの種類」を表示してくれます。
$ file [file name]でOK.
「ファイルから文字列相当と認識できる部分を探して表示する」
バイナリファイルとかが有効。バイナリファイルがコンパイル時に内部に取り込んだディレクトリとかをgrepと合わせて検索することが可能
$ strings -f /user/bin/*.exe XXXXX.exe | grep .....
みたいな感じかな。今まで数回しか使ったこない。
こちらの方が使うかな。fileコマンド。
指定されたファイルを分析して、ファイルの種類」を表示してくれます。
$ file [file name]でOK.
2012年5月16日水曜日
emacs (dired) -起動-
同じフリーである「Sakura Editior」等に戻りたくなる気持ちに負けず、「emacs」 を無理やり使っているが、少しづつ慣れてきた。今更ながら、「ディレクトリエディタ(dired)」について学ぶ。
C-x dかM-x dired
別フレームで起動したい場合は、C-x 5 d(
別ウィンドウでC-x 4 d (
C-x dかM-x dired
別フレームで起動したい場合は、C-x 5 d(
dired-other-frame
) 別ウィンドウでC-x 4 d (
dired-other-window
)
。 2012年4月14日土曜日
V$SQL_PLAN
V$SQLから調査したいSQLを探し出した後、ADDRESS、HASH_VALUEやSQL_IDでV$SQL_PLANから実行計画を取得し、整形するスクリプト(小田さんのページから借用)
【パターン①】
column id format 999 newline
column operation format a20
column options format a15
column object_name format a22 trunc
column optimizer format a3 trunc
select id
, lpad (' ', depth) || operation operation
, options
, object_name
, optimizer
, cost
from v$sql_plan
where hash_value = &hash_value
and address = '&address'
start with id = 0
connect by
(prior id = parent_id
and prior hash_value = hash_value
and prior child_number = child_number
)
order siblings by id, position;
【パターン②】
column id format 999 newline
column operation format a20
column options format a15
column object_name format a22 trunc
column optimizer format a3 trunc
select id
, lpad (' ', depth) || operation operation
, options
, object_name
, optimizer
, cost
from v$sql_plan
where sql_id = &sql_id
start with id = 0
connect by (prior id = parent_id
and prior sql_id = sql_id
and prior child_number = child_number
)
order siblings by id, position;
【パターン①】
column id format 999 newline
column operation format a20
column options format a15
column object_name format a22 trunc
column optimizer format a3 trunc
select id
, lpad (' ', depth) || operation operation
, options
, object_name
, optimizer
, cost
from v$sql_plan
where hash_value = &hash_value
and address = '&address'
start with id = 0
connect by
(prior id = parent_id
and prior hash_value = hash_value
and prior child_number = child_number
)
order siblings by id, position;
【パターン②】
column id format 999 newline
column operation format a20
column options format a15
column object_name format a22 trunc
column optimizer format a3 trunc
select id
, lpad (' ', depth) || operation operation
, options
, object_name
, optimizer
, cost
from v$sql_plan
where sql_id = &sql_id
start with id = 0
connect by (prior id = parent_id
and prior sql_id = sql_id
and prior child_number = child_number
)
order siblings by id, position;
2012年4月3日火曜日
test (file)
結構忘れているよなー
test expression
[ expression ]
-r file fileが「読み取り可」ならば真
-w file fileが「書き込み可」ならば真
-x file fileが「実行可」ならば真
-f file fileが「普通のファイル」ならば真
-d file fileが「ディレクトリ」ならば真
-s file fileが「0より大きいサイズ」ならば真
! NOT(否)の意味。「この直後の判定が偽」なら真
-a AND(かつ)。「この前後の判定がどちらも真」なら真
-o OR(または)。「この前後の判定のどちらかが真」なら真
sample
[ -r file -a w file -a ! -x file ]
fileが読み書き可能で実行不可の場合に真
test expression
[ expression ]
-r file fileが「読み取り可」ならば真
-w file fileが「書き込み可」ならば真
-x file fileが「実行可」ならば真
-f file fileが「普通のファイル」ならば真
-d file fileが「ディレクトリ」ならば真
-s file fileが「0より大きいサイズ」ならば真
! NOT(否)の意味。「この直後の判定が偽」なら真
-a AND(かつ)。「この前後の判定がどちらも真」なら真
-o OR(または)。「この前後の判定のどちらかが真」なら真
sample
[ -r file -a w file -a ! -x file ]
fileが読み書き可能で実行不可の場合に真
2012年3月21日水曜日
2012年3月19日月曜日
EBS12.1.3 定期コンカレント
調べる限り、以下8つだな。
1.OAM Applicationsダッシュボード収集
OAMのワークフロー統計情報表示を最新化
2.ワークフロー制御キュー・クリーン・アップ
3.ワークフローLOCAL表の同期化
4.ワークフロー・エージェント・アクティビティ統計コンカレント・プログラム
5.ワークフロー・メーラー コンカレント統計コンカレント・プログラム
6.ワークフロー作業項目統計コンカレント・プログラム
OAMのワークフロー統計情報表示を最新化
7.ログおよびクローズ済システム・アラートのパー ジ
8.fnd_sessionsから廃止セッションを削除
PER_FND_SESSIONS_CLEANUP (プログラム名)
1.OAM Applicationsダッシュボード収集
OAMのワークフロー統計情報表示を最新化
2.ワークフロー制御キュー・クリーン・アップ
3.ワークフローLOCAL表の同期化
4.ワークフロー・エージェント・アクティビティ統計コンカレント・プログラム
5.ワークフロー・メーラー コンカレント統計コンカレント・プログラム
6.ワークフロー作業項目統計コンカレント・プログラム
OAMのワークフロー統計情報表示を最新化
7.ログおよびクローズ済システム・アラートのパー ジ
FND_LOG_MESSAGES FND_LOG_EXCEPTIONS FND_LOG_ATTACHMENTS FND_LOG_METRICS FND_LOG_TRANSACTION_CONTEXT
8.fnd_sessionsから廃止セッションを削除
PER_FND_SESSIONS_CLEANUP (プログラム名)
ラベル:
Info:OracleEBS12
2012年3月14日水曜日
I bought Amazon Touch
前にも買おうかなとブログに記述したが、Amazon Touchが日本にImport可になったので、買ってみた。1ドル81円程度で12,000円強。その他のタブレット系に比べると安い。
ユーザーインタフェースの使い心地は、思ったより悪い。iPhoneとか慣れている人は、少しストレス溜まるかも。 AmazonのWebサイトと連動した本(Kindle Edition)の購入は良い。買った本がインターネットを通じて、Touchに送付されてくるのには、今更ながら少し感動。しかも、安い。洋書や日本語版で5000円ぐらいかかるのが、1500円程度で購入できる。
日本語書籍もでてきたら、文庫等はこっちの方が良いのかも。
ユーザーインタフェースの使い心地は、思ったより悪い。iPhoneとか慣れている人は、少しストレス溜まるかも。 AmazonのWebサイトと連動した本(Kindle Edition)の購入は良い。買った本がインターネットを通じて、Touchに送付されてくるのには、今更ながら少し感動。しかも、安い。洋書や日本語版で5000円ぐらいかかるのが、1500円程度で購入できる。
日本語書籍もでてきたら、文庫等はこっちの方が良いのかも。
2012年3月8日木曜日
JDeveloper with OAF
大した話ではないけど、たまに引っかかるのでメモ
JDeveloperで作成して、コンパイルも通っているソースを他のプロジェクトフォルダに移行した時にコンパイルエラーが発生することがある。ライブラリを揃っているのに何故?
JDevelpoerのコンパイル時の文字コードが、cpXXXX系にデフォルトなっている為である。 JDevloperのエディタも文字コードと合わせるようにすること。
JDeveloperで作成して、コンパイルも通っているソースを他のプロジェクトフォルダに移行した時にコンパイルエラーが発生することがある。ライブラリを揃っているのに何故?
JDevelpoerのコンパイル時の文字コードが、cpXXXX系にデフォルトなっている為である。 JDevloperのエディタも文字コードと合わせるようにすること。
2012年3月6日火曜日
2012年3月2日金曜日
svmon
svmonでメモリ使用量のTop15をシンプルに出すコマンド
# svmon -Pt15 | perl -e 'while(<>){print if($.==2||$&&&!$s++);$.=0 if(/^-+$/)}'
# svmon -Pt15 | perl -e 'while(<>){print if($.==2||$&&&!$s++);$.=0 if(/^-+$/)}'
2012年2月29日水曜日
IBM JDK & OAS
OASのjavaプロセスのメモリが微増している。-Xmxの数値に達しながら、わずかながら、微増している。16Kぐらいかな。Native heapのExpandなのか。でも何も使用していないし。もう少し調査をしなければならないかな。
ラベル:
Info:OracleEBS12
2012年2月15日水曜日
JVM & EBS
「OACore: OA Framework」 、
「Forms : Forms ベースアプリケーションの実行」、
「OAFM (Oracle Apps Fusion Middleware) : web サービス、mapviewer 」の
3つのインスタンスが同一のJVM上で稼動する。
Heap Memoryの設定も-Xms、-Xmxは実施するが、
意外と下記の値はデフォルトのままである。下記はIBM JDKの場合。
Native Heap Size -Xminf -Xmaxf -Xmine -Xmaxe -Xgcthread -Xpartialcompactgc -Xgcpolicy
ラベル:
Info:OracleEBS12
2012年2月14日火曜日
OC4J Service from EBS R12
OACore : OA Framework ベースアプリケーションの実行
Forms : Forms ベースアプリケーションの実行
OAFM (Oracle Apps Fusion Middleware) : web サービス、mapviewer の実行
ラベル:
Info:OracleEBS12
2012年2月10日金曜日
DBMS_METADATA.GET_GRANTED_DDL
XXXスキーマに付与されたすべてのシステム権限付与を示すDDLの取得
SELECT DBMS_METADATA.GET_GRANTED_DDL('SYSTEM_GRANT','XXX') FROM DUAL;
全部取得できるのかと思ったら、抜けがある。注意!
2012年1月30日月曜日
AOL/J End
とりあえず、今理解している範囲でのEBSのJDEBC接続プールの動きである。基本の動きは11i、12とも変わっていない。このプールの仕組の上にApplication Moduleの仕組が搭載されている。その辺の動きついては、また今度かな。
ラベル:
Info:OracleEBS12
AOL/J Part6.
やっと最後。FND_JDBC_USABLE_CHECKは変更した方が良いと思うが、後は無視してもよいと俺は思う。どういうときに設定を見直す必要があるのか、教えてください。
FND_JDBC_USABLE_CHECK
FND_JDBC_USABLE_CHECKは接続をクライアントに貸し出す前にPL/SQLでの検索を行うかどうかを決定する。プールは接続を渡す前に使用可能かどうかのチェックを行う。これは常に接続がNullではなく、またクローズされていないことのチェックある。FND_JDBC_USABLE_CHECKがtrueに設定されていると、更にその接続が、簡単なPL/SQLの検索を行うことができるどうかの確認も行なわれる。
これはデフォルトがfalseになっているので注意。Safetyチェックなので、できればTrueにした方が良いと思うが、何故PL/SQLのみなのか、説明はない。JavaからPL/SQLをコールする場合の方法としてチェックが必要という意味なのだろうか?
FND_JDBC_CONTEXT_CHECK
FND_JDBC_CONTEXT_CHECKは、接続がプールに戻されるときにAOLのセキュリティ情報とNLSの状態がデータベースから取得されるかどうかを決定する。FND_JDBC_CONTEXT_CHECKがtrueの場合、接続がプールに戻されるときにこれらが取得される。(これはDBConnObj.isReusable() に実装されている)。このチェックは選択アルゴリズムが利用可能リストにある接続のセッション情報にアクセスできるよう、接続が返されるときに行われる。
FND_JDBC_PLSQL_RESET
PL/SQLリセットのフラグは、プールがクライアントに接続を渡す前にその接続で持っているPL/SQLの状態が解放されるかどうかを左右する。このフラグのデフォルトはfalseです。trueにセットされると、プールが接続を渡す前にPL/SQLの状態がクリアされる。
プールは利用可能なリストの中からクライアントのための接続を選択した後、その接続の初期化を
行う。その初期化のうちの一つが、後にapps initializationのルーチンが実行される必要があ
るかどうかを決定するためにSessionManagerによって利用されるフラグをセットすることである。
FND_JDBC_PLSQL_RESETがtrueにセットされていると、このフラグは常にtrueとなります。プールは接続を初期化した後、その接続が使用可能かどうかのチェックも行う。この場合、チェックはPL/SQLの状を解放するDBMS_SESSION.RESET_PACKAGEの実行も行う。これがtrueに設定されていると、プールのパフォーマンスは悪くなる。
FND_JDBC_USABLE_CHECK
FND_JDBC_USABLE_CHECKは接続をクライアントに貸し出す前にPL/SQLでの検索を行うかどうかを決定する。プールは接続を渡す前に使用可能かどうかのチェックを行う。これは常に接続がNullではなく、またクローズされていないことのチェックある。FND_JDBC_USABLE_CHECKがtrueに設定されていると、更にその接続が、簡単なPL/SQLの検索を行うことができるどうかの確認も行なわれる。
これはデフォルトがfalseになっているので注意。Safetyチェックなので、できればTrueにした方が良いと思うが、何故PL/SQLのみなのか、説明はない。JavaからPL/SQLをコールする場合の方法としてチェックが必要という意味なのだろうか?
FND_JDBC_CONTEXT_CHECK
FND_JDBC_CONTEXT_CHECKは、接続がプールに戻されるときにAOLのセキュリティ情報とNLSの状態がデータベースから取得されるかどうかを決定する。FND_JDBC_CONTEXT_CHECKがtrueの場合、接続がプールに戻されるときにこれらが取得される。(これはDBConnObj.isReusable() に実装されている)。このチェックは選択アルゴリズムが利用可能リストにある接続のセッション情報にアクセスできるよう、接続が返されるときに行われる。
FND_JDBC_PLSQL_RESET
PL/SQLリセットのフラグは、プールがクライアントに接続を渡す前にその接続で持っているPL/SQLの状態が解放されるかどうかを左右する。このフラグのデフォルトはfalseです。trueにセットされると、プールが接続を渡す前にPL/SQLの状態がクリアされる。
プールは利用可能なリストの中からクライアントのための接続を選択した後、その接続の初期化を
行う。その初期化のうちの一つが、後にapps initializationのルーチンが実行される必要があ
るかどうかを決定するためにSessionManagerによって利用されるフラグをセットすることである。
FND_JDBC_PLSQL_RESETがtrueにセットされていると、このフラグは常にtrueとなります。プールは接続を初期化した後、その接続が使用可能かどうかのチェックも行う。この場合、チェックはPL/SQLの状を解放するDBMS_SESSION.RESET_PACKAGEの実行も行う。これがtrueに設定されていると、プールのパフォーマンスは悪くなる。
ラベル:
Info:OracleEBS12
AOL/J Part5
FND_JDBC_MAX_WAIT_TIME(変更不可)
最大待ち時間は、クライアントが接続を取得しようとするのにどの位の時間を費やすかを決定する。
す。接続をプールから借りるアルゴリズムには、経過時間を最大待ち時間と比較してチェックする
機能が組み込まれている。最大値を超えた場合、nullがクライアントに返されます。事前定義の
設定は10秒。
FND_JDBC_SELECTION_POLICY(変更不可)
選択ポリシーは、あるクライアントに関しての接続が、利用可能な接続のリストからどのように選択されるかを決定する。コストベースの選択アルゴリズムを採用するよう事前定義されています。このアルゴリズムでは、そのクライアントの状態に一致するように行われる初期化処理が最小になる。
Pool.COSTと呼ばれるコストベースが設定されている。
最大待ち時間は、クライアントが接続を取得しようとするのにどの位の時間を費やすかを決定する。
す。接続をプールから借りるアルゴリズムには、経過時間を最大待ち時間と比較してチェックする
機能が組み込まれている。最大値を超えた場合、nullがクライアントに返されます。事前定義の
設定は10秒。
FND_JDBC_SELECTION_POLICY(変更不可)
選択ポリシーは、あるクライアントに関しての接続が、利用可能な接続のリストからどのように選択されるかを決定する。コストベースの選択アルゴリズムを採用するよう事前定義されています。このアルゴリズムでは、そのクライアントの状態に一致するように行われる初期化処理が最小になる。
Pool.COSTと呼ばれるコストベースが設定されている。
ラベル:
Info:OracleEBS12
AOL/J Part4
FND_JDBC_BUFFER_DECAY_INTERVAL
バッファ減衰間隔はどの位の頻度で接続プールのメンテナンスが行われるかを指定する。
スレッドはバッファサイズを最大でもFND_JDBC_BUFFER_DECAY_INTERVAL秒毎にチェックする。
各サイクル間の実際の時間はJVMの負荷によって幾らか異なる。実際は大分ずれていると思う。
このパラメータは、FND_JDBC_BUFFER_DECAY_SIZEと共にバッファの減衰量の調整に利用される。例えば、バッファ減衰サイズが3で減衰間隔が1分の場合、1分当たりのバッファの減衰量は3を超えることはない。デフォルトは300秒だったりする。60秒までインターバルを短くすることは可能。
負荷が高い時は、FND_JDBC_BUFFER_DECAY_INTERVALとFND_JDBC_BUFFER_DECAY_SIZEの2つの値の調整に尽きると思う。想定される負荷(例えば、1分あたり増加量以上の数値を設定すればよい)
FND_JDBC_BUFFER_DECAY_SIZE
バッファ減衰サイズは利用可能な接続がバッファサイズ以上になっているときに1回のスレッドのサ
イクルで除去されるべき接続の最大数を指定する。このパラメータは、FND_JDBC_BUFFER_DECAY_
INTERVALと共に減衰量の調整のために使用される。
設定値によるケースパターンは後で記述。
バッファ減衰間隔はどの位の頻度で接続プールのメンテナンスが行われるかを指定する。
スレッドはバッファサイズを最大でもFND_JDBC_BUFFER_DECAY_INTERVAL秒毎にチェックする。
各サイクル間の実際の時間はJVMの負荷によって幾らか異なる。実際は大分ずれていると思う。
このパラメータは、FND_JDBC_BUFFER_DECAY_SIZEと共にバッファの減衰量の調整に利用される。例えば、バッファ減衰サイズが3で減衰間隔が1分の場合、1分当たりのバッファの減衰量は3を超えることはない。デフォルトは300秒だったりする。60秒までインターバルを短くすることは可能。
負荷が高い時は、FND_JDBC_BUFFER_DECAY_INTERVALとFND_JDBC_BUFFER_DECAY_SIZEの2つの値の調整に尽きると思う。想定される負荷(例えば、1分あたり増加量以上の数値を設定すればよい)
FND_JDBC_BUFFER_DECAY_SIZE
バッファ減衰サイズは利用可能な接続がバッファサイズ以上になっているときに1回のスレッドのサ
イクルで除去されるべき接続の最大数を指定する。このパラメータは、FND_JDBC_BUFFER_DECAY_
INTERVALと共に減衰量の調整のために使用される。
設定値によるケースパターンは後で記述。
ラベル:
Info:OracleEBS12
AOL/J Part3
FND_JDBC_BUFFER_MIN
最小バッファは、プールが利用可能リストに保持しようとする最小の接続数。
バッファサイズがFND_JDBC_BUFFER_MIN以下になると、プール管理のスレッドは
新しい接続を作るように通知される。通知されると、スレッドは即座にその差分を
埋めるだけの接続を作成しようと試みます。プールが既に最大値に達している場合には
新しい接続は作成されない。
このパラメータを0に設定すると、最小バッファのメンテナンスは無効化されます。
しかし、最大バッファのメンテナンスは行われたままです。一方でパラメータを
FND_MAX_JDBC_CONNECTIONSより大きな値に設定すると、全てのバッファのメンテナンス
は無効化される。
FND_JDBC_BUFFER_MAX
最大バッファはプールが利用可能リストに保持しようとす接続の最大数です。
負荷の高い間、バッファは最大数を超えることがあります。しかし、負荷が低くなると、
メンテナンスのスレッドは最大バッファの数までバッファを減少させます。
値が整数(例:30)の場合、最大バッファは固定。
一方でパーセント(例:20%)の場合、最大バッファは一定ではなく、代わりにトータルの
プールサイズのパーセントとして動的に算出される。最小バッファも最大バッファを
動的に決定する際に考慮される。( 整数値にパーセント記号(%)を変えることで変更可能であり
%の場合は10%以上が指針)
maximum(t) = minimum + ( (FND_JDBC_BUFFER_MAX/100) * FND_MAX_JDBC_CONNECTIONS)
ここで、maximum(t)及びsize(t)はある時刻における最大バッファとプールサイズです。
スレッドは定期的にバファサイズをチェックします。バッファサイズが最大バッファより
大きい場合、スレッドはFND_JDBC_BUFFER_DECAY_SIZEに指定された数もしくは
最小バッファを超えた接続数の内、より小さい方の数だけ利用可能な接続を減少させます。
接続が利用可能リストから除去されるとき、最も長い時間利用されていないものが
最初に除去される。
このパラメータを100%に、あるいはFND_MAXIMUM_JDBC_CONNECTIONSと同じ値
及びFND_JDBC_BUFFER_MIN以下の値に設定することでメンテナンスのスレッドが
接続を除去されないようになる。
このパラメータを0に設定すると、最大バッファのメンテナンスは無効化される。
FND_JDBC_BUFFER_MINとFND_JDBC_BUFFER_MAXの双方を0に設定するとメンテナンス
がされなくなる。通常はMINとMAXの間で維持しようとする。
最小バッファは、プールが利用可能リストに保持しようとする最小の接続数。
バッファサイズがFND_JDBC_BUFFER_MIN以下になると、プール管理のスレッドは
新しい接続を作るように通知される。通知されると、スレッドは即座にその差分を
埋めるだけの接続を作成しようと試みます。プールが既に最大値に達している場合には
新しい接続は作成されない。
このパラメータを0に設定すると、最小バッファのメンテナンスは無効化されます。
しかし、最大バッファのメンテナンスは行われたままです。一方でパラメータを
FND_MAX_JDBC_CONNECTIONSより大きな値に設定すると、全てのバッファのメンテナンス
は無効化される。
FND_JDBC_BUFFER_MAX
最大バッファはプールが利用可能リストに保持しようとす接続の最大数です。
負荷の高い間、バッファは最大数を超えることがあります。しかし、負荷が低くなると、
メンテナンスのスレッドは最大バッファの数までバッファを減少させます。
値が整数(例:30)の場合、最大バッファは固定。
一方でパーセント(例:20%)の場合、最大バッファは一定ではなく、代わりにトータルの
プールサイズのパーセントとして動的に算出される。最小バッファも最大バッファを
動的に決定する際に考慮される。( 整数値にパーセント記号(%)を変えることで変更可能であり
%の場合は10%以上が指針)
maximum(t) = minimum + ( (FND_JDBC_BUFFER_MAX/100) * FND_MAX_JDBC_CONNECTIONS)
ここで、maximum(t)及びsize(t)はある時刻における最大バッファとプールサイズです。
スレッドは定期的にバファサイズをチェックします。バッファサイズが最大バッファより
大きい場合、スレッドはFND_JDBC_BUFFER_DECAY_SIZEに指定された数もしくは
最小バッファを超えた接続数の内、より小さい方の数だけ利用可能な接続を減少させます。
接続が利用可能リストから除去されるとき、最も長い時間利用されていないものが
最初に除去される。
このパラメータを100%に、あるいはFND_MAXIMUM_JDBC_CONNECTIONSと同じ値
及びFND_JDBC_BUFFER_MIN以下の値に設定することでメンテナンスのスレッドが
接続を除去されないようになる。
このパラメータを0に設定すると、最大バッファのメンテナンスは無効化される。
FND_JDBC_BUFFER_MINとFND_JDBC_BUFFER_MAXの双方を0に設定するとメンテナンス
がされなくなる。通常はMINとMAXの間で維持しようとする。
ラベル:
Info:OracleEBS12
AOL/J Part2
AOL/Jにおいて、各種パラメータの定義、設定のポイントを記述する。
FND_MAX_JDBC_CONNECTIONS
利用可能な(Available)接続とロック(lock)された(他のクライアントによって使用中で
利用不可の)接続の総計の許容される最大数。プールが最大サイズに達して、
全ての接続がロックされると、現在のクライアントが返却しない限り
新しいクライアントはプールから接続を借りることができません。
デフォルトの設定は500.(12.1.3)
設定した時は、Oracle DBの 初期化パラメータであるProcessesにも気をつけること。
FND_MAX_JDBC_CONNECTIONS > PROCESSESだと、PROCESSESの数値を超えて、
新規コネクションを作成する段階でORA-00020が発生する。
FND_MAX_JDBC_CONNECTIONS達して、再利用可能なコネクションが存在しない場合、
Oracle AS側からエラーが戻される。 その他として、エンハンス機能である
AOL/J Connection Harvesterというものがあるが、現時点は稼動確認を取っていないので、
説明は無。
ラベル:
Info:OracleEBS12
AOL/J Part1
年明けから結構経ってしまった。反省。
EBSの JDBCのConnection Poolingの仕組である。アプリケーションモジュールのプーリングの仕組とは異なるので注意が必要。
AutoConfigで調整が可能である為、大量負荷がかかるOAFのアプリケーションをデリバリする場合は、負荷テストで、各値の数値の増減を確認した方がよい。
(オラクル社より診断ツールが提供されている。プロファイルは「FND: 診断」を「Y」に変えると、取得することが可能になり、「AOL/Jデータベース接続 プール・ステータス」というメニューから表示可能である。ログイン後、以下のURLを叩いても可能。
http://<hostname>:<port>/OA_HTML/jsp/fnd/AoljDbcPoolStatus.jsp
「available connection」、「locked connections」、「connection destroyed ( by thread)」を中心にモニタリングした方がよい。「leaked connections」は存在しないと認識するが、仮に発生していたら調査をした方がよい。
EBSの JDBCのConnection Poolingの仕組である。アプリケーションモジュールのプーリングの仕組とは異なるので注意が必要。
AutoConfigで調整が可能である為、大量負荷がかかるOAFのアプリケーションをデリバリする場合は、負荷テストで、各値の数値の増減を確認した方がよい。
(オラクル社より診断ツールが提供されている。プロファイルは「FND: 診断」を「Y」に変えると、取得することが可能になり、「AOL/Jデータベース接続 プール・ステータス」というメニューから表示可能である。ログイン後、以下のURLを叩いても可能。
http://<hostname>:<port>/OA_HTML/jsp/fnd/AoljDbcPoolStatus.jsp
「available connection」、「locked connections」、「connection destroyed ( by thread)」を中心にモニタリングした方がよい。「leaked connections」は存在しないと認識するが、仮に発生していたら調査をした方がよい。
ラベル:
Info:OracleEBS12
登録:
投稿 (Atom)