2014年8月23日 (土)

IO Resource Manager 関係のメモ

黒い画面の好きなyskwkzhrさんも気に入るよね、きっと :)


PART 1 of 4 "Test interdatabase consolidation with Oracle Exadata IORM"

PART 2 of 4 "Test interdatabase consolidation with Oracle Exadata IORM"

PART 3 of 4 "Test intradatabase consolidation with Oracle Exadata IORM"

PART 4 of 4 "Test intradatabase consolidation with Oracle Exadata IORM"


ここで使ってるモニターリングツールはSwingbenchでも有名なDominic Gilesさんのサイトね。ステキです:)
Database Time Monitor
CPU Monitor
Monitor DB

| | コメント (0) | トラックバック (0)

2014年1月 6日 (月)

SELECT ~ FOR UPDATE SKIP LOCKED その4 - もしもITL不足だったら...

skip lockedのつづきです。

ITLエントリー不足時のskip lockedの動きを確認してみるか....


100行が1ブロックに収まるような表を作成しておく...計算上、ITLエントリーは最大で4エントリー程度になるように....したつもり....
(ASSMで、INITRANSはデフォルト、ブロックサイズは8KB、PCTFREEは0%)

SCOTT@pdborcl> r
1 select
2 objectid
3 ,file#
4 ,block#
5 ,count(id) as num_of_rows
6 from
7 (
8 select
9 dbms_rowid.rowid_object(rowid) as objectid
10 ,dbms_rowid.rowid_relative_fno(rowid) as file#
11 ,dbms_rowid.rowid_block_number(rowid) as block#
12 ,id
13 from
14 q
15 )
16 group by
17 objectid
18 ,file#
19 ,block#
20 order by
21 objectid
22 ,file#
23* ,block#

OBJECTID FILE# BLOCK# NUM_OF_ROWS
---------- ---------- ---------- -----------
93077 9 972461 100

※セッション1 - lockできた

SESSION1@pdborcl> select * from q where id = '0001' for update;

ID
----
TEXT_STRING
----------------------------------------------------------------------
0001
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション2 - lockできた。 この時点で 1 + 1 = 2 のITLエントリは使い切っている。

SESSION2@pdborcl> select * from q where id = '0002' for update;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0002
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション3 - lockできた。 ITLがブロック内の空きスペースに作れたため :)

SESSION3@pdborcl> select * from q where id = '0003' for update;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0003
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション4 - 計算上のITLエントリー数の上限値. 問題なくlockできた。

SESSION4@pdborcl> select * from q where id = '0004' for update;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0004
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション5 - 狙い通り! 5つめのITLエントリーを作成するだけの空きがブロック内にない状況なので待機しちゃう :)

SESSION5@pdborcl> select * from q where id = '0005' for update;


待機イベント見れば一目瞭然、ITLエントリー不足で待機してますね!

SYS@pdborcl> select username,event from v$session where username = 'SCOTT'

USERNAME EVENT
---------- ----------------------------------------
SCOTT SQL*Net message from client
SCOTT SQL*Net message from client
SCOTT enq: TX - allocate ITL entry
SCOTT SQL*Net message from client
SCOTT SQL*Net message from client

ここまでは、ITL不足な状況のfor update文ではよく見かける光景ですよね :)


for update skip lockedにすると.....

※セッション1 - locked!

SESSION1@pdborcl> select * from q where id = '0001' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0001
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション2 - locked!!

SESSION2@pdborcl> select * from q where id = '0002' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0002
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション3 - locked!!!

SESSON3@pdborcl> select * from q where id = '0003' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0003
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション4 - locked!!!!

SESSION4@pdborcl> select * from q where id = '0004' for update skip locked;

ID
----
TEXT_STRING
---------------------------------------------------------------------
0004
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

※セッション5(ITLエントリーが確保できず id = '0005'の行をlockすることができないので空振りします。興味深い動きですよね。)

SESSION5@pdborcl> select * from q where id = '0005' for update skip locked;

レコードが選択されませんでした。


次回へつづく.....かもしれない。



SELECT ~ FOR UPDATE SKIP LOCKED その1 - @sh2ndさんエントリの復習など
SELECT ~ FOR UPDATE SKIP LOCKED その2
SELECT ~ FOR UPDATE SKIP LOCKED その3

| | コメント (0) | トラックバック (0)

2014年1月 5日 (日)

SELECT ~ FOR UPDATE SKIP LOCKED その3

skip lockedのつづきです。

skip lockedの特徴を確認しておきますか!

skip lockedはロックの獲得ができた行だけをロック待機なしで返してくれる :)
IDが'0001', '0002', '0003', '0005'の行をロックしておく。

SESSION1@pdborcl> select id from q where id in ('0001', '0002', '0003', '0005') for update skip locked;

ID
----
0001
0002
0003
0005

IDが '0001','0002','0003'の行は先行のトランザクションで既にロックされているため、ロックできた行だけがロック待機なしで返される。

SESSION2@pdborcl> select id from q where id in ('0001', '0002', '0003', '0004', '0005', '0006') for update skip locked;

ID
----
0004
0006

もちろん、ロックできる行が1行もなければロックを待機せず空振!

SESSION3@pdborcl> select id from q where id in ('0001', '0002', '0003') for update skip locked;

レコードが選択されませんでした。


つづく。


SELECT ~ FOR UPDATE SKIP LOCKED その1 - @sh2ndさんエントリの復習など
SELECT ~ FOR UPDATE SKIP LOCKED その2

| | コメント (0) | トラックバック (0)

2013年12月31日 (火)

SELECT ~ FOR UPDATE SKIP LOCKED その2

つづきです。


そういえば、skip lockedって構文がマニュアルでは解説されていないリリースでふつーーーーに、使われててビビったことあったな。
(マニュアルに書かれていないリリースでは、自己責任使ってねw)


Oracle12c R1 - SKIP LOCKED
http://docs.oracle.com/cd/E49329_01/server.121/b71278/statements_10002.htm#SQLRF55374


Oracle11g R2 - (skip locked、推奨事項などが追記された)
http://docs.oracle.com/cd/E16338_01/server.112/b56299/statements_10002.htm#i2126016


Oracle11g R1 - (skip locked登場)
http://otndnld.oracle.co.jp/document/products/oracle11g/111/doc_dvd/server.111/E05750-03/statements_10.htm#7292


Oracle10g R2 (ここまでのマニュアルにはskip lookedは記載されていない。AQがらみで使われていたのは確かだ....)
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/server.102/B19201-02/statements_10.html#6799


どのあたりのバージョンから登場していたのかはJonathan Lewisさんのブログからたどれば分かると思うよ...
http://jonathanlewis.wordpress.com/2010/05/31/skip-locked/


Oracle11g R2のドキュメントからは以下のような追記されている。


「この機能は、Oracle Streams Advanced Queuingなどのマルチコンシューマ・キュー環境で使用するために設計されています。
 キュー・コンシューマは、他のコンシューマによってロックされた行はスキップして未ロックの行を取得できるので、
 他のコンシューマの操作が終了するまで待つ必要はなくなります。
 SKIP LOCKED機能を直接使用するかわりに、Oracle Streams Advanced Queuing APIを使用することをお薦めします。」

と。

以下のリリースで確認したが skip lockedに関して動作の差は無いようだ。
2013/1/5追記
動作の差は無いようだ、とは書いたが、結果オーライってことでございます。内部動作までは見えないので(キリつ

・Oracle11g R1 11.1.0.7.0
・Oracle11g R2 11.2.0.1.0
・Oracle11g R2 11.2.0.2.0
・Oracle12c R1 12.1.0.1.0


※セッション1
SESSION1> select * from q order by id;

ID DATA
---------- ----------
1 a
2 b
3 c

※セッション1
SESSION1> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

ID DATA
---------- ----------
1 a

※セッション2
SKIP LOCKEDなのでしようとしていたレコードがロックできなければ空振りし、ロック獲得を待機しません
SESSION2> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

レコードが選択されませんでした。


※セッション1
SESSION1> DELETE FROM q WHERE id = 1;

1行が削除されました。

※セッション2
何度やっても同じですよね :)
SESSION2> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

レコードが選択されませんでした。


※セッション1
SESSION1> COMMIT;

コミットが完了しました。

SESSION1>

※セッション2
ここで初めて、対象レコードがロックできます!
マルチコンシューマ・キュー環境向けって意味がよ〜〜〜〜く分かる動きだと思います
SESSION2> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE SKIP LOCKED;

ID DATA
---------- ----------
2 b


skip lockedって面白いよね。

skip lockedの特徴について、もう少し書く予定、多分、来年へつづく。。。。。


みなさま、良いお年を!



SELECT ~ FOR UPDATE SKIP LOCKED その1 - @sh2ndさんエントリの復習など

| | コメント (0) | トラックバック (0)

SELECT ~ FOR UPDATE SKIP LOCKED その1 - @sh2ndさんのエントリの復習など

JPOUT Advent Calender 2013の@sh2ndさんのエントリーが面白かったので大晦日に酒飲みながら... :)
まずは twitterでのやり取りなど....


20131231_113305


20131231_163205

イケテナイとか、良いとか、自由に言えるのはユーザーだからこそだと思うんだ。
セールストークじゃない生の情報って大切だ。


ということで、skip locked へ行く前に、Oracle11g R1 11.1.0.7.0 および、Oracle12c R1 12.1.0.1.0 で @sh2ndさんのエントリーの復習から :)

※セッション1
SESSION1> select * from q order by id;

ID DATA
---------- ----------
1 a
2 b
3 c

※セッション1
SESSION1> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;

ID DATA
---------- ----------
1 a

※セッション2
SESSION2> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;
(ここで待たされる。待つことは正しい動き)

※セッション1
SESSION1> DELETE FROM q WHERE id = 1;

1行が削除されました。

※セッション1
SESSION1> commit;

コミットが完了しました。

SESSION1>

※セッション2はここでロックを獲得できる。
ID DATA
---------- ----------
2 b

SESSION2>


Oracle11g R2 11.2.0.1.0とOracle11g R2 11.2.0.2.0は、Wrong Resultだったんだと思うが...

※セッション1
SESSION1> select * from q order by id;

ID DATA
---------- ----------
1 a
2 b
3 c

※セッション1
SESSION1> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;

ID DATA
---------- ----------
1 a

※セッション2
SESSION2> SELECT id, data FROM q WHERE id = (SELECT MIN(id) FROM q) FOR UPDATE;
(ここで待たされる。というところまでは同じ)


※セッション1
SESSION1> DELETE FROM q WHERE id = 1;

1行が削除されました。

※セッション1
SESSION1> COMMIT;

コミットが完了しました。

SESSION1>

※セッション2 (注1
(しか〜〜〜し、なんとレコードが選択されませんでした!!!!!)
レコードが選択されませんでした。

SESSION2>

結果
OracleREAD COMMITTED
11.1.0.7.0ID=2を取得
11.2.0.1.0空振り
11.2.0.2.0空振り
12.1.0.1.0ID=2を取得


注1)
Oracle11g 11.2.0.3.0以降では修正されているとのこと...(私は手持ちのが無かったので未確認...だれか書いてw)

SELECT ~ FOR UPDATE SKIP LOCKEDへつづく...

| | コメント (0) | トラックバック (0)

2013年10月13日 (日)

AWRレポートはOracle Database 12c R1ではFlat Designに変更されたのか? ;p

AWRレポートもフラットデザイン採用? w

以下、Oracle Database 11g R2までのAWRレポート

20131013_70906




Oracle Database 12C R1では、フラットデザイン。 
意図してやっているのだろうか? 
border="1"がborder="0"になってる。CSSは以前のままだが。

20131013_70856

| | コメント (0) | トラックバック (0)

2013年8月13日 (火)

Cross Platform Transportable Tablespace #12

ネタとしては地味ですがOracle Database 12cのTransportalbe tablespaceも軽めにチェック

以前のエントリ..2009年か〜〜遠い目
Cross Platform Transportable Tablespace #11


あれ、ちょいとズレてるけどご愛嬌:)

06:59:36 SYS@orcl12c> select * from v$version;

BANNER CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production 0
PL/SQL Release 12.1.0.1.0 - Production 0
CORE 12.1.0.1.0 Production 0
TNS for Linux: Version 12.1.0.1.0 - Production 0
NLSRTL Version 12.1.0.1.0 - Production 0

プラットフォームの情報も変化はない。Mac OSの文字もそのまま..

06:52:31 SYS@pdborcl> select * from v$transportable_platform;

PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT CON_ID
----------- ----------------------------------------------------------------------------------------------------- -------------- ----------
1 Solaris[tm] OE (32-bit) Big 0
2 Solaris[tm] OE (64-bit) Big 0
7 Microsoft Windows IA (32-bit) Little 0
10 Linux IA (32-bit) Little 0
6 AIX-Based Systems (64-bit) Big 0
3 HP-UX (64-bit) Big 0
5 HP Tru64 UNIX Little 0
4 HP-UX IA (64-bit) Big 0
11 Linux IA (64-bit) Little 0
15 HP Open VMS Little 0
8 Microsoft Windows IA (64-bit) Little 0
9 IBM zSeries Based Linux Big 0
13 Linux x86 64-bit Little 0
16 Apple Mac OS Big 0
12 Microsoft Windows x86 64-bit Little 0
17 Solaris Operating System (x86) Little 0
18 IBM Power Based Linux Big 0
19 HP IA Open VMS Little 0
20 Solaris Operating System (x86-64) Little 0
21 Apple Mac OS (x86-64) Little 0

20行が選択されました。


con_idはお約束で追加されていますが、ビューは大きく変わってないようですね。

12cで試している方のエントリを見つけたのでメモ:
Oracle 12c: Transport tablespaces across platforms




Cross Platform Transportable Tablespace #11

| | コメント (0) | トラックバック (0)

2013年8月 8日 (木)

Difference of Initialization Parameters between 11g r1 (11.1.0.6.0) and 12c r1 (12.1.0.1.0) - including hidden params

※2014/8/4 修正、追記
比較したバージョンが誤っていたため訂正しました。正しくは、11g R1 11.1.0.6.0でした。


型の差分までは取得しませんでしが、Oracle11g R2 (11.2.0.1.0)とOracle12c R1 (12.1.0.1.0)の初期化パラメータ(隠しパラメータ含む)の差分をHTML化しました。(クエリ結果をHTML形式でspoolしただけですが)

まだどのような差分があるのか見切れていませんが、じ〜〜〜っくりと見ようと思っています :)

参考 (パラメータ数)
11g R2 11.2.0.1.0
11g R1 11.1.0.6.0
パラメータ総数 : 2049
隠しパラメータ数 : 1755 (うち ダブルアンダースコア隠しパラメータ数 : 10 )

11g R1 11.2.0.1.0
パラメータ総数 : 2399
隠しパラメータ数 : 2057 (うち ダブルアンダースコア隠しパラメータ数 : 10 )

12c R1 12.1.0.1.0
パラメータ総数 : 3351
隠しパラメータ数 : 2984 (うち ダブルアンダースコア隠しパラメータ数 : 11 )

隠しパラメータの増加が目立ちます.... (@@)

Difference of Initialization Parameters between 11g r1 (11.1.0.6.0) and 12c r1 (12.1.0.1.0)

| | コメント (0) | トラックバック (0)

2013年4月28日 (日)

db file scattered read と db file parallel read と db file sequential read (最終回)

無理矢理引っ張った感じですが、db file scattered read と db file parallel read と db file sequential readの最終回。

今日は、db file parallel read に注目してみようと思います。


db file parallel readはどのような待機イベントだったか再確認しておきましょう!

マニュアルでは以下のように説明されています。

db file parallel read
リカバリ時のイベントです。
バッファ・プリフェッチ中に、最適化(複数のシングル・ブロック読取りの実行ではない)として発生する可能性もあります。
リカバリ時に変更が必要となったデータベース・ブロックはデータベースからパラレルに読み込まれます。

すべてのI/Oが完了するまでの時間が待機時間となる

少々わかりずらいですが、「バッファ・プリフェッチ中に、最適化(複数のシングル・ブロック読取りの実行ではない)として発生する可能性もあります。」ってところがポイントですよね。(リカバリしているわけではないので!)

でてきましたね、 prefetch という単語が!

斜め読みしちゃうと?となりそうですが、「複数のシングル・ブロック読取りの実行ではない」という箇所からもシングル・ブロック読み取りの繰り返しではなく、一括読み込み的なI/O最適化に関連した動き、だろうな〜ということは想像できます.
db file scattered read と db file parallel read と db file sequential read (その6)でも簡単に記載しているので参考に)

連続したブロックを一括読取りするのは、 db file scattered read
単一ブロックをブロック単位で読み取るのは、 db file sequential read
そして、不連続な複数ブロックを一括読取りするのは、db file parallel read


不連続ってところもポイントですね! 連続してないんですよ!

そこで、db file scattered read と db file parallel read と db file sequential read (その1)に書いた赤字部分が鍵になってきます!

TABLE_NAME                     INDEX_NAME                       NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
------------------------------ ------------------------------ ---------- ------------- -----------------
HIGH_CLUSTERING_FACTOR PK_HIGH_CLUSTERING_FACTOR 100000 100000 99978
LOW_CLUSTERING_FACTOR PK_LOW_CLUSTERING_FACTOR 100000 100000 4348

CLUSTERING_FACTORってNUM_ROWSに近ければ近いほど、索引のキー順に行を読んでしまうと読んだ行数ど同じ程度のデータブロックを読み込む必要があるということを示しています。
(マニュアルにも書いてますよね。Oracle® Databaseパフォーマンス・チューニング・ガイド11gリリース2 (11.2) - 11.2.3.1 ブロックのI/O(行ではなく)の想定

マニュアル、読みました?? 

ほんとに? 
(マニュアル読むの大切ですよ〜マニュアル読んで、試して、大きくなった、私が通りますよ〜〜〜と。)

では、細かい説明はもういいですよね! (^^;;;

で、
INDEX RANGE SCANとなっている場合、CLUSTERING_FACTORが低い場合と高い場合では、読み込みブロック数に差がある、低い場合は、少ないブロック読み込みで済むが、高い場合はより多くのブロックを読み込む必要があるということになります :)


効率的なI/Oを目指すOracleさんなので....CLUSTERING_FACTORが高く..

select
/*+
leading(t2 t1)
use_nl(t2 t1)
index(t2 pk_high_clustering_factor)
*/
t2.id
,t2.name
,t1.name
from
low_clustering_factor t1
inner join high_clustering_factor t2
on
t1.id = t2.id
where
t2.id between 30001 and 35000
/

こんな実行計画になっていて、かつ、physical reads prefetch warmupが発生していない状況で、バッファキャッシュヒット率が悪いと物理読み込みが発生して....

Rows     Row Source Operation
------- ---------------------------------------------------
2421 NESTED LOOPS (cr=5252 pr=2841 pw=0 time=2771706 us)
2421 NESTED LOOPS (cr=2831 pr=2522 pw=0 time=4204941 us cost=5012 size=1530612 card=2501)
2421 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2589 pr=2458 pw=0 time=4188001 us cost=2510 size=765612 card=2502)
2421 INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=168 pr=121 pw=0 time=7663 us cost=8 size=0 card=2502)(object id 82774)
2421 INDEX UNIQUE SCAN PK_LOW_CLUSTERING_FACTOR (cr=242 pr=64 pw=0 time=0 us cost=0 size=0 card=1)(object id 82772)
2421 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=2421 pr=319 pw=0 time=0 us cost=1 size=306 card=1)

db file sequential read以外に、db file parallel readが発生するんですよね。

Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 163 0.00 0.00
SQL*Net message from client 163 0.96 3.36
db file parallel read 161 0.01 0.63
SQL*Net more data to client 161 0.00 0.00
db file sequential read 14 0.00 0.00
********************************************************************************

INDEX RANGE SCANとなっている場合、CLUSTERING_FACTORが低い場合と高い場合では、読み込みブロック数に差がある、低い場合は、少ないブロック読み込みで済むが、高い場合はより多くのブロックを読み込む必要があるということになりますよね :)

と書きましたが、それを確認する簡単な実験を一つ。

バッファキャッシュヒット率が100%の状態でauto traceした結果です。
同一件数ヒットするクエリかつ、実行計画もINDEX RANGE SCANなのですが、
CLUSTERING_FACTORが低い表は、consistent getsが少なく、CLUSTERING_FACTORが高い表は、consistent getsが多くなるという差が発生しているのに気づきましたか?
(どちらの表も同じ定義の表なのですが、CLUSTERING_FACTORだけは変えてあります。)


注)CLUSTERING_FACTORが高い場合オプティマイザは索引を利用したアクセス効率が悪いと判断しTABLE FULL SCANを行う場合もあります。(以下の例ではヒントでINDEX RANGE SCANを強制しています)

select * from low_clustering_factor where id between 1000 and 3057;

2058行が選択されました。

経過: 00:00:00.09

実行計画
----------------------------------------------------------
Plan hash value: 2077556633

--------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2059 | 615K| 95 (0)| 00:00:02 |
| 1 | TABLE ACCESS BY INDEX ROWID| LOW_CLUSTERING_FACTOR | 2059 | 615K| 95 (0)| 00:00:02 |
|* 2 | INDEX RANGE SCAN | PK_LOW_CLUSTERING_FACTOR | 2059 | | 5 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("ID">=1000 AND "ID"<=3057)


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
365 consistent gets
0 physical reads
0 redo size
666586 bytes sent via SQL*Net to client
1923 bytes received via SQL*Net from client
139 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2058 rows processed

select /*+ INDEX_ASC(t1 pk_high_clustering_factor) */ * from high_clustering_factor t1 where id between 1000 and 5000;

2058行が選択されました。

経過: 00:00:00.10

実行計画
----------------------------------------------------------
Plan hash value: 3928373190

---------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2002 | 598K| 2009 (0)| 00:00:25 |
| 1 | TABLE ACCESS BY INDEX ROWID| HIGH_CLUSTERING_FACTOR | 2002 | 598K| 2009 (0)| 00:00:25 |
|* 2 | INDEX RANGE SCAN | PK_HIGH_CLUSTERING_FACTOR | 2002 | | 7 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("ID">=1000 AND "ID"<=5000)


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
2201 consistent gets
0 physical reads
0 redo size
666587 bytes sent via SQL*Net to client
1923 bytes received via SQL*Net from client
139 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2058 rows processed


各SQL文実行時に物理I/Oが発生しCLUSTERING_FACTORが高ければ、db file parallel readが発生することに...

※SQLトレース(tkprofで整形済み)

SQL ID: ap97zhtgsmt34
Plan Hash: 2077556633
select *
from
low_clustering_factor where id between 1000 and 3057


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 139 0.03 0.07 96 365 0 2058
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 141 0.03 0.07 96 365 0 2058

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 84

Rows Row Source Operation
------- ---------------------------------------------------
2058 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=365 pr=96 pw=0 time=94236 us cost=95 size=630054 card=2059)
2058 INDEX RANGE SCAN PK_LOW_CLUSTERING_FACTOR (cr=143 pr=6 pw=0 time=3630 us cost=5 size=0 card=2059)(object id 82772)


Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 139 0.00 0.00
db file sequential read 96 0.00 0.05
SQL*Net message from client 139 0.02 1.09
********************************************************************************

SQL ID: fmynvkvbvrv49
Plan Hash: 3928373190
select /*+ INDEX_ASC(t1 pk_high_clustering_factor) */ *
from
high_clustering_factor t1 where id between 1000 and 5000


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 139 0.28 1.85 1647 2201 0 2058
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 141 0.28 1.85 1647 2201 0 2058

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 84

Rows Row Source Operation
------- ---------------------------------------------------
2058 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2201 pr=1647 pw=0 time=1756678 us cost=2009 size=612612 card=2002)
2058 INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=144 pr=6 pw=0 time=8099 us cost=7 size=0 card=2002)(object id 82774)


Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 139 0.00 0.00
db file sequential read 1594 0.01 1.66
SQL*Net message from client 139 0.02 1.68
db file parallel read 6 0.00 0.00
********************************************************************************


あ〜〜〜すっきり! :)

みなさん、よいゴールデンウィークを!




バックナンバー

db file scattered read と db file parallel read と db file sequential read (その1)
db file scattered read と db file parallel read と db file sequential read (その2)
db file scattered read と db file parallel read と db file sequential read (その3)
db file scattered read と db file parallel read と db file sequential read (その4)
db file scattered read と db file parallel read と db file sequential read (その5)
db file scattered read と db file parallel read と db file sequential read (その6)
db file scattered read と db file parallel read と db file sequential read (その7)
db file scattered read と db file parallel read と db file sequential read (その8)

| | コメント (0) | トラックバック (0)

2013年4月26日 (金)

db file scattered read と db file parallel read と db file sequential read (その8)

>次回はphysical reads prefetch warmupを発生させます。(引っ張り過ぎw

の予告通り、physical reads prefetch warmupを発生させてみます!

やったことをほぼそのまま書いておきますね:)

オラクルさん、ディクショナリーやらなんやらいろいろ読んでしまって、小さめのバッファキャッシュだとそれらでお腹いっぱいになったりするんだよねw (よく考えられてる:)


23:29:24 SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 313880576 bytes
Fixed Size 1336176 bytes
Variable Size 125832336 bytes
Database Buffers 180355072 bytes
Redo Buffers 6356992 bytes
データベースがマウントされました。
データベースがオープンされました。
23:29:47 SYS> select sid,serial# from v$session where username='SCOTT';

SID SERIAL#
---------- ----------
63 11


23:30:06 SYS> select name,value from v$sesstat vss join v$statname vsn on vss.statistic# = vsn.statistic#
where (name like '%prefetch%' or name like '%physical read%') and sid=63 order by name
/
NAME VALUE
---------------------------------------------------------------- ----------
index crx upgrade (prefetch) 0
physical read IO requests 89
physical read bytes 729088
physical read flash cache hits 0
physical read requests optimized 0
physical read total IO requests 89
physical read total bytes 729088
physical read total multi block requests 0
physical reads 89
physical reads cache 89
physical reads cache prefetch 0
physical reads direct 0
physical reads direct (lob) 0
physical reads direct temporary tablespace 0
physical reads for flashback new 0
physical reads prefetch warmup 0
physical reads retry corrupt 0
prefetch clients - 16k 0
prefetch clients - 2k 0
prefetch clients - 32k 0
prefetch clients - 4k 0
prefetch clients - 8k 0
prefetch clients - default 0
prefetch clients - keep 0
prefetch clients - recycle 0
prefetch warmup blocks aged out before use 0
prefetch warmup blocks flushed out before use 0
prefetched blocks aged out before use 0


