第6章 db2の特徴的な機能紹介 - ibmdatabase partitioning...

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

本書に含まれている情報は、正式なIBMのテストを受けていません。また、明記にしろ、暗黙的にしろ、なんらの保証もなしに配布されるものです。

この情報の使用またはこれらの技術の実施は、いずれも、使用先の責任において行われるべきものであり、それらを評価し、実際に使用する環境に統合する使用先の判断に依存しています。それぞれの項目は、ある特定の状態において正確であることがIBMによって調べられていますが、他のところで同じまたは同様の結果が得られる保証はありません。これらの技術を自身の環境に適用することを試みる使用先は、自己の責任において行う必要があります。

© Copyright IBM Japan Co., Ltd. 2009

＜２００９年１２月＞

内容

• Workload Manager

• パーティショニング機能

• 行圧縮機能

• pureXML

© 2009 IBM Corporation2

• オンラインでの表移動

Workload Manager


WorkloadWorkloadManagerManagerWorkloadWorkloadManagerManager

DB2 Workload Manager (WLM) 概要

ワークロード識別・分類目的ごとに

レポートSERVICE CLASS

• きめ細かいワークロードの識別・分類

• 閾値による制御（コスト、実行並行度、実行時間 etc）

• 実行優先度の制御

• 目的に応じたレポーティング

DB2エンジンに組み込まれた機能


暴走クエリーの閾値制御

実行優先度の制御

レポートWORKLOAD

CLASS

WORKLOAD

SERVICE CLASS

１．ワークロード分類し、サービスクラスに誘導

WORKLOAD

アクティビティーの分類と誘導アクティビティー実行環境

• WORKLOAD• 接続ユーザー/アプリケーション名などによりアクティビティーを分類

• SERVICECLASSに誘導

• SERVICE CLASS• 分類されたアクティビティーが実行される環境


CLASS

WL_HIGH

WL_LOW

DB2

SC_HIGH

SC_LOW

APPL1

接続USER=USER10

APPL2

接続USER=USER20

優先度を下げる

優先度を上げる

個別にレポート

個別にしきい値監視

WORKLOAD

２．閾値によるワークロードの制御

アクティビティー実行開始

アクティビティー実行終了

③Reactive：反応的しきい

例）見積もりコストが10万を超えるアクティビティーは実行しない①Predictive：

予測的しきい値の評価

・ESTIMATEDCOST


②Proactive：並列度のしきい値評価

アクティビティー実行の要求

反応的しきい値の評価(進行中)

例）異常に長い時間がかかっている処理や、検索結果行が膨大な処理を検出し停止する

例）アクティビティの並列度が10を超えた場合はキューに待

機させる。

・TOTALSCPARTITIONCONNECTIONS・CONCURRENTDBCOORDACTIVITIES・CONCURRENTWORKLOADOCCURRENCES

・TOTALDBPARTITIONCONNECTIONS・CONCURRENTWORKLOADACTIVITIES・SQLROWSRETURNED・ACTIVITYTOTALTIME・CONNECTIONIDLETIME・SQLTEMPSPACE

しきい値説明

Predictive （予測的） ESTIMATEDSQLCOST 見積もりコスト

Proactive（並列度） CONCURRENTDBCOORDACTIVITIES

同時並行実行数

QUEUEDACTIVITIES キュー待機

Reactive（反応的） SQLROWSRETURNED 結果行数

ACTIVITYTOTALTIME 合計実行時間

3.設定可能なしきい値の種類V9.7

V9.7


ACTIVITYTOTALTIMECONNECTIONIDLETIME 接続アイドル時間

SQLTEMPSPACE 一時表スペース使用量

AGGSQLTEMPSPACE 一時表スペース使用量

（サービスクラス毎）

CPUTIME CPU時間

SQLROWSREAD 読み込み行数

CPUTIMEINSC CPU時間

（REMAP ACTIVITY用）

SQLROWSREADINSC 読み込み行数

（REMAP ACTIVITY用）

V9.7 NEW!

例えば「1000行以上の大量検索は許可しない」という制限が可能に。

4．SERVICE CLASSによる実行優先度の調整

• サービスクラスは、作業グループに対するユニークな実行環境

