Comments
Description
Transcript
DB2 V9.7新機能ワークショップ 圧縮 圧縮機能強化 機能強化
DB2 V9.7新機能ワークショップ <第1.00版 2009年 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