※指定セッションのセッションレベルのSQLトレース開始!


23:30:27 SYS> exec dbms_monitor.session_trace_enable(63,11,true,false,null);

PL/SQLプロシージャが正常に完了しました。


....この間に、db file * read祭りになるクエリをSCOTTユーザで実行します!....


※指定セッションのセッションレベルSQLトレース終了!


23:32:21 SYS> exec dbms_monitor.session_trace_disable(63,11);

PL/SQLプロシージャが正常に完了しました。


:) db file scattered readが発生しています! 対象セッションのセッション統計をみて確認みると....

※SQLトレース結果(tkprofで整形済み)


select
/*+
leading(t2 t1)
use_nl(t2 t1)
index(t2 pk_high_clustering_factor)
*/
t2.id
,t2.name
,t1.name
from
low_clustering_factor t1
inner join high_clustering_factor t2
on
t1.id = t2.id
where
t2.id between 30001 and 35000

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.01 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 163 0.27 1.81 2364 5252 0 2421
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 165 0.28 1.82 2364 5252 0 2421

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 84

Rows Row Source Operation
------- ---------------------------------------------------
2421 NESTED LOOPS (cr=5252 pr=2364 pw=0 time=7618698 us)
2421 NESTED LOOPS (cr=2831 pr=2104 pw=0 time=8830835 us cost=5012 size=1530612 card=2501)
2421 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2589 pr=2070 pw=0 time=8807144 us cost=2510 size=765612 card=2502)
2421 INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=168 pr=34 pw=0 time=3764 us cost=8 size=0 card=2502)(object id 82774)
2421 INDEX UNIQUE SCAN PK_LOW_CLUSTERING_FACTOR (cr=242 pr=34 pw=0 time=0 us cost=0 size=0 card=1)(object id 82772)
2421 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=2421 pr=260 pw=0 time=0 us cost=1 size=306 card=1)


Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 163 0.00 0.00
Disk file operations I/O 1 0.00 0.00
db file sequential read 251 0.03 0.40
db file scattered read 37 0.02 0.23
SQL*Net message from client 163 0.02 1.71
SQL*Net more data to client 161 0.00 0.00
db file parallel read 160 0.08 1.07
********************************************************************************

select
/*+
leading(t1 t2)
use_nl(t1 t2)
index(t1 pk_low_clustering_factor)
*/
t1.id
,t1.name
,t2.name
from
low_clustering_factor t1
inner join high_clustering_factor t2
on
t1.id = t2.id
where
t1.id between 1 and 5000

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 173 0.24 0.77 1302 3367 0 2566
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 175 0.24 0.78 1302 3367 0 2566

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 84

Rows Row Source Operation
------- ---------------------------------------------------
2566 NESTED LOOPS (cr=3367 pr=1302 pw=0 time=913653 us)
2566 NESTED LOOPS (cr=801 pr=232 pw=0 time=324655 us cost=5231 size=1530000 card=2500)
5000 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=564 pr=226 pw=0 time=78984 us cost=229 size=1530000 card=5000)
5000 INDEX RANGE SCAN PK_LOW_CLUSTERING_FACTOR (cr=181 pr=8 pw=0 time=5896 us cost=11 size=0 card=5000)(object id 82772)
2566 INDEX UNIQUE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=237 pr=6 pw=0 time=0 us cost=0 size=0 card=1)(object id 82774)
2566 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2566 pr=1070 pw=0 time=0 us cost=1 size=306 card=1)


Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 173 0.00 0.00
db file sequential read 1302 0.00 0.62
SQL*Net message from client 172 0.01 1.66
SQL*Net more data to client 171 0.00 0.00

よかったよかった、うまく physical reads prefetch warmupが増加しててw (^^


NAME                                                                  VALUE
---------------------------------------------------------------- ----------
index crx upgrade (prefetch) 0
physical read IO requests 3294
physical read bytes 30957568
physical read flash cache hits 0
physical read requests optimized 0
physical read total IO requests 3294
physical read total bytes 30957568
physical read total multi block requests 15
physical reads 3779
physical reads cache 3779
physical reads cache prefetch 1916
physical reads direct 0
physical reads direct (lob) 0
physical reads direct temporary tablespace 0
physical reads for flashback new 0
physical reads prefetch warmup 485
physical reads retry corrupt 0
prefetch clients - 16k 0
prefetch clients - 2k 0
prefetch clients - 32k 0
prefetch clients - 4k 0
prefetch clients - 8k 0
prefetch clients - default 0
prefetch clients - keep 0
prefetch clients - recycle 0
prefetch warmup blocks aged out before use 20
prefetch warmup blocks flushed out before use 0
prefetched blocks aged out before use 0


physical reads prefetch warmupってその名の通り、warmupなんですよね。バッファキャッシュの。

いつもより余計に読み込んでるからって驚かないでね!

おまけ。

起動直後には、SYS関連のオブジェクトがバッファキャッシュに読み込まれてしまって、physical read prefetch warmupが発生しないこともなんどかありました。

で、試しに、バッファキャッシュをクリアしてみたんですね...そしたら、warmupするじゃないですか!


23:15:00 SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 313880576 bytes
Fixed Size 1336176 bytes
Variable Size 125832336 bytes
Database Buffers 180355072 bytes
Redo Buffers 6356992 bytes
データベースがマウントされました。
データベースがオープンされました。
23:15:18 SYS> select status,count(1) from v$bh group by status;

STATUS COUNT(1)
---------- ----------
xcur 5413
cr 165


※このとき既にバッファキャッシュはイッパイに! なにが乗っていたかというと..

SYS関連のオブジェクト...


OBJECT_NAME                    STATUS       COUNT(1)
------------------------------ ---------- ----------
ACCESS$ xcur 49
AQ$_MGMT_TASK_QTABLE_I xcur 2
AQ$_QTABLE_AFFINITIES_PK xcur 1
AQ$_QUEUES xcur 1
AQ$_QUEUES_CHECK xcur 1
AQ$_QUEUE_TABLES xcur 1
AQ$_QUEUE_TABLES_PRIMARY xcur 1
AQ$_QUEUE_TABLE_AFFINITIES xcur 2
AQ$_SCHEDULES xcur 1
AQ$_SUBSCRIBER_TABLE xcur 2
AQ$_SUBSCRIBER_TABLE_PRIMARY xcur 1
ARGUMENT$ xcur 11
ASSOC1 xcur 1
C_COBJ# xcur 45
C_FILE#_BLOCK# cr 4
C_FILE#_BLOCK# xcur 141
C_OBJ# xcur 159
C_OBJ#_INTCOL# xcur 319
C_TOID_VERSION# xcur 2821
C_TS# xcur 13
C_USER# xcur 6
DAM_CONFIG_PARAM$ xcur 2
DBMS_LOCK_ALLOCATED xcur 1
DEPENDENCY$ xcur 60
EDITION$ xcur 2
EMDW_TRACE_CONFIG_IDX_01 xcur 1

.... 以下略 ...


バッファキャッシュ、フラ〜〜〜ッシュ! ❤


23:15:35 SYS> alter system flush buffer_cache;

システムが変更されました。


※バッファキャッシュにはfreeができました。


23:15:46 SYS> select status,count(1) from v$bh group by status;

STATUS COUNT(1)
---------- ----------
xcur 2
free 5576


※クエリ実行前のセッション統計


NAME                                                                  VALUE
---------------------------------------------------------------- ----------
index crx upgrade (prefetch) 0
physical read IO requests 88
physical read bytes 720896
physical read flash cache hits 0
physical read requests optimized 0
physical read total IO requests 88
physical read total bytes 720896
physical read total multi block requests 0
physical reads 88
physical reads cache 88
physical reads cache prefetch 0
physical reads direct 0
physical reads direct (lob) 0
physical reads direct temporary tablespace 0
physical reads for flashback new 0
physical reads prefetch warmup 0
physical reads retry corrupt 0
prefetch clients - 16k 0
prefetch clients - 2k 0
prefetch clients - 32k 0
prefetch clients - 4k 0
prefetch clients - 8k 0
prefetch clients - default 0
prefetch clients - keep 0
prefetch clients - recycle 0
prefetch warmup blocks aged out before use 0
prefetch warmup blocks flushed out before use 0
prefetched blocks aged out before use 0


いつものクエリを実行.....

...中略...


※実行後、該当セッションのセッション統計を見てみると...


NAME                                                                  VALUE
---------------------------------------------------------------- ----------
index crx upgrade (prefetch) 0
physical read IO requests 3026
physical read bytes 32858112
physical read flash cache hits 0
physical read requests optimized 0
physical read total IO requests 3026
physical read total bytes 32858112
physical read total multi block requests 27
physical reads 4011
physical reads cache 4011
physical reads cache prefetch 2376
physical reads direct 0
physical reads direct (lob) 0
physical reads direct temporary tablespace 0
physical reads for flashback new 0
physical reads prefetch warmup 985
physical reads retry corrupt 0
prefetch clients - 16k 0
prefetch clients - 2k 0
prefetch clients - 32k 0
prefetch clients - 4k 0
prefetch clients - 8k 0
prefetch clients - default 0
prefetch clients - keep 0
prefetch clients - recycle 0
prefetch warmup blocks aged out before use 65
prefetch warmup blocks flushed out before use 0
prefetched blocks aged out before use 0

バッファキャッシュクリアしても出ることあるんだね。


これでおしまい。  あ、一つ思い出したので、次回にでも。

つづく。




バックナンバー

db file scattered read と db file parallel read と db file sequential read (その1)
db file scattered read と db file parallel read と db file sequential read (その2)
db file scattered read と db file parallel read と db file sequential read (その3)
db file scattered read と db file parallel read と db file sequential read (その4)
db file scattered read と db file parallel read と db file sequential read (その5)
db file scattered read と db file parallel read と db file sequential read (その6)
db file scattered read と db file parallel read と db file sequential read (その7)

| | コメント (0) | トラックバック (0)

2013年4月24日 (水)

db file scattered read と db file parallel read と db file sequential read (その7)

前回、物理読み込みが発生しない状況を作りdb file * read関連の物理読み込みが発生しない状況ではphysical reads prefetch warmup/cache prefetchが発生していないことを確認しました。

ということで、続きです。


physical reads prefetch warmupってどのような状況で増加するのか、待機イベントはどのようなものなのか確認してみることに..... (もうわかってるくせに〜w)

physical reads prefetch warmupは以下のように説明されています。
- バッファ・キャッシュの自動プリウォーム中にディスクから読み取られたデータ・ブロックの数 / class - 8 : cache

また、津島博士のパフォーマンス講座 第13回 キャッシュ周りについて でも説明されています。(この手の解説をマニュアルで読んだ記憶がないが、どこかに記載されてるのかな?....)

では、どのような待機イベントが発生するのか...
試してガッテン、じゃなくて、試して納得!でおなじみの、しばちょう先生のセッションの資料(ODDD2011)によると、db file scattered readが発生するようですね。


なるほど....どの程度かわかりませんが、バッファキャッシュにある程度データブロックが乗っかっているとphysical reads prefetch warmupって発生しないんだろうなぁ。というところまでは、なんとなく理解できました。:)


さっそく、physical reads prefetch warmupを発生させてみましょう!...

と、その前に、physical reads prefetch warmupは発生させず、physical reads cache prefetchだけを発生させてみますw

バッファキャッシュは本検証で実行するクエリでアクセスする表や索引以外のブロックで満たしてあります。

v$bhの状態


SYS> select status,count(1) from v$bh group by status;

STATUS COUNT(1)
---------- ----------
xcur 8903
cr 20

という状況(物理読み込みが発生しない状況)でdb file * read祭りになるクエリを実行してみることにします。

クエリを実行する前のセッション統計(prefetch関連のみ)は以下の通り。


22:04:51 SYS> l
1 select
2 name
3 ,value
4 from
5 v$sesstat vss
6 join v$statname vsn
7 on
8 vss.statistic# = vsn.statistic#
9 where
10 (
11 name like '%prefetch%'
12 or name like '%physical read%'
13 )
14 and sid=195
15 order by
16* name
22:04:52 SYS> /


NAME VALUE
---------------------------------------------------------------- ----------
index crx upgrade (prefetch) 0
physical read IO requests 479
physical read bytes 7012352
physical read flash cache hits 0
physical read requests optimized 0
physical read total IO requests 479
physical read total bytes 7012352
physical read total multi block requests 2
physical reads 856
physical reads cache 856
physical reads cache prefetch 377
physical reads direct 0
physical reads direct (lob) 0
physical reads direct temporary tablespace 0
physical reads for flashback new 0
physical reads prefetch warmup 0
physical reads retry corrupt 0
prefetch clients - 16k 0
prefetch clients - 2k 0
prefetch clients - 32k 0
prefetch clients - 4k 0
prefetch clients - 8k 0
prefetch clients - default 0
prefetch clients - keep 0
prefetch clients - recycle 0
prefetch warmup blocks aged out before use 10
prefetch warmup blocks flushed out before use 0
prefetched blocks aged out before use 0


※SQLトレース(tkprofにて整形済み)


select
/*+
leading(t2 t1)
use_nl(t2 t1)
index(t2 pk_high_clustering_factor)
*/
t2.id
,t2.name
,t1.name
from
low_clustering_factor t1
inner join high_clustering_factor t2
on
t1.id = t2.id
where
t2.id between 30001 and 35000

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 163 0.37 1.46 2084 5252 0 2421
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 165 0.38 1.47 2084 5252 0 2421

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 84

Rows Row Source Operation
------- ---------------------------------------------------
2421 NESTED LOOPS (cr=5252 pr=2084 pw=0 time=898088 us)
2421 NESTED LOOPS (cr=2831 pr=1866 pw=0 time=2127562 us cost=5012 size=1530612 card=2501)
2421 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2589 pr=1855 pw=0 time=2109985 us cost=2510 size=765612 card=2502)
2421 INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=168 pr=8 pw=0 time=14251 us cost=8 size=0 card=2502)(object id 82774)
2421 INDEX UNIQUE SCAN PK_LOW_CLUSTERING_FACTOR (cr=242 pr=11 pw=0 time=0 us cost=0 size=0 card=1)(object id 82772)
2421 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=2421 pr=218 pw=0 time=0 us cost=1 size=306 card=1)


Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 163 0.00 0.00
db file sequential read 624 0.01 0.84
SQL*Net message from client 163 0.02 2.22
SQL*Net more data to client 161 0.00 0.00
db file parallel read 141 0.02 0.42
********************************************************************************

select
/*+
leading(t1 t2)
use_nl(t1 t2)
index(t1 pk_low_clustering_factor)
*/
t1.id
,t1.name
,t2.name
from
low_clustering_factor t1
inner join high_clustering_factor t2
on
t1.id = t2.id
where
t1.id between 1 and 5000

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 173 0.31 0.85 1383 3367 0 2566
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 175 0.31 0.85 1383 3367 0 2566

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 84

Rows Row Source Operation
------- ---------------------------------------------------
2566 NESTED LOOPS (cr=3367 pr=1383 pw=0 time=1180156 us)
2566 NESTED LOOPS (cr=801 pr=233 pw=0 time=340045 us cost=5231 size=1530000 card=2500)
5000 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=564 pr=227 pw=0 time=98730 us cost=229 size=1530000 card=5000)
5000 INDEX RANGE SCAN PK_LOW_CLUSTERING_FACTOR (cr=181 pr=9 pw=0 time=7998 us cost=11 size=0 card=5000)(object id 82772)
2566 INDEX UNIQUE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=237 pr=6 pw=0 time=0 us cost=0 size=0 card=1)(object id 82774)
2566 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2566 pr=1150 pw=0 time=0 us cost=1 size=306 card=1)


Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 173 0.00 0.00
db file sequential read 1383 0.01 0.66
SQL*Net message from client 172 0.02 2.24
SQL*Net more data to client 171 0.00 0.00

実行後のセッション統計を見てみると....おおおおおおおお!

physical reads cache prefetchは増加しているのでprefetchは発生していますが、physical reads prefetch warmupは発生していません。


NAME                                                                  VALUE
---------------------------------------------------------------- ----------
index crx upgrade (prefetch) 0
physical read IO requests 3963
physical read bytes 35553280
physical read flash cache hits 0
physical read requests optimized 0
physical read total IO requests 3963
physical read total bytes 35553280
physical read total multi block requests 2
physical reads 4340
physical reads cache 4340
physical reads cache prefetch 1696
physical reads direct 0
physical reads direct (lob) 0
physical reads direct temporary tablespace 0
physical reads for flashback new 0
physical reads prefetch warmup 0
physical reads retry corrupt 0
prefetch clients - 16k 0
prefetch clients - 2k 0
prefetch clients - 32k 0
prefetch clients - 4k 0
prefetch clients - 8k 0
prefetch clients - default 0
prefetch clients - keep 0
prefetch clients - recycle 0
prefetch warmup blocks aged out before use 10
prefetch warmup blocks flushed out before use 0
prefetched blocks aged out before use 0

physical reads prefetch warmupとphysical reads cache prefetchが同時に増加していた時に比べ、発生している待機イベントに違いがあることに気づきましたか? :) そう、db file scattered readが発生していないんですよ!

次回はphysical reads prefetch warmupを発生させます。(引っ張り過ぎw


ところで、prefetch warmup blocks aged out before useという統計値が増加していますよね。
キャッシュバッファを暖めただけで利用されずに捨てられたデータブロック数をカウントしているようです。(マニュアルに記載されていないので、想像ですが)

悲しいですね、使われずに捨てられるなんて。


バックナンバー

db file scattered read と db file parallel read と db file sequential read (その1)
db file scattered read と db file parallel read と db file sequential read (その2)
db file scattered read と db file parallel read と db file sequential read (その3)
db file scattered read と db file parallel read と db file sequential read (その4)
db file scattered read と db file parallel read と db file sequential read (その5)
db file scattered read と db file parallel read と db file sequential read (その6)

| | コメント (0) | トラックバック (0)

2013年4月14日 (日)

db file scattered read と db file parallel read と db file sequential read (その6)

続きです。

system callからも読み取れますが、各待機イベントでは
db file sequential read - 単一ブロック読み込み
db file parallel read - 不連続ブロックの複数ブロックの読み込み
db file scattered read - 連続したブロックの複数ブロック読み込み

が行われ、読み込まれたブロックはバッファキャッシュに乗せられるわけです。

注)
今回は発生しないようにしていますが、Oracle11g R2では実行計画上フルスキャンとなっていても、db file scattered readまたはdirect path read(バッファキャッシュを経由しない)になる場合があります。(smart flash cacheが無い場合)

db file scattered read vs direct path read関連の話題は以下のブログを参考に :)
10046 trace name context forever - Oracle OpenWorld 2012 Unconference presented by JPOUG
10046 trace name context forever - Smart Flash Cache 簡単なパフォーマンス比較
技術情報| Insight Techology, Inc. Part 7 - 11gR2からのフルスキャン
Ask Tom "Direct path reads 11gR2" - Thanks for the question regarding "Direct path reads 11gR2", version 11.2.0.1

direct path readが発生していないので :)
...キャッシュヒット率100%ならば発生しないってこと、ですよね。

試してみます!

バッファキャッシュには以下のSQL文でアクセスする表以外のオブジェクトも含め事前に乗せてあります。
以下SQL文では表、索引ともバッファキャッシュヒット率100%になるようにしてあります。

v$bhの状態(STATUS=freeがないので空きブロックの無い状態)

STATUS       COUNT(1)
---------- ----------
xcur 8904
cr 21

SQLトレースを見ると物理読み込みは発生していないこと、db file * read待機イベントが発生していないことが確認できます!

SQLトレース(tkprofにて整形後)

select
/*+
leading(t2 t1)
use_nl(t2 t1)
index(t2 pk_high_clustering_factor)
*/
t2.id
,t2.name
,t1.name
from
low_clustering_factor t1
inner join high_clustering_factor t2
on
t1.id = t2.id
where
t2.id between 30001 and 35000

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 163 0.06 0.07 0 5252 0 2421
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 165 0.06 0.07 0 5252 0 2421

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 84

Rows Row Source Operation
------- ---------------------------------------------------
2421 NESTED LOOPS (cr=5252 pr=0 pw=0 time=63861 us)
2421 NESTED LOOPS (cr=2831 pr=0 pw=0 time=67887 us cost=5012 size=1530612 card=2501)
2421 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2589 pr=0 pw=0 time=51456 us cost=2510 size=765612 card=2502)
2421 INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=168 pr=0 pw=0 time=7260 us cost=8 size=0 card=2502)(object id 82774)
2421 INDEX UNIQUE SCAN PK_LOW_CLUSTERING_FACTOR (cr=242 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 82772)
2421 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=2421 pr=0 pw=0 time=0 us cost=1 size=306 card=1)


Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 163 0.00 0.00
SQL*Net message from client 163 0.02 2.51
SQL*Net more data to client 161 0.00 0.00
********************************************************************************

select
/*+
leading(t1 t2)
use_nl(t1 t2)
index(t1 pk_low_clustering_factor)
*/
t1.id
,t1.name
,t2.name
from
low_clustering_factor t1
inner join high_clustering_factor t2
on
t1.id = t2.id
where
t1.id between 1 and 5000

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 173 0.04 0.05 0 3367 0 2566
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 175 0.04 0.05 0 3367 0 2566

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 84

Rows Row Source Operation
------- ---------------------------------------------------
2566 NESTED LOOPS (cr=3367 pr=0 pw=0 time=44887 us)
2566 NESTED LOOPS (cr=801 pr=0 pw=0 time=32245 us cost=5231 size=1530000 card=2500)
5000 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=564 pr=0 pw=0 time=17496 us cost=229 size=1530000 card=5000)
5000 INDEX RANGE SCAN PK_LOW_CLUSTERING_FACTOR (cr=181 pr=0 pw=0 time=3624 us cost=11 size=0 card=5000)(object id 82772)
2566 INDEX UNIQUE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=237 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 82774)
2566 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2566 pr=0 pw=0 time=0 us cost=1 size=306 card=1)


Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 173 0.00 0.00
SQL*Net message from client 172 0.07 2.01
SQL*Net more data to client 171 0.00 0.00

db file * read祭りだった際には明らかに増加していた physical reads prefetch warmupやphysical reads cache prefetchも含め、
物理読み込みが発生しない状況であれば、それらの待機イベントも発生しないのは当然と言えば当然ですよね。 :)

SQL実行前のシステム統計(physical readとprefetch関連のみ)


---------------------------------------------------------------- ----------
index crx upgrade (prefetch) 0
physical read IO requests 2201
physical read bytes 18030592
physical read flash cache hits 0
physical read requests optimized 0
physical read total IO requests 2201
physical read total bytes 18030592
physical read total multi block requests 0
physical reads 2201
physical reads cache 2201
physical reads cache prefetch 741
physical reads direct 0
physical reads direct (lob) 0
physical reads direct temporary tablespace 0
physical reads for flashback new 0
physical reads prefetch warmup 0
physical reads retry corrupt 0
prefetch clients - 16k 0
prefetch clients - 2k 0
prefetch clients - 32k 0
prefetch clients - 4k 0
prefetch clients - 8k 0
prefetch clients - default 0
prefetch clients - keep 0
prefetch clients - recycle 0
prefetch warmup blocks aged out before use 0
prefetch warmup blocks flushed out before use 0
prefetched blocks aged out before use 0

SQL文実行後のシステム統計(physical readとprefetch関連のみ)

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
index crx upgrade (prefetch) 0
physical read IO requests 2201
physical read bytes 18030592
physical read flash cache hits 0
physical read requests optimized 0
physical read total IO requests 2201
physical read total bytes 18030592
physical read total multi block requests 0
physical reads 2201
physical reads cache 2201
physical reads cache prefetch 741
physical reads direct 0
physical reads direct (lob) 0
physical reads direct temporary tablespace 0
physical reads for flashback new 0
physical reads prefetch warmup 0
physical reads retry corrupt 0
prefetch clients - 16k 0
prefetch clients - 2k 0
prefetch clients - 32k 0
prefetch clients - 4k 0
prefetch clients - 8k 0
prefetch clients - default 0
prefetch clients - keep 0
prefetch clients - recycle 0
prefetch warmup blocks aged out before use 0
prefetch warmup blocks flushed out before use 0
prefetched blocks aged out before use 0

物理読み込みが発生しない状況を作りdb file * read関連の物理読み込みが発生しない状況で、physical reads prefetch warmup/cache prefetchが発生していないことは確認しました。

次回はphysical reads prefetch warmupってどんな時に発生しやすいのか確認してみます。その際、発生する待機イベントってなんだろう? (もうわかってるでしょ、でしょ?)

つづく

”SSD”、”SSD”、ってプロジェクトでお金握ってる人の耳元で毎日つぶやいていれば、

いつの日か、「あ、そうだ! SSDがあるじゃまいか」と、自分から言うようになるんじゃないかなと思っているんだが、だれか実践してくれないかなw 


バックナンバー

db file scattered read と db file parallel read と db file sequential read (その1)
db file scattered read と db file parallel read と db file sequential read (その2)
db file scattered read と db file parallel read と db file sequential read (その3)
db file scattered read と db file parallel read と db file sequential read (その4)
db file scattered read と db file parallel read と db file sequential read (その5)

| | コメント (0) | トラックバック (0)

2013年4月13日 (土)

db file scattered read と db file parallel read と db file sequential read (その5)

続きです。

@yoheiaさんがprefetch的な動き...と言っていますね。気になる気になる単語です :)

こことか、
http://www.oracle.com/technetwork/jp/content/007-087711-ja.html

ここなどにもちょろっと書かれていいます。
TANEL PODER'S BLOG: Advanced Oracle Troubleshooting Guide – Part 10: Index unique scan doing multiblock reads?!

