Insight Technology, Inc

インサイトテクノロジー

Japanese | English

株式会社インサイトテクノロジー 発行
http://www.insight-tec.com

・;*;・゜’★,。・*;・゜’♪☆。・;*;゜’♪★。・;*;゜’☆   ●●●●
●                                                      Vol.58 ●●●
●●          おら!オラ!Oracle  −どっぷり検証生活−           ●●
●●●                                         ☆       2001.05.30 ●
●●●●☆。・;*;・゜’★,。・*;・゜’♪☆。・;*;゜’♪★。・;*;゜;♪

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆                   データベース管理を極める13章             ◆
◇                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~            ◇
●≫≫≫≫≫≫≫≫≫≫≫≫ 増刷決定 !!≪≪≪≪≪≪≪≪≪≪≪≪≪●
◇      12月に発売された「極める13章」がついに1万部突破!    ◇
◆          感謝を込めて消費税+送料無料キャンペーン継続!        ◆
◇            今がチャンス!是非この機会をお見逃し無く。          ◇
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

◎●  I┃ N┃ D┃ E┃ X┃!┃◎●
   ━┛━┛━┛━┛━┛━┛
┏━━━━━━━━━━━┓
┃★ Oracle検証生活 ★  ━━━━━━━━━━━━━━━━━━━━━━┓
┣━━━━━━━━━━━┛
┣○ 【 ロ ッ ク に 関 す る 検 証   そ の 5 】
┣━━━━━━━━━━━┓
┃★  製 品 情 報   ★  ━━━━━━━━━━━━━━━━━━━━━…
┣━━━━━━━━━━━┛
┣○ 【 Oracle管理ツール Performance Insight 】
┃    国内3500ライセンスの販売実績を誇る最強のチューニングツール
┃
┣━● 【 Linux版 Performance Insight 】
┃      リリース予定
┃
┣○ 【 SQeeL(スキール)】
┃    WEBに適した新言語 ⇒ SQeeL!(オープンソースのフリーウェア)
┣━━━━━━━━━━━┓
┃★  INFORMATION   ★  ━━━━━━━━━━━━━━━━━━━━━…
┣━━━━━━━━━━━┛
┣○ 【 連載情報 】
┣○ 【 書籍のご案内 】
┣○ 【 QAについて 】
┣○ 【 編集者より 】
┣○ 【 解 除 の 方 法 】
┃  http://www.insight-tec.com/jp/html/ora3/ora3.html
┃  解除手続きは上記のURLよりお願い致します。原則として当方での解除
┃  は行っておりません、ご了承の程お願い申し上げます。
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…
┣○  【 注意事項 】
┃    本文中にテーブルが含まれていますので、お読みになる際はMSゴシッ
┃    ク等、等幅フォントをお使いただくことをお勧めします。
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□■ Oracle検証生活 □■÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
〜ロックに関する検証 その5〜
ペンネーム ちゃむ

前回は、インデックスが作成してあるテーブルに対して更新処理を行ったとき
の、トランザクションロックに関しての検証を行った。
今回からは、ビットマップ・インデックスを作成したテーブルに対して、更新
処理を行なってみる。その時のロックの仕組みを検証する前に、ビットマップ・
インデックスの構造を十分に理解する必要がある。

<B-Treeインデックスとビットマップ・インデックスの構造上の比較>

<B-Treeインデックス>

B-Treeのインデックスの構造は、前回説明した通りである。
B-Treeインデックスが使用されて検索が行われると、該当するキー値が存在す
るリーフブロックが読み込まれ、それが指しているROWIDにより実データにアク
セスする。カーディナリティが高い(値の種類が多い)場合は、非常に有効で、
例えばプライマリキー列によるイコール検索などは抜群に速いことは体感した
ことがあると思う。しかし、カーディナリティが低い場合は、同じ値が複数存
在するので、データをあまり絞り込むことができず、実データのアクセス数が
増えてしまう。このような場合は、全件検索よりも遅い場合もある。

<ビットマップ・インデックス>
ビットマップ・インデックスの構造のイメージ図を以下のURLに示す。

http://www.insight-tec.com/html/reference/ref58.html

実は、ビットマップ・インデックスも、内部的にはB-Treeインデックスのリー
フブロックの中に、上記のURLで示されたイメージ図のような形式で納められて
いる。
したがって、ビットマップ・インデックスもB-Treeインデックスと同様に、
TREEDUMPを取得することができる。

