Comments
Description
Transcript
DB2 UDB EEEにおける運用 DB2 UDB 運用管理
DB2 UDB 運用管理 DB2 UDB EEEにおける運用 DB2 UDB EEEにおける運用 お断り：当資料は、DB2 UDB V7.1（UNIX,PC) をベースに作成されています。 (一部、Fixpackに含まれるV7.2の機能についてもふれています。） ＜第２．００版＞２００１年１１月 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 内容 １．ロギング ２．データベース回復 ３．破損回復 ４．データの移動 ５．DB区画の再構成 ６．高可用性システムの構築 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 1-2 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 1. ロギング お断り：当資料は、DB2 UDB V7.1（UNIX,PC) をベースに作成されています。 (一部、Fixpackに含まれるV7.2の機能についてもふれています。） ＜第２．００版＞２００１年１１月 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 内容 1-1. DB2 UDB EEEにおけるログファイルの配置 1-2. DB2 UDB EEEにおけるログパスの変更 1-3. ログに関連するデータベース構成パラメーター 1-4．ユーザー出口プログラムによるログの保存 1-5．データ･レプリケーションを使用する場合の考慮点 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 3-4 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 1-1. EEEにおけるログファイルの配置 EEEでは、各データベース区画が独立してログファイルを持っている 各データベース区画での更新情報は、各データベース区画がローカルに持つログファイルに書 かれる。 データベース区画０ データベース区画１ Database Path Database Path $DBINSTANCE $DBINSTANCE NODE0000 NODE0001 SQL00001 SQL00001 SQLOGDIR SQLOGDIR S0000000.LOG S0000000.LOG S0000001.LOG S0000001.LOG S0000002.LOG S0000002.LOG (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：EEEにおけるログの配置 EEEでは、各データベース区画がそれぞれ独立してログファイルを持っています。ですから、各データベース区画での更新情 報は、それぞれのデータベース区画がローカルに持つログファイルに書かれることになります。 デフォルトのログパスは、データベースパスの下に作られます。もしインスタンス「db2inst1」において、データベースパ ス「/database」を指定してデータベースを作成した場合、データベース区画０におけるログファイル、データベース区画１ におけるログファイルの置かれるパスは以下のようになります。ここでSQL00001は、このデータベースがこのパスを指定し て作成された最初のデータベースであることを意味します。 データベース区画０： /database/db2inst1/NODE0000/SQL00001/SQLOGDIR データベース区画１： /database/db2inst1/NODE0001/SQL00001/SQLOGDIR (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 5-6 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 1-2. EEEにおけるログパスの変更 データベース構成パラメーター NEWLOGPATH デフォルトのログパスを変えたい場合、データベース構成パラメーター NEWLOGPATHを変 更する。 データベース区画０ データベース区画０ Database Path $DBINSTANCE db2 update db cfg for MYDB using newlogpath /logpath NODE0000 Database Path $DBINSTANCE NODE0000 SQL00001 /logpath NODE0000 SQL00001 S0000000.LOG S0000001.LOG SQLOGDIR SQLOGDIR S0000002.LOG S0000000.LOG S0000001.LOG S0000002.LOG (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：EEEにおけるログパスの変更 デフォルトのログパスは、データベースパスの下に作られますが、パフォーマンスや対障害性の向上のために通常は別の場 所にログを配置します。ログファイルの置かれる場所を変更するためには、データベース構成パラメーターのNEWLOGPATHを 変更します。このとき、新しく指定されたログパスの下には、データベース区画の番号に基づいたサブディレクトリーが自 動的に作成され、その下にログファイルが置かれます。これは、複数のデータベース区画が同じサーバー上に定義されてい た場合に、それぞれのデータベース区画が同じディレクトリーにログファイルを配置してしまうのを防ぐためです。 指定した新しいログパスへ切り替えるためには、一度すべてのアプリケーションが対象のデータベースから切り離されなく てはなりません。一度すべてのアプリケーションが切断された後、次に最初のアプリケーションがこのデータベースに接続 した時点で、新しいログパスへログファイルが作成されます。 以下の例では、データベースMYDBの新しいログパスとして、/logpathを設定します。 db2 update db cfg for MYDB using newlogpath /logpath DB2 UDB EEEでは、データベース構成パラメーターは、各データベース区画ごとにそれぞれ設定します。ですから、DB2 UDB EEEの全データベース区画でのログパスを変更したい場合、UPDATE DB CFGコマンドを全てのデータベース区画で発行する必 要があります。 以下の例では、db2_allとupdate db cfgコマンドとの組み合わせにより、データベースMYDBの全データベース区画の新しい ログパスを/logpathにしています。db2_allを使うと、任意のデータベース区画に対するコマンドの発行ができます。 db2_all "; db2 update db cfg for MYDB using newlogpath /logpath" 次の３つの例では、データベース区画１のログパスを/logpathに変更しています。 （例1）db2_all "<<+1<; db2 update db cfg for MYDB using newlogpath /logpath" （例2）export DB2NODE=1 db2 update db cfg for MYDB using newlogpath /logpath （例3）db2 set client attach_node 1 db2 update db cfg for MYDB using newlogpath /logpath (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 7-8 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 1-3. ログに関連する構成パラメーター データベース構成パラメーターは、各データベース区画ごとに設定 ログバッファーのサイズ（LOGBUFSZ） 一次ログファイルの数（LOGPRIMARY） 二次ログファイルの数（LOGSECOND） ログファイルの大きさ（LOGFILSIZ） ログを保持するかどうか（LOGRETAIN） ユーザー出口プログラムを使って、ログファイルのアーカイブを行うか（USEREXIT) 各パラメーター値は、各データベース区画で違うものを指定可能 基本的には同じ値を指定すべき。 データの配置やデータ更新の発生にノード間で偏りがあるようなケースでは違う大きさを 指定することも考慮。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：ログに関連する構成パラメーター 既に説明したNEWLOGPATHも含め、データベース構成パラメーターは、各データベース区画ごとに設定します。ログに関連す るデータベース構成パラメーターには以下のものがありますが、いずれも各データベース区画ごとに値の設定がなされま す。 ログバッファーのサイズ（LOGBUFSZ） 一次ログファイルの数（LOGPRIMARY） 二次ログファイルの数（LOGSECOND） ログファイルの大きさ（LOGFILSIZ） ログを保持するかどうか（LOGRETAIN) ユーザー出口プログラムの使用（USEREXIT) これら各パラメーターの値は、原則としては同じ値を指定すべきです。ただし、データの配置やデータ更新の発生にノード 間で偏りがあるようなケースでは違う大きさを指定することも考えられます。 以下の例では、全てのデータベース区画におけるLOGBUFSZ,LOGPRIMARY，LOGSECOND，LOGFILSIZの各パラメーターの値を更新 しています。 db2_all "; db2 update db cfg for MYDB using logbufsz 10 logprimary 15 logsecond 15 logfilsiz 1000" (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 9-10 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 1-4. ユーザー出口プログラムによるログの保存 ユーザー出口プログラムは各データベース区画で独立してコールさ れる 「USEREXIT=ON」は各データベース区画で設定しなければならない。 サンプルプログラムとして提供されているユーザー出口プログラムを修正、コンパイル し、「$HOME/sqllib」ディレクトリの下のサブディレクトリー「adm」に置く。 EEEでは＄HOMEはNFSにより、各データベース区画で共有されている。 各データベース区画は、このユーザー出口プログラムをコールすることで、ログファイルのコピーを行う。 ログファイルのアーカイブ先のパスは、きちんとデータベース区画番号を含んだ形で事前 に作成しておくこと ユーザー出口プログラムの修正 #define ARCHIVE_PATH "/ArchivePath/" この場合にデータベース区画０から３にまたがるデータベース「SAMPLE」のために用意しておくディレクトリー データベース区画０ /ArchivePath/SAMPLE/NODE0000 データベース区画１ /ArchivePath/SAMPLE/NODE0001 データベース区画２ /ArchivePath/SAMPLE/NODE0002 データベース区画３ /ArchivePath/SAMPLE/NODE0003 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：ユーザー出口プログラムによるログの保存 既に説明したように、ログファイルは各データベース区画で独立して作成されます。従ってこれらのログファイルを保存す るユーザー出口プログラムもDB2によって各データベース区画で独立して実行されます。 各データベース区画でユーザー出口プログラムが呼ばれるタイミングは、Enterprise EditionやWorkgroup Editionといった 非区画化DBを使った場合と同様、ある一つのログファイルが一杯になったとき、あるいはデータベースへのすべての接続が クローズされたときです。当然、各データベース区画毎に発生する更新の量が均一とは限らないので、結果的にユーザー出 口プログラムが呼び出されるタイミングも、データベース区画毎にばらばらになりえます。 EEEの環境でユーザー出口プログラムを使用する場合には、以下の点に注意してください。 「USEREXIT=ON」は各データベース区画で設定すべきである。 サンプルプログラムとして提供されているユーザー出口プログラムを修正、コンパイルし、「$HOME/sqllib」ディレクト リの下のサブディレクトリー「adm」に置くこと。 EEEでは＄HOMEはNFSにより、各データベース区画で共有されている。 各データベース区画は、このユーザー出口プログラムをコールすることで、ログファイルのコピーを行う。 「$HOME/sqllib/bin」にはユーザー出口プログラムを置かないこと。「$HOME/sqllib/bin」は実際には 「/usr/lpp/db2_07_01/bin」へのシンボリック・リンクなので、もし＄HOME/sqllib/binにユーザー出口プログラム を置いてしまうと、他のマシン上のデータベース区画からこのユーザー出口プログラムが見えなくなってしまう。 ログファイルのアーカイブ先のパスは、きちんとデータベース区画番号を含んだ形で事前に各マシン上に作成しておくこ と 例えば、ユーザー出口プログラムを以下のように修正したとします。 #define ARCHIVE_PATH "/ArchivePath/" この場合にデータベース区画０から３にまたがるデータベース「SAMPLE」のために用意しておくディレクトリーは以 下のようになります。 データベース区画０ /ArchivePath/SAMPLE/NODE0000 データベース区画１ /ArchivePath/SAMPLE/NODE000 1 データベース区画２ /ArchivePath/SAMPLE/NODE0002 データベース区画３ /ArchivePath/SAMPLE/NODE0003 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 11-12 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 1-5. データ･レプリケーションを使用する場合の考慮点 EEEがレプリケーション・ソースとなる場合 レプリケーションのソースとなる表は、カタログ区画だけからなる、シングル区画のノー ドグループ上に定義された表でなければならない。 それ以外の表にDATA CAPTURE CHANGES属性をつけようとすると、SQL0270（理由コード４）が返される。 CAPTUREコンポーネントは、複数データベース区画のログをマージする機能がない。 カタログノードでは、データベース構成パラメーター「LOGRETAIN＝RECOVERY」または 「LOGRETAIN=CAPTURE」が設定されている必要がある。 EEEがレプリケーション・ターゲットとなる場合 APPLYコンポーネントはどこか一箇所で稼動していれば良い ターゲット表のキーに対応する列の更新の場合、更新のかわりに削除/挿入を実行させる こと DB2 UDB V7.1+FixPak1より使用可能な、区分キーの更新を可能にするオプション 「db2set=DB2_UPDATE_PART_KEY=ON」を設定していてもこの点は変わらない。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：データレプリケーションを使用する場合の考慮点 DB2 UDB EEEがレプリケーション･ソースとなる場合 EEEにおいて、ある表が複数データベース区画にまたがっていた場合、その表に対する更新は、それぞれの更新が発生し たデータベース区画内のログファイルに記録されます。もし、このような表をデータレプリケーションのソースとして使 おうとしたとすると、データ･レプリケーションのCAPTUREコンポーネントは、各データベース区画のログからこの表に対 する更新情報を抽出したうえでマージし、それをステージング表へ出力しなくてはなりません。しかしながら現行の CAPTUREコンポーネントは、ログをマージするような機能が備わっていないため、EEEを使っていた場合、レプリケーショ ンのソースとなる表は、カタログ区画だけからなるシングル区画のノードグループ上に定義された表（すべての行がカタ ログノード上に存在するような表）でなければなりません。もし、それ以外の表にDATA CAPTURE CHANGES属性をつけよう とすると、SQL0270（理由コード４）が返されます。 $ db2 alter table employee data capture changes DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、SQL ステートメントとして処理されました。 SQL 処理中に、そのコマンドが返されました。 SQL0270N 関数をサポートしていません (理由コード = "4")。 SQLSTATE=42997 CAPTUREコンポーネントがレプリケーション･ソースとなる表への更新を取得できるよう、カタログノードでは、データ ベース構成パラメーター「LOGRETAIN＝RECOVERY」または「LOGRETAIN=CAPTURE」が設定されている必要があります。 DB2 UDB EEEがレプリケーション･ターゲットとなる場合 DB2 UDB EEEを使っていたとしても、APPLYコンポーネントはどこか一箇所で稼動していれば結構です。APPLYコンポーネ ントは、DB2 UDB EEEサーバー上のどこかひとつのデータベース区画に接続し、レプリケーション・ソースからの変更 データを反映します。この接続されたデータベース区画がコーディネーターとなり、必要であれば他のデータベース区画 へ変更データを伝播します。 もし、ターゲット表の一次キーに対応する列の更新がソース表の側でなされた場合、ターゲットである、EEEの側では更 新のかわりに削除/挿入を実行させて下さい。 これは、DB2 UDB V7.1+FixPak1より使用可能な、区分キーの更新を可能にするオプション 「db2set DB2_UPDATE_PART_KEY=ON」 を設定していても同じです。なぜなら依然として一次キーや固有索引のキーは 区分キーのスーパーセットでなければならないからです。EEEである、ないに関わらず、ターゲット表の一次キーへ の更新は、削除/挿入という形で取り込まれなくていけません。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 13-14 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2. データベース回復 お断り：当資料は、DB2 UDB V7.1（UNIX,PC) をベースに作成されています。 (一部、Fixpackに含まれるV7.2の機能についてもふれています。） ＜第２．００版＞２００１年１１月 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 内容 ２-１．バックアップの取得 ２-２．BACKUP DATABASEコマンドの実行 ２-３．オンライン V.S. オフライン ２-４．バックアップ・ファイル ２-５．リストア ２-６．RESTORE DATABASEコマンドの実行 ２-７．表スペース単位のBackup/Restoreの考慮点 ２-８．ロールフォワード保留状態 ２-９．ロールフォワード-どこまで？ ２-１０．回復履歴ファイル ２-１１．リカバリーの例 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 15-16 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-1. バックアップの取得 BACKUP DATABASE DSS DSS ディスク -orテープ SYSADM SYSCTRL SYSMAINT Backup Buffer -orTSM (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：バックアップの取得 DB2 UDB EEEではデータベース全体のバックアップを行いたいと思った場合、全てのデータベース区画でバックアップを行 う必要があります。更に、最初にカタログ区画（このデータベース作成のためのCREATE DATABASEコマンドが発行された区 画）のバックアップを他のパーティションのバックアップとは別に取得する必要があります。これが終了した後は、他の パーティションのバックアップを並行に取得するできます。 （ただし、オンライン・バックアップの時はカタログ・パーティションのバックアップ取得も並行して実行できます。） その他の考慮点は以下の通りです。 BACKUPコマンドを実行するためには、SYSADM,SYSCTRL,SYSMAINTの権限が必要です。 データベースや表スペースのバックアップは、ディレクトリ，テープ，Tivoli Storage Manager（TSM）の管理するス トレージなどに保管することが出来ます。TSMを使用するとデータベース・サーバーが存在するマシン以外のストレー ジに保管することもできます。 BACKUPコマンドのBUFFERオプションを指定しなかった場合、データベース・マネージャー構成パラメータのBACKBUFSZ に指定された値がバッファーのサイズとして使用されます。 データベース構成パラメータのLOGRETAINまたはUSEREXITを変更して、ロールフォワード可能にした時には必ず データベースを使用する前にデータベースのオフライン・バックアップを取る必要があります。 異なった表スペースのバックアップとリストアーが同時に必要となった場合、同一パーティション上で同時にバック アップとリストアーを行うことはできません。 複数の表スペースに別れている表が存在する場合には、それらの表スペースをまとめてバックアップまたはリストアー するようにします。 例えば、DMS表スペースを使って索引やLONGデータをその他のデータとは別の表スペースに配置する場合など (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 17-18 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-2. BACKUP DATABASE コマンドの実行 BACKUP DATABASEコマンドは各データベース区画で実行する BACKUP DATABASEコマンドが実行されるデータベース区画を指定す る方法にはいくつかある。 方法１：環境変数DB2NODEを使う方法 export DB2NODE=1 db2 BACKUP DATABASE sample TO /DBBK 方法２：SET CLIENTコマンドを使う方法 db2 SET CLIENT CONNECT_NODE 1 db2 BACKUP DATABASE sample TO /DBBK 方法３：db2_allを使う方法 db2_all "<<+1< db2 BACKUP DATABASE sample TO /DBBK" その他の考慮点は非EEE環境と同じ データベースマネージャーは起動していなければならない、など (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：BACKUP DATABASEコマンドの実行 BACKUP DATABASEコマンドは各データベース区画で実行されなくてはなりません。どのデータベース区画のバックアップを取得するのかを BACKUP DATABASEコマンドに示す方法にはいくつかあります。例えば、Sampleデータベースのデータベース区画１の部分のフルバックアップ をディレクトリー/DBBKに取得したい場合： 方法１：環境変数DB2NODEを使う方法 export DB2NODE=1 db2 BACKUP DATABASE sample TO /DBBK 方法２：SET CLIENTコマンドを使う方法 db2 SET CLIENT CONNECT_NODE 1 db2 BACKUP DATABASE sample TO /DBBK 方法３：db2_allを使う方法 db2_all "<<+1< db2 BACKUP DATABASE sample TO /DBBK" といった方法が考えられます。特に3番目の方法は複数のデータベース区画のバックアップを同時に取得したい場合に便利です。既に説明した ように、オフラインバックアップの取得の場合には、まずカタログ区画のバックアップを取ってから、残りの区画のバックアップ取得を行い ますので、例えばカタログ区画が０番だったとすると、db2_allを使って以下の例のようにしてバックアップを取得できます。 db2_all "<<+0< db2 BACKUP DATABASE sample TO /DBBK" db2_all "<<-0<; db2 BACKUP DATABASE sample TO /DBBK" 一番目ではカタログ区画であるデータベース区画０番のバックアップ取得、2番目では、その他の区画のバックアップ取得が行われます。この 例のようにセミコロン「；」をつけた場合、指定されたコマンドが各区画で平行に実行されます。セミコロンの指定が無かった場合には、 ノード構成ファイル「db2nodes.cfg」に定義された順番で各区画毎に順番にコマンドの実行がなされます。 その他の考慮点は非EEE環境と同様、以下のようなものがあります。 BACKUPコマンドまたはAPIを使用する前にはデータベースは起動（db2start)している必要があります。 BACKUPコマンドまたはAPIを使用する場合、データベース別名を明示的に指定する必要があります。 表スペースのバックアップは、１つまたは複数の表スペースを指定することができます。 各区画のバックアップ取得をさらに並列に実行できます（PARALLELISMオプション）。並列バックアップの効果を得るために、複数の出力 先（ディレクトリ，テープデバイス）を使用できます。 バックアップ中、バックアップされたデータは内部のバッファーに入れられます。このバッファーがいっぱいになるとそのデータはバッ クアップ・メディアにコピーされます。バックアップのパフォーマンスを向上させるために複数のバッファーとI/Oストリームを使用する ことができます。バッファーの数は、使用しているディスクの数より大きく設定します。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 19-20 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 解説：BACKUP DATABASEコマンドの実行（続き） BACKUPコマンドでバッファーのサイズをページ単位で指定することができます。指定しなかった場合には、 データベース・マネージャー構成パラメータのBACKBUFSZの値が使用されます。バッファーをアロケーションするの に十分な使用可能メモリーが無い場合にはエラーが返されます。理想的なバッファーのサイズは、表スペースのエク ステント・サイズの倍数です。 PARALLELISMは、バックアップ中に作成されるバッファー・マニピュレーターの数を指定します。 データベース中のいくつかの表スペースが異常な状態にある場合、データベースのバックアップは行うことは出来ま せん。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 意図的なブランクページです。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 21-22 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-3. オフライン vs. オンライン オフライン・バックアップ バックアップ中は、他のユーザは接続できない カタログ区画と他の区画は並行してバックアップ出来ない バージョン回復とロールフォワード回復をサポート オンライン･バックアップ バックアップ中も、他のユーザも接続可能 カタログ区画と他の区画のバックアップ取得を平行に実行できる アーカイブ・ログ使用時のみ取得可能 ロールフォワード回復のみサポート BACKUP DATABASE ONLINE update select アクセス中 ﾃﾞｰﾀﾍﾞｰｽ connect (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：オフライン vs. オンライン EEE環境でバックアップを取得する場合にも、オフラインとオンラインの2種類のバックアップ･モードの選択ができま す。 オフライン・バックアップ オフライン・バックアップを行う場合、他のユーザはデータベース区画に接続することは出来ません。格納されてい るデータは整合性のとれた状態にあり、バージョン回復またはロールフォワード回復（アーカイブ・ログ使用時の み）に使用することが出来ます。 「アーカイブ･ログ使用」とは、データベース構成パラメータのLOGRETAIN=RECOVERY、またはUSEREXIT=ONを指定 することによって、アーカイブ･ログが保管されているような環境のことを示します。 循環ログ使用時には、オフライン・バックアップのみがサポートされています。 カタログ区画とカタログ以外の区画は、オフライン・バックアップでは同時にBACKUP DATABASEコマンドの実行が出来 ません。これは、カタログ区画のオフライン・バックアップを行うとカタログ区画に排他接続が行われてしまうが、 他の区画のバックアップを行うためにはカタログ区画への内部的な接続が必要となるためです。 オンライン・バックアップ オンライン・バックアップを行う場合、他のアプリケーションやプロセスはバックアップ中でもデータベースへの 接続が可能です。 オンライン・バックアップは、アーカイブ・ログを使用している場合にのみ使用できます。 オンライン・バックアップのファイルをリストアーした時点では、それらのデータはロールフォワードを行うまで整 合性が取れていない状態のためデータベースに接続できません。従ってロールフォワード回復が必須となります。 注意！ オフライン・バックアップを用いたバージョン回復を行う場合、各DB区画のバックアップは同期の取れたものでなけれ ばなりません。言い換えると、各DB区画のバックアップを取得する場合、最初にカタログ区画のバックアップを取得し てから、すべての区画のバックアップ取得が完了するまで、DBへは一切の更新が入ってはいけません。さもないと将来 バックアップからDBのバージョン回復を行ったとき、区画間の同期が取れていないためにDBは使用不能になってしまい ます。このことは特に循環ロギングの時に重要です。循環ロギングでは、バージョン回復のみ可能であり、ロールフォ ワード回復ができないからです。 予期せずにユーザーからのDB更新が入ってしまわないよう、バージョン回復を行う可能性がある環境では、DBのバック アップ取得時には、ユーザーからの接続ができないように接続権限をREVOKEしておく、または普段はユーザー側にはDB のALIASを見せておき、バックアップ取得時にはこれをアンカタログする、といった方策を講じる必要があります。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 23-24 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-4. バックアップ・ファイル ディスクに作成されるバックアップ・ファイルの名前： データベース別名 バックアップのタイプ インスタンス名 データベース区画の番号 カタログ区画の番号 バックアップのタイム・スタンプ 順序番号 テープにバックアップした場合にはファイル名は作成されない しかし、同様の情報がバックアップ・ヘッダーに保管される。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：バックアップ・ファイル inst00インスタンスにあるDSSデータベースを1999.11.1の13:12:59にバックアップした場合には以下のようなファイル名 になります． 別名 ￨ インスタンス ￨ カタログ ￨ 年 ￨ 月 日 分 秒 ￨ ￨ ￨ ￨ DSS.0.inst00.NODE0000.CATN0000.19991101131259.001 ￨ タイプ ￨ パーティション ￨ 時間 ￨ 順序番号 タイプは、 0 : データベース・パーティションのバックアップ 3 : データベース・パーティション内の表スペースのバックアップ 4 : 表のロード時のコピー を示します。 テープにバックアップする場合には、ファイル名は作成されませんがファイル名に示される情報と同一のものがバック アップ・ヘッダーに保管されています。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 25-26 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-5. リストアー - パーティション単位 RESTORE DATABASE DSS DSS ディスク -orSYSADM SYSCTRL SYSMAINT(*) テープ Restore Buffer -orADSM (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：リストアー - パーティション単位 リストアーを行う場合には以下の点を考慮して下さい。 データベースや表スペースのバックアップから既存のデータベースにリストアーを行うためにはSYSADM,SYSCTRL, SYSMAINT権限の内のどれか1つが最低必要です。 SYSMAIN権限では、新規のデータベースへのリストアーは出来ません。 リストアーする対象として、回復履歴ファイルのみ、１つまたは複数の表スペース、全てのバックアップ・イメージ を選択することが出来ます。 RESTOREコマンドは、Tivoli Storage Manager（TSM)を利用することが出来ます。 データベース区画のリストアーは、排他接続を要求します。そのためアプリケーションはリストアー中の区画上では 稼動することは出来ません。なお、カタログ区画とそれ以外の区画は同時にリストア処理が可能です。（非カタログ 区画のリストアがカタログ区画へ内部的に接続するようなことはありません） 表スペースのリストアーには、オンライン（share mode）とオフライン（exclusive mode）があります。オンライ ン・リストアーは他の表スペースへのアクセスは認めます。しかし、リストアー中の表スペースに関してはコマンド が終了するまで排他制御が行われます。 バッファーのサイズと数は、RESTOREコマンドのオプションとして明示的に指定することが出来ます。もし、明示的に バッファーのサイズを指定しなかった場合には、データベース・マネージャー構成パラメータのRESTBUFSZの値が使用 されます。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 27-28 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-6. RESTORE DATABASE コマンドの実行 RESTORE DATABASEコマンドは各データベース区画で実行する RESTORE DATABASEコマンドが実行されるデータベース区画を指定 する方法にはいくつかある。 方法１：環境変数DB2NODEを使う方法 export DB2NODE=1 db2 RESTORE DATABASE sample FROM /DBBK 方法２：SET CLIENTコマンドを使う方法 db2 SET CLIENT CONNECT_NODE 1 db2 RESTORE DATABASE sample FROM /DBBK 方法３：db2_allを使う方法 db2_all "<<+1< db2 RESTORE DATABASE sample FROM /DBBK" その他の考慮点は非EEE環境と同じ データベースマネージャーは起動していなければならない、など (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：RESTORE DATABASEコマンドの実行 RESTORE DATABASEコマンドも各データベース区画で実行されなくてはなりません。どのデータベース区画のリストアを実 行するのかをRESTORE DATABASEコマンドに示す方法にはいくつかあります。例えば、Sampleデータベースのデータベース 区画１の部分のリストアをディレクトリー/DBBKに取得したイメージから実行する場合： 方法１：環境変数DB2NODEを使う方法 export DB2NODE=1 db2 RESTORE DATABASE sample FROM /DBBK 方法２：SET CLIENTコマンドを使う方法 db2 SET CLIENT CONNECT_NODE 1 db2 RESTORE DATABASE sample FROM /DBBK 方法３：db2_allを使う方法 db2_all "<<+1< db2 RESTORE DATABASE sample FROM /DBBK" といった方法が考えられます。特に3番目の方法は複数のデータベース区画のリストアを同時に実行したい場合に便利で す。例えばカタログ区画が０番だったとすると、db2_allを使って以下の例のようにしてリストアを実行できます。 db2_all "<<+0< db2 RESTORE DATABASE sample FROM /DBBK" db2_all "<<-0<; db2 RESTORE DATABASE sample FROM /DBBK" 一番目ではカタログ区画であるデータベース区画０番のリストア実行、2番目では、その他の区画のリストアが実行され ます。 RESTORE DATABASEコマンドを実行する上でのその他の考慮点は非EEE環境と同様です。 データベースをリストアーする前には、データベース・マネージャーが起動している必要があります。 リダイレクト･リストアー（RESTORE.....REDIRECT)を実行する事が出来ます。このコマンドの後にSET TABLESPACE CONTAINERSコマンドを実行して新しいコンテナーの情報を定義します。次にCONTINUEオプションを指定してRESTORE コマンド（RESTORE.....CONTINUE)を実行してデータベースのリストアーを続けます。 これにより、BACKUPしたデータベースで定義されていた表スペースの作成場所を変更することが出来ます。 既存のデータベースに対してリストアーする場合には、REPLACE EXISTINGオプションを付けることでデータベースを 上書きする前にでる警告メッセージを回避することが出来ます。 回復履歴ファイルが削除されていたり破壊されている場合には、バックアップ・イメージから履歴ファイルのみを リストアーすることが出来ます。（HISTORY FILE) (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 29-30 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 解説：RESTORE DATABASEコマンドの実行（続き） リストアーのパフォーマンスを向上させるために複数のバッファーを使用することが出来ます。バッファーはバック アップ・メディアからのデータで満たされます。バッファーの数は、使用しているI/Oデバイスの数より多く設定して 下さい。バッファーのサイズは、明示的に指定しない場合データベース・マネージャー構成パラメーターRESTBUFSZ の値が使用されます。もしバッファーをアロケーションするのに十分な使用可能メモリーが無い場合には エラーが返 されます。 PARALLELISMオプションは、リストアー処理中に作成されるバッファー・マニピュレータの数を指定します。 リストアーで使用するデータベース区画または表スペースのバックアップは、ディレクトリー，テープ， TSMに管理 された場所に保管しておくことが出来ます。 RESTOREコマンドをデータベース区画の回復のために実行した場合、リストアーが正常に終了するまで その区画は使用することは出来ません。 RESTOREコマンドを表スペースの回復のために実行した場合、リストアーおよびロールフォワードが正常に終了する までその表スペースは使用できません。 リストアー中にシステム障害などが発生した場合には、再度RESTOREコマンドを実行し正常終了するまでそのデータ ベース区画は使用できません。 データベース区画や表スペースのバックアップから特定の表スペースのリストアーをすることが可能です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 意図的なブランクページです。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 31-32 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-7. 表スペース単位のBackup/Restoreの考慮点 ロールフォワードを行うことが必須 バックアップからいくつかの表スペースのみのリストアーが可能 Long／LOB データ用の表スペースの使用 カタログ表スペースの回復 重要な表の回復 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：表スペース単位のBackup/Restoreの考慮点 表スペース単位のバックアップおよびリストアーを行うためには、アーカイブ・ログの使用が必須となります。 その表スペースが作成されているノードグループ内の一部の区画のみで表スペースのリストアーを行う場合には、End of Log指定でのロールフォワードが必須となります。しかし、ノードグループ内の全ての区画で表スペースのリストアーを 行う場合には、Point-In-Timeリカバリーが可能です。表スペースに対してPoint-In-Timeリカバリーを実行すると、ロー ルフォワード終了後その表スペースはバックアップ保留状態となります。そのため、バックアップを取るまでその表ス ペースは使用できません。 データベース区画または表スペースのバックアップから、特定の表スペースのリストアーを行うことが出来ます。 表スペース単位のバックアップ/リストアーにより、より変更頻度の高い表スペースのバックアップを頻繁に取得する、 ある表が壊れた場合にその表が属する表スペースのリカバリーだけを行う、といった運用を可能にします。当然、データ ベース全体のバックアップを取得するよりも、一部の表スペースだけのバックアップを取得する方が、より短時間でバッ クアップは完了します。 LONGデータやLOBデータを別の表スペースに格納している場合、これらの表スペースは同時にリストアーしロールフォ ワードする必要があります。 表スペース単位のリカバリーが可能であると、カタログ表スペースの障害時に回復時間を短縮することが出来ます。 重要な表や、更新が頻繁に行われる表を１つの表スペースに格納しておくと障害時に回復時間を短縮することが出来ま す。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 33-34 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-8. ロールフォワード保留状態 以下の場合にロールフォワード保留状態になります アーカイブ・ロギングの環境で、"WITHOUT ROLLING FORWARD"オプションを指定しない でオフライン・データベースのバックアップをリストアーした場合 オンライン・バックアップをリストアーした場合. 表スペース単位のリストアーをした場合 DB2が表スペースのメディア・エラーを見つけた場合 DB2によって管理される保留状態 データベースの保留状態は、データベースに対する処理が出来ない 表スペースの保留状態は、他の表スペースへの処理は可能 ロールフォワード保留状態から抜け出すためには、ROLLFORWARD DATABASEコマンドの実行が必要 カタログ区画からROLLFORWARD DATABASEを実行します。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：ロールフォワード保留状態 EEE環境では、ROLLFORWARD DATABASEコマンドは、カタログ区画からのみ実行する事が出来、全てのロールフォワード保 留状態の区画に影響します。 ロールフォワードを必要とするデータベースは、全てのパーティションでデータベース・マネージャー構成パラメータの LOGRETAINまたはUSEREXITまたはその両方が設定されている必要があります。 ロールフォワード保留状態はデータベースの整合性を守るためにDB2が使用するステータスです。このステータスは、 データベースの整合性を確実な物とするためにロールフォワードが必要なことを示しています。 ロールフォワード保留状態は、データベースまたは表スペース単位に設定されます。 データベースがロールフォワード保留状態の場合、データベースに対する全ての処理が出来ません。表スペースがロール フォワード保留状態の場合には、他の表スペースに対する処理は行うことが出来ます。 以下のような場合にデータベースがロールフォワード保留状態になります。 ・オフライン・データベースのバックアップを、WITHOUT ROLLING FORWARDオプション無しにリストアーした場合 ・オンライン・データベースのバックアップをリストアーした場合 以下のような場合に表スペースがロールフォワード保留状態になります。 ・表スペースのリストアーをした場合 ・DB2がメディア・エラーを検知した場合に、その障害の発生している表スペース ROLLFORWARDコマンドを実行するためには、SYSADM,SYSCTRL,SYSMAINT権限が必要となります。 DB2 UDB EEEではROLLFORWARDコマンドはカタログ・ノードからしか発行できません。 ロールフォワードは、データベースのログ・ファイルからトランザクション・レコードを適用します。 ロールフォワードを実行した時に、データベースがロールフォワード保留状態であればデータベースのロールフォワード を行います。データベースがロールフォワード保留状態に無い場合には、ロールフォワード保留状態の表スペースに対し てロールフォワードを行います。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 35-36 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-9. ロールフォワード- どこまで? End of Logs 最新状態へのリカバリー 障害発生区画のみのRESTOREで回復ができる Point in time Coordinated Universal Time（CUT）を指定する 日本の時刻-9時間 フォーマット: yyyy-mm-dd-hh.mm.ss.nnnnnn リカバリー対象のDBまたは表スペースの全区画でRESTOREが必要 オンライン バックアップ バックアップの終了までのロールフォワードは必須 表スペースの Point in time 最低限ロールフォワードが必要な時間は各表スペース単位に維持される ロールフォワード後にはバックアップが必須 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：ロールフォワード- どこまで？ データベース管理者は、ROLLFORWARDコマンドを実行する事によりロールフォワード保留状態を解消することが出来ま す。管理者は、ログの最後（End Of Logs）までロールフォワードを行うか、指定した時刻（Point In Time)までロール フォワードを行うか選択できます。 データベースの整合性は守られている必要があるため、オンライン・バックアップの終了した時刻までは最低限ロール フォワードする必要があります。 ある特定の区画でのみ障害が発生した場合、その区画のみデータベースバックアップからのリストアを行ったのち、END OF LOGSまでロールフォワードを行うことで回復ができます。バックアップ取得時点への回復（バージョン回復と呼ばれ る、ROLLFORWARDを行わない回復）をする場合やPoint-In-Timeへのロールフォワードを行う場合には、全区画での RESTORE（表スペースの場合にはその表スペースの定義されたノードグループの全区画）が必要です。 表スペースのPoint In Timeリカバリーは、複数の表間の参照制約を保証する必要があります。最低限ロールフォワード を行う必要がある時間は表スペース毎に保持しています。 isotimeを指定する場合、指定する時刻はCoordinated universal time（CUT)を指定します。 多くの場合、データベースを最新の状態に回復することを望みます。その場合にはEND OF LOGSオプションを指定しま す。 AND STOP / AND COMPLETEオプションを指定しないでロールフォワードを行うとデータベースはロールフォワード保留状 態のままです。表スペースを使用可能にするためにはAND STOPまたはAND COMPLETEを指定します。 表スペースのポイント・イン・タイム・リカバリーを行った場合、その表スペースはROLLFORWARD DATABASEコマンド完了 時にバックアップ保留状態になります。バックアップ保留状態の表スペースの表の参照は可能ですが、更新はできませ ん。この表スペースが更新可能になるためには、表スペースのバックアップを取得する必要があります。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 37-38 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-10. 回復履歴ファイル CREATE database BACKUP database or tablespace(s) RESTORE database or tablespace(s) LOAD table データベース区画 単位で作成される create 回復履歴 ファイル update update 回復履歴 ファイル 回復履歴 ファイル update 回復履歴 ファイル バックアップをした時間 バックアップを取った場所 最後にRestoreした時間 など db2 LIST HISTORY ALL FOR DSS (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：回復履歴ファイル 回復履歴ファイルは、データベースの回復に関する情報を履歴として記録しておくファイルです。ファイルは、データ ベース区画毎に作成され変更されます。データベース構成ファイルと同じディレクトリに格納されています。回復履歴 ファイルは次のような場合に更新されます。 データベースまたは表スペースのバックアップを行った時 データベースまたは表スペースのリストアーを行った時 ロールフォワードを行った時 表へのデータ・ロードを行った時 表の再編成を行った時 ALTER TABLESPACE操作を行った時 回復履歴ファイルは、データベース区画や表スペースの回復が必要な時に使用する要約されたバックアップ情報を提供し ます。このバックアップの情報としては次のようなものがあります。 バックアップ、ロード、ロードのコピーを行ったデータベース区画 いつ処理を行ったか バックアップやコピーの保管場所 表スペースのPoint-In-Timeリカバリーに関する情報 など 回復履歴ファイル内の情報は、LIST HISTORYコマンドで照会することができます。また、バックアップからRESTOREコマ ンドを使用して回復履歴ファイルを回復することができます。 回復履歴ファイル内のエントリーは、デフォルトでは366日間保管されます。この保管期間は、データベース構成パラ メータのREC_HIS_RETENTNを使用して変更することが出来ます。また、PRUNE HISTORYコマンドを使用して手動で古くなっ たエントリーを削除することも可能です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 39-40 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-11. リカバリー例 （例1） 循環ログ使用 ﾊﾟｰﾃｨｼｮﾝ 1 ﾊﾟｰﾃｨｼｮﾝ2 ﾊﾟｰﾃｨｼｮﾝ 3 TBS1 TBS1 TBS1 TBS2 TBS3 TBS3 あるパーティション の データベースが 破損した！ 回復に必要な 物 DBバックアップ DBバックアップ パーティション１ パーティション２ DBバックアップ パーティション３ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：リカバリー例 （例1） ここでは実際の障害発生のパターンとそれを回復する方法、手順にどんなものがあるかを見てゆきます。 この例は、循環ログを使っている環境でのデータベース区画障害に対する回復を示しています。循環ログの場合に可能な唯 一の回復手順はバージョン回復、すなわちオフラインバックアップ取得時点への回復です。この場合、各区画間で同期を取 るためには、障害を発生していない区画を含むすべての区画でデータベースのリストアを行います。リストアは、まずカタ ログ区画で実行しておき、その後で残りの区画で実行します。カタログ区画以外の区画のリストアは並行に実行可能です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 41-42 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-11. リカバリー例 （例２） 循環ログ使用 ﾊﾟｰﾃｨｼｮﾝ 1 ﾊﾟｰﾃｨｼｮﾝ2 ﾊﾟｰﾃｨｼｮﾝ 3 TBS1 TBS1 TBS1 TBS2 TBS3 TBS3 あるパーティション の １つの表スペースが 破損した！ 回復に必要な 物 DBバックアップ DBバックアップ パーティション１ パーティション２ DBバックアップ パーティション３ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：リカバリー例 （例２） この例もまた、循環ログを使っている環境での例です。このケースでは、あるデータベース区画における一つの表スペー スに対する障害に対する回復を示しています。 たとえ、障害があるひとつの表スペースにだけ発生した場合であっても、循環ログ方式を使用している場合には、フォ ワードリカバリーができませんので、やはり例１のときと同様、バージョン回復を行うしかありません。すなわち、障害 を発生していない区画を含むすべての区画でデータベースのリストアを行います。その結果、バックアップ取得時の状態 に戻せることになります。リストアは、まずカタログ区画で実行しておき、その後で残りの区画で実行します。カタログ 区画以外の区画のリストアは並行に実行可能です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 43-44 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-11. リカバリー例 （例３） アーカイブ・ログ使用 ﾊﾟｰﾃｨｼｮﾝ 1 ﾊﾟｰﾃｨｼｮﾝ2 ﾊﾟｰﾃｨｼｮﾝ 3 TBS1 TBS1 TBS1 TBS2 TBS3 TBS3 回復に必要な 物： バージョン回復 ロールフォワード回復 （ End Of Logs） あるパーティション の データベースが 破損した！ ロールフォワード回復 （ Point In Time） LOG LOG LOG LOG LOG LOG DBバックアップ パーティション１∼ ３ DBバックアップ パーティション２ バックアップ後の 全てのログ パーティション２ DBバックアップ パーティション１∼３ バックアップ後の 特定時刻までのログ パーティション１∼３ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：リカバリー例 （例３） ここでの例は、例１と同様にある一つのデータベース区画での障害が発生しています。ただし、例１と違う点は、アーカイ ブログ方式が使われている、という点です。 アーカイブログ方式が使われている、ということは、フォワードリカバリーが可能である、ということを意味します。すな わち、この例のような障害パターンでは、以下の3通りのリカバリー方法があります。 バージョン回復 例1の場合と同様にすべての区画でリストアをします。このとき、RESTOREコマンドにWITHOUT ROLLING FORWARDとつける ことで、RESTOREの完了後、即座にデータベースが使用可能になります。リストアは、まずカタログ区画で実行してお き、その後で残りの区画で実行します。カタログ区画以外の区画のリストアは並行に実行可能です。 ロールフォワード回復（End of Logs） ログの最後までロールフォワードする場合、障害の発生した区画のみのRESTOREの実行でリカバリーができます。 RESTORE DATABASEを障害の発生した区画で実行し、ROLLFORWARD DATABASEコマンドを「TO END OF LOGS」オプション付で カタログ区分で実行します。 ROLLFORWARDコマンドのON NODEオプションで、どの区画でROLLFORWARDが実行されるべきか指定できます。ON NODEオプ ションを指定しなかった場合、DB2はロールフォワードが必要なすべての区画でフォワードリカバリーを実行します。 この例では、フォワードリカバリーは区画２で走ります。ですから、このリカバリーには、区画２上における、バック アップ取得後のすべての更新情報を含んだログファイルが必要です。 ロールフォワード回復（Point-In-Time） アーカイブログ方式の場合、さらにバックアップ取得後の任意の時刻を指定して、その時刻までのリカバリーをさせるこ とができます。 この場合には、すべての区画でRESTORE DATABASEを実行し、バックアップ取得後の任意の時刻を指定してROLLFORWARD DATABASEを実行します。 ROLLFORWARD DATABASE実行時は、時刻の指定とともに「AND COMPLETE」オプションを指定する ことでデータベースが「ロールフォワード保留状態」から抜け出すことができます。 この例では、フォワードリカバリーはすべての区画で走ります。ですから、このリカバリーには、全区画における、バッ クアップ取得から指定した時刻までのすべての更新情報を含んだログファイルが必要です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 45-46 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-11. リカバリー例 （例４） アーカイブ・ログ使用 ﾊﾟｰﾃｨｼｮﾝ1 ﾊﾟｰﾃｨｼｮﾝ2 ﾊﾟｰﾃｨｼｮﾝ3 TBS1 TBS1 TBS1 TBS2 TBS3 TBS3 回復に必要な物： バージョン回復 ロールフォワード回復 （ End Of Logs） あるパーティションの １つの表スペースが 破損した！ ロールフォワード回復 （ Point In Time） LOG LOG LOG LOG LOG LOG DBバックアップ パーティション１∼３ TBS３バックアップ バックアップ後の パーティション２ 全てのログ パーティション２ TBS３バックアップ パーティション２，３ バックアップ後の 特定時刻までのログ パーティション２，３ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：リカバリー例 （例４） 例２と同様、ある一つのデータベース区画での一つの表スペースに障害が発生しているケースですが、アーカイブログ方 式が使われています。 アーカイブログ方式が使われている、ということは、フォワードリカバリーが可能である、ということを意味します。す なわち、この例のような障害パターンでは、以下の3通りのリカバリー方法があります。 バージョン回復 例２の場合と同様にすべての区画でリストアをします。このとき、RESTOREコマンドにWITHOUT ROLLING FORWARDとつ けることで、RESTOREの完了後、即座にデータベースが使用可能になります。リストアは、まずカタログ区画で実行し ておき、その後で残りの区画で実行します。カタログ区画以外の区画のリストアは並行に実行可能です。 ロールフォワード回復（End of Logs） ログの最後までロールフォワードする場合、障害の発生した区画の表スペースのみのRESTOREの実行でリカバリーがで きます。 「RESTORE DATABASE データベース名 TABLESPACE（TBS3）」を障害の発生した区画で実行し、ROLLFORWARD DATABASEコマンドを「TO END OF LOGS」オプション付でカタログ区分で実行します。このとき使用するバックアップ イメージは、明示的にTBS3だけを指定して取得されたバックアップイメージでも、DB全体を取ったフルバックアップ のイメージでも結構です。 ROLLFORWARDコマンドのTABLESPACEオプションでリカバリーする表スペース、そしてON NODEオプションで、どの区画 でリカバリーがなされるべきか指定できます。TABLESPACEオプションもON NODEオプションも指定されなかった場合、 DB2はすべての区画のすべての表スペースのうち、ロールフォワードが必要部分のフォワードリカバリーを実行しま す。 この例では、フォワードリカバリーは区画２で走ります。ですから、このリカバリーには、区画２上における、バッ クアップ取得後のすべての更新情報を含んだログファイルが必要です。 ロールフォワード回復（Point-In-Time） アーカイブログ方式の場合、バックアップ取得後の任意の時刻を指定してリカバリーが可能です。 この場合には、該当する表スペースが定義されたノードグループのすべての区画でRESTORE DATABASEを実行し、バッ クアップ取得後の任意の時刻を指定してROLLFORWARD DATABASEを実行します。 ROLLFORWARD DATABASE実行時は、時 刻の指定とともに「AND COMPLETE」オプションを指定することで表スペースが「ロールフォワード保留状態」から抜 け出し、「バックアップ保留状態」になります。 障害を発生した表スペース（TBS3)は、区画２と区画３からなるノードグループに定義されています。ですから、表ス ペースTBS3のリストアを区画２と区画３に対して実行し、そのあとでROLLFORWARDを実行することになります。 カタログ区画からROLLFORWARD DATABASEコマンドを実行すると、フォワードリカバリーは区画２と３で走ります。で すから、このリカバリーには、区画２と３における、バックアップ取得後のすべての更新情報を含んだログファイル が必要です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 47-48 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-11. リカバリー例 （例５） アーカイブ・ログ使用 ﾊﾟｰﾃｨｼｮﾝ 1 ﾊﾟｰﾃｨｼｮﾝ2 ﾊﾟｰﾃｨｼｮﾝ 3 TBS1 TBS1 TBS1 CATALOG TBS2 TBS2 回復に必要な 物： バージョン回復 ロールフォワード回復 （ End Of Logs） LOG LOG LOG DBバックアップ パーティション１∼ ３ カタログ表スペース が 破損！ ロールフォワード回復 （ Point In Time） −＞ 出来ない CATALOGバックアップ バックアップ後の 全てのログ パーティション1 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：リカバリー例 （例５） この例もアーカイブロギング方式ですが、壊れたのがこのデータベースのカタログ表が作成されている、カタログ表ス ペースです。 カタログ表スペースのリカバリーの場合、ポイントインタイムのフォワードリカバリーはできません。ですから、可能な 回復のシナリオは以下の２種類になります。 バージョン回復 例４の場合と同様にすべての区画でリストアをします。このとき、RESTOREコマンドにWITHOUT ROLLING FORWARDとつ けることで、RESTOREの完了後、即座にデータベースが使用可能になります。リストアは、まずカタログ区画で実行し ておき、その後で残りの区画で実行します。カタログ区画以外の区画のリストアは並行に実行可能です。 ロールフォワード回復（End of Logs） ログの最後までロールフォワードする場合、障害の発生した、カタログ表スペースのみのRESTOREの実行でリカバリー ができます。 「RESTORE DATABASE データベース名 TABLESPACE（SYSCATSPACE）」をカタログ区画で実行し、ROLLFORWARD DATABASEコマンドを「TO END OF LOGS」オプション付でカタログ区画で実行します。このとき使用するバックアップ イメージは、明示的にSYSCATSPACEだけを指定して取得されたバックアップイメージでも、DB全体を取ったフルバック アップのイメージでも結構です。 ROLLFORWARDコマンドのON NODEオプションで、どの区画でROLLFORWARDが実行されるべきか指定できます。ON NODEオ プションを指定しなかった場合、DB2はロールフォワードが必要なすべての区画でフォワードリカバリーを実行しま す。 この例では、フォワードリカバリーはカタログ表スペースが作成されている、区画１で走ります。ですから、このリ カバリーには、区画１上における、バックアップ取得後のすべての更新情報を含んだログファイルが必要です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 49-50 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 2-11. リカバリー例 （例６） アーカイブ・ログ使用 ﾊﾟｰﾃｨｼｮﾝ 3 ﾊﾟｰﾃｨｼｮﾝ 1 ﾊﾟｰﾃｨｼｮﾝ2 TBS1 TBS2 TBS2 CATALOG TBS3(LOB) TBS3(LOB) 回復に必要な 物： バージョン回復 ロールフォワード回復 （ End Of Logs） LOG LOG LOG DBバックアップ パーティション１∼ ３ TBS３ バックアップ パーティション３ バックアップ後の 全てのログ パーティション３ あるパーティションの 1つのLOB用表スペースが 破損！ （ TBS2にREGULARデータ が 存在している） ロールフォワード回 復 （ Point In Time） LOG LOG LOG TBS2,TBS３ バックアップ パーティション２， ３ バックアップ後の 特定時刻までのログ パーティション２，３ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：リカバリー例 （例６） アーカイブログ方式が使われている環境で、ある一つのデータベース区画での一つの表スペースに障害が発生しているケースです。ただしこの例で は、LONGデータ（LONG VARCHAR，LONG VARGRAPHIC，CLOB，BLOB，DBCLOB）を通常のデータタイプのデータとは別の表スペースに配置していま す。つまり、区画２と区画３にまたがるノードグループがあり、そのなかに通常の表スペースTBS2、それにLONGデータのためのTBS3が定義されてい ます。そしてTBS2とTBS3の両方を指定したCREATE TABLEよって作成された表が存在しています。 この例のような障害パターンでも、例４と同様に3通りのリカバリー方法があります。 バージョン回復 例４の場合と同様にすべての区画でリストアをします。このとき、RESTOREコマンドにWITHOUT ROLLING FORWARDとつけることで、RESTOREの完 了後、即座にデータベースが使用可能になります。リストアは、まずカタログ区画で実行しておき、その後で残りの区画で実行します。カタロ グ区画以外の区画のリストアは並行に実行可能です。 ロールフォワード回復（End of Logs） ログの最後までロールフォワードする場合、障害の発生した区画の障害を発生した表スペースのみのRESTOREの実行でリカバリーができます。 「RESTORE DATABASE データベース名 TABLESPACE（TBS3）」を障害の発生した区画で実行し、ROLLFORWARD DATABASEコマンドを「TO END OF LOGS」オプション付でカタログ区分で実行します。このとき使用するバックアップイメージは、明示的にTBS3だけを指定して取得されたバッ クアップイメージでも、DB全体を取ったフルバックアップのイメージでも結構です。 ROLLFORWARDコマンドのON NODEオプションで、どの区画でROLLFORWARDが実行されるべきか指定できます。ON NODEオプションを指定しなかっ た場合、DB2はロールフォワードが必要なすべての区画でフォワードリカバリーを実行します。 この例では、フォワードリカバリーは区画２で走ります。ですから、このリカバリーには、区画２上における、バックアップ取得後のすべての 更新情報を含んだログファイルが必要です。 ロールフォワード回復（Point-In-Time） この場合には、該当する表スペースが定義されたノードグループのすべての区画でRESTORE DATABASEを実行し、バックアップ取得後の任意の時 刻を指定してROLLFORWARD DATABASEを実行します。 ROLLFORWARD DATABASE実行時は、時刻の指定とともに「AND COMPLETE」オプションを指 定することで表スペースが「ロールフォワード保留状態」から抜け出すことができます。 注意していただきたいのは、TBS2とTBS3の2つの表スペースで一つの表データを持っている構成になっているため、ポイントインタイムのリカバ リーの場合には、これら2つの表スペースの同期を取る必要がある、という点です。この例では、まず表スペースTBS2とTBS3のリストアを区画２ と区画３に対して実行し、そのあとでROLLFORWARDを実行することになります。 カタログ区画からROLLFORWARD DATABASEコマンドを実行すると、フォワードリカバリーは区画２と３で走ります。ですから、このリカバリーに は、区画２と３における、バックアップ取得後のすべての更新情報を含んだログファイルが必要です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 51-52 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 3. 破損回復 お断り：当資料は、DB2 UDB V7.1（UNIX,PC) をベースに作成されています。 (一部、Fixpackに含まれるV7.2の機能についてもふれています。） ＜第２．００版＞２００１年１１月 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 目次 3-１．EEEにおける破損回復 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 53-54 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 3-1. EEEにおける破損回復 破損回復も各データベース区画ごとに走る RESTART DATABASEコマンドを使用 RESTART DATABASEコマンドは、それが実行された区画でのみ破損回復を行う AUTORESTARTパラメーター（DB構成パラメーター、区画毎に設定） YESに設定されている場合 クライアントからの接続時にコーディネーター区画およびカタログ区画で（必要ならば）破損回復が実行さ れる その他の区画では、実際にそれらに処理要求がコーディネーター区画から飛んだ時点で（必要ならば）破損 回復が実行される NOに設定されている場合 破損回復が必要なすべての区画でRESTART DATABASEコマンドを実行しなければなりません。 カタログ区画を含む複数の区画に再起動が必要な場合、まずカタ ログ区画から再起動 カタログ区画が正常な場合、わざわざカタログ区画を停止する必要はない。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：EEEにおける破損回復 EEEでは、各データベース区画で発生する変更は、それぞれの区画でのトランザクション・ログに記録されます。従っ て、破損回復も各データベース区画毎に必要になります。 障害によってダウンした区画は、DB2STARTコマンドの実行で再立ち上げが可能ですが、その区画が破損回復を必要とする 場合、RESTART DATABASEコマンドが実行されなければなりません。RESTART DATABASEコマンドは、それが実行された区画 でのみ破損回復を行います。RESTART DATABASEが実行される区画番号は、DB2NODE環境変数を設定する、db2_allユーティ リティーとの組み合わせでRESTART DATABASEを実行する、あるいはSET CLIENTコマンドで接続区画を指定しておいてから RESTART DATABASEコマンドを実行する、といった方法で指定できます。 (例） db2 set client connect_node 2 db2 restart database mydb DB構成パラメーターの一つである、AUTORESTARTの設定により、破損回復を自動的に走らせることができます。このパラ メーターは各データベース区画ごとに設定されます。 YESに設定されている場合、DB区画が活動化された時点で自動的にRESTART DATABASEが実行されます。 クライアントからの接続時にコーディネーター区画およびカタログ区画で（必要ならば）破損回復が実行されま す。 その他の区画では、実際にそれらに処理要求がコーディネーター区画から飛んだ時点で（必要ならば）破損回復 が実行されます。 NOに設定されている場合 破損回復が必要なすべての区画でRESTART DATABASEコマンドを実行しなければなりません。 複数のDB区画に同時に問題が発生した場合には、それぞれの区画にて再始動が必要です。このとき、もし再始動が必要な 区画にカタログ区画が含まれていた場合には、まずカタログ区画から先にRESTART DBを実行し、その後で残りの区画の RESTART DBを実行するようにして下さい。これを守らないと、RESTARTが終わらなかったり、あるいは非常に時間がか かってしまう、という場合があります。 再始動の対象となる区画にカタログ区画が含まれていない場合には、特にこのような考慮は不要です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 55-56 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 4. データの移動 お断り：当資料は、DB2 UDB V7.1（UNIX,PC) をベースに作成されています。 (一部、Fixpackに含まれるV7.2の機能についてもふれています。） ＜第２．００版＞２００１年１１月 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 目次 ４-１．Export ユーティリティー ４-２．Exportの並行処理 ４-３．データのロード ４-４．バッファ無しINSERT ４-５．バッファ付きINSERT ４-６．IMPORT ４-７．ロードの並行処理 ４-８．Autoloaderの４つのモード ４-９．複数区画へのロード - Autoloader ４-１０．Autoloaderの使用 ４-１１．データの偏りの検査 ４-１２．データに偏りがある場合の解消 ４-１３．Autoloaderを使ったLOBデータのLOAD ４-１４．Autoloaderトラブル・シューティング (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 57-58 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-1．Export ユーティリティー db2 connect to MYDB db2 "export to myfile of del messages msg select * from t1" DB2 UDB EEE MYDB 出力ファイル EXPORT myfile t1 t2 データベースの表からコーディネーター区画上のファイルへデータをexport メッセージを検査して、エラーあるいは警告メッセージがないかどうかを確認 SYSADM、DBADM権限、あるいは表および視点に対するCONTROLまたはSELECT特権が必要 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：EXPORTユーティリティー 区画化された表または視点からのデータのEXPORTであっても、非区分化表からのEXPORTとなんら変わりません。対象の データベースへ接続をしてからEXPORTユーティリティーを実行します。SELECT要求は対象表のデータが配置されたデータ ベース区画へ送信され、選択された行はコーディネーター区画上の指定されたファイルへ書き出されます。 EXPORTユーティリティー実行後は、出力メッセージを検査し、エラーや警告の無いことを確認して下さい。 それぞれの表あるいは視点に対してEXPORTユーティリティーを実行するためには、SYSADM権限、DBADM権限、表への CONTROL特権か、あるいはselect特権が必要です。 PC/IXF 形式でのexportは、システム・カタログ表を除いて表のすべての索引の定義を保管します。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 59-60 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-2．Exportの並行処理 EXPORTを全DB区画で同時に実行 db2_all "¥"￨￨ db2 connect to MYDB; db2 'export to /database/instnn/t1.00## of del select * from t1 where nodenumber (col1) = current node'" 接頭部シーケンス「"」を入れると、「##」をＤＢ区画番号に置換 接頭部シーケンス「￨￨」を入れると、バックグランドでコマンドを並列に実行 db2batch（-pオプション）を使用する方法 EEE環境でのパラレルEXPORTをサポート（-pオプション使用） 区分データベース環境内で、EXPORTするデータを定義するSELECTを実行し、個々の区画でEXPORTファイルを 作成可能 db2batch -d MYDB -f Q1.SQL -r /outputpath/outfile, /outputpath/msg -q on -p s Q1.SQLファイルには、EXPORTするデータを定義するSELECTを記述（SELECT * FROM T1;) db2batchが自動的に "WHERE NODENUMBER(col1)=CURRENT NODE" のような条件をつけてSELECTを各区画で実行 する。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：EXPORTの並行処理 普通にデータベースへ接続してEXPORTを実行した場合、選択された行はすべてコーディネーター区画があるマシン上の ファイルへ出力されます。その結果、特に大量行のEXPORTの場合などはコーディネーター区画のあるマシンのDISK I/O がボトルネックとなる可能性があります。 これを避けるための一つの方法として、各区画で並行にEXPORTを別々に実行し、それぞれの区画にある行だけを取り出 す、という方法があります。例えば、４区画上にまたがった表がある場合、それぞれの区画に接続する４つのEXPORTユー ティリティーを実行し、出力ファイルも各区画のあるマシン上に作成する、という方法です。この方法を使いますと、抽 出した行のファイルへの書き出しがすべてのマシン上で行われることになりますし、また抽出した行をコーディネーター 区画へ送るという、ノード間通信も無くなりますので、高速にEXPORTを完了することができます。 EXPORTコマンドの中で指定するSELECTステートメントでは、WHERE文節の中でNODENUMBER 関数と特殊レジスターCURRENT NODEを使用し、接続したDB区画の中だけから行のEXPORTを実行します。NODENUMBER関数の引数は対象表の任意の列名を指 定します。 こちらの例では、db2_allとEXPORTを組み合わせることで、全区画でEXPORTの並行処理を行っています。出力ファイルは ｔ1の後ろに区画番号をつけたような形になっています。この区画番号をつけるために接頭部シーケンス「"」が使用され ています。こちらを使うと、「##」をＤＢ区画番号に置換します。 各区画で同時にデータのアンロードを行い、結果を各区画のローカルファイルに保管するための方法としては、db2batch を使用することも可能です。 db2batchを使うと、入力ファイルに与えられたSELECTステートメントを実行し、これを指定した結果ファイルに書き出す ことができます。 EEE環境では、db2batchに-pオプションを指定することができます。これを指定すると与えられたSELECTステートメント には自動的に「WHERE NODENUMBER()=CURRENT NODE」のような条件が付加され、各DB区画にて同時実行されます。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 61-62 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-3．データのロード Insert バッファ無しInsert vs バッファ付きInsert バッファ付きInsertの指定 PREP/BIND オプションのINSERT BUF db2cli.iniファイルにInsertBufferingを指定（DB2 UDB V7.2 FP4） ステートメントオプションSQL_ATT_INSERT_BUFFERINGを設定（DB2 UDB V7.2 FP4） Import Insertを使用したユーティリティー バインドファイル(db2uimpm.bnd)をINSERT BUFにてバインドしてバッファ付きImport Load ログをとらない データを分割（db2split）後ロードする Autoloader データの分割、ロード処理を一つのコマンド、構成ファイルで実現 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：データのロード DB2 UDB EEE でデータを格納するために使用される３つの基本的な方法は、insert、importとloadです。 INSERTステートメントを実行するアプリケーションは、プリコンパイルまたはバインド･オプションでバッファ無し INSERT、あるいはバッファ付きINSERTを利用することができます。 DB2 UDB V7.2のFixPak4では、CLIでもバッファ付きINSERTを使用することができます。CLIでバッファ付きINSERTを使用 したい場合、db2cli.iniファイルに設定するInsertBufferingキーワード、あるいはCLIのステートメントオプション SQL_ATTR_INSERT_BUFFERINGに適当な値を設定します。（詳しくは後述） import コマンドはデータをロードするために提供されているユーティリティーです。このユーティリティーはバッファ 無しINSERTを利用しており、トランザクションログをとります。ただし、INSERT BUFオプションを使用し、importパッ ケージdb2uimpm.bndをデータベースに再バインドすれば、バッファ付きINSERTになります。 loadコマンドは、表をロードするために各DB区画で並列に処理を行なうことのできる高速ロードユーティリティーです。 このユーティリティーは、INSERTを使用せず、直接データページのフォーマットでデータを格納してゆきますので、トラ ンザクションログをとりません。LOADをつかって格納されるデータは事前にdb2splitユーティリティーを使って各DB区画 に適切に分割されていなければなりません。 db2splitはDB2 UDB V5.0以降、マニュアルには出ていませんが、以前のリリースとのコンパティビリティーを提供す るため、現行リリースでも使用可能です。しかしながら現在では、ＡＵＴＯＬＯＡＤＥＲがdb2ｓｐｌｉｔのすべての 機能を含んでおりますので、AUTOLOADERを使うようにして下さい。 autoloaderユーティリティー（db2atld）によって、分割とロード処理の両方を行なうことができます。autoloader ユー ティリティーは分割とロード処理で必要とされているすべてのデータ処理を行います。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 63-64 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-4．バッファ無しINSERT アプリケーション Exec SQL INSERT コーディネー ター区画 区画 1 区画 2 SQLCODE 区画 3 ディスク への書き 込み Hash SQLCODE (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：バッファ無しINSERT INSERT DEFをプリコンパイルやバインド・オプションで指定した場合、バッファ無しINSERTが行われます。これはデフォ ルトの設定値です。 バッファー無しINSERTでは、挿入される各行が個々にハッシュされ、適切なDB区画に格納されます。INSERT DEFオプショ ンにより、アプリケーションはVALUESをもつ標準的なINSERTとして実行されることになります。一度に1行ずつ挿入さ れ、ターゲットのDB区画はコーディネーターDB区画に応答し、そしてINSERT処理を要求したアプリケーションに戻りま す。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 65-66 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-5．バッファ付きINSERT アプリケーション Exec SQL INSERT 対応するバッファ へのINSERT hash SQLCODE 0 0 1 2 3 アプリケーション Exec SQL COMMIT SQLCODE 0 0 1 2 3 バッファが並列に適切なDB区画 に挿入される SQLCODE 0 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：バッファ付きINSERT プリコンパイル や バインド時にINSERT BUFオプションを指定した場合、そのアプリケーションのINSERT処理ははバッ ファー付きINSERTとなります。 バッファー付きINSERTは、db2cli.iniファイルに設定するInsertBufferingキーワード、あるいはCLIのステートメントオ プションSQL_ATTR_INSERT_BUFFERINGに適当な値を設定することで、CLIのアプリケーションでも使用できます。 バッファー付きINSERTでは、各行はコーディネーターDB区画上の各DB区画毎の挿入バッファ（4KB）へハッシュされ、あ て先区画に実際にデータが送られる前にアプリケーション側にSQLCODE ０が返ります。 挿入バッファが満たされると、その４KB分のデータがあて先のDB区画に送られます。 Commit, Rollback, Update, Delete, Create, Alter, Drop, Grant, Revoke, Reorg, Runstats, Select into, Begin Compound SQL, End Compound SQL, Execute Immediateが実行された時点でも、バッファーのフラッシュが行われ、すべ てのDB区画で並行に挿入処理がなされます。 バッファー付きINSERTを使う場合、あて先にデータを送ってはじめて判明するようなエラー（固有キーにおける重複デー タなど）のSQLCODEは、バッファーをフラッシュしたステートメントに返ります。 つまり、エラーが非同期で報告される ことになりますので、そのようなエラーを意識したプログラミングが必要になります。 バッファー付きINSERTでエラーが発生した場合、そのUOWはバックアウトされます。 バッファー付きINSERTでは、挿入された行はそれらを挿入したアプリケーションですぐに検索することはできません。こ れは、バッファー上にデータがまだ置かれている可能性があるからです。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 67-68 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 CLIによるバッファ付きINSERT（FixPak4） CLIアプリケーション（Array Insert）がバッファ付きINSERTを実 行可能 バッファ付きINSERTの使用は、ステートメントレベルで指定可能 従来はBINDまたはPREPのときに指定するINSERT BUFオプションでのみ指定可能 重複キーのエラー（SQLCODE -803)を警告に変換する機能を提供 バッファ付きINSERT中に発生するエラーは、バッファー全体をROLLBACKするが、重複 キーが発生したことによるエラー（SQLCODE -803）は、単に重複行をスキップするだ けで、バッファ全体のROLLBACKをしない CLIでバッファ付きINSERTを使う場合の設定 CLI構成キーワード InsertBuffering を db2cli.iniファイルに設定する -1：CLIはバッファ付きINSERTを行わない。ステートメントで指定のSQL_ATTR_INSERT_BUFFERINGは無視 0：CLIはバッファ付きINSERTを行わない。ステートメントで指定のSQL_ATTR_INSERT_BUFFERINGは有効 1：CLIはバッファ付きINSERTを行う。 2：CLIはバッファ付きINSERTを行う。重複キーのエラー(-803）は警告（+803）に変換される。 ステートメントオプション SQL_ATTR_INSERT_BUFFERINGを設定する SQLSetStmtAttrを用いて0、1、2のいずれかの値とともに指定 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：CLIによるバッファ付きINSERT（FixPak4） 2001/9に出荷のFixPak4で新しく提供される機能として、Array Insertを使ったCLIアプリケーションによるバッファ付き INSERTがあります。 従来バッファ付き挿入を使用したい場合には、BINDまたはPREPのときに指定するINSERT BUFオプションでのみ指定可能で したが、FixPak4からは、CLIアプリケーションのステートメントレベルで、バッファ付き挿入を使用する指定ができま す。 従来より、バッファ付きINSERT中に発生するエラーは、バッファー全体をROLLBACKしていました。このエラーにはユニー ク索引を持つ表に対する重複キーの挿入（SQLCODE -803）も含まれていましたが、このFixPak４で提供される新機能で は、重複キーが発生したことによるエラー（SQLCODE -803）は、単に重複行をスキップするだけで、バッファ全体の ROLLBACKをしないような設定もできるようになりました。 CLIでバッファ付きINSERTを使いたい場合、CLI構成ファイル（db2cli.ini）に構成キーワード InsertBufferingを設定す るか、またはステートメントオプションのSQL_ATTR_INSERT_BUFFERINGを設定します。構成キーワードInsertBufferingに 設定可能な値は以下の通りです。 -1：CLIはバッファ付きINSERTを行わない。ステートメントで指定のSQL_ATTR_INSERT_BUFFERINGは無視 0：CLIはバッファ付きINSERTを行わない。ステートメントで指定のSQL_ATTR_INSERT_BUFFERINGは有効 1：CLIはバッファ付きINSERTを行う。 2：CLIはバッファ付きINSERTを行う。重複キーのエラー(-803）は警告（+803）に変換される。 ステートメント単位でバッファ付きINSERTの使用を設定する場合、ステートメントオプション SQL_ATTR_INSERT_BUFFERINGを設定します。このステートメントオプションの設定は、上記CLI構成キーワードの InsertBufferingの設定を上書きします。ステートメントオプションの設定に際しては、SQLSetStmtAttr関数を用いま す。SQL_ATTR_INSERT_BUFFERINGには、0、1、2の値が設定可能で、それぞれの意味は上記InsertBufferingと同じです。 なお、０，１，２の代わりにそれぞれ、SQL_ATTR_INSERT_BUFFERING_OFF、SQL_ATTR_INSERT_BUFFERING_ON、 SQL_ATTR_INSERT_BUFFERING_IGDを指定することもできます。（ちなみにIGDはignore duplicate keyの意） (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 69-70 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-6．IMPORT Import コーディネーター DB区画 DB2 DB2 DB2 DB2 DB2 DB2 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：IMPORT IMPORTの使用方法は非区画化環境と変わりません。データベースへ接続してから対象の表に対してIMPORTを実行します。 IMPORTは一行ずつハッシングを行い、パーティションマップによって決められたDB区画に行を挿入します。 INPORTでバッファ付きINSERTを使用したい場合、INSERT BUFオプションを使用し、importパッケージdb2uimpm.bndをデー タベースに再バインドすれば、バッファ付きINSERTになります。なお、バッファ付きINSERTの場合には、INSERT_UPDATE オプションは使わないで下さい。INSERT_UPDATEオプションは固有索引のある表に対してINSERTを発行し、もし挿入行の キーが重複していた場合にはUPDATEを発行しなおす、という動きをしますが、これが正しく処理されるためには、一行ご とにSQLCODEがアプリケーション（この場合にはIMPORT）に返らなくてはならないからです。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 71-72 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 参考：IMPORTの並行処理 IMPORTは対象表が配置されている全区画にロックを取得する db2batchなどをつかってパラレルEXPORTを行ったとしても、パラレルIMPORTは不可 各区画のみを参照するような視点を使用 create view View0 as select * from Test where nodenumber(col0)=0 データがIMPORTされる宛先のみにロックが取られるため、パラレルIMPORTが可能 Import ... insert into Test 区画0の データ Import ... insert into Test Import ... insert into View0 区画1の データ Import ... insert into View1 区画0の データ 区画1の データ 各区画にのみロックを 取得するため、パラレ ルIMPORTが可能 パラレルIMPORT を試みてもロック待 ちになる X-Lock X-Lock X-Lock 視点View0 表Test 区画0 区画1 X-Lock 視点View0 表Test 区画0 区画1 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説： EXPORTを各区画で同時に実行し、それぞれの区画が持っているデータをファイルに書き出す方法についてはすでに説明し ました。それでは、こうして複数ファイルにEXPORTしたデータをDB2の表へIMPORTするためには、どうすれば良いでしょ うか？ 最も簡単な方法は各ファイルについて一つずつIMPORTを実行する、あるいは一旦全部のファイルをひとつにまとめてし まってからこれをIMPORTするという方法です（IMPORTでは、複数の入力ファイルを指定することはできません）。しかし ながら、この方法ではコーディネーターノードやネットワークへの負荷が大きく、IMPORTを高速に行うことはできないで しょう。せっかく各区画に配置されるべきデータがそれぞれ別ファイルに入っているのですから、これを各区画にパラレ ルにIMPORTする方法について考えてみましょう。（EXPORTの対象の表とIMPORTの対象の表は、同じ区分キーを持ち、それ ぞれのパーティショニング・マップも同じと仮定） このとき問題となるのは、IMPORTが対象表に取得するロックです。データベースに各区画から接続し、それぞれの区画の データを同時にIMPORTしようとしても、2番目以降のIMPORTはロック待ちになってしまいます。(前ページの左側の図） IMPORTをパラレルに実行させるためには、IMPORTが宛先の区画のみにロックを取るようにさせる工夫が必要です。これを 実現する方法としては、事前に各区画のみを参照するような視点を作成しておき、それらの視点に対してIMPORTを行う、 というものがあります。例えば、前ページの右側の図の例では、区画０と１にまたがる表Testに対し、「create view View0 as select * from Test where nodenumber(col0)=0」、「create view View1 as select * from Test where nodenumber(col0)=1」で定義されるような視点を用意し、それらに対してIMPORTを行っています。 こうすれば、IMPORTユーティリティーは各区画のみにロックを取得することになりますので、ロック待ちを起こすことな く、パラレルに実行可能となります。 注意： NODENUMBER関数を使ってVIEWを定義する場合、WITH CHECK OPTIONオプションを指定できません。つまり、IMPORTを含 むINSERTやUPDATEステートメントの実行をこの視点に対して実行するとき、WHEREで指定された条件に合致しなくても エラーにはなりません。 従って、例えば区画０と区画１の双方のデータを含むような入力ファイルからREPLACEモードにて、上記View0に IMPORTした場合、まず区画０のデータが削除されるが、区画1のデータはそのまま、そして入力ファイルの中の区画0 に該当するデータは区画0に挿入され、区画1に該当するデータは区画1に挿入されることになります。 パラレルにデータを挿入する方法としては、このような方法の他、次のページ以降で解説するLOADユーティリティーを使 用する方法があります。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 73-74 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-7．ロードの並行処理 Original Data Source フラットファイル split load load load 区画 1 区画 2 区画 3 DB2 DB2 load DB2 区画 4 DB2 load 区画 5 DB2 load 区画 6 DB2 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：ロードの並行処理 loadコマンドは、表をロードするために各DB区画で並列に処理を行なうことのできる高速ロードユーティリティーです。 このユーティリティーは、INSERTを使用せず、直接データページのフォーマットでデータを格納してゆきますので、トラ ンザクションログをとりません。LOADユーティリティーを使って格納されるデータの入力ファイルは、事前にあて先区画 の数に適切に分割されていなければなりません。 入力ファイルの分割は、オートローダー（db2splitユーティリティー）を使って行います。分割は、入力ファイルから一 行取り出し、Partitioningキーに該当する部分のデータをハッシングし、その行のあて先を確定することで行います。 オートローダーを用いた場合、入力ファイルの分割以外に、あて先DB区画でのLOADユーティリティーの実行も行うことが できます。 db2splitはDB2 UDB V5.0以降、マニュアルには出ていませんが、以前のリリースとのコンパティビリティーを提供す るため、現行リリースでも使用可能です。しかしながら現在では、オートローダーがdb2ｓｐｌｉｔのすべての機能を 含んでおりますので、オートローダーを使うようにして下さい。 オートローダーはdb2splitを内部的に使用して入力ファイルをDB区画数分に分割、分割データは各DB区画のあるマシンへ 転送します。そしてそれぞれの各DB区画で独立してLOADを実行します。 オートローダーは、データの分割処理だけ、またはLOAD処理の部分だけを実行するためにも使われます。 単一区画からなるノードグループ上に定義された表に対するロード処理の場合には、入力ファイルの分割が不要です。で すからAutoloaderは使用せずに、直接LOADユーティリティーによってデータのロードを行います。この場合、LOADユー ティリティーのMODIFIED BY NOHEADERオプションを指定してください。 MODIFIED BY NOHEADERオプションは、入力ファイルにヘッダー部分がないことを示します。複数のDB区画からなる ノードグループ上に定義された表へのロードの場合、Autoloader（実際はその中で呼び出されるdb2split）によって 生成された分割ファイルは、分割キーやパーティションマップの情報をヘッダー部に持ちます。これは、この分割 ファイルが正しい分割キーやパーティションマップに基づいて分割されたことを保証するためです。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 75-76 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-8．Autoloaderの４つのモード db2atld analyze 最適な パーティションマップ db2atld split_and_load db2atld split_only load_only db2atld 区画 1 区画 2 区画 4 区画 3 区画 5 区画 6 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：Autoloaderの４つのモード Autoloaderは４つの異なったモードで実行することが可能です。 SPLIT_ONLYモード SPLIT_ONLYは、データの分割のみが実行されます。指定されたデータベース区画のために分割して、あて先区画のあるマ シンの指定した場所、あるいは現行作業ディレクトリにファイルが書きこまれます。 LOAD_ONLYモード LOAD_ONLYは、分割ファイルを受け取り、並列に区画へロードします。指定された場所あるいは現行作業ディレクトリか ら分割ファイルを探し、対応する複数区画へのロードを並行に実行します。 SPLIT_AND_LOADモード SPLIT_AND_LOADは、SPLIT処理からLOAD処理へデータを転送するため、これらの2つ処理を結合しパイプ処理を行います。 SPLIT_AND_LOADオプションを使った場合、分割ファイルをDISK上へ書き出さないので一連の処理を高速に行うことができ ます。ただし、LOADフェーズの途中でエラーになった場合、仮にロードの再始動を行いたい場合でも再びデータの分割か らやり直さなければなりません。それに対し、SPLIT_ONLYの実行、LOAD_ONLYの実行、という具合に2段階で処理した場合 には、分割をやり直さなくてもLOADのRESTARTが可能です。 ANALYZEモード ANALYZEは、入力ファイルのデータを検査し、表にロードされるデータを各区画に均一にロード可能となるようなパー ティションマップを生成します。生成されたパーティションマップを適用するためには、REDISTRIBUTEユーティリティー を使用する必要があります。 Autoloaderで分割/ロードできるのは、DEL形式（区切り文字付きASCII)、またはASC形式（区切り文字無しASCII)のどちらか です。LOADユーティリティーはPC/IXF形式の入力ファイルもサポートしていますが、AutoloaderでPC/IXF形式のファイルを 分割/ロードすることはできません。PC/IXF形式の入力ファイルを区画化された表へ格納しなくてはならない場合、IMPORTを 使用するか、あるいは一度単一区画上の別表にLOADしてからSELECT/INSERTでターゲット表へロードすることになります。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 77-78 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-9．複数区画へのロード - Autoloader DB区画 0,1,2,3,4上 のマージとロード 8ノードMPP構成 n0 n0 M L n5 n1 n1 S M L n6 n2 n2 S M L n7 n3 n3 S M L n4 n4 メディア DB区画5,6,7 読取処理 上のsplit 入力 データ R 複数区画でのSPLIT処理 ソケット SPLIT_NODESあり 指定された区画でSPLIT SPLIT_NODESなし LOADのanyorder修飾子が指定されている場合 （OUTPUT_NODES内の区各数）/4＋１ノードでSPLIT LOADのanyorder修飾子が指定されていない場合 1区画でSPLIT 単一構成ファイルだけでLOAD処理可能 ソケット M L ソケット (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：複数区画へのロード- Autoloader データファイルの分割は多くのCPU時間とDISK I/Oを伴う処理です。オートローダーは、分割処理を複数のDB区画上で並列に 実行することが可能です。DB2 UDB EEEでは、分割処理を並列で行うため、ユーザーが分割処理を行うDB区画を選択するオプ ションをもっています。DB区画はロードされている区画と同じ、あるいは異なる場合も可能です。これらの複数区画への分 割処理からの出力は、複数区画へロードするためにそれぞれのDB区画へ送られます。複数のDB区画上で分割された入力デー タは、ロードが行われる各DB区画上でマージされ、ロードされます。 複数区画で分割をする場合、以下のような制限事項があります。 LOADではANYORDERを指定します（指定しない場合、一区画での分割になる）。そのためロードされるデータの順序は入力 ファイルの順序とは一致しません。 LOADコマンドのROWCOUNTオプションをサポートしません。 split段階での並列処理を行うと、LOADコマンドにおいてSAVECOUNT値はサポートされていません。 db2atldは名前付きパイプではなくソケットを内部通信チャネルとして使い、デフォルト範囲（6063∼6000）の中からTCP ポート番号を選択します。 このポートは構成ファイル中のPORTSパラメータで変更するか、DB2レジストリ変数 DB2ATLD_PORTSを設定することで変更す ることができます。優先順位は、DB2ATLD_PORTS ＞ PORTS ＞ デフォルト です。 メディア読み取り - (R) メディア読み取りは、入力データを読み取り、分割の指定をされたDB区画への入力データの初期分割を行います。これは各 分割DB区画へソケットを利用する処理で、ラウンドロビンで行われます。 Split 段階 - (S) Autoloaderは構成ファイルで定義されている各DB区画で、db2splitユーティリティーを実行します。その入力はautoloader コマンドが実行されたメディア読み取り処理からソケット処理経由となっています。db2splitは出力ソケット数分に入力 データを分割します。ロードを実行する各DB区画へ1つずつの出力ソケットがあります。すべての分割に使用されるパーティ ションマップはautoloader構成ファイルに指定します。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 79-80 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 解説：複数区画へのロード- Autoloader Merge 段階 - (M) DB2 Loadは並列で行う複数入力処理をサポートしていません。そのため、各分割DB区画からソケット処理される入力データ は、ロードするあて先のDB区画でマージされます。このマージ処理は、同時に各分割処理元からレコードが送られてくるた め、多くの入力データを受け取ります。しかし受け取られたレコードのマージ処理は行われません。つまり、ロード段階に 送られるレコードの順序は入力ファイルでのレコード順序とは必ずしも一致しません。 Load 段階 - (L) Autoloaderは、同じDB区画で実行されるマージ処理からソケット処理された出力をロードするために、構成ファイルに定義 されているオプションを使用して、各DB区画でDB2ロードユーティリティーを呼び出します。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ブランク・ページです ( 81-82 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-10．AutoLoaderの使用 オートローダー起動準備 作業ディレクトリの作成 全DB区画からアクセス可能なディレクトリ 通信の設定 SVCENAMEの設定 DB2COMMの設定 autoloader.cfgの準備（サンプルファイルを修正して使用） db2 load from INPUTFILE of DEL insert into db2inst1.mytable DATABASE=MYDB SPLITNODES=(5,6,7,8) MODE=SPLIT_AND_LOAD オートローダーの起動 $ db2atld -config autoloader.cfg (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：Autoloaderの使用 オートローダーを使用する前に、以下の設定をする必要があります。 オートローダーを実行する作業ディレクトリを作成します。このディレクトリは全DB区画からアクセスできなければなり ません。 DBM構成パラメータ：SVCENAMEとDB2レジストリ変数：DB2COMMが正しく設定されていることを確認してください。これは オートローダーが、作業ディレクトリから各DB区画へTCP/IPを使用したリモートデータベース接続を確立するためです。 オートローダー構成ファイル：autoloader.cfgを、sqllib/samples/autoloaderディレクトリから作業ディレクトリにコ ピーし、必要に応じて編集して下さい。（構成ファイル中の設定に関する詳細情報に関しては、「データ移動ユーティリ ティー 手引きおよび解説書」をご参照下さい。） 主な要編集項目は以下の通りです。 LOADコマンド： LOAD_ONLY、SPLIT_AND_LOADモードでの実行時に実際に各DB区画で実行されるLOADコマンドを記述 します。また、オートローダーは、指定されたLOADコマンドのパラメーターの値に基づいて、SPLIT_ONLY、 SPLIT_AND_LOAD、あるいはANALYZEモードで使用する入力ファイルを決定したり、必要なパーティションマップを特 定します。 DATABASEパラメーター： 対象のデータベース名を指定します SPLIT_FILE_LOCATIONパラメーター ：SPLIT_ONLY、またはLOAD_ONLYモードの時の分割ファイルの入出力先を指定 します。 SPLIT_NODESパラメーター：入力ファイルの分割を行うDB区画を指定します。 MODEパラメーター：SPLIT_ONLY、LOAD_ONLY、SPLIT_AND_LOAD、ANALYZEのいずれかを指定します。 LOGFILEパラメーター：オートローダーが生成するログファイルなどのファイル名のベースとなる名前を指定しま す。パス名も含めて指定する場合、そのディレクトリーが全DB区画からアクセス可能である必要があります。 LOGFILEパラメーターのデフォルト値は”./autoloader.log” です。 RUN_STAT_NODEパラメーター： LOADコマンドで「STATISTICS YES」が指定された場合、このパラメーターで指定さ れた区画で統計情報を取得します。EEEの場合、統計情報は一区画でのみ取得されることにご注意下さい。 上記の例では、DEL形式の入力ファイル「INPUTFILE」からデータベース「MYDB」に作成されている表 「db2inst1.mytable」への分割およびロードを行っています。分割に際しては、DB区画５，６，７，８の４区画を使 用しています。 上記の設定が完了したらオートローダーコマンドを以下のように起動します。 db2atld [-config config_file] [-restart] [-terminate] -configでオートローダー構成ファイルを指定します。 -restartで中断されたオートローダーのRESTARTを要求します。（構成ファイルは変更する必要なし） -terminateで中断されたオートローダーを終了させます。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 83-84 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-11．データの偏りの検査 オートローダーが生成するメッセージファイルから確認 各区画に何行が割り当てられたかが分かります。 ロード済み表における各区画での件数を確認 NODENUMBER関数を使用する db2 "select nodenumber(column-name), count (*) from table-name group by nodenumber(column-name) " (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：データの偏りの検査 DB2 UDB EEEで最適なパフォーマンスを得るためには、各表のレコードが、それらの定義されているノードグループの全体の 区画にまんべんなく配置されていることが非常に重要です。 SPLIT_ONLYモード、あるいはSPLIT_AND_LOADモードでオートローダーを使った場合、分割されたデータが各区画に何行ずつ 割り当てられたかをオートローダーが生成するログファイルを検査することで知ることができます。 例えば、区画０で実行された分割のログは、デフォルトでは「autoloader.log.split.000.log」というファイルに書き出 されます。 また、現在すでにデータが含まれている表のデータが各区画にどのように配置されているかを調べるためには、NODENUMBER 関数を使ったSELECT文を実際に発行します。NODENUMBER関数は、行のDB区画番号を返しますので、「COUNT(*)」と「GROUP BY NODENUMBER()」を組み合わせることで、各DB区画に含まれる行数を知ることができます。なお、NODENUMBER関数で指定す る列は表上のどの列名でも指定できます。 ある表のデータの区画間の配置に著しい偏りがあった場合、次ページ以降に示すような方法で、その表を区画間に均一に配 置するのに最適なパーティションマップを生成･適用することで、この偏りを解消することができます。ただし、パーティ ションマップを変更することは、同じノードグループに属するすべての表の配置に影響を与えるので、ある一つの表の偏り を解消することが、別の表の偏りを生んでしまう恐れもありますので注意が必要です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 85-86 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-12．データに偏りがある場合の解消 ANALYZEモードでdb2atldを実行 入力ファイルで与えられたデータを各DB区画へ均一に配置するために最適なPartition Mapを生成 データファイル 構成ファイル (MODE=ANALYZE) db2atld 最適なPartition Map 生成されたPartition Mapを適用する（ REDISTRIBUTE NODEGROUP） 〔 例）REDISTRIBUTE NODEGROUP mygroup USING TARGETMAP out.pmap 新しいParitition Mapでデータを分割＆LOAD データファイル 構成ファイル (MODE=SPLIT_AND_LOAD) db2atld 各区画へのロード (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：データに偏りがある場合の解消 もしノードグループ内のDB区画間でデータが均一に分配されていない場合、均一に配置するのに最適なパーティションマッ プを生成･適用することで、この偏りを解消することができます。ただし、パーティションマップを変更することは、同じ ノードグループに属するすべての表の配置に影響を与えるので、ある一つの表の偏りを解消することが、別の表の偏りを生 んでしまう恐れもありますので注意が必要です。 新しいパーティションマップを実行モード「ANALYZE」のオートローダーで生成します。オートローダーは入力データのファ イルを検査し、均一なデータ配置を実現するためのパーティションマップを生成します。 新しいパーティションマップを適用するためには、REDISTRIBUTE NODEGROUPユーティリティーをTARGETMAPオプション付きで 実行します。REDISTRIBUTE NODEGROPは、指定されたノードグループで使用されるパーティションマップを置き換えます。具 体的には、そのノードグループに定義された全ての表を一行ずつ読み取ってHashingを行い、新しいパーティションマップに 基づいて決定されるDB区画に行を移動します。 まだロードがなされていないデータに関しては、普通にSPLIT_AND_LOADモード（あるいはSPLIT_ONLYとLOAD_ONLYの2段階） のオートローダーの実行によって分割･ロード処理が可能です。オートローダーは新しいパーティションマップをカタログ表 から取り出して分割のために使用します。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 87-88 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-13．Autoloaderを使ったLOBデータのLOAD LOBデータのLOAD LOBSINFILEオプションが指定され、別のファイルに格納されているLOBを使用する場合、 LOBファイルが置かれたディレクトリはロードされるすべてのノードからアクセスが可能 でなければなりません。 転送 Shared files DB区画１ lob1 DB区画１ 1 lob1 2 lob2 3 lob3 4 lob4 5 lob5 6 lob6 ... 7 lob7 split 2 5 lob2 lob2 lob5 lob3 DB区画２ 1 4 6 lob1 lob4 lob6 DB区画２ lob4 lob5 DB区画３ lob6 DB区画３ 3 7 lob3 lob7 lob7 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：Autoloaderを使ったLOBデータのLOAD LOADユーティリティーには、LOBSINFILEというオプションがあります。このオプションは、別ファイルに保管されたLOBデー タをロードする場合に使用します。入力ファイル中のLOBデータ列に該当する位置には、LOBデータではなく、LOBデータを保 管している別ファイルの名前が記述されるようにします。 このようなオプションをAutoloader構成ファイル中のLOADコマンドで指定する場合、実際にこの別ファイルへのアクセスを 行うのは、各DB区画上で実行されるLOADであるため、LOBファイルが置かれたディレクトリはロードされるすべてのDB区画が あるノードからアクセスが可能でなければなりません。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 89-90 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ４-14．Autoloaderトラブル・シューティング 生成されるすべてのログファイルをチェックすること オートローダーのメッセージ出力 db2splitが生成するログファイル（例： autoloader.log.split.000.log） SplitでのReject行はLOADへは渡らない LOADのログファイル （例：autoloader.log.load.000） LOADコマンドでMESSAGESオプションでメッセージファイルを指定しても無視される ロードでエラーの場合、現行のdb2atldに割り込みが入ります。 db2atldの失敗や割り込まれた場合の再始動方法 db2atld -config 構成ファイル -RESTART db2atldの失敗や割り込まれた場合のクリーンアップ方法: db2atld -config 構成ファイル -terminate (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：Autoloaderトラブル・シューティング オートローダーの実行後は、必ずオートローダーが出力する、すべてのメッセｰジを確認して、エラーが発生していないこと を確認して下さい。 オートローダーはオートローダー自身のメッセージ出力を標準出力へ出す他に、SPLITのログ（SPLIT_ONLY、 SPLIT_AND_LOAD、ANALYZEモードの場合）、それとLOADのログ（LOAD_ONLY、SPLIT_AND_LOADモードの場合）を生成します。 必ずすべてのログファイルをチェックしてください。 SPLIT段階でRejectされた行は、LOADへはわたりません。LOAD段階でRejectされた行はDUMPFILEオプションで指定されたファ イルへの書き出しが可能ですが、SPLIT段階でRejectされた行は、SPLITのログに「何行目のレコードがRejectされた」とい う旨のメッセージが書かれます。 LOADでMESSAGESオプションを指定していた場合でも、このパラメーターで指定されたファイルにLOADのメッセージが書き出 されることはありません。変わりにオートローダーの構成ファイル中のLOGFILEパラメーターで指定されたベース名をもとに したログファイルにLOADのメッセージは書かれます。デフォルトでは、オートローダーの実行ディレクトリー上に 「autoloader.log.load.000」（区画０へのロードの場合）のようなファイルが作成されます。 オートローダーが途中で失敗した場合、以下のようなオプションでもう一度オートローダーを実行します。構成ファイルに 特に変更を加える必要はありません： RESTARTオプション オートローダーの再始動を行います。 TERMINATE オートローダーが生成した一時ファイルなどをすべて削除します。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 91-92 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 ５. DB区画の再構成 お断り：当資料は、DB2 UDB V7.1（UNIX,PC) をベースに作成されています。 (一部、Fixpackに含まれるV7.2の機能についてもふれています。） ＜第２．００版＞２００１年１１月 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 目次 5-１．パーティションの調整 5-2．パーティションの追加 5-3．データの再配布 5-4．データベース・パーティションの削除 5-5．データの再配布（REDISTRIBUTE NODEGROUP） 5-6．再配布ユーティリティー：UNIFORMオプション 5-7．UNIFORM 例 5-8．再配布ユーティリティー：DISTFILEオプション 5-9．DISTFILE 例 5-10．再配布ユーティリティー：TARGETMAPオプション 5-11．TARGETMAP 例 5-12．再配布 - エラー時のリカバリー 5-13．再配布の段階的実行 5-14．MAKEPMAPユーティリティー 5-15．MAKEPMAPの使用例 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 93-94 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-1. パーティションの調整 バランスの取れた ノード・グループ データの増加により CPU/ ディスク資源が アンバランス パーティションを追加 但し、新しく追加した区分 の資源はまだ利用されない データの再配布 バランスの取れた ノード・グループ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：パーティションの調整 DB2 UDB EEEの大きな特長は、高いスケーラビリティーです。つまり、新しくSPのノードのようなハードウェアを追加、そこ へ新しいDB区画を作ることで、データ量や同時アクセスユーザー数の増加に対応することができます。 新しい区画が追加された場合、既にデータベース内に格納されているデータは、新しい区画を含める形に再配布することが できます。前のページの図表には、ユーザがどのような手順でデータベースに新規にパーティションを追加し、そしてデー タを再配布して新しいパーティションを有効にするかが示されています。 DB2は再配布（REDISTRIBUTE）ユーティリティーを提供しています。これはノード・グループに対して実行し、ノードグルー プ内の各表のデータ再配布を行います。 ノード・グループの再配布はシステム・カタログのPARTITIONMAPS、NODEGROUPS、 NODEGROUPDEFを修正します。 ノード・グループ再配布ユーティリティーは、パーティション間でデータを移動（INSERT／DELETE)します。 一つの区分を追加した後 一つの区分を除去する前 ロード・バランスの間 ノード・グループ再配布ユーティリティーはカタログ・パーティションから実行する必要があります。 ノード・グループ再配布ユーティリティーは、処理中に断続的にCommitを実行します。１つのUOWで一つの表を移動します。 表を移動する間パッケージが無効になりますが、次のアクセス時自動的に再バンドされます。 複数の表がCollocatedであった場合、一時的に関係が崩れます。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 95-96 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-2. パーティションの追加 db2stop db2nodes.cfgを編集して host4を追加します。 db2start host4上で：db2 add node 既存パーティション host1 host2 host3 0 1 2 3 host4 host1 0 host2 0 host3 0 host4 0 db2nodes.cfg $ db2start nodenum 3 addnode hostname host4 port 0 既存パーティション host1 host2 host3 $ db2stop $ db2start host4 0 host1 1 host2 2 host3 3 host4 0 0 0 0 db2nodes.cfg (db2startで更新される ) (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：パーティションの追加 DB2 UDB EEEは、データベース・システムに新しいパーティションを追加することで、新規追加の物理ノードを活用する手段 を提供しています。 パーティションは、db2start...addnodeコマンドまたはADD NODEコマンドを実行することで追加する ことができます。また、マニュアルでdb2nodes.cfgを直接編集した後、ADD NODEコマンドを実行することでも区画の追加が 可能です。 ADD NODEコマンド、またはDB2STARTのADD NODEオプションの実行により、新しい区画を作成します。その際、現在定義され ている全てのデータベースのディレクトリー構造（/DBPATH/INSTANCE/NODExxxx/SQL000x/...）を新しいDB区画のために作成 します。そのため、既存のDBが使用中のDBパスと同じディレクトリーが、新規DB区画が作成される物理ノード上でも使用可 能である必要があります。 ADD NODEコマンドは、追加したいノード上から発行する必要があります。 ADD NODEコマンド、またはdb2start...addnodeでDB区画を追加すると、同時に各データベースの一時表スペースも新しいDB 区画を使用するような構成に変更されます。このときの新規区画での一時表スペースのコンテナーは、カタログノード区画 での一時表スペースコンテナーと同様のものが使用されます。 もしカタログノード以外の区画で使用中のコンテナー情報を用いたい場合には、”LIKE NODE 区画番号”オプションにてADD NODE（またはADDNODEオプションのDB2START)を実行して下さい。また、もし自分で明示的に新規区画で用いられる一時表ス ペースのコンテナー定義を指定したければ、”WITHOUT TABLESPACES”オプションにてADD NODE（またはADDNODEオプション のDB2START)を実行し、その後で各DBの一時表スペースに対して以下のようなコマンドを実行して一時表スペースのコンテ ナーを追加します。以下の例では、新しく追加されたDB区画「3」で使用されるコンテナーとして、ディレクトリー 「/MYCONTAINER」を指定しています。 ALTER TABLESPACE mytemp ADD （'/MYCONTAINER'） ON NODE （3） (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 97-98 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-3. データの再配布 新しいパーティションにデータを再配布します 1. ノード・グループ更新の定義 ALTER NODEGROUP mygroup ADD NODES(3) LIKE NODE 2 REDISTRIBUTE NODEGROUP mygroup UNIFORM ノード・グループmygroup中で、 全ての表スペース中の、全ての 表の中を新しく追加した パーティションを含めてデータ を再配布する または 2. ALTER NODEGROUP mygroup ADD NODES (3) WITHOUT TABLESPACES ALTER TABLESPACE MYTS ADD ( FILE ON NODES (3) '/x/y/z' 1025 ) ALTER TABLESPACE ･･･ ノード・グループ更新の定義 ノード指定コンテナー定義で 表スペースを新しい区分に拡 張します。 ノード・グループmygroup中で、 全ての表スペース中の、全ての 表の中を新しく追加した パーティションを含めてデータ を再配布する REDISTRIBUTE NODEGROUP mygroup UNIFORM (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：データの再配布 ノードグループへのパーティションの追加と除去は、ALTER NODEGROUPステートメントを使用します。 ALTER NODEGROUPステートメントでパーティションを追加する際、"LIKE NODE"オプションにより、ノードグループ内の既存 の他のパーティションと同じように表スペースのコンテナーを作成することが出来ます。 また、ALTER NODEGROUPステートメントの"WITHOUT TABLESPACES"オプションを使用することにより、ALTER NODEGROUP実行時 には新規DB区画に表スペースを作成しないようにすることができます。このオプションを用いた場合、追加したDB区画の表 スペース定義は、後からユーザがALTER TABLESPACEステートメントで明示的に指定します。 ALTER NODEGROUPを実行したノード・グループの表スペース中に表が存在しない場合、上記方法1では、ALTER NODEGROUPス テートメントだけで、パーティション・マップが更新されます。 それに対し方法２では、mygroupの中に定義された全ての 表スペースに対してALTER TABLESPACEを実行して新規DB区画のためのコンテナーが追加された時点でこのノードグループの パーティションマップが更新されます。 表が存在する場合、ALTER NODEGROUPを実行すると「SQL1759W」が返されます。この時点ではパーティションマップは新しい もの（新規追加のDB区画を含むもの）になっていません。REDISTRIBUTE NODEGROUPコマンドが実行された時点でパーティ ションマップが更新されます。 SQL1759W Redistribute nodegroup is required to change data partitioning for objects in nodegroup "MYGROUP" to include some added nodes or exclude some dropped nodes. SQLSTATE=01618 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 99-100 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-4. データベース・パーティションの削除 1. 各データベースのデータを再配布します host1 host2 host3 host4 ALTER NODEGROUP mygroup DROP NODE (3) REDISTRIBUTE NODEGROUP mynode UNIFORM 2. db2 drop node verifyを実行します メッセージSQL6035Wが表示される場合 （データベースはこの区画を使用中です） ① データを再配布します ② イベント・モニターを除去します ③ コマンドを再実行します メッセージSQL6034Wが表示される場合 0 1 2 3 host1 host2 host3 host4 0 0 0 0 db2nodes.cfg （ノードが使用されてない） 3. db2stop drop nodenum を実行します 0 1 2 host1 0 host2 0 host3 0 db2nodes.cfg (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：データベース・パーティションの削除 DB2 UDB EEEは、パーティション・データベース・システムからデータベース・パーティションを削除してデータベース構成 を変更する手段を提供します。 DROP NODE VERIFYコマンドを使用して、削除したいデータベース・パーティションを使用中のデータベースがあるかどうか をチェックすることができます。 データベース・パーティションを削除するには、db2stopコマンドでdrop nodenumオプションを発行します。このコマンドは db2nodes.cfgファイル中の全てのデータベース・パーティションを停止し、削除したいデータベース・パーティションに関 連する各データベースパスのディレクトリーを削除し、db2nodes.cfgから削除したいデータベース・パーティションのエン トリーを削除します。 db2stop drop NODENUM ノード番号 削除したいデータベース・パーティション上にデータが存在する場合、データベース・パーティションを削除する前に、全 てのデータベースに対して削除したいデータベース・パーティション上にあるデータを再配布しなければなりません。 1. 削除したいDB区画を使用しているすべてのノードグループに対して「DROP NODE」オプションを指定したALTER NODEGROUPコマンドを実行します。 2. REDISTRIBUTE NODEGROUPを使って、削除したいデータベース・パーティション上にあるデータを再配布します。 3. 削除したいデータベース・パーティションでdrop node verifyコマンドを発行して、このデータベース・パーティショ ンが使用されていない状態であることを確認します。 メッセージSQL6034Wが表示された場合、データベース・パーティションの削除処理に進んで下さい。 メッセージSQL6035Wが表示された場合、まだこの区画を使用中のノードグループ、あるいはイベントモニターが存在 しています。REDISTRIBUTE NODEGROUPコマンドを使用して削除したいデータベース・パーティション上からほかの データベース・パーティション上にデータを移動しなければなりません。さらにもしこの区画上に定義されたイベン トモニターが存在する場合にはそちらも削除されなければなりません。これらの処理を完了する前に、データベー ス・パーティションを除去することは出来ません。 4. db2stop drop nodenumコマンドを発行します。このコマンドはすべての区画を停止します。 5. db2startコマンドでデータベースを再起動します。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 101-102 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-5. データ再配布（REDISTRIBUTE NODEGROUP） カタログ区画からコマンドを発行しなければならない データを配分する三つの方法： ノード・グループ中の全てのノード上で均一に配分する TARGETMAP（ターゲット・パーティション・マップ）を使用する DISTFILE（配布ファイル）を使用する (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：データの再配布 REDISTRIBUTE NODEGROUPコマンドを使用してデータを再配布するには、以下の方法があります： １．ノード・グループの全てのデータベース・パーティション上で均一にデータを配分します。 ２．ターゲット・パーティション・マップを使用してデータを再配布します。 ３．配布ファイルを使用してデータを再配布します。 REDISTRIBUTE NODEGROUPコマンドは、カタログ・ノードからのみ実行することが可能です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 103-104 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-6. 再配布ユーティリティー：UNIFORMオプション UNIFORMオプション それぞれの4096個ハッシュ区分は、同じ量のデータをハッシュすると仮定します 各パーティションに対して同じ数のハッシュ区分がある新しい区分マップを生成する 手順 ALTER NODEGROUP GROUP1 ADD NODES (4) WITHOUT TABLESPACES ALTER TABLESPACE MYTS ADD (FILE 'x/y/z' 1024) ON NODES (4) REDISTRIBUTE NODEGROUP GROUP1 UNIFORM 既存のマップ 0 1 3 0 1 3 0 1 3 0 1 3 X X 0 1 3 0 1 3 0 1 3 0 1 3 0 1 3 X X 新しいマップ 0 1 3 0 4 3 4 1 4 0 1 X X 0 4 3 0 1 3 0 1 3 4 1 3 0 1 4 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：再配布ユーティリティー：UNIFORMオプション UNIFORMオプションを指定したREDISTRIBUTE NODEGROUPユーティリティーでは、それぞれの4096個のハッシュ区分は、同じ量 のデータをハッシュし、ノード・グループ中の全てのデータベース・パーティション上で均一にデータが配分されるいると 仮定します。すなわち各DB区画に対して同量のハッシュ区分を割り当てるようなパーティションマップを生成し、それに基 づいたデータ再配布を行います。 UNIFORMオプションは、最小量のデータ移動で、各データベース・パーティション上に同じ数のハッシュ区分を配置するよう にします。 REDISTRIBUTE NODEGROUPユーティリティーのUNIFORMオプションはデータ非均一の修正を提供しません。データ非均一の問題 が既に存在する時、UNIFORMオプションを使用しても問題の解決にはなりません。 こちらに示す例は、一つのデータベース・パーティションを追加した後の再配布の例です。このデータベース・パーティ ションは、ADD NODEまたはdb2startコマンドで追加されたものと仮定します。この例では、ALTER NODEGROUPステートメント により、GROUP1が新たにDB区画4を使用させ、ALTER TABLESPACEステートメントにより、この新しいDB区画上のコンテナーを 定義しています。続いて実行されるREDISTRIBUTE NODEGROUPコマンドにより、新しいパーティションマップが生成され、新 しいDB区画へデータが移動されます。 ノードグループがどのDB区画を使用中かを知るためのコマンドとして、LIST NODEGROUPSコマンドがあります。以下の例は、 ノードグループGROUP１がDB区画の0,1,3,4を使用中であることを示します。 $ db2 list nodegroups show detail NODEGROUP NAME PMAP_ID NODE NUMBER IN_USE ---------------------------- ------- ---------------------- -----IBMCATGROUP 0 0 Y IBMDEFAULTGROUP 1 0 Y IBMDEFAULTGROUP 1 1 Y IBMDEFAULTGROUP 1 3 Y GROUP1 3 0 Y GROUP1 3 1 Y GROUP1 3 3 Y GROUP1 3 4 Y 8 record(s) selected. (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 105-106 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-7. UNIFORM 例 ＃行数 10 20 5 10 5 15 15 5 既存の マップ 新しい マップ 0 1 3 0 1 3 0 1 0 1 3 0 1 3 2 2 各パーティション上の行数 0 35 1 30 0 20 1 25 2 20 3 20 既存 3 20 新しい パーティション２を追加 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：UNIFORM例 例で示したように、UNIFORMオプションは、各データベース・パーティションに同じ数のハッシュ区分になるように パーティション・マップを更新します。 例では新しいパーティション・マップは、各パーティション毎に２個のハッシュ区 分を持っています。 このオプションは、データが均一に配分されたかをチェックしません。配布の結果として、データは全てのパーティション 上に均一に配分されない場合があります。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 107-108 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-8. 再配布ユーティリティー：DISTFILEオプション DISTFILEオプション 各ハッシュ区分には違う量のデータが含まれる時に使用する 全てのデータベース・パーティションに対して同じデータ量となるよう 新しいパーティション・マップを生成する REDISTRIBUTE NODEGROUP GROUP1 USING DISTFILE ファイル名 既存 0 1 3 0 1 3 0 1 3 0 1 3 X 新しい X 0 1 3 0 1 3 0 1 3 0 1 3 0 1 3 X X X X 0 3 3 0 1 3 0 1 3 1 1 3 0 1 1 0 1 3 0 3 3 3 1 1 0 1 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：再配布ユーティリティー：DISTFILEオプション 各パーティション上でのデータが均等に分散されていない時、USING DISTFILEオプションを使用して再配布ユーティリ ティーの入力として配布ファイル（DISTFILE）を指定し、ノード・グループ中の全てのデータベース・パーティション上 で、データを均一に再配布することができます。 DISTFILEオプションは、データ非均一の修正の為に使用されます。このオプションは、入力として指定したデータ配布ファ イルに基づいて、新しいパーティション・マップを生成します。データ配布ファイルは、各ハッシュ区分にどれだけのデー タが割り当てられているかを示すもので、4096個のハッシュ区分に対して一つの正整数値を含みます。 db2splitプログラム で、入力ファイルをSPLITまたはANALYZEする時に配布ファイルは生成されます。 DISTFILEでは、行数、バイト数或は他のデータ単位で、各ハッシュ区分に対するデータ量を示すことができます。DISTFILE オプションによる再配布ユーティリティーを実行すると、ノード・グループ中の全DB区画にわたってデータをできる限り均 一に再配布するようなパーティションマップをDISTFILEの内容にもとづいて生成し、データの再配布を行います。 DISTFILEには、4096個の正整数値がCHARフォーマットで入っています。値の合計は、4294967295以下である必要がありま す。例えば、配布ファイルには、以下のような内容を含んでいます： 10223 1345 112000 0 ... この例では、ハッシュ区分2は、112000の重みを持ち、区分3（重みは0）には、データがまったくありません。 PARTITION（カラム名）のSQL関数を使用して、データベース・パーティションにわたって、既に表の中にロードされたデー タに対して現行のデータ配布ファイルを作り出すことができます。 （例） SELECT COUNT(*) FROM mytable GROUP BY PARTITION (col1) ORDER BY PARTITION (col1) ただしこの例のように実行すると行が一切割り当てられていないハッシュ値に対しては、何も値を返しませんので、例え ば以下のようにして０行が割り当てられているハッシュ値に０を返すような工夫が必要です。 1. INTEGER列 「c1」 一列のみからなる４０９６行の表mytempを作成する。列１には０から４０９５の値を順番に入れる。 2. 以下のようなSQLを実行する WITH temp1 (key, weight) AS (SELECT PARTITION(mypkey),COUNT(*) FROM mytable GROUP BY PARTITION(mypkey)) SELECT CASE WHEN temp1.weight IS NULL THEN 0 ELSE temp1.weight END FROM temp1 RIGHT OUTER JOIN mytemp on temp1.key=mytemp.c1 order by mytemp.c1 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 109-110 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-9. DISTFILE 例1 - 最大の表 # 行数 10 20 5 10 5 15 15 5 既存の マップ 新しい distfile マップ 0 2 3 0 1 3 2 1 10 20 5 10 5 15 15 5 各パーティションの行数 0 2 3 0 1 3 1 1 0 20 1 10 2 35 3 20 0 20 1 25 2 20 3 20 既存MAP使用 新しいMAP使用 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：DISTFILE 例１- 最大の表 この例は、ノードグループ内の特定の表（一番大きな表）の実際のデータ量を基にしたDISTFILEを使用して再配布していま す。再配布ユーティリティーは、非均一の配布を直すため、データベース・パーティション間で均一にデータを配分する パーティション・マップを生成します。 このオプションは、あくまでも特定の表データに基づいて最適なマップを生成します。ですから、このオプションによって 生成されたマップが、同じノードグループ中のすべての表を均一に分割するのに最適であるとは限りません。 このユーティリティーは、最小の行移動でこの機能を実現します。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 111-112 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-9. DISTFILE 例2 - 他の表 # 行数 15 15 5 5 15 10 10 10 既存の マップ 0 2 3 0 1 3 2 1 distfile 10 20 5 10 5 15 15 5 新しい マップ 0 2 3 0 1 3 1 1 各パーティションの行数 0 20 1 25 2 25 3 15 既存MAP使用 0 20 1 35 2 15 3 15 新しいMAP使用 DISTFILEは例１と同じ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：DISTFILE 例2 - 他の表 例２は、例１で再配布を行った場合、同一のノードグループ内にある他の表（DISTFILEと関連の無い表）がどのように再配 布されるかを示しています。REDISTRIBUTEユーティリティーは、提供されたDISTFILEに基づいて、新しいパーティション・ マップを生成します。従って、DISTFILEで示された各ハッシュ区分の重み付けと異なる重み付けとなる表に対しては均一な 再配布が行われない場合があります。 これは、ノード・グループ中の一つの表から作成したDISTFILEを使用した時に、発生する可能性がある現象の一つの例で す。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 113-114 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-10. 再配布ユーティリティー：TARGETMAP TARGETMAPオプション ユーザが配布の結果を制御したい時に使用します ユーザにより定義した入力パーティション・マップを使用します REDISTRIBUTE NODEGROUP GROUP1 USING TARGETMAP ファイル名 ユーザにより定義したパーティション・マップ 0 1 1 0 3 3 1 1 3 0 0 3 0 1 3 0 1 3 0 1 3 0 1 3 0 1 3 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：再配布ユーティリティー ：TARGETMAPオプション TARGETMAPオプションは、データベース管理者がパーティション・マップを独自に作成する場合に使用可能です。 このパーティション・マップは、オートローダーのANALYZEオプションを使用して作成することが出来ます。 データ配置を厳密に制御する為、PARTITIONまたはNODENUMBERカラム関数を使用してユーザがパーティション・マップを作成 することも可能です。（だだし、非常に手間のかかる作業となります。） オートローダーのANALYZEモードは、入力ファイルを分析して、パーティション上でデータを均一に配分するようなパーティ ション・マップを作成します。 TARGETMAPオプションは、与えられた新しいマップに基づいてノード・グループ中のデータを再配布します。パーティショ ン・マップがノード・グループ中に存在しないデータベース・パーティションを含んでいる場合、エラーを返します。 ターゲット・パーティション・マップが、対応するノード･グループ中に存在するデータベース・パーティションを含んでい なかった場合、そのデータベース・パーティションには再配布後データは存在しません。このようなデータベース・パー ティションは、REDISTRIBUTE NODEGROUPを実行する前または後で、ALTER NODEGROUP DROP NODEを使用して除去することが可 能です。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 115-116 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-11. TARGETMAP 例 ＃行数 既存の マップ 10 20 5 10 5 15 15 5 0 2 3 0 1 3 2 1 新しい マップ 各パーティションの行数 0 0 1 1 2 2 3 3 0 20 1 10 2 35 3 20 既存MAP使用 0 30 1 15 2 20 3 20 新しいMAP使用 TARGETMAP (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：TARGETMAP例 この例は、新しいパーティション・マップによって行を再配布しています。 TARGETMAPオプションでは、データの均一化の制御や、移動される行数もデータベース・マネージャーは制限しません (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 117-118 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-12. 再配布 ー エラー時のリカバリー 原因： ログ/データ・ファイル用スペースの不足 一つの表の再配置は１UOWで行われるため、最大の表が移動可能なだけのログ領域を確保すること ネットワーク/システム問題 データ再配布は１UOWで１つの表だけに対して行なう エラー発生時、ノード・グループ中の一部の表だけは再配布が必要 二つのリカバリー方法 REDISTRIBUTE NODEGROUP ... CONTINUE REDISTRIBUTE NODEGROUP ... ROLLBACK メッセージ・ファイル (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：再配布 - エラー時のリカバリー データ再配布操作中に、エラーが発生する場合があります。これは、ログやデータ・ファイル用スペースの不足や、 ネットワーク/システムの問題が原因で起る可能性があります。 データの再配布はノードグループ単位に実行しますが、表が１つ再配布する度にCOMMITが発行されます。ですから、 REDISTRIBUTEユーティリティーの実行中にエラーが発生した場合には、一部分の表は既に再配布されているが、同一ノード グループ内の他の表はまだ再配布されていない状態になる可能性があります。このとき再配布済みの表は新しいパーティ ションマップを使用しますが、再配布の終わっていない表は古いパーティションマップのままです。 エラーが発生した場合、二つのリカバリー方法があります： REDISTRIBUTE NODEGROUP ... CONTINUEオプション 前回失敗したREDISTRIBUTE NODEGROUP操作を続行します。つまり、再配布がまだ完了していない表に対して再配布を実行 します。例えば、再配布の間にデータベースのログ・ファイルが一杯になってしまった場合などは、ログ領域を拡張して からこのオプションによるREDISTRIBUTEを実行します。 REDISTRIBUTE NODEGROUP ... ROLLBACKオプション 前回失敗したREDISTRIBUTE NODEGROUP操作をロールバックし、再配布した表を元の状態にもどします。つまり前回の REDISTRIBUTEにて再配布に成功した表をすべてもとの配置に戻します。表は元のパーティション・マップに基づいた配置 に戻されます。 再配布操作の実行中に、一つのメッセージ・ファイルは、sqllibディレクトリーのサブ・ディレクトリー redistに書き込ま れます。ファイル名は以下の形式を持ちます。タイムスタンプ値はコマンドが発行された時間です。 データベース名.ノード・グループ名.タイムスタンプ （UNIXプラットフォーム） データベース名¥ノード・グループ名¥日付¥時間 （非UNIXプラットフォーム） (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 119-120 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 解説：再配布に必要なログ領域の見積もり 再配布をおこなう場合には、一番大きな表に着目し、その表の再配布に必要な分のログ領域を確保して下さい。 例えば、1000万行のデータが４区画に250万行ずつあり、これを5区画へ再配置するとすると、4区画からの50万行のDELETEと新区画への200万行の挿 入が必要になります。これだけの処理を行うためのアクティブログの領域が各区画でそれぞれ必要になります。 再配布に必要なログ領域の大きさは、まず何行のデータが動くのかを求め、以下のようにしておおよその大きさを見積もって下さい。 各記号は以下のとおり： RS: 表のレコード長（LONG DATAの分は含まない） NR： 挿入される行数 ni: 索引の数 ISi: 索引キーの長さ（IS1∼ISni） ＮCi: 索引ｉを構成する列数（NC1∼NCni） 表へ一行へ挿入するときに発生するログレコードの大きさ： 50バイト＋RS 索引へ１行追加するときに発生するログレコードの大きさ： 60バイト＋１２ｘNCi 従って一行挿入を行うのに必要なログ領域（これをＬＲとします）は： （50+RS)+(60+12xNC1+IS1)+(60+12xNC2+IS2).....+(60+12xNCni+ISni) 索引へのデータ挿入時には索引ページの分割が発生する可能性があります。索引ページの分割がどれほど発生するかは、索引ページのFreeス ペース、索引キーの長さ、挿入される行数などに依存します。「管理の手引き-計画」のなかに索引のサイズ見積もりに関する詳しい記述があり ます。そちらを参照の上、挿入前と挿入後での索引ページ数を見積もり、発生するページスプリットの回数を求めて下さい。索引のページスプ リットに伴うログ（IO）は、索引の置かれた表スペースのページサイズ（4K, 8K, 16K, 32K）をPG、索引iに発生したスプリットの回数をPSiと すると以下のようになります： PGｘPS1＋PGｘPS2＋......＋PGｘPSni さらにROLLBACKのためにリザーブされるログ領域の分も考慮しなければなりませんので、結果として挿入のためのログ領域は以下のようにして 見積もることができます： （LRｘNR＋IO）ｘ２ LOGRETAIN＝NOの設定になっているDBや、あるいはNOT LOGGEDオプションが設定されているLOB列の場合、LONGデータはログされません。オー バーヘッドとして64MBごとに１００バイトが必要ですが、通常は無視できるほどの大きさと言えます。 LOGRETAIN=ON、またはUSEREXIT=ONの設定になっている場合、LONGデータもログされます（LOBについては、NOT LOGGEDが設定されない場 合）。ただし、ROLLBACKのためにリザーブされるLOG領域はありませんので、このケースにおけるログ領域は、そのLONGデータの大きさをLSと すれば以下のようになります。： LS+（LRｘNR＋IO）ｘ２ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 意図的なブランクページです。 ( 121-122 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-13. 再配布の段階的実行 REDISTRIBUTEを実行するときの課題 再配布中の表はアクセス不可 再配布済み、またはまだ再配布の始まっていない表はアクセス可 大量のログを発生する可能性有り 再配布処理は既存の区画からのDELETE＆新区画へのINSERT 再配布する表の索引を削除することを考慮 既存の区画間でのデータ移動は発生しない Activeログは各区分で最大32GBまで （V6.1では4GB） ノード追加の後など、段階的にデータの再配布をする いきなり均一なデータ配置となるようなマップでいきなり再配置するのではなく、徐々に データを動かすようなマップを作成して、再配布を行う。 例えば１００GBのデータ移動を毎日１０GBずつ10日間かけてやる (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：再配布の段階的実行 REDISTRIBUTE NODEGROUPを実行すると、そのノードグループ内の表は順番に再配布処理がなされます。そして１つの表の再 配布が完了する度にCOMMITが発行されます。 REDISTRIBUTEを使用するときの考慮点として以下のようなものが挙げられます： 再配置中の表はアクセス不可 大量のログを発生する可能性有り ある表がアクセス不能になる期間の長さや発生するログの量（既存区画からのDELETE＆新区画へのINSERTを完了するのに必 要なログの量）は、対象となるノードグループに定義されている表の大きさや既存のDB区画の数、それに追加されるDB区画 の数に依存しますので、業務要件や確保可能なログスペースによっては、UNIFORMオプションを使って一気に新しい区画へ均 等なデータ配布を行うことができないケースがありえます。 このようなケースでの選択枝として： 再配置中の表へアクセスできなくなる事を避けたいため、別の表（新規区画を含んだ別ノードグループ内に作成）を作成 し、そこへSELECT＆INSERTする。INSERT完了後にRENAME TABLE 均一なデータ配置となるようなマップで一気に再配置するのではなく、徐々にデータを動かすようなマップを作成して、 再配布を行う。例えば１００GBのデータ移動を毎日１０GBずつ10日間かけてやる というような手法が考えられます。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 123-124 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-14. MAKEPMAPユーティリティー サンプルプログラムとして提供 目的に応じたパーティションマップを生成 生成されたパーティションマップは、TARGETMAPオプションのREDISTRIBUTEユーティリ ティーを使って適用 使用目的 段階的な再配布を実現するため、少しの行を新区画へ移動したい ある区画に対し、他よりも多くのデータを配置したい（新しく追加した物理ノードやディ スクは他よりも高性能であるケース） 指定されたDISTFILE、またはハッシュ値の分布の情報を使って最適なパーティションマッ プを生成したい (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：MAKEPMAPユーティリティー DB2のサンプルプログラムの一つにMAKEPMAPというプログラムがあります。これは「$HOME/sqllib/samples/c/makepmap.c」 として提供されているコードをコンパイルして使用します。 このプログラムを使用しますと以下のように要件に応じたパーティションマップを作成できます。生成されたパーティショ ンマップは、TARGETMAPオプションのREDISTRIBUTEユーティリティーを使って適用します。 目的 段階的な再配布を実現するため、少しの行を新区画へ移動したい ある区画に対し、他よりも多くのデータを配置したい（新しく追加した物理ノードやディスクは他よりも高性能である ケース） 指定されたDISTFILE、またはハッシュ値の分布の情報を使って最適なパーティションマップを生成したい (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 125-126 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 5-15. MAKEPMAPの使用例 4区画から5区画への段階的な再配置 各区画100万件、合計400万件入っているデータを5区画へ再配置 ＝＞ 各区画80万件 各区画から20万件の削除 ＆ 新区画への80万件の挿入 これを4回にわけて実行したい makepmap -f db2nodes.cfg -i pmap.in -o pmap.out -m 204 db2nodes.cfg 0 host0 0 host0s 1 host1 0 host1s 2 host2 0 host2s 3 host3 0 host3s 4 host4 0 host4s 1 1 1 1 1 -f ノード構成ファイル db2nodes.cfgファイルをコピーし、5列目に各区画にどれだけのデータを割り当てたいのか重みを指定する。各区画に均 等にデータを割り当てたければ、全ての区画に対して「１」を記述すれば良い ‐ ｉ現在のパーティションマップが収められているファイル 現在使用中のパーティションマップをdb2gpmapユーティリティーで取得して指定 -o 生成されるパーティションマップが収められるファイル この生成されたマップ指定してREDSITRIBUTEを実行する -m 移動されるデータ量の上限 移動されるパーティションマップのエントリーの最大数を指定する。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：MAKEPMAPの使用例 ここでは、4区画から5区画への段階的な再配置をする場合にMAKEPMAPをどのように使うかを見てみましょう。 各区画に100万件、計400万件が入っているデータを5区画へ再配置するケースを考えます。つまり、「各区画から20万件の削 除 ＆ 新区画への80万件の挿入」という処理が行われることになります。このとき一回のREDISTRIBUTEで均一なデータ配置 を行うのではなく、「各区画から5万件の削除 ＆ 新区画への20万件の挿入」を4回繰り返す方式にしたいとしましょう。 このケースでは、以下のようなコマンドを実行することになります。 makepmap -f db2nodes.cfg -i pmap.in -o pmap.out -m 204 ここで各オプションの意味は以下の通りです： -f ノード構成ファイル（デフォルト： db2nodes.cfg） 各区画にどれだけのデータを割り当てたいのか重みを指定するのに使います。具体的には、現在使用中のノード構成 ファイル（db2nodes.cfg）をコピーし、5列目に各区画にどれだけのデータを割り当てたいのか重みを指定します。 各区画に均等にデータを割り当てたければ、全ての区画に対して「１」を記述すれば良いことになります。 ‐ｉ 現在のパーティションマップが収められているファイル（デフォルト： pmap.in） 現在使用中のパーティションマップを指定します。db2gpmapユーティリティーで取得可能です。 -o 生成されるパーティションマップが収められるファイル（デフォルト： pmap.out） makepmapが生成するパーティションマップは、このオプションで指定したファイルへ書き出されます。実際のデータ 再配布は、このファイルをUSING TARGETMAPオプションで指定したREDSITRIBUTE NODEGROUPによって実行されます。 -m 移動されるデータ量の上限 移動されるパーティションマップのエントリーの最大数を指定する。この例では、一度のREDISTRIBUTEで行われる データ移動を20万件に抑えたいわけですから、20万件がパーティションマップのエントリー幾つ分に該当するかを算 出して指定します。データの偏りなし、と仮定すると、400万件＝4096エントリーであることから、「4096エント リー ｘ 20万件/400万件 = 204エントリー」が20万件分に該当することになります。 なお、この例では使用しませんが、これ以外のオプションとして、入力のDISTFILEを指定する-dオプション、DISTFILEの 代わりに「SELECT PARTITION(c1) FROM TABLE table1 GROUP BY PARTITION(c1)」結果が収められたファイルを指定す る-eオプションがあります。これらのオプションが指定された場合、-mオプションで指定された値は、「マップのエント リー数」ではなく、一度のREDISTRIBUTEで削除または挿入される最大の行数を示します。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 127-128 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 解説：MAKEPMAPの使用例 makepmapを実行すると、以下のようなメッセージが出力されます。 DB2 Universal Database EEE PMAP Generator Version 1.10 Output PMAP file pmap.out Max node number= 4 Weight for node[0]: 1 Weight for node[1]: 1 Weight for node[2]: 1 Weight for node[3]: 1 Weight for node[4]: 1 データは5区画へ均等に配分しま す。 一度に移動するマップのエントリーは最大204です。 Total user defined weigths:5 Input partition map is pmap.in Total table weights:4096 Maximum move weight per node is: 204 Node[0]: start 1024 target 816 moved 204 end 820 Node[1]: start 1024 target 816 moved 0 end 1024 Node[2]: start 1024 target 816 moved 0 end 1024 Node[3]: start 1024 target 816 moved 0 end 1024 Node[4]: start 0 target 816 moved 204 end 204 区画0から204エントリー分が取り除かれ、区画5へ 204エントリー分が挿入されるようなマップが生成され ます。最終的には5つの区画が816ずつのマップエント リーを持つことになります。 PMAP Generator completed with return code:0 今回生成されたマップで一度再配布を行ったのち、今度はこのマップを入力のマップとして新しいマップを生成、次の再配布処理を実 行することになります。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ブランク・ページです ( 129-130 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6. 高可用性システム お断り：当資料は、DB2 UDB V7.1（UNIX,PC) をベースに作成されています。 (一部、Fixpackに含まれるV7.2の機能についてもふれています。） ＜第２．００版＞２００１年１１月 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 目次 ６−１．高可用性DB2 UDB構成の考慮点 ６−２．ノード障害時のUDB EEEの振る舞い ６−３．DB2 UDB EEEの構成 ６−４．UDB EEEのリソースグループ （引き継ぐリソース） ６−５．NFSサーバー引継ぎに関する考慮点 ６−６．NFSサーバーの引継ぎ例 ６−７．NFSサーバーの引継ぎ設定 ６−８．HACMP環境におけるUDB EEE起動 ６−９．HACMP環境におけるUDB EEE引継ぎ ６−１０．HACMP環境におけるUDB EEE停止 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 131-132 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-1. 高可用性DB2 UDB構成の考慮点 インスタンス・グループとインスタンス・オーナー クラスター内で同一ユーザーID、グループID インスタンス作成 インスタンスの作成は、通常データベースが稼動するマシン上でのみ作成 インスタンスを作成したマシン以外がサービスを提供している場合、db2ilistコマンドによるインスタンスの表 示不可 インスタンス・オーナーのホーム・ディレクトリー 外部ディスク上に作成し、ノード障害時に引き継ぐ データ・ディレクトリー 外部ディスク上に作成し、ノード障害時に引き継ぐ Mutual Take Overなど、引継ぎ先でも別のDB区画が動く場合には、データベースパスやコンテナーパスが重複し てしまわないように注意すること 〔例） DBパス名/インスタンス名/NODExxxxをファイルシステムのマウントポイントにする TCP/IPポート /etc/servicesの定義をクラスター間で合わせる (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：高可用性DB2 UDB構成の考慮点 多くの考慮点がDB2 UDB EEとDB2 UDB EEEを使った環境で共通です。 特にMutual Take Overを指定しているなど、引継ぎ先でも別のDB区画が動く場合には、データベースパスやコンテナーパス が重複してしまわないように注意して下さい。 〔例） DBパス名/インスタンス名/NODExxxxをファイルシステムのマウントポイントにする (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 133-134 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-2. ノード障害時のUDB EEEの振る舞い カタログ区画のあるノードでの障害 データベースへの接続はすべてエラーとなる コーディネーター区画のノード障害 トランザクションは再実行が必要 データベースとのコネクションは失われる アプリケーションにはSQLCODE−１２２４が返る 非コーディネーター区画のノード障害 そのノードの持つデータへの参照、更新処理は停止 アプリケーションにはSQLCODE−１２２９が返る 非コーディネーター区画のノード障害（トランザクションと無関 係） トランザクションには影響無し (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：ノード障害時のUDB EEEの振る舞い DB2 UDB EEEはShared Nothingアーキテクチャーを採用していますが、各DB区画はそれぞれ連携してアプリケーションからの SQLを処理してゆきますので、一箇所の障害が全体におよぶ可能性があります。以下ではノード障害の発生した場所と、それ に伴う影響を見てゆきます。 カタログ区画のあるノードでの障害 データベースへの接続はすべてエラーとなります（あらゆるデータベース接続は必ずカタログ表への照会処理を伴うた め） コーディネーター区画のノード障害 その区画からのDB接続は不可です。 トランザクション実行中にコーディネーター区画のノードで障害が発生した場合、トランザクションはロールバックされ ます。 データベースとアプリケーションの間のコネクションは失われます アプリケーションにはSQLCODE−１２２４が返ります。 非コーディネーター区画のノード障害 そのノードの持つデータへの参照、更新処理はできなくなります。 トランザクション実行中にノード障害が発生した場合、トランザクションはロールバックされます。 アプリケーションにはSQLCODE−１２２９が返ります。 非コーディネーター区画のノード障害（トランザクションと無関係） この場合、トランザクションには影響がありません。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 135-136 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-3. DB2 UDB EEEの構成 DB2 UDB EEE実行モジュール配置 各ノードの内蔵ディスクに導入、もしくはNFS等を用いて共有 DB2インスタンスのホームディレクトリー配置 NFS等によりノード間で共有 NFSサーバーには、DB2クラスターノード、その他のノード、CWSなどの選択肢が存在する HACMPによるNFSサーバー引継ぎを行う場合、NFSサーバー用IPアドレスの引継ぎが必要 DB2 UDB EEEデータベース区画構成 DB2データベース区画の関連ファイル、ログと表スペース・コンテナー DB区画単位に他の物理ノードにサービスを引き継ぐことが可能 ２DB区画を持つ物理ノードの障害時に、それぞれ別々の物理ノードに引き継がせる構成も 可能 ノード障害時にIPアドレスは引き継がず、UDBのノード構成ファイル（db2nodes.cfg）の 変更で対応 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：DB2 UDB EEEの構成 DB2 UDB EEE実行モジュール配置 DB2 UDBの関連ファイルセット（/usr/lpp/db2_07_01以下）は各ノードの内蔵ディスクに導入しても結構ですし、もしく はNFS等を用いて各ノードで共有することもできます。 DB2インスタンスのホームディレクトリー配置 DB2インスタンス･オーナーのホームディレクトリーはNFS等によりノード間で共有していなければなりません。 NFSサーバーには、DB2クラスターノード、その他のノード、CWSなどの選択肢が存在します。 HACMPによるNFSサーバー引継ぎを行う場合には、NFSサーバー用IPアドレスの引継ぎが必要になります。 DB2 UDB EEEデータベース区画構成 DB2データベース区画のDB2関連ファイル、ログと表スペース・コンテナー 障害発生時には、DB区画単位に他の物理ノードにサービスを引き継ぐことが可能です。 ２DB区画を持つ物理ノードの障害時に、それぞれ別々の物理ノードに引き継がせる構成も可能です。（当然それぞれのDB 区画の関連ファイルシステムやコンテナーは別々のVGに作成されている必要があります） ノード障害時にIPアドレスは引き継がず、DB2 UDBのノード構成ファイルの変更で対応することができます。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 137-138 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-4. DB2 UDB EEEのリソースグループ DB2 ＵＤＢ ＥＥＥのモジュール（NFSを使って複数ノードで共有の場 合） /usr/lpp/db2_07_01ディレクトリ以下を引き継ぐ インスタンス・オーナのホーム・ディレクトリ 例）/home/udbinstディレクトリ以下を引き継ぐ DB2 ＵＤＢ ＥＥＥのデータベース部分 DB区画に関連するファイル、表スペースコンテナーを引き継ぐ ユーザ・アプリケーション（オプション） NFSサーバーのIPアドレス コーディネーターノードとしてクライアントからのアクセスを受け入 れるIPアドレス 引き継ぐ必要のあるファイルは全て外部ディスク上に作成すること (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：DB2 UDB EEEのリソースグループ （引き継ぐリソース） DB2 UDB EEEの環境で引き継ぐリソースとしては以下のようなものが考えられます。 DB2 ＵＤＢ ＥＥＥのモジュール（オプション） ＮＦＳマウントして使用している場合は引き継ぎが必要 /usr/lpp/db2_07_01ディレクトリ以下を引き継ぐ NFSサーバーの引継ぎをHACMPで行う場合、後述のNFSサーバー引継ぎに関する考慮点を参照 インスタンス・オーナのホーム・ディレクトリ インスタンス･オーナーのホームディレクトリーを提供するNFSサーバーが落ちた場合にはこれを引き継ぐ必要があり ます。 例）/home/udbinstディレクトリ以下を引き継ぐ 後述のNFSサーバー引継ぎに関する考慮点を参照 DB2 ＵＤＢ ＥＥＥのデータベース部分 DB区画に関連するファイル、表スペースコンテナーを引き継ぎます。このとき引継ぎ先に既に存在しているLVやファ イルシステムと名前が重複しないように気をつけて下さい。 例）/databaseではなく、/database/udbinst/NODE0000Xディレクトリ以下を引き継ぐ 共用ディスク上のLV名、ファイルシステム名は所有する可能性のあるノード間で一意であるようにして下さい。名前 にノード名やDB区画番号等を入れる事が望まれます。 ユーザ・アプリケーション（オプション） NFSサーバーのIPアドレス コーディネーターノードとしてクライアントからのアクセスを受け入れるIPアドレス 引き継ぐ必要のあるファイルは全て外部ディスク上に作成して下さい。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 139-140 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-5. NFSサーバー引継ぎに関する考慮点 HACMPによるNFS export, NFS mountの制御を行っている場合に、 NFSサーバーの引継ぎ先でもDB2が稼動している場合、引継ぎ時に問 題 問題の発生する構成例 NFSサーバー # exportfs /home/udbhome NFSクライアントかつNFSサーバーバックアップ # mount node1_svc:/home/udbhome /home/udbhome 引継ぎ発生時に、HACMPがNFS mountのumountを試み、その際に該当ファイルシステムを使用しているプロセスを killする HACMPによりNFS EXPORTさせるファイルシステム名と別のパスにNFS MOUNTさせる設定が可能 (HACMP V4.3 IX85426以降) NFSサーバー # exportfs /home/udbhome_local NFSサーバー、NFSクライアントかつNFSサーバーバックアップ、単なるNFSクライアント # mount node1_svc:/home/udbhome_local /home/udbhome NFSサーバーやNFSバックアップマシンは、NFSサーバー時には、自分自身へのNFS mountとなる Filesystems to NFS Mount には、"NFSマウントを行うマウントポイント","NFSサーバーにおける実際のファイ ルシステムのマウントポイント"を";"で区切って記述 Filesystems mounted before IP configuredはtrueで利用 デフォルトのfalseの場合、引継時にファイルシステムよりIPアドレスが先に復活してしまいます。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：NFSサーバー引継ぎに関する考慮点 HACMPによるNFSサーバーの引継ぎ HACMPによるNFS export, NFS mountの制御を行っている場合、NFSサーバーの引継ぎ先でもDB2が稼動している場合、以下の ようなケースで引継ぎ時に問題が発生します。 問題の発生する構成例 NFSサーバー # exportfs /home/udbhome NFSクライアントかつNFSサーバーバックアップ # mount node1_svc:/home/udbhome /home/udbhome 引継ぎ発生時に、HACMPがNFS mountのumountを試み、その際に該当ファイルシステムを使用しているプロセスをkill する HACMPによりNFS EXPORTさせるファイルシステム名と別のパスにNFS MOUNTさせる設定が可能 (HACMP V4.3 IX85426以降) ですので、以下のようにして問題の発生を防ぎます。 NFSサーバー # exportfs /home/udbhome_local NFSサーバー、NFSクライアントかつNFSサーバーバックアップ、単なるNFSクライアント # mount node1_svc:/home/udbhome_local /home/udbhome NFSサーバーやNFSバックアップマシンは、NFSサーバー時には、自分自身へのNFS mountとなる Filesystems to NFS Mount には、"NFSマウントを行うマウントポイント","NFSサーバーにおける実際のファイルシ ステムのマウントポイント"を";"で区切って記述 Filesystems mounted before IP configuredはtrueで利用 デフォルトのfalseの場合、引継時にファイルシステムよりIPアドレスが先に復活してしまいます。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 141-142 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-6. NFSサーバーの引継ぎ例(1) exportfs /udbhome_local mount node1_svc:/udbhome_local /udbhome mount node1_svc:/udbhome_local /udbhome node1_svc /udbhome_local NFSサーバー NFSクライアント、NFSバックアップサーバー (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：NFSサーバーの引継ぎ例(1) NFSサーバー、NFSクライアント共、EXPORTさせるファイルシステム名と別のパスにNFS MOUNTさせる設定になっていま す。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 143-144 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-6. NFSサーバーの引継ぎ例(2) exportfs /udbhome_local mount node1_svc:/udbhome_local /udbhome node1_svc /udbhome_local NFSサーバー NFSクライアント、NFSバックアップサーバー (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：NFSサーバーの引継ぎ例(2) NFSサーバーに障害が起こり、NFSサーバーの引継ぎをする例です。ローカルのファイルシステムであってもNFSマウントして いる点に着目して下さい。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 145-146 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-7. NFSサーバーの引継ぎ設定 設定例 # smit -C hacmp → Cluster Configuration → Cluster Resources → Cluster Resources → Change/Show Resources for a Resource Group Configure a Resource Group Type or select values in entry fields. Press Enter AFTER making all desired changes. [TOP] Resource Group Name Node Relationship Participating Node Names [Entry Fields] node1rg cascading node1 node2 Service IP Label [node1_svc] Filesystems [/udbhome_local] + + + Filesystems Consistency Check fsck Filesystems Recovery Method sequential + + Filesystems to Export [/udbhome_local] Filesystems to NFS Mount [/udbhome;/udbhome_local]+ Network For NFS Mount + ・ ・ Filesystems mounted before IP configured + [BOTTOM] [] true (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：NFSサーバーの引継ぎ設定 SMITでの設定画面の例です。 Filesystems to NFS Mount に、"NFSマウントを行うマウントポイント","NFSサーバーにおける実際のファイルシステムのマ ウントポイント"が";"で区切って記述されている点に着目して下さい。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 147-148 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-8. HACMP環境におけるDB2 UDB EEE起動例 例）ﾎｽﾄ node2 の場合 １ db2nodes.cfg (正常時） db2nodes.cfg (切戻し時） 0 node1 0 switch1 1 node2 0 switch2 2 node3 0 switch3 3 node4 0 switch4 0 node1 0 switch1 1 node1 1 switch1 2 node3 0 switch3 3 node4 0 switch4 ある ① db2nodes.cfg内に 自Nodeの ｴﾝﾄﾘｰがあるか？ ③ db2start nodenum 1 restart hostname node2 port 0 netname switch2 db2start nodenum 1 ② NG 無い ﾒｯｾｰｼﾞに OK ④ ”SQL1063N"が 返されたか？ n<5 ⑥ ⑤ 何回目ﾘﾄﾗｲ？ Sleep，n++ n>=5 正常終了 異常終了 １ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：HACMP環境におけるDB2 UDB EEE起動例 HACMPにおけるDB2 UDB EEE起動Shellの例です。 DB2 UDB EEE環境においては、起動時と引継ぎ時のロジックが異なります。 1. 起動条件の確認 正常な状態からの起動なのか、障害によりtakeoverしていたマシンの切戻し作業での起動なのかを判断 これから起動しようとしているDB区画が前回どのマシン上で起動していたかをdb2nodes.cfgより判別 起動しようとしているマシンと前回起動していたマシンが同一であれば正常状態からの起動 異なっていた場合にはtakeover後の切戻しによる起動 2. 正常な状態での起動 db2start nodenum A restartノードを１つ１つ起動するためrestartオプションを指定し起動情報を他のノードに通知 3. 切戻し状態からの起動 db2start nodenum A restart hostname B port 0 netname C A ： 起動するＤＢのノード番号 B ： 起動するマシンのホスト名を指定 C ： 起動するマシン上のインターフェースを指定 4. 正常起動の確認 db2startコマンドは正常に終了するとメッセージとして” SQL1063N"を返す これを利用して正常起動できたか確認 5. リトライ数の確認 6. コマンドのリトライ コマンドをリトライする場合には、何秒か間を取ってから実行 また何度目のリトライかカウントしておく (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 149-150 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-9. HACMP環境におけるDB2 UDB EEE引継ぎ例 ① db2start nodenum X restart hostname port NewPort netname NewNet ② NewHost NG 正常起動 OK？ n>=3 OK Sleep， n++ n<3 異常終了 ③ 整合状態 OK？ OK NG ④ 引継ぎ区画で Restart Database 整合状態 OK？ OK NG 異常終了 正常終了 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：HACMP環境におけるDB2 UDB EEE引継ぎ例 ノード障害のためにDB区画の引継ぎが必要な場合、その引継ぎ対象となる区画をRESTARTオプション付きのDB2STARTで立ち上 げます。このとき、新しくその区画が立ち上がるノードのホスト名、区画間通信で使われるポート番号、スイッチのラベル 名なども併せて指定することにより、db2nodes.cfgファイル（ノード構成ファイル）が書き換えられます。 DB2NODES.CFGの変更情報は稼動中の他の区画にも伝えられますので、ある一つの区画の引継ぎのために全区画を停止しなけ ればならない、ということはありません。 以下に引継ぎ時フローの例を示します (注：番号はフローにおける番号であり、順序を示すものではない） 1. 障害ノードで稼動していたDB区画を別のノードで立ち上げます。このとき、この区画は停止していなければなりませ ん。停止していない区画に対してDB2START...RESTARTを行うと、SQL6072Nが返されます。 db2start nodenum X restart hostname NewHost port NewPort netname NewNet X： 障害が発生したDB区画の区画番号 NewHost： Takeover先のマシン上のホスト名 NewPort： Takeover先のマシンで既に稼動しているDB区画の数に従って指定。 例えば、既に1つDB区画が稼動していてPORT 0が使用されているならば、次の1を指定 NewNet： Takeover先のマシン上で使用している高速ネットワーク（SPスイッチなど）のラベル名 2. 正常に再起動できたか確認 db2startコマンドは正常に終了するとメッセージとして”SQL1063N"を返す。これを利用して正常起動できたか確認 3. 整合状態の確認 「GET DB CFG FOR DB名」を実行、「整合状態のデータベース = YES」が返されることを確認。NOの場合には破損回 復が必要 4. 破損回復 RESTART DATABASEコマンドを使って破損回復を走らせる。AUTORESTART＝YESに設定されている場合は不要。その場 合、DBが活動化された時点で自動的に破損回復が走る。 -注意DISKを引き継いだ後のDBの再立ち上げは、必ずDB２が使用するDISKがアクセス可能になってから行ってください。例えばDMS 表スペースで使用しているRawデバイスは、importvgが実行されると所有者がrootになってしまいますが、chownで所有者を インスタンスオーナーにしてからDB再起動を行ってください。そうでないと、そのデバイスを使用する表スペースがOFFLINE やROLLFORWARD保留状態になってしまいます。 OFFLINE状態はALTER TABLESPACE...SWITCH ONLINE、ROLLFORWARD保留状態はROLLFORWARD DATABASEにて解消します。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 151-152 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-10. HACMP環境におけるDB2 UDB EEE停止例 １ 接続あり ② Force Application (YY) 注１ ③ ２ n>=5 n<5 ⑥ 接続無し ① List Applications for Database dbname ⑤何回目ﾘﾄﾗｲ？ Sleep，n++ １ NG 異常終了 n<5 ⑤ 何回目ﾘﾄﾗｲ？ db2stop nodenum X ﾒｯｾｰｼﾞに SQL1064N"が ④” 返されたか？ n>=5 OK 正常終了 ⑥ Sleep，n++ 異常終了 ２ 注１ YYはApplHandleの値を設定する Auth Id Application Appl. Application Id DB # of Name Handel Name Agents -------- -------------- ---------- ------------------------------ -------- ----TYUKI01 db2bp.exe 420 9889BEA3.0411.980324014402 MYDB 00 1 UDBSYS02 db2bp.exe 240 98898427.0408.980324071450 MYDB 00 1 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：HACMP環境におけるDB2 UDB EEE停止例 接続状況の確認 db2 list applications for database Ｘ データベースへの接続が存在しない場合コマンドは”SQL1611W”を返す これを利用してアプリケーションの接続が存在するか確認 接続の強制終了（ROLLBACK処理） db2 force application (XX) list applicationsコマンドの出力結果をもとにアプリケーションを１つ１つ切断 ＸＸにはAppl Handleを指定 FORCE APPLICATIONはROLLBACK処理の実行なので、長く更新中のトランザクションは終了されるのに時間がかかる。 KILLしてしまうことも考慮 データベースの停止 db2stop nodenum A ノード毎にデータベースを停止 正常停止の確認 db2stopコマンドは正常に終了するとメッセージとして”SQL1064N"を返す これを利用して正常停止できたか確認 リトライ数の確認 コマンドのリトライ コマンドをリトライする場合には、何秒か間を取ってから実行します (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 153-154 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 6-11. DB2 UDB EEE付属HACMP/ES引継ぎサンプル フェールオーバー/回復やユーザー定義イベントのためのサンプル・ スクリプト サンプルスクリプト /usr/lpp/db2_07_00/samples/hacmp/es/以下 UDB EEE引継ぎ用スクリプト /usr/lpp/db2_07_00/samples/hacmp/es/rc.db2pe HACMP ES 用の DB2 固有のユーザー定義イベント DB2 インスタンスの NFS ファイル・サーバーのフェールオーバースクリプト ネットワークのフェールオーバースクリプト SP GUI Perspective の監視イベントを定義するためのスクリプト サンプルスクリプト群のインストール・スクリプト SP Perspective の問題管理 (pman) リソースの管理スクリプト (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 解説：DB2 UDB EEE付属HACMP/ES引継ぎサンプル フェールオーバー/回復やユーザー定義イベントのためのHACMP/ES用サンプル・スクリプトが提供されておりますので、参考 にして下さい。 サンプルスクリプト /usr/lpp/db2_07_01/samples/hacmp/es/以下 UDB EEE引継ぎ用スクリプト /usr/lpp/db2_07_00/samples/hacmp/es/rc.db2pe HACMP ES 用の DB2 固有のユーザー定義イベント DB2 インスタンスの NFS ファイル・サーバーのフェールオーバースクリプト ネットワークのフェールオーバースクリプト SP GUI Perspective の監視イベントを定義するためのスクリプト サンプルスクリプト群のインストール・スクリプト SP Perspective の問題管理 (pman) リソースの管理スクリプト (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 155-156 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 DB2 UDB EEEにおける運用 （補足資料） お断り：当資料は、DB2 UDB V7.1（UNIX,PC) をベースに作成されています。 (一部、Fixpackに含まれるV7.2の機能についてもふれています。） ＜第２．００版＞２００１年１１月 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 DB2 UDB EEEにおける運用（補足資料）内容 1.DB2 UDB EEEにおける運用に関する質問と回答 この補足資料は、IBM製品に対する技術的なQ&Aシステムである「 Smart Answer」 に入力された質問の中から 参考となるQ&Aを抜き出したものです。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 157-158 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 1.DB2 UDB EEEにおける運用に関する質問と回答 Q1. <<< QUESTION >>> 2001/05/21 10:02:28 現在、数百 TB クラスの DB を UDB EEE で実現することを提案しておりますが、 バックアップ/リストアについて教えて下さい。 構成は UDB EEE の各ノードにディスクと複数テープ装置をつけ、 テーブルスペース単位に TSM にてバックアップを取得することを想定 していますが、以下のことは可能でしょうか？ １．各ノードに各々複数のテープ装置を装着した場合、複数のテーブルスペースを TSM にてオンラインバックアップを同時に実行し、複数のテープ装置への書き出しを 同時に実行することは可能でしょうか？ ２．１をうけて複数のテープ装置から、テーブルスペース単位の 同時リストアは可能でしょうか？ (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 A1. <<< ANSWER >>> 2001/05/22 10:36:42 １． はい、オフラインバックアップはできませんが、オンラインでしたら可能です。 また、ひとつの表スペースのバックアップであっても、「 OPEN n SESSIONS 」を指定することで、複数の I/O セッション を TSM に対して張ることができます。 要件が、単にひとつの DB のバックアップの高速化を図りたい、というのでしたら、明示的に BACKUP コマンドを各表ス ペースに実行するよりも、複数の I/O セッションを使った DB のフルバックアップを取るようにするのが良いかと思われま す。その方がバックアップイメージが一つになりますので、運用が簡単になるでしょう。基本的には定期的な DB フルバッ クアップ取得を行い、特に重要な表スペースや高い頻度で更新される表スペースについて、DB フルバックアップより高い頻 度で表スペースバックアップを取る、という運用にしてはいかがでしょうか？ ２． はい、やはり ONLINE オプションを指定することで可能です。 表スペース単位のバックアップ/リストアを行う場合、DB 構成パラメーターを LOGRETAIN=RECOVERY または USEREXIT=ON の設定にし、リストア後は必ず ROLLFORWARD を行わなくてはならないことに注意して下さい。 また、ある表スペースのみが壊れた場合には、その表スペースのバックアップからの RESTORE＆ROLLFORWARD で回復できま すが、DB が完全に壊れてしまったときには、必ず一度 DB のフルバックアップから RESTORE をし、そのあとで表スペース のバックアップを当ててゆくような回復が必要になることにご注意下さい。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 159-160 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 Q2. <<< QUESTION >>> 2001/06/27 19:44:39 AIX V4.3.3 DB2 EEE V7.1 + FixPak3 logpath にロー・デバイスを指定した場合において、 UserExit を使用してアーカイブ・ログを管理する方法について確認させてください。 Q1) logretain=Recovery userexit=Yes 上記以外に設定しなければならないパラメーターはないという理解で正しいですか？ Q2) USEREXIT プログラムのソースコードのコメントをみると特別な指定は必要ないようなのですが、 logpath がロー・デバイスであることによって、何か設定が必要な点や注意点がありましたら、 ご教授ください。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 A2. <<< ANSWER >>> 2001/06/28 09:20:34 A1. 正しいです。 なお、Logpath の切替は、通常のファイルの場合と同様で NEWLOGPATH を指定します。 A2. 特別な点 ･2次ログファイルは割振られません ･必ず USEREXIT を利用してください ･ROLLFORWARD 時には、｢ OVERFLOW LOG PATH ｣ を指定してください 以下の場合は利用しないで下さい。 ･DpropR のソース DB となる場合 ･sqlurlogAPI を使用する場合 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 161-162 ) DB2 UDB 運用管理 DB2 UDB EEEにおける運用 Q3. <<< QUESTION >>> 12/22/2000 11:30:16 AM AIX 4.3.3 / HACMP 4.4 and UDB EEE 7.1 環境下でシステム構築を行っていますが、 db2start / stop の際のパラメータについて以下の質問があります。 1. db2start nodenum 1 restart と db2start nodenum 1 restart hostname hosta port 0 netname neta との使い分けについて SIL の資料を確認したのですが、自ノードのエントリーが 有る場合は db2start で、無い場合は全部のパラメータを指 定せよ と理解したのですが、すべてのケースで全部のパラメータを指定する場合、（前回自ノードで動いている如何に かかわらず）何か不具合が発生するのでしょうか? できれば処理の単純化から常に全部のパラメータ付で行いたいのですが。 2. 複数のノード同時に切り戻し処理を行うケースについて db2start オプションによる切り戻し処理（ある DB ノードが稼動するホストが異なった場合）が平行して複数発生した 場合、db2nodes.cfg ファイルには不整合は起きないと考えて良いでしょうか。 3. UDB EEE 回復処理のトリガーについて 上記２つの質問とは種類が異なりますが、EEE が回復した際には、全ノード整合性＝ＹＥＳ で確認できることは理解し たのですが、逆に回復処理を行わなければならない状況の際には、どのようなメッセージ・ステータスを元に行うべきで しょうか。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 A3. <<< ANSWER >>> 2000/12/22 7:08:50 PM A1) 常に全部のパラメータ付きで実施しても問題ありません。 ただし、例え db2nodes.cfg を書き換える必要が無くても db2nodes.cfg を書き換える作業が発生します。 A2) 問題ありません。 ただし、db2start プロセスは同時に複数起動できません。 既に db2start 処理が行われている場合には SQLエラー（ SQL6036N ）が返ります。 ですので、このエラーを受け取った場合には時間をあけて再実行するロジックなどを検討する必要があります。 A3) 電源障害などで DB2 エンジンが強制終了してしまった後に、DB2 を起動する際には DB 構成パラメータの整合性 が YES かどうか確認してください。 NO であれば、回復処理（ CrashRecovery ）を実施する必要があります。 (C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部 ( 163-164 )