第6章 DB2の特徴的な機能紹介

＜２００９年１２月＞
第６章 DB2の特徴的な機能紹介
本書に含まれている情報は、正式なIBMのテストを受けていません。また、明記にしろ、暗黙的にしろ、なんらの保証もなしに配布されるものです。
この情報の使用またはこれらの技術の実施は、いずれも、使用先の責任において行われるべきものであり、それらを評価し、実際に使用する環境に統合する
使用先の判断に依存しています。それぞれの項目は、ある特定の状態において正確であることがIBMによって調べられていますが、他のところで同じまたは同
様の結果が得られる保証はありません。これらの技術を自身の環境に適用することを試みる使用先は、自己の責任において行う必要があります。
© Copyright IBM Japan Co., Ltd. 2009
内容
• Workload Manager
• パーティショニング機能
• 行圧縮機能
• pureXML
• オンラインでの表移動
2
© 2009 IBM Corporation
Workload Manager
3
© 2009 IBM Corporation
DB2 Workload Manager (WLM) 概要
•
•
•
•
きめ細かいワークロードの識別・分類
閾値による制御 （コスト、実行並行度、実行時間 etc）
実行優先度の制御
目的に応じたレポーティング
ワークロード
識別・分類
WORKLOAD
SERVICE
CLASS
DB2エンジンに組み
込まれた機能
Workload
Manager
目的ごとに
レポート
実行優先度の制御
WORKLOAD
暴走クエリーの閾値制御
4
© 2009 IBM Corporation
１．ワークロード分類し、サービスクラスに誘導
• WORKLOAD
•
•
接続ユーザー/アプリケーション名などによりアクティビティーを分類
SERVICECLASSに誘導
• SERVICE CLASS
•
分類されたアクティビティーが実行される環境
アクティビティーの分類と誘導
WORKLOAD
SERVICE
CLASS
アクティビティー実行環境
優先度を
上げる
SC_HIGH
APPL1
接続USER=USER10
WL_HIGH
個別にレ
ポート
WL_LOW
APPL2
SC_LOW
接続USER=USER20
DB2
5
優先度を
下げる
個別にしき
い値監視
© 2009 IBM Corporation
２．閾値によるワークロードの制御
①Predictive：
予測的しきい
値の評価
アクティビティー
実行終了
例） 見積もりコストが10万を超えるアク
ティビティーは実行しない
アクティビティー
実行開始
・ESTIMATEDCOST
②Proactive
：並列度のし
きい値評価
アクティビティー
実行の要求
例） アクティビティの並列度が
10を超えた場合はキューに待
機させる。
・TOTALSCPARTITIONCONNECTIONS
・CONCURRENTDBCOORDACTIVITIES
・CONCURRENTWORKLOADOCCURRENCES
6
③Reactive：
反応的しきい
値の評価
(進行中)
例）異常に長い時間がかかっ
ている処理や、検索結果行が
膨大な処理を検出し停止する
・TOTALDBPARTITIONCONNECTIONS
・CONCURRENTWORKLOADACTIVITIES
・SQLROWSRETURNED
・ACTIVITYTOTALTIME
・CONNECTIONIDLETIME
・SQLTEMPSPACE
© 2009 IBM Corporation
V9.
7
3.設定可能なしきい値の種類
しきい値
説明
Predictive （予測的）
ESTIMATEDSQLCOST
見積もりコスト
Proactive（並列度）
CONCURRENTDBCOORDACTIVI
TIES
同時並行実行数
QUEUEDACTIVITIES
キュー待機
SQLROWSRETURNED
結果行数
ACTIVITYTOTALTIME
合計実行時間
CONNECTIONIDLETIME
接続アイドル時間
SQLTEMPSPACE
一時表スペース使用量
AGGSQLTEMPSPACE
一時表スペース使用量
（サービスクラス毎）
CPUTIME
CPU時間
SQLROWSREAD
読み込み行数
CPUTIMEINSC
CPU時間
（REMAP ACTIVITY用）
SQLROWSREADINSC
読み込み行数
（REMAP ACTIVITY用）
Reactive（反応的）
例えば「1000行以上の大量
検索は許可しない」という制
限が可能に。
7
V9.7
NEW!
© 2009 IBM Corporation
4．SERVICE CLASSによる実行優先度の調整
• サービスクラスは、作業グループに対するユニークな実行環境
•
それぞれのサービスクラスに異なるリソース優先度を割り当てる
• サービスクラスで利用可能なリソースの調整
•
CPU優先度制御 (AGENT PRIORITY)
• AIX WLMとの連携による詳細な管理が可能
•
I/Oプリフェチ優先度制御(PREFETCH PRIORITY)
AGENT PRIORITY,
PREFETCH PRIORITYを
設定する。
• 設定値: HIGH, MEDIUM, LOW
WORKLOAD
接続ユーザー
などで分類
WL_HIGH
優先度の高い処理
SERVICE CLASS
SC_HIGH
優先度の高い
サービスクラス
で実行
SC_LOW
WL_LOW
優先度の低い処理
8
優先度の低
いサービスク
ラスで実行
© 2009 IBM Corporation
パーティショニング機能
9
© 2009 IBM Corporation
DB2機能によるアクセス効率の向上
• アクセス効率向上
• パーティションDB
• データベースの区分化による性能向上
• クエリーを複数CPUにより並列処理
• データ分割による効率化
• スケーラブルな拡張性
• 可用性向上（パーティションレベル）
データ
データ
ログ
データ
ログ
データ
APR
MAY
ログ
データベース
履歴表A
• パーティション表
• 表の区分化による性能向上
• 特定レンジのみアクセス
• データの高速追加／削除
• 可用性向上（表スペースレベル）
ログ
JAN
区分の
デタッチ
FEB
MAR
区分の
アタッチ
JAN
MAY
• マルチディメンション・クラスタリング（MDC）表
• 表のクラスター化による性能向上
• ブロックレベルでのアクセス
• ブロック索引による効率化
• データの高速追加／削除
10
セル
© 2009 IBM Corporation
ハイ・パフォーマンスを支える並列処理
Database Partitioning Feature（DPF）による並列処理
１０００区分までのスケーラビリティー
透過的データアクセス
アプリケーションは意識することなく、複数サーバーによるス
ケールアウトにより、並列処理を実現します。
•
データベースの区分を持つサーバー群
• 全体で１つのデータベース
• パラレル・オプティマイザーと高速通信経路で接続
•
ハッシングにより均等にデータ分散
アプリケーション
ＤＢ２クライアント
どの区画に接続しても
同じ結果が返ってきます
CPU
CPU
CPU
１００TBのDBも１００区分で
１TBのDB設計と同じ
CPU
CPU
アプリケーション
ＤＢ２クライアント
CPU
データベース
区画1
データベース
区画2
データベース
区画3
メモリー
メモリー
メモリー
データ
データ
データ
CPU
・・・
CPU
データベース
区画N-1
メモリー
データ
CPU
CPU
データベース
区画N
メモリー
データ
単一データベース
11
© 2009 IBM Corporation
ハイ・パフォーマンスを支えるパーティション表
•
ひとつの表を複数の区分に分割
•
古い区分を高速にロールアウト （区分のデタッチ）
•
既存データはオンライン状態で、新しい区分をロールイン （区分のアタッチ）
•
区分単位でのアクセス性能向上
•
各区分は異なる表スペースに配置可能
パーティション表
日付などのレンジで区分に分割し整理する
売上履歴表
過去のデータは
まとめて瞬時に
切り離し
DETACH
Jan
Feb
Mar
Apr
ATTACH
新規データを個
別にLOADして
から区分を取り
付け
Jan
読みたい区分の
みにアクセス
12
© 2009 IBM Corporation
ハイ･パフォーマンスを支える多次元分析機能
•
多次元クラスタリング（MDC)とは
•
複数属性の値によってデータを分類して自動的に格納する機能
•
単一属性のクラスタでは実現できなかった「2008年9月」の「DB2」の「東京」というような複数の属
性をもつクラスタ
•
次元別検索のパフォーマンス向上
•
データ並べ替えを目的とした再編成不要
•
削除のパフォーマンスアップ（ブロック削除が可能）
•
索引のサイズが小さい（索引はブロック・ベース（BID））
BID
•
レコードベースの通常の索引も同時に作成可能
サマリー表作成など
集計バッチにも効果
大
ブロック
レコード
作成SQL例：
セル
CREATE TABLE MDC1 (
Date DATE,地域 CHAR(10),製品 VARCHAR(10),
年月 generated always as (INTEGER(Date)/100), ... )
製品
ORGANIZE BY DIMENSIONS (年月, 地域, 製品)
次元
列名指定のみでメ
ンテナンス不要
13
2008
2008年
年8月,
東京,
東京
,
2008
2008年
年9月, 2008
2008年
年9月,
DB2
東京,
東京,
東京,,
東京
DB2
DB2
2008
2008年
年8月,
大阪,,
大阪
2008
2008年
年9月, 2008
2008年
年9月, Webspher
大阪,,
大阪
e
大阪,,
大阪
Webspher Webspher
e
e
地域
次元
年月
次元
© 2009 IBM Corporation
通常の表に保管されたデータ
必要な行へのアクセスのために大
量の不要な行も読み込む
ひとつのクエリーを処理するのはひ
とつのCPUのみ。
14
© 2009 IBM Corporation
複数パーティションにハッシュ分割（DBパーティショ
ン）
P1
P2
P3
 ひとつのクエリーを複数のCPUを
