株式会社インサイトテクノロジー 発行
http://www.insight-tec.com/jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━Vol.19
☆☆☆ おら！オラ！ Oracle −どっぷり検証生活− ☆☆☆
2000.08.23
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
他ではなかなか得られない、マニュアルを読んでもわからない、
そういったOracleに関する技術情報をお届けするメルマガです。
実際に検証した結果も交えてお伝えしていきます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
<<目次>>
■Oracle検証生活・・・続・INDEXに関する検証 その２
■QAコーナー・・・追加レコード数よりLF_ROWSの値がかなり大きいのは？
■お知らせ・・・○Oracle管理ツール Performance Insight
○無料セミナーのご案内 ○連載情報
○書籍ご予約受付中 ○ＱＡについて
■編集者より
■■注意事項！！■■
本文中にテーブルが含まれていますので、お読みになる際はMSゴシック等、
等幅フォントをお使いただくことをお勧めします。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ Oracle検証生活 ▼━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜続・INDEXに関する検証 その２＞ ペンネーム モンキーターン
--- UPDATEとINDEXの関係 ---
前回のメルマガで INDEXキーを同一の値で UPDATEすると INDEXにどのような
変更が行われたか、わかっていただけたと思う。
今回は、INDEXキーが異なる値で更新された場合の UPDATEと INDEXの関係につ
いて、INDEXを中心に検証を交えながら説明していこう。
--- どっぷり検証生活 START！ ---
今回も前回使用した検証用テーブルと INDEXを使用する。
＜＜＜検証に用いたSQL文＞＞＞
SQL> UPDATE EMP_TEST SET EMPNO = 1111 WHERE EMPNO = 7369 ;
1行が更新されました。
SQL> COMMIT ;
コミットが完了しました。
SQL> ALTER SYSTEM CHECKPOINT ;（alter system権限が必要）
システムが変更されました。
なぜ、CHECKPOINTを発生させたのかは前回のメルマガを参照
＜＜＜BLOCK_DUMPの取得＞＞＞
取得方法は前回のメルマガを参照
＜＜結果＞＞
異なる値（7369⇒1111）で UPDATEする前のINDEX_BLOCK_DUMPの結果
row#0[1879] flag: ----, lock: 0
col 0; len 3; (3): c2 4a 46 --------------→（1）（EMPNO=7369）
col 1; len 6; (6): 02 00 00 03 00 00
row#1[1866] flag: ----, lock: 0
col 0; len 3; (3): c2 4b 64
col 1; len 6; (6): 02 00 00 03 00 01
row#2[1853] flag: ----, lock: 0
col 0; len 3; (3): c2 4c 16
col 1; len 6; (6): 02 00 00 03 00 02
・
・
・
row#12[1724] flag: ----, lock: 0
col 0; len 3; (3): c2 50 03
col 1; len 6; (6): 02 00 00 03 00 0c
row#13[1711] flag: ----, lock: 0 ------------→（2）（row# 13）
col 0; len 3; (3): c2 50 23
col 1; len 6; (6): 02 00 00 03 00 0d
----- end of leaf block dump -----
異なる値（7369⇒1111）で UPDATEした後のINDEX_BLOCK_DUMPの結果
row#0[1698] flag: ----, lock: 2
col 0; len 3; (3): c2 0c 0c -------------→（3）（EMPNO=1111）
col 1; len 6; (6): 02 00 00 03 00 00
row#1[1879] flag: --D-, lock: 2 -------------→（4）（flag=D）
col 0; len 3; (3): c2 4a 46 -------------→（5）（EMPNO=7369）
col 1; len 6; (6): 02 00 00 03 00 00
row#2[1866] flag: ----, lock: 0
col 0; len 3; (3): c2 4b 64
col 1; len 6; (6): 02 00 00 03 00 01
・
・
・
row#13[1724] flag: ----, lock: 0
col 0; len 3; (3): c2 50 03
col 1; len 6; (6): 02 00 00 03 00 0c
row#14[1711] flag: ----, lock: 0 ------------→（6）（rows# 14）
col 0; len 3; (3): c2 50 23
col 1; len 6; (6): 02 00 00 03 00 0d
----- end of leaf block dump -----
ここで注目していただきたいのは、row#と flagである。
row#
（2）UPDATE前 row#0 〜 row#13（14レコード存在していることを意味している）
（6）UPDATE後 row#0 〜 row#14（15レコード存在していることを意味している）
UPDATE後、row#が増えているのが確認できる。
では、UPDATE前とUPDATE後に何が増えたのかを見ていこう。
EMPNO＝7369（1）を EMPNO＝1111（3）に UPDATEを行った。しかし、UPDATE
したはずの EMPNO＝7369（5）が flagに D（4）を立てて残っているのが確認
できる。
また、INDEXは INDEXキーを SORTした状態でデータを保持しているが、実デー
タが格納されているテーブルには存在しないデータ（削除されたため）も、IN
DEX内では flagに Dを立てた上で、SORTの対象となっていることが確認できた。
テーブル中のデータを削除したとしても、INDEXの構造は変わることなく、実際
には Leaf_BLOCK中にデータが flag = D として管理され残ったままになるので
ある。このデータ（flag = Dと管理されたデータ）も、レンジ検索時には検索
の対象となってしまうため、パフォーマンスに影響を及ぼしてしまうのである。
10万件のデータ中 9万件を削除したような場合、空のLeaf_BLOCKに I／Oが発生
していたかのように見えていたが、実は Leaf_BLOCK中にデータが残っていたの
である。
なぜ、このような処理を施すのであろうか？
それは、INDEXの構造上の問題である。削除されたからといって、そのLeaf_BLOCK
を切り離すのではなく、再度同じ値が入ってきたときのために使う領域
（Place Holder）として保持していると考えられる。実際に、一度削除した値
を再度入力（INDEXキーが同じ値）した場合、INDEXの構造上の問題で大きな組
み替えが起きていない限り、必ず同じ Leaf_BLOCKに入ることは検証済みである。
次回は、INDEXの情報元である、BLOCK_DUMP、TREEDUMP、INDEX_STATSビューの
データの整合性について検証してみる。
＜＜＜余談＞＞＞
INDEXをより活用する方法としてオプティマイザ・ヒントがある。INDEXは作っ
ただけでは何の意味もない。使わせてなんぼである。SQL文をコーディングする
ときに「オプティマイザに自分の意志を伝える」という機能を使わない手はな
い。
宝の持ち腐れならぬ INDEXの持ち腐れにならないように！
サザン凱旋 茅ヶ崎にて
〜続・INDEXに関する検証 その２〜
by モンキーターン
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ ＱＡコーナー ▼━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
☆★Question１★☆
>毎日１回、同じテーブルに全件削除した後に1,000〜3,000件データを追加して
>います。INDEXを ANALYZEして INDEX_STATS表を調べると、追加レコード件数よ
>り LF_ROWSの値がかなり大きくなっています。どうしてこんなことになるので
>しょうか？
☆★Answer＆Advice★☆
「メルマガ Vol．14・15のQA」と今回のメルマガをご覧いただければ、テーブ
ルのデータを削除したときの INDEXの動きがわかっていただけたと思います。
ご質問のような現象が起きるのは、削除された INDEXキーはデータを削除する
のではなく削除データを flagで管理する（全件削除も）ために Leaf_BLOCKの
行数はテーブルの実レコード件数よりも値が大きくなります。
1つの目安として追加レコード件数より LF_ROWSの値が大きくなればなるほど、
INDEXが歪んでいるかもしれないということは言えると思います。当然、パフォ
ーマンスに影響を及ぼします。
対処方法といたしましては、「メルマガ Vol．15のQA」をご覧ください。
INDEX_STATS表の LF_ROWSは、実データ＋flagに Dとついたデータ、DEL_LF_R
OWSは、flagに Dとついたデータを表しています。
試しに、LF_ROWS 引く DEL_LF_ROWSしてみてください。追加レコード件数と等
しくなるはずです。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ 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関連業務に携わる方、是非ご一読ください。
９月号が発売中です。
http://www.insight-tec.com/jp/topics/magazine.html
上記のURLで各回のタイトルがご覧になれます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ 書籍ご予約受付中 ▼━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜送料無料でお届けします＞
「Oracle8 プロフェッショナルテクニック」は大好評につき、現在在庫切れと
なっており、ご注文いただいた皆様にはたいへんご迷惑をおかけしております。
まもなく入荷する予定ですので、今しばらくお待ちください。
これからご注文いただく方も、入荷次第発送させていただくということで
予約注文を受付けておりますのでよろしくお願い申し上げます。
また弊社のHPよりお申し込みいただいた方に限り、送料無料でお届けします。
専門書としては異例の速さで増刷が決定するほどの好評をいただい
ている「Oracle8 プロフェッショナルテクニック」をぜひご活用ください。
http://www.insight-tec.com/jp/topics/books.html
ホームページより受付中です。お早めに！
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ ＱＡについて ▼━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜皆様からのＱＡを受付けております＞
皆様のＱＡにはできるだけ、お答えしたいと思っています。
すべてのＱＡにお答えすることはできないかもしれませんが、
適宜メルマガ内でとりあげていく予定ですので、是非ＱＡをお寄せください。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼ 編集者より ▼━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
この夏、はじめて帰省ラッシュにあたってしまった。今までは夜中に走って
いたこともあって、たいした渋滞にはハマらなかったんだけど、今回はすご
かった。サービスエリアに入ったが最後。サービスエリアの駐車場から本線
に出るまでに1時間以上かかってしまった。もう２度とあんな思いはしたくな
いです。 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