マニュアルで記載されている箇所ってあるんでしたっけ? (誰となく..

v$sesstatから該当セッションのセッション統計から"phsical read"または"prefetch"を含む統計値を見みてみると...

SQL文の実行前と実行後を比較するとどの統計値が増加したか一目瞭然です。赤字部分にちゅうもーく!

Oracle® Databaseリファレンス11g リリース2 (11.2)を見てみると、

physical reads cache prefetch
- 事前にフェッチされた連続および不連続ブロックの数 / class - 8 : cache


physical reads prefetch warmup
- バッファ・キャッシュの自動プリウォーム中にディスクから読み取られたデータ・ブロックの数 / class - 8 : cache

と記載されています。どちらもprefetchと関連がありそうですね:)

physical reads cache prefetchの説明にもありますが、連続及び不連続ブロックという部分、待機イベントにも現れていますよね。

連続ブロックを物理読み込みする待機イベントと言えば、db file scatterd readですし、
不連続ブロックを一括読み込みするといえば、 db file parallel readですよね。:)

※SQL文実行前

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
index crx upgrade (prefetch) 0
physical read IO requests 48
physical read bytes 393216
physical read flash cache hits 0
physical read requests optimized 0
physical read total IO requests 48
physical read total bytes 393216
physical read total multi block requests 0
physical reads 48
physical reads cache 48
physical reads cache prefetch 0
physical reads direct 0
physical reads direct (lob) 0
physical reads direct temporary tablespace 0
physical reads for flashback new 0
physical reads prefetch warmup 0
physical reads retry corrupt 0
prefetch clients - 16k 0
prefetch clients - 2k 0
prefetch clients - 32k 0
prefetch clients - 4k 0
prefetch clients - 8k 0
prefetch clients - default 0
prefetch clients - keep 0
prefetch clients - recycle 0
prefetch warmup blocks aged out before use 0
prefetch warmup blocks flushed out before use 0
prefetched blocks aged out before use 0


※SQL文実行後

NAME                                                                  VALUE
---------------------------------------------------------------- ----------
index crx upgrade (prefetch) 0
physical read IO requests 4141
physical read bytes 42541056
physical read flash cache hits 0
physical read requests optimized 0
physical read total IO requests 4141
physical read total bytes 42541056
physical read total multi block requests 34
physical reads 5193
physical reads cache 5193
physical reads cache prefetch 4599
physical reads direct 0
physical reads direct (lob) 0
physical reads direct temporary tablespace 0
physical reads for flashback new 0
physical reads prefetch warmup 1052
physical reads retry corrupt 0
prefetch clients - 16k 0
prefetch clients - 2k 0
prefetch clients - 32k 0
prefetch clients - 4k 0
prefetch clients - 8k 0
prefetch clients - default 0
prefetch clients - keep 0
prefetch clients - recycle 0
prefetch warmup blocks aged out before use 0
prefetch warmup blocks flushed out before use 0
prefetched blocks aged out before use 0


ところで、prefetchもprefetch warmupも物理読み込みなのは分かりましたが、どのような状況だと発生するのでしょう? もしくは発生しやすいのでしょう?

そのヒントはその1に..

次回へつづく




バックナンバー

db file scattered read と db file parallel read と db file sequential read (その1)
db file scattered read と db file parallel read と db file sequential read (その2)
db file scattered read と db file parallel read と db file sequential read (その3)
db file scattered read と db file parallel read と db file sequential read (その4)

| | コメント (0) | トラックバック (0)

2013年4月 8日 (月)

db file scattered read と db file parallel read と db file sequential read (その4)

db file scattered read と db file parallel read と db file sequential read の続きです。

再びリクエストにお答えしてw、SQLとレースを有効した状態でstraceして該当待機イベントでどのようなsystem callになっているのか確認してみたよ > @yoheia :)


db file sequential read

WAIT #4: nam='db file sequential read' ela= 53584 file#=7 block#=375476 blocks=1 obj#=82773 tim=1365258291285100

....
pread64(17, "\6\242\0\0\372\267\5\0\\]\216\0\0\0\1\6\226y\0\0\1\0\0\0UC\1\0009]\216\0"..., 8192, 3070181376) = 8192

db file scattered read

WAIT #4: nam='db file scattered read' ela= 14462 file#=7 block#=374752 blocks=26 obj#=82773 tim=1365258291450333

....
pread64(17, "\6\242\0\0\340\267\5\0005]\216\0\0\0\1\6}\372\0\0\1\0\0\0UC\1\0002]\216\0"..., 212992, 3069968384) = 212992

db file parallel read

WAIT #4: nam='db file parallel read' ela= 25040 files=1 blocks=11 requests=11 obj#=82773 tim=1365258291641614

....
io_submit(1261568, 11, {{0x7981c8, 0, 0, 0, 17}, {0x79834c, 0, 0, 0, 17}, {0x7984d0, 0, 0, 0, 17}, {0x798654, 0, 0, 0, 17}, {0x7987d8, 0, 0, 0, 17}, {0x79895c, 0, 0, 0, 17}, {0x798ae0, 0, 0, 0, 17}, {0x798c64, 0, 0, 0, 17}, {0x798de8, 0, 0, 0, 17}, {0x798f6c, 0, 0, 0, 17}, {0x7990f0, 0, 0, 0, 17}}) = 11
io_getevents(1261568, 11, 128, {{0x79834c, 0x79834c, 8192, 0}, {0x7984d0, 0x7984d0, 8192, 0}, {0x7981c8, 0x7981c8, 8192, 0}, {0x798654, 0x798654, 8192, 0}, {0x7987d8, 0x7987d8, 8192, 0}, {0x798ae0, 0x798ae0, 8192, 0}, {0x798c64, 0x798c64, 8192, 0}, {0x798de8, 0x798de8, 8192, 0}, {0x7990f0, 0x7990f0, 8192, 0}, {0x798f6c, 0x798f6c, 8192, 0}, {0x79895c, 0x79895c, 8192, 0}}, {600, 0}) = 11

このdb file parallel readも狙って出せるくらいだから、たまたまそういう状況では発生しちゃうわけですよ。

以下のSQLトレースは、全てHIGH_CLUSTERING_FACTOR(表)に対する待機イベントですが、何が起きているか想像するとワクワクしてきませんか? (変態だな)

WAIT #4: nam='db file parallel read' ela= 10307 files=1 blocks=14 requests=14 obj#=82773 tim=1364725159669764 
WAIT #4: nam='db file scattered read' ela= 1931 file#=7 block#=374755 blocks=29 obj#=82773 tim=1364725159671819
WAIT #4: nam='db file parallel read' ela= 5874 files=1 blocks=14 requests=14 obj#=82773 tim=1364725159733551 
WAIT #4: nam='db file sequential read' ela= 337 file#=7 block#=374065 blocks=1 obj#=82773 tim=1364725159733959 

ということで、いろいろと、力尽きたので今日はここまで。

次回へつづく。


バックナンバー

db file scattered read と db file parallel read と db file sequential read (その1)
db file scattered read と db file parallel read と db file sequential read (その2)
db file scattered read と db file parallel read と db file sequential read (その3)

| | コメント (0) | トラックバック (0)

2013年4月 4日 (木)

db file scattered read と db file parallel read と db file sequential read (その3)

続きです。

リクエストにお答えして生SQLトレース(抜粋)を見てみましょう :)

最初に実行したSQL文のSQLトレースを見てみることにします。

select
/*+
leading(t2 t1)
use_nl(t2 t1)
index(t2 pk_high_clustering_factor)
*/
t2.id
,t2.name
,t1.name
from
low_clustering_factor t1
inner join high_clustering_factor t2
on
t1.id = t2.id
where
t2.id between 30001 and 35000
/

実行計画は以下の通り、index range/unique scan + nested loop joinが行われていました。

Rows     Row Source Operation
------- ---------------------------------------------------
2421 NESTED LOOPS (cr=5252 pr=2841 pw=0 time=2771706 us)
2421 NESTED LOOPS (cr=2831 pr=2522 pw=0 time=4204941 us cost=5012 size=1530612 card=2501)
2421 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2589 pr=2458 pw=0 time=4188001 us cost=2510 size=765612 card=2502)
2421 INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=168 pr=121 pw=0 time=7663 us cost=8 size=0 card=2502)(object id 82774)
2421 INDEX UNIQUE SCAN PK_LOW_CLUSTERING_FACTOR (cr=242 pr=64 pw=0 time=0 us cost=0 size=0 card=1)(object id 82772)
2421 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=2421 pr=319 pw=0 time=0 us cost=1 size=306 card=1)

待機イベント見てみると、index range/unique scan + table access by index rowidという実行計画からは想像できない待機イベントが....(実は狙って発生させてるくせに〜w

Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 163 0.00 0.00
db file scattered read 107 0.01 0.30
SQL*Net message from client 163 0.96 3.36
db file parallel read 161 0.01 0.63
SQL*Net more data to client 161 0.00 0.00
db file sequential read 14 0.00 0.00
********************************************************************************

(生)SQLトレース抜粋

...中略...
PARSE #4:c=1000,e=1534,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=1087412721,tim=1364725159601671
EXEC #4:c=1000,e=97,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1087412721,tim=1364725159601925
WAIT #4: nam='SQL*Net message to client' ela= 7 driver id=1650815232 #bytes=1 p3=0 obj#=82773 tim=1364725159602105 
WAIT #4: nam='db file scattered read' ela= 19499 file#=7 block#=371968 blocks=32 obj#=82774 tim=1364725159621743
WAIT #4: nam='db file scattered read' ela= 11156 file#=7 block#=373703 blocks=32 obj#=82774 tim=1364725159633042
WAIT #4: nam='db file scattered read' ela= 1699 file#=7 block#=375476 blocks=32 obj#=82773 tim=1364725159635032
WAIT #4: nam='db file scattered read' ela= 5889 file#=7 block#=367232 blocks=32 obj#=82772 tim=1364725159641300
WAIT #4: nam='db file scattered read' ela= 17223 file#=7 block#=368599 blocks=32 obj#=82771 tim=1364725159658667
FETCH #4:c=2999,e=56653,p=160,cr=6,cu=0,mis=0,r=1,dep=0,og=1,plh=1087412721,tim=1364725159658788
WAIT #4: nam='SQL*Net message from client' ela= 430 driver id=1650815232 #bytes=1 p3=0 obj#=82771 tim=1364725159659311 
WAIT #4: nam='db file parallel read' ela= 10307 files=1 blocks=14 requests=14 obj#=82773 tim=1364725159669764 
WAIT #4: nam='db file scattered read' ela= 1931 file#=7 block#=374755 blocks=29 obj#=82773 tim=1364725159671819 
WAIT #4: nam='SQL*Net message to client' ela= 3 driver id=1650815232 #bytes=1 p3=0 obj#=82773 tim=1364725159671902 
WAIT #4: nam='SQL*Net more data to client' ela= 40 driver id=1650815232 #bytes=8330 p3=0 obj#=82773 tim=1364725159672223
FETCH #4:c=2000,e=12910,p=43,cr=38,cu=0,mis=0,r=15,dep=0,og=1,plh=1087412721,tim=1364725159672272
WAIT #4: nam='SQL*Net message from client' ela= 9227 driver id=1650815232 #bytes=1 p3=0 obj#=82773 tim=1364725159681536 
WAIT #4: nam='db file parallel read' ela= 5766 files=1 blocks=12 requests=12 obj#=82773 tim=1364725159687404 
WAIT #4: nam='db file scattered read' ela= 1922 file#=7 block#=376416 blocks=32 obj#=82773 tim=1364725159689681
WAIT #4: nam='SQL*Net message to client' ela= 3 driver id=1650815232 #bytes=1 p3=0 obj#=82773 tim=1364725159689951 
WAIT #4: nam='SQL*Net more data to client' ela= 13 driver id=1650815232 #bytes=8278 p3=0 obj#=82773 tim=1364725159690473
FETCH #4:c=4000,e=8972,p=44,cr=32,cu=0,mis=0,r=15,dep=0,og=1,plh=1087412721,tim=1364725159690547
WAIT #4: nam='SQL*Net message from client' ela= 7980 driver id=1650815232 #bytes=1 p3=0 obj#=82773 tim=1364725159698617 
WAIT #4: nam='db file parallel read' ela= 2716 files=1 blocks=13 requests=13 obj#=82773 tim=1364725159701431 
WAIT #4: nam='db file scattered read' ela= 2179 file#=7 block#=374240 blocks=32 obj#=82773 tim=1364725159703739 
WAIT #4: nam='SQL*Net message to client' ela= 5 driver id=1650815232 #bytes=1 p3=0 obj#=82773 tim=1364725159704315 
WAIT #4: nam='SQL*Net more data to client' ela= 40 driver id=1650815232 #bytes=8278 p3=0 obj#=82773 tim=1364725159704541 
FETCH #4:c=3999,e=5937,p=45,cr=32,cu=0,mis=0,r=15,dep=0,og=1,plh=1087412721,tim=1364725159704589
WAIT #4: nam='SQL*Net message from client' ela= 11759 driver id=1650815232 #bytes=1 p3=0 obj#=82773 tim=1364725159716396 
WAIT #4: nam='db file parallel read' ela= 1999 files=1 blocks=13 requests=13 obj#=82773 tim=1364725159718604 
WAIT #4: nam='db file scattered read' ela= 1667 file#=7 block#=374066 blocks=32 obj#=82773 tim=1364725159720394 
WAIT #4: nam='SQL*Net message to client' ela= 3 driver id=1650815232 #bytes=1 p3=0 obj#=82773 tim=1364725159720497 
WAIT #4: nam='SQL*Net more data to client' ela= 43 driver id=1650815232 #bytes=8278 p3=0 obj#=82773 tim=1364725159720707 
FETCH #4:c=1000,e=4261,p=45,cr=32,cu=0,mis=0,r=15,dep=0,og=1,plh=1087412721,tim=1364725159720752
WAIT #4: nam='SQL*Net message from client' ela= 6700 driver id=1650815232 #bytes=1 p3=0 obj#=82773 tim=1364725159727511 
WAIT #4: nam='db file parallel read' ela= 5874 files=1 blocks=14 requests=14 obj#=82773 tim=1364725159733551 
WAIT #4: nam='db file sequential read' ela= 337 file#=7 block#=374065 blocks=1 obj#=82773 tim=1364725159733959 
WAIT #4: nam='SQL*Net message to client' ela= 4 driver id=1650815232 #bytes=1 p3=0 obj#=82773 tim=1364725159734041 
WAIT #4: nam='SQL*Net more data to client' ela= 77 driver id=1650815232 #bytes=8278 p3=0 obj#=82773 tim=1364725159734271 
...以下略...


db file * read待機イベントとアクセスブロック数及び参照オブジェクトとオブジェクト名を見やすくすると以下のようになります。
db_file_multiblock_read_count=32なのでscatterd readのblocksは理解できるのですが、parallel readのblocksってどこで制御してるんだ..わからんw..というか調べきれてない..

db file scattered read  blocks=32 (INDEX:PK_HIGH_CLUSTERING_FACTOR)
db file scattered read blocks=32 (INDEX:PK_HIGH_CLUSTERING_FACTOR)
db file scattered read blocks=32 (TABLE:HIGH_CLUSTERING_FACTOR)
db file scattered read blocks=32 (INDEX:PK_LOW_CLUSTERING_FACTOR)
db file scattered read blocks=32 (TABLE:LOW_CLUSTERING_FACTOR)
db file parallel read blocks=14 (TABLE:HIGH_CLUSTERING_FACTOR)
db file scattered read blocks=29 (TABLE:HIGH_CLUSTERING_FACTOR)
db file parallel read blocks=12 (TABLE:HIGH_CLUSTERING_FACTOR)
db file scattered read blocks=32 (TABLE:HIGH_CLUSTERING_FACTOR)
db file parallel read blocks=13 (TABLE:HIGH_CLUSTERING_FACTOR)
db file scattered read blocks=32 (TABLE:HIGH_CLUSTERING_FACTOR)
db file parallel read blocks=13 (TABLE:HIGH_CLUSTERING_FACTOR)
db file scattered read blocks=32 (TABLE:HIGH_CLUSTERING_FACTOR)
db file parallel read blocks=14 (TABLE:HIGH_CLUSTERING_FACTOR)
db file sequential read blocks=1 (TABLE:HIGH_CLUSTERING_FACTOR)

発生しているdb file * read待機イベントでアクセスしているオブジェクトは以下の通り。
実行計画上 index unique/range scan なのですが、索引でもscatterd readが発生することがあるんですよ〜っ。

db file parallel read
- obj# = 82773 - HIGH_CLUSTERING_FACTOR(表)

db file scattered read
- obj# = 82771 - LOW_CLUSTERING_FACTOR(表)
- obj# = 82772 - PK_LOW_CLUSTERING_FACTOR(索引)
- obj# = 82773 - HIGH_CLUSTERING_FACTOR(表)
- obj# = 82774 - PK_HIGH_CLUSTERING_FACTOR(索引)

db file sequential read
- obj# = 82771 - LOW_CLUSTERING_FACTOR(表)
- obj# = 82773 - HIGH_CLUSTERING_FACTOR(表)


2つ目のクエリは db file parallel readが発生しないだけで傾向は同じです。 :)

次回へつづく。


バックナンバー

db file scattered read と db file parallel read と db file sequential read (その1)
db file scattered read と db file parallel read と db file sequential read (その2)

| | コメント (0) | トラックバック (0)

2013年4月 1日 (月)

db file scattered read と db file parallel read と db file sequential read (その2)

答え分かりましたかねぇ?

環境情報など再現方法などは次回にしますが、どうなるかやってみましょう。(事前にSQLトレースを有効にしてあります。)


※各SQLはヒントで実行計画を固定してあります。
最初は参考資料3の実行計画になるクエリから実行します。

-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2501 | 1494K| 5012 (1)| 00:01:01 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 2501 | 1494K| 5012 (1)| 00:01:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| HIGH_CLUSTERING_FACTOR | 2502 | 747K| 2510 (1)| 00:00:31 |
|* 4 | INDEX RANGE SCAN | PK_HIGH_CLUSTERING_FACTOR | 2502 | | 8 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_LOW_CLUSTERING_FACTOR | 1 | | 0 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID | LOW_CLUSTERING_FACTOR | 1 | 306 | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------

SELECT
/*+
leading(t2 t1)
use_nl(t2 t1)
index(t2 pk_high_clustering_factor)
*/
t2.id
,t2.name
,t1.name
FROM
low_clustering_factor t1
INNER JOIN high_clustering_factor t2
ON
t1.id = t2.id
WHERE
t2.id BETWEEN 30001 AND 35000
/

次は参考資料2の実行計画になるクエリを実行します。

-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2500 | 1494K| 5231 (1)| 00:01:03 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 2500 | 1494K| 5231 (1)| 00:01:03 |
| 3 | TABLE ACCESS BY INDEX ROWID| LOW_CLUSTERING_FACTOR | 5000 | 1494K| 229 (0)| 00:00:03 |
|* 4 | INDEX RANGE SCAN | PK_LOW_CLUSTERING_FACTOR | 5000 | | 11 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_HIGH_CLUSTERING_FACTOR | 1 | | 0 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID | HIGH_CLUSTERING_FACTOR | 1 | 306 | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------

SELECT
/*+
leading(t1 t2)
use_nl(t1 t2)
index(t1 pk_low_clustering_factor)
*/
t1.id
,t1.name
,t2.name
FROM
low_clustering_factor t1
INNER JOIN high_clustering_factor t2
ON
t1.id = t2.id
WHERE
t1.id BETWEEM 1 AND 5000
/

どのような待機イベントが発生しているかSQLトレース結果(tkprofで整形済み)を見てみると...

最初のクエリのトレース結果

call     count       cpu    elapsed       disk      query    current        rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 163 0.30 1.06 2841 5252 0 2421
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 165 0.30 1.06 2841 5252 0 2421

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 84

Rows Row Source Operation
------- ---------------------------------------------------
2421 NESTED LOOPS (cr=5252 pr=2841 pw=0 time=2771706 us)
2421 NESTED LOOPS (cr=2831 pr=2522 pw=0 time=4204941 us cost=5012 size=1530612 card=2501)
2421 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2589 pr=2458 pw=0 time=4188001 us cost=2510 size=765612 card=2502)
2421 INDEX RANGE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=168 pr=121 pw=0 time=7663 us cost=8 size=0 card=2502)(object id 82774)
2421 INDEX UNIQUE SCAN PK_LOW_CLUSTERING_FACTOR (cr=242 pr=64 pw=0 time=0 us cost=0 size=0 card=1)(object id 82772)
2421 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=2421 pr=319 pw=0 time=0 us cost=1 size=306 card=1)


Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 163 0.00 0.00
db file scattered read 107 0.01 0.30
SQL*Net message from client 163 0.96 3.36
db file parallel read 161 0.01 0.63
SQL*Net more data to client 161 0.00 0.00
db file sequential read 14 0.00 0.00

2つ目のクエリのトレース結果

call     count       cpu    elapsed       disk      query    current        rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 173 0.28 0.72 1874 3367 0 2566
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 175 0.28 0.73 1874 3367 0 2566

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 84

Rows Row Source Operation
------- ---------------------------------------------------
2566 NESTED LOOPS (cr=3367 pr=1874 pw=0 time=802588 us)
2566 NESTED LOOPS (cr=801 pr=381 pw=0 time=115791 us cost=5231 size=1530000 card=2500)
5000 TABLE ACCESS BY INDEX ROWID LOW_CLUSTERING_FACTOR (cr=564 pr=286 pw=0 time=42241 us cost=229 size=1530000 card=5000)
5000 INDEX RANGE SCAN PK_LOW_CLUSTERING_FACTOR (cr=181 pr=32 pw=0 time=26744 us cost=11 size=0 card=5000)(object id 82772)
2566 INDEX UNIQUE SCAN PK_HIGH_CLUSTERING_FACTOR (cr=237 pr=95 pw=0 time=0 us cost=0 size=0 card=1)(object id 82774)
2566 TABLE ACCESS BY INDEX ROWID HIGH_CLUSTERING_FACTOR (cr=2566 pr=1493 pw=0 time=0 us cost=1 size=306 card=1)


Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 173 0.00 0.00
db file scattered read 381 0.01 0.42
db file sequential read 287 0.00 0.14
SQL*Net message from client 172 0.04 2.83
SQL*Net more data to client 171 0.00 0.00


ということで、

A) db file scattered read
B) db file parallel read
C) db file sequential read

A)、B)、C)すべての待機イベント発生しました!!! :)  

実に興味深い。。。。 実行計画見てても、分からないですよね、こればかりは。


次回へ続く。




バックナンバー
db file scattered read と db file parallel read と db file sequential read (その1)

| | コメント (0) | トラックバック (0)

2013年3月30日 (土)

db file scattered read と db file parallel read と db file sequential read (その1)

突然ですが、問題です!

・Oracle11g R2です。(隠しパラメータは変更していません)
・Oracleインスタンスは起動したばかりです。
・参考資料1)のような索引が、それぞれの表に作成されています。
・駆動表は入れ替わっていますが、参考資料2)と3)のような実行計画で2つのSQL文が実行されました。

発生する待機イベントはどれでしょうか?

A) db file scattered read
B) db file parallel read
C) db file sequential read

参考資料1)

TABLE_NAME                     INDEX_NAME                       NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
------------------------------ ------------------------------ ---------- ------------- -----------------
HIGH_CLUSTERING_FACTOR PK_HIGH_CLUSTERING_FACTOR 100000 100000 99978
LOW_CLUSTERING_FACTOR PK_LOW_CLUSTERING_FACTOR 100000 100000 4348

参考資料2)

-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2500 | 1494K| 5231 (1)| 00:01:03 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 2500 | 1494K| 5231 (1)| 00:01:03 |
| 3 | TABLE ACCESS BY INDEX ROWID| LOW_CLUSTERING_FACTOR | 5000 | 1494K| 229 (0)| 00:00:03 |
|* 4 | INDEX RANGE SCAN | PK_LOW_CLUSTERING_FACTOR | 5000 | | 11 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_HIGH_CLUSTERING_FACTOR | 1 | | 0 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID | HIGH_CLUSTERING_FACTOR | 1 | 306 | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------

参考資料3)

-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2501 | 1494K| 5012 (1)| 00:01:01 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 2501 | 1494K| 5012 (1)| 00:01:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| HIGH_CLUSTERING_FACTOR | 2502 | 747K| 2510 (1)| 00:00:31 |
|* 4 | INDEX RANGE SCAN | PK_HIGH_CLUSTERING_FACTOR | 2502 | | 8 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_LOW_CLUSTERING_FACTOR | 1 | | 0 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID | LOW_CLUSTERING_FACTOR | 1 | 306 | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------

次回へつづく.... :) Enjoy!

| | コメント (0) | トラックバック (0)

2013年2月 3日 (日)

Instant Client v11.2.0.3.0 for Mac OS X (Intel x86) のセットアップ

ディレクトリ掘るのめんどくさいんで、Instant Client 10g for MacOS Xの時と同じくすべて同一フォルダに解凍しちゃってますが....。(^^;;;

....動作確認... :)
20130203_60648


そういえば、Instant ClientのREADME.txtには、Darwin 13.0の文字がありますな。

System name:	Darwin
Release: 11.3.0
Version: Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64
Machine: x86_64

| | コメント (0) | トラックバック (0)

2012年11月14日 (水)

Oracle 11g R2の日本語マニュアルがePub/Mobipocketで提供されてた :)

Oracle 11g R2の日本語マニュアルもePub/Mobipocketで提供されたようなので(一部英語のまま)さっそく..

http://docs.oracle.com/cd/E16338_01/ebooklist/ebooklist.html

20121114_230709


20121114_230450

ということで、Oracle11g R2 日本語マニュアルの棚ができあがり :) on iPad

Photo


| | コメント (0) | トラックバック (0)

2012年1月30日 (月)

AWRレポート、AWR SQLレポート一括取得スクリプトを作ったよ。

Statspackレポートもそうなのですが、AWRレポート/AWR SQLレポートも個別に取得していると凄ーく辛いんですよね。一日分出力するとか、AWRレポートで処理時間の長いSQL文のAWR SQLレポートを個別に取得しようとなると...

ただでさえ忙しいのに、AWRレポート取得するのに時間掛けたくないですよね。

