Download Online Split Mirror 内容

DB2 UDB (PC&Unix) V7.2
Online Split Mirror
Online Split Mirror
お断り：当資料は、DB2 UDB V7.2（UNIX,PC)をベースに作成されています。
＜第１．００版＞２００１年６月
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
内容
１．現状と問題点
２．ESS コピーサービス
３．SET WRITE SUSPENDコマンド
４．db2inidbユーティリティー（Fixpak2）
５．SNAPSHOT
６．STANDBY
７．MIRROR
８．WRITE SUSPEND時の表スペース状態
９．SUSPEND I/O時の制約
１０．Suspend I/O時異常終了後のクラッシュリカバリー
１１．スプリット・イメージからのバックアップ （
V 7.2）
１２．Split Mirrorシナリオ
１３．今後の拡張
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 1-2 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
現状と問題点
現状
24時間、365日DB2を止めることができないようなサービス形態の増加
”
データベースのミラー化”
需要増大(負荷分散、データの保護等の理由）
大規模DBの要件増加
いままでの問題点
DB2 UDBではESS FlashCopyや他のOS提供のコピーを使用したBackup/Recovery手順がサ
ポートされなかった
backup/restore/rollforwardといったユーティリティーを使用せざる得なかった
Backup/Restore時の実行速度が遅い
Readのみを許可し、Writeを許可しないモードがDB2 UDBから提供されていない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：現状と問題点
近年、24時間365日DB2を止めることができないようなサービス形態は増加の一途をたどっています。また負荷分散、データ保護などの
ため、データベースを「ミラー化」する、という要件も多くなっています。さらにテラバイトを超えるようなDBのバックアップ/リストアをDB2
提供のBACKUP DB/RESTORE DBで行うことが現実的でないようなケースも出てきています。
DB2 UDB V7.1までは、DB2 UDBとしてESS FlashCopyや他のOS提供のコピーを使用したBackup/Recovery手順がサポートされず、db2
コマンドとしてのbackup/restore/rollforwardコマンドを使用せざる得ませんでした。
DB2のユーティリティーである、Backup/Restore DBは、ESS Flash Copyなどに比べるとDBバックアップ取得の処理は遅く、またReadの
みを許可し、Writeを許可しないモードがDB2から提供されていなかったため、OS提供のコピーを使用したBackupを取得しようとする場
合には、DBを停止しなければなりませんでした。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 3-4 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
ESS コピーサービス
FlashCopy (Local)
Peer-to-Peer Remote Copy
(PPRC:対等リモート・コピー）
機能
瞬時にデータのコピーを取得する機能
ディスク･ボリューム単位でコピー
AIXではhdisk単位
利点
バックアップ処理によるアプリケーション停止時間の大幅な削減
テスト・
データの容易な作成
データの容易な複製（
BIアプリケーションへの利用など）
起動
Ｗｅｂアプリケーション（IBM TotalStorage Expert ESS Specialist)から起動
command I/F (開発中）
利用可能日とフィーチャー
２０００年第四四半期
有料フィーチャーが必要
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：ESSコピーサービス
Flash Copy、Peer-to-Peer Remote Copy（
PPRC）
は、それぞれ IBM Enterprise Storage Server（
ESS)の提供する有料フィーチャーであ
る、ESSコピーサービスとして提供される機能です。
Flash Copyは、ESSのボリュームのポイント･イン･タイム・コピーの取得を可能にします。つまり、Flash Copyが実行されるとその時点で
のDISKのコピーを取得することができます。Flash Copyは数秒で完了する非常に速い処理で、Flash Copyの完了後はOriginalとCOPY
の両方を使用できます。
PPRCは、あるESSのひとつのLogical Unit（
LUN)から2番目のESSにある別LUNへのリアルタイムのミラーリングを可能にする、同期プ
ロトコルです。この2番目のESSは遠隔地に置くことができます。PPRCはアプリケーションから独立しています。コピーはディスクサブシス
テム単位で行われるため、アプリケーションからはそのコピー機能の存在を意識することがありません。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 5-6 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
SET WRITE SUSPENDコマンド
OnlineのDBからFlash Copyのような機能を使ってSplit Mirrorイメージを
取得するため、新しいコマンドが提供された
set write suspend for database （
Fixpak1）
すべてのTablespaceとLogに対するDISK書き込みを禁止
書き込み禁止のリソースへの書き込み要求はWAIT状態になる
バッファープールへの書き込み、ログバッファーへの書き込みは認める
SELECT/INSERT/UPDATE/DELETEとも、表スペースやLOGのDISKへの書き込みを発生し
ない限り実行可能
バッファープール、ログバッファーに空きがある限り、UPDATE/INSERT/DELETEの実行可能
更新トランザクションのCOMMITはログバッファーのDISKフラッシュをするのでWAITになる
一時表スペースへの書き込みが必要なSELECTはWAITになる
発行するとLog Buffer内のログはDiskへForce Writeされる
バッファープール内にあるページはDiskへForce Writeされない
書き込み禁止状態になったDBからFlash Copyのような機能を使ってSplit Mirrorイメージを取
得する
DBを停止する必要はなし
set write resume for database（
Fixpak1）
Suspend write状態の解除
Split Mirrorイメージの取得完了後、直ちにこのコマンドで書き込み禁止状態を解除する
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：SET WRITE SUSPENDコマンド
OnlineのDBからFlash Copyのような機能を使ってSplit Mirrorイメージを取得するため、DB2 UDB V7.1のFixpak１では新しいコマンドが提
供されました。
set write suspend for database
すべてのTablespaceとLogに対するDISK書き込みを禁止します。DISK書き込み禁止の状態になっても、バッファープールやログバッ
ファーといったメモリー上の領域への書き込みは禁止しません。ですから、SELECT/INSERT/UPDATE/DELETEとも、DISKへの書
き込みが発生しない限り実行可能です。すなわち、バッファープール、ログバッファーに空きがある限り、
UPDATE/INSERT/DELETEの実行は可能ですが、それらをCOMMITしようとした時点でWAIT状態になります。COMMITはログバッ
ファーのフラッシュをするからです。また、SELECTであっても書込み禁止のDISKへの書き込みを必要とする場合、WAIT状態になる
可能性があります。
書き込み禁止されたリソースに書込み要求をしてしまう例：
SELECT でもORDER BYをし、そのシステム一時表スペースへ書き込みをする場合待ち
そのSELECT自身がDirty Page(Bufferpool上にあるデータで変更があったページ）をdiskへ書き戻しを要求するよう場合は待ち
SET WRITE SUSPEND FOR DATABASEが発行されるとLog Buffer内のログはDiskへForce Writeされます
バッファープール内にあるページはDiskへForce Writeされません。
バッファープール内のDirtyページに書かれた情報はSplit Mirroredイメージには書かれないことになりますが、ログには反映さ
れています。後ほどこのSplit Mirrorを使用するときにはCrashリカバリー（またはROLLFORWARD)を実行することでログにある
更新情報をSplit Mirrorイメージの方へ反映させることができます。
set write resume for database
Suspend_write状態を解除します。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 7-8 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
db2inidbユーティリティー（Fixpak2）
取得されたSplit Mirrorイメージの用途を決定する
Snapshot
Crashリカバリーが実行され, Write Suspend状態が解除
Split Mirrorが取得された時点でCOMMITもROLLBACKもされていないトランザクションは
ROLLBACKされる
循環ログを用いているDBからのSplit Mirrorには、このオプションのみ使用可能
Standby
Crashリカバリーは実行せず、DBをRollforward Pending状態にする。Write Suspend状態は解除
OriginalのDBで生成されたログファイルを使って随時ROLLFORWARDを実行
Mirror
Crashリカバリーは実行せず、DBをRollforward Pending状態にする。Write Suspend状態は解除
Split MirrorをあたかもDBのバックアップのように使用する際に指定
Split MirrorをPrimaryDB上に戻してから db2inidb ... as mirror を実行
>>-db2inidb---database-alias---AS---+--SNAPSHOT-+-------------->
|
+--STANDBY--+
|
+--MIRROR---+
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：db2inidbユーティリティー（Fixpak2）
SET WRITE SUSPENDコマンドは、ログバッファーのフラッシュは行いますが、バッファープール上のDirtyページのフラッシュは行いませ
ん。ですから、取得したSplit Mirrorイメージは整合性の取れていない状態にあります。
DB2 UDB V7.1のFixPak２で、新しくdb2inidbというコマンドが使用可能になりました。このコマンドは、取得したSplit Mirrorイメージをどん
な目的に使用するのかをＤＢ２に知らせるために使用します。
コマンド構文
>>-db2inidb----database_alias----AS----+-SNAPSHOT-+------------><
+-STANDBY--+
'-MIRROR---'
スナップショット
Crashリカバリーが実行され、Write Suspend状態が解除されます。新しいLOG CHAINが始まるため、元のデータベースのいかなる
ログからもロールフォワードは実行できません。
db2inidb <db_name> as snapshot
db2inidbコマンドが完了した時点で、データベースはバックアップを含むすべての作業を行えるようになります。循環ログ方式を用い
ている場合、SNAPSHOTのみ指定可能です。
スタンバイ
データベースをロールフォワード保留状態にします。
db2inidb <db_name> as standby
スタンバイとミラーの両オプションではCrashリカバリーは実行されません。また、実行途中のトランザクションは未解決のままになる
ため、データベースは不整合状態のままです。
STANDBYオプションでdb2initdbコマンドが実行されたSplit Mirrorは、ROLLFORWARD保留状態のままセカンダリーDBにおいておき
ます。Primaryで生成されたログファイルは随時SecondaryへROLLFORWARDを使って適用してゆきます。Secondaryを使いたくなっ
た時点でROLLFORWARD ．．．COMPLETEを実行すれば良いわけです。
ミラー
ミラーコピーは元データベースに置きかえられ、データベースはロールフォワード保留状態になり、そしてWRITE SUSPEND状態は
解除されます。
db2inidb <db_name> as mirror
分割されたDBイメージのログではなく、プライマリーDBのログを使ってROLLFORWARDを実行することが必要です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 9-10 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
解説：db2inidbユーティリティー（Fixpak2）（続き）
Split Mirrorを取得したDBが循環ログ方式を用いている場合、STANBYおよびMIRRORオプションは指定できません。以下はそのよ
うなDBからのSplit Mirrorに対してSTANDBYオプションを指定したときのエラーメッセージです。
$ db2inidb testdb as standby
ERROR: Database TESTDB is not a recoverable database
EEE構成においてはSplit Mirrorイメージがアクセス可能になる前に、全てのノード上でツールを稼動させる必要があります。
Split Mirrorに対してdb2inidbを実行していないのにCONNECTしようとすると、以下のようなエラーとなります。
SQL20153N The database's split image is in the suspended state.
SQLSTATE=55040
DIAG.LOG出力
2001-05-24-22.40.06.189963
Instance:udb32v7
Node:000
PID:43598(db2agent (TESTDB2))
Appid:*LOCAL.udb32v7.010524134006
data_protection sqlpgint
Probe:50
Database:TESTDB2
Split image can only be accessed by db2inidb command
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
意図したブランクページです。
( 11-12 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
SNAPSHOT
読み取り専用のセカンダリーDBに、アプリケーション用にある時点のプ
ライマリー DBのクローンを作成する
Data
Data
Active
Log
Active
Log
Primaryからアーカイブログは
転送しない
Archived
Log
DataBase
Primary
DataBase
Secondary
SNAPSHOT手順
１．Primaryにてdb2 set write suspend for database
２．OS LevelでのPrimaryからSecondaryへCopyを実施
３．Primaryにてdb2 set write resume for database
４．Secondaryにてdb2start
５．Secondaryにてdb2inidb <DB> as snapshot ( =>Read/Write使用可能状態）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：SNAPSHOTの例
Primary DBの作成
db2 create db v7db on /dblandt
[db2v7@dbdcserv(Ja_JP)/home/db2v7]
==> db2 create db v7db on /dblandt
DB20000I The CREATE DATABASE command completed successfully.
==> df /dblandt
Filesystem 512-blocks
Free %Used Iused %Iused Mounted on
/dev/lv06
98304 62248 37%
231 2% /dblandt
[db2v7@dbdcserv(Ja_JP)/home/db2v7]
==> cd /dblandt
[db2v7@dbdcserv(Ja_JP)/dblandt]
==> ls -l
合計 16
drwxrwsr-x 3 db2v7 db2adm
512 Nov 06 15:33 db2v7
drwxrwx--- 2 root system
512 Oct 26 10:03 lost+found
Active Logpathの変更
db2 update db cfg for v7db using newlogpath /work/activelog
[db2v7@dbdcserv(Ja_JP)/dblandt]
==> db2 update db cfg for v7db using newlogpath /work/activelog
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
DB21026I For most configuration parameters, all applications must disconnect from this database before the changes become
effective.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 13-14 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
解説：SNAPSHOTの例（続き）
Active Log PATH確認
db2 connect
Database Connection Information
Database server
= DB2/6000 7.1.2
SQL authorization ID = DB2V7
Local database alias = V7DB
db2 get db cfg for v7db
Log file size (4KB)
Number of primary log files
Number of secondary log files
Changed path to log files
Path to log files
First active log file
(LOGFILSIZ) = 1000
(LOGPRIMARY) = 3
(LOGSECOND) = 2
(NEWLOGPATH) =
= /work/activelog/
=
Group commit count
(MINCOMMIT) = 1
Percent log file reclaimed before soft chckpt (SOFTMAX) = 100
Log retain for recovery enabled
(LOGRETAIN) = OFF
User exit for logging enabled
(USEREXIT) = OFF
Auto restart enabled
(AUTORESTART) = ON
Index re-creation time
(INDEXREC) = SYSTEM (RESTART)
Default number of loadrec sessions (DFT_LOADREC_SES) = 1
Number of database backups to retain (NUM_DB_BACKUPS) = 12
Recovery history retention (days) (REC_HIS_RETENTN) = 366
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：SNAPSHOTの例（続き）
Primary DBへ表を作成
TEST_SOURCE表を作成
CREATE TABLE TEST_SOURCE (ROW_NUMBER SMALLINT NOT NULL, TEST_DATA SMALLINT, DES
CRIPTION CHAR(20)) DATA CAPTURE CHANGES
DB20000I The SQL command completed successfully.
CREATE UNIQUE INDEX TEST_SOURCE_X ON TEST_SOURCE (ROW_NUMBER)
DB20000I The SQL command completed successfully.
INSERT INTO TEST_SOURCE VALUES (1,1,'this is row1')
DB20000I The SQL command completed successfully.
INSERT INTO TEST_SOURCE VALUES (3,3,'this is row3')
DB20000I The SQL command completed successfully.
INSERT INTO TEST_SOURCE VALUES (5,5,'this is row5')
DB20000I The SQL command completed successfully.
INSERT INTO TEST_SOURCE VALUES (6,6,'this is row6')
DB20000I The SQL command completed successfully.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 15-16 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
解説：SNAPSHOTの例（続き）
Primary側にてSET WRITE SUSPEND FOR DATABASE
==> db2 set write suspend for database
DB20000I The SET WRITE command completed successfully.
File転送＋ＦＴＰ（またはESSのFlashCopy)
tar -cvf /work/v7db.tar /dblandt/db2v7
tar -cvf /work/activelog.tar /work/activelog
Primary->Secondary FTP実施
Primary側にてSET WRITE RESUME FOR DATABASE
通常にRead/Write可能
Secondary側にてdb2start
Secondary側にてdb2 catalog db v7db /dblandtを実施
Secondary側にてdb2stop
Secondary側にて解凍
tar -xvf /work/v7db.tar /dblandt/db2v7
tar -xvf /work/activelog.tar /work/activelog
Secondary側にてdb2start 後db2inidb
db2start
db2inidb v7db as snapshot
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：SNAPSHOTの例（続き）
Secondary側のデータ確認
db2 connect to v7db
Database Connection Information
Database server
= DB2/6000 7.1.2
SQL authorization ID = DB2V7
Local database alias = V7DB
データを確認
db2v7@udb04:/work>db2 "select * from test_source"
ROW_NUMBER TEST_DATA DESCRIPTION
---------- --------- -------------------1
1 this is row1
3
3 this is row3
5
5 this is row5
6
6 this is row6
4 record(s) selected.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 17-18 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
STANDBY
常時プライマリーのデータベースからロールフォワード可能なStandby
データベースをセカンダリーに作成する
Data
Data
Active
Log
Archived
Log
Archived
Log
DataBase
DataBase
Primary
Primaryからアーカイブログを
転送する
Secondary
手順
１．Primaryにてdb2 set write suspend for database
２．OS LevelでのPrimaryからSecondaryへCopyを実施
３．Primaryにてdb2 set write resume for database
４．Secondaryにてdb2start
５．SecondaryにてCopyされたActive LOG削除(COPYされていれば）
６．Secondaryにてdb2inidb <DB> as Standby( =>Rollforward Pending状態）
７．Primary側のUserExitにて書き出されたLog FileをSecondaryへ転送、Secondary側で
ROLLFORWARD実行（
STOP/COMPLETEオプションは付けない）(以降、繰り返す)
８．もしPrimary側がDownしたらばRollforward with STOP/COMPLETEをSecodary側にて実施
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：STANDBYの例
Primary側にてUser ExitをON
USEREXIT Programを修正
#define ARCHIVE_PATH
"/work/"
/* path must end with a slash
*/
#define RETRIEVE_PATH "/work/"
/* path must end with a slash
*/
#define AUDIT_ACTIVE
1
/* enable audit trail logging
*/
#define ERROR_ACTIVE
1
/* enable error trail logging
*/
#define AUDIT_ERROR_PATH "/work/"
/* path must end with a slash
*/
#define AUDIT_ERROR_ATTR "a"
/* append to text file
*/
#define BUFFER_SIZE
32
/* # of 4K pages for output buffer */
db2 update db cfg for v7db using userexit on
Primary側で更新後、接続を解除 --->
アクティブlogがクローズされArchived Log Path(/work/V7DB/NODE0000)へUSEREXITにてLOGが書き出される
db2 "update test_source set test_data=test_data+100"
db2 "select * from test_source"
ROW_NUMBER TEST_DATA DESCRIPTION
---------- --------- -------------------1
101 this is row1
3
103 this is row3
5
105 this is row5
6
106 this is row6
4 record(s) selected.
db2 terminate
lsコマンド
[db2v7@dbdcserv(Ja_JP)/work/V7DB/NODE0000]
==> ls -l
合計 24
-rw------- 1 db2v7 sys
12288 Nov 06 16:41 S0000000.LOG
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 19-20 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
解説：STANDBYの例（続き）
Primary側にてSET WRITE SUSPEND FOR DATABASE
==> db2 set write suspend for database
DB20000I The SET WRITE command completed successfully.
File転送＋ＦＴＰ（またはESSのFlashCopy)
tar -cvf /work/v7db.tar /dblandt/db2v7
Primary->Secondary FTP実施
Primary側にてSET WRITE RESUME FOR DATABASE
通常にRead/Write可能
Secondary側にてdb2stop
Secondary側の/sqllib/adm下へPrimaryと同じUSEREXITプログラムをCOPY(db2uext2)
Secondary側にて解凍
tar -xvf /work/v7db.tar /dblandt/db2v7
Secondary側にてdb2start 後db2inidb
db2start
(前回のSNAPSHOT Test時のデータ,ログ消去の為、db2 drop db v7dbおよびcatalog db v7db on /dblandtを実施しておく）
db2inidb v7db as standby
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：STANDBYの例（続き）
Secondary側でdb2inidbを実施後、接続TRY
db2v7@udb04:/dblandt>db2 connect to v7db
SQL1117N A connection to or activation of database "V7DB" cannot be made
because of ROLL-FORWARD PENDING. SQLSTATE=57019
QUERY STATUSを実施
db2v7@udb04:/dblandt>db2 rollforward db v7db query status
Rollforward Status
Input database alias
= v7db
Number of nodes have returned status = 1
Node number
Rollforward status
Next log file to be read
Log files processed
Last committed transaction
=0
= DB pending
= S0000001.LOG
= = 2000-11-06-07.55.33.000000
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 21-22 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
解説：STANDBYの例（続き）
PrimaryからSecondaryへArchived LOG(S0000000.LOG)を転送後、Rollforwardを実施
db2v7@udb04:/work/V7DB/NODE0000>ls -l
合計 24
-rw-r--r-- 1 db2v7 db2adm 12288 Nov 06 17:51 S0000000.LOG
db2v7@udb04:/work/V7DB/NODE0000>db2 rollforward db v7db to end of logs
Rollforward Status
Input database alias
= v7db
Number of nodes have returned status = 1
Node number
Rollforward status
Next log file to be read
Log files processed
Last committed transaction
=0
= DB working
= S0000001.LOG
= = 2000-11-06-07.55.33.000000
STATUSが"DB pending"から"DB working"に変更され、Next LogはS0000001.LOGのまま変更なし
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：STANDBYの例（続き）
Primary側にて更新後、接続をきる
[db2v7@dbdcserv(Ja_JP)/work/V7DB/NODE0000]
==> db2 connect
Database Connection Information
Database server
= DB2/6000 7.1.2
SQL authorization ID = DB2V7
Local database alias = V7DB
[db2v7@dbdcserv(Ja_JP)/work/V7DB/NODE0000]
==> db2 "update test_source set test_data=test_data+100"
DB20000I The SQL command completed successfully.
[db2v7@dbdcserv(Ja_JP)/work/V7DB/NODE0000]
==> db2 terminate
DB20000I The TERMINATE command completed successfully.
[db2v7@dbdcserv(Ja_JP)/work/V7DB/NODE0000]
==> ls -l
合計 48
-rw------- 1 db2v7 sys
12288 Nov 06 16:55 S0000000.LOG
-rw------- 1 db2v7 sys
12288 Nov 06 17:10 S0000001.LOG
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 23-24 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
解説：STANDBYの例（続き）
PrimaryからSecondaryへArchived LOG(S0000001.LOG)を転送後、Rollforwardを実施
db2 rollforward db v7db to end of logs
Rollforward Status
Input database alias
= v7db
Number of nodes have returned status = 1
Node number
Rollforward status
Next log file to be read
Log files processed
Last committed transaction
=0
= DB working
= S0000002.LOG
= S0000001.LOG - S0000001.LOG
= 2000-11-06-08.10.23.000000
DB20000I The ROLLFORWARD command completed successfully.
上記を繰り返し、常にSecondaryはRollforward Pending状態
SecondaryDBでロールフォワード保留状態を解消し、アプリケーションからアクセス可能にするためには、ROLLFORWARD DB ＜
DBNAME＞TO END OF LOGS AND COMPLETEを実行する。その時点で（
適用したログの範囲で）
完了していないトランザクションは
ROLLBACKとみなされる。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
意図したブランクページです。
( 25-26 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
MIRROR
セカンダリーへコピーされたSplit Mirrorからプライマリーへコピーバック
し、PrimaryDBのLOGからロールフォワード可能なデータベースを作成
する
Data
Data
MirrorとしてCopy Backする前
に更新されてはいけない
Active
Log
Archived
Log
DataBase
Primary
Archived
Log
DataBase
Secondary
手順
１．Primaryにてdb2 set write suspend for database
２．OS LevelでのPrimaryからSecondaryへCopyを実施
３．Primaryにてdb2 set write resume for database
４．<Primaryにて通常運用後、 障害発生>
５．SecondaryからPrimaryへCOPY Back （
Primary側のLogは退避させておく）
SecondaryのLOGはCOPY Backしないが、log control file(SQLOGCTL.LFH)は含める
６．Primaryにてdb2inidb <DB> as Mirror( =>Rollforward Pending状態）
７．Primary側で既存のLOGを使用してRollforward ＋ STOP/COMPLETEを実施
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Mirrorの例
Primary DB側で表の内容を確認後、更新(接続は切断しない-->更新はActive Log上にある状態）
[db2v7@dbdcserv(Ja_JP)/work/V7DB/NODE0000]
==> ls
S0000000.LOG S0000001.LOG S0000002.LOG
==> db2 "select * from test_source"
ROW_NUMBER TEST_DATA DESCRIPTION
---------- --------- -------------------1
301 this is row1
3
303 this is row3
5
305 this is row5
6
306 this is row6
4 record(s) selected.
==> db2 +c "update test_source set test_data=test_data+100"
DB20000I The SQL command completed successfully.
[db2v7@dbdcserv(Ja_JP)/work/V7DB/NODE0000]
==> db2 commit
DB20000I The SQL command completed successfully.
[db2v7@dbdcserv(Ja_JP)/work/V7DB/NODE0000]
==> ls
S0000000.LOG S0000001.LOG S0000002.LOG
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 27-28 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
解説：Mirrorの例（続き）
Primary側にて接続があるにも関わらず、異常終了させる
別セッションにてdb2stop -kil
[db2v7@dbdcserv(Ja_JP)/home/db2v7]
==> db2 list applications
Auth Id Application
Name
-------- -------------DB2V7
db2bp
Appl.
Application Id
Handle
---------- -----------------------------28
*LOCAL.db2v7.001106084234
DB
# of
Name
Agents
-------- ----V7DB
1
[db2v7@dbdcserv(Ja_JP)/home/db2v7]
==> db2stop -kill
SQL1064N DB2STOP processing was successful.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Mirrorの例（続き）
Secondary側からDB Copy Imageのみをコピーバックする(Secondary側のActive,Archived Logはコピーバックしない）
ESS FlashCopyまたはtar+ftpの実施
Primary側でdb2inidb,db2startを実施
db2inidb v7db as mirror
==> db2inidb v7db as mirror
[db2v7@dbdcserv(Ja_JP)/work/activelog]
==> db2 connect
SQL1032N No start database manager command was issued. SQLSTATE=57019
[db2v7@dbdcserv(Ja_JP)/work/activelog]
==> db2start
SQL1063N DB2START processing was successful.
[db2v7@dbdcserv(Ja_JP)/work/activelog]
==> db2 connect
SQL1117N A connection to or activation of database "V7DB" cannot be made
because of ROLL-FORWARD PENDING. SQLSTATE=57019
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 29-30 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
解説：Mirrorの例（続き）
Primary側でロールフォワード
==> ls
S0000003.LOG S0000004.LOG S0000005.LOG SQLLPATH.TAG
[db2v7@dbdcserv(Ja_JP)/work/activelog]
==> db2 rollforward db v7db to end of logs and stop
Rollforward Status
Input database alias
= v7db
Number of nodes have returned status = 1
Node number
Rollforward status
Next log file to be read
Log files processed
Last committed transaction
=0
= not pending
=
= S0000000.LOG - S0000003.LOG
= 2000-11-06-08.42.47.000000
DB20000I The ROLLFORWARD command completed successfully.
データを確認
==> db2 'select * from test_source'
ROW_NUMBER TEST_DATA DESCRIPTION
---------- --------- -------------------1
401 this is row1
3
403 this is row3
5
405 this is row5
6
406 this is row6
4 record(s) selected.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
意図したブランクページです。
( 31-32 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
WRITE SUSPEND時の表スペース状態
WRITE SUSPEND時は、すべてのTABLESPACEが書き込み禁止
==> db2 set write suspend for database
==> db2 list tablespaces
Tablespaces for Current Database
Tablespace ID
= 0
Name
= SYSCATSPACE
Type
= System managed space
Contents
= Any data
State
= 0x10000
Detailed explanation:
Write Suspended
Tablespace ID
Name
Type
Contents
State
Detailed explanation:
Write Suspended
=
=
=
=
=
1
TEMPSPACE1
System managed space
System Temporary data
0x10000
Tablespace ID
Name
Type
Contents
State
Detailed explanation:
Write Suspended
=
=
=
=
=
2
USERSPACE1
System managed space
Any data
0x10000
db2diag.log
2000-11-03-21.08.09.989000 Instance:DB2 Node:000
PID:984(db2syscs.exe) TID:1184 Appid:*LOCAL.DB2.001103120746
buffer_pool_services sqlbSuspendWrite Probe:30 Database:AZUMA98
IO suspended for tablespace 0
2000-11-03-21.08.09.999000 Instance:DB2 Node:000
PID:984(db2syscs.exe) TID:1184 Appid:*LOCAL.DB2.001103120746
buffer_pool_services sqlbSuspendWrite Probe:30 Database:AZUMA98
IO suspended for tablespace 1
2000-11-03-21.08.10.009000 Instance:DB2 Node:000
PID:984(db2syscs.exe) TID:1184 Appid:*LOCAL.DB2.001103120746
buffer_pool_services sqlbSuspendWrite Probe:30 Database:AZUMA98
IO suspended for tablespace 2
2000-11-03-21.08.10.059000 Instance:DB2 Node:000
PID:984(db2syscs.exe) TID:1184 Appid:*LOCAL.DB2.001103120746
buffer_pool_services sqlbSetPoolChange Probe:110 Database:AZUMA98
Suspend I/O Write: all tablespaces
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：WRITE SUSPEND時の表スペース状態
SET WRITE SUSPEND FOR DATABASE を実行すると、そのデータベースのすべての表スペースがwrite suspend状態（
0x10000）となっ
て書き込み不能となります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 33-34 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
SUSPEND I/O時の制約
SELECTでも待ちになるケース有り。(タイムアウトしない）
バッファープール中Dirty PageをDISKへ書き戻す行為を引き起こすSELECT文
Log Bufferにあふれ、DISKへ書き込みを起こす更新(表にData Change Capture属性がある場
合にはLOG量が増加するので要注意、省略時のLogBuffer Size=8KB）
ソートをメモリー内で行なえず、システムテンポラリー領域へ書き込みを要求するORDER BY
付きのSELECT文
その他の考慮点
REORG/QUIESCE/ALTER TABLESPACE/CREATE TABLESPACEなどは実行不可(待ち）
SUSPEND I/O中DB2STOPできない
==> db2stop
SQL1553N DB2 cannot be stopped because one or more databases are in WRITE SUSPEND state.
SUSPEND I/O中、BACKUPはTABLESPACEへラッチ要求がでるため待ちになる
BACKUP/RESTORE実行中はSUSPEND I/Oができない
SQL01550N The SET WRITE SUSPEND command failed. (Reason code = n).
1. Database is not activated.
2. Database is in backup in progress state.
3. Database is in restore in progress state.
4. Database is already in suspended state.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：SUSPEND I/O時の制約
SELECTであってもWRITE SUSPEND状態のリソースへの書き込みが必要になる場合があるため、場合によってはWRITE SUSPEND状
態のDBで待ち状態になることがあります。以下のようなケースです。
バッファープール中Dirty PageをDISKへ書き戻す行為を引き起こすSELECT文
Log Bufferにあふれ、DISKへ書き込みを起こす更新(表にData Change Capture属性がある場合にはLOG量が増加するので要注
意、省略時のLogBuffer Size=8KB）
ソートをメモリー内で行なえず、システムテンポラリー領域へ書き込みを要求するORDER BY付きのSELECT文
なお、WRITE SUSPEND状態のものへ書き込みが発生したための待ちは、LOCK待ちと異なりタイムアウトしないので注意が必要です。
その他の考慮点
REORG/QUIESCE/ALTER TABLESPACE/CREATE TABLESPACEなどをWRITE SUSPEND状態のDBに対して発行すると、WRITE
RESUMEが発行されるまで待たされることになります。
SUSPEND I/O中DB2STOPはできません
==> db2stop
SQL1553N DB2 cannot be stopped because one or more databases are in WRITE SUSPEND state.
SUSPEND I/O中はBACKUPはTABLESPACEへラッチ要求がでるため待ちになります
BACKUP/RESTORE実行中はSUSPEND I/Oができません。
SQL01550N The SET WRITE SUSPEND command failed. (Reason code = n).
1. Database is not activated.
2. Database is in backup in progress state.
3. Database is in restore in progress state.
4. Database is already in suspended state.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 35-36 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
解説：SELECTが待ちになる例
バッファープールぺージの書き出しのためSELECTが待ちの例
BUFFERPOOL SIZE 10ページ
表 PERF (C1 INT,C2 INT,C3 CHAR(50) CHAR(50))
索引なし
表は304Page 10000行
db2start
db2 connect to azuma98
データベース接続情報
バップァープールの初期化
STATUS:
Read/Write
データベース・サーバー = DB2/NT 7.2.0
SQL 権限 ID
= AZUMA
ローカル・
データベース別名 = AZUMA98
db2 set write suspend for database
DB20000I SQL コマンドが正常に終了しました。
バップァープール内のページがすべてDirty
STATUS:
Write_SUSPEND
>db2 +c "update perf set c2=c2+1 where c1<305"
DB20000I SQL コマンドが正常に終了しました。
* where c1<305は10Page分の更新を意味する
ページの書き出しができない
>db2 +c "select * from test_source"---->待ち
STATUS:
Write_SUSPEND
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
意図したブランクページです。
( 37-38 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
Suspend I/O時異常終了後のクラッシュリカバリー
RESTART DATABASEコマンドに新しいオプション WRITE RESUMEが
追加
WRITE SUSPEND状態のままDBがDownした場合に使用する
SUSPEND_WRITE状態を解消し、Crash Recoveryを走らせる
WRITE SUSPEND状態でのDBダウン
==> db2 set write suspend for database
DB20000I The SET WRITE command completed successfully.
==> db2stop -kill
SQL1064N DB2STOP processing was successful.
==> db2start
SQL1063N DB2START processing was successful.
[db2v7@dbdcserv(Ja_JP)/work/activelog]
RESTARTの実行
==> db2 connect to v7db
SQL1552N The command failed because the database is currently in WRITE
SUSPEND state.
==> db2 restart database v7db
SQL1552N The command failed because the database is currently in WRITE
SUSPEND state.
==> db2 restart db v7db write resume
DB20000I The RESTART DATABASE command completed successfully.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Suspend I/O時異常終了後のクラッシュリカバリー
RESTART DATABASEコマンドに新しいオプション WRITE RESUMEが追加されました。このオプションは、WRITE SUSPEND状態のまま
DBがDownした場合に使用します。このオプションがWRITE SUSPENDのままDOWNしたDBのRESTARTで指定されると、
SUSPEND_WRITE状態は解消され、Crash Recoveryが走ります。
以下の例では、SUSPEND WRITE状態のDBを強制的にDOWNさせ、RESTART DBを使って再始動しています。
==> db2 set write suspend for database
DB20000I The SET WRITE command completed successfully.
==> db2stop -kill
SQL1064N DB2STOP processing was successful.
==> db2start
SQL1063N DB2START processing was successful.
[db2v7@dbdcserv(Ja_JP)/work/activelog]
==> db2 connect to v7db
SQL1552N The command failed because the database is currently in WRITE
SUSPEND state.
==> db2 restart database v7db
SQL1552N The command failed because the database is currently in WRITE
SUSPEND state.
==> db2 restart db v7db write resume
DB20000I The RESTART DATABASE command completed successfully.
以下はWRITE RESUMEを指定しなかった場合のDB2DIAG.LOG出力です。
2001-05-24-22.46.52.932221 Instance:udb32v7 Node:000
PID:9552(db2agent (TESTDB2)) Appid:*LOCAL.udb32v7.010524134632
buffer_pool_services sqlbStartPools Probe:22 Database:TESTDB2
Tablespace SYSCATSPACE (0) is in state x10000.
StartPool is not possible. rc=ffff 81f3
~~.
String Title:sqlbStartPools PID:9552 Node:000
The database cannot be recovered because tablespaces cannot be put on-line
To restart the database please specify "WRITE RESUME" option.
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 39-40 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
スプリット・イメージからのバックアップ （V 7.2）
スプリット･イメージからのバックアップの取得
スプリット･イメージ（
ROLLFORWARD保留状態のデータベース）
に対し、DBのフルバックアッ
プ取得が可能
V7.2の時点では、DMS表スペースのみで作られたDBのフルバックアッ
プのみサポート
db2inidbの実行後にのみDBのバックアップ取得可能
一度でもROLLFORWARDを実行してしまうと、COMPLETEまたはSTOPオプションでの
ROLLFORWARDを実行しない限り、BACKUPの取得はできない。
SMS表スペースを含むバックアップは失敗する
Onlineバックアップは不可
スプリット・
イメージはロールフォワード保留状態なので、そもそもONLINEは有り得ない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：スプリット・イメージからのバックアップ （V 7.2）
通常はROLLFORWARD保留状態のDBや表スペースのバックアップを取ることはできません。しかし、V7.2より、Split Mirrorイメージが
db2inidbコマンドによってROLLFORWARD保留状態になっているものについては、DBのフルバックアップが取得できるようになりました。
V7.2の時点では、DMS表スペースのみで作られたDBのフルバックアップのみサポートされます。
SMS表スペースを含むバックアップは失敗します。
$ db2 backup database testdb to /dev/null
SQL1042C An unexpected system error occurred.
そのときのdb2diag.log
2001-05-24-22.23.38.337999 Instance:udb32v7 Node:000
PID:45318(db2agent (TESTDB)) Appid:*LOCAL.udb32v7.010524132140
database_utilities buildAppTblsp Probe:37 Database:TESTDB
Backing up of a split mirrored database containing SMS Tablespaces is unsupported
V7.2からサポートされるようになったのは、db2inidbコマンドによってROLLFORWARD保留状態となったDBのバックアップ取得です。です
から、例えばRESTORE DBが完了してROLLFORWARD保留状態となったいるDBのバックアップは取得できません。
db2inidbコマンドの実行後、PrimaryDBからのログをROLLFORWARD DBで適用した場合、STOPまたはCOMPLETEオプションを指定し
ないと、DBはROLLFORWARD保留のままです。このようなDBからのBackupも取得できません。一度ROLLFORWARDを実行してしまっ
たSPLIT MIRRORイメージの場合には、STOP/COMPLETEオプションでROLLFORWARD保留状態を解除したあとでなければBACKUP
の取得ができません。
Onlineバックアップは不可
スプリット・イメージはロールフォワード保留状態なので、そもそもONLINEは有り得ない
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 41-42 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
Split Mirrorシナリオ
Primary UDB
Secondary UDB
ESSクラスター１
ESSクラスター2
Data
PPRC
Data
FlashC
Data
FlashC
Data
LOG
PPRC
LOG
FlashC
LOG
FlashC
LOG
Volume Set A
Volume Set B
Volume Set C
ミラーからの
バックアップ
Volume Set D
Volume Set A： Primaryデータベース
Volume Set B： PPRCによって作成されたPrimaryデータベースのミラー
Volume Set C： Volume Set Bのローカル・フラッシュコピー（StandByデータベース）
Volume Set D： Volume Set Cのローカル・フラッシュコピー（バックアップデータベース）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：Split Mirrorシナリオ
初期状態
Primaryデータベース（Volume Set A）では通常の読み書きが行われています。アーカイブログは、PPRC接続により常にStandby側
（
VolumeSetB）
にミラーが取られるようにします。
SUSPEND WRITE
PrimaryデータベースでSET WRITE SUSPENDを発行し、書き込み禁止状態にします。一度書き込み禁止状態になると、すべての更
新トランザクション、またはReadOnlyであっても一時表を必要とするようなトランザクションはすべて待ち状態になります。
PPRCを用いた再同期化
PPRCを用いて、Primaryデータベースとそのミラー（
Volume Set B)の同期を取ります。PPRCは更新のあったDISK上のトラックをコ
ピーします。
RESUME WRITE
VolumeSetAとBの同期を取る処理が完了したら、直ちにSET WRITE RESUMEを実行し、書き込み禁止状態を解除します。
FLASH COPY
VolumeSet AとBの同期を取るPPRCの接続が完了したら、VolumeSetBからCへローカルフラッシュコピーを実行します。
VolumeSetCに対しては、STANDBYモードのdb2inidbコマンドを実行し、ロールフォワード保留状態にしておきます。
LOGのPPRC接続再開
フラッシュコピーの取得が完了したら、VolumeSetAとBの間のPPRC接続をRESYNCモードで再開し、Primaryデータベースの側で生
成された最新のログをセカンダリーサーバー側へ持ってきます。
Primaryデータベースの側で生成されたログを随時StandbyデータベースへROLLFORWARDによって適用し、必要なときに
ROLLFORWARDをCOMPLETEオプションで実行して、こちらのDBをアプリケーションに開放することができます。
ミラーの保管
Standyデータベースを直ちにAvailableにした場合、その時点でもはやPrimaryDBで生成されたログを適用することができなくなりま
す。その場合、こちらの例のようにもう一つミラーを作ることで、StandbyDBがサービス開始した後もPrimaryで生成されるログを適
用する先を確保できます。
安全のために必要であれば、作成されたSplit Mirrorのバックアップをテープなどのメディアに取ることもできます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 43-44 )
DB2 UDB (PC&Unix) V7.2
Online Split Mirror
今後の拡張
現在はWRITE SUSPEND/RESUMEはDB単位であるがTABLESPACE
単位に拡張予定
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
意図したブランクページです。
( 45-46 )