ローカルエクステントマネージメントに関する検証 その７
～ローカルエクステントマネージメントに関する検証 その７～
ペンネーム ちゃむ
————————————————————————–
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つのフリーブロックに別れているかは、
～ローカルエクステントマネージメントに関する検証 その３～を参照のこと
100Mのテーブルスペースの「LOCAL」,「DICTIONARY」にそれぞれのテーブルス
ペースにテーブルを作成して100万件のデータを挿入したときのパフォーマンス
の違いを示す。
次の2点を比較する。
１．「LOCAL」、「DICTIONARY」上のテーブルにSQL*LOADERを用いて100万件INSERT
したときのパフォーマンスの違い
２．それらのテーブルをtruncateしたときの処理速度の違い。
１．
以下は比較に使用するテーブルスペース、テーブルを作成する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
２．
次にそのデータを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（東京ドーム）へ
の出展が決まりました。メルマガライターもブース（インサイトテクノロジー）
に全員終結します。会場で皆様にお会いできるのを楽しみにしております！！
以上 「牛角（焼肉屋）」が駅前にできた 茅ヶ崎にて