• それぞれのサービスクラスに異なるリソース優先度を割り当てる

• サービスクラスで利用可能なリソースの調整

• CPU優先度制御 (AGENT PRIORITY)• AIX WLMとの連携による詳細な管理が可能

• I/Oプリフェチ優先度制御(PREFETCH PRIORITY)• 設定値: HIGH, MEDIUM, LOW AGENT PRIORITY,


• 設定値: HIGH, MEDIUM, LOW

WL_HIGH

SC_HIGH

SC_LOW

WORKLOAD SERVICE CLASS

WL_LOW

優先度の高い処理

優先度の低い処理

優先度の高いサービスクラス

で実行

優先度の低いサービスクラスで実行

接続ユーザーなどで分類

AGENT PRIORITY,PREFETCH PRIORITYを設定する。

パーティショニング機能


• アクセス効率向上

• パーティションDB• データベースの区分化による性能向上

• クエリーを複数CPUにより並列処理

• データ分割による効率化

• スケーラブルな拡張性

• 可用性向上（パーティションレベル）

DB2機能によるアクセス効率の向上

データベース

データログデータログデータログデータログ

履歴表A


• パーティション表

• 表の区分化による性能向上

• 特定レンジのみアクセス

• データの高速追加／削除

• 可用性向上（表スペースレベル）

• マルチディメンション・クラスタリング（MDC）表

• 表のクラスター化による性能向上

• ブロックレベルでのアクセス

• ブロック索引による効率化

• データの高速追加／削除

履歴表A

JAN区分のデタッチ

MAY

MAY区分のアタッチ

JAN FEB MAR APR

セル

ハイ・パフォーマンスを支える並列処理

Database Partitioning Feature（DPF）による並列処理

アプリケーションは意識することなく、複数サーバーによるスケールアウトにより、並列処理を実現します。

• データベースの区分を持つサーバー群

• 全体で１つのデータベース

• パラレル・オプティマイザーと高速通信経路で接続

• ハッシングにより均等にデータ分散

アプリケーションＤＢ２クライアント

どの区画に接続しても同じ結果が返ってきます

１０００区分までのスケーラビリティー１０００区分までのスケーラビリティー

透過的データアクセス透過的データアクセス

アプリケーションＤＢ２クライアント

１００TBのDBも１００区分で１TBのDB設計と同じ


単一データベース

データベース区画1

CPUCPU

メモリー

データ

・・・


CPUCPU

メモリー

データ


CPUCPU

メモリー

データ

データベース区画N

CPUCPU

メモリー

データ

データベース区画N-1

CPUCPU

メモリー

データ

ＤＢ２クライアント同じ結果が返ってきます

ＤＢ２クライアント

ハイ・パフォーマンスを支えるパーティション表

• ひとつの表を複数の区分に分割

• 古い区分を高速にロールアウト（区分のデタッチ）

• 既存データはオンライン状態で、新しい区分をロールイン（区分のアタッチ）

• 区分単位でのアクセス性能向上

• 各区分は異なる表スペースに配置可能


Jan Feb Mar Apr

過去のデータはまとめて瞬時に

切り離し

新規データを個別にLOADしてから区分を取り

付けDETACH ATTACH

日付などのレンジで区分に分割し整理するパーティション表

Jan

売上履歴表

読みたい区分のみにアクセス

ハイ･パフォーマンスを支える多次元分析機能

• 多次元クラスタリング（MDC)とは

• 複数属性の値によってデータを分類して自動的に格納する機能

• 単一属性のクラスタでは実現できなかった「2008年9月」の「DB2」の「東京」というような複数の属性をもつクラスタ

• 次元別検索のパフォーマンス向上

• データ並べ替えを目的とした再編成不要

• 削除のパフォーマンスアップ（ブロック削除が可能）

• 索引のサイズが小さい（索引はブロック・ベース（BID））

サマリー表作成など集計バッチにも効果

大


セル

ブロック

20082008年年99月月, , 東京東京, , DB2DB2

20082008年年99月月, , 東京東京, , DB2DB2

20082008年年99月月, , 大阪大阪, ,

WebspherWebspheree