ということで、やっつけで作ったのですが、そのまま載せるのもあれなんで、やっつけで作った感じを多少減らしてgithubに公開しました。;)

https://github.com/discus/Oracle-AWR-batch-generation-script/blob/master/awrreport_batch.sql


もっといい感じに改造してくれるといいな〜とかとか... :)

Oracle11g R1/R2 Enterprise Edition、HTML形式で出力します。(RAC環境では試してないので多分だめかと。)。
AWRを利用するには追加ライセンスが必要なのでご注意を


使い方は・・

SQL*plusを起動し、select any dictionaryシステム権限、dbms_repositoryパッケージの実行権限が付与されたユーザで接続して実行するだけ。
SYSTEMユーザでやる事が多いけど、所変わればなんとやらなので・・・そこんとこよろしく。(w


一括取得なので実行当日を含めてn日分のAWRレポートを取得し、同時に処理時間の長いTop20のAWR SQLレポートも取得します。
レポートは各スナップショット間(今のところ固定)で取得します。

指定するパラメータは、以下の3つ。

Enter snap_id for starting AWR report generation. [NULL] : 
AWRレポートを取得する最初のSNAP_IDを指定します。 NULLがデフォルトでほとんどの場合デフォルトのままで事足りると思います。


Enter number of days for reporting period. [1] : 

一括取得する日数を指定します。当日を含みます。
当日分のAWRレポートを出力するのであれば、デフォルト値の1のままでOKです。


Enter suffix for AWR reports filename. [NULL] : test

保存するAWRレポートのファイル名に付加するsuffixを指定します。
試験名とか設定するといいですよね。

"test"と指定した場合

awrrpt_nnnn_nnnn_test.htmlや
awrsqrpt_nnnn_nnnn_test_sqlid.html

の形式で保存します。(nnnnはSNAP_ID)


実行例1)当日分の全レポートを取得する例

SYSTEM> 
SYSTEM> !ls -l awr*.sql
-rw-r--r-- 1 oracle oinstall 6065 1月 29 18:23 awrreport_batch.sql

SYSTEM> @awrreport_batch
--
-- Oracle AWR and AWR SQL report batch generation script
--
-- ***** This script always generate html format AWR reports. *****
--
Enter snap_id for starting AWR report generation. [NULL] :
Enter number of days for reporting period. [1] :
Enter suffix for AWR reports filename. [NULL] : test
--
--
--
clear break compute;
repfooter off;
ttitle off;
btitle off;

・・・中略・・・

<p />
<br /><a class="awr" href="#top">Back to Top</a><p />
</body></html>

SYSTEM>


実行例2)当日分かつsnap_id=291以降で一括取得。(事前にsnap_idを調べておいてね)

SYSTEM> 
SYSTEM> @awrreport_batch
--
-- Oracle AWR and AWR SQL report batch generation script
--
-- ***** This script always generate html format AWR reports. *****
--
Enter snap_id for starting AWR report generation. [NULL] : 291
Enter number of days for reporting period. [1] :
Enter suffix for AWR reports filename. [NULL] : test
--
--
--
clear break compute;
repfooter off;
ttitle off;
btitle off;

・・・中略・・・

<p />
<br /><a class="awr" href="#top">Back to Top</a><p />
</body></html>

SYSTEM>
SYSTEM>
SYSTEM> !ls -l *.html
-rw-r--r-- 1 oracle oinstall 379083 1月 29 22:23 awrrpt_291_292_test.html
-rw-r--r-- 1 oracle oinstall 11899 1月 29 22:23 awrsqrpt_291_292_test_0c83z9rqx45hu.html
-rw-r--r-- 1 oracle oinstall 11899 1月 29 22:23 awrsqrpt_291_292_test_0h3mfbzk6uyw0.html
-rw-r--r-- 1 oracle oinstall 11897 1月 29 22:23 awrsqrpt_291_292_test_2p7t0mw7zvu5z.html

・・・中略・・・

-rw-r--r-- 1 oracle oinstall 11899 1月 29 22:23 awrsqrpt_291_292_test_bhtycgwkxhfj9.html
-rw-r--r-- 1 oracle oinstall 11900 1月 29 22:23 awrsqrpt_291_292_test_bpaggvtfkar9k.html
-rw-r--r-- 1 oracle oinstall 11899 1月 29 22:23 awrsqrpt_291_292_test_c50hdbyuwhfn6.html
-rw-r--r-- 1 oracle oinstall 11892 1月 29 22:23 awrsqrpt_291_292_test_g3f3cw3zy5aat.html

SYSTEM>

なお、Oracleインスタンスが再起動された期間でawrrpt.sqlなどを実行すると、レポートが作成できずエラーでSQL*Plusも終了してしまいますが、本スクリプトでは該当部分のレポートはスキップするようにしてあります。:)

Instance     DB Name      Snap Id   Snap Started       Level
------------ ------------ --------- ------------------ -----
lampeye LAMPEYE 274 29 1月 2012 09:33 1
275 29 1月 2012 10:00 1
276 29 1月 2012 10:30 1
277 29 1月 2012 11:00 1
278 29 1月 2012 11:30 1
279 29 1月 2012 12:00 1
280 29 1月 2012 12:30 1
281 29 1月 2012 13:00 1
282 29 1月 2012 13:30 1
283 29 1月 2012 14:00 1
284 29 1月 2012 14:30 1
285 29 1月 2012 15:00 1
286 29 1月 2012 15:30 1
287 29 1月 2012 16:00 1
288 29 1月 2012 16:30 1
289 29 1月 2012 17:00 1
290 29 1月 2012 17:30 1

291 29 1月 2012 18:31 1 ←再起動されてる
292 29 1月 2012 18:34 1

293 29 1月 2012 22:26 1 ←再起動されてる


Enjoy!

| | コメント (0) | トラックバック (0)

2012年1月 6日 (金)

Index Only Access (Index Only Scan) っていいよね(デメリットもあるけどさ) #2

Index Only Accessのいいとこ、紹介しちゃいますの続きです。

前回は、索引しかアクセスしない(Index Only Access)場合と、索引+表データもアクセスしちゃう場合の実行計画上の違いを確認しましたよね。


今回は、Index Only Accessで得られる改善効果の1つであるソート処理の回避について簡単な例で確認してみます。

※VISIBLE/INVISIBLEにしている索引の詳細は前回の記事を参照してくださいね。

Now Playing ♪ - ハイスクールララバイ / イモ欽トリオ - 1981

まず、最初は、悪い子の例から。

索引を全表走査した上で order by seq# でソート処理が実行されます。酷いですね。検索条件列に適切な索引を作れよ〜〜〜っ。という状態ですね。

SQL> alter index tab10_i01 invisible;

索引が変更されました。

SQL> alter index tab10_i02 invisible;

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:04.99

実行計画
----------------------------------------------------------
Plan hash value: 2100371779

----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 10 | 160 | 16788 (1)| 00:03:22 |
| 1 | SORT ORDER BY | | 10 | 160 | 16788 (1)| 00:03:22 |
|* 2 | TABLE ACCESS FULL | TAB10 | 10 | 160 | 16787 (1)| 00:03:22 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - filter("NON_UNIQUE_KEY"='0000000001')


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
61544 consistent gets
61540 physical reads
0 redo size
655 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed

次に、普通の子の例。

検索条件であるnon_unique_keyに定義された索引を使いIndex range scanかつ、seq#をアクセスするために表データをrowidでアクセス。その後にソート処理が行われています。

普通の子らしい、よい実行計画ですね。 :)

SQL> alter index tab10_i01 visible;

索引が変更されました。

SQL> alter index tab10_i02 invisible;

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:00.08

実行計画
----------------------------------------------------------
Plan hash value: 1783972576

------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 10 | 160 | 5 (20)| 00:00:01 |
| 1 | SORT ORDER BY | | 10 | 160 | 5 (20)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| TAB10 | 10 | 160 | 4 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | TAB10_I01 | 10 | | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

3 - access("NON_UNIQUE_KEY"='0000000001')


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
17 physical reads
0 redo size
655 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed

そして、最後は、良い子の登場。

この子、データ量が多くなった場合、ソート処理も足枷になると考えたようで Index only accessを利用したソート処理回避作戦を取ったようです。 
実行計画をみればわかりますが、索引しかアクセスしておらず、SORT ORDER BY というオペレーションも消えています!

検索条件である、non_unique_key列とソート対象のseq#列の2列からなる複合索引を利用するIndex only accessを狙ったようですね。

ただし、これには order by seq# [asc]であるという大前提があります。
order by seq# desc というソートも考慮する必要がある場合には、non_unique_key [asc]とseq# desc とした別の複合索引必要になります。(デメリットといえばデメリットですかね、)

order by seq# descというソート条件が仕様上無い事を事前に確認しておけば、なお完璧ですよね〜。 良い子。流石です。 :)

SQL> alter index tab10_i01 invisible;

索引が変更されました。

SQL> alter index tab10_i02 visible;

索引が変更されました。

SQL> select seq# from tab10 where non_unique_key = '0000000001' order by seq#;

10行が選択されました。

経過: 00:00:00.01

実行計画
----------------------------------------------------------
Plan hash value: 489654843

------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 10 | 160 | 3 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| TAB10_I02 | 10 | 160 | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - access("NON_UNIQUE_KEY"='0000000001')


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
16 physical reads
0 redo size
655 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
10 rows processed


次回へつづく。(他のソート回避の例も紹介しちゃうか、考えちう)


Index Only Access (Index Only Scan) っていいよね(デメリットもあるけどさ) #1

いん!、イン!、Index どっぷり Inde Only Access生活w - Oracle OpenWorld Unconference presented by JPOUG

| | コメント (0) | トラックバック (0)

2012年1月 4日 (水)

Index Only Access (Index Only Scan) っていいよね(デメリットもあるけどさ) #1

さて、OracleさんがAppleさんのOSで楽しいことしてくれないから最近つまんなくなりつつあるので、普通にSQL文のチューニングネタです。


鬼熱かった、鬼熱かった! :: Insight out 2011- DB tech showcaseでもかなり触れていた、Index Only Scan日本ではこの表現が割合的に多いようなのですが、Index Only Accessって言ってましたね、トムカイトさんも。英語では後者のほうが一般的なのかもしれません。ここではIndex Only Accessってことにしておきます。;)


デメリットもあるけど、Index Only Accessのいいとこばかりを中心に、書いちゃうよ〜w


まず、前提から。

TAB10表は以下のように定義してあります。意図的に表データが大きくなるようにしてあります :)

 名前                NULL?    型
------------------ -------- --------------
SEQ# NOT NULL NUMBER
NON_UNIQUE_KEY NOT NULL CHAR(10)
DATA VARCHAR2(500)

また、以下のような索引を事前に索引しているが、PK_TAB10という主キー索引以外はINVISIBLEとして作成してある。
INVISIBLEで作成しておくと、索引は通常通りメンテナンスされるが、オプティマイザは実行計画作成時にINVISIBLEな索引を利用しないというOracle11gから登場した便利な機能

