ローカルエクステントマネージメントに関する検証 その6

~ローカルエクステントマネージメントに関する検証 その6~
ペンネーム ちゃむ

————————————————————————–
8iからの新機能ローカルエクステントマネージメントを以下「LOCAL」と呼ぶ。
従来のデータディクショナリーでエクステントを管理する方法を以下「DICTIONARY」
と呼ぶ。
————————————————————————–

前回までで、「LOCAL」のエクステントをビットマップ管理するという構造的な
ところは理解できたであろう。
今回は、「LOCAL」と「DICTIONARY」を比較したときのメリットについて説明
する。

まずは、メルマガの第2回の ~フリーブロックに関する検証 その2~ で
説明をした内容であるが少し復習する。

そこで説明した重要なポイントは2点あった。

1.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」は、コアレス対象外を意味している。

2.STエンキュー(Space transaction enqueue)に関して

コアレスや領域マップを更新するTRUNCATE処理、DROP処理、CREATE TABLEな
どの処理を行う際に取得されるロックの一種
問題は、STエンキューは、インスタンス上に1つしか存在しない点である。

STエンキューは、通常はほんの一瞬しか取得されないので、問題になることはな
い。しかし、もしこのロックを長時間取得しているときがあれば、表領域に対
して領域マップの更新ができなくなり、他の表領域に対して領域マップを更新
するような処理が起こったときにその処理を待たせてしまう。

さて、復習したところで今回は「LOCAL」と「DICTIONARY」の領域マップ更新時
のV$LOCKから見た違いについて検証する。

手順1

「LOCAL」と「DICTIONARY」をエクステント単位を同じにして、同定義のテーブ
ルを5つそれぞれに作成する。但し、テーブルは領域マップの更新が起こりやす
いように、エクステントサイズを2ブロックと小さく設定する。

手順2

20000件のデータを5つのテーブルにSQL*LOADERを用いて、同時に流す。

手順3

V$LOCKよりそれぞれの処理の実行時の様子を見る。

検証開始

手順1

「LOCAL」

/*テーブルスペース作成*/
create tablespace TESTl
datafile '../mnt1/testl' size 100m
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 4k;

/*テーブル作成 以下と同様なテーブルを5つ作成する*/
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;

/*テーブル作成 以下と同様なテーブルを5つ作成する*/
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の5つの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
(STエンキュー待ちで発生するタイムアウト)。

というエラーメッセージが出力されるようなサイトには、「LOCAL」は、
それを防ぐための手段になり得るだろう。

12月14日(木)、15日(金)に開催されるORACLE OPEN WORLD(東京ドーム)へ
の出展が決まりました。メルマガライターもブース(インサイトテクノロジー)
に全員終結します。会場で皆様にお会いできるのを楽しみにしております!!

以上 寺尾 聡が犬の散歩をしていた 茅ヶ崎にて