使って並列に処理することができる
15
© 2009 IBM Corporation
複数パーティションにハッシュ分割して並列処理
P1
P2
P3
依然として不要なI/Oは存在。
可用性を損なうことなく大量
データの入れ替えを行いたい。
16
© 2009 IBM Corporation
データをレンジ分割して保存（パーティション表）
P1
P2
P3
Jan
Feb
条件に合致したパーティショ
Mar
ンのみを参照すればよい
パーティションの高速削除と
追加が可能
17
© 2009 IBM Corporation
データをレンジ分割して保存（パーティション表）
P1
P2
P3
Jan
Feb
Mar
未だ不要なI/Oが残っている
18
© 2009 IBM Corporation
各行をブロックに整理して保管（多次元クラスター表）
P1
P2
P3
Jan
Feb
同じ値を持った行同士を同じ
ブロックに集めて保管。
Mar
必要な行を取り出すための
I/Oが最小限で済む
19
© 2009 IBM Corporation
各行をブロックに整理して保管（多次元クラスター表）
P1
P2
P3
Jan
Feb
Mar
これ以上I/Oの効率を上げるこ
とはできないか？？？
20
© 2009 IBM Corporation
各ブロックに格納される行数を増やす（行圧縮）
P1
P2
P3
Jan
Feb
各ブロックにより多くの行を保管
し、ディスク容量の削減が可能。
Mar
必要な行を取り出すためのI/O
がさらに少なくなる。
21
© 2009 IBM Corporation
ブランク・ページ
22
© 2009 IBM Corporation
行圧縮機能
23
© 2009 IBM Corporation
DB2でのデータ圧縮技術の歴史
• V8 GA～
• テーブル作成時の「VALUE COMPRESSION」
• V8 FixPak 4～
• バックアップイメージの圧縮
• V9.1
• 表の行圧縮 (Row Compression)の登場
• V9.5
• 辞書メンテナンスの機能強化 (ADC)
• V9.7
•
•
•
•
24
索引の圧縮
一時表の圧縮
XML（XDA）の圧縮
インラインLOBデータの圧縮
業界では
DB2のみ
© 2009 IBM Corporation
圧縮することのメリット
ディスク使用量の削減
 特に、繰り返しデータがあるような場合に効果的