また前述の表には以下のような主キー(PK_TAB10)と非ユニークな索引が2つ作成してあります。(あまり良い例ではないですがご勘弁を)
但し、TAB10_I01、TAB10_I02の2索引は、INVISIBLEで作成してあります。効果確認時など便利ですよね。
(不可視索引の詳細はマニュアル「Oracle Database 管理者ガイド 11gリリース1(11.1)不可視索引の作成」を参照のこと。


INDEX_NAME COLUMN_NAME
------------ -------------------
PK_TAB10 SEQ#

TAB10_I01 NON_UNIQUE_KEY

TAB10_I02 NON_UNIQUE_KEY
SEQ#

検証時の処理時間及び、実行統計は、各クエリを2回実行し2回目の処理時間及び、実行統計を載せてあります。
(2回目の実行前にバッファキャッシュをクリアしてあるので、ソフトパース+キャッシュミスほぼ100%という状況の処理時間及び実行統計情報です。)

テストデータは以下件数で、non_unique_keyは偏りはなく均一に分布させあります。
実際のはなし、均等になることの方が稀ではあると思いますけど、Index Only Accessの効果を見る事ができればそれでOKなので。

COUNT(1)
----------
800000


COUNT(DISTINCTNON_UNIQUE_KEY)
-----------------------------
80000


NON_UNIQUE COUNT(1)
---------- ----------
0000000001 10
0000000002 10
0000000003 10
0000000004 10
0000000005 10
0000000006 10
0000000007 10
0000000008 10
0000000009 10
0000000010 10
0000000011 10
0000000012 10
0000000013 10
0000000014 10
0000000015 10
0000000016 10
0000000017 10
0000000018 10
0000000019 10
0000000020 10

・・・以下略・・・

まず最初は一番分かりやすい、Index Only Accessの例から。

non_unique_key列に、TAB10_I01という非ユニーク索引を作成してありますが、現状、INVISIBLE状態にしてあるため索引が無く全表走査となっていますよね。

SQL> set autot trace exp stat
SQL>
SQL> select count(non_unique_key) from tab10 where non_unique_key between '0000000001' and '0000000010';

経過: 00:00:04.32

実行計画
----------------------------------------------------------
Plan hash value: 1584905094

----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 11 | 16787 (1)| 00:03:22 |
| 1 | SORT AGGREGATE | | 1 | 11 | | |
|* 2 | TABLE ACCESS FULL| TAB10 | 100 | 1100 | 16787 (1)| 00:03:22 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - filter("NON_UNIQUE_KEY"<='0000000010' AND
"NON_UNIQUE_KEY">='0000000001')


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
61544 consistent gets
61539 physical reads
0 redo size
562 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

ここで、TAB10_I01索引をVISIBLEへ変更して同一クエリを実行してみると……
TAB10_I01索引を利用した実行計画はIndex Range Scanに変化します。しかも、表データはアクセスしていません。これがIndex Only Accessの典型的な例です。アクセスブロック数も処理時間も大きく改善していますよね。

ただ、Index only scanにはデメリットもあります。

それは、索引が多くなればなるほどDML文には足枷になり遅くなるため点です。参照と更新、挿入、削除のバランスを取るのが大切ですが、
とにかく参照を速くする、更新、挿入、削除の処理性能などは少々犠牲にしても問題ないのであれば、どんどんやっちゃいます!(ご利用は計画的にw)

SQL> alter index tab10_i01 visible;
SQL>
SQL> select count(non_unique_key) from tab10 where non_unique_key between '0000000001' and '0000000010';

経過: 00:00:00.02

実行計画
----------------------------------------------------------
Plan hash value: 3770330610

-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 11 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 11 | | |
|* 2 | INDEX RANGE SCAN| TAB10_I01 | 100 | 1100 | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("NON_UNIQUE_KEY">='0000000001' AND
"NON_UNIQUE_KEY"<='0000000010')


統計
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
3 physical reads
0 redo size
562 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

ちなみに、クエリは少々違うのですが、Index only accessで無い場合は、index range scan+table access by index rowidとなり以下のような実行計画になっちゃいます。
(こちらの方がよく目にする実行計画じゃないでしょうかね。私も性能的な問題等なければ以下のような実行計画であれば良しとしておくことが多いのも事実です。。)

実行計画
----------------------------------------------------------
Plan hash value: 1097902029

------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 100 | 51700 | 11 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID | TAB10 | 100 | 51700 | 11 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TAB10_I02 | 100 | | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------------------

次回へつづく。(忙しくてなかなか書けないかもw)

| | コメント (0) | トラックバック (0)

2011年2月17日 (木)

shutdown immeidateしない、ほかの理由に遭遇! おまけのおまけ(でた〜最近、よくあるパターンw)

さて、前回のおまけで終了〜。 のつもりだったがリスナー経由の時は問題ないな〜と気づいて気が変わり。おまけのおまけとなりましたw


前回まではBEQで繋いでたな〜、と思ってリスナー経由の専用サーバー接続で同じことを試してみたらshutdown immeidateが待機させられない事に気づいた。

お〜〜〜〜っ。oracleのサーバープロセスがdefunctにならないっつーことは…

ということで、早速試してみた。

※1つめの端末でSQL*Plusを起動してOracleをスタートアップ(なお事前にリスナーは起動済みです)

[oracle@lampeye ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 水 2月 16 23:10:11 2011

Copyright (c) 1982, 2008, Oracle. All rights reserved.

23:10:11 > conn / as sysdba
接続されました。
23:21:54 SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 1603411968 bytes
Fixed Size 2160112 bytes
Variable Size 436210192 bytes
Database Buffers 1157627904 bytes
Redo Buffers 7413760 bytes
データベースがマウントされました。
データベースがオープンされました。
23:22:04 SYS>

※2つめの端末でSQL*Plusを起動してリスナー経由(この例では専用サーバー接続)でOracleへ接続後、host command(!)でshellへ入っておく。

[oracle@lampeye ˜]$ 
[oracle@lampeye ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 水 2月 16 23:22:45 2011

Copyright (c) 1982, 2008, Oracle. All rights reserved.

23:22:45 > conn scott/tiger@lampeye
接続されました。
23:22:53 SCOTT> !
[oracle@lampeye ˜]$

※この状態で、プロセスツリーをチェックしてみると…Bequeath Protocol接続の時は、PID=5398の子プロセスとしてOracleのサーバープロセスがforkされていたのに、居ないのよ…

[oracle@lampeye ˜]$ ps -ef | grep gnome-terminal
oracle 4976 1 0 23:08 ? 00:00:01 gnome-terminal
oracle 5440 5031 0 23:23 pts/3 00:00:00 grep gnome-terminal
[oracle@lampeye ˜]$
[oracle@lampeye ˜]$ pstree -p 4976 -ual
gnome-terminal,4976,oracle
├─bash,4982
│ └─sqlplus,5154
│ └─oracle,5376 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
├─bash,5007
│ └─sqlplus,5398
│ └─bash,5413
├─bash,5031
│ └─pstree,5441 -p 4976 -ual
├─bash,5161
├─gnome-pty-helpe,4981
└─{gnome-terminal},4983
[oracle@lampeye ˜]$

※じゃ、どこに行ったのよ…と、調べてみると…リスナー経由だとサーバープロセスの親プロセスはINIT

23:29:17 SYS> select s.username,p.username,p.spid from v$process p join v$session s on p.addr = s.paddr where s.username='SCOTT'

USERNAME USERNAME SPID
------------------------------ --------------- ------------------------
SCOTT oracle 5400

経過: 00:00:00.01
23:29:18 SYS>

[oracle@lampeye ˜]$ ps -f -p 5400
UID PID PPID C STIME TTY TIME CMD
oracle 5400 1 0 23:22 ? 00:00:00 oraclelampeye (LOCAL=NO)
[oracle@lampeye ˜]$

※これならshutdown immeidateは待たされずに実行される!

23:35:22 SYS> 
23:35:22 SYS> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
23:35:33 SYS>

ということは、SQL*PlusからBequeath Protocol接続の場合、host commandでshellへ入ったままにしているとshutdown immeidateが待機させられるのな…


じゃ、sqlnet.ora に BEQUEATH_DETACH=yes を設定すれば回避できそーな気がする
Oracle Database Net Servicesリファレンス 11g リリース1(11.1)- 5.2.1 BEQUEATH_DETACH

早速、検証…

sqlnet.oraにBEQUEATH_DETACH=yesを追記。

[oracle@lampeye ˜]$ 
[oracle@lampeye ˜]$ cat $ORACLE_HOME/network/admin/sqlnet.ora
# sqlnet.ora Network Configuration File: /opt/u01/app/oracle/product/11.1.0/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
BEQUEATH_DETACH=yes

[oracle@lampeye ˜]$

※1つめの端末でSQL*Plusを起動し、Oracleをstartup…

[oracle@lampeye ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 水 2月 16 23:39:14 2011

Copyright (c) 1982, 2008, Oracle. All rights reserved.

23:39:14 > conn / as sysdba
アイドル・インスタンスに接続しました。
23:39:17 SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 1603411968 bytes
Fixed Size 2160112 bytes
Variable Size 436210192 bytes
Database Buffers 1157627904 bytes
Redo Buffers 7413760 bytes
データベースがマウントされました。
データベースがオープンされました。
23:39:26 SYS>


※2つめの端末でSQL*Plusを起動、BEQ接続でSCOTTユーザへ接続後、host command(!)でshellへ入っておく…

[oracle@lampeye ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 水 2月 16 23:39:39 2011

Copyright (c) 1982, 2008, Oracle. All rights reserved.

23:39:39 > conn scott/tiger
接続されました。
23:39:45 SCOTT> !
[oracle@lampeye ˜]$


※この状態でプロセスツリーを見てみると…お〜〜〜、SQL*Plusの子プロセスではなくなっている…

[oracle@lampeye ˜]$ pstree -p 4976 -ual 
gnome-terminal,4976,oracle
├─bash,4982
│ └─sqlplus,5596
├─bash,5007
│ └─sqlplus,5664
│ └─bash,5686
├─bash,5031
│ └─pstree,5711 -p 4976 -ual
├─bash,5161
├─gnome-pty-helpe,4981
└─{gnome-terminal},4983
[oracle@lampeye ˜]$

※じゃ〜、どこの子になっちゃったのか調べてみましょう…

23:41:08 SYS> select s.username,p.username,p.spid from v$process p join v$session s on p.addr = s.paddr where s.username IN ('SYS','SCOTT');

USERNAME USERNAME SPID
------------------------------ --------------- ------------------------
SYS oracle 5685
SCOTT oracle 5666

経過: 00:00:00.03
23:41:40 SYS>

お〜、やはり、SQL*Plusの子じゃなくて、INITの養子となってしまったようですw

[oracle@lampeye ˜]$ ps -f -p 5685 5666
UID PID PPID C STIME TTY STAT TIME CMD
oracle 5666 1 0 23:39 ? Ss 0:00 oraclelampeye (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle 5685 1 0 23:40 ? Ss 0:00 oraclelampeye (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
[oracle@lampeye ˜]$

これなら、shutdown immeidateも待たされないでしょうね :)

23:42:52 SYS> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
23:43:07 SYS>

immeidateしない、ほかの理由に遭遇! ネタはこれで、ほんとにほんとのおしまい :)


shutdown immeidateしない、ほかの理由に遭遇!
shutdown immeidateしない、ほかの理由に遭遇! #2
shutdown immeidateしない、ほかの理由に遭遇! #3
shutdown immeidateしない、ほかの理由に遭遇! おまけ

| | コメント (0) | トラックバック (0)

2011年2月10日 (木)

shutdown immeidateしない、ほかの理由に遭遇! おまけ

前回までで状況も把握できたし、そうなった場合の回避策も見えたのですが、子プロセスの生成とかdefunctなゾンピ君の刈り取りってどーなってんだろーと気になり…

子プロセスの生成状況を以下の順で見てみる…

  1. shellに入っただけ
  2. SQL*Plus起動
  3. SCOTTユーザへ接続
  4. host command(!)でshellへ入る


shellに入っただけ

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ ps -e -u oracle | grep gnome-terminal
3337 ? 00:00:09 gnome-terminal
[oracle@pleco ˜]$
[oracle@pleco ˜]$ pstree -p 3337 -u
gnome-terminal(3337,oracle)─┬─bash(3377)
├─bash(3737)───pstree(4063)
├─gnome-pty-helpe(3342)
└─{gnome-terminal}(3344)


SQL*Plus起動

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$
[oracle@pleco ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 木 2月 10 14:54:44 2011

Copyright (c) 1982, 2008, Oracle. All rights reserved.

14:54:44 >

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ pstree -p 3337 -u
gnome-terminal(3337,oracle)─┬─bash(3377)───sqlplus(4064)
├─bash(3737)───pstree(4066)
├─gnome-pty-helpe(3342)
└─{gnome-terminal}(3344)


SCOTTユーザへ接続

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$
[oracle@pleco ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 木 2月 10 14:54:44 2011

Copyright (c) 1982, 2008, Oracle. All rights reserved.

14:54:44 > conn scott/tiger
接続されました。
14:54:57 SCOTT>

scottユーザに接続した状態…
このようにSQL*Plusの子プロセスが1つであればshutdown immeidateが待機させられることはないんだけど…ね。
[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ pstree -p 3337 -u
gnome-terminal(3337,oracle)─┬─bash(3377)───sqlplus(4064)───oracle(4067)
├─bash(3737)───pstree(4068)
├─gnome-pty-helpe(3342)
└─{gnome-terminal}(3344)


host command(!)でshellに入った

[oracle@pleco ˜]$ 
[oracle@pleco ˜]$
[oracle@pleco ˜]$ sqlplus /nolog

SQL*Plus: Release 11.1.0.7.0 - Production on 木 2月 10 14:54:44 2011

Copyright (c) 1982, 2008, Oracle. All rights reserved.

14:54:44 > conn scott/tiger
接続されました。
14:54:57 SCOTT> !
[oracle@pleco ˜]$

SQL*Plusからホストコマンド(!)でshellに入った状態…
SQL*Plusの子プロセスが複数でoracle以外のがある状態で、他のSQL*Plusからshutdown immediateを実行されちゃうと、以下にあるpid=4067が<defunct>状態のまま刈り取られない。===>Oracleがshutdown immeidateで停止しない。ってことになるのな。
[oracle@pleco ˜]$ 
[oracle@pleco ˜]$ pstree -p 3337 -u
gnome-terminal(3337,oracle)─┬─bash(3377)───sqlplus(4064)─┬─bash(4069)
└─oracle(4067)
├─bash(3737)───pstree(4093)
├─gnome-pty-helpe(3342)
└─{gnome-terminal}(3344)
[oracle@pleco ˜]$
[oracle@pleco ˜]$

じゃ、実験!

以下のようにshutdown immeidateが待機させられている状態を作る。赤字(pid=3627)の子プロセスがdefunctつまりゾンビになるわけね。

shutdown immeidateを実行するSQL*Plusとは別にSQL*Plusを起動し、host command(!)でshellに入っておきます…

16:09:28 > conn scott/tiger
接続されました。
16:12:45 SCOTT> !
[oracle@pleco ˜]$

[oracle@pleco ˜]$ pstree -p 3372 -u
gnome-terminal(3372,oracle)─┬─bash(3378)───sqlplus(3493)─┬─bash(3628)
└─oracle(3627)
├─bash(3403)───sqlplus(3427)───oracle(3599)
├─bash(3520)───pstree(3672)
├─gnome-pty-helpe(3377)
└─{gnome-terminal}(3379)

この状態で、もう一つのSQL*Plusからsysユーザでshutdown immeidateを実行します…shutdown immeidateは待機させられます。
この時、pid=3627の子プロセスはdefunct状態になってますが、刈り取られていません。この影響でshutdown immediateが待機させられています。
SQL*Plusからshellに入っていない場合、つまり、SQL*Plusのプロセス(pid=3493)の子プロセスが1つしかない場合は、shutdown immeidateが待機させられることはない…この辺りに問題がありそうな気がします…

16:12:59 SYS> 
16:12:59 SYS>
16:13:00 SYS> shutdown immediate

[oracle@pleco ˜]$ pstree -p 3372 -u
gnome-terminal(3372,oracle)─┬─bash(3378)───sqlplus(3493)─┬─bash(3628)
└─oracle(3627)
├─bash(3403)───sqlplus(3427)───oracle(3599)
├─bash(3520)───pstree(3672)
├─gnome-pty-helpe(3377)
└─{gnome-terminal}(3379)

試しに親プロセスであるSQL*Plus(pid=3493)にSIGCHLDシグナルを送ってみましょう。
[oracle@pleco ˜]$ kill -SIGCHLD 3493
[oracle@pleco ˜]$ kill -SIGCHLD 3493
[oracle@pleco ˜]$ kill -SIGCHLD 3493
[oracle@pleco ˜]$ kill -SIGCHLD 3493
[oracle@pleco ˜]$ kill -SIGCHLD 3493
・・・・以下略w・・・・

ん〜〜〜〜〜。ゾンビを刈り取ってくれません><

試しにshellからexitしてみます…

16:09:28 > conn scott/tiger
接続されました。
16:12:45 SCOTT> !
[oracle@pleco ˜]$ exit
exit

16:18:24 SCOTT>
[oracle@pleco ˜]$ pstree -p 3372 -u
gnome-terminal(3372,oracle)─┬─bash(3378)───sqlplus(3493)───oracle(3627)
├─bash(3403)───sqlplus(3427)───oracle(3599)
├─bash(3520)───pstree(3673)
├─gnome-pty-helpe(3377)
└─{gnome-terminal}(3379)

shellからはexitしました。SQL*Plus(pid=3493)の子プロセスがoracleだけ(pid=3627)のゾンビだけになりました。oracleのゾンビ(pid=3627)が残っているうちはshutdown immeidateは待機させられたままです! 

では、もう一回、親プロセスであるSQL*PlusにSIGCHLDシグナルを送ってみましょう! 今度はうまく行きそうな気がします!

[oracle@pleco ˜]$ kill -SIGCHLD 3493
[oracle@pleco ˜]$ pstree -p 3372 -u
gnome-terminal(3372,oracle)─┬─bash(3378)───sqlplus(3493)
├─bash(3403)───sqlplus(3427)───oracle(3599)
├─bash(3520)───pstree(3675)
├─gnome-pty-helpe(3377)
└─{gnome-terminal}(3379)
[oracle@pleco ˜]$

やった〜〜〜〜〜〜 :) SQL*Plus(pid=3493)の子プロセス(pid=3627)のゾンビが見事に刈り取られました!

その瞬間……待機させられていたshutdown immeidateは見事終了!!!!

16:12:59 SYS> 
16:12:59 SYS>
16:13:00 SYS> shutdown immediate
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
16:18:42 SYS>


shutdown immeidateしない、ほかの理由に遭遇! ネタはこれにて :)




shutdown immeidateしない、ほかの理由に遭遇!
shutdown immeidateしない、ほかの理由に遭遇! #2
shutdown immeidateしない、ほかの理由に遭遇! #3
shutdown immeidateしない、ほかの理由に遭遇! おまけ

| | コメント (0) | トラックバック (0)

2011年2月 9日 (水)

shutdown immeidateしない、ほかの理由に遭遇! #3

もう一つ検証し忘れてた!。

この現象に気づいたとき、SQL*Plusから接続していたユーザがsysユーザや、systemユーザだけだったので、それ以外のユーザで接続している場合は大丈夫なんじゃね?都市伝説の検証…

これまでと同様に2つのSQL*Plusを起動しておきます。

1つめのSQL*Plusでは、sysユーザに接続しておきます…

[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 水 2月 9 07:26:10 2011

Copyright (c) 1982, 2009, Oracle. All rights reserved.

07:26:10 > conn / as sysdba
接続されました。


2つめのSQL*Plusでは、scottユーザ(sysユーザ、systemユーザ以外の一般ユーザ)に接続し、host command(!)でshellに入ったままにしておきます…

[oracle@leaffish ˜]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on 水 2月 9 07:26:23 2011

Copyright (c) 1982, 2009, Oracle. All rights reserved.

07:26:23 > conn scott/tiger
接続されました。
07:26:29 SCOTT> !
[oracle@leaffish ˜]$


では、sysユーザでshutdown immeidateを実行してみます…

07:26:10 > conn / as sysdba
接続されました。
07:26:16 SYS>
07:26:16 SYS>
07:26:17 SYS> shutdown immediate

お〜〜〜、shutdown immeidateが待機させられています。

「SQL*Plusから接続していたユーザがsysユーザや、systemユーザだけだったので、それ以外のユーザで接続している場合は大丈夫なんじゃね?都市伝説」は都市伝説
Oracleへ接続するユーザに関係なく、SQL*Plusからhost command(!)でshellに入ったままのセッションがある状態で他のセッションからshutdown immeidateを実行した場合、shutdown immeidateは、shutdown timeoutせずにshutdownを待機し続けるのは事実。

まとめると…

現象:

  • shutdown immeidate文を実行したがshutdown timeout(1時間)も発生せずshutdownが待機させれれたままになり停止できない。


発生条件(Updated 16-Feb-2011):

  • Linux/Unix系のOracle11g R2 11.2.0.1.0 (ちなみにそれ以外のリリースでは11.1.0.7.0で同様の現象を確認しています、他のリリースでは未検証。)
  • shutdown immeidateを発行するセッション以外に、SQL*Plusからhost command(! はたま host)でshellに入ったままになっているセッションがある場合。かつ、Bequeath ProtocolでOracleへ接続している。


確認ポイント:

  • アラートログに "SHUTDOWN: Active processes prevent shutdown operation"が繰り返される。
  • ps -ef | grep ora などでプロセスをみると <defunct>な子プロセスがあり、親プロセスがSQL*Plusである。
  • ls -lrt で最後にリストされるトレースファイル(shutdownを実行しているプロセスのトレースファイル)に"ksukia: Attempt <連番?> to re-kill process OS PID=<pid>"のメッセージが繰り返し出力され続ける


対処(Updated 16-Feb-2011):

  • shutdown aboartするしかない。<defunct>なプロセスの親であるSQL*Plusのプロセスをkill -SIGTERMとか-SIGKILLで終了させる。それでもshutdownが待機しているようなら、最後の手段、shutdown abortということで。
    SQL*Plus起動してる人が連絡取れる場所にいるのならその方にexitしてもらうのもありw
  • その他の方法として、sqlnet.oraに、BEQUEATH_DETACH=yes を設定して、サーバープロセスをSQL*Plusの子ではなく、INITの子になってもらう(これがおすすめかも)


現象と回避方法を確認したリリース(Updated 16-Feb-2011):

  • Oracle11g R1 11.1.0.7.0 for Linux (32bit/64bit)
  • Oracle11g R1 11.1.0.7.0 for HP-UX(itanium)
  • Oracle11g R2 11.2.0.1.0 for Linux (32bit/64bit)
  • Oracle11g R2 11.2.0.1.0 for Solaris x86-64

KROWNっぽいまとめ方にしてみました :) (他のUnix系リリースでも作りはおなじでしょうね)

でもさあ、SQL*Plusからホストコマンド、使うんだよね結構。shellに入って、SQL*Plusから入っていたこと忘れて、また、SQL*Plus起動しちゃって…さらにshellに入って…以下繰り返しw。 注意しましょうね。→ 自分。




shutdown immeidateしない、ほかの理由に遭遇!
shutdown immeidateしない、ほかの理由に遭遇! #2
shutdown immeidateしない、ほかの理由に遭遇! #3
shutdown immeidateしない、ほかの理由に遭遇! おまけ

| | コメント (0) | トラックバック (0)

2010年9月23日 (木)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

前回のネタ振りから随分間があいてしまいました。m(_ _)m

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? 」シリーズで_pga_max_sizeが固定値の様に見えてしまっているのですが、そのようになってしまった、"大きなミス"ってどこかわかりますか?

ってところ、わかりますかね。

実は、行く先々で pga_aggregate_targetとか _pga_max_sizeの値を覗いてみてて、あれ、自分のMacやPCで確かめた値と違う???何故ってことが数回あって、あ、そういことかと気付いたわけです。

答えから先に言うと、

Oracle10g R1までは確かに _pga_max_sizeは200MBで固定値だった。ところが、Oracle10g R2以降は、Oracleが内部で動的に変更する隠しパラメータになったということ。

そして、_pga_max_sizeをalter system文で変更してしまうと、Oracle10g R2以降では、その値は動的に変更されず、ユーザが設定した値で固定されてしまう。


ということ。


この影響で、私が実施したテストケースでは全て_pga_max_sizeは200MBのままで固定値のように見えていたということ。。

orz... まあ、隠しパラメータですから、どんな仕様変更があっても文句はいいません。>< はい。


では、早速、alter system文で値を設定してしまった _pga_max_sizeパラメータを元の状態に戻しましょう!

手順としては、Oracleインスタンス起動、spfileからpfileを作り、pfileから_pga_max_sizeの部分を削除、インスタンス停止、pfileでOracleインスタンス起動、spfile作って再起動って感じです。

とりあえず、Oracle10g R1で。

SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Prod
PL/SQL Release 10.1.0.3.0 - Production
CORE 10.1.0.3.0 Production
TNS for MacOS X Server: Version 10.1.0.3.0 - Production
NLSRTL Version 10.1.0.3.0 - Production

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 100M

SYS> @pgastat

NAME size(MB)
------------------------------ ----------
aggregate PGA target parameter 100
aggregate PGA auto target 76.1923828
global memory bound 5

SYS>
SYS> create pfile from spfile;

ファイルが作成されました。

SYS> !cat $ORACLE_HOME/dbs/initxtiger.ora

・・・中略・・・

xtiger.__large_pool_size=4194304
xtiger.__shared_pool_size=104857600
*._pga_max_size=209715200
*.background_dump_dest='/Volumes/Discus/4oracle/oracle/u01/app/oracle/admin/xtiger/bdump'
*.compatible='10.1.0.2.0'

・・・中略・・・

SYS> edit $ORACLE_HOME/dbs/initxtiger.ora



*._pga_max_sizeの行を削除!
SYS> !cat $ORACLE_HOME/dbs/initxtiger.ora

・・・中略・・・

xtiger.__large_pool_size=4194304
xtiger.__shared_pool_size=104857600
*.background_dump_dest='/Volumes/Discus/4oracle/oracle/u01/app/oracle/admin/xtiger/bdump'
*.compatible='10.1.0.2.0'

・・・中略・・・

SYS> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SYS>
SYS> startup pfile=$ORACLE_HOME/dbs/initxtiger.ora
ORACLEインスタンスが起動しました。

Total System Global Area 293601280 bytes
Fixed Size 778888 bytes
Variable Size 120331640 bytes
Database Buffers 171966464 bytes
Redo Buffers 524288 bytes
データベースがマウントされました。
データベースがオープンされました。

SYS> create spfile from pfile;

ファイルが作成されました。

SYS> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。

SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 293601280 bytes
Fixed Size 778888 bytes
Variable Size 120331640 bytes
Database Buffers 171966464 bytes
Redo Buffers 524288 bytes
データベースがマウントされました。
データベースがオープンされました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
pga_aggregate_target big integer 100M

SYS> @pgastat

NAME size(MB)
------------------------------ ----------
aggregate PGA target parameter 100
aggregate PGA auto target 76.3242188
global memory bound 5

SYS> @show_hidden_pga_param

KSPPINM KSPPSTVL KSPPSTDF
------------------------------ ------------------------------ ---------------------------
_pga_large_extent_size 1048576 TRUE
_pga_max_size 209715200 TRUE
_use_ism_for_pga TRUE TRUE
pga_aggregate_target 104857600 FALSE

SYS>


戻った〜。 show parameter pgaで 隠しパラメータである_pga_max_sizeパラメータが表示されているということは、その値がデフォルト値と同じ値であっても、そのパラメータの値は、ユーザがセットした値ということ。show parameterで _pga_max_sizeが表示されなくなったらOK。

ちなみに、 show_hidden_pga_param.sqlは以下のようなクエリ。

select
a.ksppinm
,b.ksppstvl
,b.ksppstdf
from
x$ksppi a join x$ksppcv b
on a.indx = b.indx
where
a.ksppinm like '%pga%'
order by
a.ksppinm
/

次回へつづく。


前回までのあらすじ・・・
Mac De Oracle なんですが、Windows(32bit)でのOracleな話
Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2
Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #10
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #11
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #12
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #13
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #14
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #15
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #16
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #17
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #18
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #19
_pga_max_sizeってOracle11gではどうなったっけ? という確認。
_pga_max_sizeってOracle11gではどうなったっけ? という確認。シーズン2

| | コメント (0) | トラックバック (0)

2010年5月22日 (土)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #19

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その19回目、


そして、あっという間に、Oracle11g R2の自動メモリー管理を無効、自動PGAメモリー管理有効状態での確認も最終回!
前回、_pga_max_sizeの50%になってしまったpga_aggregate_targetを16GB/4095GBに設定した場合のテストを_pga_max_sizeを調整してpga_aggregate_targetの20%が利用される状態にして再び確認して終わりにしたいと思います。

SYS> alter system set "_pga_max_size"=6554m;

システムが変更されました。

SYS> alter system set pga_aggregate_target=16g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 6554M
pga_aggregate_target big integer 16G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 16384
aggregate PGA auto target 14721.3281
global memory bound 3276.7998

SYS> alter system set "_pga_max_size"=1677313m;

システムが変更されました。

SYS> alter system set pga_aggregate_target=4095g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 1677313M
pga_aggregate_target big integer 4095G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4193280
aggregate PGA auto target 3773918.79
global memory bound 838656

SYS>


・・・中略・・・

SCOTT> @test4

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 30000 SORT (v2) 1171.63
0 order by code

SCOTT>

Oracle10g R2以降は32bitでも64bitでも、自動メモリー管理が無効で、自動PGAメモリー管理が有効ならば、かつNon parallelならば、LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)とう条件で作業域を割り当てているのは確からしい。

次回は、ちょっと別の角度から。ということで次回へつづく。


前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #10
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #11
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #12
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #13
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #14
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #15
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #16
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #17
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #18

| | コメント (0) | トラックバック (0)

2010年5月21日 (金)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #18

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その18回目、


Oracle11g R2での検証の続き。まいどおなじみ、_pga_max_sizeを大きな値にして、pga_aggregate_targetの20%がglobal memory boundに設定されるようにして確認。

SYS> alter system set "_pga_max_size"=3840m;

システムが変更されました。

SYS> alter system set pga_aggregate_target=256m;

システムが変更されました。

SYS> alter system flush shared_pool;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 256M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 256
aggregate PGA auto target 206.173828
global memory bound 51.1992188

SYS>
SYS> alter system set pga_aggregate_target=512m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 512M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 512
aggregate PGA auto target 436.869141
global memory bound 102.399414

SYS> alter system set pga_aggregate_target=768m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 768M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 768
aggregate PGA auto target 667.212891
global memory bound 153.599609

SYS>
SYS> alter system set pga_aggregate_target=1g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 1G
SYS> @pgastat


NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 1024
aggregate PGA auto target 897.591797
global memory bound 204.799805

SYS> alter system set pga_aggregate_target=2g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 2G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 2048
aggregate PGA auto target 1820.0127
global memory bound 409.599609

SYS>
SYS> alter system set pga_aggregate_target=4g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 4G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4096
aggregate PGA auto target 3662.25293
global memory bound 819.199219

SYS> alter system set pga_aggregate_target=8g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 8G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 8192
aggregate PGA auto target 7349.43164
global memory bound 1638.39941

やはりここで変化あり!

SYS> 
SYS> alter system set pga_aggregate_target=16g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 16G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 16384
aggregate PGA auto target 14722.1543
global memory bound 1920

SYS> alter system set pga_aggregate_target=4095g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 4095G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4193280
aggregate PGA auto target 3773917.1
global memory bound 1920

SYS>

Oracle11g R1と同じ結果になりましたね。LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5) ということね。Oracle11g R2でも。
次回へつづく。



前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #10
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #11
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #12
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #13
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #14
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #15
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #16
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #17

| | コメント (0) | トラックバック (0)

2010年5月20日 (木)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #17

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その17回目、


Oracle11g R2 自動メモリー管理は無効、自動PGAメモリー管理は有効な状態での検証スタート!

いつものように、_pga_max_sizeはデフォルトの200MBで、pga_aggregate_targetを10MBから4095MBまで増加させてglobal memory boundがどのように変化するか確認します!

SYS> alter system set pga_aggregate_target=10m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 10M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 10
aggregate PGA auto target 4
global memory bound 2

SYS> alter system set pga_aggregate_target=20m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 20M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 20
aggregate PGA auto target 4
global memory bound 4

SYS> alter system set pga_aggregate_target=40m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 40M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 40
aggregate PGA auto target 12.8583984
global memory bound 8

SYS> alter system set pga_aggregate_target=256m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 256M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 256
aggregate PGA auto target 207.263672
global memory bound 51.1992188

SYS> alter system set pga_aggregate_target=512m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 512M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 512
aggregate PGA auto target 436.851563
global memory bound 100

SYS>

お、変化ありました。Oracle11g R2でも自動PGAメモリー管理の動きは同じみたいね。

どんどんやっつけちゃいましょー

SYS> alter system set pga_aggregate_target=768m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 768M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 768
aggregate PGA auto target 667.283203
global memory bound 100

SYS> alter system set pga_aggregate_target=1g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 1G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 1024
aggregate PGA auto target 897.688477
global memory bound 100

SYS> alter system set pga_aggregate_target=2g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 2G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 2048
aggregate PGA auto target 1819.87207
global memory bound 100

SYS> alter system set pga_aggregate_target=4g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 4G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4096
aggregate PGA auto target 3662.25293
global memory bound 100

SYS> alter system set pga_aggregate_target=8g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 8G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 8192
aggregate PGA auto target 7349.43164
global memory bound 100

SYS> alter system set pga_aggregate_target=16g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 16G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 16384
aggregate PGA auto target 14721.3457
global memory bound 100

SYS> alter system set pga_aggregate_target=2095g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 2095G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 2145280
aggregate PGA auto target 1930719.63
global memory bound 100

SYS>


そして、念のため実際にソート! glolbal memory boundに設定されたサイズになってますね〜。

SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2) 100.02 409993216 409993216
0 order by code

SCOTT>


次回へつづく。



前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #10
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #11
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #12
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #13
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #14
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #15
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #16

| | コメント (0) | トラックバック (0)

2010年5月19日 (水)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #16

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その16回目、

今回からOracle11g R2 for Windows 32bit環境での検証です。なお、自動メモリー管理(AMM)はOFFで自動SGAメモリー管理(ASMM)、自動PGAメモリー管理(APMM)は有効になっています。
この状態でOracle11g R1までと動きに違いがないかみてみることにします。

SYS> select * from v$version;

BANNER
----------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

SYS>

ダブルアンダースコアの隠しパラメータがが気味悪いw ですが、たぶん影響しないんじゃないかと。もともとOracle側で制御しているパラメータだし。

SYS> @show_param

KSPPINM KSPPSTVL KSPPSTDF
-------------------------------- -------------------------------- --------------------------------
_4031_sga_dump_interval 3600 TRUE
_4031_sga_max_dumps 10 TRUE
__pga_aggregate_target 79691776 TRUE
__sga_target 239075328 TRUE
_kdli_sio_pga FALSE TRUE
_kdli_sio_pga_top FALSE TRUE
_ldr_pga_lim 0 TRUE
_lock_sga_areas 0 TRUE
_memory_imm_mode_without_autosga TRUE TRUE
_memory_initial_sga_split_perc 60 TRUE
_memory_nocancel_defsgareq FALSE TRUE
_pga_large_extent_size 1048576 TRUE
_pga_max_size 209715200 TRUE
_pgactx_cap_stacks FALSE TRUE
_sga_clear_dump FALSE TRUE
_sga_early_trace 0 TRUE
_sga_locking none TRUE
_use_ism_for_pga TRUE TRUE
lock_sga FALSE TRUE
memory_max_target 0 TRUE
memory_target 0 TRUE
pga_aggregate_target 78643200 FALSE
pre_page_sga FALSE TRUE
sga_max_size 239075328 TRUE
sga_target 239075328 FALSE

25行が選択されました。

SYS>
SYS> show parameter workarea_size_policy

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
workarea_size_policy string AUTO
SYS>


次回へつづく。



前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #10
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #11
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #12
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #13
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #14
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #15

| | コメント (0) | トラックバック (0)

2010年5月18日 (火)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #15

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その15回目、

さて、Oracle11g R1での検証もいよいよ最終回。 
前回、_pga_max_sizeが3840MBで、pga_aggregate_targetを16GB/4095GBとしたところで、_pga_max_sizeの50%がglobal memory boundとして設定されていました。
じゃ、最後の2でもpga_aggregate_targetの20%をglobal memory boundとして利用するようにしちゃえ!

ということで、_pga_max_sizeを6554MB/1677313MB、pga_aggregate_targetを16GB/4096GBとしてギリギリでpga_aggregate_targetの20%が利用されるように設定してみました。
以下の通り、global memory boundは、pga_aggregate_targetの20%である、3276.8MB/838656MBになってます!

SYS> alter system set "_pga_max_size"=6554m;

システムが変更されました。

SYS> alter system set pga_aggregate_target=16g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 6554M
pga_aggregate_target big integer 16G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 16384
aggregate PGA auto target 14720.7744
global memory bound 3276.7998

SYS>


SYS> alter system set "_pga_max_size"=1677313m;

システムが変更されました。

SYS> alter system set pga_aggregate_target=4095g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 1677313M
pga_aggregate_target big integer 4095G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4193280
aggregate PGA auto target 3773917.72
global memory bound 838656

SYS>

最後に、実メモリ768MBしか積んでないマシンなのに無理矢理、1GB越えのPGAを利用してもらっちゃいます。
当然ですが、swapしまくりなので、普通の時間でレスポンスなんて戻ってきませんから真似しないようにw swapを使ってDISKガリガリいってましたがOracle上ではちゃんとOPTIMALとなっておりますはい!。

SCOTT> @test4

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 30000 SORT (v2) 1171.63
0 order by code

SCOTT>


ということで、次回、Oracle11g R2 for Linux x86の自動メモリー管理(AMM)下でどうなるか確認と、思ったのですが、ちょうど Oracle11g R2 for Windows (32bit)がダウンロードできるようになっていたので、急遽、Oracle11g R2 for Windows(32bit)かつ、自動メモリー管理をオフにした状態ではどうなるか確認してみましょう。なを32bitのWindowsなのでSGA/PGA合わせて2GB超えないような範囲で遊びマッス!。

なんか久々に1ヶ月ものぐらいのネタに膨らまそうか考えてたりして・・・・。

次回へつづく。



前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #10
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #11
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #12
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #13
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #14

| | コメント (0) | トラックバック (0)

2010年5月17日 (月)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #14

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

_pag_max_sizeに大きな値を設定し、LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)という条件で割り当てられていることを確認してみます!

SYS> alter system flush shared_pool;

システムが変更されました。

SYS> alter system set "_pga_max_size"=3840m;

システムが変更されました。

SYS> alter system set pga_aggregate_target=256m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 256M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 256
aggregate PGA auto target 205.734375
global memory bound 51.1992188

SYS> alter system set pga_aggregate_target=512m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 512M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 512
aggregate PGA auto target 435.700195
global memory bound 102.399414

SYS> alter system set pga_aggregate_target=768m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 768M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 768
aggregate PGA auto target 666.518555
global memory bound 153.599609

SYS> alter system set pga_aggregate_target=1g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 1G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 1024
aggregate PGA auto target 896.52832
global memory bound 204.799805

SYS> alter system set pga_aggregate_target=2g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 2G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 2048
aggregate PGA auto target 1818.44824
global memory bound 409.599609

SYS> alter system set pga_aggregate_target=4g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 4G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4096
aggregate PGA auto target 3735.43555
global memory bound 819.199219

SYS> alter system set pga_aggregate_target=8g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 8G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 8192
aggregate PGA auto target 7347.50684
global memory bound 1638.39941



まちがいなく、pga_aggregate_targetの20%がglobal memory boundに設定されてます!

さて、pga_aggregate_targetを16GB以上に設定すると、_pga_max_sizeの50%より、pga_aggregate_targetの20%の方が大きくなるため、_pga_max_sizeパラメータの50%のサイズがglobal memory boundに設定されるはず! ではやってみよう!

SYS> alter system set pga_aggregate_target=16g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 16G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 16384
aggregate PGA auto target 15023.2441
global memory bound 1920

SYS> alter system set pga_aggregate_target=4095g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 4095G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4193280
aggregate PGA auto target 3773917.55
global memory bound 1920

SYS>

予想通り、_pga_max_sizeの50%がglobal memory boundに設定されてますね。
Oracle11g R1での検証もいよいよ次回が最終回。ということで、次回へつづく。



前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #10
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #11
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #12
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #13

| | コメント (0) | トラックバック (0)

2010年5月16日 (日)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #13

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その13回目、

_pga_max_sizeはデフォルトのままで、pga_aggregate_targetを増加させていくと、Oracle10g R2と同様に、LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)という条件で割り当てられてるようだ。ということでその確認のつづき。

pga_aggregate_targetが512MBになったところで、_pga_max_sizeの200MBの50%のサイズがglobal memory boundとして設定されるようになった。さらに増加させてその割合に変化がないか確認していく。

SYS> alter system set pga_aggregate_target=768m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 768M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 768
aggregate PGA auto target 666.720703
global memory bound 100

SYS> alter system set pga_aggregate_target=1g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 1G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 1024
aggregate PGA auto target 896.677734
global memory bound 100

SYS> alter system set pga_aggregate_target=2g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 2G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 2048
aggregate PGA auto target 1818.26367
global memory bound 100

SYS> alter system set pga_aggregate_target=4g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 4G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4096
aggregate PGA auto target 3661.89258
global memory bound 100

SYS> alter system set pga_aggregate_target=8g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 8G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 8192
aggregate PGA auto target 7348.25391
global memory bound 100

SYS> alter system set pga_aggregate_target=16g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 16G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 16384
aggregate PGA auto target 14720.5371
global memory bound 100

pga_aggregate_targetを16GBにしても、_pga_max_sizeの50%のサイズである100MBがglobal memory boundに設定されていますね。

最後に、pga_aggregate_targetを4095GBにしてみると〜

SYS> alter system set pga_aggregate_target=4095g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 4095G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4193280
aggregate PGA auto target 3773918.45
global memory bound 100

SYS>

・・・中略・・・

SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2) 100.02 409993216 409993216
0 order by code