20082008年年99月月, , 大阪大阪, ,

WebspherWebspheree

20082008年年88月月, , 大阪大阪, ,

WebspherWebspheree

20082008年年88月月, , 東京東京,,DB2DB2

年月

次元

製品

次元

地域

次元レコード

• BID• レコードベースの通常の索引も同時に作成可能

作成SQL例：CREATE TABLE MDC1 (Date DATE,地域 CHAR(10),製品 VARCHAR(10), 年月 generated always as (INTEGER(Date)/100), ... )

ORGANIZE BY DIMENSIONS (年月, 地域, 製品)

列名指定のみでメンテナンス不要

通常の表に保管されたデータ


必要な行へのアクセスのために大

量の不要な行も読み込む

ひとつのクエリーを処理するのはひ

とつのCPUのみ。

複数パーティションにハッシュ分割（DBパーティション）

P 1 P 2 P 3


ひとつのクエリーを複数のCPUを

使って並列に処理することができる

複数パーティションにハッシュ分割して並列処理

P 1 P 2 P 3


依然として不要なI/Oは存在。

可用性を損なうことなく大量

データの入れ替えを行いたい。

データをレンジ分割して保存（パーティション表）

P 1

Jan

P 2 P 3


Feb

Mar条件に合致したパーティショ

ンのみを参照すればよい

パーティションの高速削除と

追加が可能

データをレンジ分割して保存（パーティション表）

P 1

Jan

P 2 P 3


Feb

Mar

未だ不要なI/Oが残っている

各行をブロックに整理して保管（多次元クラスター表）

P 1

Jan

P 2 P 3


Feb

Mar

同じ値を持った行同士を同じ

ブロックに集めて保管。

必要な行を取り出すための

I/Oが小限で済む

各行をブロックに整理して保管（多次元クラスター表）

P 1

Jan

P 2 P 3


Feb

Marこれ以上I/Oの効率を上げるこ

とはできないか？？？

各ブロックに格納される行数を増やす（行圧縮）

P 1

Jan

P 2 P 3


Feb

Mar

各ブロックにより多くの行を保管

し、ディスク容量の削減が可能。

必要な行を取り出すためのI/O

がさらに少なくなる。

ブランク・ページ



行圧縮機能


• V8 GA～

• テーブル作成時の「VALUE COMPRESSION」

• V8 FixPak 4～

• バックアップイメージの圧縮

• V9.1• 表の行圧縮 (Row Compression)の登場

• V9.5

DB2でのデータ圧縮技術の歴史


• V9.5• 辞書メンテナンスの機能強化 (ADC)

• V9.7• 索引の圧縮

• 一時表の圧縮

• XML（XDA）の圧縮

• インラインLOBデータの圧縮

業界ではDB2のみ

圧縮することのメリット

ディスク使用量の削減

特に、繰り返しデータがあるような場合に効果的

バッファー・プールの使用率向上

より多くのデータが圧縮された状態でバッファープールに乗るため、バッファープールヒット率の向上が期待できる

© Copyright IBM Japan Systems Engineering Co., Ltd. 200925

ディスクへの読み書き量が削減できるため、特にI/Oネックのシステムにはパフォーマンス向上の効果がある

ログ・ファイルへの書き出し量が削減される

行圧縮機能の概要

• 辞書を使った行レベルのデータ圧縮（V9.1～）

• 辞書には、レコードにある特定のパターンが記録される

• ディスク使用量の削減

• より多くのデータが圧縮された状態でバッファープールに乗るため、バッファープールヒット率の向上が期待できる

• ディスクへの読み書き量が削減できるため、特にI/Oネックのシステムにはパフォーマンス向上の効果がある


名前部署給与都道府県区・市郵便番号

Fred 500 10000 東京都港区 24355

John 500 20000 東京都港区 24355

01 500

02 東京都, 港区,24355

… …

Fred 500 10000 東京都港区 24355 John 500 20000 東京都港区 24355 …

ディクショナリー

Fred (01) 10000 (02) John (01) 20000 (02) …

索引圧縮の使用方法

• 索引圧縮を使用する場合

• CREATE INDEX、ALTER INDEXのCOMPRESS YESオプション使用

