|
もんじゅ会議室 >
せんちゃん専用掲示板 >
|
|
(回答先: 第10回 プロファイル （パスワード・セキュリティとリソースの管理） 投稿者 とく 日時 2003 年 9 月 22 日 12:54:53)
第12回 記憶構造
http://www.seshop.com/se/edu/shikaku/omo/miti/miti_gold12.asp?educat=gold2
（本物ページには画像がある）
このカテゴリで押さえておくポイントは次の2つと考えれば良いでしょう。
記憶領域管理パラメタ
・PCTFREE
・PCTUSED
・INITRANS（ブロックあたりの同時トランザクション初期数）
・MAXTRANS（ブロックあたりの同時トランザクション最大数）
領域に関するデータディクショナリ
・DBA_FREE_SPACE（表領域内の空き領域）
・DBA_SEGMENTS
・DBA_EXTENTS
1.記憶領域管理パラメタ（PCTFREEとPCTUSED）
Oracleで「PCT」ときたら、「PerCenTage（%）」のことです。FREE（空き）の割合（P
CT）です。何のために空けておくのかが重要です。「更新（UPDATE）のため」に空け
ておくのです。パフォーマンスチューニングを勉強し始めると、わかってくることな
のですが、データブロックの中に沢山レコードを詰め込んでいたほうが、効率的なん
です。だって、OracleのI/Oの最小単位はデータブロックですよね。1回の労力で沢山
のレコードを読み込めたほうが、同じデータ数を読み込まなければいけない場合I/O
の回数が少なくてすむでしょ。だからぎっしりとレコードを詰め込む・・・しかし、
社員の名前が「林」から「佐々木」に変わったとします。つまり「2バイト」だった
値が「6バイト」に伸びてしまったということです。ところが、ぎっしりと詰め込ん
でしまったものだから、「林」を「佐々木」にするだけの「空き」領域がない！どう
しよう、「林」のレコードは他のブロックに移行してもらおう・・・ということにな
ります。ところが、OracleはINSERTしたときのブロックを覚えているもんだから、「林」
のレコードを検索すると、移行前のブロックを読みに行ってしまう。そして、そのブ
ロックに移行先が書いてあるので改めて、移行先のブロックを読みに行く。えっつ？
2つのブロックを読まなきゃいけないの？！I/Oを少なくしようと思って、ぎっしり詰
め込んだのが裏目に出ちゃった！！という結果になるのです。そんなことになるんだ
ったら、最初からUPDATEによって、値が伸びることを考慮した「空き」を設けておけ
ばいいですよね。「どのくらい空けておく？」「20バイトのレコードが4バイト伸び
て24バイトになるから、う〜ん20%位。」「じゃあ、更新によってレコードが長くな
ることを考慮してあけておくためのPCTFREEは、20ね。」となるのです。
PCTUSEDの「USED」は「使用」ですよね。つまりPCTUSEDは使用率です。
Oracleは基本的には、INSERTするときに、DELETEしたことによって空いた領域（ブロ
ック）を使いに行ったりはしません。だって、あっちが空いた、こっちが空いたって
離れたブロックをあっち書いたりこっち書いたりしていたら、時間がかかってしまう
ではないですか。それより連続した領域を使った方が書込みは効率がいいですよね。
だからといって、DELETEによってガラガラに空いてしまったブロックをいつまでも
再利用しないでおくのももったいない。せっかくブロックを読み込んだのにほとんど
空っぽの状態だったなんて困りものです。では、いつ再利用しますか？1件削除され
たら、すぐにその空いた領域を次のINSERTで使いに行きますか？それとも、半分くら
いまで削除されたらにしますか？皆さんが決めてください。それが、PCTUSEDです。
「PCTUSED 90」と設定したら、「使用率は90%を維持してね。もし、DELETEによって
90%を下回ることになったら次のINSERTでその空いた領域を使って90%以上使用してい
る状態にして頂戴。」ということです。「PCTUSED 40」と設定したら、「DELETEに
よって領域が空いたの？いいわ、しばらくそのままにしておいて。でも半分以上空い
たままというのも無駄だから、せめて使用率が40%を下回ったら新しいレコードを書
き込んで頂戴。」ということになるのです。
はい、ではわかったところで・・・結論PCTFREEが大きい/小さいということはどうい
うことを意味するんですか?そのメリット＆デメリットは何ですか？
PCTFREEが大きい
・更新によってレコード長が長くなる場合に向いている（移行行を防ぐことができる）
→UPDATEが行われない表には大きな値を設定する必要は無い。
・ブロックに余裕がある（空いている領域が多い→レコードは多く格納されていない）
→全件検索が中心の表には不利（1ブロックあたりのレコード数が少ないということは同じ件数でも多くのブロックが必要）
PCTUSEDが大きい
・ブロックが満杯の状態を常に維持できる
→全件検索には有利
・INSERTのパフォーマンスは劣化する可能性あり
→もともとDELETEされることがないなら、関係ない
データブロック
2.領域に関するデータディクショナリ
早速、検索結果を見てみましょう。
SQL> select SEGMENT_NAME,SEGMENT_TYPE,TABLESPACE_NAME,EXTENTS
2 from DBA_SEGMENTS
3 where OWNER = 'SCOTT'
4 and SEGMENT_NAME in ('EMP' , 'DEPT');
SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENTS
--------------- --------------- --------------- ----------
DEPT TABLE SYSTEM 1
EMP TABLE DRSYS 14
どのくらい領域が必要か、あらかじめ計算もせずに大量のデータをロードしたけれど、
エクステントは拡張していないかしら？と、確認したいならDBA_SEGMENTS。EMP表（セ
グメント）は、14個のエクステントに別れて入ってます。ということがわかります。
それで、その14個のエクステントは、それぞれどこにどの位の大きさなんだろう？
ということまで調べたければ、DBA_EXTENTS。DBA_EXTENTSは、詳しくわかって便利そ
うに思えますが、エクステントが100個もあるセグメントだったら、ちょっと検索し
て表示してみる気になりませんよね…だから、「エクステントの個数を調べたい！」
って聞かれたら、私ならDBA_SEGMENTSを検索しましょう！って言っちゃうかな…。
SQL> select SEGMENT_NAME,EXTENT_ID,FILE_ID,BLOCK_ID,BLOCKS
2 from DBA_EXTENTS
3 where OWNER = 'SCOTT' and SEGMENT_NAME = 'EMP';
SEGMENT_NAME EXTENT_ID FILE_ID BLOCK_ID BLOCKS
--------------- ---------- ---------- ---------- ----------
EMP 0 7 490 128
EMP 1 8 2 128
EMP 2 7 618 128
EMP 3 8 130 128
EMP 4 7 746 128
EMP 5 8 258 128
EMP 6 7 874 128
EMP 7 8 386 128
EMP 8 7 1002 128
EMP 9 8 514 128
EMP 10 7 1130 128
EMP 11 8 642 128
EMP 12 7 1258 128
EMP 13 8 770 128
14行が選択されました。
FILE_IDはデータファイルの識別番号、BLOCK_IDはデータファイル内のブロック番号。
そのエクステントの開始ブロック番号です。BLOCKSはブロック数。つまり初期エクス
テント（EXTENT_IDが0）は、7番のデータファイル内の490番のブロックから連続128
ブロック分の領域を使っているということです。EXTENT_IDが1というのは、追加（NE
XT）1つ目を表します。
ちなみに、私のDRSYS表領域は、次の2つのデータファイルから構成されておりました。