SCOTT>

やはり、global memory boundは、_pga_max_sizeの50%のままですね。_pga_max_sizeを大きなサイズにし、pga_aggregate_targetの20%が利用されるかを確認しますよ〜。ということで次回へつづく。


前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #10
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #11
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #12

| | コメント (0) | トラックバック (0)

2010年5月15日 (土)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #12

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その12回目、

さて、Oracle11g R1 for Linux x86を利用した検証を始めるよ〜 :)

これまでと同様に、まず、_pga_max_sizeはデフォルトの200MBのままで、pga_aggregate_targetを10MB/20MB/40MB/256MB/512MBと増加させてglobal memory boundがどう変化するか確認していく。

SYS> alter system set pga_aggregate_target=10m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 10M
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 10
aggregate PGA auto target 4
global memory bound 2

SYS> alter system set pga_aggregate_target=20m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 20M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 20
aggregate PGA auto target 4
global memory bound 4

SYS> alter system set pga_aggregate_target=40m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 40M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 40
aggregate PGA auto target 11.3720703
global memory bound 8

SYS>

ここまでのところ、 pga_aggregate_targetの20%がglobal memory boundとして設定されている。

次ぎいってみよー!

SYS> alter system set pga_aggregate_target=256m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 256M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 256
aggregate PGA auto target 205.479492
global memory bound 51.1992188

SYS> alter system set pga_aggregate_target=512m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 512M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 512
aggregate PGA auto target 436.31543
global memory bound 100

お、やはり、変化しました。 512MBの20%は、102.4MBですが、global memory boundに設定された値は、100MB。 _pga_max_sizeの50%ですね〜。
おそらく、Oracle10g R1と同じ割当条件なんでしょうね。

次回はpga_aggregate_targetパラメータをさらに増加させてみますよ。。つづく。



前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #10
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #11

| | コメント (0) | トラックバック (0)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #11

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その11回目、

さて、Oracle10g R2までは試したので、今回からはOracle11g R1で試します。利用したのはOracle11g R1 for Linux x86.

いつものように現状確認と、登録済みデータの確認から。自動メモリー管理が有効は無効にしてあります。自動SGA管理と自動PGA管理は有効になってますよー。
というか少なくとも自動PGA管理は有効にしておかないとこの検証自体が・・・・w

dSYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

SYS>
SYS> @show_param

KSPPINM KSPPSTVL KSPPSTDF
-------------------------------- ------------------------------ ------------------------------
_4031_sga_dump_interval 3600 TRUE
_4031_sga_max_dumps 10 TRUE
__pga_aggregate_target 104857600 FALSE
__sga_target 352321536 FALSE
_kdli_sio_pga FALSE TRUE
_kdli_sio_pga_top FALSE TRUE
_lock_sga_areas 0 TRUE
_memory_initial_sga_split_perc 60 TRUE
_memory_nocancel_defsgareq FALSE TRUE
_pga_large_extent_size 1048576 TRUE
_pga_max_size 209715200 FALSE
_sga_clear_dump FALSE TRUE
_sga_early_trace 0 TRUE
_sga_locking none TRUE
_use_ism_for_pga TRUE TRUE
lock_sga FALSE TRUE
memory_max_target 0 TRUE
memory_target 0 TRUE
pga_aggregate_target 104857600 FALSE
pre_page_sga FALSE TRUE
sga_max_size 352321536 TRUE
sga_target 352321536 FALSE

22行が選択されました。

SYS> show parameter workarea_size_policy

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy string AUTO
SYS>

とりあえず、200000万件、1.6GBほどのデータを登録してあります。

SCOTT> select count(*) from code;

COUNT(*)
----------
200000

SCOTT> l
1 select
2 blocks*block_size/1024/1024 as "table_size(MB)"
3 from
4 user_tables ut join user_tablespaces uts
5 on ut.tablespace_name = uts.tablespace_name
6* and ut.table_name = 'CODE'
SCOTT> /

table_size(MB)
--------------
1600.625

SCOTT>

次回へつづく。



前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #10

| | コメント (0) | トラックバック (0)

2010年5月13日 (木)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #10

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その10回目、

前回までで、Oracle10g R2では、LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)という条件でPGAの作業領域を割り当てているらしいというところまでは確認できた。
今回は、隠しパラメータ、 _pga_max_sizeパラメータを3840MBという大きな値に設定し、 pga_aggregate_targetの20%が利用されるか確認してみた。

_pga_max_sizeを3840MBと設定し、pga_aggregate_targetを256MB/512MB/768MB/1G/2G/4G/8G/16Gと増加させた場合、常に1920MB(_pga_max_size*0.5)より小さくなるのでpga_aggregate_target*0.2のサイズがglobal memory boundとして設定されるはず。

では、早速確認してみる。

SYS> alter system flush shared_pool;

システムが変更されました。

SYS> alter system set "_pga_max_size"=3840m;

システムが変更されました。

SYS> alter system set pga_aggregate_target=256m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 256M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 256
aggregate PGA auto target 213.75
global memory bound 51.1992188

SYS> alter system set pga_aggregate_target=512m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 512M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 512
aggregate PGA auto target 444.155273
global memory bound 102.399414

SYS> alter system set pga_aggregate_target=768m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 768M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 768
aggregate PGA auto target 685.213867
global memory bound 153.599609

SYS> alter system set pga_aggregate_target=1g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 1G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 1024
aggregate PGA auto target 919.334961
global memory bound 204.799805

SYS> alter system set pga_aggregate_target=2g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 2G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 2048
aggregate PGA auto target 1826.8418
global memory bound 409.599609

SYS> alter system set pga_aggregate_target=4g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 4G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4096
aggregate PGA auto target 3669.74121
global memory bound 819.199219

SYS> alter system set pga_aggregate_target=8g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 8G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 8192
aggregate PGA auto target 7472.14941
global memory bound 1638.39941

SYS> alter system set pga_aggregate_target=16g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 16G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 16384
aggregate PGA auto target 14729.168
global memory bound 1920

SYS>


実メモリ2GBしか積んでないので3.2GB近くのPGAサイズが割り当てられるか実際のテストはちょいとだけ無理をして1GBぐらいを目指してみた…

SYS> alter system flush shared_pool;

システムが変更されました。

SYS> alter system set pga_aggregate_target=6g;

システムが変更されました。

SYS>
SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 3840M
pga_aggregate_target big integer 6G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 6144
aggregate PGA auto target 5513.83594
global memory bound 1228.7998

SYS>

・・・中略・・・

SCOTT> @test4

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 30000 SORT (v2) 1171.63
0 order by code

1GB以上のPGAが利用されたところまでは確認できた〜〜。ということで、

Oracle10g R2において、1セッションでパラレルクエリでなければ、LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)という条件でPGAを割り当てているのは確からしい。

今回で、Oracle10g R2 for MacOS X Server x86-64での検証はおわり、Oracle11g R1 for Linux x86で試してみようと思う。なお自動メモリー管理(AMM)は利用していない構成にしてある。ということで次回へつづく。



前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9

| | コメント (0) | トラックバック (0)

2010年5月12日 (水)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #9

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その9回目、

_pga_max_sizeはデフォルトの200MBのままで、pga_aggregate_targetを256MB/512MB/768MB/1GB/2GB/4GB/8GB/16GB/4095GBと増加させてみる。

Oracle10g R2 for MacOS X x86_64版では、Oracle10g R1までと違い、pga_aggregate_target * 0.2を割り当てているということまでは見る事ができた。
以前のリリースのように _pga_max_size * 0.5と比べて小さい値を使うのだと仮定すれば、 LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5)となっているんでしょうね。きっと。

とすると… 256MB/512MB/768MB/1GB/2GB/4GB/8GB/16GB/4095GBとpga_aggregate_targetを増加させると、256MBの場合だけ _pga_max_size * 0.5 を下回る。pga_aggregate_targetが512MB以上、かつ_pga_max_sizeがデフォルトの200MBの場合、global memory boundは常に100MBになるはず。

じゃ、確かめてみよう!

SYS> alter system set pga_aggregate_target=256m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 256M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 256
aggregate PGA auto target 213.855469
global memory bound 51.1992188

SYS>

SYS> alter system set pga_aggregate_target=512m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 512M
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 512
aggregate PGA auto target 443.979492
global memory bound 100

やはり、ここで変化しましたね!

SYS> alter system set pga_aggregate_target=768m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 768M
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 768
aggregate PGA auto target 674.384766
global memory bound 100

SYS> alter system set pga_aggregate_target=1g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 1G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 1024
aggregate PGA auto target 905.053711
global memory bound 100

SYS> alter system set pga_aggregate_target=2g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 2G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 2048
aggregate PGA auto target 1826.63965
global memory bound 100

SYS> alter system set pga_aggregate_target=4g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 4G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4096
aggregate PGA auto target 3669.82031
global memory bound 100

SYS> alter system set pga_aggregate_target=8g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 8G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 8192
aggregate PGA auto target 7356.19043
global memory bound 100

SYS> alter system set pga_aggregate_target=16g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 16G
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 16384
aggregate PGA auto target 14728.9131
global memory bound 100

SYS>

・・・中略・・・

SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2) 100.02 409993216 409993216
0 order by code

SCOTT>

・・・中略・・・

SYS> alter system flush shared_pool;

システムが変更されました。

SYS> alter system set pga_aggregate_target=4095g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 4095G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4193280
aggregate PGA auto target 3773925.04
global memory bound 100

・・・中略・・・

SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2) 100.02 409993216 409993216
0 order by code

SCOTT>

予想通り、 LEAST(pga_aggregate_target * 0.2, _pga_max_size * 0.5) となっている模様〜。まだまだつづきますよ〜 :)



前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8

| | コメント (0) | トラックバック (0)

2010年5月11日 (火)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #8

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その8回目、

Oracle10g R1の場合と同様に、_pga_max_sizeパラメータはデフォルト(200BMMB)のまま、pga_aggregate_targetを10MBスタートして増加させて確認していきますよ〜。

SYS> alter system set pga_aggregate_target=10m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 10M
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 10
aggregate PGA auto target 4
global memory bound 2

SYS>

・・・中略・・・

SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2) 2.01 409993216 409993216
0 order by code

SCOTT>

あれ、Oracle10g R1までの頃と割り当てられてるサイズが違う! pga_aggregate_targetが10MBなのに0.5MBではなく、2MB。つまり20%が割り当てられてます。

SYS> alter system flush shared_pool;

システムが変更されました。

SYS> alter system set pga_aggregate_target=20m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 20M
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 20
aggregate PGA auto target 4
global memory bound 4

・・・中略・・・

SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2) 4.04 409993216 409993216
0 order by code

SCOTT>

・・・中略・・・

SYS> alter system flush shared_pool;

システムが変更されました。

SYS> alter system set pga_aggregate_target=40m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 40M
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 40
aggregate PGA auto target 18.4570313
global memory bound 8

・・・中略・・・

SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT (v2) 8.04 409993216 409993216
0 order by code

SCOTT>

Oracle10g R1までの頃より、pgaの作業領域が大きく確保されるようになってるということもある程度見えましたが、まだばだ続きます。

注)パラレルクエリの場合はちょいと違いますからご注意を。余裕があったらやるかもしれないけど。:)


前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7

| | コメント (0) | トラックバック (0)

2010年5月10日 (月)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #7

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その7回目、

今回からOracle10g R2での検証、環境は以下。

Oracle10g R2 for MacOS X Server (x86_64) / MacOS X 10.6.3 Core2 Duo 2.2Ghz RAM:2GB

手順はOracle10g R1の場合と同じだが、多少順番が前後したり設定するサイズは変更しながら行うかもしれないのであしからず。

SYS> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for MacOS X Server: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

SYS>

Oracle10g R1 for MacOS X Serverの場合と同じテスト表とデータを用意してっ、と。

SCOTT> 
SCOTT> create table code (code varchar2(4000));

表が作成されました。

SCOTT>
SCOTT> begin for i in 1..100000 loop insert into code values(lpad('#',4000,'#')); end loop; commit; end;
2 /

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'CODE',degree=>2,estimate_percent=>100);

PL/SQLプロシージャが正常に完了しました。

SCOTT>
SCOTT> l
1 select
2 blocks*block_size/1024/1024 as "table_size(MB)"
3 from
4 user_tables ut join user_tablespaces uts
5 on ut.tablespace_name = uts.tablespace_name
6* and ut.table_name = 'CODE'
SCOTT> /

table_size(MB)
--------------
788.101563

SCOTT>


テスト開始まえの関連パラメータの値は以下のような状態になってます。

SYS> @show_param

KSPPINM KSPPSTVL KSPPSTDF
------------------------------ ------------------------------ ------------------------------
_4031_sga_dump_interval 3600 TRUE
_4031_sga_max_dumps 10 TRUE
_lock_sga_areas 0 TRUE
_pga_large_extent_size 1048576 TRUE
_pga_max_size 209715200 FALSE
_use_ism_for_pga TRUE TRUE
lock_sga FALSE TRUE
pga_aggregate_target 104857600 FALSE
pre_page_sga FALSE TRUE
sga_max_size 612368384 TRUE
sga_target 612368384 FALSE

11行が選択されました。

SYS> show parameter workarea_size

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
workarea_size_policy string AUTO
SYS>


引っ張るメソッドはいつもと同じということで、Oracle10g R2編、次回へつづく。 :)


前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6

| | コメント (0) | トラックバック (0)

2010年5月 9日 (日)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #6

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その6回目、

前回までで、Oracle10g R1 (32bit)がpga_aggregate_targetパラメータと_pga_max_sizeパラメータをどのように使ってpgaの作業領域を割り当てているか見えたのですが、念押しでもういっちょw.

_pga_max_size * 50% が使われるというところをデフォルトの200MB以外でも確認して、Oracle10g R1 (32bit)での検証はおわりにしたい。:)

_pga_max_sizeパラメータは隠しパラメータなのでOracle Supportの指示なしには変更しないパラメータ、遊ぶ場合は、趣味の環境等でやってね :)

_pga_max_sizeを400MB/800MBと変更し、pga_aggregate_targetも4GB/8GBと設定する。Oracleがきまぐれで割り当てていないのであれば、 LEAST(_pga_max_size*0.5, pga_aggregate_target*0.05)より、200MB/400MBがglobal memory boundとして設定されるはず。

SYS> alter system set "_pga_max_size" = 400m;

システムが変更されました。

SYS> alter system set pga_aggregate_target = 4g;

システムが変更されました。

SYS> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 293601280 bytes
Fixed Size 778888 bytes
Variable Size 116137336 bytes
Database Buffers 176160768 bytes
Redo Buffers 524288 bytes
データベースがマウントされました。
データベースがオープンされました。
SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 400M
pga_aggregate_target big integer 4G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4096
aggregate PGA auto target 3673.17773
global memory bound 200

SYS>

・・・中略・・・

SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT 172.89 409993216 409993216
0 order by code

・・・中略・・・

SYS> alter system set "_pga_max_size" = 800m;

システムが変更されました。

SYS> alter system set pga_aggregate_target = 8g;

システムが変更されました。

SYS> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 293601280 bytes
Fixed Size 778888 bytes
Variable Size 116137336 bytes
Database Buffers 176160768 bytes
Redo Buffers 524288 bytes
データベースがマウントされました。
データベースがオープンされました。
SYS>
SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 800M
pga_aggregate_target big integer 8G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 8192
aggregate PGA auto target 7359.09961
global memory bound 400

SYS>

・・・中略・・・

SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT 370.66 409993216 409993216
0 order by code

ということで、Oracle10g R2 編へつづく。




前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5

| | コメント (0) | トラックバック (0)

2010年5月 8日 (土)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #5

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その5回目、

Oracle10g R1 (32bit)で、pga_aggregate_targetを40MBから一気に上限に近い4095GBに増加させたところで、global memory boundへの割当割合が変化した。

今回は、pga_aggregate_targetを1GBから16GBそして、後半では、_pga_max_sizeも増加させてどう変化するか確認してみることに。

_pga_max_sizeパラメータは隠しパラメータなのでOracle Supportの指示なしには変更しないパラメータ、遊ぶ場合は、趣味の環境等でやってね :)

あ、ところで、なんでPGAネタを始めたかって? 知りたいですか? 

実は、先日、インフラ担当(Oracleにはかなり詳しいと思われる)の方と話していて、pga_aggregate_targetの話題になったとき、その方が、「そーゆー、都市伝説みたいな話があるよね〜、キッパリ!」、みたいなノリで話していたので、私:「そんな事ないよー、都市伝説みたいじゃなくて都市伝説だよ(ウソウソ)、ほんととうにそう動いてるよ〜」、という話をしていて、どーしても書かなきゃ!、という気持ちになったのでした〜。それ以外に、第一回目でもちょっと書きましたが、10g r2ではちょいと変わったとか...いう話もあったし。(マニュアルにも書いてないし、Oracleに完全お任せでいいかというと、性能問題に絡んでくるちょいといやらしいとこなので)

余談はこのくらいにして、実験再開。

実際にソート処理をさせなくても、いままでの結果から、global memory boundの値が自動PGAメモリー管理では重要な意味があることは確認できたと思うので、毎回ソート処理を行わないで進めます。(適当な所で実際にソートしてみます!)

Oracle10g R1も9iと同様に、MIN(pga_aggregate_target * 0.05, _pga_max_size * 0.5)という条件で割り当てているのはほぼ確実なので、_pga_max_size=200MB (デフォルト)のままで、pga_aggregate_targetを1GB/2GB/4GB/8GB/16GBと増加させた場合、_pga_max_size * 0.5 = 100MBを下回るのは、pga_aggregate_targetに1GBを指定した場合のみなので、Oracleが気まぐれにglobal memory boundを設定しているのでなければ、global memory boundは、51.2BM/100MB/100MB/100MB/100MBという変化になるはず!


2010/5/8追記:
MIN(pga_aggregate_target * 0.05, _pga_max_size * 0.5)という表現よりSQLなら
LEAST(pga_aggregate_target * 0.05, _pga_max_size * 0.5)こっちの方がいいな次ぎからLEASTにする。


ということを脳のcacheにKEEPした上で、以下をご覧ください。
SYS> alter system set pga_aggregate_target=1g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 1G

SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 1024
aggregate PGA auto target 908.4375
global memory bound 51.1992188

SYS>
SYS>
SYS> alter system set pga_aggregate_target=2g;

システムが変更されました。

SYS>
SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 2G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 2048
aggregate PGA auto target 1830.2168
global memory bound 100

SYS>
SYS> alter system set pga_aggregate_target=4g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 4G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4096
aggregate PGA auto target 3673.33594
global memory bound 100

SYS>
SYS> alter system set pga_aggregate_target=8g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 8G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 8192
aggregate PGA auto target 7359.69727
global memory bound 100

SYS>
SYS> alter system set pga_aggregate_target=16g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 16G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 16384
aggregate PGA auto target 14732.2793
global memory bound 100

SYS>
SYS>

・・・中略・・・

SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT 97.58 409993216 409993216
0 order by code

やった〜!、予想通り!!! :)

さらに念押し、pga_aggregate_target * 5%が _pga_max_size * 50% より小さくなるようにして、さらに変化を見る。

16GB * 5% = 819.2MB なので 820MB * 2 = 1640MB を _pga_max_sizeパラメータに設定すればいろいろと見えるよね。たぶん。

MacOS X版Oracle10g R1だけかもしれないけど?(未確認なので)、動的に変わるはず(と思っている)_pga_max_sizeがどうも静的なので、Oracle10g R1では _pga_max_sizeを変更した場合は必ず、インスタンスを再起動しています。 (^^;;;;

_pga_max_sizeを1640MBに設定後、pga_aggregate_targetを1GB/2GB/4GB/8GB/16GBと増加させます。Oracleが気まぐれでglobal memory boundを設定していなければ、global memory boundの値は、51.2MB/102.4MB/204.8MB/409.6MB/819.2MBという変化を見せてくれるはず。

SYS> alter system set "_pga_max_size"=1640m;

システムが変更されました。

SYS> alter system set pga_aggregate_target=1g;

システムが変更されました。

SYS> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SYS> startup
ORACLEインスタンスが起動しました。

Total System Global Area 293601280 bytes
Fixed Size 778888 bytes
Variable Size 116137336 bytes
Database Buffers 176160768 bytes
Redo Buffers 524288 bytes
データベースがマウントされました。
データベースがオープンされました。
SYS>
SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 1640M
pga_aggregate_target big integer 1G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 1024
aggregate PGA auto target 907.892578
global memory bound 51.1992188

SYS> alter system set pga_aggregate_target=2g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 1640M
pga_aggregate_target big integer 2G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 2048
aggregate PGA auto target 1829.30273
global memory bound 102.399414

SYS>
SYS> alter system set pga_aggregate_target=4g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 1640M
pga_aggregate_target big integer 4G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4096
aggregate PGA auto target 3672.4834
global memory bound 204.799805

SYS>
SYS> alter system set pga_aggregate_target=8g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 1640M
pga_aggregate_target big integer 8G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 8192
aggregate PGA auto target 7358.87988
global memory bound 409.599609

SYS>
SYS> alter system set pga_aggregate_target=16g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 1640M
pga_aggregate_target big integer 16G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 16384
aggregate PGA auto target 14731.6289
global memory bound 819.199219

SYS>

データ量を倍にして、実際にソートしてみると。。。700MB以上のPGAを使ってくれました〜パチパチ。

SCOTT> 
SCOTT> begin for i in 1..100000 loop insert into code values(lpad('#',4000,'#')); end loop; commit; end;
2 /

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'CODE',degree=>2,estimate_percent=>100);

PL/SQLプロシージャが正常に完了しました。

SCOTT> alter system flush shared_pool;

システムが変更されました。

SCOTT> @test3

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
------------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 20000 SORT 781.26
0 order by code


SCOTT>

もうここまででもOracle10g R1での検証は十分かと思いますが、さらに念押しで確認してみますよ〜(趣味の世界w) 次回へつづく。




前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4

| | コメント (0) | トラックバック (0)

2010年5月 7日 (金)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #4

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その4回目、

Oracle10g R1 (32bit)で、pga_aggregate_targetを徐々に増加させ、PGAの使われ方がどう変わるかの確認のつづき。


pga_aggregate_targetを10MB、20MBと増加させてきたが、今回は、40MB、そして 4095GBと上限値近くまで増やしてみる。

SYS> alter system flush shared_pool;

システムが変更されました。

SYS> alter system set pga_aggregate_target=40m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 40M
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 40
aggregate PGA auto target 22.5527344
global memory bound 2

・・・中略・・・

SCOTT>
SCOTT> -- test #3 _pga_max_size=200m (default) / pga_aggregate_target=40m
SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT 1.92 409993216 409993216
0 order by code

SCOTT>

pga_aggregate_targetを10MB、20MB、40MBと増加させてみたところ、Oracle9i R2までと同じく、pga_aggregate_targetの5%をglobal memory boundとし、その値を上限にオペレーションしていることは確からしい。

次ぎは、_pga_max_sizeパラメータのデフォルト値である200MBを元にしてPGAサイズが決定されるようにしてみる。
pga_aggregate_targetを4095GBにする必要は全くないのだけれどね、ほんとうは。 :)

SYS> 
SYS> alter system flush shared_pool;

システムが変更されました。

SYS> alter system set pga_aggregate_target=4095g;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 4095G
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 4193280
aggregate PGA auto target 3773929.32
global memory bound 100

SYS>

・・・中略・・・

SCOTT>
SCOTT> -- test #4 _pga_max_size=200m (default) / pga_aggregate_target=4095G
SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT 97.58 409993216 409993216
0 order by code

SCOTT>

お〜〜〜っと、ここで変化が現れました。

これまでのテストでは、pga_aggregate_targetの5%がglobal memory boundとして調整されていましたが、5%より随分小さい値が設定されています。これもOracle9i R2と同様に、_pga_max_sizeの50%という値が設定されていると考えてよさそう。 pga_aggregate_target * 5% か _pga_max_size * 50% のいずれか小さい方が利用されていますよね。

次回はその辺りをもう少し細かく確認してみよと思います。つづく…




前回までのあらすじ・・・

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3

| | コメント (0) | トラックバック (0)

2010年5月 6日 (木)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #3

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その3回目、

まずは、pga_aggregate_targetパラメータを変更し、PGAがどのように利用されるかみていく。10MBからはじめ、徐々に増加させてみる。
(なお、Oracleのバックグラウンドプロセス以外のセッションは以後のテストで接続している1セッションのみ。同時に複数のセッションがあると自動PGAメモリー管理が働きすぎて困るのでw)

SYS>
SYS> alter system set pga_aggregate_target=10m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 10M

SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 10
aggregate PGA auto target 4
global memory bound .5

SYS>

前述の情報を見ただけでもわかる方はもう気づいたと思いますが、実際にソート処理を行わせてPGAのサイズなどもみておきますね。(その方が面白いしw)

SCOTT> --test #1 _pga_max_size=200m(default) / pga_aggregate_target=10m
SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT .44 409993216 409993216
0 order by code

SCOTT>

