オラクル専用ページへもどる
-----------------------------------------------------------------------------------------
■インデックスのエクステント情報の取得方法
以下のSQLを index再構築(ALTER INDEX ... REBUILD)の前後で実施し、
結果を比較してブロック、エクステントの増加状況を調査する。
-------------------------- SQL ------------------------
column segment_name heading "SEGMENT_NAME" FORMAT a32 justify l
select segment_name,
segment_type,
tablespace_name,
blocks,bytes,
extents,(bytes / blocks) as BLOCK_SIZE
from dba_segments
where segment_name='インデックス名' and segment_type in ('INDEX')
order by segment_type,
segment_name;
-------------------------------------------------------
以下、参考例と結果
column segment_name heading "SEGMENT_NAME" FORMAT a32 justify l
select segment_name,
segment_type,
tablespace_name,
blocks,bytes,
extents,(bytes / blocks) as BLOCK_SIZE
from dba_segments
where segment_name='PK_EMP' and segment_type in ('INDEX')
order by segment_type,
segment_name;
SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME BLOCKS BYTES EXTENTS BLOCK_SIZE
--------------- -------------- ----------------- --------- ------- ------- -----------
PK_EMP INDEX SYSTEM 8 65536 1 8192
-----------------------------------------------------------------------------------------
■統計情報のバックアップ・リストア方法
※dbms_utilityコマンドでアナライズ。
dbms_utility.analyze_schema(schema_name, {COMPUTE|ESTIMATE|DELETE}, rows, percents);
例：
SQL} execute dbms_utility.analyze_schema('SCOTT','estimate',null,15);
◆ analyze コマンドで取得した情報を確認します。
select table_name, num_rows,blocks, avg_row_len, user_stats
from user_tables where table_name='EMP';
TABLE_NAME NUM_ROWS BLOCKS AVG_ROW_LEN USE
------------------------------ ---------- ---------- ----------- ---
EMP 14 1 41 NO
◆ EXPORT 用の TABLE を作成します。
begin
DBMS_STATS.CREATE_STAT_TABLE (
ownname =>'SCOTT',
stattab =>'STATTAB',
tblspace =>'USERS');
end;
/
◆ 上記の統計情報を EXPORT します。
↓テーブル単位
begin
DBMS_STATS.EXPORT_TABLE_STATS (
ownname => 'SCOTT',
tabname => 'EMP',
stattab => 'STATTAB',
cascade => TRUE);
end;
/
↓スキーマ単位
begin
DBMS_STATS.EXPORT_SCHEMA_STATS (
ownname => 'SCOTT',
stattab => 'STATTAB',
statid => null,
statown => null);
end;
/
◆ 統計情報を変更します。
delete from emp where empno=7934;
execute dbms_utility.analyze_schema('SCOTT','estimate',null,15);
select table_name, num_rows,blocks, avg_row_len, user_stats
from user_tables where table_name='EMP';
TABLE_NAME NUM_ROWS BLOCKS AVG_ROW_LEN USE
------------------------------ ---------- ---------- ----------- ---
EMP 13 1 41 NO
◆ EXPORT した統計情報を IMPORT します。
↓テーブル単位
begin
DBMS_STATS.IMPORT_TABLE_STATS (
ownname => 'SCOTT',
tabname =>'EMP',
stattab => 'STATTAB',
statid => null,
cascade => false);
end;
/
↓スキーマ単位
begin
DBMS_STATS.IMPORT_SCHEMA_STATS (
ownname => 'SCOTT',
stattab => 'STATTAB',
statid => null,
statown => null,
no_invalidate => TRUE);
end;
/
◆ IMPORT した統計情報を確認します。
select table_name, num_rows,blocks, avg_row_len, user_stats
from user_tables where table_name='EMP';
TABLE_NAME NUM_ROWS BLOCKS AVG_ROW_LEN USE
------------------------------ ---------- ---------- ----------- ---
EMP 14 1 41 NO
■スキーマの全オブジェクトに関する統計情報を削除する方法
統計情報の削除は以下のコマンドをご利用下さい。
begin
dbms_stats.delete_schema_stats('SCOTT');
end;
/
-----------------------------------------------------------------------------------------
■統計情報の取得調査方法
以下のディクショナリ･ビューを 統計情報取得（analyze index xxxx compute statistics）の前後で取得し、
結果を比較して統計情報取得状況を調査する。
確認するためのディクショナリ･ビュー
-----------------------------------
DBA_INDEXES
DBA_IND_PARTITIONS
DBA_IND_SUBPARTITIONS
列名と解説
----------
BLEVEL : B*-treeの高さ
LEAF_BLOCKS : リーフ･ブロックの数
DISTINCT_KEYS : キー値の値の種類の数(NOT NULL列を含む索引の場合には索引列の値の種類の数と同じ値になる)
AVG_LEAF_BLOCKS_PER_KEY : 値ごとのリーフ･ブロックの平均数(UNIQUE索引は常にこの値は1)
AVG_DATA_BLOCKS_PER_KEY : 値ごとのデータ･ブロックの平均数(索引のついている列データが同じ値を持つ行が平均で
何ブロックに分散しているかを表している)
CLUSTERING_FACTOR : KROWN:61358『索引の統計値であるクラスタ化係数(CLUSTERING_FACTOR)について』参照
SAMPLE_SIZE (-): 統計の収集をESTIMATE指定で行った時のサンプル・サイズ
LAST_ANALYZED (-): 最新の統計収集日時
GLOBAL_STATS (**)(-): KROWN:45745『パーティション表に対する統計情報取得のレベルについて』参照
USER_STATS (**)(-): KROWN:27003『統計情報が USER 定義のものかどうか判断する方法』参照
PCT_DIRECT_ACCESS(**)(GP)(-): 索引構成表の2次索引で使用する統計値で、直接行アクセスできる割合(この値が100以外の値のときには
索引の再構築を検討してください)
例：ディクショナリ確認例
select index_name,table_name,last_analyzed from dba_indexes where index_name='PK_EMP';
select * from dba_ind_partitions where index_name='PK_EMP';
select * from dba_ind_subpartitions where index_name='PK_EMP';
■インデックスのリーフ分割調査方法
以下のSQLを index再構築(ALTER INDEX ... REBUILD)の前後で実施し、
結果を比較してリーフブロック分割状況を調査する。
-------------------------- SQL ------------------------
validate index {インデックス名};
select height,blocks,lf_blks,lf_rows,del_lf_rows,br_blks,br_rows
from index_stats where name='インデックス名';
-------------------------------------------------------
以下、参考例と結果
validate index PK_EMP;
select height,blocks,lf_blks,lf_rows,del_lf_rows,br_blks,br_rows
from index_stats where name='PK_EMP';
HEIGHT BLOCKS LF_BLKS LF_ROWS DEL_LF_ROWS BR_BLKS BR_ROWS
---------- ---------- ---------- ---------- ----------- ---------- ----------
1 8 1 14 0 0 0
●参考情報
※INDEX_STATSで調べるインデックスは事前にVALIDATEしておく必要がある。
これで収集したデータを基に統計が得られる。
※項目内容
HEIGHT インデックス階層の深さ
BLOCKS 全ブロック数（未使用も含む）
LF_BLKS リーフブロック数
LF_ROWS リーフブロックに含まれる行数
DEL_LF_ROWS 削除されたリーフの行数
BR_BLKS ブランチブロック数
BR_ROWS ブランチ行数
-----------------------------------------------------------------------------------------
■HINT句追加等、SQL文の変更が出来ない場合のチューニング方法について
これらの方法で必ず効果が出ると保証されるものではありません。
設定する前に検証環境での効果を確認する必要があります。
１．初期パラメータによる方法
(a)インデックスアクセスのコスト変更
オプティマイザの動作を補正する２つのパラメータ
（インデックスアクセスのコストを低く見積もり、インデックスアクセスを選択
しやすくする）でオプティマイザのコスト計算にバイアスを掛けることが出来ます。
２つのパラメータのデフォルト値（cachingは0、cost_adjは100）はバッチ処理では
最適ですが、オンライン処理では一般的に以下の初期設定値が目安となります。
optimizer_index_caching=90
optimizer_index_cost_adj=25
これら２つのパラメータは、セッション単位では動的に変更できますが、システム
全体を変更する場合は初期パラメータファイルを変更後、インスタンスの再起動が
必要です。セッション単位の変更は以下のコマンドで変更します。
SQL} alter session set optimizer_index_caching=95;
(b)複数表の結合の解析時間を縮小
複数表の結合を行うような問合せでは表の結合順序を最適化するために解析時間が
大幅にかかってしまう可能性があります。
その場合には初期化パラメータoptimizer_max_permutationsの値を小さくすること
によって解析時間を減少させることが出来ます。
optimizer_max_permutations=2000 （デフォルトは2000）
システム全体を変更する場合は初期パラメータファイルを変更後、インスタンスの
再起動が必要です。セッション単位の変更は以下のコマンドで変更します。
SQL} alter session set optimizer_max_permutations=1000;
(c)統計情報収集のレベルを設定
アドバイザ機能レベル（statistics_level）が”BASIC”に変わっている場合、
デフォルトの”TYPICAL”として効果を比較してみる。以下はパラメータの例と
レベル値の意味です。
statistics_level=TYPICAL
＜値の意味＞
* BASIC
使用可能になるアドバイザ機能、統計情報はありません。
* TYPICAL(デフォルト)
一部のアドバイザ機能、統計情報の取得が可能になります。
【使用可能になるアドバイザ機能】
- バッファ・キャッシュ・アドバイザ
- MTTRアドバイザ
- 共有プールアドバイザ
- PGAアドバイザ
【使用可能になる統計情報】
- セグメントレベル統計情報
- Timed statistics
TYPICAL に設定いただきますと、BASICでは使用することができなかった機能を
使用しての統計情報の取得が行えます。
TYPICAL に設定いただくことで、効率の良い実行計画が選択される可能性があります。
システム全体を変更する場合は以下のコマンドで変更可能です。
SQL} alter system set statistics_level=TYPICAL
２．列値ヒストグラム統計の収集による方法
チューニング対象SQL文の条件句に指定されている列に格納されている値の分布に
ばらつきがある場合には、その列に対してヒストグラムを作成することによって最適な
実行計画を生成することができます。
設定例：
SQL} analyze table {テーブル名} compute statistics for all columns;
for columns の後に、size xx で作成するヒストグラムの区間の最大数を設定
します。デフォルトは 75 です。
sizeには、検索条件になるカラムデータの種類（DISTINCT値）を指定することが
一般的です。
３．高速応答オプティマイズ(FIRST_ROWS_n)を選択する方法
問合せ結果全体ではなく最初の一部を高速に返すオプティマイズ方法として
高速応答オプティマイズ(FIRST_ROWS_n)を選択すると、OLTP環境では有効な場合が
あります。
インスタンス・レベルで指定する場合、初期パラメータに値を指定します。
以下は設定例と値の種類となります。
設定例：optimizer_mode = first_rows_100
＜optimizer_mode値の種類＞
choose ・・・関連する表に最低1つの統計情報がある場合はCBO、
ない場合にはRBOを使います。
rule ・・・統計情報の有無に関わらずRBOを使います。
first_rows/first_rows_n ・・・CBOの実行方法として、最初の行を戻すまでの
応答時間（レスポンス）を最小限に抑えます。
all_rows・・・CBOの実行方法として、全体的な応答時間（スループット）を
最小限に抑えます。
first_rows_nでは、統計情報の有無に関わらずCBOが選択され、最初のn行
(n=1, 10, 100, 1000)を高速に返すようにオプティマイズが行われます。
この方法は完全にコストに基づいて評価が行われ、nの値によって選択される計画も
変わる可能性があります。従来のような経験則は使用されません。
CBOは複数の実行計画を評価し、それぞれについて、最初のn行を取得するための
コストを算出します。
高速応答オプティマイズでは、問合せ結果全体の取得は必ずしも高速にはならない
ことに注意してください。
結果全体を高速に取得したい場合は、ALL_ROWSを選択する必要があります。
このパラメータはセッション単位では動的に変更できますが、システム全体を
変更する場合は初期パラメータファイルを変更後、インスタンスの再起動が
必要です。セッション単位の変更は以下のコマンドで変更します。
SQL} alter session set optimizer_mode=first_rows_100;
４．実行計画を固定する方法(プラン・スタビリティ)
オプティマイザが生成したSQL文の実行計画に相当する「アウトライン」を作成し、
別のインスタンスでそのアウトラインの使用を宣言し、元の実行計画を使用する
ように設定します。
プランスタビリティ(アウトライン)の設定
- CREATE ANY OUTLINEシステム権限が必要です。
- ALTER SESSION SET CREATE_STORED_OUTLINES = TRUE | FALSE | {category}
TRUEまたはカテゴリ名を指定すると、そのセッションで発行されたSQL文全てに
対してストアド・アウトラインが作成されます。TRUEを設定した場合の
カテゴリは"DEFAULT"というカテゴリ名で登録されます。
設定例：
SQL} grant create any outline to {対象ユーザ}; システム権限で実行
SQL} connect demo/demo 対象ユーザに変更
SQL} alter session set create_stored_outlines = true;
以上
-----------------------------------------------------------------------------------------
■ロックについての考察（その１）
INDEXリビルドで取得するロックとUPDATEで取得するロックの違いについて。
TMロック（DMLエンキュー）は、以下のいずれかのモードで取得される。
RS(SS): 行共有 LMODE=2
RX(SX): 行排他 LMODE=3
S: 共有 LMODE=4
SRX(SSX): 共有行排他 LMODE=5
X: 排他 LMODE=6
各モードの互換性は以下のとおり。
要求するモード
RS RX S SRX X
――――――――――
既モ RS | 可 可 可 可 否
に｜ |
取ド RX | 可 可 否 否 否
得 |
さ S | 可 否 可 否 否
れ |
て SRX | 可 否 否 否 否
い |
る X | 否 否 否 否 否
★alter index rebuild online を行った SID=9 のセッション例
SQL} select sid,type,id1,lmode,request,ctime,block from v$lock where sid=9;
SID TY ID1 LMODE REQUEST CTIME BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
rebuild 9 TM 6655 (S) 4 0 13 0
" 9 TM 6622 (RS) 2 (S) 4 16 0
" 9 DL 6622 (RX) 3 0 16 0
↑
■Lock TYPEが
TM - DML enqueue
DL - Direct loader parallel index create
SQ - Sequence number enqueue
の場合に対象オブジェクトを特定することができます。
★
SQL} select sid,type,id1,lmode,request,ctime,block from v$lock where sid in (8,9);
SID TY ID1 LMODE REQUEST CTIME BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
update 8 TX 524293 (X) 6 0 1104 0
" 8 TM 6622 (RX) 3 0 1104 1
rebuild 9 TM 6655 (S) 4 0 13 0 ← 可：共有 取得
" 9 TM 6622 (RS) 2 (S) 4 16 0 ← 可：行共有 取得
" 9 DL 6622 (RX) 3 0 16 0 ← 可：行排他 取得
↑ V$LOCKのID1列の値が、該当表のOBJECT_IDです。
以上
-----------------------------------------------------------------------------------------
■■■PIの便利活用例
・PIのWATからCPU負荷の多いSQLを確認できます。
以下手順です。
■PIにアクセスし、”アドミニストレータツール”ボタンでWeb Admin Tool画面(WAT)に入ります。
「コンソール」→「Top Minder」をクリックするとTop Minder画面が別画面で開きます。
Top Minder画面で調べたいホストの「＋」部分をクリックするとそのホストのインスタンスが展開します。
該当DBのInstance Nameをマウス右ボタンでクリックするとポップアップメニューがで出るので”SQL Minder”を選択します。
SQL Minder画面が別画面で開きます。グラフが出てきます。グラフ左上に「Wait Event Disk(I/O)」となっているポップアップ
メニューを「CPU Utilization」 に変更します。
SQL Minder画面内のアイコン（Diskの絵）にマウスポインタを合わせると”共有プール内のSQL文を取得する”
と出るのでこれをクリックします。
”SQL取得条件”のダイアログが出るので、取得条件を「TOP CPU＿TIME/EXEC」にします。
（発行ユーザー名、最大取得行は適時入力）良ければ「OK」をクリック。
★グラフの下にCPUを多く使った順にSQL文が出ます。
■■■PIのWeb Admin Tool (WAT) を使う際に使用するポート番号を変更する方法
設定ファイルを編集・保存後、PI を再起動することで変更できます。
(Solaris)
$IST_HOME/etc/istwsrv.conf
(Windows)
{Drive}:\Program Files\Insight\Performance\etc\istwsrv.conf
■手順
（A)現在のポート番号の使用状況を確認しておきます。
netstat -an | grep 12345 (変更前の値で取得。応答があることを確認)
netstat -an | grep 13116 (変更予定の値で取得。応答がないことを確認)
（B)下記の位置にある設定ファイル(念のためバックアップ)の、ServerセクションにあるPortディレクティブ
の数値を変えたい値に変更して保存。
(Solaris)
$IST_HOME/etc/istwsrv.conf
(Windows)
{Drive}:\Program Files\Insight\Performance\etc\istwsrv.conf
（C)PI を再起動し、起動状況を確認。
istctl stopall
istctl startall
istctl status
（D)新しいポート番号の使用状況を確認。
netstat -an | grep 12345 (変更前の値で取得。応答がないことを確認)
netstat -an | grep 13116 (変更後の値で取得。応答があることを確認)
※WATから設定できるのは以下の設定ファイルのみ
・インスタンス情報（Port定義はありません）
・user.conf （ファイル自体）
・wat.conf ”
・minder.conf ”
・report.conf ”
・js.conf ”
・monitor.conf ”
・ライセンス情報 （Port定義はありません）
■■Report data情報の収集
・コマンド： istctl collectlog dataを実行
画面に表示される[PI-SUP.ホスト名.日付.tar.bz2]ファイルの提供
・xml形式とtext形式のレポートがある場所
$IST_USR_HOME/host名/oracle_sid名/report配下の
xmlとtext 配下にレポートファイルがある。
■■■ロックの種類
表ロック時に発生する TM エンキューをトレースするには、V$LOCK パフォーマンスビューを理解する必要がある。
まず、TMの種類と関係について
LMODEの数字が大きいほど、重度なロックとなる。
LMODE ロックの名称 呼称 旧呼称 (別名)?
1 なし NULL - -
2 行共有 RS/SS Row Share Sub Share
3 行排他 RX/SX Row eXclusive Sub eXclusive
4 共有 S Share
5 共有行排他 SRX/SSX Share Row eXculsive Share Sub eXculsive
6 排他 X eXclusive
■共有ロックと排他ロック
・共有ロック
共有ロックは主に参照を行う際に掛けるロックであり複数設定することも可能。
しかし SELECT の度にロックを掛けているわけではなく、データや表定義が変更されると困る操作のときにだけ掛けられる。
例: 更新予定の行を宣言して SELECT する(RSロック)、
インデックスの作成中に本体である表定義が変更されないようにロックするなどである。(Sロック)
簡単に言うと、読み取りが終了(もしくは終わりと宣言 COMMIT,ROLLBACK)するまで 行 または テーブル定義 は
変更しないでねフラグを立てる。
・排他ロック
排他ロックは更新を行なう際に掛けるロックであり 1リソース(行や表)に対して 1つだけ設定できる。
こちらは同じリソースを同時に更新させないようにするためのもの。
・ロックの解除
ロックの解除には COMMT または ROLLBACK を行なう。
・行共有ロック(RS / SS)
SELECT ...FOR UPDATE 文により「表」に掛けられるロック。
注意： SELECT FOR UPDATE WAIT による WAIT の秒数指定は排他ロック(X) された表に対しては無効になってしまう。
DDL: DROP TABLE(Xロック)、ダイレクト・パス・インサート(X) などが実行できなくなる。
・行排他ロック(RX / SX)
INSERT,UPDATE,DELETE 文により、「表」に掛けられるロック。
・ALTER INDEX 〜 REBUILD ONLINE; (Sロック)が待機する。
インデックスを張っていない外部制約のケース では行排他ロックから共有、共有行排他ロックへ
エスカレートする可能性があるので注意が必要(簡単に回避できる)
・共有ロック(S)
LOCK TABLE table IN SHARE MODE
一部のDDL CREATE INDEX /VIEW/PROCEDURE/SYNONYM などにより「表」に掛けられるロック。
ALTER INDEX 〜 REBUILD ONLINE ; (Sロック) では待機状態になる。(CREATE INDEX は NOWAIT)
・共有行排他ロック(SRX / SSX)
LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE により「表」に掛けられるロック。
インデックスを張っていない外部制約のケース で CASCADE 設定時に間接的に発生する。
・排他ロック(X)
LOCK TABLE table IN EXCLUSIVE MODE
DROP TABLE/ALTER TABLE などにより「表」に掛けられるロック。
一部のDML(ダイレクト・パス・インサート)でも発生する。
■表ロック同士の関係マトリックス
[別のセッションの後続処理に許可されるロックモード]
LMODE 表ロック ロックを発行するSQL 行共有 行排他 共有 共有行排他 排他
1 なし SELECT ... FROM table ... ● ● ● ● ●
------------------------------------------------------------------------------------------
2 行共有 SELECT ... FOR UPDATE [OF ...] ▲ ▲ ▲ ▲ ×
LOCK TABLE ...
ROW SHARE MODE ● ● ● ● ×
------------------------------------------------------------------------------------------
3 行排他 INSERT INTO table ... ● ▼ × × ×
UPDATE table ... ▲ ▲ × × ×
DELETE FROM table ... ▲ ▲ × × ×
LOCK TABLE ...
ROW EXCLUSIVE MODE ● ● × × ×
------------------------------------------------------------------------------------------
4 共有 LOCK TABLE
...SHARE MODE ● × ● × ×
------------------------------------------------------------------------------------------
5 共有行排他 LOCK TABLE ...
SHARE ROW EXCLUSIVE MODE ● × × × ×
------------------------------------------------------------------------------------------
6 排他 LOCK TABLE ...
EXCLUSIVE MODE × × × × ×
------------------------------------------------------------------------------------------
● ロックを取得可能
× ロックの取得は不可能
▲ ロックを取得可能であるが別セッションからの同一行へのアクセスは待機させられる(TX待機)
▼ ロックを取得可能であるが別セッションからのプライマリキー制約、ユニーク制約に該当する行の INSERT は待機させられる(TX待機)
▲ ▼ に関して：トランザクションが分散トランザクションの場合には初期化パラメータによってタイムアウトが発生する。
■■■lsInventoryの取得例（oraInst.loc直接指定）
・opatch lsinventory -detail -invPtrLoc /{PATH}/oraInst.loc
例) opatch lsinventory -detail -invPtrLoc /opt/oracle/product/10.1.3/oraInst.loc
■■■実行中のSQL文を確認する方法
select q.sql_text from v$sql q,v$session s
where q.address=s.sql_address
and q.hash_value=s.sql_hash_value
and username='ユーザ名';
■例：
select q.sql_text from v$sql q,v$session s
where q.address=s.sql_address
and q.hash_value=s.sql_hash_value
and username='SCOTT';
■■■prstat等でCPU負荷の高いoracleプロセスのPIDからセッション情報等を取得する方法
重いPIDをいくつかリストアップします。
% prstat -s cpu
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
10363 oracle 272M 235M run 10 0 0:02:08 55% oracle/2
22587 oracle 280M 240M sleep 59 0 0:00:32 2.0% oracle/2
11759 oracle 278M 226M sleep 59 0 0:01:04 0.5% oracle/12
26244 oracle 3344K 1984K cpu0 49 0 0:00:10 0.4% prstat/1
...
(2) 上記のPIDに該当するコマンド名をPSコマンドで調べます。
上記PIDに該当するものの中でコマンド(CMD)がoracle{SID名}...のPIDを調べます。
% ps -ef
UID PID PPID C STIME TTY TIME CMD
oracle 22587 22334 1 15:44:32 ? 0:55 oracle{SID} (DESCRIPTION=
(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
...
(3) 上記PIDに該当するoracleのセッションID等の情報を以下のようなSQLで調査することが出来ます。
※該当のPIDが実行中である必要があります。
実行の結果、行が無い場合は無視して下さい。
■調査用SQLサンプル
-----------------------------------------------------------------
col username for a10
col machine for a15
col program for a30
col logon_time for a20
set pagesize 9999
select s.sid "SID", s.username "USERNAME", p.spid "OS PID",
s.machine "MACHINE", s.program "PROGRAM",
to_char(s.logon_time, 'yy/mm/dd hh24:mi:ss') "LOGON TIME",
a.sql_text "SQL TEXT"
from v$session s, v$process p, v$sqlarea a
where p.spid ={OS上のPID} ★こちらに値を設定
and s.paddr = p.addr
and s.sql_address=a.address(+)
and s.sql_hash_value=a.hash_value(+)
and s.username is not null
and s.audsid != userenv('SESSIONID');
-----------------------------------------------------------------
■■シェルからsqlを実行する例
#!/bin/sh
$ORACLE_HOME/bin/sqlplus "system/manager@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node1)(PORT=1521))
(CONNECT_DATA=(SID=ORCL)))" @sample.sql
オラクル専用ページへもどる