Value Driven Proposals...2007/12/58/3/05 この文書のデータの利用または公開には、...

2007/12/58/3/05この文書のデータの利用または公開には、最終ページに記載されている制限事項が適用されます。

ビジネス・ユニットの名前

PSU_temp_0522

第3章パフォーマンス強化

＜第１．００版２００７年１１月＞

本書に含まれている情報は、正式なIBMのテストを受けておらず、全体または一部においていかなる保証責任を負わないものとし、保証対象とは見なされません。こ

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

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


この文書のデータの利用または公開には、終ページに記載されている制限事項が適用されます。22 © Copyright IBM Japan Systems Engineering Co., Ltd. 2007

PSU_temp_0522

内容

リアルタイム統計情報収集

LOBの照会パフォーマンス改善

MDCロールアウトの高速化

オプティミスティック・ロッキング拡張サポート

「No File System Caching」がデフォルトで有効になった

索引構築の並列処理がデフォルトで有効になった



PSU_temp_0522

リアルタイム統計情報収集



PSU_temp_0522

ブランク・ページ



PSU_temp_0522

リアルタイム統計情報収集： DB2 9.5での改善点

1. リアルタイムで統計情報を収集

– 必要に応じてステートメント実行（適化）の前に、自動的にRUNSTATSが実

行される。

2. ファブリケート統計の精度向上

– 利用できる統計情報が存在しない場合、索引マネージャからのメタ・データを使用して統計情報を「ファブリケート（ねつ造）」する。

V9.5New

V9.5New



PSU_temp_0522

統計情報取得改善の歴史

V8.2

– 自動統計情報収集機能の追加

• 表を定期的にモニターし、統計情報を変化させるような更新頻度が高い表に対して、RUNSTATSを実行する。

V9.1

– 自動統計情報収集機能がデフォルトでON

•課題

•自動統計情報収集は2時間ごとに実行される。

•更新量が多い場合、自動統計情報収集のタイミングでは間に合わないケースがある。

•統計情報が古い状態で実行されるSQLは適なアクセスパスでない可能性があった。



PSU_temp_0522

リアルタイム統計情報収集を利用した場合の動作

① 非同期統計情報収集

– できる限り、バックグラウンドで実行される統計情報収集を利用

② リアルタイム統計情報収集（同期統計情報収集）

– 統計情報が正確でないと判断した場合、SQLステートメントが適化される前に統計情報を取得

③ ファブリケート統計情報の利用

– なんらかの理由で、リアルタイム統計取得ができなかった場合、索引マネージャからのメタ・データを使用して統計情報を「ファブリケート（ねつ造）」する。

④ 上記②、③により統計情報が利用された場合、非同期統計情報の取得を要求する。

①非同期統計情報収集．

②リアルタイム統計情報

収集

③ファブリケート統計の

利用

大量更新

← ④非同期統計取得要求

より実情に即したアクセ

スプラン



PSU_temp_0522

Note：リアルタイム統計情報収集を利用した場合の動作

V9.5では、リアルタイム統計情報を利用することで、より実情に即した統計情報を利用することができます。リアルタイム統計情報の機能を有効にした場合、統計情報収集の流れは以下のようになります。

① 非同期統計情報収集

– バックグラウンドで実行される統計情報取得

• できる限り、通常プロセスの一環として、バックグラウンドで取得される統計情報を使用します。

② リアルタイム統計情報収集（同期統計情報収集）

– たとえば、非同期に統計情報が収集される前に、表に対する大量更新が発生していたとします。このような表に対するステートメントが実行された場合、オプティマイザーが、現在の統計情報はもはや正確ではないと判断し、SQLステートメントが適化される前に、その場で統計情報を取得します。

③ ファブリケート統計情報の利用

– ②のリアルタイム統計情報の取得に時間がかかりすぎるなどの理由で、リアルタイム統計取得が成功しなかった場合、索引マネージャのメタ・データを使用して統計情報を「ファブリケート（ねつ造）」して代替的に使用します。

④ リアルタイム統計情報収集、および、ファブリケート統計情報が利用された場合、非同期統計情報収集が要求されます。

V9.5New



PSU_temp_0522

参考：自動統計情報収集実施フロー

Run the Query

YES NO

NO

同期統計収集を実施

Send request to Auto Runstats

1)No statistics

2)Truncated table

3)Drastic updates

Many row updates?YES

①

②⑥

⑦③

④

⑤

Collect Statistics

SUCCEED

FAIL

Fabrication

⑧

非同期統計収集のリクエスト

JITS

deamon



PSU_temp_0522

NOTE：参考：自動統計情報収集実施フロー

1.統計情報を収集しないケース

① -> ② -> ③

2.非同期統計収集のみ実行されるケース

① -> ② -> ④ -> ⑤

3.同期統計収集、非同期統計収集が実行されるケース

① -> ⑥ -> ⑦ -> ⑤

4.同期統計収集、FABRICATION、非同期統計収集が実行されるケース

① -> ⑥ -> ⑧ -> ⑤



PSU_temp_0522

リアルタイム統計情報収集機能の設定方法

設定方法

– 新しいDB CFG “AUTO_STMT_STATS” をONに設定する

• 同期統計収集のON/OFFを設定するパラメーター

• 動的に変更可能

• デフォルト値はOFF （※）

• 階層構造となっている点に注意

– AUTO_MAINT, AUTO_TBL_MAINT, AUTO_RUNSTATSが全てONになっている必要がある

• データベースがアクティブにされてから低 5 分間は、リアルタイム統計収集アクティビ

ティーは行われない

Automatic maintenance (AUTO_MAINT) = ON

Automatic database backup (AUTO_DB_BACKUP) = OFF

Automatic table maintenance (AUTO_TBL_MAINT) = ON

Automatic runstats (AUTO_RUNSTATS) = ON

Automatic statement statistics (AUTO_STMT_STATS) = ON

Automatic statistics profiling (AUTO_STATS_PROF) = OFF

Automatic profile updates (AUTO_PROF_UPD) = OFF

Automatic reorganization (AUTO_REORG) = OFF

リアルタイム統計情報収集機能



PSU_temp_0522

リアルタイム統計情報収集詳細

リアルタイム統計情報収集の実施判断基準

– 現存の統計情報が有効かどうかをオプティマイザーが判断

• 統計情報が取得されていない表

• IMPORTを使用して切捨てられた表(/dev/nullをIMPORT)

• 更新頻度の高い表

– 後に統計情報を収集した時点からどれだけ表アクティビティーUID（Update,Insert,Delete）が発生したかで決定

表が、同期統計収集の基準を満たしていている場合であっても、クエリーのオプティマイゼーションが要求されない限り、リアルタイム統計情報は収集されない

同期統計収集および作成は、メンテナンス・ポリシー定義で指定されたメンテナンス時間帯には従わない。（いつでも実行される）



PSU_temp_0522


リアルタイム統計情報収集は、照会 1 つにつき 5 秒（デフォルト）に制限される。同期収集が時間制限を超えると、リアルタイム統計情報収集を中止し、ファブリケート統計を利用する。その際、非同期収集要求が送信される。

リアルタイム統計情報収集では、統計情報はシステム・カタログ表に格納されない。

– その代わりに、統計は「統計キャッシュ」と呼ばれるメモリー領域に格納され、後ほど非同期操作によってシステム・カタログ表に格納される。

– システム・カタログ更新のオーバーヘッド、ロック競合の可能性も回避するため。

– 統計キャッシュ内の統計情報は、後続の SQL コンパイル要求で使用可能。

自動統計収集の実行中も、影響を受ける表に対し、あたかも RUNSTATS コマンドがその表で実行されていないかのように、引き続き通常のデータベース・アクティビティー (更新、挿入、削除) が可能

リアルタイム統計情報収集が実行された表に関連するパッケージは無効となり、次回の実行時に再度コンパイルが必要となる。

– RUNSTATSが実行されると、対象表に関連するパッケージが無効となるのは、V9.1以前からと同様の挙動。



PSU_temp_0522


デフォルトでは、分散情報を含む基本統計情報や、サンプリングを使用した詳細な索引統計（WITH DISTRIBUTION AND SAMPLED DETAILED INDEXES ALL）を実施

– 統計プロファイルを使用することによってカスタマイズ可能

1つの表で行われる同期統計収集は、1つのみ。同期統計収集を必要とする他のエージェントは、可能な場合にはファブリケート統計を作成し、引き続きステートメント・コンパイルを行う。この動作は DPF環境でも強制される。



PSU_temp_0522


リアルタイム統計情報収集の対象となる表

– 通常表、MQT、宣言済みグローバル一時表(DGTT)

• DGTTに関しては、非同期統計は収集されない。

• リアルタイム統計収集プロセスはDGTTに対する非同期統計取得要求を発行しない。

自動統計収集対象外の表（リアルタイム・非同期統計収集共通）

– 統計ビュー

– VOLATILE表

– SYSSTATカタログビューを手動で更新した表

• 統計が手動で変更された場合、DB2はユーザーが表の統計保守をしているとみなため、統計の自動保守を行わない

リアルタイム統計プロセスは静的、動的SQLの両方が対象



PSU_temp_0522

ファブリケート統計詳細

ファブリケート統計とは

– なんらかの理由で、リアルタイム統計取得ができなかった場合、索引マネージャからのメタ・データを使用して統計情報を「ファブリケート（ねつ造）」し、一時的に利用する。

– V9.5では、以前のバージョンより多くの情報をファブリケートできる

• CARD,FULLKEYCARD（ユニーク索引が有る場合）

• HIGH2KEY,LOW2KEY,NLEAF,NLEVELS,FPAGES

以下のケースで使用される

– 同期統計情報収集がタイムアウトした場合

– オプティマイザーが、同期統計収集の負荷が高すぎると判断した場合

メモリー上でのみ有効となる

V9.5New



PSU_temp_0522

非同期統計情報収集詳細

非同期統計情報収集とは

– バックグラウンドで自動的に統計情報収集を収集する

– デフォルトで有効になる (AUTO_RUNSTATS) = ON

実施タイミング

– リアルタイム統計を利用可能にしていない場合

• 非同期統計収集の検査は 125分間隔で行われる。（今までの自動RUNSTATSに相当)

– リアルタイム統計を利用可能にしている場合

• 非同期統計収集の検査は引き続き 125分間隔で行われるが、そのほかにも以下のタイミングで非同期統計情報取得の要求が開始する。