バッファー・プールの使用率向上
 より多くのデータが圧縮された状態でバッファープールに乗るため、
バッファープールヒット率の向上が期待できる
 ディスクへの読み書き量が削減できるため、特にI/Oネックのシステム
にはパフォーマンス向上の効果がある
ログ・ファイルへの書き出し量が削減される
25
© Copyright IBM Japan Systems Engineering Co., Ltd. 2009
行圧縮機能の概要
• 辞書を使った行レベルのデータ圧縮 （V9.1～）
• 辞書には、レコードにある特定のパターンが記録される
• ディスク使用量の削減
• より多くのデータが圧縮された状態でバッファープールに乗るため、バッファープール
ヒット率の向上が期待できる
• ディスクへの読み書き量が削減できるため、特にI/Oネックのシステムにはパフォー
マンス向上の効果がある
名前
部署
給与
都道府県
区・市
郵便番号
Fred
500
10000
東京都
港区
24355
John
500
20000
東京都
港区
24355
Fred
500
10000
東京都
港区
24355
John
500
20000
東京都
港区
24355
…
ディクショナリー
Fred
(01)
10000
(02)
John
(01)
20000
(02)
…
01
500
02
東京都, 港
区,24355
… …
26
© 2009 IBM 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するまでは、圧縮された状態で保持される
27
© 2009 IBM 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
•
28
オブジェクトのスキーマ名
objectname
•
•
オブジェクトタイプ（表：’T’ or NULL、索引：’I’ )
データ・パーティション番号（非データ・パーティション環境：’-2’ or ‘0’or NULL)
圧縮属性の確認、および圧縮によって節約できるリーフページ数の見積もり
などが可能
© 2009 IBM Corporation
新しい表関数②（ADMIN_GET_INDEX_INFO)
>>-ADMIN_GET_INDEX_INFO--(--objecttype--,,--objectschema--,--objectname--)--------------------------><
•
Objecttype
•
•
Objectschema
•
•
29
オブジェクトスキーマ
Objectname
•
•
オブジェクトタイプ（表：’T’ or NULL、索引：’I’ )
オブジェクト名
索引毎の圧縮情報、およびその表に定義されている全索引に対して必要
なサイズなどを確認可能
© 2009 IBM Corporation
索引圧縮の条件
圧縮表
非圧縮表
CREATE INDEX
COMPRESS YES
圧縮
圧縮
CREATE INDEX
COMPRESS NO
非圧縮
非圧縮
ALTER INDEX
COMPRESS YES
圧縮
圧縮
ALTER INDEX
COMPRESS NO
非圧縮
非圧縮
CREATE INDEX
COMPRESS指定なし
圧縮
非圧縮
以前のリリースよりマイ
グレーションされたDB
非圧縮
非圧縮
※表の圧縮属性を変更しても、変更時点で既に存在している索引の圧縮属性は変更されない
30
© 2009 IBM 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が使用されるようになった
31
© 2009 IBM 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を実行する
32
© 2009 IBM Corporation
DB2 pureXML機能概要
33
© 2009 IBM Corporation
DB2 pureXMLの歩み
V9.7
XMLウェアハウスへ
DPF
V9.5
MDC
pureXML機能強化
パーティション表
V9.1
Inline格納
XDA圧縮
pureXMLサポート
部分更新
オンライン索引再編成/索引作成
XML基本機能
XSLT
UDF
XML列/索引
スキーマエボリューション
Global Temporary Table
XQuery
Replication
複数文書のdecompositoin
各種ユーティリティ
Load
parse/validationの詳細エラー
34
© 2009 IBM Corporation
DB2におけるXMLデータの格納
• DB2のpureXML機能では、XMLデータを保持するための「XMLデータ型」を提供する
• XMLデータ型はリレーショナル表の中に定義し、レコードの中の1カラムとして取り扱う
• XMLデータは分解(Parse)されDOMに似た階層型のフォーマット(XDM)で格納される
•
照会時にはParseしない
• XML格納方法は2通り - inline格納/XDA(XML Data Area)格納
insert into dept values (1,……, ’<dept><emp>夏目漱石</emp></dept>’)
dept表の論理構造
inline格納する表の定義
deptID
…
deptdoc
1
…
<dept> …
create table dept (deptID int,…,
deptdoc xml inline length 10000 )
<emp>夏目漱石</emp>
</dept>
…
リレーショナル
deptID
…
…
XML
deptdoc
1
inline格納時のdept表の物理構造
35
XDA格納する表の定義
create table dept
(deptID int,…, deptdoc xml)
…
LOBと類似だが
bufferpoolを使用
リレーショナル
deptID
XML
XDA(XML Data Area)
deptdoc
XML記述子
regions
index
XMLデータ
XDA格納時のdept表の物理構造
© 2009 IBM Corporation
XML照会の２つの方法
DB2 SERVER
CLIENT
DB2 Client /
Customer Client
Application
SQL/XML
Relational
Interface
XQuery
XML
Interface
DB2 Storage:
DB2
Engine
Relational
XML
• XQueryを主言語とする
• W3C XQuery標準で定義
• V9新機能
• XQueryにSQLを組み込むことも可能
• SQLを主言語とする
• SQL/XML(SQLのXML用関数)の使用
• SQL標準で定義
• V8からサポート、V9で拡張
• SQLにXQueryを組み込むことができる
36
© 2009 IBM Corporation
XML索引
• XMLカラムに対してユーザーが索引を作成
•
索引対象は、要素、属性
•
XML索引は、CREATE INDEXステートメント中xmlpattern(XPath)を記述して指定
•
XMLのデータ型はSQLデータ型にマップされる。
CREATE INDEX empindex ON company(docs)
GENERATE KEY USING XMLPATTERN '/company/emp/@id' AS SQL DOUBLE
•
COMPANY表
1row
1row
37
XML索引を使って検索を実行
• ANDing/ORing
COMPANYDOC (XMLデータタイプ列）
(XML
<company name="Company1">
<emp id="31201" salary="60000" gender="Female">
<name><first>Laura </first><last>Brown</last></name>
<dept id="M25">Finance</dept>
</emp>
</company>
<company name="Company2">
<emp id="31664" salary="60000" gender="Male">
<name><first>Chris</first><last>Murphy</last></name>
<dept id="M55">Marketing</dept>
</emp>
<emp id="42366" salary="50000" gender="Female">
<name><first>Nicole</first><last>Murphy</last></name>
略
EMPINDEX索引
COMPANYDOC
(DOUBLE)
31201
31664
42366
DOUBLE型の索引が作成される
© 2009 IBM Corporation
XMLスキーマ対応
•
DB2は、XMLスキーマによるXMLインスタンスの妥当性検査をサポートする
• XMLスキーマをXSR (XML Schema Repository)へ登録する必要がある
•
DB2では、妥当性検査はXMLインスタンス単位で行う
• 妥当性検査を行うかどうか、どのXMLスキーマを使用するかは任意
• １つのカラムに妥当性検査済みのXMLインスタンスと、検査されていないXMLインスタ
ンスが混在しても良い
• １つのカラムに異なるXMLスキーマで妥当性検査されたXMLインスタンスが混在しても
良い
XML
• INSERT,IMPORT, (UPDATE)によるXMLインスタンスの投入時に実施可能
文書
38
登録
XSR
DB2
INSERT
XML
Schema
システム・カタログ
XML
Schema
Validate
Validな
(妥当な)
XML
文書
© 2009 IBM Corporation
pureXML in DB2 V9.7
DPF
DB2 XML Support
MDC
2008年
2008年
9月,
東京,,
東京
2008年
2008
DB2年
9月, 大
阪,
Webs
phere
XML
2008年
2008年
2008年
2008年 8月, 東
9月,
京,
2008年
2008年
東京,, DB2
東京
8月, 大
2008年
2008
DB2年
9月, 大 阪,
阪, Webs
Websp phere
here
データ
ウェアハウス
文書系XMLデータの
パーティション表
J
a
n
F
e
b
M
ar
管理/加工/検索
A
pr
大量のXMLデータ
文書サイズが大きいXMLデータ
圧縮
•マニュアル
•報告書/申請書
•条例/省令
•カルテ
39
など
© 2009 IBM Corporation
XML表の作成 – DPFサポート
• DPF環境でもXML列を含む表の作成が可能
• DPF環境の既存の表にALTER TABLEでXML列の追加が可能
• どのパーティションからでもXSRオブジェクト(XMLスキーマなど)の登録/
検索が可能
• SQL/XML, XQueryのパラレル実行可能
• パラレルのLOADが可能
• 制約
CREATE TABLE table1 (
col1 int,
col2 xml,
DISTRIBUTE BY HASH(col1))
• XML列をdistribution keyにすることはできない
• distribution keyを持つXML表に対しuniqueなXML索引を持てない
• V9.1/V9.5のXMLフォーマットを持つ表はDPF環境に分散できない
=> 表の再作成またはADMIN_MOVE_TABLEによる移行が必要
40
© 2009 IBM Corporation
XML表の作成 – MDCサポート
• XML列を含むMDC表の作成が可能
• MDC表にALTER TABLEでXML列の追加が可能
• MDCブロック索引と、XML索引を合わせて使用することが可能
CREATE TABLE MDC1 (
製品 VARCHAR(10),
製品明細 XML)
ORGANIZE BY DIMENSIONS (製品)
• 制約
• XML列を次元(ORGANIZE BY節)に指定することはできない
41
© 2009 IBM Corporation
XML表の作成 – パーティション表サポート
• XML列を含む表をパーティション表にすることが可能
• パーティション表に対してALTER TABLEでXML列の追加が可能
• XDA用の表スペースは、パーティション表の表スペースに置くことも、
別表スペースに置くことも可能
CREATE TABLE t1(c1 INT, c2 INT, c3 XML)
IN tbsp1, tbsp2, tbsp3
LONG IN tbsp6, tbsp7, tbsp8
PARTITION BY RANGE(c1)
(STARTING FROM 1 ENDING 90 EVERY 30)
• 制約
• XML列をpartition keyに
することはできない
tbsp1
tbsp2
tbsp3
t1.p1
t1.p2
t1.p3
XDA1
XDA2
XDA3
tbsp6
tbsp7
tbsp8
• XML索引はpartitioned index
(ローカル索引)にすることはできない
42
© 2009 IBM Corporation
XMLデータの圧縮
•
DB2 V9.5では、基礎表に保持されたものがV9.5での圧縮対象
•
V9.7ではXDAオブジェクトに保持されたXMLデータも圧縮対象
create table dept (deptID char(8),...,doc XML inline length 10000)
データ・オブジェクト
圧縮可（V9.5）
43
ID
…
PR27
…
PR28
…
ACC
…
索引オブジェクト
DOC (XML)
XML記述子
Region
s
Index
圧縮可（V9.7）
XDAオブジェクト(XML Data)
© 2009 IBM Corporation
XMLデータの圧縮方法
create table dept (deptID char(8),...,doc XML) compress yes
• 圧縮辞書の作成
• REORG TABLE （RESETDICTIONARYオプション）
• すでに表にデータがある場合(ALTER TABLE COMPRESS YESで表属性を変更し
REORG)
• Automatic Dictionary Creation （ADC）
• V9.5から
• 表に一定量のデータが挿入されると自動的に辞書が作成され、データが圧縮される
• LOAD REPLACE
• V9.5から
• 新規のテーブル作成/データを一時ExportしてLoadしなおす場合
• 自動的な辞書の作成または既存辞書の再利用が可能
• XDA圧縮辞書が作成されないケース （SQL2220Wが返される）
• REORG、LOAD REPLACEを実行したが、XDAオブジェクトが空の場合
• XMLデータがV9.1、V9.5からのマイグレーションによるものの場合
• V9.7版のXDAフォーマットにするため、表の再作成が必要
• ADMIN_MOVE_TABLEプロシージャー（V9.7新機能）を使用可能
44
© 2009 IBM Corporation
XML索引の圧縮
• ユーザー定義XML索引の圧縮可能
• 索引圧縮はV9.7新機能
• COMPRESS YESと指定された表に対する索引は自動的に圧縮
• CREATE INDEXで明示的に圧縮モードを指定
(COMPRESS [YES|NO])
45
© 2009 IBM Corporation
ブランク・ページ
46
© 2009 IBM Corporation
表のオンライン移動機能
ADMIN_MOVE_TABLEプロシージャー
47
© 2009 IBM Corporation
表のオンライン移動機能: ADMIN_MOVE_TABLEプロシージャー
表の読み書きを可能にしたまま、表を移動する
⇒ これまで表の再作成が必要だった変更作業をオンラインで実施できる
• 別の表スペースへの移動
• ディスク配置の変更
• 表スペース作成時に表スペース単位で決定される定義の変更
（例：ページ・サイズ、エクステント・サイズなど）
• 表の定義情報の変更
例えば…
•
•
•
•
索引定義
MDC表の次元列 (MDC表において各行の格納されるブロックを決定する列)
パーティション表のレンジ定義
別 表スペース
表スペース
データの圧縮/非圧縮/再圧縮
Ｃ１
Ｃ２
Ｃ１
Ｃ２
INSERT,
DELETE,
UPDATE
48
© 2009 IBM Corporation
表のオンライン移動機能の仕組み
表スペース１
INSERT,
DELETE,
UPDATE
表スペース2
① ターゲット表
ソース表
Ｃ１
Ｃ２
②
Ｃ１
Ｃ２
表移動の5つのステップ
① 初期化
(INIT)
－移動先表、トリガー、
ステージング表作成
－定義情報変更
④
② コピー (COPY)
トリガー
③
①
②
① ステージング表
表スペース1から表スペース2へ 表を移動させる場合
推奨：
・ソース表にユニーク索引をつける
－差分データ更新される行が1つになるため
・作成ディスク・スペース容量を十分に確保する
－ソース表に加え、 ターゲット表、ターゲット表に付随する索引、ステージング表の
ための領域が必要、また、コピーに伴って必要となるログ量も考慮する必要がある
49
－データ・コピー
－変更データ情報を
ステージング表格納
③ リプレイ(REPLY)
－ステージング表からの
差分データ反映
④ 切り替え(SWAP)
※アクセス不可
⑤ クリーンアップ
(CLEANUP)
※keepオプション(元表保持)
© 2009 IBM Corporation
Let’s go Lab7!!
50
© 2009 IBM Corporation