3. 可用性とスケーラビリティ

＜第１．００版 ２０12年 9月＞
3. 可用性とスケーラビリティ
本資料掲載事項は、ある特定の環境・使用状況においての正確性がIBMによって確認されていますが、すべての環境において同様の結果が得られる保証は
ありません。これらの技術を自身の環境に適用する際には、自己の責任において十分な検証と確認を実施いただくことをお奨めいたします。
© Copyright IBM Japan Systems Engineering Co., Ltd. 2012
1
© 2012 IBM Corporation
内容
• HADR機能強化
• レプリケーション機能強化
• DB2 pureScale Feature機能強化
2
© 2012 IBM Corporation
HADR機能強化
3
© 2012 IBM Corporation
HADR機能強化内容
• マルチスタンバイ
• ログ・スプーリング
• HADR遅延再生
4
© 2012 IBM Corporation
V10.1のHADR新機能の背景
• 迅速な引継ぎを実現できていた今までのHADRでも以下のような悩みがあった
• 非同期モードを使っていても、スタンバイとの距離が遠い場合、トランザクションに影響がでる・・・
災害対策向けの構成だと難しい・・・
• HADRを使っていると必ずスタンバイ側にはログが適用されてしまう、ユーザー側で反映させるタ
イミングを制御したい・・・
• 可用性構成だけではなく、災害対策として複数拠点にスタンバイを作成したい、など
・超非同期モードでプライマリートラン
ザクションへの影響を削減！！
・HADR遅延再生やログ・スプーリング
機能でスタンバイ側のReplayタイミン
グを指定可能に！！
・Localにスタンバイ（可用性構成）、更
に異なる拠点にもスタンバイ（災対構
成）というマルチスタンバイ構成が可能
に！！
5
© 2012 IBM Corporation
HADR（High Availability Disaster Recovery）
• V8.2
プライマリーのみアクセス可能
• HADR新機能
• V9.5
• HADR PEER WINDOW提供
• TSAとの統合（db2haicu）
Primary
• V9.7 FixPack1
スタンバイも参照可能
• スタンバイ読み取り機能の提供
• V9.7 FixPack5 (V9.5FixPack8)
Standby
Primary
Standby
• 超非同期モードの追加
複数スタンバイ構成が可能
• V10.1
• 複数スタンバイのサポート
• ログ・スプーリング
• 遅延再生
Primary
Standby
6
© 2012 IBM Corporation
HADR同期モード
HADR
HADR
send()
receive()
log writer
log
log
file
file
Commit Succeeded
7
© 2012 IBM Corporation
参考）超非同期（SUPERASYNC）モード
• 超非同期モードの特徴
• V9.5 FP8、V9.7FP5以降に追加された同期モード
• 通常のシングルDBと同様に、トランザクションログをプライマリDBのディスクに書き込んだ
時点で、アプリケーションにCommitを返す
• アプリケーションの応答時間へのHADRオーバーヘッドが最も尐ない同期モード
• HADR用NW帯域が十分でない場合や、スタンバイ側の再生処理が遅延するような場合での
性能影響を軽減することが可能
• 考慮点
• データロストについて
• プライマリDBの更新処理のみを保障するため、プライマリ側で障害が発生し、待機系に引き
継ぐ場合には、データロストが発生する可能性がある
• HADRの状態について
• 超非同期モードでは、HADRが、PEER状態または切断済みPEER状態にならないため、ログ
ギャップを個別に監視する必要がある
8
© 2012 IBM Corporation
HADR 複数スタンバイ
プリンシパル・スタンバイ
プライマリー
超非同期のみ
補助スタンバイ
補助スタンバイ
• 全てのスタンバイDBは、プライマリーDBから直接接続される
• プライマリーDBから補助スタンバイへ繋がるような数珠繋ぎは不可
• スタンバイ読み取り機能は全てのスタンバイDBでサポート
• 引継ぎは、どのスタンバイDBからも実行可能
• 引継ぎ後、スタンバイDBのプライマリDBに関するDB構成パラメーター情報を
書き換え、新しいプライマリーDBを認識する
• プリンシパル・スタンバイDBが不在の場合プライマリーのHADRを起動できない
• by forceであれば起動可能
9
© 2012 IBM Corporation
HADR 複数スタンバイ（メリット・制約）
• 複数スタンバイ（最大3スタンバイDB）を構成可能
• HADRによって、ローカルサイトでの冗長化と、災対の両方を構築可能
• プライマリーの可用性をダウンさせずに、スタンバイにFix適用し、ローリングアップ
グレードさせることが出来る
• V9.7まではスタンバイのFix適用の際、一旦HADRを停止する必要があった
• プリンシパル・スタンバイDB(PS)は、現行のスタンバイと同等
• プライマリーとPS間は全ての同期モードをサポート
• TSAを使用して、自動引継ぎが可能
• プライマリーから補助スタンバイへの引継ぎは自動引継ぎ構成は未サポート
• 最大2つの補助スタンバイDB(AS)をサポート
• プライマリーとAS間は、超非同期モードのみサポート
• プライマリーからの自動引継ぎはサポートしていない
• PSと同様に、常に現在のプライマリDBからログが伝播される
10
© 2012 IBM Corporation
複数スタンバイの設定方法（ホストの指定）
• 新しく提供された HADR_TARGET_LIST DB構成パラメーターを指定
• V10.1以前の1対1のHADRペアで起動したい場合には、設定不要
• スタンバイの台数が2台の場合はリストに2台分指定する
•
“|” を区切り文字にして、ホスト名またはIPアドレスを指定する
全てのリストは、現在のプライマ
リーを指定している必要がある
• 例） host1.ibm.com:4000|host2.ibm.com:4010
• HADR_TARGET_LIST は、プリンシパルと補助スタンバイの全てを指定
する
• プライマリーDBで最初に指定されたホストが、プリンシパルスタンバイ
となり、残りのDBは補助スタンバイになる
• 全てのスタンバイが、リストにプライマリーを指定する必要がある
プリンシパルスタンバイ
HADR_TARGET_LIST =
<myPrincSB:port>|
<myAuxSB1:port>|
<myAuxSB2:port>
補助スタンバイ
HADR_TARGET_LIST =
<myPrincSB:port>|
<myAuxSB1:port>|
<myAuxSB2:port>
補助スタンバイ
プライマリー
HADR_TARGET_LIST =
<princSB:port>|<auxSB1:port>|<auxSB2:port>
11
HADR_TARGET_LIST =
<myPrincSB:port>|
<myAuxSB1:port>|
<myAuxSB2:port>
© 2012 IBM Corporation
複数スタンバイ の設定方法（同期モードの指定）
• DB構成パラメーターHADR_SYNC_MODE
は、プライマリーとプリンシパルスタンバイの
同期モードを指定する
• HADR_SYNC_MODEが設定されていても、
スタンバイがプリンシパルか補助スタンバイ
かを判断して、有効同期モード（effective
sync mode )が設定される
host2:11 (プリンシパルスタンバイ)
HADR_TARGET_LIST =
host1:10
HADR_SYNC_MODE = SYNC
Effective sync mode = SYNC
host3:12 (補助スタンバイ)
HADR_TARGET_LIST =
host4:13|host1:10
HADR_SYNC_MODE = SYNC
Effective sync mode = SUPERASYNC
host4:13 (補助スタンバイ)
host1:10 (プライマリー)
HADR_TARGET_LIST =
host2:11|host3:12|host4:13
HADR_SYNC_MODE = SYNC
12
HADR_TARGET_LIST =
host3:12|host1:10
HADR_SYNC_MODE = SYNC
Effective sync mode = SUPERASYNC
© 2012 IBM Corporation
4台構成のHADR環境の構築例
• host1,host2,host3,host4の4台でマルチスタンバイを構成する場合の手順
は以下のとおり
• 手順１：host1でログの設定及びDBバックアップを取得する
• 手順２：host1で取得したDBバックアップを各ノードに restore
• 手順３：構成パラメーターの変更を各ノードにおいて実施
• 手順４：host2-4にてスタンバイとしてHADRを起動
• 手順５：host1にてプライマリーとしてHADRを起動
• 手順６：db2pdでロールを確認
13
© 2012 IBM Corporation
HADR マルチスタンバイ構成図
Localサイト
DRサイト
DBサーバ Primary(host1:hadr_p)
DBサーバ Aux1(host3:hadr_a1)
HADR_TARGET_LIST =host2:hadr_s|
host3:hadr_a1|host4:hadr_a2
HADR_TARGET_LIST= host4:hadr_a2|
host1:hadr_p|host2:hadr_s
Primaryになったら
Aux2がPrincipal
Primaryになったら
旧PrimaryがPrincipal
14
Primaryになったら
Aux1がPrincipal
DBサーバ Principal(host2:hadr_s)
DBサーバ Aux2(host4:hadr_a2)
HADR_TARGET_LIST= host1:hadr_p|
host3:hadr_a1|host4:hadar_a2
HADR_TARGET_LIST= host3:hadr_a1|
host1:hadr_p|host2:hadr_s
© 2012 IBM Corporation
構築手順１：host1でログの設定及びDBバックアップを取得
する
$ hostname
host1
$ db2start
06/12/2012 13:44:01
0 0 SQL1063N DB2START の処理が正常に終了しました。
SQL1063N DB2START の処理が正常に終了しました。
$ db2 "update db cfg for sample using LOGARCHMETH1 DISK:/home/db2inst1/archive/"
DB20000I UPDATE DATABASE CONFIGURATION コマンドが正常に完了しました。
$ db2 backup db sample to /QITWORK/bkup
バックアップは成功しました。 このバックアップ・イメージのタイム・スタンプは
20120612135148 です。
$ ls -ltr
total 315280
-rwxrwxrwx
1 db2inst1 db2test 161419264 Jun 12 13:51 SAMPLE.0.db2inst1.DBPART000.20120612135148.001
→各ノードにコピー
15
© 2012 IBM Corporation
構築手順2： host1で取得したDBバックアップを各ノードに
restore
$ hostname
host2
$ db2 restore db sample from /QITWORK/bkup
SQL2539W 警告!
バックアップ・イメージ・データベースと同じ既存データベースをリストアします。デー
タベース・ファイルは削除されます。
続けますか。 (y/n) y
DB20000I RESTORE DATABASE コマンドが正常に完了しました。
→同様に、host3、host4で上記手順を実施
16
© 2012 IBM Corporation
構築手順3:構成パラメーターの変更を各ノードにおいて実施
Localサイト
<host1>
HADR_LOCAL_HOST: host1
DRサイト
Primary
<host3>
HADR_LOCAL_HOST: host3
HADR_LOCAL_SVC: hadr_p
HADR_REMOTE_HOST: host2
HADR_REMOTE_SVC: hadr_s
SUPERASYNC
Aux1
HADR_LOCAL_SVC: hadr_a1
HADR_REMOTE_HOST: host1
LOGINDEXBUILD : ON
HADR_REMOTE_SVC: hadr_p
HADR_REMOTE_INST: db2inst1
HADR_TARGET_LIST :
host3:hadr_a1|host4:hadr_a2 | host2:hadr_s
HADR_SYNCMODE:NEARSYNC
LOGINDEXBUILD : ON
HADR_REMOTE_INST: db2inst1
HADR_TARGET_LIST :
host2:hadr_s|host3:hadr_a1|host4:hadr_a2
SYNC or NEARSYNC or ASYNC
<host2>
HADR_LOCAL_HOST: host2
Principal
HADR_LOCAL_SVC: hadr_s
HADR_REMOTE_HOST: host1
HADR_REMOTE_SVC: hadr_p
HADR_REMOTE_INST: db2inst1
HADR_TARGET_LIST :
host1:hadr_p|host3:hadr_a1|host4:hadr_a2
SUPERASYNC
<host4>
HADR_LOCAL_HOST: host4
Aux2
HADR_LOCAL_SVC: hadr_a2
HADR_REMOTE_HOST: host1
HADR_REMOTE_SVC: hadr_p
HADR_REMOTE_INST: db2inst1
HADR_TARGET_LIST :
host4:hadr_a2 | host3:hadr_a1| host2:hadr_s
LOGINDEXBUILD : ON
LOGINDEXBUILD : ON
HADR_SYNCMODE:NEARSYNC
17
© 2012 IBM Corporation
構築手順3:構成パラメーターの変更を各ノードにおいて実施
• host1での変更例
$ hostname
host1
$ db2 -tvf db2cfg_host1.txt
update db cfg for sample using HADR_LOCAL_HOST host1
DB20000I UPDATE DATABASE CONFIGURATION コマンドが正常に完了しました。
update db cfg for sample using HADR_LOCAL_SVC hadr_p
DB20000I UPDATE DATABASE CONFIGURATION コマンドが正常に完了しました。
update db cfg for sample using HADR_REMOTE_HOST host2
DB20000I UPDATE DATABASE CONFIGURATION コマンドが正常に完了しました。
HADR_TARGET_LIST以外は9.7以
前からのパラメーター
update db cfg for sample using HADR_REMOTE_SVC hadr_s
DB20000I UPDATE DATABASE CONFIGURATION コマンドが正常に完了しました。
update db cfg for sample using HADR_REMOTE_INST db2inst1
DB20000I UPDATE DATABASE CONFIGURATION コマンドが正常に完了しました。
update db cfg for sample using HADR_TARGET_LIST host2:hadr_s|host3:hadr_a1|host4:hadr_a2
DB20000I UPDATE DATABASE CONFIGURATION コマンドが正常に完了しました。
update db cfg for sample using LOGINDEXBUILD ON
DB20000I UPDATE DATABASE CONFIGURATION コマンドが正常に完了しました。
→同様に、残りの3つのDBサーバーでパラメーターを設定
18
© 2012 IBM Corporation
構築手順4：host2-4にてスタンバイとしてHADRを起動
$ hostname
host2
$ db2 start hadr on db sample as standby
DB20000I START HADR ON DATABASE コマンドが正常に完了しました。
$ hostname
host3
$ db2 start hadr on db sample as standby
DB20000I START HADR ON DATABASE コマンドが正常に完了しました。
$ hostname
host4
$ db2 start hadr on db sample as standby
DB20000I START HADR ON DATABASE コマンドが正常に完了しました。
19
© 2012 IBM Corporation
構築手順5： host1にてプライマリーとしてHADRを起動
$ hostname
host1
$ db2 start hadr on db sample as primary
DB20000I START HADR ON DATABASE コマンドが正常に完了しました。
以上で、4台構成のHADRマルチスタンバイ構成が完成
20
© 2012 IBM Corporation
構築手順6： db2pdでロールを確認
$ hostname
HADR_ROLE = PRIMARY
host1
HADR_SYNCMODE = SUPERASYNC
$ db2pd –hadr –db sample
STANDBY_ID = 2
HADR_STATE = REMOTE_CATCHUP
(以下抜粋して掲載。db2pdの詳細については後述。）
PRIMARY_MEMBER_HOST = host1
STANDBY_MEMBER_HOST = host3
Database Member 0 -- Database SAMPLE -- Active
HADR_CONNECT_STATUS = CONNECTED
-- Up 0 days 01:23:49 -- Date 2012-06-13 15:10:35
HADR_ROLE = PRIMARY
HADR_ROLE = PRIMARY
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 1
HADR_SYNCMODE = SUPERASYNC
STANDBY_ID = 3
HADR_STATE = REMOTE_CATCHUP
HADR_STATE = PEER
PRIMARY_MEMBER_HOST = host1
PRIMARY_MEMBER_HOST = host1
STANDBY_MEMBER_HOST = host4
STANDBY_MEMBER_HOST = host2
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS = CONNECTED
・・・確認ポイント
21
© 2012 IBM Corporation
HADR マルチスタンバイ4台構成による引継ぎ例
• 引継ぎ例1： Primary→Aux1へ正常テークオーバー
• Primary→Aux1へ正常テークオーバー
• 引継ぎ後はAux1のターゲットリストの1番目に設定しているAux2が
Principalとして稼動
• 引継ぎ例2：Primary→Principalへ強制テークオーバー
• Primaryのインスタンスがダウン
• Principalへ強制引継ぎ
• 引継ぎ後、HADRは3台構成で稼動
22
© 2012 IBM Corporation
引継ぎ例1:Primary→Aux1へ正常テークオーバー
• Primary→Aux1へ正常テークオーバーする手順は以下の
とおり
• 手順１：host3（Aux1）でtakeover hadrコマンドを実施
• 手順２：db2pdでロールが変更されていることを確認
23
© 2012 IBM Corporation
引継ぎ例1 イメージ図
Localサイト
DBサーバ Primary(host1:hadr_p)
HADR_TARGET_LIST =host2:hadr_s|
host3:hadr_a1|host4:hadr_a2
DRサイト
①
Primary
から
Aux1に
TKO
DBサーバ Aux1(host3:hadr_a1)
HADR_TARGET_LIST= host4:hadr_a2|
host1:hadr_p|host2:hadr_s
②Aux1として
稼動
②Principal
として稼動
②Aux2として
稼動
24
DBサーバ Principal(host2:hadr_s)
DBサーバ Aux2(host4:hadr_a2)
HADR_TARGET_LIST= host1:hadr_p|
host3:hadr_a1|host4:hadar_a2
HADR_TARGET_LIST= host3:hadr_a1|
host1:hadr_p|host2:hadr_s
© 2012 IBM Corporation
手順１：host3でtakeover hadrコマンドを実施
$ hostname
host3
$ db2 takeover hadr on db sample
DB20000I TAKEOVER HADR ON DATABASE コマンドが正常に完了しました。
25
© 2012 IBM Corporation
手順2： db2pdでロールが変更されていることを確認
$ hostname
host3
HADR_ROLE = PRIMARY
HADR_SYNCMODE = SUPERASYNC
$ db2pd –hadr –db sample
STANDBY_ID = 2
(以下抜粋して掲載。db2pdの詳細については後述。）
HADR_STATE = REMOTE_CATCHUP
Database Member 0 -- Database SAMPLE -- Active –
Up 0 days 04:12:28 – Date 2012-06-13 16:02:33
PRIMARY_MEMBER_HOST = host3
STANDBY_MEMBER_HOST = host1
HADR_CONNECT_STATUS = CONNECTED
HADR_ROLE = PRIMARY
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 1
HADR_STATE = PEER
PRIMARY_MEMBER_HOST = host3
STANDBY_MEMBER_HOST = host4
HADR_CONNECT_STATUS = CONNECTED
HADR_ROLE = PRIMARY
HADR_SYNCMODE = SUPERASYNC
STANDBY_ID = 3
HADR_STATE = REMOTE_CATCHUP
PRIMARY_MEMBER_HOST = host3
STANDBY_MEMBER_HOST = host2
HADR_CONNECT_STATUS = CONNECTED
26
© 2012 IBM Corporation
引継ぎ例2:Primary→Principalへ強制テークオーバー
• Primary→Principalへ強制テークオーバーする手順は以
下のとおり
• 手順１：host1でdb2syscをkill（インスタンス障害）
• 手順２：host2でtakeover hadr by forceコマンドを実施
• 手順３：db2pdでロールが変更されていることを確認
27
© 2012 IBM Corporation
引継ぎ例2
Localサイト
DRサイト
DBサーバ Primary(host1:hadr_p)
DBサーバ Aux1(host3:hadr_a1)
HADR_TARGET_LIST =host2:hadr_s|
host3:hadr_a1|host4:hadr_a2
HADR_TARGET_LIST= host4:hadr_a2|
host1:hadr_p|host2:hadr_s
①インスタン
スダウン
③Aux1
として稼動
②Primary
から
Principalに
強制TKO
③Aux2
として稼動
28
DBサーバ Principal(host2:hadr_s)
DBサーバ Aux2(host4:hadr_a2)
HADR_TARGET_LIST= host1:hadr_p|
host3:hadr_a1|host4:hadar_a2
HADR_TARGET_LIST= host3:hadr_a1|
host1:hadr_p|host2:hadr_s
© 2012 IBM Corporation
手順１：host1でdb2syscをkill
$ hostname
host1
$ ps -ef | grep $ ps -ef | grep db2sysc
db2inst1 13107338 16056502 0 10:53:34
- 0:09 db2sysc 0
db2inst1 16777396 16515236 0 13:06:17 pts/0 0:00 grep db2sysc
$ kill -9 13107338
29
© 2012 IBM Corporation
手順2：host2でtakeover hadr by forceコマンドを実施
$ hostname
host2
$ db2 takeover hadr on db sample by force
DB20000I TAKEOVER HADR ON DATABASE コマンドが正常に完了しました。
30
© 2012 IBM Corporation
手順3： db2pdでロールが変更されていることを確認
$ hostname
host2
HADR_ROLE = PRIMARY
HADR_SYNCMODE = SUPERASYNC
$ db2pd –hadr –db sample
STANDBY_ID = 2
(以下抜粋して掲載。db2pdの詳細については後述。）
HADR_STATE = REMOTE_CATCHUP
Database Member 0 -- Database SAMPLE -- Active –
PRIMARY_MEMBER_HOST = host2
Up 0 days 15:44:35 -- Date 2012-06-22 10:48:00
STANDBY_MEMBER_HOST = host3
HADR_CONNECT_STATUS = CONNECTED
HADR_ROLE = PRIMARY
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 1
HADR_STATE = DISCONNECTED
PRIMARY_MEMBER_HOST = host2
HADR_ROLE = PRIMARY
HADR_SYNCMODE = SUPERASYNC
STANDBY_ID = 3
HADR_STATE = REMOTE_CATCHUP
STANDBY_MEMBER_HOST = host1
PRIMARY_MEMBER_HOST = host2
HADR_CONNECT_STATUS = DISCONNECTED
STANDBY_MEMBER_HOST = host4
HADR_CONNECT_STATUS = CONNECTED
31
© 2012 IBM Corporation
V10.1 HADRのモニター
•DB2 V10.1では、HADRに関するモニターが強化されている
•モニター方法は以下の2種類提供されている（取得できる情報は同じ）
db2pd -hadr
• V9.7よりも出力される情報が増えている
• DBへの接続を必要としないため、プライマリ/主スタンバイ/補助スタンバイの全
てのサーバーで取得可能
• ただし、プライマリ上でしか、他のスタンバイの情報を取得することができない
MON_GET_HADR表関数
• V10.1からの新規表関数
• DBへの接続を必要とし、select文で取得できるため、出力の絞込みができる
• 読み取り専用スタンバイを使用しない場合は、スタンバイ側では取得できない
32
© 2012 IBM Corporation
db2pd –hadr
Database Member 0 -- Database SAMPLE -- Active -- Up 0 days 01:23:49 -- Date 201
2-06-13 15:10:35
• db2pd –hadr –db <dbname>
Primary - PStandby
• 取得コマンド・オプションはV9.7までと同様
• 出力形式と内容が大幅に変更された
• プライマリー
• 全スタンバイとプライマリの状況が表示される
Primary – AStandby1
• スタンバイ（プリンシパル・補助）
• db2pdを実行したスタンバイとプライマリとの状況のみ
出力される
Database Member 0 -- Database SAMPLE -- Active Standby -- Up 0 days 03:20:45 -Date 2012-06-13 15:10:36
HADR_ROLE = STANDBY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 0
LOG_STREAM_ID = 0
HADR_STATE = PEER
PRIMARY_MEMBER_HOST = host1
PRIMARY_INSTANCE = db2inst1
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = host2
STANDBY_INSTANCE = db2inst1
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 2012-06-13 13:46:49.048533 (1339562809)
HEARTBEAT_INTERVAL(seconds) = 2
HADR_TIMEOUT(seconds) = 10
TIME_SINCE_LAST_RECV(seconds) = 2
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000685
LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.010
LOG_HADR_WAIT_COUNT = 14
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 131400
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 65700
PRIMARY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
STANDBY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
HADR_LOG_GAP(bytes) = 0
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
STANDBY_RECV_REPLAY_GAP(bytes) = 0
PRIMARY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_REPLAY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_RECV_BUF_SIZE(pages) = 512
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 0
PEER_WINDOW(seconds) = 0
READS_ON_STANDBY_ENABLED = Y
STANDBY_REPLAY_ONLY_WINDOW_ACTIVE = N
（スタンバイ・ノードでdb2pd実行例）
33
Primary – AStandby2
HADR_ROLE = PRIMARY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 1
LOG_STREAM_ID = 0
HADR_STATE = PEER
PRIMARY_MEMBER_HOST = host1
PRIMARY_INSTANCE = db2inst1
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = host2
STANDBY_INSTANCE = db2inst1
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 2012-06-13 13:46:49.047726 (1339562809)
HEARTBEAT_INTERVAL(seconds) = 2
HADR_TIMEOUT(seconds) = 10
TIME_SINCE_LAST_RECV(seconds) = 2
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000685
LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.010
LOG_HADR_WAIT_COUNT = 14
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 131400
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 65700
PRIMARY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
STANDBY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
HADR_LOG_GAP(bytes) = 0
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
STANDBY_RECV_REPLAY_GAP(bytes) = 0
PRIMARY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_REPLAY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_RECV_BUF_SIZE(pages) = 512
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 0
PEER_WINDOW(seconds) = 0
READS_ON_STANDBY_ENABLED = Y
STANDBY_REPLAY_ONLY_WINDOW_ACTIVE = N
HADR_ROLE = PRIMARY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = SUPERASYNC
STANDBY_ID = 2
LOG_STREAM_ID = 0
HADR_STATE = REMOTE_CATCHUP
PRIMARY_MEMBER_HOST = host1
PRIMARY_INSTANCE = db2inst1
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = host3
STANDBY_INSTANCE = db2inst1
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 2012-06-13 13:46:47.847248 (1339562807)
HEARTBEAT_INTERVAL(seconds) = 2
HADR_TIMEOUT(seconds) = 10
TIME_SINCE_LAST_RECV(seconds) = 1
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000685
LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.010
LOG_HADR_WAIT_COUNT = 14
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 131400
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 65700
PRIMARY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
STANDBY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
HADR_LOG_GAP(bytes) = 0
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
STANDBY_RECV_REPLAY_GAP(bytes) = 0
PRIMARY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_REPLAY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_RECV_BUF_SIZE(pages) = 512
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 0
PEER_WINDOW(seconds) = 0
READS_ON_STANDBY_ENABLED = Y
STANDBY_REPLAY_ONLY_WINDOW_ACTIVE = N
HADR_ROLE = PRIMARY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = SUPERASYNC
STANDBY_ID = 3
LOG_STREAM_ID = 0
HADR_STATE = REMOTE_CATCHUP
PRIMARY_MEMBER_HOST = host1
PRIMARY_INSTANCE = db2inst1
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = host4
STANDBY_INSTANCE = db2inst1
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 2012-06-13 13:47:23.065051 (1339562843)
HEARTBEAT_INTERVAL(seconds) = 2
HADR_TIMEOUT(seconds) = 10
TIME_SINCE_LAST_RECV(seconds) = 2
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000685
LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.010
LOG_HADR_WAIT_COUNT = 14
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 131400
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 65700
PRIMARY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
STANDBY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
HADR_LOG_GAP(bytes) = 0
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000005.LOG, 13, 61194775
STANDBY_RECV_REPLAY_GAP(bytes) = 0
PRIMARY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_REPLAY_LOG_TIME = 2012-06-13 14:16:57.000000 (1339564617)
STANDBY_RECV_BUF_SIZE(pages) = 512
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 0
PEER_WINDOW(seconds) = 0
READS_ON_STANDBY_ENABLED = Y
STANDBY_REPLAY_ONLY_WINDOW_ACTIVE = N
（プライマリー・ノード上でのdb2pd実行例）
© 2012 IBM Corporation
（参考）V9.7以前のdb2pd –hadr出力例
34
© 2012 IBM Corporation
DB2 V10.1でのdb2pd –hadr（出力例1/2)
（補助スタンバイで取得したdb2pdの出力例）
補助スタンバイなので、モード
はSUPERASYNC
SUPERASYNCモードの
場合ステータスは常に
REMOTE_CATCHUP
35
© 2012 IBM Corporation
DB2 V10.1でのdb2pd –hadr（出力例2/2)
• スタンバイ側でのログ受信やログ適用に関する詳細な情報が得られ
るようになった
• （例）
• STANDBY_REPLAY_LOG_FILE,PAGE,POS（スタンバイ側での適用ログの位置情報）
• STANDBY_RECV_REPLAY_GAP（スタンバイ側で受信したログと適用したログの差分情
報）
• PRIMARY_LOG_TIME（プライマリ側での最新のトランザクションタイムスタンプ）
• STANDBY_LOG_TIME（スタンバイ側で受信した最新のトランザクションタイムスタンプ）
• STANDBY_REPLAY_LOG_TIME(スタンバイ側で適用された最新のトランザクションタイ
ムスタンプ)
（補助スタンバイで取得したdb2pdの出力例：抜粋）
36
© 2012 IBM Corporation
MON_GET_HADR表関数の出力例
SELECT HADR_ROLE, STANDBY_ID, HADR_SYNCMODE,HADR_STATE,
PRIMARY_LOG_TIME,STANDBY_LOG_TIME,STANDBY_REPLAY_LOG_TIME,STANDBY_REPLAY_DELAY,STANDBY_RECV_BUF_PER
CENT,varchar(PRIMARY_MEMBER_HOST ,20) as PRIMARY_MEMBER_HOST, varchar(STANDBY_MEMBER_HOST ,20) as
STANDBY_MEMBER_HOST from table(MON_GET_HADR(NULL))
HADR_ROLE STANDBY_ID HADR_SYNCMODE HADR_STATE
PRIMARY_LOG_TIME
STANDBY_LOG_TIME
STANDBY_REPLAY_LOG_TIME STANDBY_REPLAY_DELAY STANDBY_RECV_BUF_PERCENT PRIMARY_MEMBER_HOST
STANDBY_MEMBER_HOST
------------- ---------- ------------- ----------------------- -------------------------- -------------------------- -------------------------- -------------------- ----------------------- -------------------- -------------------PRIMARY
15.31.57.000000
1 NEARSYNC
PEER
2012-06-13-15.31.57.000000 2012-06-13-15.31.57.000000 2012-06-130 +0.00000000000000E+000 host2
host1
PRIMARY
15.31.57.000000
2 SUPERASYNC REMOTE_CATCHUP
0 +0.00000000000000E+000 host2
2012-06-13-15.31.57.000000 2012-06-13-15.31.57.000000 2012-06-13host3
PRIMARY
15.31.57.000000
3 SUPERASYNC REMOTE_CATCHUP
0 +0.00000000000000E+000 host2
2012-06-13-15.31.57.000000 2012-06-13-15.31.57.000000 2012-06-13host4
3 レコードが選択されました。
37
© 2012 IBM Corporation
ログ・スプーリング
• ログ・スプーリングの機能を有効にすると、プライマリから転送されたログをスタンバ
イ側に蓄積する
• スタンバイにおけるReplayが遅延し、ログ受信バッファーが満杯になった場合にログをディスクに
蓄積する
• HADR_SPOOL_LIMIT DB構成パラメーターにログ受信バッファーが満杯になった場合に、ディ
スクに書き込まれる上限を指定（４Kページ単位）
• スタンバイのログのReplay状況とプライマリからのログ受信状況を切り離すことが
可能
• どの同期モードでも使用可能
Primary
Standby
超非同期
スタンバイで
ログをスプール
38
38
© 2012 IBM Corporation
ログ・スプーリングと超非同期のどちらを選択する?
• ログ・スプーリング
• スタンバイのReplay状況に関わらずログを受信可能
• プライマリー側で処理が一時的に高負荷状態になりスタンバイ側の処理が遅延
するときの影響を軽減可能
• どの同期モードでも選択可能
• 超非同期
• プライマリへの影響を全同期モードの中で最も軽微にするモード
• N/Wが遅延している場合に特に有効
• 両方を使用することも可能
• N/Wとスタンバイサーバーの両方のパフォーマンスが悪い場合
• HADR遅延再生を使用する場合
39
39
© 2012 IBM Corporation
HADR遅延再生
• HADR_REPLAY_DELAY DB構成パラメーターが提供された
• Log_spoolingが前提
• スタンバイにログが反映されるまでの時間を指定する
• 0の値はtime delayが行われないことを意味する（デフォルトの設定）
• 超非同期を使用したスタンバイのみ有効
• マルチスタンバイの場合複数スタンバイ毎に遅延時間を変えることも可能
• 論理障害からの回復に役立つ
• 重要な業務データを削除してしまったような場合に、回復可能になる
• 指定した期間以内（スタンバイに誤操作が伝播される前）にエラーを発見し、HADRを停止し、ス
タンバイDBを、障害発生前の時点までPoint in timeでRollforwardし回復させることが可能
Standby
Primary
超非同期
スタンバイで
ログをスプール
40
© 2012 IBM Corporation
HADR機能拡張のまとめ
• HADRで複数スタンバイをサポート
• ローカルHA構成と、災対構成の両方をHADRで実現可能
• 超非同期モードで補助スタンバイと連携することでトランザクションへの影響を軽
微にする
• Log Spooling機能の提供
• スタンバイ側のReplay処理が遅延している場合の影響を軽減することが出
来る
• トランザクションが急激に増えた場合などに有効
• HADR遅延再生
• データ誤削除などをスタンバイに指定期間、伝播させないことが可能
• 論理障害発生時の復旧時間が早くなるケースがある
41
© 2012 IBM Corporation
レプリケーション機能強化
42
© 2012 IBM Corporation
拡大するレプリケーションの活用法
情報系システム構築
DB2マイグレーションのデータ移
行
43
異なる業務間でのデータ連携
災対システム
© 2012 IBM Corporation
内容
• IBM InfoSphere Data Replication V10.1.3 新機能
• DDLサポート
製品パッケージの名前
• Qキャプチャー停止ポイントの制御の強化
が変わりました。
• トリガーによるコンフリクト抑止
• LOBデータに関するパフォーマンス向上
• 異なるバージョン間の組合せ
• Qレプリケーション
• SQLレプリケーション
• 制約事項
44
© 2012 IBM Corporation
DDLサポートとは？
•
V10よりDDLをログに書き出しQキャプチャーがDDLを送信する
• CREATE TABLE / DROP TABLE
• ALTER TABLE （ADD COLUMN / ALTER COLUMN SET DATA TYPE)
•
DDL ステートメントのロギング
•
デフォルトでは設定は
NOになっている
(LOG_DDL_STMTS) = YES が必要
$ db2 get db cfg|grep DDL
DDL ステートメントのロギング
(LOG_DDL_STMTS) = NO
DB2 ログ
DB
CREATE
DROP
Ｔ１
ALTER
Log Read API
SQLCapture
QCapture
サポート
されませ
ん
45
© 2012 IBM Corporation
Qレプリケーション定義の自動化
例えば、T000、T001、T002、T003・・・
T499のように500表をサイトBにレプリ
ケーションしたい場合、
サイトA
500表、それぞれ定義が必要になる。
基本的には定義→ACTIVATEを行う。
サイトB
T○○○
T○○○
T○○○
T○○○
T○○○
T○○○
T○○○
T○○○
T○○○
T○○○
※ACTIVATEは、その表のレプリケー
ションをONにする操作。
V9.7まで
①
サイトAにT500を追加(CREATE TABLE)
V10.1新機能
①
「T」から始まる表名は全てレプリケーションされる
ように事前に設定
②
サイトAにT500を追加(CREATE TABLE)
②
T500をレプリケーション定義(自動でサイトB
にT500をCREATEすることは可能)
③
T500をACTIVATE
④
サイトAにT501を追加(CREATE TABLE)
(自動でQレプリケーション定義。その後T500に更
新があると、自動でACTIVATE)
(以降同様)
(以降同様)
46
(自動でQレプリケーション定義。その後T500に更
新があると、自動でACTIVATE)
③
サイトAにT501を追加(CREATE TABLE)
© 2012 IBM Corporation
DDLをレプリケーションするための設定
•
CREATE TABLE / DROP TABLEの場合
• スキーマ・レベルのサブスクリプションを作成しておく
• CREATE SCHEMASUBコマンド
• ASNCLPのみサポート(RCは未サポートです）
• スキーマサブに登録された表がCREATEされると、サブスクリプション・プ
ロファイルをもとにレプリケーション・ソース表として登録される
•
ALTER TABLEの場合
• ADD COLUMNは２つの方法があります
• ADDCOLシグナルを使用 (V8からの機能)
• REPL_ADDCOL設定値 (V10新機能)
• 上記のいずれかをしない場合は列追加はターゲットへは反映されません。
• ALTER COLUMN SET DATA TYPE
• 必要な設定はありません。V10以上でソース表が変更されるとターゲットへレ
プリケーションされます。
• ただし、ターゲットがV10より低いバージョンの場合はＱサブスクリプションが
Diactivateされます
• ターゲット表のREORGはQアプライが実施します
47
© 2012 IBM Corporation
参考) DDLをレプリケーションするためには （内部のしくみ）
•
キャプチャーは、変更されたソース表の履歴情報を常に保持しているため、さまざまな
バージョンのソース表のログを読むことが出来ます。
•
このために、新しい制御表を使っています
•
•
•
•
IBMQREP_TABVERSION表
IBMQREP_COLVERSION表
Qサブスクリプションが活動化された後、ソース表が変更されるたびに上記の表に
行が挿入されます
これらの制御表はSQLレプリケーションでも使用されています。
<< ソース表の定義変更時の注意点!! >>
•
•
TABVERSION、COLVERSION表には表名ではなくTABLEID(SYSIBM.SYSTABLESのオブジェク
トID)が格納されています。TABLEIDはDROP/CREATEにより変更される可能性があるため、定義
変更をDROP/CREATEで実施している場合は、始めにCAPSTOPでQサブスクリプションを非活動
化し、定義変更後、CAPSTARTで活動化して下さい。活動化された時点で
TABVERSION/COLVERSINOの既存の行は削除され、新しい情報が挿入されます。
上記は、SQLレプリケーションにおいても同じです。DROP/CREATEの前にCAPSTOPにより変更
収集を停止し、定義変更完了後にフルリフレッシュ、または手動フルリフレッシュにてレプリケーション
を開始してください。
•
•
また、定義変更に関してテクニカルフラッシュが発行されています。（z/OS環境における問題)
「【障害情報】DB2 for z/OS V9 または V10をソースとして、Qレプリケーション、またはSQLレプリ
ケーションを利用する場合は、いくつかの条件においてIIDR (旧IRS) V10 APAR PM63905以上が
必須となります」
•
http://w3-06.ibm.com/jp/domino02/ise/ISEINFO.NSF/99a7d1be5103176a492563ef002002e5/51e9b533fc493ede49257a4500255f86?OpenDocument
48
© 2012 IBM Corporation
参考：サブスクリプションプロファイルとスキーマサブのサンプル
CREATE SUBSCRIPTION OPTIONS unioptions1
SUBTYPE U
HAS LOAD PHASE I
CAPTURE_LOAD W
SPILL_MODELQ "IBMQREP.SPILL.MODELQ"
SUPPRESS DELETES N
IBMQREP_SUBS_PROF
REPLICATE ADD COLUMN Y
IGNORE TRIGGERS CASCADE DELETES SET NULL
CONFLICT ACTION Q
ERROR ACTION S
OWNER LIKE / NAME LIKE で指定する
OKSQLSTATES sqlstate
さらに、EXCLUDE OWNER /EXCLUDE NAME で特
定の表を除外することもできます。
LOAD TYPE 5
EXIST DATA APPEND;
CREATE SCHEMASUB schemasub_uni1
SUBTYPE U REPLQMAP qmap1
FOR TABLES NAME LIKE "A%“
IBMQREP_SCHEMASUBS
OPTIONS unioptions1;
※注 ASNCLPのみのサポートです。レプリケーション・センターはサポートされていません。
49
© 2012 IBM Corporation
参考：Ｑキャプチャー起動時のログ
2012-04-20-16.15.47.953000 <subMgr::handleSTARTSCHEMASUB> ASN7247I "Q Capture" :
"ASN" : "WorkerThread" : Q キャプチャー・プログラムは、スキーマ・レベルの Q サブスクリ
プション "SCSUB1" とそれに対応するプロファイルを正常にロードしました。 Q サブスクリプ
ションはレプリケーション・キュー・マップ "QMAP1" を使用し、Q サブスクリプションが "A%"
オブジェクトのスキーマ "%" で自動的に作成されるように指定します。
2012-04-20-16.15.48.609000 <subMgr:initAllSubs> ASN7000I "Q Capture" : "ASN" :
"WorkerThread" : "1" サブスクリプションがアクティブです。 "0" サブスクリプションは非ア
クティブです。新しい "0" サブスクリプションは、正常に活動化されました。新しい "0" サブ
スクリプションは、活動化できず非アクティブになっています。
2012-04-20-16.15.48.625000 <asnqwk> ASN0572I "Q Capture" : "ASN" : "WorkerThread" :
"mqpub 10.1.0 (Level s120403, PTF NT32101), DB2 v10.1.0" プログラムは正常に初期化されま
した。
50
© 2012 IBM Corporation
参考： DDL自動検知確認
CREATE TABLE A1 (C1 INT NOT NULL PRIMARY KEY, C2 INT)
DATA CAPTURE CHANGES
DATA CAPTURE CHANGES属性をつけることを忘れない
でください。
DATA CAPTURE CHANGES属性を忘れると、CREATE
TABLEはレプリケーションされません。
2012-04-20-16.36.57.375000 <subMgr::publishDDL> ASN7210I "Q Capture" : "ASN" :
"WorkerThread" : スキーマ・レベルの Q サブスクリプション "SCSUB1" に対応する Q サブス
クリプション "A10001" が、送信キュー "Q1" およびレプリケーション・キュー・マップ
"QMAP1" を使用するソース表 "AA327361.A1" に、正常に作成されました。
51
© 2012 IBM Corporation
参考：メッセージの確認
**** Message number: 4
**** Message size:
1128
qMsgHeader.msgFamily: QREP
qMsgHeader.msgtype:
ASNMQ_CREATESUB_MSG
qMsgHeader.msgVersion: ASNMQ_VERSION700
subName: A10001
subId: 2
srcDbName: QSRC1
srcOwner: AA327361
srcName: A1
targetType: 1
subType: U
conflictRule: K
conflictAction: F
errorAction: S
subOkSqlStates:
subGroup:
initiatorNode: 0
sourceNode: 0
targetNode: 0
hasLoadPhase: I
loadType: 0
modelQ: IBMQREP.SPILL.MODELQ
schemaSubName: SCSUB1
originated from: CREATE TABLE DDL
52
**** Message number: 5
**** Message size:
1270
qMsgHeader.msgFamily:
QREP
qMsgHeader.msgtype:
ASNMQ_DDL_MSG
qMsgHeader.msgVersion: ASNMQ_VERSION700
qMsgHeader.msgDDLType:
ASNMQ_DDL_GENERIC
Default Schema:
'AA327361'
Owner Name:
'AA327361'
Function path:
'"SYSIBM","SYSFUN","SYSPROC","SYSIBMADM","AA327361"'
subId:
2
objectType:
0
objectSchema:
AA327361
objectName:
A1
SQL codepage:
1208
SQL Text Length:
54
SQL Text:
"create table a1 (c1 int not null
primary key, c2 int) "
DDL
© 2012 IBM Corporation
参考：最初のDMLが発行されるとQサブスクリプションがACTIVATEされる
ソース表へ更新が発生すると、Qサブスクリプションは活動かされます。
例）INSERT INTO A1 VALUES(1,1)
Qキャプチャー実行ログ
2012-04-20-16.47.02.531000 ASN7010I "Q Capture" : "ASN" : "WorkerThread" : プログラムは、
ソース表 "AA327361.A1" の発行または Q サブスクリプション "A10001" (送信キュー "Q1"、発行また
はレプリケーション・キュー・マップ "QMAP1") を正常に活動化しました。
Qアプライ実行ログ
2012-04-20-16.47.02.562000 ASN8999D Browser for queue 'Q1' received a 'ASNMQ_SUBSCHEMA_MSG'
message.
2012-04-20-16.47.02.718000 ASN7606I "Q Apply" : "ASN" : "BR00000" : Q サブスクリプション
"A10001" (受信キュー "Q1"、レプリケーション・キュー・マップ "QMAP1") がアクティブです。
53
© 2012 IBM Corporation
Qキャプチャー停止ポイントの制御の強化
• ターゲットDBで静止点を確保するための機能
• ある時点までの変更が全てターゲットで適用されたこと
(または伝送キューから除去されたこと) をQキャプチャー
に知らせ停止することができるようになった
STOP SIGNAL
Q
Capture
STOP SIGNALを処理
Q
Apply
最後までデータを反映したら教えてください
データを全て反映
全て反映しました
Qキャプチャー停止
54
© 2012 IBM Corporation
Qキャプチャー停止ポイントの制御の強化
• Qキャプチャー・コマンド(asnqccmd)およびSIGNALで本機能を提供
• DATA_APPLIED ・・・ データがターゲットに反映されれば
• DATA_SENT
・・・ データが伝送キューから除去されれば
>>-asnqccmd--capture_server=db_name----+-----------------------+->
'-capture_schema=schema-'
asnqccmdコマン
ドのsyntax
>+-stopq=+-qname-+-----+--------------------------------------+-->
|
'--ALL--' | |
|
|
| '-captureupto=-+-'timestamp string'-+--'
'-stop-------------'
+-current_timestamp--+
'-eol----------------'
>----------------------+-------------------------+---------------><
|
|
'-after=+-data_applied-+--'
'-data_sent—---'
INSERT INTO ASN.IBMQREP_SIGNAL(
SIGNALの例
SIGNAL_TIME, SIGNAL_TYPE, SIGNAL_SUBTYPE, SIGNAL_INPUT_IN, SIGNAL_STATE) VALUES(
CURRENT TIMESTAMP, 'CMD', 'STOPQ', 'Q1;CURRENT_TIMESTAMP;DATA_APPLIED', 'P')
55
© 2012 IBM Corporation
参考）実行ログのサンプル
• 前ページのSIGNALを実行した例
SIGNAL実行時のQキャプチャーの実行ログ
2012-04-06-12.21.31.781000 ASN7178I "Q Capture" : "ASN" : "WorkerThread" : すべての送信キューが非ア
クティブ (I) 状態にあります。STARTQ コマンドを使用して、非アクティブなキュー上でのレプリケーションま
たはパブリッシングを再開することができます。
2012-04-06-12.21.31.781000 ASN7223I "Q Capture" : "ASN" : "WorkerThread" : stopafter オプションを使
用した stop または stopq コマンドに応じて、プログラムは、送信キュー "Q1" にパブリッシュされるすべて
のトランザクションがターゲットで適用されるのを待ちます。
データが全て反映されたことを知らせるQアプライの実行ログ
2012-04-06-12.31.29.390000 ASN7224I “Q Apply” : “ASN” : “BR00000” : 受信キュー “Q1” (レプリ
ケーション・キュー・マップ “QMAP1”) の Q アプライ・ブラウザー・スレッドは、送信キュー “Q1” にパ
ブリッシュされた、コミット・シーケンス番号 “0000:0000:0000:2f68:0000:0000:0006:b2ba”、コミット・タ
イム・スタンプ “2012-04-06-12.21.31.000001” までのすべてのトランザクションが適用されたことを Q
キャプチャー・プログラムに通知しました。ブラウザー・スレッドはメッセージの処理を継続します。
Qアプライからの通知を受け取ったことを知らせるQキャプチャーの実行ログ
2012-04-06-12.31.30.062000 ASN7227I "Q Capture" : "ASN" : "WorkerThread" : 送信キュー "Q1" (レプリ
ケーション・キュー・マップ "QMAP1") にパブリッシュされたすべてのトランザクションがターゲットで適用さ
れました。
56
© 2012 IBM Corporation
ターゲットDBで静止点が必要な理由
•
異なる業務のデータベース間をQレプリケーションで連携
• 生産管理側は、24時間稼働している
• 受注管理側は、ある時点のデータを元にバッチ処理を行う
厳密に言えば、例えば受発注管理側は、生産管理側で21時までの更新データのみが必要な場合、
・データ連携は21時までの更新データを処理して停止しなければいけない(21時1分の更新データを
処理してはいけない)
・受発注管理側では、停止した時点までの全てのデータが反映されてから、バッチを開始しなければ
いけない
受発注管理
生産管理
Qレプリケーションに
よるデータ連携
Q Capture
57
agent
agent
agent
Q Apply
© 2012 IBM Corporation
参考）これまでの静止点確保の方法
• データ連携停止は、「SIGNAL」で停止することで厳密なポイントで停止が可能
• SIGNALは更新ログに書かれ、それをQキャプチャーが処理する仕組み。そのためある業務処理
完了後に停止SIGNALを発行すれば、その業務処理全てをQキャプチャーが処理したことを保証
して停止できる
SIGNAL表の更新
DB2 LOG
アプリケーションからの更新
内容：STOP
Q Capture
MQPUT
Q Capture
停止
「SIGNAL」までの更新を全てQキャプチャーが処理したことは保証できるが、それが全てターゲット側に反映され
たかどうかはどのように保証するか？
方法：
・ダミーの表をレプリケーションさせる
・SIGNAL表への更新と同じトランザクションでダミー表を更新
・ダミー表への更新がターゲット側に反映されていることを確認
・IBMQREP_APPLYMON表のOLDEST_TRANS列の値から、ダミー表を更新した時間までがターゲット側に反映されたことを
確認。(Qアプライは通常並列で処理するため、ダミー表の更新のみでは追い越しが発生している可能性があるため)
58
© 2012 IBM Corporation
レプリケーションにおけるトリガー処理 (V9.7まで)
• DB2 V9.7までは、レプリケーション対象表にトリガーが存在するとデータのコ
ンフリクトが発生していた
• ターゲット側のトリガーを外すなどの考慮が必要
SERVER 2
SERVER 1
UPDATES
DB2
TABLE 1
DB2
TABLE 2
TRIGGER
database
recovery
log
TABLE 1_cp
Q Replication
Capture
TABLE 2_cp
TRIGGER
Apply
コンフリクト!
DB2 V9.7では、レプリケーション対象表にトリガーオブジェクトがある場合は、ソース、ターゲット
で同じ構成をとることができなかった
59
© 2012 IBM Corporation
レプリケーションにおけるトリガー処理 (V10新機能)
• DB2 V10.1からは、レプリケーション対象表にトリガーが存在していても、データの
コンフリクトは発生しない
• キャプチャーパラメータまたはIBMQREP_SUBS表でIGNTRIGをYに設定する
SERVER 1
UPDATES
DB2
TABLE 1
TABLE 2
TRIGGER
database
recovery
log
IGNTRIG=Yに設定する
ことで、TABLE2の更新
はキャプチャーしない
SERVER 2
DB2
TABLE 1_cp
Q Replication
Capture
TABLE 2_cp
TRIGGER
Apply
データのコンフリクト
は発生しない
DB2 V10.1では、ターゲット側でトリガーを外すなどの考慮は必要なく、ソースとターゲットは同
じ構成をとることが可能
60
© 2012 IBM Corporation
設定方法
• IGNTRIGを設定する方法は2種類ある
方法１）Qサブスクリプション単位に指定
CREATE QSUB USING REPLQMAP QMAP1(
SUBNAME QSUB2 TABLE2
OPTIONS HAS LOAD PHASE I SUPPRESS DELETES N START AUTOMATICALLY NO
IGNORE TRIGGERS
EXIST TARGET NAME TABLE2
CONFLICT ACTION F ERROR ACTION S LOAD TYPE 0);
方法２）QキャプチャーのパラメーターでIGNTRIG=Yを設定（Qキャプチャー単位）
asnqcap capture_server=galidb1 capture_schema=asn IGNTRIG=Y logstdout=Y
• パラメータ設定確認（ IBMQREP_SUBS表を更新した場合）
db2“select substr(SUBNAME,1,20) as SUBNAME,STATE,IGNTRIG,IGNCASDEL,IGNSETNULL from
ASN.IBMQREP_SUBS”
SUBNAME
STATE IGNTRIG IGNCASDEL IGNSETNULL
-------------------- ----- ------- --------- ---------TAB1SUB001
A
N
N
N
QSUB2
A
Y
N
N
2 レコードが選択されました。
61
© 2012 IBM Corporation
参考）IGNTRIG=Y
Qキャプチャーの設定とQサブスクリプションの設定のどちらが有効か？
Qサブスクリプション設定で
IGNTRIG 'N'
Qサブスクリプション設定で
IGNTRIG ‘Y'
Qキャプチャーの設定で
Qキャプチャーの設定で
IGNTRIG
IGNTRIG 'Y'
'N'
トリガーによって更新されたデー
タは
トリガーによって更新されたデー
タは
レプリケーションされます
レプリケーションされません
トリガーによって更新されたデー
タは
トリガーによって更新されたデー
タは
レプリケーションされません
レプリケーションされません
コマンドラインからIGNTRIG=Nを指定しても、サブスクリプションで指定しているIGNTRIG=Yは上書きされない
62
© 2012 IBM Corporation
参考） 実行例(1/2):
ソース環境
ターゲット環境
サブスクリプション定義
表：TABLE1
表：TABLE1_cp
TAB1SUB001(TABLE1→TABLE1_cp)
表：TABLE2
表：TABLE2_cp
TAB2SUB001(TABLE2→TABLE2_cp)
トリガー*
トリガー*
*TABLE1、TABLE1_cpに更新が入るとTABLE2、TABLE2_cpのある列をupdateするトリガーを作成
Files¥IBM¥SQLLIB¥BIN>db2 “update ASN.IBMQREP_SUBS
•C:¥Program
IGNTRIGを設定する方法は3種類ある
•
set IGNTRIG='Y' where subname=‘TAB2SUB001’”
IBMQREP_SUBS表を更新するIGNTRIG=Yを設定（サブスクリプション単位）
C:¥Program Files¥IBM¥SQLLIB¥BIN>asnqcap capture_server=galidb1 capture_schema=asn IGNTRIG=Y logstdout=Y
CREATE
QSUB USING REPLQMAP GALIDB1_ASN_TO_GALIDB2_ASN
• キャプチャーパラメータでIGNTRIG=Yを設定（キャプチャー単位）
(SUBNAME TAB2SUB001 TABLE2
OPTIONS
HAS LOAD PHASE I
IGNORE
TRIGGERS
• asnclpのサブスクリプション定義に設定
（サブスクリプション単位）
TARGET NAME TABLE2_cp);
63
© 2012 IBM Corporation
参考） 実行例(2/2):
• パラメータ設定確認（ IBMQREP_SUBS表を更新、サブスクリプションで設定した場合の確認方法）
C:¥Program Files¥IBM¥SQLLIB¥BIN>db2 “select substr(SUBNAME,1,20) as SUBNAME,STATE,IGNTRIG,IGNCASDEL,IGNSETNULL from ASN.IBMQREP_SUBS”
SUBNAME
STATE IGNTRIG IGNCASDEL IGNSETNULL
-------------------- ----- ------- --------- ---------TAB1SUB001
A
N
N
N
TAB2SUB001
A
Y
N
N
2 レコードが選択されました。
• IGNTRIG=N(デフォルト)に設定した場合
•
コンフリクトが発生し、EXCEPTION表に書かれます
C:¥Program Files¥IBM¥SQLLIB¥BIN>db2 "select EXCEPTION_TIME,substr(RECVQ,1,20) as RECVQ,substr(SUBNAME,1,20) as SUBNAME,REASON,substr(TEXT,1,100) as
TEXT from ASN.IBMQREP_EXCEPTIONS
EXCEPTION_TIME
RECVQ
SUBNAME
REASON
TEXT
-------------------------- -------------------- -------------------- ------------ -------------------------------------------------2012-04-19-17.40.22.484000 Q1
64
TAB2SUB001
DUPLICATE
UPDATE "AHA03926"."TABLE2_cp" SET "COUNT" = 1 WHERE "COUNT" = 0
© 2012 IBM Corporation
LOBデータに関するパフォーマンス向上
• Qキャプチャーはリカバリー・ログからLOB データを直接読み
取るようになりました
• LOBデータがログに書かれていれば、Qキャプチャーが自動的に読み取ります
• DB2 V10.1にて新しくdiagnostic logが書かれるようになり、 InlineでないLOBの
ログも読取り可能となりました
※IRS for z/OS V10は、DB2 10 for z/OS 以降でサポートされるInlineのLOBのログからの読
取りが可能となった。
65
© 2012 IBM Corporation
従来のLOBレプリケーション
Qレプリケーションでは、V9.7 FP2からInline LOBのレプリケーションが可能
 DB2でのLOBデータのロギング
