株式会社インサイトテクノロジー 発行
http://www.insight-tec.com/jp/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Vol.20
☆☆☆ おら！オラ！ Oracle −どっぷり検証生活− ☆☆☆
2000.08.30
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
他ではなかなか得られない、マニュアルを読んでもわからない、
そういったOracleに関する技術情報をお届けするメルマガです。
実際に検証した結果も交えてお伝えしていきます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
<<目次>>
■Oracle検証生活・・・続・INDEXに関する検証 その３
■QAコーナー・・・更新処理中にREBUILDはできるの？
■お知らせ・・・○Oracle管理ツール Performance Insight
○無料セミナーのご案内 ○連載情報
○書籍ご予約受付中 ○ＱＡについて
■編集者より
■■注意事項！！■■
本文中にテーブルが含まれていますので、お読みになる際はMSゴシック等、
等幅フォントをお使いただくことをお勧めします。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ Oracle検証生活 ▼━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜続・INDEXに関する検証 その３＞ ペンネーム モンキーターン
前回までの検証で、INDEXは削除されたデータを、flagを用いて管理している
ことが分かった。
では、いつまで管理し続けるのであろうか？
結論から述べると、flag = Dで管理されているキーが存在する Leaf_BLOCKに、
PHYSICAL READまたは PHYSICAL WRITEが発生すると、flag = Dで管理されてい
る INDEXキーは開放されるという結果を得た。
今回は、INDEXに対して PHYSICAL READまたは PHYSICAL WRITEを発生させずに、
INDEXの主な情報元である、TREEDUMP、BLOCK_DUMP、INDEX_STATSビュー それぞ
れの内容を確認してみよう。上記 3つの INDEX情報が、それぞれどのように関
連しているかを中心に検証を交えながら説明してこう。
次回、INDEXに対して PHYSICAL READまたは PHYSICAL WRITEを発生させて、同
様の検証を行ない、今回との違いを明らかにする。
--- どっぷり検証生活 START！ ---
＜＜＜検証用テーブルとINDEXの作成＞＞＞
1．ユーザー SCOTTで EMP_TESTと言うデータ件数が10万件のテーブルを作成
（中身は EMP表と同じ）
2．表の項目 EMPNOに対して、EMP_TEST_INDEXと言う INDEXを作成
（INDEXは別の表領域に作成）
＜＜＜検証に用いたSQL文＞＞＞
SQL> DELETE FROM EMP_TEST WHERE ROWNUM < 90001 ;
90000行が削除されました。
SQL> COMMIT ;
コミットが完了しました。
＜＜＜INDEX情報の取得方法＞＞＞
TREEDUMP、BLOCK_DUMP、INDEX_STATSの情報を取得する。
これらの情報の取得方法を、以下のURLに示す。
TREEDUMP ⇒ http://www.insight-tec.com/html/reference/ref20a.html
BLOCK_DUMP ⇒ http://www.insight-tec.com/html/reference/ref20b.html
INDEX_STATS ⇒ http://www.insight-tec.com/html/reference/ref20c.html
＜＜＜結果＞＞＞
＜＜DELETE直後のINDEX情報 ＜TREEDUMP＞＜BLOCK_DUMP＞＜INDEX_STATS＞ ＞＞
＜TREEDUMP＞
----- begin tree dump
branch: 0x2400003 37748739 (0: nrow: 7, level: 2)
branch: 0x24000aa 37748906 (-1: nrow: 165, level: 1)
leaf: 0x2400004 37748740 (-1: nrow: 116 rrow: 0)------→（1）
leaf: 0x2400005 37748741 (0: nrow: 110 rrow: 0)
leaf: 0x2400006 37748742 (1: nrow: 110 rrow: 0)
・
中略
・
leaf: 0x240036a 37749610 (67: nrow: 103 rrow: 0)
leaf: 0x240036b 37749611 (68: nrow: 103 rrow: 0)
leaf: 0x240036c 37749612 (69: nrow: 103 rrow: 46)
leaf: 0x240036d 37749613 (70: nrow: 103 rrow: 103)
leaf: 0x240036e 37749614 (71: nrow: 103 rrow: 103)
・
中略
・
leaf: 0x24003cd 37749709 (7: nrow: 103 rrow: 103)
leaf: 0x24003ce 37749710 (8: nrow: 66 rrow: 66)
----- end tree dump
nrowsは、削除されたことによって、flag = Dで管理されることになったキー
の数と、flag = Dではないキーの数を合計したものである。つまり、削除の
有無に関わらず、その Leaf_BLOCK中に存在する INDEXキーの数を表したもの
である。（以下 flag = Dではないキーを「有効」という言葉で表わす。）
rrowsは、その Leaf_BLOCK中に存在する flag = Dではない有効な INDEXキー
の数のみを表したものである。
簡単に表すと
nrowsは、flag = Dのデータ数＋有効データ数
rrowsは、有効データ数
である。
＜BLOCK_DUMP＞
以下の BLOCK_DUMPは、＜TREEDUMP＞の（1）で示しているLeaf_BLOCKのDUMPである。
row#0[1880] flag: --D-, lock: 2
col 0; len 2; (2): c1 02
col 1; len 6; (6): 02 00 00 03 00 00
row#1[1868] flag: --D-, lock: 2
col 0; len 2; (2): c1 03
col 1; len 6; (6): 02 00 00 03 00 01
・
・
・
row#114[497] flag: --D-, lock: 2
col 0; len 3; (3): c2 02 10
col 1; len 6; (6): 02 00 00 05 00 1e
row#115[484] flag: --D-, lock: 2
col 0; len 3; (3): c2 02 11
col 1; len 6; (6): 02 00 00 05 00 1f
----- end of leaf block dump -----
ブロック内のINDEXキーがすべて削除されたことによって、すべてのキーが f
lag = Dで管理されている様子が伺える。また、このBLOCK_DUMPの flag = Dの
数は、116（row#0〜row#115）で有効データ数は 0である。これは、TREEDUMP
の nrows = 116 と rrows = 0の数と一致する。
＜INDEX_STATS＞
SQL> analyze index emp_test_index validate structure ;
索引が分析されました。
SQL> select name , lf_rows , del_lf_rows , br_rows , blocks
from index_stats ;
NAME LF_ROWS DEL_LF_ROWS BR_ROWS BLOCKS
--------------- --------- ----------- --------- --------
EMP_TEST_INDEX 100000 90000 964 1430
10万件存在する INDEXキーのうち、9万件が削除されたことを意味している。
削除されたことにより、有効な INDEXキーは1万件しか存在しないが、実際に
は、削除されたキーを flag = Dで管理するだけで、インデックスの構造は変
わらず、削除前の10万件がそのまま残っている。
DEL_LF_ROWSは、flag = Dのデータ数
LF_ROWSは、flag = Dのデータ数＋有効データ数を表している。
flag = Dで管理されていない、有効な INDEXキーの数を求めるには、LF_ROWS
から DEL_LF_ROWSを差し引いてあげればよい。
「 LF_ROWS = 有効な INDEXキーの数 」と勘違いされがちなので、
注意が必要である。
夏の暮れ 茅ヶ崎にて
〜続・INDEXに関する検証 その３〜
by モンキーターン
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ ＱＡコーナー ▼━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
☆★Question１★☆
＞INDEXのREBILUDについて教えてください。
＞表に更新処理（INSERT,UPDATE,DELETE等）を実行中にINDEXのREBILUDは可能
＞でしょうか？
＞その際、更新処理が待たされたりしないのでしょうか？
☆★Answer＆Advice★☆
表に更新処理（INSERT,UPDATE,DELETE等）を実行中にその表のINDEXのREBILUD
をするとREBILUD処理は以下のようなエラーが発生します。DLL文が表ロックを
取得できないときは、NOWAIT指定つまり処理を待たずにエラーを返します。
SQL> ALTER INDEX TEST REBUILD ;
エラー行: 1: エラーが発生しました。
ORA-00054: リソース・ビジー、NOWAITが指定されていました。
逆に、INDEXの REBILUD最中にその INDEXがはってある表に更新処理を行なうと
更新処理は索引作成(REBILUD)処理が終了するまで待たされます。
Oracle8i から索引作成（create index, alter index rebuild）時に「onlin
e」キーワードが指定できるようになりました。これは、表ロックではなく行
ロックを取得するので、索引作成中でもロック待ちせずに、表に更新処理を実
行することが可能になります。また、表に更新処理を行なっている最中でも索
引作成ができます。
「online」キーワード指定の例
SQL> CREATE INDEX EMP_NAME ON EMP(ENAME) ONLINE ;
SQL> ALTER INDEX EMP_NAME REBUILD ONLINE ;
但し、ここで１つ注意しなければならないことがあります。
ユーザーが REBUILD中の INDEXキーを含んだ UPDATEを行ない COMMITし忘れて
いたとします。その状態で、上記の「online」で索引作成を行なうと、UPDATE
で掛けられたロックが解除されない限りつまり、ROLLBACKまたはCOMMITがされ
ない限り索引作成処理は終わりません。
ゆえに、「ONLINE」を使用するにしても、運用サイトの特徴をよく考えて実行
させないといけません。
「online」での索引作成処理の内部の動きは別の機会で細かく説明しようと思
います。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ 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
ホームページより受付中です。お早めに！
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ ＱＡについて ▼━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜皆様からのＱＡを受付けております＞
皆様のＱＡにはできるだけ、お答えしたいと思っています。
すべてのＱＡにお答えすることはできないかもしれませんが、
適宜メルマガ内でとりあげていく予定ですので、是非ＱＡをお寄せください。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ 編集者より ▼━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ようやく20号を迎えました。これからも応援してくださいね。
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