前述の結果から見ると、ソート処理は、0.44MBのPGAを利用していることが確認でき、そのサイズは、global memory bound以下のサイズであり、global memory boundは、pga_aggregate_targetパラメータで指定したサイズ(10MB)の5%である0.5MBであることがわかる。

では次ぎに、20MBに増加させて試してみると…

SYS> alter system flush shared_pool;

システムが変更されました。

SYS> alter system set pga_aggregate_target=20m;

システムが変更されました。

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 20M

SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 20
aggregate PGA auto target 4.36816406
global memory bound 1

・・・中略・・・

SCOTT>
SCOTT> -- test #2 _pga_max_size=200m(default) / pga_aggregate_target=20m
SCOTT> @test2

SQL_TEXT OPERATION_TYPE last_mem(MB) LAST_TEMPSEG_SIZE MAX_TEMPSEG_SIZE
---------------------------------------- -------------------- ------------ ----------------- ----------------
select * from code where rownum <= 10000 SORT .97 409993216 409993216
0 order by code

SCOTT>


pga_aggregate_targetパラメータが10MBの場合と同様に、pga_aggregate_target5%がglobal memory boundのサイズとして調整され、ソート処理を行わせてもその範囲以下を上限としてメモリソート+DISKソートが行われていることがわかる。

Oracle10g R1は、Oracle9i R2のまでと同じ割当方法だよね〜。

ここまでに利用したスクリプトは以下。(今回使った分ね。)
・test2.sql

set term off
select * from code where rownum <= 100000 order by code
/
set term on
@show_workarea2

・show_workarea2.sql

col sql_text for a40
col operation_type for a20
select
sql_text
,operation_type
,round(last_memory_used/1024/1024,2) as "last_mem(MB)"
,last_tempseg_size
,max_tempseg_size
from
v$sql vs join v$sql_workarea vsw
on vs.sql_id = vsw.sql_id
where
sql_text='select * from code where rownum <= 100000 order by code'
/

ということで、次回へつづく。 :)


前回までのあらすじ・・・
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2

| | コメント (0) | トラックバック (0)

2010年5月 5日 (水)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #2

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? その2回目、

自動PGAメモリー管理下ではどのようにPGAが割り当てられているのか確認して見ることに…

はじめは、

Oracle10g R1 for MacOS X Server (32bit) / MacOS X 10.4.11 Server PPC G5 Dual 2.7Ghz RAM:1GB

という環境から。

SYS> select * from v$version;

BANNER
----------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Prod
PL/SQL Release 10.1.0.3.0 - Production
CORE 10.1.0.3.0 Production
TNS for MacOS X Server: Version 10.1.0.3.0 - Production
NLSRTL Version 10.1.0.3.0 - Production

SYS>

以下、隠しパラメータも含めて(多めに表示してますが気にしないで・・)確認!
赤字のパラメータはいろいろ関わってくるから気にしておくと吉だけど、隠しパラメータは基本的にユーザがかってに変更するパラメータではないので、Oracle社さんからの指示に従ってね :-)

ちなみに、隠しパラメータは、パラメータ名称の先頭が "_"になっているパラメータのこと。かってに変更されては困るからマニュアルにも記載されていないパラメータのこと。
英語圏のブログを検索するときは、hidden parameters なんてキーワード含めるといいよ!

SYS> @show_param

KSPPINM KSPPSTVL KSPPSTDF
------------------------------ ------------------------------ ------------------------------
_4031_sga_dump_interval 3600 TRUE
_4031_sga_max_dumps 10 TRUE
_lock_sga_areas 0 TRUE
_pga_large_extent_size 1048576 TRUE
_pga_max_size 209715200 FALSE
_use_ism_for_pga TRUE TRUE
lock_sga FALSE TRUE
pga_aggregate_target 104857600 FALSE
pre_page_sga FALSE TRUE
sga_max_size 293601280 TRUE
sga_target 293601280 FALSE

11行が選択されました。

SYS>
SYS> show parameter workarea_size_policy

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
workarea_size_policy string AUTO
SYS>


隠しパラメータは通常はshow parameterコマンドでは表示されないけど一旦設定してあげると表示されるようになるんだよ〜。
_pga_max_size隠しパラメータのデフォルト値は200MBなんだけどあえて設定してやることでshow parameterコマンドで確認できるようにしてあります。
マネしないでね、してもいいけど自己責任でお願いします (^^;;;

SYS> show parameter pga

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
_pga_max_size big integer 200M
pga_aggregate_target big integer 100M
SYS>
SYS> @pgastat

NAME size(MB)
-------------------------------------------------- ----------
aggregate PGA target parameter 100
aggregate PGA auto target 76.6142578
global memory bound 5

SYS>

最後の結果は、v$pgastatビューを問い合わせているんですが、一番のポイントは赤字部分のglobal memory boundなのでよ〜〜〜〜く覚えておいてね (^^

以下、ここまでで使ったスクリプト。

show_param.sql

set linesize 200
col ksppinm for a30
col ksppstvl for a30
col ksppstdf for a30
select
a.ksppinm
,b.ksppstvl
,b.ksppstdf
from
x$ksppi a join x$ksppcv b
on a.indx = b.indx
where
a.ksppinm like '%pga%'
or a.ksppinm like '%sga%'
or a.ksppinm like 'memory%'
order by
a.ksppinm
/

pgastat.sql

set linesize 200
col name for a50
select
name
,value/1024/1024 "size(MB)"
from
v$pgastat
where
name in (
'aggregate PGA target parameter'
,'aggregate PGA auto target'
,'global memory bound'
)
/


というこで、引っぱりまくってますが、Oracle10g R1 (32bit)編、次回へつづく。


前回までのあらすじ・・・ ・pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1

| | コメント (0) | トラックバック (0)

pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? #1

かな〜り間が空きましたが、久々にMac De Oracleっぽいネタにしました〜w

pga_aggregate_targetというか_pga_max_sizeパラメータというかPGAに割り当てられるSORTやhash-joinなどのサイズ絡みの話をいくつかのプロジェクトでしてたらOracle10g R2以降は割当る割合が変わったよね〜なんて話が出てた事もあり、実際はどーなーのよー。という事で調べてみる事にした。

Oracle9i R2までのお話は、過去記事や国内外のブログでも沢山書かれているのでそちらも参考にしてもらうよろしいかと…

sizing pga_aggregate_target and pga_max_size for Oracle
The _PGA_MAX_SIZE hidden parameter
新・ソートに関する検証
32bitと64bitのOracle10gでも_pga_max_sizeの値は同じ。
Mac De Oracle なんですが、Windows(32bit)でのOracleな話 #2

確認方法は、前述した新・ソートに関する検証の検証方法を参考に進めて行くことにした。
pga_aggregate_target関連の話でかつ、日本語の記事だとここが一番分かりやすい。感謝。

今回対象としたのは以下のプラットフォームとリリースのOracle

・Oracle10g R1 for MacOS X Server (32bit) / MacOS X 10.4.11 Server PPC G5 Dual 2.7Ghz RAM:1GB
・Oracle10g R2 for MacOS X Server (64bit) / MacOS X 10.6.3 Core2 Duo 2.2Ghz RAM:2GB
・Oracle11g R1 for Linux x86 (32bit) / CentOS 5.4 Pentium M 1Ghz RAM:768MB
・Oracle11g R2 for Linux x86 (32bit) / CentOS 5.4 Pentium M 1Ghz RAM:768MB


まず、検証対象の全データベースのSCOTTスキーマに以下の表とデータを登録しておく! :)

SCOTT> create table code (code varchar2(4000));

表が作成されました。

SCOTT> begin for i in 1..100000 loop insert into code values(lpad('#',4000,'#')); end loop; commit; end;
2 /

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'CODE',estimate_percent=>100);

PL/SQLプロシージャが正常に完了しました。

SCOTT>
SCOTT> l
1 select
2 blocks*block_size/1024/1024 as "table_size(MB)"
3 from
4 user_tables ut join user_tablespaces uts
5 on ut.tablespace_name = uts.tablespace_name
6* and ut.table_name = 'CODE'
SCOTT> /

table_size(MB)
--------------
782.101563

SCOTT>

ということで、次回へつづく。 (^^

| | コメント (0) | トラックバック (0)

2010年3月24日 (水)

PL/SQLでCASE式を使わずに条件分岐 #3

PL/SQLでCASE式を使わずに条件分岐の3回目です。

前回作成したプロシージャをパッケージ化し、コマンドを外部から与えられるようにしてみます。

前回作成したsimpleCommandプロシージャを削除してパッケージ化します。store()プロシージャでコマンドを登録、execute()プロシージャで実行です。

SCOTT> drop procedure simpleCommand;

プロシージャが削除されました。

SCOTT>
SCOTT> l
1 CREATE OR REPLACE PACKAGE simpleCommand
2 AS
3 PROCEDURE store(
4 commandName IN VARCHAR2
5 ,commandSource IN command
6 );
7 --
8 PROCEDURE execute(
9 commandName IN VARCHAR2
10 );
11* END;
SCOTT> /

パッケージが作成されました。

SCOTT>
SCOTT> l
1 CREATE OR REPLACE PACKAGE BODY simpleCommand
2 AS
3 TYPE command_type IS TABLE OF command INDEX BY VARCHAR2(4000);
4 commands command_type;
5 --
6 PROCEDURE store(
7 commandName IN VARCHAR2
8 ,commandSource IN command
9 )
10 IS
11 BEGIN
12 commands(commandName) := commandSource;
13 END;
14 --
15 PROCEDURE execute(
16 commandName IN VARCHAR2
17 )
18 IS
19 BEGIN
20 commands(commandName).execute();
21 EXCEPTION
22 WHEN NO_DATA_FOUND THEN
23 DBMS_OUTPUT.PUT_LINE('そんなコマンド知りません! >< ');
24 END;
25* END;
SCOTT> /

パッケージ本体が作成されました。

SCOTT>

では早速試してみます。まず、コマンドを登録!

SCOTT> l
1 BEGIN
2 simpleCommand.store(
3 'いま何時?',
4 Command(
5 'BEGIN '||
6 'DBMS_OUTPUT.PUT_LINE(''現在時刻:''||TO_CHAR(systimestamp, ''yyyy-mm-dd hh24:mi:ss''));'||
7 'END;'
8 )
9 );
10 simpleCommand.store(
11 '従業員数は?',
12 Command(
13 'DECLARE '||
14 'numberOfEmployees NUMBER;'||
15 'BEGIN '||
16 'SELECT COUNT(*) INTO numberOFEmployees FROM emp;'||
17 'DBMS_OUTPUT.PUT_LINE(''従業員数:''||TO_CHAR(numberOfEmployees));'||
18 'END;'
19 )
20 );
21 simpleCommand.store(
22 '従業員リスト',
23 Command(
24 'DECLARE '||
25 'CURSOR empList IS '||
26 'SELECT '||
27 'empno '||
28 ',ename '||
29 ',dname '||
30 'FROM '||
31 'emp JOIN dept '||
32 'ON emp.deptno = dept.deptno '||
33 'ORDER BY '||
34 'dname, empno, ename;'||
35 'BEGIN '||
36 'FOR empRec IN empList LOOP '||
37 'DBMS_OUTPUT.PUT_LINE(empRec.empno || '' '' || empRec.ename || '' '' || empRec.dname);'||
38 'END LOOP; '||
39 'END;'
40 )
41 );
42* END;
SCOTT> /

PL/SQLプロシージャが正常に完了しました。

SCOTT>


実行!.これで適用範囲を広げらるかも・・・w

SCOTT> set serveroutput on size 100000
SCOTT>
SCOTT> exec simpleCommand.execute('従業員リスト');
7782 CLARK ACCOUNTING
7839 KING ACCOUNTING
7934 MILLER ACCOUNTING
7369 SMITH RESEARCH
7566 JONES RESEARCH
7788 SCOTT RESEARCH
7876 ADAMS RESEARCH
7902 FORD RESEARCH
7499 ALLEN SALES
7521 WARD SALES
7654 MARTIN SALES
7698 BLAKE SALES
7844 TURNER SALES
7900 JAMES SALES

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec simpleCommand.execute('いま何時?');
現在時刻:2010-03-20 23:53:22

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec simpleCommand.execute('従業員数は?');
従業員数:14

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec simpleCommand.execute('ほげほげ');
そんなコマンド知りません! ><

PL/SQLプロシージャが正常に完了しました。

SCOTT>




・バックナンバー
PL/SQLでCASE式を使わずに条件分岐 #1
PL/SQLでCASE式を使わずに条件分岐 #2

| | コメント (0) | トラックバック (0)

2010年3月23日 (火)

PL/SQLでCASE式を使わずに条件分岐 #2

PL/SQLでCASE式を使わずに条件分岐の2回目です。

前回作成したプロシージャから、とにかくCASE式を無くてみましょ。

まず、以下の様なオブジェクト型を定義して・・・・・

SCOTT> l
1 CREATE OR REPLACE TYPE command AS OBJECT
2 (
3 commandStr CLOB,
4 MEMBER PROCEDURE execute
5* );
SCOTT> /

型が作成されました。

SCOTT>
SCOTT> l
1 CREATE OR REPLACE TYPE BODY command
2 AS
3 MEMBER PROCEDURE execute
4 IS
5 BEGIN
6 EXECUTE IMMEDIATE commandStr;
7 END;
8* END;
SCOTT> /

型本体が作成されました。

SCOTT>

PL/SQLの結合配列のINDEXにVARCHAR2型を利用すればハッシュテーブルと同じように使えることを利用して実行するコマンドはCLOBに格納してEXECUTE IMMEDIATE文で実行しちゃうという方法です。実行するコマンドは外部から与えるようにすることもできますが、とりあえず内部に直書き。

SCOTT> l
1 CREATE OR REPLACE PROCEDURE simpleCommand
2 (
3 commandName IN VARCHAR2
4 )
5 IS
6 TYPE command_type IS TABLE OF command INDEX BY VARCHAR2(4000);
7 commands command_type;
8 --
9 PROCEDURE init IS
10 BEGIN
11 commands('いま何時?')
12 := Command(
13 'BEGIN '||
14 'DBMS_OUTPUT.PUT_LINE(''現在時刻:''||TO_CHAR(systimestamp, ''yyyy-mm-dd hh24:mi:ss''));'||
15 'END;'
16 );
17 commands('従業員数は?')
18 := Command(
19 'DECLARE '||
20 'numberOfEmployees NUMBER;'||
21 'BEGIN '||
22 'SELECT COUNT(*) INTO numberOFEmployees FROM emp;'||
23 'DBMS_OUTPUT.PUT_LINE(''従業員数:''||TO_CHAR(numberOfEmployees));'||
24 'END;'
25 );
26 commands('従業員リスト')
27 := Command(
28 'DECLARE '||
29 'CURSOR empList IS '||
30 'SELECT '||
31 'empno '||
32 ',ename '||
33 ',dname '||
34 'FROM '||
35 'emp JOIN dept '||
36 'ON emp.deptno = dept.deptno '||
37 'ORDER BY '||
38 'dname, empno, ename;'||
39 'BEGIN '||
40 'FOR empRec IN empList LOOP '||
41 'DBMS_OUTPUT.PUT_LINE(empRec.empno || '' '' || empRec.ename || '' '' || empRec.dname);'||
42 'END LOOP; '||
43 'END;'
44 );
45 END;
46 --
47 BEGIN
48 init();
49 --
50 commands(commandName).execute();
51 EXCEPTION
52 WHEN NO_DATA_FOUND THEN
53 DBMS_OUTPUT.PUT_LINE('そんなコマンド知りません! >< ');
54* END;
SCOTT>
SCOTT> /

プロシージャが作成されました。

SCOTT>


できた!!! :)

SCOTT> set serveroutput on size 100000
SCOTT> exec simpleCommand('いま何時?');
現在時刻:2010-03-20 15:50:27

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec simpleCommand('従業員リスト');
7782 CLARK ACCOUNTING
7839 KING ACCOUNTING
7934 MILLER ACCOUNTING
7369 SMITH RESEARCH
7566 JONES RESEARCH
7788 SCOTT RESEARCH
7876 ADAMS RESEARCH
7902 FORD RESEARCH
7499 ALLEN SALES
7521 WARD SALES
7654 MARTIN SALES
7698 BLAKE SALES
7844 TURNER SALES
7900 JAMES SALES

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec simpleCommand('従業員数は?');
従業員数:14

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec simpleCommand('ほげほげ');
そんなコマンド知りません! ><

PL/SQLプロシージャが正常に完了しました。

SCOTT>

次回はコマンドを外部から与えられるように改造してみます。 次回へつづく。


・バックナンバー
PL/SQLでCASE式を使わずに条件分岐 #1

| | コメント (0) | トラックバック (0)

2010年3月22日 (月)

PL/SQLでCASE式を使わずに条件分岐 #1

随分前ですが、html5-developers-jpのディスカッションでJavaScriptでswitch文を使わずに条件分岐という話題があって、あ、そうそう、PL/SQLでもできるよね、って瞬間的に思っていたのですが、忙しくて、ず〜っと放置してたネタでございます。:)

今回は使うのは、Oracle11g R2 for Linux x86。

SCOTT> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

まずは、CASE式を使って書けば以下のような感じになるよね! ってところから。

SCOTT> l
1 CREATE OR REPLACE PROCEDURE simpleCommand
2 (
3 commandName IN VARCHAR2
4 )
5 IS
6 CURSOR empList IS
7 SELECT
8 empno
9 ,ename
10 ,dname
11 FROM
12 emp JOIN dept
13 ON emp.deptno = dept.deptno
14 ORDER BY
15 dname, empno, ename
16 ;
17 --
18 numberOfEmployees NUMBER;
19 BEGIN
20 CASE commandName
21 WHEN 'いま何時?' THEN
22 DBMS_OUTPUT.PUT_LINE('現在時刻:'||TO_CHAR(systimestamp, 'yyyy-mm-dd hh24:mi:ss'));
23 WHEN '従業員数は?' THEN
24 SELECT COUNT(*) INTO numberOFEmployees FROM emp;
25 DBMS_OUTPUT.PUT_LINE('従業員数:'||TO_CHAR(numberOfEmployees));
26 WHEN '従業員リスト' THEN
27 FOR empRec IN empList LOOP
28 DBMS_OUTPUT.PUT_LINE(empRec.empno || ' ' || empRec.ename || ' ' || empRec.dname);
29 END LOOP;
30 ELSE
31 DBMS_OUTPUT.PUT_LINE('そんなコマンド知りません! >< ');
32 END CASE;
33 --
34* END;
SCOTT> /

プロシージャが作成されました。

SCOTT>
SCOTT> set serveroutput on size 100000
SCOTT> exec simpleCommand('いま何時?');
現在時刻:2010-03-21 00:10:17

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec simpleCommand('従業員リスト');
7782 CLARK ACCOUNTING
7839 KING ACCOUNTING
7934 MILLER ACCOUNTING
7369 SMITH RESEARCH
7566 JONES RESEARCH
7788 SCOTT RESEARCH
7876 ADAMS RESEARCH
7902 FORD RESEARCH
7499 ALLEN SALES
7521 WARD SALES
7654 MARTIN SALES
7698 BLAKE SALES
7844 TURNER SALES
7900 JAMES SALES

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec simpleCommand('従業員数は?');
従業員数:14

PL/SQLプロシージャが正常に完了しました。

SCOTT> exec simpleCommand('ほげほげ');
そんなコマンド知りません! ><

PL/SQLプロシージャが正常に完了しました。

SCOTT>


上記のようなPL/SQLプロシージャ中のCASE式を排除してコマンドパターンっぽくできるのか。。。方法はいろいろあるな〜と思いつつ、PL/SQLの結合配列を使う方法で試してみた。
ということで、次回へつづく :) …

| | コメント (0) | トラックバック (0)

2010年3月 9日 (火)

_pga_max_sizeってOracle11gではどうなったっけ? という確認。

2010/11/25追記
実は_pga_max_sizeの扱いがOracle10g R2以降ひっそりと変更されていた!という事実。Season2という後付けのタイトルで後日談を書いておきましたので次いでに見ておくとちょっとは幸せになるかも…
pga_aggregate_targetでPGA?、_pga_max_sizeでPGA? Season2 #1

_pga_max_sizeなどの隠しパラメータのサイズを確認しておこっと。ということでOracle11g r1とr2の比較。_pga_max_sizeの値は10g r2の頃と同じだな〜と。
ただ、Oracle11g r2ではr1とくらべてpgaが付く隠しパラメータが2つ増えてるね。

SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

SYS>
SYS> l
1 select
2 a.ksppinm
3 ,b.ksppstvl
4 ,b.ksppstdf
5 from
6 x$ksppi a join x$ksppcv b
7 on a.indx = b.indx
8 and a.ksppinm like '%pga%'
9 order by
10* a.ksppinm
SYS> /

KSPPINM KSPPSTVL KSPPSTDF
------------------------------ ------------------------------ ---------
__pga_aggregate_target 79691776 FALSE
_kdli_sio_pga FALSE TRUE
_kdli_sio_pga_top FALSE TRUE
_pga_large_extent_size 1048576 TRUE
_pga_max_size 209715200 TRUE
_use_ism_for_pga TRUE TRUE
pga_aggregate_target 78643200 FALSE

7行が選択されました。
SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

SYS>
SYS>
SYS> l
1 select
2 a.ksppinm
3 ,b.ksppstvl
4 ,b.ksppstdf
5 from
6 x$ksppi a join x$ksppcv b
7 on a.indx = b.indx
8 and a.ksppinm like '%pga%'
9 order by
10* a.ksppinm
SYS> /

KSPPINM KSPPSTVL KSPPSTDF
------------------------------ ------------------------------ ---------
__pga_aggregate_target 109051904 FALSE
_kdli_sio_pga FALSE TRUE
_kdli_sio_pga_top FALSE TRUE
_ldr_pga_lim 0 TRUE
_pga_large_extent_size 1048576 TRUE
_pga_max_size 209715200 TRUE
_pgactx_cap_stacks FALSE TRUE
_use_ism_for_pga TRUE TRUE
pga_aggregate_target 0 TRUE

9行が選択されました。

SYS>

| | コメント (0) | トラックバック (0)

2010年2月 8日 (月)

SQLって深いよね、ほんと。

先日、以下のようなクエリを見てこんな書き方見た事無いとか、クエリが間違ってんじゃないのとか騒いでいたので、そんなこと無いよ! と一言。(アプリケーションの要求仕様までは把握していないので、アプリケーション的に正しいのか?ってところまでは不明だったのですが…)
外部結合でOracleの方言を使っちゃうとパッと見、結合条件なのか選択条件なのか分かり憎いのは間違いないので、利用できるリリースのOracleなら標準的な記述にしたほうがいいよねというお話。


以下、Oracleの方言で外部結合を行うクエリ。5行目の部分が騒ぎの発端。多分、みなさん結合条件じゃなくて、選択条件と勘違いしたか、結合条件だと判断してたとしても何か勘違いした模様で騒いでいたらしい。

SCOTT> l

1 SELECT ename,dname,loc
2 FROM emp,dept
3 WHERE
4 emp.deptno = dept.deptno(+)
5* AND dept.loc(+) = 'NEW YORK'
SCOTT> /

ENAME DNAME LOC
---------- -------------- -------------
MILLER ACCOUNTING NEW YORK
KING ACCOUNTING NEW YORK
CLARK ACCOUNTING NEW YORK
scott
JAMES
TURNER
BLAKE
MARTIN
WARD
ALLEN
FORD
JONES
SMITH
ほげ

14行が選択されました。

SCOTT>

前述のようなOracleの方言は標準的な記述に書き換えると分り易くなるよ!

どうですか? 外部結合の結合条件だと一発で分りますよね!

SCOTT> l

1 SELECT ename,dname,loc
2 FROM
3 emp LEFT OUTER JOIN dept
4 ON emp.deptno = dept.deptno
5* AND dept.loc = 'NEW YORK'
SCOTT> /

ENAME DNAME LOC
---------- -------------- -------------
MILLER ACCOUNTING NEW YORK
KING ACCOUNTING NEW YORK
CLARK ACCOUNTING NEW YORK
scott
JAMES
TURNER
BLAKE
MARTIN
WARD
ALLEN
FORD
JONES
SMITH
ほげ

14行が選択されました。

SCOTT>

え、まだ、もやもやしてるって?!

じゃあ、副問合せで書き換えてみたらこのクエリの意味が分り易いんじゃないかな? 以下の例のように…

SCOTT> l

1 SELECT ename,dname,loc
2 FROM
3 emp LEFT OUTER JOIN
4 (
5 SELECT *
6 FROM dept
7 WHERE loc = 'NEW YORK'
8 ) d
9* ON emp.deptno = d.deptno
SCOTT> /

ENAME DNAME LOC
---------- -------------- -------------
MILLER ACCOUNTING NEW YORK
KING ACCOUNTING NEW YORK
CLARK ACCOUNTING NEW YORK
scott
JAMES
TURNER
BLAKE
MARTIN
WARD
ALLEN
FORD
JONES
SMITH
ほげ

14行が選択されました。

SCOTT>


前述のクエリをOracleの方言で外部結合すると…

SCOTT> l

1 SELECT ename,dname,loc
2 FROM
3 emp
4 ,(
5 SELECT *
6 FROM dept
7 WHERE loc = 'NEW YORK'
8 ) d
9 WHERE
10* emp.deptno = d.deptno(+)
SCOTT> /

ENAME DNAME LOC
---------- -------------- -------------
MILLER ACCOUNTING NEW YORK
KING ACCOUNTING NEW YORK
CLARK ACCOUNTING NEW YORK
scott
JAMES
TURNER
BLAKE
MARTIN
WARD
ALLEN
FORD
JONES
SMITH
ほげ

14行が選択されました。

SCOTT>


どう? わかった?

| | コメント (2) | トラックバック (0)

2009年9月20日 (日)

Oracle SQL Developer Data Modeler #2

Oracle SQL Developer Data Modelerの第2回目です。
今回はOracle database 11g release 2 for Linux x86のHRスキーマのテーブル定義をリーバスエンジニアリングし物理モデルと論理モデル、ついでにDDLも生成してみた。以下のムービーの通りリレーションの自動レイアウトはちょっとイマイチかもしれないがそれ以外は良さげです。ちなみに今回の例でも日本語は使っていません。多分次回のエントリで日本語を使っている所を出せるかも。。あくまで予定ですので未定ですが。


