DB2 V9.7新機能ワークショップ 圧縮 圧縮機能強化 機能強化

DB2 V9.7新機能ワークショップ
＜第１．００版 ２００９年 ７月＞
圧縮機能強化
圧縮機能強化
本書に含まれている情報は、正式なIBMのテストを受けていません。また、明記にしろ、暗黙的にしろ、なんらの保証もなしに配布されるものです。
この情報の使用またはこれらの技術の実施は、いずれも、使用先の責任において行われるべきものであり、それらを評価し、実際に使用する環境に統合する
使用先の判断に依存しています。それぞれの項目は、ある特定の状態において正確であることがIBMによって調べられていますが、他のところで同じまたは同
様の結果が得られる保証はありません。これらの技術を自身の環境に適用することを試みる使用先は、自己の責任において行う必要があります。
© Copyright IBM Japan Systems Engineering Co., Ltd. 2009
内容
• 行圧縮機能の概要（～V9.5）
• DB2 V9.7新機能
– 索引圧縮
– 一時表圧縮
– XML(XDA)データ圧縮
– LOBの処理パフォーマンス改善と圧縮
2
© 2009 ISE Corporation
行圧縮機能 概要（～V9.5)
概要（～V9.5)
行圧縮機能
3
© 2009 ISE Corporation
行圧縮機能の
行圧縮機能の概要
• 辞書を
辞書を使った行
った行レベルの
レベルのデータ圧縮
データ圧縮 （V9.1の
V9.1の新機能）
新機能）
– データ・ページのデータとログ・レコードを圧縮
LONG/LOB列、索引データ、一時表は圧縮の対象外
XML列は、INLINEで定義されている場合に、圧縮対象とすることが可能
（V9.5～）
– 辞書には、レコードにある特定のパターンが記録される
名前
部署
給与
都道府県
区・市
郵便番号
Fred
500
10000
東京都
港区
24355
John
500
20000
東京都
港区
24355
Fred
500
10000
東京都
港区
24355
John
500
20000
東京都
港区
24355
…
ディクショナリー
Fred
4
(01)
10000
(02)
John
(01)
20000
(02)
…
01
500
02
東京都, 港区,24355
…
…
© 2009 ISE Corporation
行圧縮機能の
行圧縮機能の概要（
概要（続き）
• メリット
– ディスク使用量
ディスク使用量の
使用量の削減
– より多
より多くのデータ
くのデータが
データが圧縮された
圧縮された状態
された状態で
状態でバッファープールに
バッファープールに乗るため、
るため、
バッファープールヒット率
バッファープールヒット率の向上が
向上が期待できる
期待できる
ディスクへの
ネックの
ディスクへの読
への読み書き量が削減できるため
削減できるため、
できるため、特にI/Oネック
ネックのシステムに
システムに
はパフォーマンス向上
パフォーマンス向上の
向上の効果がある
効果がある
– ログ・
ログ・ファイルへの
ファイルへの書
への書き出し量が削減される
削減される
5
© 2009 ISE Corporation
DB2 V9.7から新たに圧縮可能となったオブジェクト
• 複数の
複数のアルゴリズムを
アルゴリズムを用いた索引自動圧縮
いた索引自動圧縮
• 一時表の
一時表の自動圧縮
Temp
Table
Table
Order By
• LOBデータ
データと
データの
データとXMLデータ
データの圧縮
Temp
Order By
• レプリケーションの
レプリケーションのサポート
– 圧縮表からのレプリケーション
6
© 2009 ISE Corporation
V9.7圧縮機能
V9.7圧縮機能
7
© 2009 ISE Corporation
索引の
つの手法
索引の圧縮 － 3つの
つの手法による
手法による圧縮
による圧縮
索引ページ
索引ページ
圧縮された
圧縮された索引
された索引ページ
索引ページ
ページヘッダー
ページヘッダー
スロットDir
スロットDir
スロットDir
スロットDir
AA
1
山田
1
山田
AA
2
鈴木
2
鈴木
AA
3
伊藤
3
伊藤
8
可変長の
可変長のスロット・
スロット・ディレクトリー
ページに格納されるキーの数に
よってスロット・ディレクトリーの長
さを変動できるようにした。
前方一致部分の
前方一致部分の圧縮
各キーで共通な前方一致部分を
圧縮
RIDリスト
RIDリストの
リストの圧縮
各エントリーのRID（ページ番号
+Slot番号）を保管する代わりに差
分情報を保管するように変更
© 2009 ISE Corporation
索引の
索引の圧縮 － 前方一致部分の
前方一致部分の圧縮
• 各キーで
キーで共通な
共通な前方一致部分を
前方一致部分を圧縮
– 列の境界は
境界は無関係
索引キー
索引キーの
キーの値
(AA,
(AA,
(AA,
(BB,
(BB,
1,
2,
3,
1,
1,
山田)
鈴木)
伊藤)
佐藤)
田中)
圧縮された
圧縮された索引
された索引に
索引に格納される
格納されるデータ
されるデータ
(AA, 1, 山田)
(, 2, 鈴木)
(, 3, 伊藤)
(BB, 1, 佐藤)
(,, 田中)
前方一致部分を
前方一致部分を省略して
省略して保管
して保管
9
© 2009 ISE Corporation
RID list compression
• Large表
Large表スペース上
スペース上の表のPage4に
Page4に、同じKeyValueの
KeyValueの行が10行入
10行入って
行入って
いるケース
いるケース
●Uncompressed Index
<00
<00
<00
<00
00
00
00
00
00
00
00
00
04,
04,
04,
04,
00
00
00
00
00>, <00 00 00 04, 00 01>, <00 00 00 04, 00 02>,
03>, <00 00 00 04, 00 04>, <00 00 00 04, 00 05>,
06>, <00 00 00 04, 00 07>, <00 00 00 04, 00 08>,
09>
●Compressed Index
<00 00 00 04, 00 00>, <1>, <1>, <1>, <1>, <1>, <1>, <1>, <1>, <1>, <1>
RID間のDelta情報のみを記録
10
© 2009 ISE Corporation
索引圧縮利用時のポイント ー 圧縮効率の高い索引を選択する
• 索引キーの合計長が長い、または索引キーのカーディナリティが低い索引
– 1ページに格納される索引キー・エントリーの数が少なく、スロット・ディレクトリーを短くすることができる
• 重複データが前方のキー列に多い索引
– 前方一致部分の圧縮が期待できる
DATE列などは圧縮効率が高い
• クラスター率の高い索引
RIDリスト上の各RID間の差分が小さいため、RIDリストの圧縮率が高くなる
索引A
索引A
索引B
索引B
索引C
索引
索引種別
ユニーク索引
非ユニーク索引
ユニーク索引
キー列
キー列
INT、CHAR(100)、CHAR(100)
INT、CHAR(100)、CHAR(100)
DATE
挿入レコード
挿入レコード数
レコード数
50000
50000
2547
Full Key Card
50000
500
2547
1471
63
12
1471 (±
(±0%）
0%）
28 （-56%）
56%）
9(－
－25%)
リーフ
非圧縮
ページ
数
リーフ
圧縮
ページ
数
圧縮の
圧縮の
効果無し
効果無し
11
圧縮の
圧縮の
効果有
圧縮の
圧縮の
効果有
© 2009 ISE Corporation
使用方法
• 索引圧縮を
索引圧縮を使用する
使用する場合
する場合
– CREATE INDEX、ALTER INDEXのCOMPRESS YESオプション使用
CREATE INDEX X01 ON T01 (C01) COMPRESS YES
CREATE INDEX X02 ON T02 (C02)
ALTER INDEX X02 COMPRESS YES
REORG INDEXES ALL FOR TABLE T02
• 索引圧縮の
索引圧縮の解除方法
– ALTER INDEXのCOMPRESS NOオプション
ALTER INDEX X02 COMPRESS NO
REORG INDEXES ALL FOR TABLE T02
ALTER後のREORG INDEXESするまでは、圧縮された状態で保持される
12
© 2009 ISE Corporation
新しい表関数
しい表関数①
表関数①（ADMIN_GET_INDEX_COMPRESS_INFO)
>>-ADMIN_GET_INDEX_COMPRESS_INFO--(--objecttype--,--objectschema--,--objectname--,-->
>--dbpartitionnum--,--datapartitionid--)-----------------------><
–
objecttype
–
objectschema
–
–
オブジェクト名（case-sensitive）
dbpartitionnum
–
データベース・パーティション番号（非データベース・パーティション環境：’-2’ or NULL)
datapartitionid
13
オブジェクトのスキーマ名
objectname
•
オブジェクトタイプ（表：’T’ or NULL、索引：’I’ )
データ・パーティション番号（非データ・パーティション環境：’-2’ or ‘0’or NULL)
圧縮属性の確認、および圧縮によって節約できるリーフページ数の見積もり
などが可能
© 2009 ISE Corporation
新しい表関数
しい表関数②
表関数②（ADMIN_GET_INDEX_INFO)
>>-ADMIN_GET_INDEX_INFO--(--objecttype--,,--objectschema--,--objectname--)--------------------------><
–
Objecttype
オブジェクトタイプ（表：’T’ or NULL、索引：’I’ )
Objectschema
オブジェクトスキーマ
Objectname
–
–
•
14
オブジェクト名
索引毎の圧縮情報、およびその表に定義されている全索引に対して必要な
サイズなどを確認可能
© 2009 ISE Corporation
索引の
索引の圧縮と
圧縮と圧縮効果確認 － 実行例
$ db2 "select count(*) from lineitem1"
1
-----------
550410
1 record(s) selected.
$ db2 "select L_RECEIPTDATE from lineitem1 fetch first 3 rows only"
L_RECEIPTDATE
まだ索引圧縮になっていない
------------1997-12-05
1997-11-09
1993-09-18
非圧縮の場合、圧縮で節約される
リーフページの見積もりが表示さ
れる
3 record(s) selected.
$ db2 "create index id1 on lineitem1(L_RECEIPTDATE)"
DB20000I
The SQL command completed successfully.
$db2 "select substr(indname,1,5) as indname,substr(tabname,1,10) as
tabname,compress_attr,index_compressed,pct_pages_saved,num_leaf_pages_saved from table
(admin_get_index_compress_info('I','IWA97','ID1','-2','-2')) as t"
INDNAME TABNAME
COMPRESS_ATTR INDEX_COMPRESSED PCT_PAGES_SAVED NUM_LEAF_PAGES_SAVED
------- ---------- ------------- ---------------- --------------- -------------------ID1
LINEITEM1
N
N
48
599
1 record(s) selected.
15
© 2009 ISE Corporation
索引の
索引の圧縮と
圧縮と圧縮効果確認 － 実行例 （続き）
$ db2 alter index id1 compress yes
DB20000I
The SQL command completed successfully.
索引圧縮がONになっているが、まだ物理的に圧縮
されていない（INDEX_COMPRESSED がN）状態
$ db2 "select substr(indname,1,5) as indname,substr(tabname,1,10) as
tabname,compress_attr,index_compressed,pct_pages_saved,num_leaf_pages_saved from table
(admin_get_index_compress_info('I','IWA97','ID1','-2','-2')) as t"
INDNAME TABNAME
COMPRESS_ATTR INDEX_COMPRESSED PCT_PAGES_SAVED NUM_LEAF_PAGES_SAVED
------- ---------- ------------- ---------------- --------------- -------------------ID1
LINEITEM1
Y
N
48
599
1 record(s) selected.
$ db2 "select substr(tabname,1,10) as tabname,substr(indname,1,5) as indname,INDEX_OBJECT_P_SIZE from
table(admin_get_index_info('','IWA97','LINEITEM1')) as t"
TABNAME
INDNAME INDEX_OBJECT_P_SIZE
---------- ------- -------------------LINEITEM1
ID1
物理的に非圧縮の場合、節約され
るリーフページの見積もりが表示
される
10240
1 record(s) selected.
この表の全索引に必要な物理
サイズが10240バイト
$ db2 "reorg indexes all for table iwa97.lineitem1"
DB20000I
16
The REORG command completed successfully.
© 2009 ISE Corporation
索引の
索引の圧縮と
圧縮と圧縮効果確認 － 実行例 （続き）
$ db2 runstats on table iwa97.lineitem1 and indexes all
DB20000I
The RUNSTATS command completed successfully.
$ db2 "select substr(indname,1,5) as indname,substr(tabname,1,10) as
tabname,compress_attr,index_compressed,pct_pages_saved,num_leaf_pages_saved from table
(admin_get_index_compress_info('I','IWA97','ID1','-2','-2')) as t"
INDNAME TABNAME
COMPRESS_ATTR INDEX_COMPRESSED PCT_PAGES_SAVED NUM_LEAF_PAGES_SAVED
------- ---------- ------------- ---------------- --------------- -------------------ID1
LINEITEM1
Y
Y
49
525
1 record(s) selected.
$ db2 "select substr(tabname,1,10) as tabname,substr(indname,1,5) as indname,INDEX_OBJECT_P_SIZE from
table(admin_get_index_info('','IWA97','LINEITEM1')) as t"
TABNAME
INDNAME INDEX_OBJECT_P_SIZE
---------- ------- -------------------LINEITEM1
ID1
1 record(s) selected.
17
2432
索引圧縮後は、
SYSCAT.INDEXESの
PCTPAGESSAVEDの値が入る
この表の全索引に必要な物理
サイズが2432バイトに減った
© 2009 ISE Corporation
索引圧縮の
索引圧縮の条件
圧縮表
非圧縮表
CREATE INDEX
COMPRESS YES
圧縮
圧縮
CREATE INDEX
COMPRESS NO
非圧縮
非圧縮
ALTER INDEX
COMPRESS YES
圧縮
圧縮
ALTER INDEX
COMPRESS NO
非圧縮
非圧縮
CREATE INDEX
COMPRESS指定
指定なし
指定なし
圧縮
非圧縮
以前の
以前のリリースより
リリースよりマイ
よりマイ
グレーションされた
グレーションされたDB
された
非圧縮
非圧縮
※表の圧縮属性を変更しても、変更時点で既に存在している索引の圧縮属性は変更されない
18
© 2009 ISE Corporation
（参考）
への負荷
参考）圧縮表の
圧縮表のパフォーマンスと
パフォーマンスとCPUへの
への負荷
ト ラ ン ザ ク シ ョ ン /秒
圧縮表（表圧縮＋圧縮索引（1個）） VS 非圧縮表
9000
8000
7000
6000
5000
4000
3000
2000
1000
0
圧縮表
非圧縮表
Sel
e
圧縮表：
ct
Up
da t
e( 索
Up
引キ
ー列
da t
e (索
以外
）
Ins
er t
引キ
ー列
De
lete
）
索引圧縮+表圧縮
CPU(user)
1 Select
2.6
2 Update(索引キー列以外
2.6
3 Update(索引キー列）
2.6
4 Insert
10.5
5 Delete
2.2
索引圧縮なし+表圧縮なし CPU(user)
6 Select
1.6
7 Update(索引キー列以外
1.6
8 Update(索引キー列）
1.6
9 Insert
6.7
10 Delete
1.7
3分間、10userで計測
IndexBPヒット率(90.5～100%),DataBPヒット率(85.6～99.9%)
非圧縮表： IndexBPヒット率(86.2～100%),DataBPヒット率(73.9～99.7%)
圧縮により、バッファープールヒット率が向上し、パフォーマンスも向上した
Select/Insert/Update/Deleteのすべてにおいて、より有効にCPUが使用されるようになった
19
© 2009 ISE Corporation
使用上の
使用上の考慮点
• MDCブロック索引, カタログ表の索引, index specifications, XMLメタ索引, XMLパス索
引は圧縮対象外
• 圧縮表に対して新しく作成する索引は、明示的にCOMPRESS NOを指定しない限り、
圧縮索引となる
– 一度圧縮索引として作成されたものを非圧縮に戻したい場合には、COMPRESS NOを指定し
てALTER INDEXを実行し、さらに索引再編成を行う
• 非圧縮表に対して新しく作成する索引は、明示的にCOMPRESS YESを指定しない限
り、非圧縮索引となる
– 一度非圧縮索引として作成されたものを圧縮したい場合には、COMPRESS YESを指定して
ALTER INDEXを実行し、さらに索引の再編成を行う
• V9.1、V9.5のデータベースをV9.7に移行しても、索引圧縮は行われない
– 索引圧縮を使用するには、ALTER INDEX・・・COMPRESS YES、およびREORG INDEXを実行
する
20
© 2009 ISE Corporation
ブランク・ページ
21
© 2009 ISE Corporation
一時表の
一時表の圧縮
• 一時表のために
一時表のために必要
のために必要となる
必要となるディスクスペース
となるディスクスペースの
ディスクスペースの削減が
削減が可能
• システム一時表
システム一時表、
一時表、ユーザー一時表
ユーザー一時表とも
一時表とも圧縮対象
とも圧縮対象
• Storage Optimization Featureライセンス
Featureライセンスの
ライセンスの登録によって
登録によって自動的
によって自動的に
自動的に有効化
• DB2の
DB2のオプティマイザーが
オプティマイザーが圧縮するかどうかを
圧縮するかどうかを自動的
するかどうかを自動的に
自動的に判断し
判断し、辞書作成
と圧縮を
圧縮を行う
$ db2pd -db sample –temptable
System Temp Table Stats:
Number of System Temp Tables
Comp Eligible Sys Temps
Compressed Sys Temps
Total Sys Temp Bytes Stored
Total Sys Temp Bytes Saved
Total Sys Temp Compressed Rows
Total Sys Temp Table Rows:
22
:
:
:
:
:
:
:
5
2
2
6831912
16868136
200000
300002
User Temp Table Stats:
Number of User Temp Tables
Comp Eligible User Temps
Compressed User Temps
Total User Temp Bytes Stored
Total User Temp Bytes Saved
Total User Temp Compressed Rows
Total User Temp Table Rows:
:
:
:
:
:
:
:
0
0
0
0
0
0
0
© 2009 ISE Corporation
XMLデータ
データの
の資料を
データの圧縮（
圧縮（詳細は
詳細はXMLの
資料を参照）
参照）
• DB2 V9.5では
V9.5では、
では、指定した
指定したサイズ
したサイズ以下
サイズ以下の
以下のXMLデータ
XMLデータを
データを基礎表に
基礎表に保持可能になった
保持可能になった
– 基礎表に保持させたいXML列を定義する際に「INLINE LENGTH <integer>」キーワードを付加する。
– 下記の例では、10000バイト以下のXMLデータを、ベース表に保持する。
– 基礎表に
基礎表に保持されたものが
保持されたものがV9.5
されたものがV9.5での
V9.5での圧縮対象
での圧縮対象
– V9.7では
V9.7ではXDA
ではXDAオブジェクト
XDAオブジェクトに
オブジェクトに保持された
保持されたXML
されたXMLデータ
XMLデータも
データも圧縮対象
create table dept (deptID char(8),...,doc XML inline length 10000)
データ・
データ・オブジェクト
圧縮可（
圧縮可（V9.5）
V9.5）
23
ID
…
PR27
…
PR28
…
ACC
…
索引オブジェクト
索引オブジェクト
DOC (XML)
XML記述子
Regions
Index
圧縮可（
圧縮可（V9.7）
V9.7）
XDAオブジェクト
オブジェクト(XML
Data)
オブジェクト
© 2009 ISE Corporation
ブランク・ページ
24
© 2009 ISE Corporation
LOBデータ
LOBデータ型
データ型に関連する
関連する処理
する処理パフォーマンス
処理パフォーマンス上
パフォーマンス上の課題
• DB2 V9.1までの課題
LOBを含むSQL処理のパフォーマンスは、LOBを含まない照会、更新
のパフォーマンス（同サイズのVARCHAR等）と比較して遅かった。
LOBがより一般的に使用されるようになったため、パフォーマンスの
改善が求められてきた。
• 原因
V9.5での
改善点
V9.7での
改善点
25
LOBデータは、DRDA上通常データとは別に転送される。
LOB列を含む結果セット1レコードごとに、データのリクエストが必要。
（ブロッキング・カーソルが使用できない）
LOBデータの配置が通常のデータページと異なる場所にあるため、1
レコードの取得のため複数回のI/Oを必要とする。
LOBデータは、バッファープールに載らない。
© 2009 ISE Corporation
LOBデータ
データの
）
データの基礎表への
基礎表への格納
への格納（
格納（LOB Inline）
• インライン格納とは
– LOBデータをLOBオブジェクトではなく、基礎表へ格納する保持形態
– 表の作成時に基礎表へ格納するサイズの上限を指定する。
通常の
保持形態
通常のLOB保持形態
データ・
データ・オブジェクト
ID
…
IMAGE(LOB)
PR27
…
LOB記述子
PR28
…
LOB記述子
ACC
…
LOB記述子
LOBオブジェクト
オブジェクト
インライン格納
保持形態
インライン格納を
格納を使用した
使用したLOB保持形態
した
データ・
データ・オブジェクト
26
ID
…
PR27
…
PR28
…
ACC
…
LOBオブジェクト
オブジェクト
IMAGE(LOB)
LOB記述子
LOBデータが基礎表
に格納されている
© 2009 ISE Corporation
LOBデータ
データの
）
データの基礎表への
基礎表への格納
への格納（
格納（LOB Inline）
• インライン格納のメリット
– バッファープールへの格納対象になるため、READ/WRITEとも飛躍的に高速化
される
– レコード本体への1回のアクセスで処理が完了するため、I/O回数の削減が見込
める
– インライン格納されたLOBデータは行圧縮の対象とすることが可能
27
© 2009 ISE Corporation
インライン格納
インライン格納の
格納の圧縮効果一例
約220MB、10000個のLOBデータをデータベースに投入した際の圧縮効果
•
– 圧縮により格納時のサイズは310MBから約185MBに縮小された
– テストデータは圧縮効果の高いテキストを使用
約100MBはインライン
格納対象外のデータ
350
LOB
データ
300
インライン格納の対象データは、
行圧縮により約60%圧縮された
97
250
ー
デ
200
タ
サ
イ 150
ズ
データサイズの
データサイズの分布
311
97
216
100
50
88
2
-
インライン格納無し
28
インライン格納のみ
インライン格納＋圧縮
サイズ
個数
8KB以下
409
8～16KB
2561
16～32KB
5488
32～50KB
1542
© 2009 ISE Corporation
LOBデータ
データ インライン格納
インライン格納の
格納の効果的な
効果的な使用法
• 一定比率のLOBデータがページサイズより小さいこと
– すべてのLOBデータが32KBを越えるデータの場合、インライン格納を指
定しても効果無し
– インライン格納の比率を上げるため、ページサイズは32KBが推奨
◆インライン格納
インライン格納が
効果的なデータ
格納が効果的な
ほとんどのデータが32KB以下に分布して
いるため、基礎表への格納率が高い。
◆インライン格納
インライン格納の
効果が薄いデータ
格納の効果が
ほとんどのデータが32KB以上に分布して
いるため、ほとんど基礎表へ格納されない。
1000
1000
ー
デ 800
ー
デ
タ 600
の
400
個
数 200
タ
の
個 400
数
0
0
600
200
16
29
800
32
48
64
80
96 112
16
32
48
64
80
96 112
© 2009 ISE Corporation
インライン格納
インライン格納を
格納を有効にする
有効にするSyntax
にする
– CREATE TABLE時もしくはALTER TABLE時に、LOB列にINLINEキーワードを追加する。
– 指定できる長さの最大長は、ページサイズごとの行の最大長以下。（4KBページでは
4005byte）
他の列を含めたトータルのレコード長が、制限値以下になるよう調整する。
– 表の新規作成時に指定する場合
create table T1 (..., doc CLOB inline length 10000)
– 既存の表のLOB列に対して追加する場合
alter table T1 alter column doc set inline length 10000
– インライン格納が有効になっていることの確認
select tabname, data_object_p_size, lob_object_p_size, data_object_p_size + lob_object_p_size
total_size from sysibmadm.admintabinfo where tabname like 'LOB%'
30
TABNAME
DATA_OBJECT_P_SIZE
LOB_OBJECT_P_SIZE
TOTAL_SIZE
--------------- -------------------- -------------------- -------------------LOB1
2048
318464
320512
LOB2_INLINE
221184
99328
320512
LOB3_INCOMP
90112
99328
189440
3 record(s) selected.
LOBデータサイズが小さく
なっていることが確認できる
© 2009 ISE Corporation
新しい関数
しい関数（ADMIN_IS_INLINE/ADMIN_EST_INLINE_LENGTH)
インライン化されているかどうかを示す関数
•
>>-ADMIN_IS_INLINLINED--(--columun-name--)-----------------------><
–
columun name
基本表の列名
（戻り値）
1
データがインライン化されていることを示す
0
データがインライン化されていないことを示す
NULL
入力がNULLであることを示す
インラインLOBのデータ長を確認するための関数
•
>>-ADMIN_EST_INLINE_LENGTH--(--columun-name--)-----------------------><
–
columun name
基本表の列名
(戻り値）
31
数値
データの見積もりインライン長
-1
データがインライン化されていないことを示す
-2
バージョン9.7より前のバージョンのときに挿入されたデータのため判別不可
能であることを示す
© 2009 ISE Corporation
使用例
$ db2 "create table a(c1 int,lob clob inline length 10000)"
DB20000I
The SQL command completed successfully.
$ db2 "create table b(c1 int,lob clob)"
DB20000I
The SQL command completed successfully.
LOB INLINEの指定
$ db2 load from a.del of del lobs from htmldata insert into a
（省略）
Number of rows read
= 10
Number of rows skipped
=0
Number of rows loaded
= 10
Number of rows rejected
=0
Number of rows deleted
=0
Number of rows committed
= 10
$ db2 "select admin_is_inlined(lob),admin_est_inline_length(lob) from a"
1
2
------ ----------1
7263
1
7437
1
8525
1
6588
32
INLINEに指定したLOBデータ長
(10000)で格納できるものは、”1”
となっている
© 2009 ISE Corporation
使用例
(続き）
1
7119
1
5912
1
4987
0
11042
0
10117
1
8284
LOBデータが10000を超えている
ため、INLINE格納ができていない
（“0”となっている）。この場合、
INLINEで格納する場合に必要と
なるLOBデータ長が示される。
10 record(s) selected.
$ db2 load from a.del of del lobs from htmldata insert into b
(省略）
Number of rows read
= 10
Number of rows skipped
=0
Number of rows loaded
= 10
Number of rows rejected
=0
Number of rows deleted
=0
Number of rows committed
33
= 10
© 2009 ISE Corporation
使用例
$ db2 "select admin_is_inlined(lob),admin_est_inline_length(lob) from b"
1
2
------ ----------0
-1
0
-1
0
-1
0
-1
0
-1
0
-1
0
-1
0
-1
0
-1
0
-1
INLINE指定していないため、-1
となっている
10 record(s) selected.
34
© 2009 ISE Corporation
LOBデータ
データ インライン格納
インライン格納 使用上の
使用上の考慮点
•
INLINEに入りきらないLOBデータは今までどおりLOBオブジェクトに格納される
•
LOBをINLINE化することにより、1ページ内に格納できる行数が少なくなるため、
LOB列を照会結果に含めない場合は今までよりもパフォーマンスが劣化する可
能性がある
•
INLINE化されたLOBデータはロギングの対照となる
•
INLINE化されたLOBデータを含む表のデータ再編成の処理時間はINLINE化し
ない場合よりも延びる傾向がある
35
© 2009 ISE Corporation
ブランク・ページ
36
© 2009 ISE Corporation