• INLINE LENGTHの長さの範囲内の場合
row
行ログ
LOB
LOBログ
V9.7～
Read OK
• INLINEの指定がない、またはINLINE LENGTHの長さより長い場合
（LOBがログに書かれるかは、LOGGEDオプションに依存、XMLは常に書かれる）
row
追加 LOBログ
LOB
QCAP
V9.7
行ログ
INLINE LENGTHで指定した長さ
Read NG
ロケータ
 QCAP V9.7 FP2でReadが可能になったのは、行ログ内のLOBログ
 追加LOBログやログがない場合は、直接ソース表をreadして更新データを取得
LOBデータがInlineの長さの範囲内
Inline指定なし、またはLOBデータ
がInlineの中さの範囲外
Logged
行ログ内
追加LOBログ
Not Logged
行ログ内
ログされない
ログからread可能
66
ログからreadできないのでソース表を照会
© 2012 IBM Corporation
LOBレプリケーションと新機能誕生の背景
LOBデータを取得する元は、Qキャプチャーのパラメータの
LOB_SEND_OPTIONによっても異なる
• LOB_SEND_OPTIONと関係（V9.7(FP2~)の場合）
Inline範囲内
Not Inline/Inline範囲外
LOB_SEND_OPTION
Logged
Not logged
Logged
Not logged
I
行ログ
行ログ
ソース表
ソース表
S
ソース表
ソース表
ソース表
ソース表
• LOB_SEND_OPTION=I の場合（LOBデータはトランザクションメッセージに含まれる）
• ログから取得できる場合はログから、できない場合はソース表からLOBデータを取得
• LOB_SEND_OPTION=Sの場合 (LOBデータは、トランザクションメッセージとは別のLOB専用メッセージ
になる）
• 常にソース表からLOBデータを取得

DB2 V10.1では、Qcapがソース表へアクセスしないようにしてほしいという
リクワイアメントがあがった
67
© 2012 IBM Corporation
V10.1での拡張機能
• V10.1のQCAPで、追加LOBログのReadができるようになった
行ログ
V9.7～ Read OK
LOBログ
QCAP
追加 LOBログ
行ログ
ロケータ
V9.7 Read NG
V10.1 Read OK!
• LOB_SEND_OPTIONと関係（V10.1の場合）
Inline範囲内
Not Inline/Inline範囲外
LOB_SEND_OPTION
Logged
Not logged
Logged
Not logged
I
行ログ
行ログ
追加LOBログ
ソース表
S
行ログ
行ログ
追加LOBログ
ソース表
• LOB_SEND_OPTION=I 、S 両方共通
• ログがない場合を除き、ログから取得する
LOBデータ更新データの取得時のパフォーマンスが向上！
データベースへの接続不要！
68
© 2012 IBM Corporation
考慮事項
• LOBをログから読ませるためには、LOB_SEND_OPTIONは「I」でも「S」でもよいが、LOB
はLOGGEDオプションが指定されていなければならない
• NOT LOGGEDを指定してはいけない
•
•
CREATE TABLE時のデフォルトはLOGGED
NOT LOGGED/LOGGEDの属性は、後からALTERで変更できない
• IN LINE LOBなのにLOB_SEND_OPTIONがSだと、INLINEからLOB部分を取り出すため
に、Qキャプチャーは追加のメモリーが必要になるので、MAX_MESSAGE_SIZE内に収まる
のであれば、敢えてLOB_SEND_OPTIONをSにすることは非推奨
• Event PublisherのXMLメッセージの場合は、V10.1での拡張はなし。
• よって LOB_SEND_OPTIONは「I」でなければログから読めない
• LOB_SEND_OPTIONが「S」の場合は、ソース表から読む
• DB2 V10.1より、XMLのログもLOBと同様にdiagnostic logが書かれるようになったが、Q
レプリケーションとしては、V10.1での拡張はなし。
• XMLは常にログに書かれるが、内部フォーマットになっているため、INLINEであっても、Q
キャプチャーはログから読めない
• LOB_SEND_OPTIONがIでもSでもソース表から読む
69
© 2012 IBM Corporation
Qレプリケーション バージョン間のサポート状況 (LUW)
Qキャプチャー
10.1
Qアプライ
10.1
Qキャプチャー
9.7
9.7
Qアプライ
10.1
9.7
9.5
※注 V10 Qキャプチャーは、V9.1、V9.5のQア
プライへはレプリケーションできません。
9.1
Qキャプチャー
9.5
70
Qアプライ
10.1
Qキャプチャー
9.1
Qアプライ
10.1
9.7
9.7
9.5
9.5
9.1
9.1
© 2012 IBM Corporation
下位レベルへのレプリケーションはCompatibilityを設定
Qキャプチャー
10.1
Qアプライ
10.1
Qキャプチャー
9.7
9.7
Qアプライ
10.1
9.7
9.5
は、Qアプライに対してQキャプチャーのレベルの方が高いため、Qキャプチャー
のCompatibilityをQアプライのレベルに合わせて動かす必要があります。ただし、
使用できる機能は低いレベルに依存します。
Qキャプチャー
9.5
71
Qアプライ
10.1
Qキャプチャー
9.1
9.1
Qアプライ
10.1
9.7
9.7
9.5
9.5
9.1
9.1
© 2012 IBM Corporation
参考）COMPATIBILITYの設定（IBMQREP_CAPPARMS表）
Qキャプチャー
10.1
Qアプライ
10.1
9.7
COMPATIBILITYはQキャプチャのバージョンがQアプライに対して高い場合に考慮する設定で
す。
レベルが低いQアプライは、高いレベルのMQメッセージを理解することができないため、Q
キャプチャがQアプライのレベルに合わせてMQのメッセージを生成する必要があります。
このMQのメッセージレベルを設定するのが、COMPATIBLITYになります。
例）QキャプチャーがV10、QアプライがV9.7の場合
UPDATE Qｷｬﾌﾟﾁｬｰｽｷｰﾏ.IBMQREP_CAPPARMS
SET COMPATIBILITY=„0907‟
※これによりV10のQキャプチャーであってもV10の新機能は使用できなくなります。
72
© 2012 IBM Corporation
Qキャプチャー V10.1 for z/OSとの組合せ
• IRS 10.1 for z/OS のQキャプチャがサポートするQアプライのバージョンは以下の通りです。
Qキャプチャー
10.1
(z/OS)
Qアプライ
10.1(LUW)
10.1(z/OS)
9.7
V10 Qキャプチャー for z/OSは、
0901/0905のCompatilityをサポートし
ています。
9.5
9.1
は、Qアプライに対してQキャプチャーのレベルの方が高いため、Qキャプチャー
のCompatibilityをQアプライのレベルに合わせて動かす必要があります。ただし、
使用できる機能は低いレベルに依存します。
73
© 2012 IBM Corporation
参考） Qキャプチャー V10.1 for z/OSとの組合せ
ALTER COLUMN SET DATA TYPEに関する注意点

Qキャプチャーfor z/OSで、ソース表に対してALTER TABLE のALTER COLUMN SET DATA TYPEを実施している
場合、Qアプライのバージョンによって振る舞いが変わりますのでご注意ください。
通常QキャプチャーはALTER COLUMN SET DATA TYPEをログから読むとQアプライに対してALTERメッセージと
SCHEMAメッセージを送信します。しかし、V10より低いレベルのQアプライはALTERメッセージを理解できませ
ん。

V10 Qアプライの場合 (compatibility =‘0907’)
ALTER メッセージとSCHEMAメッセージがQアプライへ送信されターゲット表へ適用される。

V9.7 FP6以上 Qアプライの場合 (compatibility =‘0907’)
ALTER メッセージとSCHEMAメッセージがQアプライへ送信されるが、QアプライはALTERメッセージを
無視する。
事前にターゲット表もALTERしておくことでSCHEMAメッセージを正常に処理する

V9.7 FP5以下 Qアプライの場合 (compatibility =‘0907’)
ALTER メッセージとSCHEMAメッセージがQアプライへ送信されるが、QアプライはALTERメッセージを
受け取り
エラーとなりQサブスクリプションがDiactivateされる。V9.7の場合は、FP6以上が推奨です。

Ｖ9.5 Qアプライの場合 (compatibility =‘0905’)
SCHEMAメッセージのみがQアプライへ送信される。
事前にターゲット表もALTERしておくことでSCHEMAメッセージを正常に処理する

74
V9.1 Qアプライの場合 (compatibility =‘0901’)
ALTER メッセージとSCHEMAメッセージがQアプライへ送信されるが、QアプライはALTERメッセージを
© 2012 IBM Corporation
参考）設定可能なCOMPATIBILITYの値
• 異なるバージョン間で設定するCOMPATIBLITYの値は以下の通りです。
QApply
QCapture
10.1
10.1.3
(z/OS)
(LUW)
0901
0901
0901
0905
0905
0905
0905
0901
0905
0907
0907
0907
0901
0905
0907*
0907*
0907*
×
×
0907
0907
1001
9.1
9.5
9.7
9.1
0901
0901
9.5
0901
9.7
10.1
(z/OS)
10.1.3
(LUW)
DB2 LUW V10 のQキャプチャは、V9.7以降のQアプライとのみ、レプリケーション可能です。
* Qキャプチャのバージョンは、IBMQREP_CAPPARMSのARCH_LEVELに設定されています。
IRS V10 for z/OS のARCH_LEVELは、現在’100Z’となっており、z/OSでのみ有効な値です（将来的に’1001’になる予定）。
そのため、現在では、IRS V10 for z/OSとレプリケーションする場合、COMPATIBILITYは0907に設定されています。
75
© 2012 IBM Corporation
SQLレプリケーション バージョン間のサポート状況
SQLキャプチャー
SQLアプライ
10.1
(LUW)
10.1(LUW)
SQLキャプチャー
10.1
(z/OS)
SQLアプライ
10.1(LUW)
10.1(z/OS)
10.1(z/OS)
9.7
9.7
9.5
9.5
9.1
9.1
COMPATIBILITY 列の値を0801とすることで、旧バージョン
のアプライとのレプリケーションが可能です
V10 SQLキャプチャー for z/OSの
ARCH_LEVELは以前のままの0801の
ため、Compaibilityの設定は不要
※DB2 pureScaleがソースの場合は、COMPATIBILITY 列の値は 1001であることが必要で、その場合
は、アプライも、V10.1以降であることが必要です。
76
© 2012 IBM Corporation
参考）SQLレプリケーションのCompatibility設定
http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.swg.im.iis.db.repl.sqlmig.doc/topics/iiy
rsmigluw10compat.html
77
© 2012 IBM Corporation
V10.1 GA時点での制約事項
•
V 10.1 Q キャプチャーは、Compatibility 0901、0905 をサポートしていない
•
ソースが 9.7 またはこれ以前の場合には、リモート・キャプチャーにはバー
ジョン 9.7 の Q キャプチャー・プログラムが必要
•
CCD ターゲット表は 1001 の Compatibility ではサポートされない
• バージョン 10.1 Q キャプチャー・プログラムで CCD ターゲット表を使用するに
は、Compatibility を 0907 に設定してください。
• SQLレプリケーションはV10.1でもCCDターゲットをサポートします。
•
DB2 pureScale® データベースとz/OS間のレプリケーションはできません。
78
© 2012 IBM Corporation
DB2 pureScale Feature機能強化
79
© 2012 IBM Corporation
内容
• DB2 pureScale Featureとは何か
• V10.1での機能強化
• 新機能①：パーティション表サポート
• 新機能②：Current Member隠し列
• 新機能③：DB2 WLMの実装
• 新機能④：新しいモニタリング機能
• DB2 pureScaleに関するよくある質問
80
© 2012 IBM Corporation
DB2 pureScale Feature登場の背景
～既存のテクノロジーの限界を超える～
経営者・技術者の期待
1 爆発的なトランザクション増加へ
の備え
他社ディスク・シェア型
アーキテクチャーの限界
1 サーバ追加で思ったとおりスケー
ルしない
2 スピーディかつ低コストなサービ
2 アプリ・データ分割でチューニング
3 サービスレベルを落とさない
3 障害・メンテナンス時にリカバリー
ス拡張
運用
しなければスケールしない
までの間、停止を伴う
「ノンストップ」、「スケーラビリティ」、「スピード」を追求した
新しいデータベース・インフラ技術
81
© 2012 IBM Corporation
高い可用性を実現するDB2のクラスター技術
比較のポイント
DB2 pureScale
Infosphere
Warehouse(DPF)
HADR
アーキテクチャ
アクティブ-アクティブ型
シェアードディスク型
アクティブ-アクティブ型
シェアードナッシング型
アクティブ-ホットスタンバイ型
概要
メインフレームのCFのアーキテク
チャをSWの機能で実現し、可
用性と拡張性を向上
主に大規模情報系で活用
大量データを並列的に高速に
処理できる
シンプルに可用性を向上
ログ転送のみによる二重化のた
めパフォーマンス劣化が少ない
計画停止対策・ロー
リングアップグレード
片系ずつの適用をアプリケー
ションの停止なしに可能
片系ずつの適用が可能だが、
テークオーバーの考慮が必要
片系ずつの適用が可能。
テークオーバー処理が高速
障害対策
障害時に更新中のページ以
外のデータにアクセス可能
障害サーバーの復旧時間目
標は数十秒
N-1/Nのデータにアクセス可能。
障害サーバーの復旧時間目標
は1分前後
テークオーバー中は全体停止。
復旧時間目標は数十秒から1
分程度
大規模OLTP
統合DB
高信頼性
82
大規模DWH
（大規模OLTP）
汎用的な
OLTP/DWH
© 2012 IBM Corporation
DB2 pureScale の全体構成
アプリケーションはどこにでも接続
クライアント
– 一つのデータベースとして利用
– 自動的なワークロードバランス
シングル・データベース・ビュー
DB2エンジン(メンバー)は筐体/LPARで稼動
– AIX on Power6・Power7
– SUSE Linux on System X,Red Hat on System X
メン バー
CF-Secondary
CS
CS
メンバー
メンバー
CS
メンバー
CS
CS
をサポート
CF- Primary
統合されたクラスター・サービス
CS
– 障害検知, 自動リカバリー, クラスター・ファイルシステム
– Tivoli System Automation (TSA)、GPFS™
サーバー間通信
SAN接続（Fiber）
ログ
超高速サーバー間通信
– RDMAサーバー間通信を最大限に活用 (InfiniBand)
ログ
ログ
ログ
– 10G Ethernetもサポート
Cluster caching facility (CF)
– ロックとバッファー管理を最適化
データ
– セカンダリ への同期2重化により可用性を確保
データシェアリング・アーキテクチャー
– データベースへの共有アクセス
– General Parallel File System (GPFS)
83
© 2012 IBM Corporation
DB2 pureScale採用のメリット① - 高いスケーラビリティ pureScaleと他社クラスタのスケーラビリティ
pureScale vs. Oracle RAC Projected Transaction Scalability
Transactoins per Minute
Estimated
スループット(トランザクション/分)
16,000,000
95%のスケール
$1.28/tpm
14,000,000
$1.24/tpm
12,000,000
$1.20/tpm
$1.15/tpm
10,000,000
$1.10/tpm
DB2 pureScale on
Power Systems
8,000,000
6,000,000
4,000,000
2,000,000
Oracle
RAC on
他社クラスタ
Nehalem
$1.06/tpm
$1.05/tpm
$1.67/tpm
$1.41/tpm
$1.08/tpm
65%のスケール
0
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#サーバー数
Cluster Members
Price per tpm includes 3-year total cost of acquisition of hardware, software, maintenance
Price does not include storage or networking
84
© 2012 IBM Corporation
DB2 pureScale採用のメリット② - 高い可用性  障害範囲の極小化
障害サーバー以外はアクセスを継続
DB2
DB2
DB2
DB2
• 障害サーバーへの接続は稼動中のサーバーに
再分配
Log
障害サーバーが障害発生時に更新中のデー
タ以外は全面的にアクセス可能
CF
Log
Log
データ
Log
CF
 リカバリー処理の自動化
データベースサーバーの障害
 全面復旧までの時間の高速化
障害が発生したサーバーで実行中のトランザ
クションも、問題の検知も含めて短時間で復
旧させることが可能
回復中にはインフライトデータののみをロック
利用できるデータの割合(%)
統合されたクラスター製品により障害検
知からリカバリー処理までを自動化
100
50
Time (~seconds)
85
© 2012 IBM Corporation
新機能①：DB2 pureScale環境にてパーティション表を利用可能
• DB2 pureScale環境において大規模データの管理が容易になる
• v9.7以前から利用可能な機能、v10の新機能のいずれも利用可能
• パーティションの高速なアタッチとデタッチ
• 仕掛り中のクエリーがあっても、アタッチ、デタッチ可能
• パーティション単位での管理
• 更新が頻繁に発生する区分のみを高い頻度でバックアップ、再編成、再圧縮、等
• 区分限定スキャンにより大規模表のクエリー時間短縮
• 検索条件からスキャン対象のパーティション（表、索引）を特定
履歴表A
表スペース1
１月
１月
表スペース2
表スペース3
表スペース4
２月
３月
４月
区分の
デタッチ
５月
５月
区分の
アタッチ
１月
86
表スペース5
保存期間を過ぎた
データの高速な削除
５月
LOAD済み
表の追加
© 2012 IBM Corporation
パーティション表を利用する場合の運用
LOAD時間短縮のために、メンバーで並列に実行さ
せてから、アタッチさせることが可能
• V10.1新機能であるアタッチ時のset integrity回避を使用することで、
より高速に完了させることが可能。
メンバー並列で、パーティションごとに再編成が可能
• １つのメンバー内でも同時に複数パーティションに対して並列実施
可能
• ただし、パーティション索引が張られている表に対してのみ実行可能
87
© 2012 IBM Corporation
パーティション表活用によるメンバー間の競合緩和
• 課題：同じ索引ページやデータページへのインサートが集中すると、メンバー間
の競合によって処理性能が伸びなくなる
• 複数メンバーから同じページにデータ挿入が発生すると、データの整合性確保のため、最新のページがメン
バー間でやり取りされる
• RDMAを利用したpureScaleでは、競合他社製品よりも影響は尐ないが、大規模クラスター環境では、このメン
バー間の競合のために十分な性能が出ない可能性がある。
●単調増加する列が索引キーになっている例
Member1
Member0
INSERT INTO T1
VALUES
(10, CURRENT TIMESTAMP)
INSERT INTO T1
VALUES
(20, CURRENT TIMESTAMP)
実行DDL
CREATE TABLE T1
(C1 INT, C2 TIMESTAMP);
索引X1
CREATE INDEX X1 ON T1 (C2);
表T1
88
各メンバーから常に最大の値が挿
入されるため、索引の最終ページに
アクセスが集中する
© 2012 IBM Corporation
パーティション表活用によるメンバー間の競合緩和（続き）
• 競合緩和の解決①：メンバーIDが自動的にセットされる列を区分化列とした
パーティション表を使う。
• V10.1より新しく利用可能になった”CURRENT MEMBER”をデフォルト値とした隠し
列を定義し、その列を区分化列とする。
• 区分化された表と索引を各メンバー毎に用意することができるため競合が発生しない
●メンバーIDで分割したパーティション表
Member1
Member0
INSERT INTO T1
VALUES
(10, CURRENT TIMESTAMP)
INSERT INTO T1
VALUES
(20, CURRENT TIMESTAMP)
実行DDL
CREATE TABLE T1
(C1 INT, C2 TIMESTAMP,
C3 SMALLINT WITH DEFAULT
CURRENT MEMBER
IMPLICITLYHIDDEN)
PARTITION BY RANGE （C3)
（STARTING 0 ENDING 1 EVERY 1 ) );
CREATE INDEX X1 ON T1 (C2);
89
索引X1
表T1
各メンバーから常に最大の値が挿
入されるが、挿入の発生するメン
バー毎にターゲット索引と表が分か
れているため、競合が発生しない。
© 2012 IBM Corporation
新機能②：隠し列の活用によるメンバー間の競合緩和
• 競合緩和の解決②：メンバーID隠し列（CURRENT MEMBER）を索引の第1
キーに指定する
• ユニーク索引やタイムスタンプ列のように、キーがパーティション化しにくい場合
に”CURRENT MEMBER”隠し列を第1キーに指定する
• メンバーごとに索引を局所化し、メンバー間での同一ページのやりとりを回避でき
る
●各メンバーIDが第１キーとなる局所化された索引の更新
Member0
Member1
INSERT INTO T1
VALUES
(10, CURRENT TIMESTAMP)
INSERT INTO T1
VALUES
(20, CURRENT TIMESTAMP)
実行DDL
CREATE TABLE T1
(C1 INT, C2 TIMESTAMP,
C3 SMALLINT WITH DEFAULT
CURRENT MEMBER
IMPLICITLYHIDDEN) );
0 1
索引X1
CREATE INDEX X1 ON T1 (C3,C2);
表T1
90
ID=0 ID=1
各メンバーから常に最大の値が挿
入されるが、挿入の発生するメン
バー毎にターゲットページが分かれ
ているため、競合が発生しない。
© 2012 IBM Corporation
新機能③：DB2 WLMの実装
• DB2 pureScale において、DB2 WLMが利用可能になった。
• 利用例：同じデータを使用するシステムを統合した場合に、優先度の高い
処理は、他の処理の影響を受けずに、一定のパフォーマンスを担保させる。
業務A
APサーバー
業務B
APサーバー
業務C
APサーバー
Active Node
Active Node
Active Node
Active Node
DBMS
DBMS
DBMS
DBMS
Cluster
Cluster
Cluster
Cluster
データ連携に伴うバッチ処理の負
荷に対して、高優先度のオンライン
トランザクションへの影響を小さく
することが可能。
91
業務E
APサーバー
CFNode
Node
CF
DBMS
DBMS
優先度の高い業務や、要件に合わせて柔
軟にリソースの優先度制御することが可能。
データ連携
DWHなど
業務D
APサーバー
・・・
© 2012 IBM Corporation
新機能④：新しいモニタリング表関数の提供
• CF上のGroup Buffer Pool（GBP）が適正サイズ確認のための表関数を提供
• MON_GET_GROUP_BUFFERPOOL表関数
• ページ登録やGBPへのページ書き込み時に空きスペースが無かった場合に発生するエラー
（GBP_FULL）の発生回数を報告
• 実行シンタックス
MON_GET_GROUP_BUFFERPOOL (メンバーID）
• 戻り値
列名
データタイプ
説明
MEMBER
SMALLINT
メンバーID
NUM_GBP_FULL
BIGINT
GBP_FULLエラーの発生回数
• 評価方法
•
1分間に1回以上のGBP_FULL増加があった場合には、GBPの大きさを拡大することを検討
●実行例
SELECT SUM(T.NUM_GBP_FULL) AS NUM_GBP_FULL FROM TABLE(MON_GET_GROUP_BUFFERPOOL(-2)) AS T
NUM_GBP_FULL
-----------123
1 record(s) selected.
92
© 2012 IBM Corporation
DB2 pureScaleに関するよくある質問 (1)
• DB2 pureScaleのライセンスはどのサーバーに課金されますか？
• DB2メンバーのサーバーに、DB2 pureScaleのライセンスが課金されます。
• CFサーバーには、DB2 pureScaleのライセンスは課金されません。
• DB2 pureScaleを使用するために必要なライセンスは？
• DB2 Advanced Enterprise Server Edition + DB2 pureScale Feature
• DB2 Enterprise Server Edition + DB2 pureScale Feature
• DB2 Workgroup Server Edition （クラスターの全サーバーで合計4CPUソケットまで）
• DB2 Database Enterprise Developer Edition
• DB2 pureScaleとは別に、GPFSやTSAの購入が必要ですか？
• いいえ、必要ありません。
DB2 pureScaleにGPFSやTSAのライセンスおよびモジュールが含まれます。
DB2 pureScaleを導入するとGPFSやTSAが同時に導入されます。
93
© 2012 IBM Corporation
DB2 pureScaleに関するよくある質問 (2)
• Oracle互換モードはDB2 pureScaleと組み合わせて使用できますか？
• Oracle互換モード（Oracle対応PL/SQL、SQL、トリガー、ファンクション、デー
タ型など）はDB2 pureScaleと組み合わせて使用できます。
• DB2 pureScaleの制約は？
• 現時点（2012/09）で、以下機能はDB2 pureScaleと組合わせて使用できませ
ん。機能向上として今後随時追加される予定です。
• MDC（多次元クラスター表）
• 差分/増分バックアップ
• オンラインでの表・索引の再編成（インプレース再編成）[オンライン表移動プロシー
ジャーで代用可能]
• オンラインでのDB2のFix Pack適用
• オンラインでのメンバー追加
• 自動ストレージ以外のコンテナー（従来のSMS、DMSコンテナー）
• HADR [参考：災害対策としてレプリケーション機能やストレージコピーが使用可能]
• DB2 Text Search / Net Search Extender / Spatial Extender
94
© 2012 IBM Corporation
DB2 pureScale Featureのまとめ
• DB2 pureScaleは、高い拡張性と可用性を併せ持つ新しいク
ラスターDBソリューションである
• 表/索引の設計によりホットスポットの回避が可能になった
• パーティション表の活用
• Current member隠し列の活用
• DB2 WLMにより、メンバーごとのリソース制御が可能になった
• 同一データを使用する複数システムの統合により、業務間の
優先度を調整可能
• DB2 pureScale用の新しいモニタリング機能により、パフォー
マンスのボトルネックを調査可能な情報が増えた
95
© 2012 IBM Corporation