ビットマップ・インデックスは、通常、構造的にB-Treeインデックスよりもデー
タの収納効率が良い。それは、1行ずつにカラム値とROWIDを持っているB-Tree
インデックスと比べて、上記のイメージ図のように、START ROWIDとEND ROWID
の範囲の中で、カラム値に該当するかどうかを「0」と「1」のビットで表現し
ているからだ。

また、ビットマップ・インデックスは、構造上、カラム値のカーディナリティ
が低いほど収納効率が良い。一方のB-Treeインデックスは、カーディナリティ
の違いによって収納効率が変わってくるものではない(あくまでもカラム長の
みで決まる)。

では、この収納効率に関して検証してみよう。

以下の検証では、EMP表を10万件に拡張したT10MAN_COPYというテーブルを元に
する。

**********************************************************************

SQL> DESC t10man_copy

 名前                                           NULL?    型
 ---------------------------------------------- -------- -------------
 EMPNO                                          NOT NULL NUMBER
 ENAME                                                   VARCHAR2(20)
 JOB                                                     VARCHAR2(18)
 MGR                                                     NUMBER(4)
 HIREDATE                                                DATE
 SAL                                                     NUMBER(7,2)
 COMM                                                    NUMBER(7,2)
 DEPTNO                                                  NUMBER(2)

**********************************************************************

EMPNOは、1から100000までの連番である。

これを利用し、カーディナリティ4のMGR列を作ってみよう。
そのために、MOD関数を用いる。MOD(m,n)はmをnで割った余りを返す関数である。
また、カラム長をそろえるため、to_charを使った。

********** MGR列のデータをカーディナリティ4にするためのSQL ***********

SQL> CREATE TABLE T10MAN_COPY_4 AS
     SELECT EMPNO,ENAME,JOB,to_char(mod(EMPNO,4),'0000000') MGR,
            HIREDATE,SAL,COMM,DEPTNO
     FROM T10MAN_ORG ;

表が作成されました。

以下 0000000、0000001、0000002、0000003 が交互に検索される様子

SQL> SELECT MGR FROM T10MAN_COPY_4 WHERE ROWNUM < 10 ;

MGR
--------
 0000001
 0000002
 0000003
 0000000
 0000001
 0000002
 0000003
 0000000
 0000001

**********************************************************************

同様の方法で、MGR列のカーディナリティが100および100000のテーブルを、そ
れぞれT10MAN_COPY_100、T10MAN_COPY_100000という名前で作成する。

それらのテーブルそれぞれに、B-Treeインデックスとビットマップ・インデッ
クスを作成し、使用エクステントや使用ブロックの大きさを調べる。実際に使
用しているエクステントを簡単に調べられるよう、STORAGE句をINITIAL=NEXT=2K、
MAXEXTENTS=UNLIMITED、PCTINCREASE=0に設定してインデックスを作成。

では、結果を見てみよう。

<B-Treeインデックス>

********************** カーディナリティ4の場合 ***********************

SQL> CREATE INDEX BTREE_4 ON T10MAN_COPY_4(MGR)
     STORAGE (INITIAL 2K NEXT 2K PCTINCREASE 0 MAXEXTENTS UNLIMITED) ;

エクステントの大きさを確認する

SQL> SELECT SEGMENT_NAME,BLOCKS,EXTENTS FROM DBA_SEGMENTS
     WHERE SEGMENT_NAME = 'BTREE_4' ;

SEGMENT_NAME            BLOCKS   EXTENTS
-------------------- --------- ---------
BTREE_4                   1242      1233

**********************************************************************



********************* カーディナリティ100の場合 **********************

SQL> CREATE INDEX BTREE_100 ON T10MAN_COPY_100(MGR)
     STORAGE (INITIAL 2K NEXT 2K PCTINCREASE 0 MAXEXTENTS UNLIMITED) ;

SQL> SELECT SEGMENT_NAME,BLOCKS,EXTENTS FROM DBA_SEGMENTS
     WHERE SEGMENT_NAME = 'BTREE_100' ;

SEGMENT_NAME            BLOCKS   EXTENTS
-------------------- --------- ---------
BTREE_100                 1240      1235

**********************************************************************



******************** カーディナリティ100000の場合 ********************

SQL> CREATE INDEX BTREE_100000 ON T10MAN_COPY_100000(MGR)
     STORAGE (INITIAL 2K NEXT 2K PCTINCREASE 0 MAXEXTENTS UNLIMITED) ;