– 表アクティビティーが同期収集(リアルタイム統計収集）を必要とするほど高くはないものの、非同期収集を十分必要とする高さである場合。

– 表が大きいために、同期統計収集でサンプリングを使用した場合。

– 同期統計が作成されたものである場合。

– 同期統計収集の収集時間が超過したために失敗した場合。



PSU_temp_0522

非同期統計情報収集詳細

非同期統計収集の検査に関して、大きい表 (構成ページが 4000 を超える表) の場合は、表に対する大量のアクティビティーによって確かに統計が変化したかどうかを判断するためにサンプリングを行う。変化が確実な場合にだけ、このような大きな表の統計は収集される。

非同期統計収集の場合、 RUNSTATS ユーティリティーは、メンテナンス・ポリ

シー定義で指定される適なメンテナンス時間帯に実行されるように、自動でスケジューリングされる。このポリシーはまた自動統計収集を有効にする表のセットも指定するので、不必要なリソース消費をさらにおさえられる。

非同期統計収集の場合、SYSPROC.NNSTAT ストアード・プロシージャーは、

ニックネーム統計を自動的にリフレッシュするカタログ・ベースの収集メソッドを使用して実行される。

– リアルタイム統計 (同期、または作成されたもの) は、ニックネームに関しては収集され

ない。

スロットル調整したRUNSTATSユーティリティを実行し、RUNSTATS ユーティリ

ティーの消費するリソースの量が制御される。



PSU_temp_0522

参考：統計キャッシュとは

統計キャッシュとは？

– 同期的に収集された統計情報を維持し、収集された統計をすべての照会で利用できるようにする｡

– カタログキャッシュの一部

– カタログキャッシュには、同じSYSTABLESオブジェクトの複数の項目を格納することが可能

– カタログキャッシュサイズが増加するため、同期統計収集を有効にする場合は、CATALOGCACHE_SZの値を大きくする必要がある｡

• デフォルトサイズはMAXAPPLS*4からMAXAPPLS*5へと拡張されている



PSU_temp_0522

統計情報収集に関するモニター：①統計ログ

V9.5では、「統計ログ」が導入され、自動および手動による統計収集を含め、データベースに関するすべての統計アクティビティーを記録される。

ファイル名：db2optstats.number.log

出力先（デフォルト）

– $INSTANCE/sqllib/db2dump/events

DB2_OPTSTATS_LOGレジストリー変数で以下の設定が可能

• 保管ファイル数(デフォルト5ファイル)

• ファイルサイズ(デフォルト100MB)

• ファイル名(デフォルトdb2optstats.x.log)

• ファイルパス

SYSPROC.PD_GET_DIAG_HIST 表関数を使用して照会することも可能



PSU_temp_0522

統計情報収集に関するモニター：②ADMINTABINFO 管理ビュー

ADMINTABINFO 管理ビュー

– どのように統計情報が収集されたかという情報を提供するカラムを提供

STATSTYPE CHAR(1) •「F」= 表または索引のスキャンを行わずにシステムが作り上げた統計。これらの統計はメモリー

に保管され、システム・カタログに保管されているものとは異なります。これは一時状態であり、終的に完全な統計が DB2 によって収集され、システム・カタログに保管されます。•「A」= システムが非同期に収集した統計。統計は DB2 によりバックグラウンド・プロセスで自動的に収集され、システム・カタログに保管されました。•「S」= システムが同期に収集した統計。統計は DB2 によって SQL ステートメントのコンパイル

中に自動的に収集されました。これらの統計はメモリーに保管され、システム・カタログに保管されているものとは異なります。これは一時状態であり、終的に DB2 が統計をシステム・カタログに保管します。•「U」= ユーザーが収集した統計。統計の収集は、RUNSTATS、CREATE INDEX、LOAD、REDISTRIBUTE などのユーティリティーを使用するか、システム・カタログ統計を手動で更新することによって、ユーザーが開始しました。•NULL = 不明なタイプ



PSU_temp_0522

統計情報収集に関するモニター：統計ログ出力例1/32007-11-09-04.18.34.740632+540 E136318A594 LEVEL: Event

PID : 2007230 TID : 5220 PROC : db2sysc 0

INSTANCE: bashii95 NODE : 000 DB : SAMPLE

APPHDL : 0-3438 APPID: *LOCAL.bashii95.071108190705

AUTHID : BASHII95

EDUID : 5220 EDUNAME: db2agent (SAMPLE) 0

FUNCTION: DB2 UDB, relation data serv, sqlrLocalRunstats, probe:10

COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-09-04.18.34.740461" : BY "User" : start

OBJECT : Object name with schema, 15 bytes

BASHII95.STAFF2

IMPACT : None

2007-11-09-04.18.34.796635+540 E136913A736 LEVEL: Event




AUTHID : BASHII95



COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-09-04.18.34.796487" : BY "User" : success


BASHII95.STAFF2

IMPACT : None

DATA #1 : String, 110 bytes

RUNSTATS ON TABLE "BASHII95"."STAFF2" ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND DETAILED INDEXES ALL

2007-11-09-04.18.34.740632+540 E136318A594 LEVEL: Event




AUTHID : BASHII95



COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-09-04.18.34.740461" : BY "User" : start


BASHII95.STAFF2

IMPACT : None

2007-11-09-04.18.34.796635+540 E136913A736 LEVEL: Event




AUTHID : BASHII95



COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-09-04.18.34.796487" : BY "User" : success


BASHII95.STAFF2

IMPACT : None


RUNSTATS ON TABLE "BASHII95"."STAFF2" ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND DETAILED INDEXES ALL

$date;db2 runstats on table bashii95.staff2 with distribution and detailed indexes all

統計ログ：ユーザー実行による統

計情報の取得統計ログ

$ db2 "SELECT STATSTYPE FROM SYSIBMADM.ADMINTABINFO where TABNAME='STAFF2'"

STATSTYPE

---------

U


STATSTYPE

---------

U




PSU_temp_0522





AUTHID : BASHII95


FUNCTION: DB2 UDB, SW- optimizer, sqlno_runstats_or_fabrication, probe:100

COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-15-00.02.03.169134" : BY "Synchronous" : start


BASHII95.STAFF2

IMPACT : None

2007-11-15-00.02.03.170568+540 E1567095A759 LEVEL: Event




AUTHID : BASHII95



COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-15-00.02.03.170431" : BY "Synchronous" : success


BASHII95.STAFF2

IMPACT : None


RUNSTATS ON TABLE "BASHII95"."STAFF2" ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND SAMPLED DETAILED INDEXES ALL

2007-11-15-00.02.03.169298+540 E1566485A609 LEVEL: Event




AUTHID : BASHII95



COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-15-00.02.03.169134" : BY "Synchronous" : start


BASHII95.STAFF2

IMPACT : None

2007-11-15-00.02.03.170568+540 E1567095A759 LEVEL: Event




AUTHID : BASHII95



COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-15-00.02.03.170431" : BY "Synchronous" : success


BASHII95.STAFF2

IMPACT : None


RUNSTATS ON TABLE "BASHII95"."STAFF2" ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND SAMPLED DETAILED INDEXES ALL

統計ログ：

同期実行の例


STATSTYPE

---------

S


STATSTYPE

---------

S


統計ログ



PSU_temp_0522


PID : 1065038 TID : 1209 PROC : db2acd 0

INSTANCE: bashii95 NODE : 000

APPID : *LOCAL.bashii95.071114150531

EDUID : 1209 EDUNAME: db2acd 0

FUNCTION: DB2 UDB, Automatic Table Maintenance, JitsDaemon::runstats, probe:50

COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-15-00.05.26.381076" : BY "Asynchronous" : start


BASHII95.STAFF2

IMPACT : None

2007-11-15-00.05.26.485837+540 E1568778A535 LEVEL: Event






COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-15-00.05.26.485684" : BY "Asynchronous" : success


BASHII95.STAFF2

IMPACT : None

2007-11-15-00.05.26.381222+540 E1568244A533 LEVEL: Event






COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-15-00.05.26.381076" : BY "Asynchronous" : start


BASHII95.STAFF2

IMPACT : None

2007-11-15-00.05.26.485837+540 E1568778A535 LEVEL: Event






COLLECT : TABLE AND INDEX STATS : Object name with schema : AT "2007-11-15-00.05.26.485684" : BY "Asynchronous" : success


BASHII95.STAFF2

IMPACT : None

統計ログ：

同期実行後にやがて非同期で統計情報収集が行われる


STATSTYPE

---------

A


STATSTYPE

---------

A


統計ログ



PSU_temp_0522

統計情報収集に関するモニター：③SNAPSHOT

データベース・スナップショットに統計情報収集関連のモニターエレメントが追加された。

stats_cache_size Size of statistics cache monitor element

stats_fabrications Total number of statistics fabrications monitor elements

sync_runstats Total number of synchronous RUNSTATS activities monitor element

async_runstats Total number of asynchronous RUNSTATS requests monitor element

stats_fabricate_time Total time spent on statistics fabrication activities monitor element

sync_runstats_time Total time spent on synchronous RUNSTATS activities monitor element



PSU_temp_0522

統計情報収集に関するモニター：③snapshot出力例

DATABASE スナップショットの例

・・・・・

Statistic fabrications = 0

Synchronous runstats = 4

Asynchronous runstats = 4

Total statistic fabrication time (milliseconds) = 0

Total synchronous runstats time (milliseconds) = 18

・・・・・

Catalog cache lookups = 86490

Catalog cache inserts = 125

Catalog cache overflows = 0

Catalog cache high water mark = 786432

Catalog cache statistics size = 0



PSU_temp_0522

統計情報収集に関するモニター：④db2pd

db2pd -statisticscacheデータベース・レベルの統計キャッシュに関する情報を戻します。

– summary • 統計キャッシュに関するサマリー情報を出力します。

– detail • 統計キャッシュに関する詳細情報を出力します。

• リアルタイム統計収集によって集められた新の統計を含む、統計キャッシュに保管されたすべての表に関する詳しい統計情報をダンプ出力します。

– find schema=schema object=object • 特定の表に関する統計を収集。

• schema (スキーマ名) と object (表名) を指定して特定の表に関する詳しい統計情報を出力しま

す。



PSU_temp_0522

リアルタイム統計収集とExplain

Explain 機能を使用して Explain しただけの照会 (実行していないもの) では、リアルタイ

ム統計情報は取得されない。

CURRENT EXPLAIN MODE レジスターの値によって、リアルタイム統計収集を考慮す

るかどうかが決定される。以下の一覧表参照。

CURRENT EXPLAIN MODE リアルタイム統計収集を考慮するかどう

か YES YES

EXPLAIN NO NO YES

REOPT YES RECOMMEND INDEXES NO

EVALUATE INDEXES NO



PSU_temp_0522

参考： db2exfmtの出力変更

> Extended Statistics Information:

> --------------------------------

>

> Tablespace Context:

> -------------------

> Name: IBMDB2SAMPLEREL

> Overhead: 7.500000

>

> Base Table Statistics:

> ----------------------

> Name : STAFF2

> Schema: BASHII95

> Number of Columns: 7

> Number of Pages with Rows: 13

> Number of Pages: 13

> Number of Rows: 2240

> Table Overflow Record Count: 0

> Width of Rows: 41

> Time of Creation: 2007-11-09-03.57.13.920943

> Last Statistics Update: 2007-11-09-05.30.27.444410

・・・・・・

> Number of Column Groups: 0

> Number of Data Partitions: 1

> Average Row Compression Ratio: -1.000000

> Percent Rows Compressed: -1.000000

> Average Compressed Row Size: -1

> Statistics Type: A

実行例

$db2 set current explain mode yes

$db2 set current explain snapshot yes

$db2 “select * from staff2”

$db2exfmt

•EXPLAINスナップショットが取得されていると、“Extended Statistics Information:”セクションが追加で表示される。

•EXPLAINのみでは表示されない

•利用された統計情報がどのように取得されたかがわかる



PSU_temp_0522

db2exfmtから取得可能な「Extended Statistics Information」は、スカラー関数「EXPLAIN_FORMAT_STATS」を用いて取得することも可能

EXPLAIN_FORMAT_STATS– スカラー関数

– EXPLAIN_STATEMENT表に格納されたExplainスナップショット（BLOB）から、Exlapin情報を取得する。

SELECT EXPLAIN_FORMAT_STATS(SNAPSHOT) FROM EXPLAIN_STATEMENT

参考： db2exfmtの出力変更



PSU_temp_0522

リアルタイム統計情報収集のタイムアウト値を変更する方法

リアルタイム統計情報のデフォルトのタイムアウト値は“5秒”– デフォルト値の変更は、「RTS 適化ガイドライン」によって制御する。

• 「適化ガイドライン」とは、SQLのアクセスパスをコントロールするための仕組み

– XMLで作成したプロファイルをSYSTOOLS.OPT_PROFILE表に登録して使用する。

<?xml version="1.0" encoding="UTF-16"?><OPTPROFILE VERSION="9.1.0.0"><OPTGUIDELINES>

<RTS OPTION="ENABLE" TIME="100" /></OPTGUIDELINES>

</OPTPROFILE>

タイムアウトを100msに変更する場合のプロファイル

$ cat opt_profile.del"TUKIV95","SETTIMEOUT","opt.xml"$ db2 "import from ./opt_profile.del of del modified by lobsinfile insert intosystools.opt_profile"<省略>Number of rows rejected = 0Number of rows committed = 1

$ db2 "select substr(schema,1,10),substr(name,1,15) from systools.opt_profile"SCHEMA NAME---------- ---------------TUKIV95 SETTIMEOUT

プロファイルの登録手順



PSU_temp_0522

リアルタイム統計情報収集のタイムアウト値を変更する方法– プロファイルの使用方法

– CURRENT OPTIMIZATION PROFILE 特殊レジスターをセットする

– BIND時にOPTPROFILE バインド・オプションをセットする

– CURRENTOPTIMIZATIONPROFILE クライアント構成オプションをdb2cli.iniにセット

（CLIアプリケーションの場合）

– 大きな表を新規作成し、リアルタイム統計情報収集を動かした場合の例。

– 前ページで登録したプロファイルを使用する場合としない場合で、統計情報収集に費やしている時間が異なる。（5秒 -> 100ミリ秒）

+ db2 SET CURRENT OPTIMIZATION PROFILE = tukiv95.settimeoutDB20000I The SQL command completed successfully.+ db2 declare c1 cursor for with temp(a) as ( values(1) union all select a+1 from temp where a<800000) selectcast( rand() * 10000 as int),'DummyStringString' from tempDB20000I The SQL command completed successfully.+ db2 load from c1 of cursor insert into jits6<省略>Number of rows committed = 800000

+ db2 select count(*) from jits6 where c1 in (23, 38, 43)1-----------

2551 record(s) selected.

+ awk /^Statistic fab/+ db2 get snapshot for db on sample+ {for(i=1;i<6;i++){print " "$0;getline}}

Statistic fabrications = 1Synchronous runstats = 1Asynchronous runstats = 0Total statistic fabrication time (milliseconds) = 59Total synchronous runstats time (milliseconds) = 101

+ db2 declare c1 cursor for with temp(a) as ( values(1) union all select a+1 from temp where a<800000) selectcast( rand() * 10000 as int),'DummyStringString' from tempDB20000I The SQL command completed successfully.+ db2 load from c1 of cursor insert into jits6<省略>Number of rows committed = 800000

+ db2 select count(*) from jits6 where c1 in (23, 38, 43)1-----------

2551 record(s) selected.

+ db2 get snapshot for db on sample+ awk /^Statistic fab/+ {for(i=1;i<6;i++){print " "$0;getline}}

Statistic fabrications = 1Synchronous runstats = 1Asynchronous runstats = 0Total statistic fabrication time (milliseconds) = 34Total synchronous runstats time (milliseconds) = 5002



PSU_temp_0522

LOBの照会パフォーマンス改善



PSU_temp_0522

LOB照会パフォーマンス上の課題

これまでの課題

– LOBを含む照会のパフォーマンスは、LOBを含まない照会のパフォーマンス（同サイズのVARCHAR等）と比較して遅かった。

– LOBがより一般的に使用されるようになったため、パフォーマンスの改善が求められてきた。

原因

– LOBデータは、DRDA上通常データとは別に転送される。

– LOB列を含む結果セット1レコードごとに、データのリクエストが必要。（ブロッキング・カーソルが使用できない）

– LOBデータの配置が通常のデータページと異なる場所にあるため、1レコードの取得のため複数回のI/Oを必要とする。

– LOBデータは、バッファープールに載らない。

V9.5での

改善点



PSU_temp_0522

連続ストリーミングのサポート

DB2 9.5 for LUWよりサーバ側がDDF（Dynamic Data Format）に対応

– DB2 V9.1 for z/OS及び、DB2 V9.1 for LUW FP1（クライアント）は、先行して対応。

– DDF（Dynamic Data Format）とは

• DRDAの拡張。DDFに対応したクライアント・サーバ間では、クライアントに送信するLOBのサイズに応じて3通りの転送モードが使用される。

• サーバ、クライアントのどちらかがDDFに対応しない場合は、これまでと同様の手順で通信する。

– 「DB2 V9.1 for LUWのサーバと、DB2 V9.5 for LUWのクライアント」等

– DB2 V9.1 for LUW までは、mode2に相当する転送方式のみを使用

DDFの持つ3つの転送モード

アプリケーション

DB2

FETCH

MODE１通常データに同梱

QRYDTA


DB2

レコード

FETCH

MODE2別オブジェクトで転送

EXTDTA LOB


DB2

FETCH

MODE3参照情報のみ同梱

EXTDTALOB

getString

QRYDTAレコード Ref

QRYDTAレコード LOB

V9.5New



PSU_temp_0522

Note：

3通りの転送モードとは

– mode1(LOBサイズ小) ：varcharと同様に、通常データに同梱される（QRYDTA）

– mode2(LOBサイズ中) ：通常データの後に付加される。（EXTDTA) （DB2 V9.1 for LUWと同様）

