Oracle 11g検証　ASSMを見てみる　その１

＜Oracle 11g検証第2弾 ASSMを見てみる　その１＞
ペンネーム：サマー・リーフ

第1弾 11gRAC構築に続きまして、”ASSM”をネタに見ていきます。

バックナンバー、”ASSMに関する検証”も参考にしていただければと思います。

「ASSMに関する検証」
https://old.insight-tec.com/mailmagazine/ora3/vol331.html ～ vol342.html

▼おさらい

“ASSM”ってなんじゃ？

⇒自動セグメント領域管理：Auto Segment Space Management を略して”ASSM”

ご存じの方、知らずに使っている方が居ると思います。
なにせ地味な機能ですからね。

ORACLEもバージョンを追うごとにパフォーマンスを求め、目立つ機能、内部
機能と進化を遂げながら成長しています。

どんな機能かおさらいすると～

セグメントの領域管理をORACLEが、自動で管理する機能です。

読者の皆さんに過去に物理設計フェーズで主にテーブル、インデックスを
作成するにあたって、Storage句やFREELISTの調整をしながらチューニング
の経験をした方は手間がかかったなぁと覚えてませんか。

Oracleが領域を自動で管理する機能（ASSM）によって、その手間を軽減し内部
動作としても効率よく領域（Storage）を利用できます。

この機能を利用する流れとしては、表領域を作成する際に
segment_management_clause ⇒ auto を指定します。
Oracle 10gR2からは、デフォルトで ASSM が有効の状態で表領域が作成されま
す。

機能の詳細は、冒頭で紹介したバックナンバーを参照してください。

おっと、回想はこの辺にしないと。
バックナンバーにありますからね～

▼11g を見てみましょう

DBCAで作成したインスタンス例に 11gR1 と 10gR2 と比較してみましょう。

表領域が、どう作成されているか “dba_tablespaces” を参照すると両バージ
ョン共に、デフォルトのパラメータは、同じでした。
（サイズ、管理方法、圧縮の有効・無効など）

“ASSM” は新機能としてエントリーされていないので、顕著な改善は期待して
なかったのですが、んんん？

“dba_tablespaces” のカラムに追加されていますねぇ。

MAX_SIZE              セグメントのデフォルトの最大サイズ
                        ⇒デフォルトは、2GB
PREDICATE_EVALUATION  述語がホスト（HOST）によって評価されているか、
                      記憶域（STORAGE）によって評価されているか
                        ⇒デフォルトは、"HOST"
ENCRYPTED             表領域が暗号化されているかどうか
                        ⇒デフォルトは、無効
COMPRESS_FOR          セグメントに対して圧縮を開始する契機を管理
                      ダイレクトインサート処理、または全てのDML実行時
                        ⇒デフォルトでは、NULL
                          もちろん圧縮機能は、無効

表領域に対する圧縮機能の拡張、暗号化機能の追加され管理項目が増えていま
す。

表領域の暗号化については、
バックナンバー「Oracle11g　表領域暗号化」を参考にしてください。
https://old.insight-tec.com/mailmagazine/ora3/vol366.html

引き続き、セグメントの管理に変化があるかを探っていきます。

“dba_segments”を参照してみます。

“dba_segments” のカラムも追加されています。

SEGMENT_SUBTYPE       LOBセグメントのサブタイプ
                        ⇒LOBが、SECUREFILE、または、ASSM（自動領域管
                          理）、MSSM（手動領域管理）で作成されているか
MAX_SIZE              セグメントのデフォルトの最大サイズ
                        ⇒デフォルトは、2GB
RETENTION             SECUREFILEセグメント用の保存オプション
                        ⇒デフォルトでは、NULL
MINRETENTION          SECUREFILEセグメント用の最小保存期間
                        ⇒デフォルトでは、NULL

11g から SECUREFILE という LOB型のセグメントを暗号化する新機能が追加さ
れました。
画像、音楽データなどラージオブジェクトをデータベースへ格納するニーズや
セキュリティのニーズが背景と考えます。

なので、それに伴う管理カラムが増えています。

▼”ASSM” 内部動作の検証

