ローカルエクステントマネージメントに関する検証 その６
～ローカルエクステントマネージメントに関する検証 その６～
ペンネーム ちゃむ
————————————————————————–
8iからの新機能ローカルエクステントマネージメントを以下「LOCAL」と呼ぶ。
従来のデータディクショナリーでエクステントを管理する方法を以下「DICTIONARY」
と呼ぶ。
————————————————————————–
前回までで、「LOCAL」のエクステントをビットマップ管理するという構造的な
ところは理解できたであろう。
今回は、「LOCAL」と「DICTIONARY」を比較したときのメリットについて説明
する。
まずは、メルマガの第２回の ～フリーブロックに関する検証 その２～ で
説明をした内容であるが少し復習する。
そこで説明した重要なポイントは2点あった。
１．SMONがコアレスする対象
「DICTIONARY」 → コアレス対象
「LOCAL」 → コアレス対象外
但し、「DICTIONARY」に関しては、テーブルスペースのpctincrease 0以外を
設定したテーブルスペースに対してsmonが自動的に5分に一回コアレスする。
また、コアレス対象テーブルスペースを特定するためにsmonが実行する
SQL文は以下の通りだった。
select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t where t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0
where句のt.dflextpct!=0がpctincrease 0以外をコアレス対象を意味し
t.bitmapped=0が「LOCAL」は、コアレス対象外を意味している。
２．STエンキュー（Space transaction enqueue）に関して
コアレスや領域マップを更新するTRUNCATE処理、DROP処理、CREATE TABLEな
どの処理を行う際に取得されるロックの一種
問題は、STエンキューは、インスタンス上に1つしか存在しない点である。
STエンキューは、通常はほんの一瞬しか取得されないので、問題になることはな
い。しかし、もしこのロックを長時間取得しているときがあれば、表領域に対
して領域マップの更新ができなくなり、他の表領域に対して領域マップを更新
するような処理が起こったときにその処理を待たせてしまう。
さて、復習したところで今回は「LOCAL」と「DICTIONARY」の領域マップ更新時
のV$LOCKから見た違いについて検証する。
手順１
「LOCAL」と「DICTIONARY」をエクステント単位を同じにして、同定義のテーブ
ルを５つそれぞれに作成する。但し、テーブルは領域マップの更新が起こりやす
いように、エクステントサイズを2ブロックと小さく設定する。
手順２
20000件のデータを５つのテーブルにSQL*LOADERを用いて、同時に流す。
手順３
V$LOCKよりそれぞれの処理の実行時の様子を見る。
検証開始
手順１
「LOCAL」
/*テーブルスペース作成*/ create tablespace TESTl datafile '../mnt1/testl' size 100m EXTENT MANAGEMENT LOCAL UNIFORM SIZE 4k; /*テーブル作成 以下と同様なテーブルを５つ作成する*/ create table customer5_l_1 (custid number(8) , cname varchar2(10), class varchar2(2), dummy char(60)) tablespace TESTl storage (initial 4k next 4k pctincrease 0 maxextents unlimited );
「DICTIONARY」
/*テーブルスペース作成*/ create tablespace TESTd datafile '../mnt1/testd' size 100m minimum extent 4k; /*テーブル作成 以下と同様なテーブルを５つ作成する*/ create table customer5_d_1 (custid number(8) , cname varchar2(10), class varchar2(2), dummy char(60)) tablespace TESTd storage (initial 4k next 4k pctincrease 0 maxextents unlimited );
手順2
all_load_d.batを実行する。
all_load_d.batは、load_d20000_1.batからload_d20000_5.batの５つのSQL*LOADER
のスクリプトをバックグランドで実行するバッチ・ファイルである。
all_load_d.batの中身
load_d20000_1.bat & load_d20000_2.bat & load_d20000_3.bat & load_d20000_4.bat & load_d20000_5.bat &
load_d20000_1.batの中身
（load_d20000_1.batからload_d20000_5.batの中身は同様）
（data.txtは20000件のcsvファイル）
sqlldr control=datad20000_1.ctl data=data.txt userid=scott/tiger log=datad20000_1.log
手順3
まず「DICTIONARY」のテーブルにデータを流したときのV$LOCKを見てみる。
V$LOCKは、その瞬間の状態を表したものなので、STエンキューなどといった
「一瞬」しか現れない（取得されない）ものに関しては、取得されている様
子を確認することは容易でない。以下は、「非常に良い一瞬」をとらえたも
のである。
SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK ---------------------------------------------------------------- 9 TX 458767 2242 6 0 0 0 9 TX 458763 2246 6 0 0 0 9 TM 13 0 3 0 0 0 9 TM 12 0 3 0 0 0 9 TM 57 0 3 0 0 0 9 TM 8397 0 3 0 0 0 9 ST 0 0 6 0 0 1 12 TX 327698 2245 6 0 1 0 12 TM 8400 0 3 0 1 0 12 ST 0 0 0 6 0 0 13 TX 589838 2243 6 0 0 0 13 TM 8398 0 3 0 0 0 13 ST 0 0 0 6 0 0 14 TX 524301 2254 6 0 0 0 14 TM 8401 0 3 0 0 0 14 ST 0 0 0 6 0 0 15 TX 393233 2253 6 0 1 0 15 TM 8399 0 3 0 1 0 15 ST 0 0 0 6 0 0
ここで注目していただきたいのは、まず、SID（セッションID）=9のSTエンキ
ューのBLOCK 1のものがLOCKをLMODE 6(排他モード)で取得して、REQUESTが6の
他のSIDのSTエンキューを待たせている様子がわかる。これがSTエンキューが
インスタンスに一つしか取られていないということを表わした状況である。
では、次に「LOCAL」のテーブルにデータを流したときのV$LOCKを見てみる。
SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK ---------------------------------------------------------------- 9 TX 327683 2271 6 0 0 0 9 TX 327689 2270 6 0 0 0 9 TM 8402 0 3 0 0 0 9 HW 19 71303201 6 0 0 0 9 TT 19 16 4 0 0 0 12 TX 196622 2306 6 0 0 0 12 TX 196621 2307 6 0 0 0 12 TM 8406 0 3 0 0 0 12 HW 19 71303209 6 0 0 0 12 TT 19 16 4 0 0 0 13 TX 65552 2316 6 0 0 0 13 TX 65553 2317 6 0 0 0 13 TM 8403 0 3 0 0 0 13 TM 57 0 3 0 0 0 13 TT 19 16 4 0 0 0 13 HW 19 71303203 6 0 0 0 14 TX 262150 2339 6 0 0 0 14 TX 262144 2332 6 0 0 0 14 TM 8404 0 3 0 0 0 14 HW 19 71303205 6 0 0 0 14 TT 19 16 4 0 0 0 15 TX 131078 2809 6 0 0 0 15 TX 131089 2806 6 0 0 0 15 TM 8405 0 3 0 0 0 15 HW 19 71303207 6 0 0 0 15 TT 19 16 4 0 0 0
なんと、STエンキューが取得されていない。かわりにTYPE=HWのものが取得され
ている。HWはSpace management operations on a specific segmentである。
これは領域管理に関するエンキューであるくらいのことしかわからない。
ただ、ここで重要なのは、HWは、インスタンスに複数取得できるので、待ちが生
じないところである。
alter.logにORA-01575: timeout waiting for space management resource
（ＳＴエンキュー待ちで発生するタイムアウト）。
というエラーメッセージが出力されるようなサイトには、「LOCAL」は、
それを防ぐための手段になり得るだろう。
12月14日（木）、15日（金）に開催されるORACLE OPEN WORLD（東京ドーム）へ
の出展が決まりました。メルマガライターもブース（インサイトテクノロジー）
に全員終結します。会場で皆様にお会いできるのを楽しみにしております！！
以上 寺尾 聡が犬の散歩をしていた 茅ヶ崎にて