– mode3(LOBサイズ大) ：QRYDTAには参照情報のみが含まれ、

必要になった時点(getStringやgetBytes等）で実データが送信される

アプリケーション・インターフェースごとにDDFへの対応状況が異なる

– サポート済み

• CLI

• DB2 .NET Data Provider

• IBM Data Server Driver for JDBC and SQLJ

• 組み込みSQL （MODE3 は未サポート）

– 未サポート

• OLE DB .NET Data Provider

• IBM OLE DB Provider for DB2(ADO)

• レガシーJDBCドライバー

– DDFを未サポートのインターフェースでは、これまでと同様の仕組みとなる。

DDF対応有無の判断

– 照会の開始時（カーソルのオープン等）にクライアントからサーバに送信するコマンド（OPNQRY）中に、DDFへの対応有無を表すデータが含まれる。



PSU_temp_0522


使用する転送モードの決定方法

– 転送しようとするLOBのサイズを元に、サーバ側で決定する。

• それぞれのモードのしきい値は、DRDAの接続手順中にクライアント側から指定する。

• DB2 V9.5（サーバ/クライアント）では、下記の表がデフォルトのしきい値として使用される。

– 採用する転送モードは、LOBデータの実際の長さで決まる。

• LOB列の定義上の長さではない

• 個々のLOBオブジェクトサイズを見て、適切なモードを判断する。

小値大値

Mode1 LOBサイズ小 0 照会ブロック・サイズ

Mode2 LOBサイズ中照会ブロックサイズ＋１ 1,048,576 (1MB）

Mode3 LOBサイズ大 1,048,577（1MB+1） 2GB

DB2 for LUWでのデフォルトのしきい値

(*)「照会ブロック・サイズ」は、ローカル環境ではASLHEAPSZ、リモート環境ではRQRIOBLKで決定される。



PSU_temp_0522

Note：

SEND BUFFER(AS):

QRYDTA OBJDSS (ASCII)

0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF

0000 001BD05300010015 241BFF0000010000 ...S....$.......

0010 0000020000000000 000064 ..........d

EXTDTA OBJDSS (ASCII)

0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF

0000 006FD05300010069 146C004141414141 .o.S...i.l.AAAAA

0010 4141414141414141 4141414141414141 AAAAAAAAAAAAAAAA





0060 4141414141414141 41414141414141 AAAAAAAAAAAAAAA

SQLCARD OBJDSS (ASCII)

0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF

0000 000BD00300010005 2408FF ........$..

SEND BUFFER(AS):

QRYDTA OBJDSS (ASCII)

0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF

0000 00CFD003000100C9 241BFF0000010000 ........$.......

0010 0000010000000000 0000644141414141 ..........dAAAAA






0070 4141414141414141 4141414141414100 AAAAAAAAAAAAAAA.

0080 6400000030323030 3053514C52493031 d...02000SQLRI01

0090 4600010004800100 0000000000000000 F...............

00A0 0000000000000000 0000202020202020 ..........

00B0 2020202020001253 414D504C45202020 ..SAMPLE

00C0 2020202020202020 2000000000FFFF ......

DB2 V9.1 for LUWの場合 DB2 V9.5 for LUWの場合

V9.1でのLOBデータは、QRYDTAとは別のEXTDTAオブジェクトに格納されたが、V9.5ではQRYDTA中に含まれる。

create table t1 (a int,b clob(10m));

insert into t1 values (1, clob(repeat(clob('AAAAAAAAAA'),10)));

select * from t1;

小さなLOBデータを投入し、SELECTした場合のDRDAトレース



PSU_temp_0522


関連するパラメーター

– ASLHEAPSZ/RQRIOBLK（データベース・マネージャー構成パラメーター）

• クライアント/サーバー間の通信バッファー。

• LOBデータ転送を行う際、このパラメータの設定値がmode1/2のしきい値となる。

• ローカルアプリケーションではASLHEAPSZ、リモートアプリケーションではRQRIOBLKが使用される。

– DB2_MAX_LOB_BLOCK_SIZE（DB2レジストリー変数）

• LOBデータを返却する際の、ブロックサイズの大値を指定。（デフォルト：0 制限無し）

• CLI/ODBC構成キーワードとして、同様の指定をする「MaxLOBBlockSize」も存在する。

– streamBufferSize（jccプロパティ）

• 結果セットにLOBデータそのものを含めるか、LOBロケーターもしくはプログレッシブ参照を含めるかのしきい値（mode2/3のしきい値）を指定

• CLI/ODBC構成キーワードとして、同様の指定をする「LOBCacheSize」も存在する。



PSU_temp_0522




PSU_temp_0522

連続ストリーミングのサポート JDBCの対応状況

サーバー側が連続ストリーミングをサポートしていれば、連続ストリーミングの動作がデフォルト

– DB2 for LUW V9.5以降で、LOBの連続ストリーミングをサポート

– DB2 for z/OS V9.1以降で、LOBおよびXMLオブジェクトの連続ストリーミングをサポート

ドライバー側

– バージョン

• IBM Data Server Driver for JDBC and SQLJ バージョン3.1(V9 GA)よりサポート

• IBM Data Server Driver for JDBC and SQLJ バージョン3.2(V9 FP1)よりDB2 for z/OS V9.1以降への接続では

連続ストリーミングの動作がデフォルト

• IBM Data Server Driver for JDBC and SQLJ バージョン3.5よりDB2 for LUW V9.5以降への接続では連続スト

リーミングの動作がデフォルト

– 関連するプロパティー

• progressiveStreaming• streamBufferSize• fullyMaterializeLobData



PSU_temp_0522

Note：

完全にマテリアライズ化されたデータ: 完全なLOBデータを１つのフローで送信

ストリーミング・データ: LOBデータのサブセットを複数のフローで送信

progressiveStreamingプロパティー:– データ・ソース上で連続ストリーミングがサポートされている場合に、JDBC ドライバーが連続ストリーミングを使用するかどうかを指定します。

streamBufferSize パラメーターの値は、データが戻されるときにマテリアライズ化されるかどうかを決定します。

streamBufferSizeプロパティー:– LOB または XMLデータをチャンク化するための、JDBC ドライバー・バッファーのサイズをバイト数で指定します。

fullyMaterializeLobDataプロパティー:– データ・ソースが連続ロケーターをサポートしない場合: fullyMaterializeLobDataの値が true の場合、行が取り出されるときに LOBデータは JDBCドライ

バー内で完全にマテリアライズされます。この値が false の場合、LOBデータはストリームされます。ドライバーは内部でロケーターを使用し、必要に応じてLOBデータをチャンクごとに検索します。大量のデータを収容している LOBを検索する場合、この値を false に設定するように強くお勧めします。デフォルトはtrueです。

– データ・ソースが連続ストリーミングをサポートする場合: progressiveStreamingプロパティーが YES (アプリケーション・プログラム内ではDB2BaseDataSource.YES) に設定されているか、または設定されていない場合、JDBCドライバーはfullyMaterializeLobDataの値を無視します。

fullyMaterializeLobData

progressiveStreaming

true false

Data size <= streamBufferSize 完全にマテリアライズされたデータ

完全にマテリアライズされたデータ

Data size > streamBufferSize ストリーミング・データストリーミング・データ

NO 完全にマテリアライズ化されたデータ

ロケーター

YES or NOT_SET



PSU_temp_0522

連続ストリーミングのサポート JDBC関連の障害情報

– 現象

• DB2 9.5 for LUW GA版で、1MBを超えるLOBの照会時にSQLSTATE=58015が発生し、SELECTが失敗する。（APAR番号： IZ06831）

• jccドライバの障害として、DB2 9.5 for LUW FP1でFix予定。

– 発生する条件

• クライアントにDB2 9.5 for LUW GA版を使用して、連続ストリーミングをサポートするサーバへ接続。– 接続先サーバは、DB2 for LUW及び、DB2 for z/OSでエラーの発生を確認。

• IBM Data Server Driver for JDBC and SQLJ 3.5.0/4.0 からType2で接続。

• 1MBを超えるLOBデータをSELECTし、length()、getString()、getBytes()等、クライアントがLOBの実データを要求するメソッドを実行。

– 1MBが境界となるのは、progressiveStreamingがデフォルト設定の場合。連続ストリーミングのMODE3で動作する場合に発生する。

• 同様の条件でも、Type4接続では問題なく動作する。

– 回避策

① Type4接続へ変更する

② MODE3での動作を抑止する

– jccプロパティのstreamBufferSizeを、デフォルトの1MBから拡張する。（大2GB）

– ただし、FETCHタイミングでLOBデータがアプリケーションに戻され、JVMのメモリーに展開される。巨大なLOBを取り扱う場合は下記のLOBロケーター使用を推奨

③ LOBロケーターを使用する

– jccプロパティのprogressiveStreamingをNOに、fullyMaterializeLobDataをfalseに変更する。

– LOBデータのサイズによらず初は参照情報のみが戻されるため、サイズの小さなLOBが大多数を占める場合はパ

フォーマンスが劣る可能性がある。



PSU_temp_0522

Note：

アプリケーション側で出力されるメッセージ

com.ibm.db2.jcc.b.hm: [jcc][20105][11271][3.50.152] DDM オブジェクトはサポートされていません。 DDM オブジェクトのコード・ポイントはサポートされません: 0x146c。ERRORCODE=-4499, SQLSTATE=58015

at com.ibm.db2.jcc.b.wc.a(wc.java:281)

at com.ibm.db2.jcc.b.wc.a(wc.java:319)

at com.ibm.db2.jcc.t4.bb.E(bb.java:4546)

at com.ibm.db2.jcc.t4.bb.A(bb.java:637)

at com.ibm.db2.jcc.t4.bb.i(bb.java:471)

at com.ibm.db2.jcc.t4.bb.g(bb.java:229)

at com.ibm.db2.jcc.t4.bb.b(bb.java:160)

at com.ibm.db2.jcc.t4.r.b(r.java:36)

at com.ibm.db2.jcc.t4.b.xb(b.java:2457)

at com.ibm.db2.jcc.b.eb.o(eb.java:898)

at com.ibm.db2.jcc.b.eb.i(eb.java:823)

at com.ibm.db2.jcc.t4.b.i(b.java:4393)

at com.ibm.db2.jcc.b.eb.g(eb.java:792)

at com.ibm.db2.jcc.b.eb.commit(eb.java:775)

at Db.disconnect(Util.java:292)

at DtLob.main(DtLob.java:94)



PSU_temp_0522

ブロッキングが有効な場合

•初回のFETCHで、サーバからは複数レコードを伝送。

•伝送レコードはブロッキング・バッファーへ保持し、2回目以降のFETCHではバッファーよりレコードを取得する。

ブロッキングが無効な場合

•FETCHのたびにサーバへレコードを要求。

ブロッキング・バッファー

LOBのブロッキングをサポート

V9.5より、LOBを含む結果セットをブロッキングすることが可能になった。

– V9.1までは、結果セットにLOBデータが含まれる場合ブロッキングされず、FETCHのたびにサーバに対するリクエストが必要となっていた。

– ブロッキング・サイズは通常データと同様、照会ブロック・サイズで決定される。

アプリケーションの対応

– アプリケーションの書き換えは必要なし。サーバ/クライアントがサポートし、設定が有効になっている場合、自動的にブロッキング・カーソルとして動作する。

FETCH


DB2

FETCH FETCH FETCH


DB2

FETCH

レコード2

FETCH

レコード3レコード1

レコード1 レコード2 レコード3レコード1～3

V9.5New



PSU_temp_0522

Note：

ブロッキング・カーソルが使用されるかどうかは、SQLを実行するパッケージの「BLOCKING」設定と、カーソルの種類によって決定されます。

カーソルの種類

– 「曖昧でないカーソル」とは、読み取り専用のカーソル（FROM句に複数の表が記述される等）もしくは、「FOR FETCH(READ) ONLY」がついている照会

– 「曖昧なカーソル」とは読み取り専用のカーソルではなく、かつ「FOR FETCH(READ) ONLY」がついていない照会。

BLOCKINGの設定

– プリコンパイルもしくはBIND時に指定する

– 「BLOCKING UNAMBIG」の場合

• ブロッキングが有効になるのはUNAMBIGUOUS（曖昧でない）カーソルのみ（デフォルト）

– 「BLOCKING ALL」の場合

• UNAMBIGUOUS（曖昧でない）カーソルに加えて、AMBIGOUS（曖昧な）カーソルでもブロッキングが有効

– 「BLOCKING NO」の場合

• カーソルの種類によらずブロッキングが無効

LOB値を返すユーザー定義関数を使用する場合、ブロッキングは無効になります。

LOB固有の制約



PSU_temp_0522

LOBのブロッキングをサポート

LOB固有のブロッキング・カーソル関連の設定

– CLIアプリケーションでは、db2cli.iniで設定

• BlockLobs=1 ：LOBのブロッキングが有効

• BlockLobs=0 ：LOBのブロッキングが無効（デフォルト）

– 組み込みSQLでの設定

• SQLRULES （LOB列取り出しのルールを決めるオプション。プリコンパイル時に指定する。）

– DB2 ：初回FETCH時にLOBデータを直接取り出すか、LOBロケーターを使用するかを決定。

LOBのブロッキングを使用可能。（デフォルト）

– STD ：各FETCHのタイミングでLOB列取り出しの形式を選択可能。BLOCKINGの設定によらずLOBのブロッキングは無効となる。



PSU_temp_0522

Note：ブロッキングの有無によるDRDAデータフローの違い

SEND BUFFER(AS):

QRYDTA OBJDSS (ASCII) 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF

0000 0085D0030001007F 241BFF0000000000 ........$.......0010 01005A5A5A5A5A00 0100000000000000 ..ZZZZZ.........0020 643C3F786D6C2076 657273696F6E3D22 d<?xml version="0030 312E302220656E63 6F64696E673D2255 1.0" encoding="U0040 54462D3822203F3E 0A3C51756F74653E TF-8" ?>.<Quote>0050 0A3C51756F74655F 4E756D6265723E30 .<Quote_Number>00060 3C2F51756F74655F 4E756D6265723E0A </Quote_Number>.0070 3C51756F74655F44 6174653E32303030 <Quote_Date>20000080 2D30312D30 -01-0

<省略>SEND BUFFER(AR):

CNTQRY RQSDSS (ASCII) 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF

0000 0072D0010001006C 200600442113424C .r.....l ..D!.BL0010 4B44422020202020 2020202020202020 KDB 0020 4E554C4C49442020 2020202020202020 NULLID 0030 202053514C433247 3133202020202020 SQLC2G13 0040 2020202041414141 414E475800C90008 AAAAANGX....0050 21140000FFFF0006 2141FFFF000C215B !.......!A....![0060 0000000000000000 0005214802000521 ..........!H...!0070 4CF0 L.

<省略>SEND BUFFER(AS):


0000 0085D0030001007F 241BFF0000000000 ........$.......0010 01005A5A5A5A5A00 0100000000000000 ..ZZZZZ.........0020 643C3F786D6C2076 657273696F6E3D22 d<?xml version="0030 312E302220656E63 6F64696E673D2255 1.0" encoding="U0040 54462D3822203F3E 0A3C51756F74653E TF-8" ?>.<Quote>0050 0A3C51756F74655F 4E756D6265723E30 .<Quote_Number>00060 3C2F51756F74655F 4E756D6265723E0A </Quote_Number>.0070 3C51756F74655F44 6174653E32303030 <Quote_Date>20000080 2D30312D30 -01-0

SEND BUFFER(AS):


0000 017BD00300010175 241BFF0000000000 .{.....u$.......0010 01005A5A5A5A5A00 0100000000000000 ..ZZZZZ.........0020 643C3F786D6C2076 657273696F6E3D22 d<?xml version="0030 312E302220656E63 6F64696E673D2255 1.0" encoding="U0040 54462D3822203F3E 0A3C51756F74653E TF-8" ?>.<Quote>0050 0A3C51756F74655F 4E756D6265723E30 .<Quote_Number>00060 3C2F51756F74655F 4E756D6265723E0A </Quote_Number>.0070 3C51756F74655F44 6174653E32303030 <Quote_Date>20000080 2D30312D30FF0000 00000001005A5A5A -01-0........ZZZ0090 5A5A000100000000 000000643C3F786D ZZ.........d<?xm00A0 6C2076657273696F 6E3D22312E302220 l version="1.0" 00B0 656E636F64696E67 3D225554462D3822 encoding="UTF-8"00C0 203F3E0A3C51756F 74653E0A3C51756F ?>.<Quote>.<Quo00D0 74655F4E756D6265 723E303C2F51756F te_Number>0</Quo00E0 74655F4E756D6265 723E0A3C51756F74 te_Number>.<Quot00F0 655F446174653E32 3030302D30312D30 e_Date>2000-01-0

<省略>

ブロッキング無効の場合、行データが格納されるQRYDTAの間に、次行を要求するCONTQRYコマンドが存在する。

ブロッキングが有効な場合、1つのQRYDTAに2レコード分のデータが格納される。

ブロッキング無効ブロッキング有効



PSU_temp_0522

参考：VARCHAR/LOBの照会パフォーマンス比較

VARCHARとLOBそれぞれのデータ型からの照会パフォーマンスを比較

– V9.1/V9.5それぞれで、db2batchを用いて同じデータを10000件SELECT。

– 10回試行し、2～9回目の結果を平均

結果

– V9.1では10倍程度であったVARCHAR/CLOBのパフォーマンス差が、V9.5では3～4倍程度に縮小している。（100byte/500byte）

– V9.1 => V9.5で、小さなLOBの照会時間が1/3程度に短縮している。

単位：ms

データサイズ

100byte 500byte 8KB

VARCHAR 38 49 210

CLOB 469 479 574

VARCHAR 37 45 208

CLOB 130 135 326v9.5

v9.1 約12倍

約3倍

約1/3



PSU_temp_0522

Note：

0

100

200

300

400

500

600

700

100byte 500byte 8KB

FETCH対象のデータサイズ

応答時間

v9.1 VARCHAR

v9.1 CLOBv9.5 VARCHAR

v9.5 CLOB

10,000件FETCH時の応答時間比較（ms）

約1/3 約1/3

約1/2



PSU_temp_0522

MDCロールアウトの高速化



PSU_temp_0522

MDCの削除パフォーマンス強化

セル、スライス単位のDELETEをさらに高速化

– 即時索引クリーンアップ・ロールアウト(DB2 UDB v8.2.2で実装)

– 据え置き索引クリーンアップ・ロールアウト

• MDC表に存在する索引のメンテナンスを、非同期で行うことが可能に

yeardimension

colourdimension

nationdimension

Cell for (1997, Canada, yellow)

1997, Canada,

blue

1997, Mexico, yellow

1997, Mexico,

blue

1997, Canada, yellow

1998, Canada, yellow1997,

Mexico, yellow

1998, Mexico, yellow1997,

Canada, yellow

1998, Canada, yellow

1998, Mexico, yellow

Each cell contains one or more blocks.

V9.5New



PSU_temp_0522

MDCロールアウトの制約

以下の条件下ではロールアウトは使用されない

– WHERE節に、次元列以外の列が削除条件として指定されている

– 表作成時に「DATA CAPTURE CHANGES」を指定（ﾚﾌﾟﾘｹｰｼｮﾝ）

– 削除トリガーが定義されている

– FETCH FIRST n ROWS を指定

– 次元列のUpdate(内部的には、delete and insert)

– カーソルを使用したDelete(‘WHERE CURRENT OF’)

– 参照保全の親表となっている ※

– REFRESH IMMEDIATEのMQTとして使用されている

– DELETEステートメントがOLD TABLE文節のSELECTステートメントとなっている

※外部キーがその表の次元列のサブセットである場合、カスケード削除操作はロールアウトされる



PSU_temp_0522

ロールアウトを使用する際には・・・

DB2_MDC_ROLLOUT レジストリ変数による設定

– ロールアウトの動作に関し、以下の3種類の設定が可能

• 1, TRUE, ON, YES, IMMEDIATE (default)> MDC 表からのロールアウトが使用可能になる

• 0, FALSE, OFF, NO> ロールアウトは使用不可

• DEFER> 据え置き索引クリーンアップのロールアウト

特殊レジスターによる設定

– レジストリ変数の設定を上書き可

– CURRENT MDC ROLLOUT MODE に3種類の設定が可能

• DELETEステートメント毎に設定を変更できる– SET CURRENT MDC ROLLOUT MODE IMMEDIATE CLEANUP

– SET CURRENT MDC ROLLOUT MODE NONE

– SET CURRENT MDC ROLLOUT MODE DEFERRED CLEANUP

V9.5New



PSU_temp_0522

ロールアウトの確認方法

db2explnによりアクセスパス確認

– ロールアウト使用時

• Cell Delete: Table Name = ・・・

– 通常の削除時

• Delete: Table Name = ・・・

– 即時(Immediate)なのか据え置き(Deferred)なのかは判別不能

• 即時と据え置きの発動条件は同じであるため、DB2_MDC_ROLLOUT=DEFERの設定がなされていれば、必ず据え置きとなる。

– db2exfmtには出力されない



PSU_temp_0522

Note：

db2explnの例（ロールアウト ⇔ 通常のDelete）

==================== STATEMENT ==========================================

Isolation Level = Cursor StabilityBlocking = Block Unambiguous CursorsQuery Optimization Class = 5

Partition Parallel = NoIntra-Partition Parallel = No

SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "SYSIBMADM","TAIRA95"

Statement:

deletefrom mdc1where c2=1

Section Code Page = 1208

Estimated Cost = 1521.245605Estimated Cardinality = 200.000000

( 3) Access Table Name = TAIRA95.MDC1 ID = 6,2| Index Scan: Name = TAIRA95.MDC1_IX2 ID = 5| | Regular Index (Not Clustered)| | Index Columns:| | | 1: C2 (Ascending)| #Columns = 0| Clustered by Dimension for Block Index Access| #Key Columns = 1| | Start Key: Inclusive Value| | | | 1: 1| | Stop Key: Inclusive Value| | | | 1: 1| Index-Only Access| Index Prefetch: None| Lock Intents| | Table: Intent Exclusive| | Block: Intent Exclusive| | Row : Exclusive

( 2) Cell Delete: Table Name = TAIRA95.MDC1 ID = 6,2

End of section

==================== STATEMENT ================================

Isolation Level = Cursor StabilityBlocking = Block Unambiguous CursorsQuery Optimization Class = 5

Partition Parallel = NoIntra-Partition Parallel = No

SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "SYSI

Statement:

deletefrom mdc1where c3=1

Section Code Page = 1208

Estimated Cost = 764.409180Estimated Cardinality = 100.000000

( 3) Access Table Name = TAIRA95.MDC1 ID = 6,2| Index Scan: Name = TAIRA95.MDC1_IX3 ID = 6| | Regular Index (Not Clustered)| | Index Columns:| | | 1: C3 (Ascending)| #Columns = 0| Clustered by Dimension for Block Index Access| #Key Columns = 1| | Start Key: Inclusive Value| | | | 1: 1| | Stop Key: Inclusive Value| | | | 1: 1| Index-Only Access| Index Prefetch: None| Lock Intents| | Table: Intent Exclusive| | Block: Intent Exclusive| | Row : Exclusive

( 2) Delete: Table Nam

End of section

==========

BMADM","TAIRA95"

e = TAIRA95.MDC1 ID = 6,2



PSU_temp_0522

MDC 即時(Immediate)索引クリーンアップ・ロールアウト

削除レコードをログせず、物理削除しないことで高速化

① ブロックに”ROLLOUT”とマーク

② ブロック索引からBID（ブロックID）を除去

③ ブロックの各ページにあるスロットディレクトリをクリア

④ ページ当り、１つのログレコードが書き込まれる（行単位ではない）

索引は同期で更新される

– 各索引のキーの削除のために、行をスキャンしなければならない

– 索引のロギングには変更はない



PSU_temp_0522




PSU_temp_0522

MDC 据え置き(Deferred)索引クリーンアップ・ロールアウト

DELETEステートメントにより・・・

① ブロックに“INUSE”、“ROLLOUT”とマーク

② ブロック索引からBID（ブロックID）を除去

③ ブロックの各ページにあるスロットディレクトリをクリア

④ ページ当り、１つのログレコードが書き込まれる（行単位ではない）

⑤ 索引メンテナンスのため、非同期バックグラウンドプロセスを起動

ブロックのロールアウト毎に、バックグラウンドプロセスは・・・

① 各ブロックを“INUSE”, “ROLLOUT”, “CLEANUP”とマーク

② RID索引を更新

③ ブロックを開放し、再利用可能とマーク



PSU_temp_0522

MDC 据え置き(Deferred)索引クリーンアップ・ロールアウト

メリット

– DELETE ステートメントが高速になる

– 表へのアクセス可能 – クエリーの実行可能

– 削除ログ量が削減されるため、「Fetch First N Rows Only」句を使用して、削除SQLを複数回に分割する必要が無くなる

バックグラウンドの索引クリーンアッププロセス

– 索引毎にクリーナーが起動され、索引メンテナンス時間が削減

• 即時索引クリーンアップは、索引を１つずつ処理

– 索引削除のログ量削減

• RID単位から索引ページ単位へ



PSU_temp_0522

バックグラウンド索引クリーンアップ・プロセスの確認方法

SYSPROC.ADMIN_GET_TAB_INFO_v95 表関数

– BLOCKS_PENDING_CLEANUP列を検索

db2 GET SNAPSHOT FOR DB ON <database name>

$ db2 “select BLOCKS_PENDING_CLEANUP from table (SYSPROC.ADMIN_GET_TAB_INFO_V95 ( 'TAIRA95', 'MDC1')

) as T”

BLOCKS_PENDING_CLEANUP----------------------

11

1 レコードが選択されました。

$ db2 get snapshot for db on sample | grep MDCクリーンアップ中の MDC 表ブロックの数 = 11



PSU_temp_0522


db2 LIST UTILITIES SHOW DETAIL$ db2 LIST UTILITIES SHOW DETAIL

ID = 12タイプ = MDC ROLLOUT INDEX CLEANUPデータベース名 = SAMPLEパーティション番号 = 0説明 = TABLE: TAIRA95 .MDC1開始時刻 = 2007-10-23 11:55:38.628330状態 = 実行中呼び出しタイプ = 自動スロットル:

優先順位 = 50進捗モニター:

推定完了パーセント = 72フェーズ番号 = 1

説明 = TAIRA95 .MDC1_IX3合計作業 = 6 pages完了作業 = 6 pages開始時刻 = 2007-10-23 11:55:38.674716

フェーズ番号 = 2説明 = TAIRA95 .MDC1_IX2合計作業 = 6 pages完了作業 = 2 pages開始時刻 = 2007-10-23 11:55:38.674718

フェーズ番号 = 3説明 = TAIRA95 .MDC1_IX1合計作業 = 6 pages完了作業 = 5 pages開始時刻 = 2007-10-23 11:55:38.674718



PSU_temp_0522


管理通知ログ（インスタンス名.nfy）、診断ログ（db2diag.log）$ more taira95.nfy

2007-10-23-11.55.38.639090 Instance:taira95 Node:000PID:639192(db2taskp (SAMPLE) 0) TID:5434 Appid:*LOCAL.DB2.071023025538AIC aicRolloutIndexCleanup Probe:2075 Database:SAMPLE

ADM9514I BEGIN async index cleanup on table "TAIRA95 .MDC1" (ID "2") and tablespace "SMSTS1" (ID "6").^^2007-10-23-11.55.38.771351 Instance:taira95 Node:000PID:639192(db2taskp (SAMPLE) 0) TID:5434 Appid:*LOCAL.DB2.071023025538AIC aicRolloutIndexCleanup Probe:2280 Database:SAMPLE

ADM9515I END async index cleanup on table "TAIRA95 .MDC1" (ID "2") and tablespace "SMSTS1" (ID "6").^^



PSU_temp_0522




PSU_temp_0522

MDC ロールアウトパフォーマンスデータ

1,100万行 (134,260 pages), 16K page, 16 extent size, 4 nodes, 8 RID indexes

Delete response time (in percentage) for different rollout options

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

0.3 1.5 3.0 30.0 97.0

Percentage Delete in Table

Perc

enta

ge

Delete (no rollout)

Immediate rollout

Deferred rollout including asynccleanup

Deferred rollout not including asynccleanup



PSU_temp_0522

MDC ロールアウトログスペース使用量

1,100万行 (134260 pages), 16K page, 16 extent size, 4 nodes, 8 RID indexes

Log space usage (in percentage) for different rollout options

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

03 1.5 3.0 30.0 97.0

Percentage Delete in Table

Perc

enta

ge Delete (no rollout)

Immediate rollout

Deferred rollout



PSU_temp_0522

どちらのロールアウトを使用すべき？

据え置きクリーンアップ・ロールアウト

– 削除スピード

– 多くのRID索引を持ったMDC表

– 限られたログスペース

– 非常に大規模な削除

即時クリーンアップ・ロールアウト

– 開放されたブロックを即時に再利用

– 削除後の索引スキャンパフォーマンス

– メモリーの抑制（データベース・ヒープ）

– 少量の削除

– RID索引のないMDC表



PSU_temp_0522




PSU_temp_0522

オプティミスティック・ロッキング拡張サポート



PSU_temp_0522

ペシミスティック・ロッキングとオプティミスティック・ロッキングの概念

あるデータに対して更新を意図した参照を行う場合のロッキング手法

– 参照したデータの更新を確実に成功させたい場合

→ペシミスティック・ロッキング（悲観的ロッキング）を使用

– 更新するデータの参照時に更新（U）ロックを取得する（SELECT ... FOR UPDATE）

– 他のアプリケーションは、参照はできるが更新はできない

– アプリケーションの同時並行性を向上させたい場合

→オプティミスティック・ロッキング（楽観的ロッキング）を使用

– 参照から更新の間にロックを保持しない

– 他のアプリケーションは、参照、更新ともに可能

– 参照から更新の間に> その行が他のアプリケーションによって更新されていなければ、更新は成功する

> その行が他のアプリケーションによって更新されていれば、更新は失敗する

• 更新を意図して参照するものの、更新まで実行されないことが多いケースで有効

自分が更新するデータを他の人が更新することはないだろう・・・

自分が更新するデータを他の誰かが更新するかもしれない・・・



PSU_temp_0522

ペシミスティック・ロッキング（悲観的ロッキング）の例

Time

SELECT COL1 FROM T1WHERE COL2=“AAA”…..（ロック待機）…..

（ロック待機解消）→COL1=3000

UPDATE T1SET COL1=COL1+1000WHERE COL2=“AAA”

アプリケーション2アプリケーション1

1000

3000

3000

4000

SELECT COL1 FROM T1WHERE COL2=“AAA”→COL1=1000

UPDATE T1SET COL1=COL1+2000WHERE COL2=“AAA”

値（COL1）

LOCK

LOCK

参照～更新の間にロックを保持し、他のアプリケーションからの更新を防ぐ。

→アプリケーションの同時並行性は低下するが、アプリケーション1の更新は確実に成功する。



PSU_temp_0522

オプティミスティック・ロッキング（楽観的ロッキング）の例

Time

SELECT COL1 FROM T1WHERE COL2=“AAA”→COL1=1000（ロック待機しない）

UPDATE T1SET COL1=COL1+1000WHERE COL2=“AAA”AND ...

アプリケーション2アプリケーション1

1000

3000

値（COL1）

1000

SELECT COL1 FROM T1WHERE COL2=“AAA”→COL1=1000（ロックを保持しない）

UPDATE T1SET COL1=COL1+2000WHERE COL2=“AAA”AND ...

元の行が更新されていないかをチェック

OK

OK

元の行が更新されていないかをチェック

参照～更新の間にロックを保持せず、他のアプリケーションからも参照、更新が可能。

→アプリケーション1の更新が成功することは必ずしも保証されないが、アプリケーションの同時並行性が向上する。

NG

リトライ



PSU_temp_0522

オプティミスティック・ロッキングの実装方法

V9.1以前（例）

– 以下のような方法で、参照から更新の間に他のアプリケーションからの更新が実行されなかったかを判断する

• 表に更新タイムスタンプを記録するUPDATEトリガーを定義しておき、参照時に取得したタイムス

タンプと更新時のタイムスタンプを比較する

• 参照時に全列をSELECTし、更新時に全列の値を比較する

V9.5新機能

– 直近の更新時の情報（RID、行変更トークン）をDB2が各行に保持するようになったため、

これらの情報を元に、更新の有無を判断することができる

→これまでより容易に、オプティミスティック・ロッキングを実装することが可能に。



PSU_temp_0522




PSU_temp_0522

select col1, RID_BIT(tab1) as row_id, row change token for tab1 as row_change_tok from tab1

RID_BIT()組み込み関数、ROW CHANGE TOKEN

RID_BIT()組み込み関数（および、RID()組み込み関数）

– 行のRIDをVARCHAR FOR BIT DATAとして返す

– SELECTリスト内、もしくは述部ステートメントで使用可能

• 参考）RID()組み込み関数

– RIDをBIGINTとして返す

– z/OSとの互換性のために用意されており、z/OSへ移植されるアプリケーションのみこの関数を使用する

– DPFでは使用不可

ROW CHANGE TOKEN（行変更トークン）

– 行が後に変更された時点を示すトークンをBIGINTとして返す

– SELECTリスト内、もしくは述部ステートメントで使用可能



PSU_temp_0522

RIDと行変更トークンを使用したオプティミスティック・ロッキングの実装

1. SELECTステートメント実行時に、RIDと行変更トークンをSELECTする

2. （ロックを解放する）

3. 1.でSELECTしたRIDと行変更トークンを条件として、ターゲット行に対する更新（UPDATE/DELETE）を実行する（元の行が更新されていないと仮定）

– 元の行が更新されていなければ、更新は成功

– 元の行が更新されていれば、更新は失敗（1.からリトライする）

SELECT SALARY, ROW CHANGE TOKEN FOR EMPLOYEE, RID_BIT (EMPLOYEE)FROM EMPLOYEE WHERE EMPNO = ‘000010'

UPDATE EMPLOYEE E SET SALARY= SALARY*1.1WHERE EMPNO = ‘000010’ AND

RID_BIT (E) =x'00000000014000040000000000FA9023' ANDROW CHANGE TOKEN FOR E =141272772982181532"



PSU_temp_0522

ROW CHANGE TIMESTAMP列の定義

ROW CHANGE TIMESTAMP 列– 行が後に更新された時刻（更新されていなければ、挿入された時刻）を保持する

– 生成列として定義する（CREATE TABLE, ALTER TABLE）

– 使用方法（SELECTリスト、述部にて指定）

• 列名を直接指定する

• ROW CHANGE TIMESTAMP FOR <表名>を使用

– IMPLICITLY HIDDEN属性を定義し、隠し列にすることが可能

• 明示的に列を指定したときのみ、列が表示される（”SELECT * FROM ...“では表示されない）

• V9.5からの新機能。現時点ではROW CHANGE TIMESTAMP列にのみ使用可能

– ROW CHANGE TIMESTAMP列は、以下のキー、列、名前ではサポートされない

• 主キー、外部キー

• MDCの次元列

• パーティション表のパーティション・キー

• データベース・パーティションの分散キー

• DETERMINED BY（機能従属関係）制約列

• ニックネーム

GENERATED ALWAYS FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMPGENERATED BY DEFAULT FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP



PSU_temp_0522

参考）使用例

$ db2 "create table tab_tt (col1 int, col2 int, rct timestamp not null generated always for each row on update as row change timestamp)”

DB20000I SQL コマンドが正常に完了しました。

$ date;db2 "insert into tab_tt(col1,col2) values(1,1)"

Fri Sep 21 16:29:50 JST 2007


$ db2 "select col1, rct, row change timestamp for tab_tt as row_change_timestamp from tab_tt"

COL1 RCT ROW_CHANGE_TIMESTAMP

----------- -------------------------- --------------------------

1 2007-09-21-16.29.50.427331 2007-09-21-16.29.50.427331


$ date;db2 "update tab_tt set col1=11 where col1=1"

Fri Sep 21 16:30:19 JST 2007


$ db2 "select col1, rct, row change timestamp for tab_tt as row_change_timestamp from tab_tt"

COL1 RCT ROW_CHANGE_TIMESTAMP

----------- -------------------------- --------------------------

11 2007-09-21-16.30.19.333966 2007-09-21-16.30.19.333966




PSU_temp_0522

ROW CHANGE TIMESTAMPとROW CHANGE TOKEN

ROW CHANGE TIMESTAMP列が定義されている場合、ROW CHANGE TOKENの値は、ROW CHANGE TIMESTAMP列から派生する

行ごとに参照可能

COL1 COL2 .. ROW CHANGE TIMESTAMP

….. …… … …………………………

内部的に関連性を持つ

RID ROW CHANGE TOKEN

TAB_TT



PSU_temp_0522

同一ページ中のレコード


ROW CHANGE TIMESTAMP列が定義されていない場合、ROW CHANGE TOKENの値は、データ・ページ中の管理情報から導出される。

– TIMESTAMP列を定義しない場合、表/ページの構造は変更無し

– ある行が更新されると、同一ページ内のすべての行のトークンが変わる

行ごとに参照可能

COL1 COL2 ..

….. …… …

RID ROW CHANGE TOKEN

TAB_TT

ページ単位で共通



PSU_temp_0522


表にROW CHANGE TIMESTAMP 列が定義されているかどうかで、 ROW CHANGE TOKENの細分性が異なる

– ※同一ページ内の別の行が更新されたことによってROW CHANGE TOKENが変更され、後の更新が失敗しないよう、ROW CHANGE TIMESTAMP列を作成する

• ｆalse negative：更新されていない行が更新されたと見なされ、後の更新が失敗すること

ROW CHANGE TIMESTAMP列あり ROW CHANGE TIMESTAMP列なし

ROW CHANGE TOKENの値

ROW CHANGE TIMESTAMPから導出

され、行ごとに異なるトークンを持つ

（ある行が更新されると、更新された行のみ、トークンが変わる）

ページ・ヘッダ中の情報から導出され、ページ単位でトークンを共有する

（ある行が更新されると、同一ページ内のすべての行のトークンが変わる）

false negative 起こらない

（例外：REORGによりRIDが変更された

場合は起こる）

起こる

表構造の変更必要あり必要なし



PSU_temp_0522




PSU_temp_0522

実行例

– シナリオ１

• 行変更タイムスタンプ列が表に定義され、行を変更したアプリケーションは他に存在しない状態で、行を更新する場合

– シナリオ２

• RAW CHANGE TIMESTAMPが表に定義されており、select後、更新（およびコミット）の前に、別のアプリケーションが同じ行を更新してしまう場合

– シナリオ３

• ROW CHANGE TIMESTAMP列が表に定義されていない場合で、select後、更新（およびコミット）の前に、別のアプリケーションが別の行を更新した場合

– シナリオ４

• ROW CHANGE TIMESTAMP列が定義されている場合で、select後、更新（およびコミット）の前に、別のアプリケーションによって表の再編成が行われた場合



PSU_temp_0522

シナリオ１

COL1 COL2 RCT

AAA …… …………………………

BBB …… …………………………

CCC …… …………………………

TAB_1App1db2 “select col1,・・・row change token for tab_1,rid_bit(tab_1)”

db2 “update tab_1 set col1 = ‘D’ where ・・・row change token for tab_1 = ……,rid_bit(tab_1) = ……”

①

②

※Row change timestamp列を持っている表に対する更新

アプリケーション１が、特定の行を選択し、

選択したトークンを条件として更新する場合。

・・・



PSU_temp_0522

シナリオ１

$ db2 -tvf crtbl.ddl

drop table tab_1


create table tab_1(col1 char(10),col2 int,rct timestamp not null generated always for each row on update as row change timestamp)


$ db2 describe table iwata.tab_1

Data type Column

Column name schema Data type name Length Scale Nulls

------------------------------- --------- ------------------- ---------- ----- ------

COL1 SYSIBM CHARACTER 10 0 はい

COL2 SYSIBM INTEGER 4 0 はい

RCT SYSIBM TIMESTAMP 10 0 いいえ


$ db2 "insert into tab_1(col1,col2) values('AAA',111),('BBB',222),('CCC',333)"




PSU_temp_0522

$ db2 "select col1,col2,rct,RID_BIT(tab_1) as row_id,row change token for tab_1 as row_change_tok from tab_1"

COL1 COL2 RCT ROW_ID ROW_CHANGE_TOK

---------- ----------- -------------------------- ----------------------------------- --------------------

BBB 222 2007-09-21-19.29.13.605462 x'00000000028000040000000001975B0E' 141272621765967126

AAA 111 2007-09-21-19.29.13.606030 x'000000000280000400010000007D0818' 141272621765967694

CCC 333 2007-09-21-19.29.13.613887 x'000000000280000500010000007D0818' 141272621765975551


$ db2 "update tab_1 set col1='D' where col1 = 'CCC' and row change token for tab_1 = 141272621765975551 and rid_bit(tab_1) = x'000000000280000500010000007D0818'"


$ db2 "select col1,col2,rct,RID_BIT(tab_1) as row_id,row change token for tab_1 as row_change_tok from tab_1"

COL1 COL2 RCT ROW_ID ROW_CHANGE_TOK

---------- ----------- -------------------------- ----------------------------------- --------------------

AAA 111 2007-09-21-19.29.13.606030 x'000000000280000400010000007D0818' 141272621765967694

D 333 2007-09-25-18.42.44.653792 x'000000000280000500010000007D0818' 141273168131783136

BBB 222 2007-09-21-19.29.13.605462 x'00000000028000040000000001975B0E' 141272621765967126


シナリオ１

他のアプリケーションから更新されていないため、

update が成功。



PSU_temp_0522

シナリオ２

COL1 COL2 RCT

AAA …… ……………

BBB …… ……………

CCC …… ……………


① App2db2 “select col1,・・・row change token for tab_1,rid_bit(tab_1)”

②

db2 “update tab_1 set col1 = ‘D’ where ・・・row change token for tab_1 = ……,rid_bit(tab_1) = ……”db2 “update tab_1 set col1 = ‘D’ where

・・・row change token for tab_1 = ……,rid_bit(tab_1) = ……”

③④

※Row change timestamp列を持っている表に対する更新。

アプリケーション１が選択した後更新する前に、

アプリケーション２が同じ行を選択して更新する場合

・・・・・・・・・・・・・



PSU_temp_0522

シナリオ２

$ db2 "select col1,col2,rid_bit(tab_1) as rid_bit, row change token for tab_1 as row_change_token from tab_1"

COL1 COL2 RID_BIT ROW_CHANGE_TOKEN

---------- ----------- ----------------------------------- --------------------

BBB 222 x'00000000028000040000000001975B0E' 141272621765967126

DDDDDD 333 x'00000000028000050000000001975B0E' 141273170156383942

AAA 111 x'000000000280000400010000007D0818' 141272621765967694


$ 050000000001975B0E' and row change token for tab_1=141273170156383942" <

SQL0100W FETCH、UPDATE または DELETE

の対象となる行がないか、または照会の結果が空の表です。 SQLSTATE=02000

$ db2 "select col1,col2,rid_bit(tab_1) as rid_bit, row change token for tab_1 as row_change_token from tab_1"


---------- ----------- ----------------------------------- --------------------

BBB 222 x'00000000028000040000000001975B0E' 141272621765967126

DDDDDD 333 x'00000000028000050000000001975B0E' 141273170156383942

AAA 111 x'000000000280000400010000007D0818' 141272621765967694


$ db2 "update tab_1 set col2=333333 where rid_bit(tab_1)=x'00000000028000050000000001975B0E' and row change token for tab_1=141273170156383942"


APPL2APPL１

時

間

更新対象となる行の検出に失敗してしまうため、更新失敗！

更新成功

①

②

③

④



PSU_temp_0522

シナリオ３

COL1 COL2

AAA ……

BBB ……

CCC ……


① App2db2 “select col1,・・・row change token for tab_1,rid_bit(tab_1)”

②

db2 “update tab_1 set col1 = ‘D’ where ・・・row change token for tab_1 = ……,rid_bit(tab_1) = ……”db2 “update tab_1 set col1 = ‘D’ where

・・・row change token for tab_1 = ……,rid_bit(tab_1) = ……”

③④

※Row change timestamp列を持たない表に対する更新。

アプリケーション１が選択した後更新する前に、

アプリケーション２が同じページに存在しているほかの行を更新する場合

・・・・・・・・・・・・・



PSU_temp_0522

シナリオ３

$ db2 connect to sample

データベース接続情報

データベース・サーバー = DB2/AIX64 9.5.0

SQL 許可 ID = IWATA

ローカル・データベース別名 = SAMPLE

$ db2 -tvf crtbl.ddl

create table tab_2(col1 char(10),col2 int)


$ db2 "insert into tab_2 values('aaa',10),('bbb',11),('ccc',12),('ddd',13),('eee',14)"


$ db2 "select col1,col2,rid_bit(tab_2) as rid_bit,row change token for tab_2 as row_change_token from tab_2"


---------- ----------- ----------------------------------- --------------------

bbb 11 x'0000000002C00004000000000232C08A' 36885461

ccc 12 x'0000000002C00005000000000232C08A' 36885461

eee 14 x'0000000002C00006000000000232C08A' 36885461

aaa 10 x'0000000002C000040001000000FA000C' 16385533

ddd 13 x'0000000002C000050001000000FA000C' 16385533


表に行変更タイムスタンプ列を作成していないため、一つのページ上で一つのトークン値を共有



PSU_temp_0522



---------- ----------- ----------------------------------- --------------------

bbb 11 x'0000000002C00004000000000232C08A' 36885461

ccc 12 x'0000000002C00005000000000232C08A' 36885461

eee 14 x'0000000002C00006000000000232C08A' 36885461

aaa 10 x'0000000002C000040001000000FA000C' 16385533

ddd 13 x'0000000002C000050001000000FA000C' 16385533


$ db2 "update tab_2 set col1='BBB' where rid_bit(tab_2)=x'0000000002C00004000000000232C08A' and row change token for tab_2=36885461"


シナリオ３



---------- ----------- ----------------------------------- --------------------

bbb 11 x'0000000002C00004000000000232C08A' 36885461

ccc 12 x'0000000002C00005000000000232C08A' 36885461

eee 14 x'0000000002C00006000000000232C08A' 36885461

aaa 10 x'0000000002C000040001000000FA000C' 16385533

ddd 13 x'0000000002C000050001000000FA000C' 16385533


$ db2 "update tab_2 set col1='CCC' where rid_bit(tab_2)=x'0000000002C00005000000000232C08A' and row change token for tab_2=36885461"



APPL2

時

間

軸

更新成功

①

②

③

④

APPL１

更新対象となる行の検出に失敗してしまうため、更新失敗！



PSU_temp_0522



---------- ----------- ----------------------------------- --------------------

BBB 11 x'0000000002C00004000000000232C08A' 36885604

ccc 12 x'0000000002C00005000000000232C08A' 36885604

eee 14 x'0000000002C00006000000000232C08A' 36885604

aaa 10 x'0000000002C000040001000000FA000C' 16385533

ddd 13 x'0000000002C000050001000000FA000C' 16385533


$ db2 "update tab_2 set col1='CCC' where rid_bit(tab_2)=x'0000000002C00005000000000232C08A' and row change token for tab_2=36885604"


シナリオ３

APPL2で、’bbb’→’BBB’へ変更された時に、ページ上で共有している行変更トークンの値が変わっていた！

従って,‘ccc’を更新する時のwhere条件と合致しない結果となった

新しい行変更トークンの値を指定すると更新が成功する

APPL１



PSU_temp_0522

シナリオ４

COL1 COL2 RCT

aaa …… …………………………

XXXXX …… …………………………

XXXXX …… …………………………

XXXXX …… …………………………

ccc …… …………………………

BBBBBB …… …………………………

…… …………………………

TAB_1

App1db2 “select col1,・・・row change token for tab_1,rid_bit(tab_1)”

db2 “update tab_1 set col1 = ‘D’ where ・・・row change token for tab_1 = ……,rid_bit(tab_1) = ……”

①

②

削除

削除

削除

※Row change timestamp列を持っている表に対する更新

アプリケーション１が選択した後更新する前に、表の再編成が行われた場合



PSU_temp_0522

シナリオ４

APPL１

$ db2 "select col1,rid_bit(tab_1),row change token for tab_1 from tab_1"

COL1 2 3

---------- ----------------------------------- --------------------

BBBBBB x'00000000030000040000000002EE66C4' 141273409543197521

aaa x'00000000030000050000000002EE66C4' 141273430809033061

- x'00000000030000060000000002EE66C4' 141273299230029048

ccc x'00000000030000070000000002EE66C4' 141273430809040255

xxxxx x'00000000030100000000000002EE66C4' 141273430459005525

xxxxx x'00000000030100010000000002EE66C4' 141273430459005527

xxxxx x'00000000030100020000000002EE66C4' 141273430459005529

xxxxx x'00000000030100030000000002EE66C4' 141273430459005531

xxxxx x'00000000030100040000000002EE66C4' 141273430459005533

xxxxx x'00000000030100050000000002EE66C4' 141273430459005535

xxxxx x'00000000030100060000000002EE66C4' 141273430459005537

xxxxx x'00000000030100070000000002EE66C4' 141273430459005539

xxxxx x'00000000030100080000000002EE66C4' 141273430459005541

xxxxx x'00000000030100090000000002EE66C4' 141273430459005543

xxxxx x'000000000301000A0000000002EE66C4' 141273430459005545

xxxxx x'000000000301000B0000000002EE66C4' 141273430459005547

- x'000000000301000C0000000002EE66C4' 141273430459005549


この行を変更（update）しようとしている



PSU_temp_0522

$ db2 "delete from tab_1 where col1='xxxxx'"


$ db2 reorg table tab_1

DB20000I REORG コマンドが正常に完了しました。


COL1 2 3

---------- ----------------------------------- --------------------

BBBBBB x'00000000028000040000000002EE79F0' 141273409543197521

aaa x'00000000028000050000000002EE79F0' 141273430809033061

- x'00000000028000060000000002EE79F0' 141273299230029048

ccc x'00000000028000070000000002EE79F0' 141273430809040255

- x'00000000028000080000000002EE79F0' 141273430459005549


シナリオ４

APPL2

再編成後、行変更トークンの値は変わっていないが、RIDは変更されている

行を削除し、再編成を実施する



PSU_temp_0522

$ db2 "update tab_1 set col1='BBB' where col1='BBBBBB' and rid_bit(tab_1)=x'00000000030000040000000002EE66C4' and row change token for tab_1=141273409543197521




COL1 2 3

---------- ----------------------------------- --------------------

BBBBBB x'00000000028000040000000002EE79F0' 141273409543197521

aaa x'00000000028000050000000002EE79F0' 141273430809033061

- x'00000000028000060000000002EE79F0' 141273299230029048

ccc x'00000000028000070000000002EE79F0' 141273430809040255

- x'00000000028000080000000002EE79F0' 141273430459005549


$ db2 "update tab_1 set col1='BBB' where col1='BBBBBB' and rid_bit(tab_1)=x'00000000028000040000000002EE79F0' and row change token for tab_1=141273409543197521



COL1 2 3

---------- ----------------------------------- --------------------

BBB x'00000000028000040000000002EE79F0' 141273431145146589

aaa x'00000000028000050000000002EE79F0' 141273430809033061

- x'00000000028000060000000002EE79F0' 141273299230029048

ccc x'00000000028000070000000002EE79F0' 141273430809040255

- x'00000000028000080000000002EE79F0' 141273430459005549


シナリオ４

APPL１

①で得ていた、RIDとrow change tokenを指定して更新するが、失敗してしまう

再度、SELECTを実行し、RIDとrow change tokenを調べると、RIDが変わっている

（行の値が変わっていないのでrow change tokenは変わらない）

新しいRIDを指定して更新すると、更新は成功する

更新により、row change tokenが変更される



PSU_temp_0522

オプティミスティック・ロッキング使用時の考慮点

頻繁に、複数のアプリケーションから同じデータへの更新が発生するようなシステムには適さない。

– 更新処理の失敗が頻繁に起こるため。

REORG処理によりRIDが変更された場合、行が変更されたと見なされ、更新が

失敗する。

– 特に、オンラインREORGとの共存する場合に注意が必要。

（LBACでのアクセス制御を使用している場合）オプティミスティック・ロッキングを使用するユーザーは、ROW CHANGE TIMESTAMP列が参照可能である必要

がある。



PSU_temp_0522




PSU_temp_0522


V9.5で新しく表スペースを作成すると、No File System Cachingで作成される

– 新規作成のみ、V9.5以前から既存の表スペースへは影響なし

– 但し、以下のものはV9.1の時と同様にFile System CachingがデフォルトThis change applies to AIX, LinuxR, Solaris, and Windows with the following exceptions, where the

default behavior remains to be FILE SYSTEM CACHING:AIX JFS Solaris non-VxFSLinux for System zAll SMS temporary table space files SMS permanent table space files, except for long field (LF) data and large object (LOB) data files.

– DMS FILEの表スペースに、LOBを格納する場合注意が必要。

• LOBの再読込を行うようなアプリケーションでは、パフォーマンス低下の可能性があるため、明示的な「FILE SYSTEM CACHING」の設定を推奨。



PSU_temp_0522

CREATE TABLESPACEの変更点

>>-CREATE--+-----------------------+---------------------------->

+-LARGE-----------------+

+-REGULAR---------------+

| .-SYSTEM-. |

'-+--------+--TEMPORARY-'

'-USER---'

(省略）

>--+------------------------+----------------------------------->

+-NO FILE SYSTEM CACHING-+

'-FILE SYSTEM CACHING----‘

(説明追記部分）

FILE SYSTEM CACHING or NO FILE SYSTEM CACHINGSpecifies whether or not I/O operations are to be cached at the file system level. If neither option is specified, the

default is:FILE SYSTEM CACHING for JFS on AIX, Linux System z, all non-VxFS file systems on Solaris, HPUX, SMS

temporary table space files on all platforms, and all LOB and large data NO FILE SYSTEM CACHING on all other platforms and file system types FILE SYSTEM CACHING Specifies that all I/O operations in the target table space are to be cached at the file system level. NO FILE SYSTEM CACHING Specifies that all I/O operations are to bypass the file system-level cache.

Note：



PSU_temp_0522

Note：

Platforms File system type and minimum level required

DIO or CIO requests submitted by the database manager when NO FILE SYSTEM CACHING is specified

Default behavior when neither NO FILE SYSTEM CACHING nor FILE SYSTEM CACHING is specified

Journal File System (JFS) DIO FILE SYSTEM CACHING

※On AIX JFS, FILE SYSTEM CACHING is the default.

AIX5.3+

Concurrent Journal File System (JFS2) ,

VERITAS Storage Foundation for DB2 4.1 (VxFS)

CIO NO FILE SYSTEM CACHING

No specific requirement, works on all DB2 supported file systems

DIO NO FILE SYSTEM CACHING

Windows



PSU_temp_0522

Note：

Platforms File system type and minimum level required

DIO or CIO requests submitted by the database manager when NO FILE SYSTEM CACHING is specified

Default behavior when neither NO FILE SYSTEM CACHING nor FILE SYSTEM CACHING is specified

ext2, ext3, reiserfs DIO NO FILE SYSTEM CACHING

Linux distributions SLES 9+ and RHEL 4+

(on these architectures: x86, x86_64, IA64, POWER™)

VERITAS Storage Foundation 4.1 (VxFS)

CIO NO FILE SYSTEM CACHING

ext2, ext3 or reiserfs on a Small Computer System Interface (SCSI) disks using Fibre Channel Protocol (FCP)

DIO NO FILE SYSTEM CACHING

Linux distributions SLES 9+ and RHEL 4+

(on this architecture: zSeries®)



PSU_temp_0522

索引構築の並列処理がデフォルトで有効になった



PSU_temp_0522




PSU_temp_0522

索引の並列処理設定

索引作成処理の並列処理の条件が変更

– V8、V8.2、V9.1での並列処理条件

• INTRA_PARALLEL=YESの設定時（オンラインでの構成不可）

– MAX_QUERYDEGREEで並列度の上限設定

• 表サイズが並列処理のメリットが得られる大きさ

• 複数のCPUが使用可能な環境

– V9.5からの並列処理条件

• INTRA_PARALLELの設定は

考慮しなくなった

索引作成のパフォーマンス向上

– 並列にデータのスキャン、ソートを実施

複数CPUが使用可能表サイズの大きさ CPU並列

INTRA_PARALLEL=YES

複数CPUが使用可能表サイズの大きさ

CPU並列



PSU_temp_0522

設定変更による影響

メリット

– デフォルトの設定で索引作成のパフォーマンス向上

– INTRA_PARALLEL=YESへ変更しなくても、索引作成時に複数CPUのメリットが享受できる

– INTRA_PARALLELを変更してしまうと

• インスタンス配下の全DBの全SQLが影響

• 照会用の並列度設定– DFT_DEGREEなどの並列度設定の値の見直し

• アクセスパスの変化– 変化したアクセスパスをチェックする

考慮点

– 索引作成のジョブに関して、CPU使用率などのリソースが逼迫する

• V9.1以前の環境で、CPU使用率の観点から索引を意図的に並列で作成しているジョブがある場合など

Value Driven Proposals...2007/12/58/3/05 この文書のデータの利用または公開には、...

Documents

Transcript of Value Driven Proposals...2007/12/58/3/05 この文書のデータの利用または公開には、...