CREATE INDEX X01 ON T01 (C01) COMPRESS YES

CREATE INDEX X02 ON T02 (C02)ALTER INDEX X02 COMPRESS YESREORG INDEXES ALL FOR TABLE T02


• 索引圧縮の解除方法

• ALTER INDEXのCOMPRESS NOオプション

• ALTER後のREORG INDEXESするまでは、圧縮された状態で保持される

ALTER INDEX X02 COMPRESS NOREORG INDEXES ALL FOR TABLE T02

• objecttype• オブジェクトタイプ（表：’T’ or NULL、索引：’I’ )

• objectschema• オブジェクトのスキーマ名

新しい表関数①（ADMIN_GET_INDEX_COMPRESS_INFO)

>>-ADMIN_GET_INDEX_COMPRESS_INFO--(--objecttype--,--objectschema--,--objectname--,-->

>--dbpartitionnum--,--datapartitionid--)-----------------------><


• オブジェクトのスキーマ名

• objectname• オブジェクト名（case-sensitive）

• dbpartitionnum• データベース・パーティション番号（非データベース・パーティション環境：’-2’ or

NULL)• datapartitionid

• データ・パーティション番号（非データ・パーティション環境：’-2’ or ‘0’or NULL)

• 圧縮属性の確認、および圧縮によって節約できるリーフページ数の見積もりなどが可能

• Objecttype

• オブジェクトタイプ（表：’T’ or NULL、索引：’I’ )• Objectschema

• オブジェクトスキーマ

新しい表関数②（ADMIN_GET_INDEX_INFO)

>>-ADMIN_GET_INDEX_INFO--(--objecttype--,,--objectschema--,--objectname--)--------------------------><


• オブジェクトスキーマ

• Objectname

• オブジェクト名

• 索引毎の圧縮情報、およびその表に定義されている全索引に対して必要なサイズなどを確認可能

索引圧縮の条件

圧縮表非圧縮表

CREATE INDEXCOMPRESS YES

圧縮圧縮

CREATE INDEXCOMPRESS NO

非圧縮非圧縮

ALTER INDEX COMPRESS YES

圧縮圧縮


COMPRESS YES

ALTER INDEX COMPRESS NO

非圧縮非圧縮

CREATE INDEX COMPRESS指定なし

圧縮非圧縮

以前のリリースよりマイグレーションされたDB

非圧縮非圧縮

※表の圧縮属性を変更しても、変更時点で既に存在している索引の圧縮属性は変更されない

（参考）圧縮表のパフォーマンスとCPUへの負荷

圧縮表（表圧縮＋圧縮索引（1個）） VS 非圧縮表

2000

3000

4000

5000

6000

7000

8000

9000

トラ

ンザ

クシ

ョン

/秒

圧縮表

非圧縮表

CPU(user)1 2.62 2.63 2.64 10.55 2.2

CPU(user)6 1.6