セグメントヘッダーで管理する空き領域のビットマップを見てみます。

結論から言うと、11gR1 、10gR2に全く同じ、表領域（ASSM指定）、セグメン
ト（テーブル）を作成、データも同じ件数を格納しダンプを確認するとビット
マップの状態、領域の消費サイズ共に、全く同じ結果となりました。

以下、検証した結果です。

■検証環境

OS：WindowsXP
DB：Oracle11g EE Release 11.1.0.6
Oracle10g EE Release 10.2.0.3

–表領域作成

-10g
CREATE TABLESPACE TBS_ASSM_MANUAL
DATAFILE
　　　　　　　　　　　　　　　'C:oracleproduct10.2.0oradataorclTBS_ASSM_MANUAL.dbf'
SIZE 100M SEGMENT SPACE MANAGEMENT MANUAL;

-11g
CREATE TABLESPACE TBS_ASSM_AUTO
DATAFILE
　　　　　　　　　　　　　　　'C:oracleproduct11.1.0oradataora11gTBS_ASSM_AUTO.dbf'
SIZE 100M SEGMENT SPACE MANAGEMENT AUTO;

–セグメント情報確認

セグメントのヘッダーブロックは、同じ。
内部仕様は、変わっていないようです。

-10g
OWNER  SEGMENT_NAME     HEADER_FILE HEADER_BLOCK
------ ---------------- ----------- ------------
ITI1   SUMMER_LEAF10G             5           11

-11g
OWNER  SEGMENT_NAME     HEADER_FILE HEADER_BLOCK
------ ---------------- ----------- ------------
ITI1   SUMMER_LEAF11G             5           11

–テストデータ投入

declare
　　　　cnt   number;
begin
for i in 1..20000 loop
insert into SUMMER_LEAF1xG values
(i,'aaaaaaaaaaaaaaaaaaaa','AAAAAAAAAA',sysdate);
commit;
end loop;
end;
/

–テストデータ投入所要時間

両バージョンとも誤差の範囲で同等の実行時間でした。

Ora Elaps Time（s）
— —————
10g 2.59
11g 2.39

–ヘッダーブロックのダンプ

alter system dump datafile 5 block 11;

同じ内容、件数のデータを格納し消費したブロックと空きブロックを
管理するビットマップの持ち方に違いはなかった。

-10g、11g共に同じ内容

        --------------------------------------------------------
        Low HighWater Mark : 
      ★    Highwater::  0x01400089  ext#: 15 blk#: 8 ext size: 8
        #blocks in seg. hdr's freelists: 0     
        #blocks below: 118   
        mapblk  0x00000000  offset: 15    
        Level 1 BMB for High HWM block: 0x0140008a
        Level 1 BMB for Low HWM block: 0x01400079
        --------------------------------------------------------
        Segment Type: 1 nl2: 1      blksz: 8192   fbsz: 0      
        L2 Array start offset:0x00001434
      ★First Level 3 BMB:    0x00000000
        L2 Hint for inserts:  0x0140000a
      ★Last Level 1 BMB:     0x0140008a
      ★Last Level II BMB:    0x0140000a
        Last Level III BMB:   0x00000000
           Map Header:: next  0x00000000 #extents: 17 obj#: 69647 
        flag: 0x10000000
        Inc # 0 
        Extent Map
        -----------------------------------------------------------------

ダンプの見方は、バックナンバーにあります。
https://old.insight-tec.com/mailmagazine/ora3/vol331.html

▼まとめ

検証ネタよりも今回は、事実を確認した回になりました。
“ASSM”の内部動作に変更箇所は無いようですね。

“ASSM” が新機能と追加された 9i から現在の 11g においても SYSTEM表領域
に対しては、”ASSM” で管理できない制限があります。

この制限の理由を探す旅に出ます。（雲をつかむ思いかもしれません・・）

千葉へ外出しましたが、茅ヶ崎より雪がたくさん降っていたようです。
２月に入って一段と寒くなりましたね。
茅ヶ崎にて

Oracle 11g検証 ASSMを見てみる その１

Oracle 11g検証　ASSMを見てみる　その１