株式会社インサイトテクノロジー 発行
http://www.insight-tec.com
● Vol.61 ○●●●
○● おら！オラ！Oracle −どっぷり検証生活− ○●●
○○● 2001.06.20 ○●
○○○● ○
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 英語版メルマガ配信決定！ ◆
◇ ~~~~~~~~~~~~~~~~~~~~~~~~ ◇
●≫≫≫≫≫≫≫≫≫≫≫ 大変お待たせしました！ ≪≪≪≪≪≪≪≪≪●
◇ 大好評のメルマガがついに、英語化！ ◇
◆ ただいま購読者の方々を大募集中 ◆
◇ 是非この機会をお見逃しなく♪ ◇
◆ ご登録はこちらから→ http://www.Performance-Insight.com/ ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┏○ もくじ ○ ━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃
┣★ Oracle 検証生活 ★━━━━━━━━━━━━━━━━━━━…
┃
┃ 【 ロ ッ ク に 関 す る 検 証 そ の ８ 】
┃
┣★ 製 品 情 報 ★━━━━━━━━━━━━━━━━━━━━━…
┃
┃ 【 Oracle管理ツール Performance Insight 】
┃ 国内3500ライセンスの販売実績を誇る最強のチューニングツール
┃ 【 SQeeL（スキール）】
┃ WEBに適した新言語 ⇒ SQeeL！（オープンソースのフリーウェア）
┃
┣★ INFORMATION ★━━━━━━━━━━━━━━━━━━━━━…
┃
┃ 【 連載情報 】
┃ 【 書籍のご案内 】
┃ 【 ＱＡについて 】
┃ 【 編集者より 】
┃ 【 解 除 の 方 法 】
┃ http://www.insight-tec.com/jp/html/ora3/ora3.html
┃ 解除手続きは上記のURLよりお願い致します。原則として当方での解除
┃ は行っておりません、ご了承の程お願い申し上げます。
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…
┃ 【 注意事項 】
┃ 本文中にテーブルが含まれていますので、お読みになる際はMSゴシッ
┃ ク等、等幅フォントをお使いただくことをお勧めします。
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□■ Oracle検証生活 □■÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
〜ロックに関する検証 その８〜
ペンネーム ちゃむ
前回は、ビットマップ・インデックスの構造をDUMPを用いて説明した。
今回は、ビットマップ・インデックスの構造を理解した上で、ビットマップ・
インデックスが作成してあるテーブルに対して更新処理を発行してみる。
では、早速データを1件更新してみよう。
**********************************************************************
SQL> UPDATE T10MAN_COPY_4 SET MGR = ' 0000002'
WHERE EMPNO = 1 ;
1行が更新されました。
**********************************************************************
では、別のセッションから別の行を更新してみよう。
ああーっ！！別の行を更新したのに、ロック待ちになってしまった！！
**********************************************************************
SQL> UPDATE T10MAN_COPY_4 SET MGR = ' 0000004'
WHERE EMPNO = 2 ;
「待たされているよ〜〜〜〜〜〜〜〜〜〜」
**********************************************************************
では、V$LOCKからそのロックの状態を確認してみよう。
**********************************************************************
SQL> SELECT SID,TYPE,ID1,ID2,LMODE,REQUEST,CTIME,BLOCK FROM V$LOCK
WHERE TYPE IN ('TM','TX') ;
SID TY ID1 ID2 LMODE REQUEST CTIME BLOCK
--------- -- --------- --------- --------- --------- --------- ---------
9 TX 458752 291 6 0 27 1
9 TM 5712 0 3 0 27 0
13 TX 524299 404 6 0 9 0
13 TM 5712 0 3 0 9 0
13 TX 458752 291 0 4 9 0
**********************************************************************
SID=9は、始めに更新処理をしたセッションで、SID=13は、後に更新処理をした
セッション、つまり、待たされているセッションである。一番下の行がREQUEST=4
になっているが、これは、ビットマップ・インデックスを更新する際のロック
が取得できず、待ちが発生してしまっている様子を表している。maxtrans=1に
設定した際の、トランザクション・エントリの待ちに状態はよく似ている。
このときの、ロックがかかっているビットマップ・インデックスの状態を見て
みよう。
B-Treeインデックスと同様に、1つのUPDATE文で2つのブロックが更新される。
**********************************************************************
SQL> SELECT ROWID,MGR FROM T10MAN_COPY_4 WHERE EMPNO = 1 ;
ROWID MGR
------------------ --------
AAABZQAAEAAAQjUAAA 0000001
SQL> UPDATE T10MAN_COPY_4 SET MGR = ' 0000002'
WHERE EMPNO = 1 ;
**********************************************************************
MGRを' 0000001'から' 0000002'に変更。
このときの、更新された' 0000002'の値を持つビットマップのブロックの様子
を以下に示す。
http://www.insight-tec.com/html/reference/ref61_01.html
このときの、更新された' 0000001'の値を持つビットマップのブロックの様子
を以下に示す。
http://www.insight-tec.com/html/reference/ref61_02.html
勉強熱心な読者の方々であれば、以下の様なことを耳にしたことがあるであろう。
「1つのエントリあたりのビットマップセグメントは最大でも、DB_BLOCK_SIZE
の1/2までである。」
これは、ビットマップ・セグメントを更新するとき、図（ダンプ）の場合であ
れば、「col 3; len 853; (853):」⇒ 853バイトであるが、この値がDB_BLOCK_SIZE
（この環境では2048バイト）の1/2を超えてしまうと、更新時に、以前のビット
マップ・セグメントを取り消して（実態は残っている）、新しいビットマップ・
セグメントを同一ブロック内に格納できなくなってしまうからではないであろ
うか？
始めに、次の更新処理が待たされている様子を確認したが、実際には、どこの
行まで待たされるのであろうか？
これは、当然、Start RowidとEnd Rowidに依存する。
先ほどの２つの図（ダンプ）で、
' 0000002'のエントリのStart RowidとEnd Rowidと、
' 0000001'のStart RowidとEnd Rowidの値は一致している。
col 0; len 8; (8): 20 30 30 30 30 30 30 32 ← 0000002という値
col 1; len 6; (6): 01 01 08 d4 00 00 ← Start Rowid
col 2; len 6; (6): 01 01 09 4d 00 27 ← End Rowid
col 0; len 8; (8): 20 30 30 30 30 30 30 31 ← 0000001という値
col 1; len 6; (6): 01 01 08 d4 00 00 ← Start Rowid
col 2; len 6; (6): 01 01 09 4d 00 27 ← End Rowid
さて、この「01 01 08 d4 00 00」は、どのようにROWIDを表わしているのであ
ろうか？
EMPNO = 1のROWIDは「AAABZQAAEAAAQjUAAA」であったが、
これでは「01 01 08 d4 00 00」とどのような関係があるのかわからない。
これを、ROWIDからファイル番号、ブロック番号、行番号を取得するためのパッ
ケージ DBMS_ROWID を用いて求めてみよう。
**********************************************************************
SQL> SELECT ROWID,DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) FNO,
DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) B_NO,
DBMS_ROWID.ROWID_ROW_NUMBER(ROWID) R_NO
FROM T10MAN_COPY_4
WHERE EMPNO = 1 ;
ROWID FNO B_NO R_NO
------------------ --------- --------- ---------
AAABZQAAEAAAQjUAAA 4 67796 0
**********************************************************************
「01 01 08 d4 00 00」を「010」「108d4」「0000」のように分けて、16進数の
「108d4」を10進数に直すと67796になる。この値は、上記のブロック番号と一
致している。
では、End Rowid「01 01 09 4d 00 27」を「010」「1094d」「0027」のように
分解して、16進数の「1094d0」を10進数に直すと67917になる。つまり、ブロッ
ク番号 = 67917ということである。
このStart Rowidのブロック番号とEnd Rowidのブロック番号を利用して、次の
ようなSQL文をなげてみよう。
**********************************************************************
SQL> SELECT ROWID,EMPNO,DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) FNO,
DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) B_NO,
DBMS_ROWID.ROWID_ROW_NUMBER(ROWID) R_NO
FROM T10MAN_COPY_4
WHERE DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) BETWEEN 67796 AND 67917 ;
ROWID EMPNO FNO B_NO R_NO
------------------ --------- --------- --------- ---------
AAABZQAAEAAAQjUAAA 1 4 67796 0
AAABZQAAEAAAQjUAAB 2 4 67796 1
: : : : :
: : : : :
AAABZQAAEAAAQjUAAi 35 4 67796 34
AAABZQAAEAAAQjUAAj 36 4 67796 35
AAABZQAAEAAAQjUAAk 37 4 67796 36
: : : : :
: : : : :
AAABZQAAEAAAQlNAAi 4394 4 67917 34
AAABZQAAEAAAQlNAAj 4395 4 67917 35
**********************************************************************
このSQL文により、EMPNO = 1から4395までの範囲のビットマップ・セグメント
が格納されているのが分かる。
**********************************************************************
SQL> UPDATE T10MAN_COPY_4 SET MGR = ' 0000002'
WHERE EMPNO = 1 ;
1行が更新されました。
**********************************************************************
上記の状態で、別セッションから以下のSQL文を流して確認してみよう。
**********************************************************************
EMPNO = 4396を指定すると．．．
SQL> UPDATE T10MAN_COPY_4 SET MGR = ' 0000002'
WHERE EMPNO = 4396 ;
1行が更新されました。
EMPNO = 4395を指定すると．．．
SQL> UPDATE T10MAN_COPY_4 SET MGR = ' 0000002'
WHERE EMPNO = 4395 ;
「待たされているよ〜〜〜〜〜〜〜〜〜〜」
**********************************************************************
これにより、ロックの範囲が明確にわかるであろう。
**********************************************************************
SQL> UPDATE T10MAN_COPY_4 SET MGR = ' 0000002'
WHERE EMPNO = 1 ;
**********************************************************************
上記のUPDATEでは、EMPNO = 1のMGR列は' 0000001'（更新前）なので、
カラム値が' 0000001'と' 0000002'（更新後）のStart RowidからEnd Rowidま
でのロックを取得する必要がある。
しかし、残り2つのカラム値' 0000003'と' 0000004'に関しては、Start Rowid
からEnd Rowidまでのロックは取得されていない。
つまり、Start RowidからEnd Rowidの範囲内にあるデータでも、' 0000003'か
ら' 0000004'には変更できるのである。
**********************************************************************
SQL> SELECT MGR FROM T10MAN_COPY_4 WHERE EMPNO = 4395 ;
MGR
--------
0000003
SQL> UPDATE T10MAN_COPY_4 SET MGR = ' 0000004'
WHERE EMPNO = 4395 ;
1行が更新されました。
**********************************************************************
また、以下のように値が同じであれば、ロックの影響を受けることはない。
' 0000002' ⇒ ' 0000002'
**********************************************************************
SQL> SELECT MGR FROM T10MAN_COPY_4 WHERE EMPNO = 2 ;
MGR
--------
0000002
SQL> UPDATE T10MAN_COPY_4 SET MGR = ' 0000002'
WHERE EMPNO = 2 ;
1行が更新されました。
**********************************************************************
このような例外もあるが、行レベルロックができないのがビットマップ・イン
デックスの大きな弱点である。複数セッションから、ビットマップ・インデッ
クスを作成してある列の値を変更するという処理が多いようなテーブルには、
このビットマップ・インデックスを使用するべきではないだろう。
ただし、ビットマップ・インデックスは、検索中心の処理であれば大きな効果
が望めるだろう。
以上 ちょっと長すぎたか？ 茅ヶ崎にて
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■□ Oracle 管理ツール Performance Insight ■□÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Oracleを知り尽くしたメンバーが開発したOracleパフォーマンス監視ツール
の決定版。それがPerformance Insightです。インサイトテクノロジーの技術
者の知恵とノウハウがここに結集！
パフォーマンス監視だけでなくOracleを使用しているシステムの運用、管理、
そして開発にも役立つ機能がいっぱいです。
詳しくは以下のURLをご覧ください。
http://www.insight-tec.com/jp/html/products/products.html
また無料で試使用することも可能です。
是非お問い合わせください。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□■ SQeeLのご案内 □■÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜プログラマ待望の言語SQeeL＞
●手軽に使える、速い、そしてWEBに適した新言語SQeeL！
フリーソフトSQeeLは、以下のURLより好評ダウンロード中！
既に多くの方々にご利用いただいております。
あなたもSQeeLの世界を体験してみませんか？
http://www.SQeeL.org/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■□ 連載情報 ■□÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜雑誌連載＞
Oracleのエキスパートとして定評のある弊社のスタッフが執筆しております
連載記事に関してご紹介しています。
現在「DB Magazine」に、Oracleビギナー向け連載が掲載されています。
７月号が発売中ですので、是非ご覧下さい。
http://www.insight-tec.com/jp/html/topics/magazine.html
上記のURLでタイトルがご覧になれます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□■ 書籍ご案内 □■÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜送料無料でお届けします＞
１．「Oracle8 プロフェッショナルテクニック」
弊社のHPよりお申し込みいただいた方に限り、送料無料でお届けします。
専門書としては異例の速さで増刷が決定するほどの好評をいただいている
「Oracle8 プロフェッショナルテクニック」をぜひご活用ください。
２．「Oracleデータベース管理を極める13章」
「DB Magazine」に連載され大好評だった「体験的・DBAのお仕事」が
加筆され書籍化された同書は、おかげさまで発売以来３ヶ月足らずで第３刷
となりました。
好評につき、キャンペーンを拡大いたしました！上記の書籍はいずれも
消費税サービス＋送料無料、つまり本体価格のみでご購入いただけます。
この機会をお見逃し無く。
大好評の「極める１３章」の注文が殺到していて嬉しい悲鳴です。ありがと
うございます！ですが最近、早く手元に欲しい方が多く、ご注文される際に
住所、氏名の記入もれがたいへん多く見られます。くれぐれも、記入もれが
無いよう最後に確認してからご注文してくださいね！
よろしくお願いいたします。
書籍ご購入のお申し込みは以下のURLより受付中！
http://www.insight-tec.com/jp/html/topics/books.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■□ ＱＡについて ■□÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜皆様からのＱＡを受付けております＞
皆様のＱＡにはできるだけ、お答えしたいと思っています。
すべてのＱＡにお答えすることはできないかもしれませんが、
適宜メルマガ内でとりあげていく予定ですので、是非ＱＡをお寄せください。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□■ 編集者より □■÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷÷
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
うー。書きたい事がいっぱいありすぎるぅ。まず始めにメルマガの英語版が
ついに配信となります！そこで皆さん是非この機会に登録して下さいねー！
登録はこちらから→http://www.Peformance-Insight.com/ ですっ！それか
ら最近、本当に多いんですっ。本をご注文される際に住所、氏名の記入もれ
が・・・。せっかくご注文されても、届くのに時間がかかってしまうので最
後に確認してからご注文してくださいねっ！よろしくお願いしまーす！！
by TI
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜おら！オラ！Oracle−どっぷり検証生活−＞
発行／編集：株式会社インサイトテクノロジー
http://www.insight-tec.com
マガジンID：0000030093
本メールマガジンに掲載された記事を許可なく転載することを禁じます。
Copyright (c) 1996-2001 , Insight Technology, Inc. All rights reserved.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Insight Technology, Inc
Japanese | English