Update(索引キー列）

索引圧縮+表圧縮

Select

Insert

SelectUpdate(索引キー列以外）

Delete索引圧縮なし+表圧縮なし


圧縮表： IndexBPヒット率(90.5～100%),DataBPヒット率(85.6～99.9%)

非圧縮表： IndexBPヒット率(86.2～100%),DataBPヒット率(73.9～99.7%)

0

1000

SelectUpdate(索引キー列以外）

Update(索引キー列）

InsertDelete

トラ

ンザ

クシ

ョン

3分間、10userで計測

圧縮により、バッファープールヒット率が向上し、パフォーマンスも向上した

Select/Insert/Update/Deleteのすべてにおいて、より有効にCPUが使用されるようになった

6 1.67 1.68 1.69 6.7

10 1.7

Select

Delete

Update(索引キー列以外）Update(索引キー列）Insert

使用上の考慮点

• MDCブロック索引, カタログ表の索引, index specifications, XMLメタ索引, XMLパス索引は圧縮対象外

• 圧縮表に対して新しく作成する索引は、明示的にCOMPRESS NOを指定しない限り、圧縮索引となる

• 一度圧縮索引として作成されたものを非圧縮に戻したい場合には、COMPRESS NOを指定してALTER INDEXを実行し、さらに索引再編成を行う

• 非圧縮表に対して新しく作成する索引は、明示的にCOMPRESS YESを指定しない限


• 非圧縮表に対して新しく作成する索引は、明示的にCOMPRESS YESを指定しない限り、非圧縮索引となる

• 一度非圧縮索引として作成されたものを圧縮したい場合には、COMPRESS YESを指定してALTER INDEXを実行し、さらに索引の再編成を行う

• V9.1、V9.5のデータベースをV9.7に移行しても、索引圧縮は行われない

• 索引圧縮を使用するには、ALTER INDEX・・・COMPRESS YES、およびREORG INDEXを実行する

DB2 pureXML機能概要


DB2 pureXMLの歩み

V9.5

pureXML機能強化

V9.7

XMLウェアハウスへ

DPF

MDC

パーティション表

V9.7

XMLウェアハウスへ

DPF

MDC



V9.1

pureXMLサポート

XML基本機能

XML列/索引

XQuery

各種ユーティリティ

pureXML機能強化

Inline格納

部分更新

XSLT

スキーマエボリューション

Replication

Load


XDA圧縮

オンライン索引再編成/索引作成

UDF

Global Temporary Table

複数文書のdecompositoin

parse/validationの詳細エラー


XDA圧縮

オンライン索引再編成/索引作成

UDF

Global Temporary Table

複数文書のdecompositoin

parse/validationの詳細エラー

insert into dept values (1,……, ’<dept><emp>夏目漱石</emp></dept>’)

• DB2のpureXML機能では、XMLデータを保持するための「XMLデータ型」を提供する

• XMLデータ型はリレーショナル表の中に定義し、レコードの中の1カラムとして取り扱う

• XMLデータは分解(Parse)されDOMに似た階層型のフォーマット(XDM)で格納される

• 照会時にはParseしない

• XML格納方法は2通り - inline格納/XDA(XML Data Area)格納

DB2におけるXMLデータの格納


deptID … deptdoc

1 … <dept> …

<emp>夏目漱石</emp>

</dept>

… … …

inline格納時のdept表の物理構造

リレーショナル

dept表の論理構造

deptID deptdoc…

create table dept (deptID int,…, deptdoc xml inline length 10000 )

create table dept(deptID int,…, deptdoc xml)

1

XML

XDA格納時のdept表の物理構造

XMLリレーショナル

XMLデータ

XDA(XML Data Area)deptID deptdoc

XML記述子regionsindex

inline格納する表の定義 XDA格納する表の定義

LOBと類似だがbufferpoolを使用

XML照会の２つの方法

DB2 SERVER

CLIENT SQL/XML

XQueryDB2 Engine

XML

RelationalInterface Relational

XML

DB2 Storage:

DB2 Client /Customer Client Application


• XQueryを主言語とする

• W3C XQuery標準で定義

• V9新機能

• XQueryにSQLを組み込むことも可能

• SQLを主言語とする

• SQL/XML(SQLのXML用関数)の使用

• SQL標準で定義

• V8からサポート、V9で拡張

• SQLにXQueryを組み込むことができる

XMLInterface

XML

• XMLカラムに対してユーザーが索引を作成

• 索引対象は、要素、属性

• XML索引は、CREATE INDEXステートメント中xmlpattern(XPath)を記述して指定

• XMLのデータ型はSQLデータ型にマップされる。

• XML索引を使って検索を実行

• ANDing/ORing

XML索引

CREATE INDEX empindex ON company(docs)GENERATE KEY USING XMLPATTERN '/company/emp/@id' AS SQL DOUBLE

COMPANYDOC (XML EMPINDEX索引


COMPANYDOC (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>略

1row

1row

COMPANY表EMPINDEX索引

COMPANYDOC(DOUBLE)

312013166442366

DOUBLE型の索引が作成される

• DB2は、XMLスキーマによるXMLインスタンスの妥当性検査をサポートする

• XMLスキーマをXSR (XML Schema Repository)へ登録する必要がある

• DB2では、妥当性検査はXMLインスタンス単位で行う

• 妥当性検査を行うかどうか、どのXMLスキーマを使用するかは任意

• １つのカラムに妥当性検査済みのXMLインスタンスと、検査されていないXMLインスタンスが混在しても良い

• １つのカラムに異なるXMLスキーマで妥当性検査されたXMLインスタンスが混在しても

XMLスキーマ対応


• １つのカラムに異なるXMLスキーマで妥当性検査されたXMLインスタンスが混在しても良い

• INSERT,IMPORT, (UPDATE)によるXMLインスタンスの投入時に実施可能

DB2システム・カタログ

XSR

XML文書

ValidateXMLSchema

Validな(妥当な)

XML文書

INSER

T

XMLSchema 登録

pureXML in DB2 V9.7

DB2 XML Support

DPF

20082008年年99月月, , 東京東京, , DB2DB2

20082008年年99月月, , 東京東京, , DB2DB2 20082008年年

99月月, , 大大阪阪, ,

20082008年年99月月, , 大大

阪阪, ,

20082008年年88月月, , 大大

阪阪, , WebsWebs

20082008年年88月月, , 東東

京京,,DB2DB2

MDC XMLデータ

ウェアハウス


阪阪, , WebspWebsp

herehere

阪阪, , WebsWebspherephere

WebsWebspherephere

Jan

Feb

Mar

Apr


圧縮

ウェアハウス

大量のXMLデータ

文書サイズが大きいXMLデータ

•マニュアル

•報告書/申請書

•条例/省令

•カルテなど

文書系XMLデータの

管理/加工/検索

XML表の作成 – DPFサポート

• DPF環境でもXML列を含む表の作成が可能

• DPF環境の既存の表にALTER TABLEでXML列の追加が可能

• どのパーティションからでもXSRオブジェクト(XMLスキーマなど)の登録/検索が可能

• SQL/XML, XQueryのパラレル実行可能

• パラレルのLOADが可能

• DPF環境でもXML列を含む表の作成が可能

• DPF環境の既存の表にALTER TABLEでXML列の追加が可能

• どのパーティションからでもXSRオブジェクト(XMLスキーマなど)の登録/検索が可能

• SQL/XML, XQueryのパラレル実行可能

• パラレルのLOADが可能CREATE TABLE table1 (


• 制約

• XML列をdistribution keyにすることはできない

• distribution keyを持つXML表に対しuniqueなXML索引を持てない

• V9.1/V9.5のXMLフォーマットを持つ表はDPF環境に分散できない

=> 表の再作成またはADMIN_MOVE_TABLEによる移行が必要

CREATE TABLE table1 (col1 int, col2 xml,DISTRIBUTE BY HASH(col1))

XML表の作成 – MDCサポート

• XML列を含むMDC表の作成が可能

• MDC表にALTER TABLEでXML列の追加が可能

• MDCブロック索引と、XML索引を合わせて使用することが可能

• XML列を含むMDC表の作成が可能

• MDC表にALTER TABLEでXML列の追加が可能

• MDCブロック索引と、XML索引を合わせて使用することが可能

CREATE TABLE MDC1 (製品 VARCHAR(10), 製品明細 XML)


• 制約

• XML列を次元(ORGANIZE BY節)に指定することはできない

製品明細 XML) ORGANIZE BY DIMENSIONS (製品)

XML表の作成 – パーティション表サポート

• XML列を含む表をパーティション表にすることが可能

• パーティション表に対してALTER TABLEでXML列の追加が可能

• XDA用の表スペースは、パーティション表の表スペースに置くことも、別表スペースに置くことも可能

• XML列を含む表をパーティション表にすることが可能

• パーティション表に対してALTER TABLEでXML列の追加が可能

• XDA用の表スペースは、パーティション表の表スペースに置くことも、別表スペースに置くことも可能

CREATE TABLE t1(c1 INT, c2 INT, c3 XML)IN tbsp1, tbsp2, tbsp3LONG IN tbsp6, tbsp7, tbsp8


• 制約

• XML列をpartition keyにすることはできない

• XML索引はpartitioned index(ローカル索引)にすることはできない

PARTITION BY RANGE(c1)(STARTING FROM 1 ENDING 90 EVERY 30)

tbsp3tbsp2tbsp1

t1.p1 t1.p2 t1.p3

tbsp8tbsp7tbsp6

XDA1 XDA2 XDA3

データ・オブジェクト

XMLデータの圧縮

create table dept (deptID char(8),...,doc XML inline length 10000)

• DB2 V9.5では、基礎表に保持されたものがV9.5での圧縮対象

• V9.7ではXDAオブジェクトに保持されたXMLデータも圧縮対象

• DB2 V9.5では、基礎表に保持されたものがV9.5での圧縮対象

• V9.7ではXDAオブジェクトに保持されたXMLデータも圧縮対象


ID … DOC (XML)

PR27 …

PR28 … XML記述子

ACC …

Regions

Index

索引オブジェクトデータ・オブジェクト

XDAオブジェクト(XML Data)圧縮可（V9.5）

圧縮可（V9.7）

XMLデータの圧縮方法

• 圧縮辞書の作成

• REORG TABLE （RESETDICTIONARYオプション）

• すでに表にデータがある場合(ALTER TABLE COMPRESS YESで表属性を変更しREORG)

• Automatic Dictionary Creation （ADC）

• V9.5から• 表に一定量のデータが挿入されると自動的に辞書が作成され、データが圧縮される

create table dept (deptID char(8),...,doc XML) compress yes


• 表に一定量のデータが挿入されると自動的に辞書が作成され、データが圧縮される

• 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新機能）を使用可能

XML索引の圧縮

• ユーザー定義XML索引の圧縮可能

• 索引圧縮はV9.7新機能

• COMPRESS YESと指定された表に対する索引は自動的に圧縮

• CREATE INDEXで明示的に圧縮モードを指定(COMPRESS [YES|NO])

• ユーザー定義XML索引の圧縮可能

• 索引圧縮はV9.7新機能

• COMPRESS YESと指定された表に対する索引は自動的に圧縮

• CREATE INDEXで明示的に圧縮モードを指定(COMPRESS [YES|NO])


(COMPRESS [YES|NO])(COMPRESS [YES|NO])

表のオンライン移動機能ADMIN_MOVE_TABLEプロシージャー


ADMIN_MOVE_TABLEプロシージャー

表のオンライン移動機能: ADMIN_MOVE_TABLEプロシージャー

表の読み書きを可能にしたまま、表を移動する

⇒ これまで表の再作成が必要だった変更作業をオンラインで実施できる

• 別の表スペースへの移動

• ディスク配置の変更

• 表スペース作成時に表スペース単位で決定される定義の変更（例：ページ・サイズ、エクステント・サイズなど）


（例：ページ・サイズ、エクステント・サイズなど）

• 表の定義情報の変更例えば…

• 索引定義

• MDC表の次元列 (MDC表において各行の格納されるブロックを決定する列)

• パーティション表のレンジ定義

• データの圧縮/非圧縮/再圧縮表スペース別表スペース

Ｃ１Ｃ２Ｃ１Ｃ２

INSERT,DELETE,UPDATE

表のオンライン移動機能の仕組み

表スペース１表スペース2

Ｃ１Ｃ２

表移動の5つのステップ

① 初期化 (INIT)

－移動先表、トリガー、

ステージング表作成

－定義情報変更

② コピー (COPY)

－データ・コピー

Ｃ１Ｃ２

①

②

②

③

④

INSERT,DELETE,UPDATE

トリガー

①

ソース表ターゲット表


－データ・コピー

－変更データ情報を

ステージング表格納

③ リプレイ(REPLY)

－ステージング表からの差分データ反映

④ 切り替え(SWAP)

※アクセス不可

⑤ クリーンアップ

※keepオプション(元表保持)

②

ステージング表

表スペース1から表スペース2へ表を移動させる場合

(CLEANUP)

①

①

推奨：

・ソース表にユニーク索引をつける

－差分データ更新される行が1つになるため

・作成ディスク・スペース容量を十分に確保する

－ソース表に加え、ターゲット表、ターゲット表に付随する索引、ステージング表の

ための領域が必要、また、コピーに伴って必要となるログ量も考慮する必要がある

Let’s go Lab7!!


Let’s go Lab7!!

第6章 db2の特徴的な機能紹介 - ibmdatabase partitioning...

Documents