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

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

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

前回は、「LOCAL」と「DICTIONARY」を比較したときの領域管理上のエンキュー
に関するメリットについて説明した。
今回は、「パフォーマンス」に関するメリットを検証してみよう。

まず、100Mのテーブルスペースの「LOCAL」、「DICTIONARY」をそれぞれ作った直後の
dba_free_spaceの状況を示す。

TABLESPACE_NAME  BLOCK_ID  BYTES      BLOCKS
--------------------------------------------
TESTD            2         104855552  51199
TESTL            33        58720256   28672
TESTL            28705     46071808   22496

なぜ、TESTLが2つのフリーブロックに別れているかは、
~ローカルエクステントマネージメントに関する検証 その3~を参照のこと

100Mのテーブルスペースの「LOCAL」,「DICTIONARY」にそれぞれのテーブルス
ペースにテーブルを作成して100万件のデータを挿入したときのパフォーマンス
の違いを示す。

次の2点を比較する。

1.「LOCAL」、「DICTIONARY」上のテーブルにSQL*LOADERを用いて100万件INSERT
したときのパフォーマンスの違い

2.それらのテーブルをtruncateしたときの処理速度の違い。

1.

以下は比較に使用するテーブルスペース、テーブルを作成するSQL文である。
(t100man_orgはemp表を100万件に拡張した表である。)

「DICTIONARY」

create tablespace TESTd
datafile '/mnt1/testd' size 100m
minimum extent 4k
default storage (pctincrease 0);
/* pctincrease 0はSMONにコアレスさせないため */

create table test100man_d
tablespace TESTd
storage (initial 4k next 4k pctincrease 0 maxextents unlimited freelists 1)
as select * from t100man_org where 1=2;

「LOCAL」

create tablespace TESTl
datafile '/mnt1/testl' size 100m
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 4k;

create table test100man_l
tablespace TESTl
storage (initial 4k next 4k pctincrease 0 maxextents unlimited freelists 1)
as select * from t10man_org where 1=2;

参考までに、SQL*LOADERでロードするためのCSVのテキストデータを出力するスクリプト
を以下に記述する。

---------------------スクリプト始め------------------------
set heading off
set echo off
set feed off
set spa 0
set newp 0
set pages 0  
set wra off
col EMPNO format 9999999999
col ENAME format a10
col JOB format a9
col MGR format 9999
col SAL format 9999999
col COMM format 9999999
col DEPTNO format 99

spool /mnt1/data100man.txt
select EMPNO || ',' || ENAME || ',' || JOB || ',' || MGR || ',' || HIREDATE || ','
 || SAL || ',' || COMM || ',' || DEPTNO from t100man_org
/
spool  off
---------------------スクリプト終わり------------------------

以下が従来型のSQL*LOADERを用いて100万件INSERTしたときの処理速度の違いである。
(処理をする際は必ずデータベースを再起動して行なった)
処理時間の違いは、やはりSYSTEM表領域へのIOの違いが影響しているであろう。

「DICTIONARY」

実行時間:         00:24:29.86→24分29秒86
CPU時間 :         00:05:18.30→5分18秒30

「LOCAL」

実行時間:         00:17:09.58→17分9秒58
CPU時間 :         00:05:08.74→5分8秒74

そのときのDATAFILEファイルへのIOどうであろうか?
(処理後のv$filestatの値から処理前のv$filestatの値を引き算する)

物理リード回数 → P_R
物理リードブロック回数 → P_R_B
物理ライト回数 → P_W
物理ライトブロック数 → P_W_B

「DICTIONARY」                  P_R      P_R_B      P_W      P_W_B
------------------------------------------------------------------
SYSTEM 表領域                  2958       3377     1925       1925
TESTD 表領域                      3          3    25037      25037
ロールバックセグメント表領域     47         47     5783       5783

「LOCAL」                       P_R      P_R_B      P_W      P_W_B
------------------------------------------------------------------
SYSTEM 表領域                  2272       2612       32         32
TESTL 表領域                      3          3    25061      25061
ロールバックセグメント表領域     30         30     4244       4244

2.

次にそのデータをTRUNCATEしたときの処理時間と物理IOを示す。
時間はsqlplus よりset timing onで取得したものである。
処理時間の違いは、SYSTEM表領域、ロールバックセグメント表領域のIO数
に違いが影響しているであろう。

「DICTIONARY」                  P_R      P_R_B       P_W      P_W_B
-------------------------------------------------------------------
SYSTEM 表領域                  1926       2327        230        230
TESTD 表領域                    103        103        104        104
ロールバックセグメント表領域   1128       1128       1872       1872

Elapsed: 00:09:48.11→9分48秒11

「LOCAL」                       P_R      P_R_B       P_W      P_W_B
-------------------------------------------------------------------
SYSTEM 表領域                   564        622        13         13
test100man_l 表領域             105        105       109        109
ロールバックセグメント表領域     25         25       609        609

Elapsed: 00:00:52.97→52秒97

TRUNCATE直後のdba_free_spaceの様子

「DICTIONARY」
TABLESPACE_NAME   BLOCK_ID   BLOCKS
--------------------------------------
TESTD             4          2
TESTD             6          2
TESTD             8          2
TESTD             10         2
  :               :          :
  :               :          :
  :               :          :
TESTD             24986      2
TESTD             24988      2
TESTD             24990      2
TESTD             24992      26209 → initial 100Mで確保した際の余り

「LOCAL」
TABLESPACE_NAME   BLOCK_ID   BLOCKS
--------------------------------------
TESTL             33         2
TESTL             37         28668
TESTL             28705      22496

「LOCAL」のほうは、DROPした直後に、create tablespace した直後の状態に戻っ
ている。以前、localはコアレス対象外と説明したが、ここに理由を見出せる
であろう。また、「DICTIONARY」の方は、BLOCK_IDを見ればコアレスをすれば、一
つの領域になるが、コアレスをしない状態では、エクステント境界線が12495個も
あるのがわかるであろう。

この結果は、TRUNCATEの処理時間が、「DICTIONARY」は「LOCAL」より遅いという
ことだけでなくその後のエクステントの境界線の状態を考えるといずれ、
coalesce処理が必要になったとき、その分また負荷がかかってしまうという
「負の遺産」を残してしまったということが言える。

最後にコアレス処理を手動で行なったときの処理時間を計ると以下のようになる。

alter tablespace testd coalesce;

Elapsed: 00:05:41.68→5分41秒68

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

以上 「牛角(焼肉屋)」が駅前にできた 茅ヶ崎にて