以下のムービーはQuickTIme XのScreen Recorderで記録後、YouTubeへアップロード。さらにサウンドトラックをYouTube上で設定した。


尚、上記例ではOracle SQL Developer Data ModelerからOracle database 11g release 2 へはTNS接続していましうす。MacOS XのOracle SQL DeveloperでTNS接続を利用する方法と同じです。詳細は以下を参照してください。

「Oracle SQL Developer for MacOSX で Oracle Instant Clientを使ってみる」


バックナンバー
Oracle SQL Developer Data Modeler #1

| | コメント (0) | トラックバック (0)

2009年9月16日 (水)

Cross Platform Transportable Tablespace #11

twitterで呟かれていたリトルエンティアン、ビッグエンディアンで思い出したので、久々にトランスポータブル表領域について。
Oracle database 11gが登場したり、MacがPowerPCからIntelに移行したりしたのでその辺りの情報も追加されているんだろうな〜。と思い$transportable_platformの内容を比較してみた。

まず、Oracle10g R2の頃のv$transportable_platformの情報。(以前載せたものを再掲載

SYS> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
PL/SQL Release 10.2.0.2.0 - Production
CORE 10.2.0.2.0 Production
TNS for Linux: Version 10.2.0.2.0 - Production
NLSRTL Version 10.2.0.2.0 - Production

SYS> SYS> l
1 select
2 endian_format
3 ,platform_name
4 from
5* v$transportable_platform
SYS> /

ENDIAN_FORMAT PLATFORM_NAME
---------------------------- -----------------------------------------
Big Solaris[tm] OE (32-bit)
Big Solaris[tm] OE (64-bit)
Little Microsoft Windows IA (32-bit)
Little Linux IA (32-bit)
Big AIX-Based Systems (64-bit)
Big HP-UX (64-bit)
Little HP Tru64 UNIX
Big HP-UX IA (64-bit)
Little Linux IA (64-bit)
Little HP Open VMS
Little Microsoft Windows IA (64-bit)
Big IBM zSeries Based Linux
Little Linux 64-bit for AMD
Big Apple Mac OS
Little Microsoft Windows 64-bit for AMD
Little Solaris Operating System (x86)
Big IBM Power Based Linux

17行が選択されました。

SYS>


次に、Oracle11g R2のv$transportable_platformの内容
黒太字部分は名称が変っただけですね。for AMDからx86と変更されている。
また、赤太字のHP IA Open VMSとSolaris Operating System (x86-64)が追加されている。

SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

SYS> l
1 select
2 endian_format
3 ,platform_name
4 from
5* v$transportable_platform
SYS> /

ENDIAN_FORMAT PLATFORM_NAME
-------------- --------------------------------------------------
Big Solaris[tm] OE (32-bit)
Big Solaris[tm] OE (64-bit)
Little Microsoft Windows IA (32-bit)
Little Linux IA (32-bit)
Big AIX-Based Systems (64-bit)
Big HP-UX (64-bit)
Little HP Tru64 UNIX
Big HP-UX IA (64-bit)
Little Linux IA (64-bit)
Little HP Open VMS
Little Microsoft Windows IA (64-bit)
Big IBM zSeries Based Linux
Little Linux x86 64-bit
Big Apple Mac OS
Little Microsoft Windows x86 64-bit
Little Solaris Operating System (x86)
Big IBM Power Based Linux
Little HP IA Open VMS
Little Solaris Operating System (x86-64)

19行が選択されました。


SYS>


最後は、先日リリースされたOracle11g R2のv$transportable_platformの内容。
赤太字で示した通り、Intel Macが追加されている。PowerPC版のMacはBig eneianだったがIntel版ではLittle endian。

SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

SYS>
SYS> l
1 select
2 endian_format
3 ,platform_name
4 from
5* v$transportable_platform
SYS> /

ENDIAN_FORMAT PLATFORM_NAME
-------------- --------------------------------------------------
Big Solaris[tm] OE (32-bit)
Big Solaris[tm] OE (64-bit)
Little Microsoft Windows IA (32-bit)
Little Linux IA (32-bit)
Big AIX-Based Systems (64-bit)
Big HP-UX (64-bit)
Little HP Tru64 UNIX
Big HP-UX IA (64-bit)
Little Linux IA (64-bit)
Little HP Open VMS
Little Microsoft Windows IA (64-bit)
Big IBM zSeries Based Linux
Little Linux x86 64-bit
Big Apple Mac OS
Little Microsoft Windows x86 64-bit
Little Solaris Operating System (x86)
Big IBM Power Based Linux
Little HP IA Open VMS
Little Solaris Operating System (x86-64)
Little Apple Mac OS (x86-64)

20行が選択されました。

SYS>

| | コメント (0) | トラックバック (0)

2009年9月15日 (火)

Oracle database 11g release 2 for Linux x86 Install #2

前回に引き続きOracle database 11g release 2 for Linux x86のインストールです。

前回は単にOUIによるインストールの模様だけでしたが、今回はOracle database 11g release 1までのインストーラーには無かった動きや発生したエラー等の解説を。


まず最初はSYS/SYSTEM/SYSMAN/DBSNMPのパスワード設定が6.7.3 Unlocking and Changing Passwordsに記載されているガイドラインに従っているかチェックされること。以下ステップ15/20ではガイドラインに従っていないパスワードなのでエラーと警告メッセージが表示されている。

Install_o11gr2_oui_025_2

二つ目は、インストールの最低要件がチェックされ要件を満たしていなければ以下のような画面でレポートされる。同画面より修正スクリプトの生成、実行方法までが表示されるようになったこと。インストール実施中に修正できるカーネルパラメータについては「修正可能」欄に”はい”と表示される。

Install_o11gr2_oui_029
今回はインストーラの問題と思われる点が2カ所確認できる。1点目はスワップサイズで必要サイズを確保しているはずだが「ステータス」欄には”失敗”と表示されている。2点目は、CentOS5.3なので必要なパッケージにpdksh-5.2.14は含まれていないはずだが、pdkshがインストールされていないとレポートされている。ちなみにpdkshが必要なディストリビューションはCentOS4.xの場合のはずだが、、まあ、影響は特にないし、未サポートなCentOSですから。。
Install_o11gr2_oui_030_2

「修正及び再チェック」ボタンをクリックするとカーネルパラメータの修正スクリプトが自動生成され実行手順までガイドされる。指示に従いスクリプトを実行後、「OK」ボタンをクリックすると条件の再チェックが実行される。

Install_o11gr2_oui_031_1_2

Install_o11gr2_oui_032_3_2

最終的にステップ17/20の画面では、前述した2点の誤認識と物理メモリ不足(1GBのところ768MB)で、以下の3件が要件を満たしていないとレポートされた。メモリは少々不安だったが、その他の2つは問題ないので「すべて無視」をチェックして「次へ」ボタンをクリックした。

Install_o11gr2_oui_035_1_2


3つ目に、以下のアラートで表示されているエラーがDBCAで発生したこと。(OUIでデータベース作成も行ったが、DBCA単体ではどうなのかは試していない。。。。なんで???って感じ。。)

Install_o11gr2_oui_040_2 Install_o11gr2_oui_041_2

DBCAのログを調べて分かったことなのだが、これはOracle TextのオーナーCTXSYSユーザのアンロックとパスワード設定のためのalert user文が失敗(ORA-00922)し、CTXSYSユーザへconnectできず(ORA-28000が発生)にOracle Textの Default lexerや wordlist stoplist default policyの削除とデフォルト言語でそれらを作成するという処理ができなかっただけなのでインストールそのものには影響はなかったようだ。
[oracle@corydoras glassfish]$ cat postScripts.log
1
1
alter user CTXSYS account unlock identified by ******
*
行1でエラーが発生しました。:
ORA-00922: オプション指定されていないか、または無効です。


ERROR:
ORA-28000: the account is locked


警告: Oracleにはもう接続されていません。
dropping default lexer preference...
SP2-0640: 接続されていません。
dropping default wordlist preference...
SP2-0640: 接続されていません。
dropping default stoplist preference...
SP2-0640: 接続されていません。
dropping default policy...
SP2-0640: 接続されていません。
SP2-0640: 接続されていません。
lang_abbrに値を入力してください: SP2-0310: ファイル
"/u01/app/oracle/product/11.2.0/dbhome_1/ctx/admin/defaults/drdefset.sql"を
オープンできません。
[oracle@corydoras glassfish]$




関連エントリー

Oracle Database 11g Release 2 の de-install tool
Oracle Database 11g Release 2 の de-install tool #2
Oracle Database 11g Release 2 の de-install tool #3

| | コメント (0) | トラックバック (0)

2009年9月14日 (月)

Oracle database 11g release 2 for Linux x86 Install #1

さて、インストールより先にDe-installに関して試してしまったのですが、この辺りでOracle database 11g release 2のインストールの模様でも。

以前も書きましたが、OSはCentoOS5.3、RAM:768MB、CPU:Pentium M 1GhzのDynabook SS SX/210LNLWというnote pc(OSは当時からupdateしていますがそれ以外は同じです。)を使います。
(メモリは推奨されている最低サイズより小さいく、OSは推奨されているものではありませんがRedhat EnterPrise Linux 5とは互換性が高いOSですが。。)


いつものようにインストレーションガイドに従い環境確認とカーネルパラーメータを設定しますが今回はあえてカーネルパラメータの一部を推奨値より少なくしてあります。

2.2.1 Memory Requirements

[root@corydoras ˜]# grep MemTotal /proc/meminfo
MemTotal: 758184 kB
[root@corydoras ˜]# grep SwapTotal /proc/meminfo
SwapTotal: 1540088 kB
[root@corydoras ˜]#

2.2.3 Disk Space Requirements

[root@corydoras ˜]# df  -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
35G 21G 13G 63% /
/dev/hda1 99M 17M 78M 18% /boot
tmpfs 371M 0 371M 0% /dev/shm
[root@corydoras ˜]#


2.3.1 Operating System Requirements

[root@corydoras ˜]# uname -m -r -s -v
Linux 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:20:55 EDT 2009 i686
[root@corydoras ˜]#
[root@corydoras ˜]# java -version
java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)
[root@corydoras ˜]#
[root@corydoras ˜]$ cat /etc/redhat-release
CentOS release 5.3 (Final)
[root@corydoras ˜]$


2.3.3 Package Requirements

2.3.4 Compiler Requirements


[root@corydoras ˜]# rpm -q binutils compat-libstdc++-33 elfutils-libelf elfutils-libelf-devel elfutils-libelf-devel-static gcc gcc-c++ glibc glibc-common glibc-devel glibc-headers kernel-headers ksh libaio libaio-devel libgcc libgomp libstdc++ libstdc++-devel make sysstat unixODBC unixODBC-devel
binutils-2.17.50.0.6-9.el5
compat-libstdc++-33-3.2.3-61
elfutils-libelf-0.137-3.el5
elfutils-libelf-devel-0.137-3.el5
elfutils-libelf-devel-static-0.137-3.el5
gcc-4.1.2-44.el5
gcc-c++-4.1.2-44.el5
glibc-2.5-34.el5_3.1
glibc-common-2.5-34.el5_3.1
glibc-devel-2.5-34.el5_3.1
glibc-headers-2.5-34.el5_3.1
kernel-headers-2.6.18-128.7.1.el5
ksh-20080202-2.el5_3.1
libaio-0.3.106-3.2
libaio-devel-0.3.106-3.2
libgcc-4.1.2-44.el5
libgomp-4.3.2-7.el5
libstdc++-4.1.2-44.el5
libstdc++-devel-4.1.2-44.el5
make-3.81-3.el5
sysstat-7.0.2-3.el5
unixODBC-2.2.11-7.1
unixODBC-devel-2.2.11-7.1
[root@corydoras ˜]#


2.3.5.4 Browser Requirements
マニュアルの推奨値より少ない設定のままにしているパラメータあり。


[root@corydoras ˜]# /sbin/sysctl -a | grep -E '(sem|shmall|shmmax|shmmni|file-max|ip_local_port_range|mem_default|mem_max|vmem_default|vmen_max|aio-max-nr)'
net.ipv4.ip_local_port_range = 1024 65000
net.core.optmem_max = 10240
net.core.rmem_default = 4194304
net.core.wmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_max = 262144
kernel.sem = 250 32000 100 128
kernel.shmmni = 4096
kernel.shmall = 268435456
kernel.shmmax = 4294967295
fs.aio-max-nr = 65536
fs.file-max = 6553600
[root@corydoras ˜]#


2.10.1 Oracle Base Directory

[oracle@corydoras ˜]$ env | grep ORA
ORACLE_SID=glassfish
ORACLE_BASE=/u01/app/oracle
[oracle@corydoras ˜]$
[oracle@corydoras ˜]$ echo $TMP $TMP_DIR
/tmp /tmp
その他のインストール事前準備等はインストールガイドの指示に従い実施しておく。


なお、OUIの起動はMacOS XのX11 xtermからssh -Y username@hostで接続して行っています。xtermからOUIを起動した場合、xterm上に出力される日本語メッセージは文字化けするもののOUIには影響なし。また、インストール中いくつかのエラーや、CVUのチェックエラーを無視してインストールを進めている箇所がありますが、それらについては別エントリで書く事にして今回はインストールの模様のみ公開しておきます。

SYS> !sqlplus -v

SQL*Plus: Release 11.2.0.1.0 Production


SYS> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

SYS>


関連エントリー

Oracle Database 11g Release 2 の de-install tool
Oracle Database 11g Release 2 の de-install tool #2
Oracle Database 11g Release 2 の de-install tool #3

| | コメント (0) | トラックバック (0)

2009年9月11日 (金)

Oracleのデータベースオブジェクト名にはマルチバイト文字は利用しないのが吉だね

ついに明記されたか〜という感じだが、引用識別子に関してOracle database 11g release 2のreadmeに以下のような注記がある。

2

Oracle does not recommend using quoted identifiers for database object names. These quoted identifiers are accepted by SQL*Plus, but they may not be valid when using other tools that manage database objects.

私はOracleのデータベースオブジェクト名マルチバイト文字(日本語とか)定義反対派なので直接関わったプロジェクトには存在しないが、データベースオブジェクト名全てに「日本語」を使っている大きなシステムを知っている。当然そういうところでは引用識別子命!なわけで......要注意。
以下のようなことも書いてましたっけ、そういえば。

"日本語"のデータベースオブジェクト名 #1
"日本語"のデータベースオブジェクト名 #2
"日本語" de ストアド


| | コメント (0) | トラックバック (0)

2009年9月10日 (木)

Oracle Database 11g Release 2 の de-install tool #3

Oracle database 11g R2ではde-install commandeで製品をアンインストールするようマニュアルに書いてあるのに、$ORACLE_HOMEにインストールされるOUIを起動してみると・・・「製品のアンインストール」ボタンがあるじゃないか。。。削除できるか試してみたら。。。orz... こんなオチだったとは。。。「製品のアンインストール」ボタンごと削除してても良かったのでは?とも思うが、オンラインヘルプと考えれば親切なのかもしない。

ただ、クリックした瞬間に腹を抱えて笑ってしまったのは言うまでもない。。。最初から笑いを取るためのネタかw


7

| | コメント (0) | トラックバック (0)

Oracle Database 11g Release 2 の de-install tool #2

前回、Oracle11g R2のde-install tool commandを試してみたが、OUI等のマニュアルを見る限りdeinsatallはdeinstallコマンドを使うように書かれているのだが、Oracle databavse 11g release 2でインストールされたOUIで確認したところrelase 2のOUIでも「削除」機能が残っているようだ。しかも「製品のアンインストール」ボタンで。(試していないけど使えるのかな??? マニュアルには特にどちらでも使えるとは記載されていないというOracleマジックに悩み中www。使うかどうか迷うよ〜。でもマニュアルに従うならdeinstall command使うかな。)

以下、Oracle database 11g release 1のOUIの削除。($ORACLE_HOME/oui/bin/runInstallerを起動)

1

2

4_2

5


Oracle database 11g release 2ではマニュアルを見る限りOUIから削除できなくなったかのように読み取れたのだが、インストールされたOUIを実行してみるとrelease 1と同じように削除ボタンがあり実際に削除でそうに見える。(削除は試してないけど)以下の画像は$ORACLE_HOME/oui/bin/runInstallerを起動したもの。見た目はほとんとrelease 1のOUIと同じだね。
1_2

2_2

11_2

4_4

| | コメント (0) | トラックバック (0)

Oracle Database 11g Release 2 の de-install tool

Oracle Database 11g Release 2 for Linuxがリリースされたので早速インストールしたがすぐ削除した。このリリースからOracleのアンインストールはOUIから分離されDeinstall toolとして提供されているのでDeinstall toolを先に試してみたかったので。

環境はDynabook SS SX/210LNLW RAM:768MBのCentOS5.3(そう1GBのメモリを要求されていますがRelease 1の時と同様になんとかインストールは可能なようです。お遊びとしてならギリギリ使えそうな環境。

でマニュアルを見てビックリ、commandだけなんですよ。なんとなくOUI以前のインストールを思い出しちゃいますが使い方は凄く簡単でした。削除する$ORACLE_HOMEのパスを指定して別途ダウンロードしておいたdeinstallを実行するか、$ORACLE_HOME/deinstallに移動して引数無しでdeinstallを実行するかの二通り


今回は、deinstall toolを別途ダウンロードし、$ORACLE_HOMEのパスを指定してde-installしてみた。尚、deinstallコマンド実行時listenerとoracle instanceは起動させたままで試してみた。(起動していなくてもいいのだがどうなるか試してみたかったので。)
また例によってLinuxへはMacOS XのTerminalからssh接続して実行。

[oracle@corydoras oracle11gr2]$ ll
合計 32
drwxr-xr-x 8 oracle oinstall 4096 8月 19 04:54 database
drwxr-xr-x 19 oracle oinstall 4096 8月 19 04:51 deinstall
drwxr-xr-x 6 oracle oinstall 4096 8月 19 04:53 examples
drwxr-xr-x 7 oracle oinstall 4096 8月 19 04:58 gateways
[oracle@corydoras oracle11gr2]$ cd deinstall
[oracle@corydoras deinstall]$ deinstall -home /u01/app/oracle/product/11.2.0/dbhome_1
ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1
Location of logs /u01/app/oraInventory/logs/

############ ORACLE DEINSTALL & DECONFIG TOOL START ############


######################## CHECK OPERATION START ########################
インストールの構成確認の開始


Oracleホームの場所が存在するかどうかを確認しています /u01/app/oracle/product/11.2.0/dbhome_1
選択された削除対象のOracleホームのタイプ: SIDB
選択された削除対象のOracleベース: /u01/app/oracle
中央インベントリの場所が存在するかどうかを確認しています /u01/app/oraInventory

インストールの構成確認の終了


ネットワーク構成チェック構成START

ネットワーク構成解除トレース・ファイルの場所: /u01/app/oraInventory/logs/netdc_check46396.log

構成解除するすべての単一インスタンス・リスナーを指定してください[LISTENER]:

ネットワーク構成チェック構成END

データベース・チェック構成START

データベース構成解除トレース・ファイルの場所: /u01/app/oraInventory/logs/databasedc_check46397.log

値のリストを入力として指定する場合、セパレータとしてカンマを使用してください

このOracleホームで構成されているデータベース名のリストを指定してください []: glassfish

###### データベース'glassfish' ######

単一インスタンス・データベース
データベースの診断先の場所: /u01/app/oracle/diag/rdbms/glassfish
データベースによって使用される記憶域タイプ: FS
データベース・ファイルの場所: /u01/app/oracle/oradata/glassfish,/u01/app/oracle/flash_recovery_area/glassfish
フラッシュ・リカバリ領域の場所: /u01/app/oracle/flash_recovery_area/GLASSFISH
データベースのspfileの場所: /u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfileglassfish.ora

データベースglassfishの詳細は自動的に検出されました。glassfishデータベースの詳細を変更しますか。 [n]:

データベース・チェック構成END

Enterprise Manager Configuration Assistant START

EMCA構成解除トレース・ファイルの場所: /u01/app/oraInventory/logs/emcadc_check.log

データベースglassfishの構成を確認しています
Enterprise Manager Configuration Assistant END
Oracle Configuration Manager check START
OCM check log file location : /u01/app/oraInventory/logs//ocm_check3797.log
Oracle Configuration Manager check END

######################### CHECK OPERATION END #########################


####################### CHECK OPERATION SUMMARY #######################
選択された削除対象のOracleホーム: /u01/app/oracle/product/11.2.0/dbhome_1
Oracleホームが登録されているインベントリの場所: /u01/app/oraInventory
次の単一インスタンス・リスナーが構成解除されます: LISTENER
次のデータベースが構成解除対象として選択されました: glassfish
一意のデータベース名: glassfish
使用済記憶域: FS
次のデータベースのEnterprise Managerの構成を更新しますか: glassfish
更新するEnterprise Manager ASMターゲットはありません
移行するEnterprise Managerのリスナー・ターゲットはありません
Checking the config status for CCR
Oracle Home exists with CCR directory, but CCR is not configured
CCR check is finished
続行しますか (y - はい、n - いいえ)[n]: y
このセッションのログは/u01/app/oraInventory/logs/deinstall_deconfig2009-09-10_01-48-33-AM.outに書き込まれます
このセッションのすべてのエラー・メッセージは/u01/app/oraInventory/logs/deinstall_deconfig2009-09-10_01-48-33-AM.errに書き込まれます

######################## CLEAN OPERATION START ########################

Enterprise Manager Configuration Assistant START

EMCA構成解除トレース・ファイルの場所: /u01/app/oraInventory/logs/emcadc_clean.log

データベースglassfishのEnterprise Manager Database Controlの構成の更新
Enterprise Manager ASMターゲットを更新しています(ある場合)
Enterprise Managerのリスナー・ターゲットを更新しています(ある場合)
Enterprise Manager Configuration Assistant END
データベース構成解除トレース・ファイルの場所: /u01/app/oraInventory/logs/databasedc_clean46398.log
データベース・クリーンアップ構成START glassfish
この操作には数分かかります。

データベース・クリーンアップ構成END glassfish

ネットワーク構成クリーニング構成START

ネットワーク構成解除トレース・ファイルの場所: /u01/app/oraInventory/logs/netdc_clean46399.log

単一インスタンス・リスナーの構成解除: LISTENER

リスナーの構成解除: LISTENER
リスナーを停止しています: LISTENER
リスナーの停止に成功しました。
リスナーを削除しています: LISTENER
リスナーは正常に削除されました。
リスナーは正常に構成解除されました。

ネーミング・メソッド構成ファイルの構成解除中です...
ネーミング・メソッド構成ファイルが正常に構成解除されました。

バックアップ・ファイルの構成解除中です...
バックアップ・ファイルが正常に構成解除されました。

ネットワーク構成が正常にクリーンアップされました。

ネットワーク構成クリーニング構成END

Oracle Configuration Manager clean START
OCM clean log file location : /u01/app/oraInventory/logs//ocm_clean3797.log
Oracle Configuration Manager clean END
Oracle Universal Installerクリーンアップの開始

Oracleホーム'/u01/app/oracle/product/11.2.0/dbhome_1'をローカル・ノードの中央インベントリからデタッチします : 終了

ローカル・ノードのディレクトリ'/u01/app/oracle/product/11.2.0/dbhome_1'を削除します : 終了

ローカル・ノード上でOracleベース・ディレクトリ'/u01/app/oracle'は削除されません。ディレクトリはOracleホーム'/u01/app/oracle/product/11.1.0/db_1'で使用中です。

Oracle Universal Installerのクリーンアップが成功しました。

Oracle Universal Installerクリーンアップの終了


Oracleインストール・クリーンアップの開始

インストールのクリーンアップ操作により、ノードcorydorasの一時ディレクトリ/tmp/installを削除しています

Oracleインストール・クリーンアップの終了

デフォルト・プロパティ・ファイル/home/oracle/Desktop/oracle11gr2/deinstall/response/deinstall_OraDb11g_home2.rspを/home/oracle/Desktop/oracle11gr2/deinstall/response/deinstall_OraDb11g_home2.rsp0として移動しました

######################### CLEAN OPERATION END #########################


####################### CLEAN OPERATION SUMMARY #######################
データベースglassfishのEnterprise Managerの構成を更新しました
次のデータベース・インスタンスが正常に構成解除されました: glassfish
次の単一インスタンス・リスナーが正常に構成解除されました: LISTENER
Cleaning the config for CCR
As CCR is not configured, so skipping the cleaning of CCR configuration
CCR clean is finished
Oracleホーム'/u01/app/oracle/product/11.2.0/dbhome_1'がローカル・ノードの中央インベントリから正常にデタッチされました。
ローカル・ノードのディレクトリ'/u01/app/oracle/product/11.2.0/dbhome_1'が正常に削除されました。
Oracle Universal Installerのクリーンアップが成功しました。

Oracleインストールにより、一時ディレクトリが正常にクリーンアップされました。
#######################################################################


############# ORACLE DEINSTALL & DECONFIG TOOL END #############

[oracle@corydoras deinstall]$

でもOUIで削除していたものをなんでcommandとして分離させたのだろう。

マニュアルには理由は書いてくれないので想像するしかないけど。。white paperとか見れば書いてるのかな?

command化されたことによりどんな場面でうれしくなるんだろう。。。。

今回使った感想は、OUIから分離されcommand化されたことによるうれしさは無かったが、OUIの削除ボタンよりは分かりやすいかも。。。

でもやっぱり、deinstall commandってどんな時にうれしく感じるんだろう。。。command化されて良かった!と感じる場面って。

| | コメント (0) | トラックバック (0)

2009年9月 7日 (月)

OUIやDBCAではrawデバイスを利用できないのかOracle11g R2(備忘録)

Oracle Database 11g release 2からOUIやDBCAではrawデバイスへのデータファイル作成はできないとあるね。

2

ただし・・・

「4.4 Support for Raw Devices」にはコマンドレベルなら作成できると記載されている要注意!!!!

4

| | コメント (0) | トラックバック (0)