SQL> SELECT SEGMENT_NAME,BLOCKS,EXTENTS FROM DBA_SEGMENTS
     WHERE SEGMENT_NAME = 'BTREE_100000' ;

SEGMENT_NAME            BLOCKS   EXTENTS
-------------------- --------- ---------
BTREE_100000              1238      1237

**********************************************************************

カラム長が同じなので、各インデックスの大きさには殆ど差がなかった。これ
は、値とROWIDをペアで持つというB*Treeインデックスの構造を理解していれば、
ある程度は予想できた結果であろう。
それぞれのEXTENTS数の若干の違いは、ブランチブロック数の違いである。また、
INITIAL=NEXT=2K、PCTINCREASE=0で作成しているので、通常は、カーディナリ
ティ100000の場合のように、EXTENTSの値 = BLOCKSの値 + 1ブロック(セグメ
ントヘッダー分)になるはずであるが、他の場合だと当てはまらない。
これは、フラグメントを抑えるための、「5ブロック以下のフリーブロックを残
さない動き」に関係する。詳しくは、バックナンバーにある「フリーブロック
の検証」をじっくり読み返してほしい。

<ビットマップ・インデックス>

********************** カーディナリティ4の場合 ***********************

SQL> CREATE BITMAP INDEX BITMAP_4 ON T10MAN_COPY_4(MGR)
     STORAGE (INITIAL 2K NEXT 2K PCTINCREASE 0 MAXEXTENTS UNLIMITED) ;

SQL> SELECT SEGMENT_NAME,BLOCKS,EXTENTS FROM DBA_SEGMENTS
     WHERE SEGMENT_NAME = 'BITMAP_4' ;

SEGMENT_NAME            BLOCKS   EXTENTS
-------------------- --------- ---------
BITMAP_4                    90        89

**********************************************************************



********************* カーディナリティ100の場合 **********************

SQL> CREATE BITMAP INDEX BITMAP_100 ON T10MAN_COPY_100(MGR)
     STORAGE (INITIAL 2K NEXT 2K PCTINCREASE 0 MAXEXTENTS UNLIMITED) ;

SQL> SELECT SEGMENT_NAME,BLOCKS,EXTENTS FROM DBA_SEGMENTS
     WHERE SEGMENT_NAME = 'BITMAP_100' ;

SEGMENT_NAME            BLOCKS   EXTENTS
-------------------- --------- ---------
BITMAP_100                 205       204

**********************************************************************



******************** カーディナリティ100000の場合 ********************

SQL> CREATE BITMAP INDEX BITMAP_100000 ON T10MAN_COPY_100000(MGR)
     STORAGE (INITIAL 2K NEXT 2K PCTINCREASE 0 MAXEXTENTS UNLIMITED) ;

SQL> SELECT SEGMENT_NAME,BLOCKS,EXTENTS FROM DBA_SEGMENTS
     WHERE SEGMENT_NAME = 'BITMAP_100000' ;

SEGMENT_NAME            BLOCKS   EXTENTS
-------------------- --------- ---------
BITMAP_100000             1779      1639

**********************************************************************

ビットマップ・インデックスは、B*Treeインデックスとは異なり、カーディナ
リティが低ければ低いほど、格納スペースが小さくて済む。裏を返せば、カー
ディナリティが高ければ高いほど、その分ビットマップ・セグメントが必要と
する領域が大きくなってしまうと言えよう。
このことが理由で、カーディナリティが100000の場合のビットマップ・インデッ
クスは、B*Treeインデックスの格納スペースよりも多くの領域を必要としてし
まった。

これらの検証結果を基に、以下に特徴をまとめてみた。

1.
ビットマップ・インデックスは、カーディナリティが低いほど収納効率が良い
ので、カーディナリティが低い列の値でもパフォーマンス上の効果が得られる
可能性がある。しかし、例えば、性別を表わすカラムに、均等に「男性」と
「女性」が格納してある場合、それだけでWHERE句で性別 = '男性'のように絞っ
たとしても、検索は速くならないであろう。確かに、ビットマップ・インデッ
クス自体のアクセスは速くなるが、そこから取得したROWIDを基に、テーブルに
対して全体の50%ものデータを取得しに行ってしまうからである。

2.
カーディナリティが非常に高い(主キーに相当するようなカラム)と、かえっ
てB-Treeインデックスよりも収納効率が悪くなってしまう。言い換えれば、カー
ディナリティが高い場合は、B-Treeインデックスの方が向いているといえる。

構造の違いを理解していただけたであろうか?
次回は、このビットマップの構造が生み出す、ロックの問題に関して迫ってみ
る。

