Comments
Description
Transcript
Online Split Mirror 内容
DB2 UDB 運用管理 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 運用管理 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 運用管理 Online Split Mirror ESS コピーサービス FlashCopy (Local) Peer-to-Peer Remote Copy (PPRC:対等リモート・コピー） 機能 瞬時にデータのコピーを取得する機能 ディスク･ボリューム単位でコピー AIXではhdisk単位 利点 バックアップ処理によるアプリケーション停止時間の大幅な削減 テスト・データの容易な作成 データの容易な複製（BIアプリケーションへの利用など） 起動 Ｗｅｂアプリケーションから起動 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 運用管理 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 運用管理 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 運用管理 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 運用管理 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 運用管理 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 運用管理 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 運用管理 Online Split Mirror STANDBY 常時プライマリーのデータベースからロールフォワード可能なStandby データベースをセカンダリーに作成する Data Data Active Log Archived Log DataBase Primary Archived Log Primaryからアーカイブログを 転送する DataBase 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 #define #define #define #define #define #define ARCHIVE_PATH "/work/" /* path must end with a slash */ RETRIEVE_PATH "/work/" /* path must end with a slash */ AUDIT_ACTIVE 1 /* enable audit trail logging */ ERROR_ACTIVE 1 /* enable error trail logging */ AUDIT_ERROR_PATH "/work/" /* path must end with a slash */ AUDIT_ERROR_ATTR "a" /* append to text file */ 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 運用管理 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 運用管理 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 運用管理 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 運用管理 Online Split Mirror MIRROR セカンダリーへコピーされたSplit Mirrorからプライマリーへコピーバック し、PrimaryDBのLOGからロールフォワード可能なデータベースを作成 する Data Data MirrorとしてCopy Backする前 に更新されてはいけない Active Log Archived Log Archived Log DataBase Secondary DataBase Primary 手順 １．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 運用管理 Online Split Mirror 解説： Mirrorの例（続き） Primary側にて接続があるにも関わらず、異常終了させる 別セッションにてdb2stop -kill [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 運用管理 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 運用管理 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 = = = = = Tablespace ID Name Type Contents State Detailed explanation: Write Suspended = = = = = 1 TEMPSPACE1 System managed space System Temporary 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 2 USERSPACE1 System managed space Any data 0x10000 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： WRITE SUSPEND時の表スペース状態 SET WRITE SUSPEND FOR DATABASE を実行すると、そのデータベースのすべての表スペースがwrite suspend状態（0x10000） となって書き込み不能となります。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 33-34 ) DB2 UDB 運用管理 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 2. Database 3. Database 4. Database is not activated. is in backup in progress state. is in restore in progress state. 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 運用管理 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 運用管理 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 運用管理 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 運用管理 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 Volume Volume Volume Set Set Set Set Volume Set B Volume Set C ミラーからの バックアップ Volume Set D A： Primaryデータベース B： PPRCによって作成されたPrimaryデータベースのミラー C： Volume Set Bのローカル・フラッシュコピー（StandByデータベース） 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 運用管理 Online Split Mirror 今後の拡張 現在はWRITE SUSPEND/RESUMEはDB単位であるがTABLESPACE 単位に拡張予定 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 意図したブランクページです。 ( 45-46 ) DB2 UDB 運用管理 Online Split Mirror 意図したブランクページです。 意図したブランクページです。 ( 47-48 )