株式会社インサイトテクノロジー 発行
http://www.insight-tec.com/jp/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Vol.22
☆☆☆ おら！オラ！ Oracle −どっぷり検証生活− ☆☆☆
2000.09.13
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
他ではなかなか得られない、マニュアルを読んでもわからない、
そういったOracleに関する技術情報をお届けするメルマガです。
実際に検証した結果も交えてお伝えしていきます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┏━━━━◆ プログラマ待望の言語SQeeL、まもなく登場！◆━━━━┓
★★ ┏━━━━━━━━━━━━━━━━━━━━━━━┓ ★★
★★ ┃ 手軽に使える、速い、そしてWEBに適した新言語 ┃ ★★
★★ ┃ フリーソフト、SQeeLを是非お試しください。 ┃ ★★
★★ ┃ ダウンロード開始まであと７日！！ ┃ ★★
★★ ┗━━━━━━━━━━━━━━━━━━━━━━━┛ ★★
★★SQeeLに関する詳細は、弊社HPあるいはSQeeLのHPにて紹介中です★★
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
http://www.insight-tec.com/jp/sqeel/sqeel.html
http://www.sqeeL.org
<<目次>>
■Oracle検証生活・・・続・INDEXに関する検証 その５
■お知らせ・・・○Oracle管理ツール Performance Insight
○無料セミナーのご案内 ○連載情報
○書籍ご予約受付中 ○ＱＡについて
■編集者より
■■注意事項！！■■
本文中にテーブルが含まれていますので、お読みになる際はMSゴシック等、
等幅フォントをお使いただくことをお勧めします。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ Oracle検証生活 ▼━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜続・INDEXに関する検証 その５＞ ペンネーム モンキーターン
前回までのメルマガで、大量の削除処理によって INDEX内に空の BLOCKが数多
く発生し、空の BLOCKまでもがアクセスの対象となってしまう原因については
理解していただいたと思う。
今回は、その原因について検証を交えながら説明していこう。
--- どっぷり検証生活 START！ ---
前回のメルマガで、flag = Dで管理（INDEX・キーが削除されると、そのキー自
体は削除されず、flag = Dとして管理される）されている INDEX・キーが開放
される流れを見てきた。
前回の検証テーブル（flag = Dで管理されている INDEX・キーが開放された後）
に対して、INDEXの RANGE検索を実行すると空の BLOCKまでもがアクセスの対象
となってしまう。
なぜ、空の Leaf_BLOCKにアクセスしてしまうのであろうか？
その原因を考えるとき、大切なのは INDEXの構造を把握していることと INDEX
のデータをアクセスするときの流れである。
Leaf_BLOCKがいくら flag = Dで管理されている INDEX・キーを開放して空の
Leaf_BLOCKになったとしても、アクセス管理している Branch_BLOCKや Root_
BLOCKも不要な Leaf_BLOCKデータ（空の Leaf_BLOCKデータ）を開放しないと
意味がないと言うことである。
よって今回は、Branch_BLOCKを中心に見ていこう。
＜＜＜検証用テーブルとINDEXの作成＞＞＞
1．ユーザー SCOTTで EMP_TESTと言うデータ件数が 1万件のテーブルを作成
（中身は EMP表と同じ、ただし EMPNOは ROWNUM順に UPDATEした。）
2．表の項目 EMPNOに対して、EMP_TEST_INDEXと言う INDEXを作成
（INDEXは別の表領域に作成）
＜＜＜結果＞＞＞
＜＜delete前の TREEDUMP・Branch_BLOCK_DUMP＞＞
＜TREEDUMP＞
----- begin tree dump
branch: 0x2400003 37748739 (0: nrow: 91, level: 1)
leaf: 0x2400004 37748740 (-1: nrow: 116 rrow: 116)-----→（1）
leaf: 0x2400005 37748741 (0: nrow: 110 rrow: 110)------→（2）
・
中略
・
leaf: 0x240005d 37748829 (88: nrow: 110 rrow: 110)
leaf: 0x240005e 37748830 (89: nrow: 94 rrow: 94)
----- end tree dump
＜Branch_BLOCK_DUMP＞
Branch block dump
=================
header address 71838788=0x4482c44
kdxcolev 1
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 2
kdxcosdc 0
kdxconro 90
kdxcofbo 208=0xd0
kdxcofeo 1106=0x452
kdxcoavs 898
kdxbrlmc 37748740=0x2400004 -----------------→（3）
kdxbrsno 0
kdxbrbksz 1916
row#0[1907] dba: 37748741=0x2400005 -----------------→（4）
col 0; len 3; (3): c2 02 12
col 1; TERM
row#1[1898] dba: 37748742=0x2400006
col 0; len 3; (3): c2 03 1c
col 1; TERM
・
中略
・
row#88[1115] dba: 37748829=0x240005d
col 0; len 3; (3): c2 62 62
col 1; TERM
row#89[1106] dba: 37748830=0x240005e
col 0; len 3; (3): c2 64 08
col 1; TERM
----- end of branch block dump -----
ここで、Branch_BLOCK_DUMPの見方を簡単に説明する。
まず、見ていただきたいのは＜Branch_BLOCK_DUMP＞の（4）である。これは、
＜TREEDUMP＞の（2）のLeaf_BLOCKの場所を示している。10進数のDBAが同一
ということから判断できる。
＜Branch_BLOCK_DUMP＞の（3）は、（4）以下のINDEX・キー（この例だと（4）
の col 0; c2 02 12(EMPNO＝117）より下の値）は、すべて（3）で指定した Le
af_BLOCKに入りなさいということである。同様にcol 0; c2 02 12(EMPNO＝117）
以上で col 0; len 3; (3): c2 03 1c(EMPNO＝227）より下の値は（4）のLeaf_
BLOCKに入りなさいということを意味している。簡単に言ってしまえば、Branch_
BLOCKは「より下リスト」を持っていて、それを用いてどのLeaf_BLOCKに入るか
を決めているだけである。
＜＜delete直後の TREEDUMP・Branch_BLOCK_DUMP＞＞
＜TREEDUMP＞
----- begin tree dump
branch: 0x2400003 37748739 (0: nrow: 91, level: 1)
leaf: 0x2400004 37748740 (-1: nrow: 116 rrow: 0)
leaf: 0x2400005 37748741 (0: nrow: 110 rrow: 0) ------→（5）
・
中略
・
leaf: 0x240005d 37748829 (88: nrow: 110 rrow: 110)
leaf: 0x240005e 37748830 (89: nrow: 94 rrow: 94)
----- end tree dump
＜Branch_BLOCK_DUMP＞
Branch block dump
=================
header address 71838788=0x4482c44
kdxcolev 1
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 2
kdxcosdc 0
kdxconro 90
kdxcofbo 208=0xd0
kdxcofeo 1106=0x452
kdxcoavs 898
kdxbrlmc 37748740=0x2400004
kdxbrsno 0
kdxbrbksz 1916
row#0[1907] dba: 37748741=0x2400005
col 0; len 3; (3): c2 02 12
col 1; TERM
row#1[1898] dba: 37748742=0x2400006
col 0; len 3; (3): c2 03 1c
col 1; TERM
・
中略
・
row#88[1115] dba: 37748829=0x240005d
col 0; len 3; (3): c2 62 62
col 1; TERM
row#89[1106] dba: 37748830=0x240005e
col 0; len 3; (3): c2 64 08
col 1; TERM
----- end of branch block dump -----
delete直後の TREEDUMPは、delete前の＜TREEDUMP＞（2）の rrows = 110から
delete直後の＜TREEDUMP＞（5）の rrowsが 0になり DELETEされているのが確
認できる。
一方、Branch_BLOCK_DUMPは、delete前の Branch_BLOCK_DUMPと異なる点は見
受けられなかった。
delete処理を実行しても Branch_BLOCK_DUMPの管理は変わらないのである。
＜＜delete後、INDEXの RANGE検索直後の TREEDUMP・Branch_BLOCK_DUMP＞＞
＜TREEDUMP＞
----- begin tree dump
branch: 0x2400003 37748739 (0: nrow: 91, level: 1)
leaf: 0x2400004 37748740 (-1: nrow: 0 rrow: 0)
leaf: 0x2400005 37748741 (0: nrow: 0 rrow: 0) --------→（6）
・
中略
・
leaf: 0x240005d 37748829 (88: nrow: 110 rrow: 110)
leaf: 0x240005e 37748830 (89: nrow: 94 rrow: 94)
----- end tree dump
＜Branch_BLOCK_DUMP＞
Branch block dump
=================
header address 71838788=0x4482c44
kdxcolev 1
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 2
kdxcosdc 0
kdxconro 90
kdxcofbo 208=0xd0
kdxcofeo 1106=0x452
kdxcoavs 898
kdxbrlmc 37748740=0x2400004
kdxbrsno 0
kdxbrbksz 1916
row#0[1907] dba: 37748741=0x2400005
col 0; len 3; (3): c2 02 12
col 1; TERM
row#1[1898] dba: 37748742=0x2400006
col 0; len 3; (3): c2 03 1c
col 1; TERM
・
中略
・
row#88[1115] dba: 37748829=0x240005d
col 0; len 3; (3): c2 62 62
col 1; TERM
row#89[1106] dba: 37748830=0x240005e
col 0; len 3; (3): c2 64 08
col 1; TERM
----- end of branch block dump -----
delete後で INDEXの RANGE検索直後の TREEDUMPは、delete直後の＜TREEDUMP＞
（2）の nrows = 110から delete後で INDEXの RANGE検索直後の＜TREEDUMP＞
（6）の nrowsが 0になり flag = Dで管理されていた INDEX・キーが開放され
ているのが確認できる。ここまでは、以前 行なったLeaf_BLOCKの検証結果と同
じである。
一方、Branch_BLOCK_DUMPは、delete前の Branch_BLOCK_DUMP、delete後の
Branch_BLOCK_DUMPと異なる点は見受けられなかった。
flag = Dで管理されていた INDEX・キーが開放されても Branch_BLOCK_DUMPの
管理はやはり変わらないのである。
今回の結果より、空の Leaf_BLOCKにアクセスしてしまう原因がわかっていた
だいたと思う。
要するに、Leaf_BLOCK内でどのようなことが起きても、アクセス経路を管理し
ているのは Branch_BLOCKなので、空の Leaf_BLOCKだろうが INDEX・キーの入
った Leaf_BLOCKだろうが Branch_BLOCKがその Leaf_BLOCKを管理していれば
検索条件に引っかかるために無駄な I/Oが発生するのである。
次回は、Branch_BLOCKの管理によって、INSERT処理で Leaf分割が多発する現
象を報告する予定である。
冒頭で説明したORACLEと親和性のあるWEBに適した新言語 自社開発フリーソフト
言語「SQeeL」のこともよろしくお願いします！！！！
http://www.insight-tec.com/jp/sqeel/sqeel.html
http://www.sqeeL.org
スコール 茅ヶ崎にて
〜続・INDEXに関する検証 その５〜
by モンキーターン
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ Oracle 管理ツール Performance Insight ▼━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Oracleを知り尽くしたメンバーが開発したOracleパフォーマンス監視ツール
の決定版。それがPerformance Insightです。インサイトテクノロジーの技術
者の知恵とノウハウがここに結集！
パフォーマンス監視だけでなくOracleを使用しているシステムの運用、管理、
そして開発にも役立つ機能がいっぱいです。
詳しくは以下のURLをご覧ください。
http://www.insight-tec.com/jp/products/products.html
また無料で試使用することも可能です。
是非お問い合わせください。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ 無料セミナーのご案内 ▼━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜スキルアップセミナー＞
●実践から学ぶDBチューニング第１回「INDEX利用の落とし穴」
きたる9月29日、上記の無料セミナーが開催されます。
また同時に、Oracleの運用管理ツールとして多くのお客様にご利用いただいて
おりますPerformance Insightの新バージョンのご紹介も行います。
有意義な内容のセミナーに無料で参加できるチャンスをどうぞお見逃しなく。
詳細およびお申し込みは以下のURLにて。
http://www.insight-tec.com/jp/topics/seminar.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ 連載情報 ▼━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜雑誌連載：体験的・DBAのお仕事（DB Magazine（翔泳社）)＞
Oracleのエキスパートとして定評のある弊社のスタッフが執筆しております
連載記事です。Oracle関連業務に携わる方、是非ご一読ください。
10月号が発売中です。
http://www.insight-tec.com/jp/topics/magazine.html
上記のURLで各回のタイトルがご覧になれます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ 書籍ご予約受付中 ▼━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜送料無料でお届けします＞
「Oracle8 プロフェッショナルテクニック」は大好評につき、現在在庫切れと
なっており、ご注文いただいた皆様にはたいへんご迷惑をおかけしております。
まもなく入荷する予定ですので、今しばらくお待ちください。
これからご注文いただく方も、入荷次第発送させていただくということで
予約注文を受付けておりますのでよろしくお願い申し上げます。
また弊社のHPよりお申し込みいただいた方に限り、送料無料でお届けします。
専門書としては異例の速さで増刷が決定するほどの好評をいただい
ている「Oracle8 プロフェッショナルテクニック」をぜひご活用ください。
http://www.insight-tec.com/jp/topics/books.html
ホームページより受付中です。お早めに！
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ ＱＡについて ▼━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜皆様からのＱＡを受付けております＞
皆様のＱＡにはできるだけ、お答えしたいと思っています。
すべてのＱＡにお答えすることはできないかもしれませんが、
適宜メルマガ内でとりあげていく予定ですので、是非ＱＡをお寄せください。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ 編集者より ▼━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
弊社の製品、Performance Insightがいよいよ本格的に海外で販売開始！
それに伴う作業で、社内は大忙し！ちゃむもつけまいもモンキーターンも、
会社に泊まりこみで、みんなナチュラル・ハイになってました。そんな中でも
全国のメルマガファン（？）のために頑張って刊行したこの22号！盛大な拍手
を送ってやってください。 by UA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
登録・解除は以下のURLで行うことができます。
http://www.insight-tec.com/jp/em/mail_magazine.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜おら！オラ！Oracle−どっぷり検証生活−＞
発行／編集：株式会社インサイトテクノロジー
http://www.insight-tec.com/jp
マガジンID：0000030093
本メールマガジンに掲載された記事を許可なく転載することを禁じます。
Copyright (c) 1996-2000, Insight Technology Inc., All rights reserved.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Insight Technology, Inc
Japanese | English