以上  茅ヶ崎にて

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■□ Oracle 管理ツール Performance Insight ■□÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Oracleを知り尽くしたメンバーが開発したOracleパフォーマンス監視ツール
の決定版。それがPerformance Insightです。インサイトテクノロジーの技術
者の知恵とノウハウがここに結集!
パフォーマンス監視だけでなくOracleを使用しているシステムの運用、管理、
そして開発にも役立つ機能がいっぱいです。
詳しくは以下のURLをご覧ください。

http://www.insight-tec.com/jp/html/products/products.html

また無料で試使用することも可能です。
是非お問い合わせください。

<マニュアル>
●Performance Insight3 マニュアル
Performance Insight3 User's Guide(マニュアル)の日本語版と英語版を
無料でダウンロード開始しました!

●POPSQL マニュアル
POPSQL マニュアルの英語版もダウンロード開始しました!

マニュアルのダウンロードは以下のURLから!

http://www.insight-tec.com/jp/html/products/manual.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■□ Linux版 Performance Insight■□÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Performance Insight の Linux版がリリースされる事になりました!
現在、5月末リリースに向けてテスト評価進行中です。

なお対応OSとしましては、Miracle Linux、RedHat 6.2を予定しています。
Oracle の対応バージョンとしましては、8.1.6 と 8.1.7でただいまテスト
中です。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□■ SQeeLのご案内  □■÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
<プログラマ待望の言語SQeeL>
●手軽に使える、速い、そしてWEBに適した新言語SQeeL!

フリーソフトSQeeLは、以下のURLより好評ダウンロード中!
既に多くの方々にご利用いただいております。
あなたもSQeeLの世界を体験してみませんか?

http://www.SQeeL.org/

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■□ 連載情報 ■□÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
<雑誌連載>
Oracleのエキスパートとして定評のある弊社のスタッフが執筆しております
連載記事に関してご紹介しています。
現在「DB Magazine」に、Oracleビギナー向け連載が掲載されています。
7月号が発売中ですので、是非ご覧下さい。

http://www.insight-tec.com/jp/html/topics/magazine.html
上記のURLでタイトルがご覧になれます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□■ 書籍ご案内 □■÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
<送料無料でお届けします>
1.「Oracle8 プロフェッショナルテクニック」
弊社のHPよりお申し込みいただいた方に限り、送料無料でお届けします。
専門書としては異例の速さで増刷が決定するほどの好評をいただいている
「Oracle8 プロフェッショナルテクニック」をぜひご活用ください。

2.「Oracleデータベース管理を極める13章」
「DB Magazine」に連載され大好評だった「体験的・DBAのお仕事」が
加筆され書籍化された同書は、おかげさまで発売以来3ヶ月足らずで第3刷
となりました。

好評につき、キャンペーンを拡大いたしました!上記の書籍はいずれも
消費税サービス+送料無料、つまり本体価格のみでご購入いただけます。
この機会をお見逃し無く。

さらに書籍をお買い上げいただいた方にはもれなく「Oracleの知恵袋」進呈中!
数に限りがございますので、在庫がなくなり次第終了とさせていただきます。
お早めに!

書籍ご購入のお申し込みは以下のURLより受付中!

http://www.insight-tec.com/jp/html/topics/books.html

<Oracleパーフェクトチューニングセミナー>
●6月にPerformance Insightを用いたチューニング手法を、余す所なく披露
しようと予定中です!

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■□ QAについて ■□÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
<皆様からのQAを受付けております>
皆様のQAにはできるだけ、お答えしたいと思っています。
すべてのQAにお答えすることはできないかもしれませんが、
適宜メルマガ内でとりあげていく予定ですので、是非QAをお寄せください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□■ 編集者より □■÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
読みました??「極める13章」ついに増刷決定だそうですー!!しかも、
1万部突破っ!すごいですよねー。私も読んで勉強してる最中なんです。ま
だボロボロになるまでは読んでないんですけどね・・・。でも、本当に分か
りやすいんですよー。まだの方!絶対お勧めですっ!!            by TI

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
<おら!オラ!Oracle−どっぷり検証生活−>
発行/編集:株式会社インサイトテクノロジー
http://www.insight-tec.com

マガジンID:0000030093
本メールマガジンに掲載された記事を許可なく転載することを禁じます。
Copyright (c) 1996-2001 , Insight Technology, Inc. All rights reserved.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 
 

 メールマガジン登録/解除