異種プラットフォーム間におけるDB2 UDBデータベース移行ガイド

最新推荐文章于 2019-06-14 15:48:07 发布

gold_star

最新推荐文章于 2019-06-14 15:48:07 发布

阅读量1.2k

点赞数

分类专栏： DB2 文章标签： DB2

DB2 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

1 はじめに

この資料は異なるプラットフォーム間におけるデータベース移行の手順をガイドするものです。異種プラットフォーム間においては、データベースのバックアップイメージを使用したデータ移行を行うことができませんので、環境情報およびデータベースオブジェクトを個別に移行する必要があります。また、チューニングに関しては考慮しておりませんので、データベース移行後に改めてチューニングを行う必要があります。対象はデータベース部分のみで、アプリケーションやストアード・プロシージャ−の移行に関しては触れておりませんので注意してください。

また、ターゲット（移行先）における言語環境（データベースのコードページおよびOSの言語環境）、ノード数はソース（移行元）と同じにすることを前提とします。この二つを変更する場合は、別の考慮点が必要となります。

コードページとはDB2のデータベース内に実際に格納されているデータの文字コードタイプです。ソースとターゲットのコードページを変更するためには、移行中に文字コードの変換が必要になります。ソースからDEL形式でEXPORTすれば、抽出したEXPORTファイルはテキスト形式ですので、OSコマンド等のツールで文字変換することができます。また、データの格納にLOADを使用すれば、LOAD時にコードページを変換することができます。心当たりがない場合は、月並みですが「見つけることができなければ管理できない」と納得して、この記事を読み進んでください。
アプリケーションが出力する文字コードとデータの文字コードを合わせるために、OSの言語環境はデータベースのコードページと同じにすることをお勧めします。データベースのコードページを変更する場合は OS の言語環境も変更する必要があります。この場合、アプリケーションが使用している文字コードを全てターゲットの文字コードに変換する必要が生じます。
EEEの場合、ノード数を変更する場合は、ターゲットに作成するテーブルスペースやテーブルの配置を考慮する必要があります。また、ソースから抽出したデータベースオブジェクトや設定パラメータの見直しが必要です。

2 ソース（移行元）で行う作業

2.1 環境情報およびデータベースオブジェクトの抽出
データベースは、環境変数、DB2 プロファイル・レジストリ、データベース・マネージャー構成パラメータ、データベース構成パラメータなどによって制御されます。従ってこれらの項目についても移行を行う必要があります。ただし、プラットフォームによって異なるパラメータもありますので、これらのパラメータは、移行の際に変更が必要です。抽出した項目は、ファイルなどへ出力・編集し、スクリプトなどにしてターゲットへ適用を行うことが可能です。

2.1.1 DB2 プロファイル・レジストリの抽出
DB2 UDB環境では、DB2 プロファイル・レジストリに保管されているエントリーによって制御されます。DB2 プロファイル・レジストリ情報の入っているファイルは直接編集したり、変更したりすることができません。db2set コマンドを使用して値を変更したり、値を参照したりすることができます。

[ 例 ] DB2 プロファイル・レジストリ情報をdb2set.txtに保存します。

$ db2set -all > db2set.txt

2.1.2 データベース・マネージャー構成パラメータの抽出
１つのインスタンスに1つのデータベース・マネージャー構成パラメータファイルが存在します。パラメータ情報は $INSTHOME/sqllib/db2systm ファイルに格納されていますが、直接編集することはできません。また、複数のインスタンスを移行する場合は、各インスタンスでパラメータを抽出する必要があります。

[ 例 ] DB2 コマンドdb2 getを実行し、パラメータをdbm_cfg.txtファイルに保存します。

$ db2 get dbm cfg > dbm_cfg.txt

2.1.3 データベース構成パラメータの抽出
データベース構成ファイルはデータベースごとに存在します。パラメータ情報は、/データベースディレクトリ/インスタンス名/NODEnnnn/SQLnnnnn/SQLDBCON というファイルに格納されていますが、直接編集することはできません。詳しいパラメータと値のリストについては、マニュアル「DB2管理の手引き」を参照して下さい。

[ 例 ] <DATABASE>データベース構成パラメータをdb_cfg.txtファイルに保存します。

$ db2 get db cfg for <DATABASE>>db_cfg.txt

EEEにおけるデータベース構成パラメータの抽出の注意点
EEE環境では、データベースは複数のノードをまたがって作成されるため、データベース構成ファイルは、各データベースのノードごとに存在します。従って、抽出も各データベースのノードごとに行う必要があります。ノードごとに、DB2コマンドを実行して抽出します。例えばノード0のパラメータをdb_cfg_node0.txtファイルに抽出するには、以下のコマンドを実行します。

$ db2 get db cfg for <DATABASE> > db_cfg_node0.txt

ノードを切り替えるには、環境変数 DB2NODE を変更します。

$ export DB2NODE=<NODE> (Windows環境ではC:\> set DB2NODE=) 
$ db2 terminate

変更を反映させるために、export (set) した後は必ずデータベースへの接続をterminateしてください。続けてデータベース構成パラメータを抽出するためには再度データベースへ接続する必要があります。

2.1.4 データベースオブジェクトの抽出
データベースオブジェクトの抽出には、db2look ツールの提供する機能の一つ、データベースオブジェクト再作成機能が便利です。db2look に以下のオプションを使用して、指定したデータベースの全てのユーザーによって作成された全てのオブジェクトの DDL をファイルへ出力し、抽出を行います。

データベースを指定
オブジェクトを作成した全てのユーザーを指定
データベースオブジェクトを抽出
- （テーブル、ビュー、自動要約表、別名、インデックス、トリガー、主キー、参照制約、検査制約、ユーザー定義特殊タイプ、ユーザー定義構造タイプ、ユーザー定義関数)
ユーザー定義ノードグループ・ユーザー定義バッファープール、ユーザー定義テーブルスペースを抽出
DDLを出力するファイルを指定

[ 例 ] TESTデータベースの全てのユーザーによって作成されたデータベースオブジェクトのDDLをdb2look.sqlファイルへ出力します。

$ db2look -d TEST -a -e -l -o db2look.sql

$ cat db2look.sql 
-- この CLP ファイルは DB2LOOK バージョンを使用して作成されました 7.2 
-- タイム・スタンプ: (火) 13時40分05秒 JST
-- データベース名: TEST 
-- データベース・マネージャーのバージョン: 
-- データベース・コード・ページ: 

CONNECT TO TEST; 
-----------------------------------
-- NODEGROUPS の DDL ステートメント -- 
----------------------------------- 
CREATE NODEGROUP "NG123" ON NODES 
            (1, 
             2, 
             3); 
             
------------------------------------ 
-- BUFFERPOOLS の DDL ステートメント --
------------------------------------ 
CREATE BUFFERPOOL "TEST_BP" SIZE 12800 PAGESIZE 8192 NOT EXTENDED STORAGE; 

CREATE BUFFERPOOL "TEST1_BP" SIZE 100 PAGESIZE 8192 NOT EXTENDED STORAGE; 

CONNECT RESET; 
CONNECT TO TEST; 

------------------------------------ 
-- TABLESPACES の DDL ステートメント -- 
------------------------------------ 

CREATE REGULAR TABLESPACE SINGLEA IN NODEGROUP NG0 PAGESIZE 8192 MANAGED BY DATABASE 
        USING (DEVICE '/dev/vx/rdsk/sharedg/SINGLEA_N0_C1'131072, 
                       DEVICE '/dev/vx/rdsk/sharedg/SINGLEA_N0_C2'131072) ON NODES (0) 
        EXTENTSIZE 32 
        PREFETCHSIZE 224
        BUFFERPOOL TEST 
        OVERHEAD 24.100000 
         TRANSFERRATE 0.900000; 
CREATE TEMPORARY TABLESPACE
        TSTMP8K IN NODEGROUP IBMTEMPGROUP PAGESIZE 8192 MANAGED BY SYSTEM 
        USING ('/tstmp/tstmp8k_N1_C1/tmpdir', 
                       '/tstmp/tstmp8k_N1_C2/tmpdir') ON NODES (1) 
        USING ('/tstmp/tstmp8k_N2_C1/tmpdir', 
                       '/tstmp/tstmp8k_N2_C2/tmpdir') ON NODES (2) 
        USING ('/tstmp/tstmp8k_N3_C1/tmpdir', 
                       '/tstmp/tstmp8k_N3_C2/tmpdir') ON NODES (3) 
        EXTENTSIZE 32
        PREFETCHSIZE 224 
        BUFFERPOOL TEST_BP 
        OVERHEAD 24.100000 
        TRANSFERRATE 0.900000;
------------------------------------------------ 
-- 表の DDL ステートメント "DB2INST1 "."RIREKI"
------------------------------------------------ 

CREATE TABLE "UDB7EEE "."RIREKI" ( 
                       "CD" CHAR(8) NOT NULL , 
                       "EDA" DECIMAL(8,0) NOT NULL , 
                       "BUNRUI_CD" CHAR(8) , 
                       IN "SINGLE" ; 
-- 表の索引の DDL ステートメント "DB2INST1 "."RIREKI" 

CREATE INDEX "DB2INST1 "."RIRKI_FK1" ON "DB2INST1 "."RIREKI" 
                       ("BUNRUI_CD" ASC); 
                       
-- 表の 1 次キーの DDL ステートメント "DB2INST1"."RIREKI" 

ALTER TABLE "DB2INST1 "."RIREKI" 
        ADD PRIMARY KEY 
                      ("CD",
                      "EDA"); 
                      
 - 表の外部キーの DDL ステートメント "DB2INST1 "."RIREKI" 
 
 ALTER TABLE "DB2INST1 "."RIREKI" 
         ADD CONSTRAINT "SQL010926132120840" FOREIGN KEY
                       ("CD") 
         REFERENCES "DB2INST1 "."RIREKI" 
                       ("CD") 
         ON DELETE NO ACTION 
          ON UPDATE RESTRICT;

2.2 データの抽出
データの抽出にはDB2 EXPORTコマンドを使用します。

2.2.1 EXPORT
EXPORTユーティリティは、データベースからオペレーティング・システム・ファイル (いくつかの外部ファイル形式のいずれか) にデータを抽出します。データ移行のためには表ごとに

$ db2 export to <EXPORT_FILE> of del select * from <TABLE>

を使用してデータを抜き出します。ある特定の行だけを抜き出すときはWHERE句を指定します。

■DEL形式とIXF形式
データ抽出にかかる時間および抽出したファイルサイズは、DEL形式とIXF形式による違いはほとんどありません。テストデータによると、抽出時間はそのファイルサイズに依存しているようです。ファイルサイズはレコード数だけでなく、レコード長にも依存していますので、レコード数 x レコード長で、おおまかなファイルサイズを見積もることができます。また、DEL形式ではデータタイプがCHARやDECIMALの場合、定義サイズに満たない部分は " "（空白文字）や "0" で補完されて出力されますので、生データよりもサイズが大きくなります。

EEEにおけるEXPORTの注意点
EEEのデータベース移行の場合、IXF形式では複合PARTITIONING KEY情報を正しく抽出することができないので、注意してください。また、ターゲット表が複数ノードにまたがっている場合は、データの LOAD 前に SPLIT操作が必要になりますので、SPLIT可能であるDEL形式でEXPORTする必要があります。

EEEにおける並列EXPORT
EEEでは、ソース表が複数ノードにまたがっている場合に、EXPORTをノードごとに並列に実行することで高速に処理することができます（図1参照）。例えばソース表が3ノードにまたがっている場合、約3分の1の時間で EXPORT 可能です。各ノードで実行する EXPORT 文は以下のようになります。

$ db2 export to <EXPORT_FILE> of del select * from <TABLE> where
nodenumber(<COLUMN_NAME>) = current node

where nodenumber(<COLUMN_NAME>) = current nodeを指定することで、環境変数DB2NODEで指定されるノードに格納されているデータだけを抽出することができます。これを全ノードで並列に実行することでパフォーマンスが向上します。例えば、ソース表が3ノードにまたがっていれば、3並列で処理を実行することで、3分の1の時間で処理することができます。

図1 生データサイズに対するEXPORTファイルサイズと処理時間

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

3 ターゲット（移行先）で行う作業

3.1 環境準備
移行の前にプロダクトの導入や初期設定を行います。ここではすべてrootユーザーで操作を行います。

3.1.1 ユーザー／グループ作成
OSのコマンドを使用して、インスタンスオーナーのためのユーザーを作成します。プロダクト導入時にインスタンスを作成する場合は、インスタンスオーナーのユーザー／グループは導入時に作成されます。インスタンスが複数必要な場合は、すべてのインスタンスのためのユーザーを作成する必要があります。

インスタンスオーナーのユーザー／グループ
分離ユーザー／グループ
管理サーバー／グループ（必要である場合のみ）

3.1.2 日本語環境の設定
日本語に関する環境変数の設定を確認して下さい。通常はOSの日本語環境とデータベースのコードページは同じに設定します。

3.1.3 ディスク準備
次の領域を準備する必要があります。基本的にはソースの物理設計情報を元に準備してください。

プロダクト導入のための領域
データベースが使用する領域
- 一時表用表スペース、ユーザー表スペース、ログ領域、バックアップ使用領域などが必要です。表スペースが使用しているコンテナのサイズは db2look コマンドで抽出したDDLから参照することができます。
ソースから抽出したデータを一時的に格納する領域
- ディスクを作成する手順はプラットフォームによって異なりますが、最終的に必要なディスク領域が使用可能であれば問題ありません。

3.1.4 プロダクト導入＆FixPak 適用
プロダクトを導入して、FixPak を適用します。製品に関する情報は

$ db2licm -l

コマンドによって確認できます。

3.1.5 ホスト名解決の確認
/etc/hostsファイルを編集し、ホスト名 IP アドレスを設定しておきます。または、DNSでホスト名を解決できるようにします。

3.2 インスタンス作成と設定
インスタンスが複数個存在する場合は、ここで行うファイルの編集、データベースの作成などをインスタンスごとに行う必要があります。

3.2.1 TCP/IPサービスポートの設定・ノード間通信用サービスポートの設定
rootユーザーで /etc/servicesファイルを編集します。ポート番号は、現在未使用の番号であれば、ソースが使用しているポート番号と異なっていても何ら問題はありません。これらの設定はプロダクトの導入時に設定することもできます。手動で設定する場合は以下の手順に従ってください。

■TCP/IP
DB2 インスタンス用にポート番号を設定します。

<サービス名> ポート番号

ここで設定した<サービス名>をデータベース・マネージャー構成パラメータ SVCNAME に設定します。

[ 例 ] /etc/servicesファイルの設定

db2inst1 50000/tcp

EEE FCM（Fast Communication Manager）の設定
この設定はEEEのみ必要で、ノード間で通信を行うための設定です。特にEEEではインスタンスを作成する前にFCMを設定しておく必要があります。複数のノードを使用する場合、連続したポート (各論理ノードに1つずつ) の範囲を予約する必要があります。ポート・エントリーは DB2_<インスタンス> のように記述します。2番目のエントリーは DB2_<インスタンス>_ENDのように記述します。

DB2_<インスタンス>            ポート番号    ← 始めのポート番号 
DB2_<インスタンス> _END      ポート番号    ← 最後のポート番号

例えば4つのデータベース区画を実行するデータベース区画サーバーの場合、ポート範囲として 4つの連続したポートを指定する必要があります。

[ 例 ] インスタンスdb2inst1が4論理ノードを使用する場合

DB2_db2inst1      50002/tcp
DB2_db2inst1_END 50005/tcp

3.2.2 インスタンス作成
rootユーザーでdb2icrtコマンドを使用して作成します。作成後、$INSTHOME/<インスタンス>/sqllib ディレクトリが作成されます。$INSTHOMEは、インスタンスオーナーユーザーのホームディレクトリです。プロダクト導入時にインスタンスを作成することもできます。

[ 例 ] インスタンスオーナーをdb2inst1、フェンスユーザーをdb2fencとしてインスタンスを作成します。

$ /usr/lpp/db2_07_01/instance/db2icrt -u db2fenc db2inst1

EEEインスタンスの設定
EEEインスタンスの場合は、以下の設定が追加で必要です。

■$INSTHOME/.rhosts ファイルの設定
インスタンスオーナーのユーザー権限でインスタンスオーナーのホームディレクトリに作成します。ノード上でインスタンス・オーナーがrshコマンド実行を許可するために必要なファイルです。ホストとインスタンスとの関連付けを行います。ファイル内に + と入力します。
[ 例 ] .rhosts ファイルの設定例

$ cat .rhosts +

■$INSTHOME/sqllib/db2nodes.cfgファイルの設定

db2nodes.cfgノード構成ファイルは、インスタンス作成時に自動的に作成されます。ホストとノードのマッピングを定義します。このファイルはデータベース・マネージャーが停止状態でのみ編集可能です。編集はインスタンスオーナーのユーザー権限で行います。編集が完了したら、データベース・マネージャーを開始し、ノードごとに開始メッセージが表示されることを確認して下さい。db2nodes.cfg の記述方法は以下のとおりです。

ノード番号 ホスト名 論理ノード番号 [ ネット名 ]

ノード番号
固有のノード番号（0〜999が可能）を定義し、昇順です。一度ノード番号を割り当てた後は、変更することはできません。
論理ノード番号
ノードの論理ポート番号を定義します。物理ノードの1番目の論理ポートは、必ず0から始めます。
ネット名
それぞれが独自のホスト名を持つ、複数の活動状態のTCP/IPインターフェースを持ったホストをサポートするために使用されます。

[ 例 ] 1つのホスト（WS）に4つの論理ノードを設定する場合

0 WS 0 
1 WS 1 
2 WS 2 
3 WS 3

3.3 環境情報の適用およびデータベースオブジェクトの作成
インスタンスオーナーのユーザー権限で行います。ソースで抽出した情報を適用していきます。ソースで抽出できなかったデータベースオブジェクトは作成します。適用に際しては抽出したものをそのまま適用するのではなく、ターゲット環境（ディスク、メモリ等）に適したチューニングが基本的に必要となります。

3.3.1 DB2 プロファイル・レジストリの設定
2.1.1 で抽出したdb2set.txtファイルの項目を、

$ db2set <PARAMETER> = <VALUE>

という形式で設定します。設定可能なレジストリはdb2setコマンドに lr オプションを使用して確認できます。ソースとターゲットのOSが異なる場合は、SQLプロシージャのパラメータなどパラメータをそのまま使用できない場合がありますので、適用するべきパラメータの選別を行ってから適用してください。設定後はdb2stop/db2start でdb2を再起動することで設定が有効となります。

[ 例 ]

$ db2set DB2_HASH_JOIN=YES 
$ db2set DB2_RR_TO_RS=YES 
$ db2set DB2COMM=TCPIP 
$ db2set DB2_PARALLEL_IO=*

3.3.2 データベース・マネージャー構成パラメータの設定
2.1.2 で抽出した dbm_cfg.txtファイルの項目を、

$ db2 update dbm cfg using <PARAMETER> <VALUE>

という形式で設定します。ソースの環境にあわせて、変更が必要なパラメータを変更します。また、以下の例のように、複数のパラメータを続けて設定することも可能です。設定後はdb2stop/db2startでdb2を再起動することで設定が反映されます。

[ 例 ]

$ db2 update dbm cfg using
INTRA_PARALLEL YES 
MAXAGENTS 200 
NUM_INITAGENTS 5 
FCM_NUM_BUFFERS 4096 
FCM_NUM_RQB 2048 
FCM_NUM_CONNECT -1 
FCM_NUM_ANCHORS -1

3.3.3 データベース作成
データベースは、create databaseコマンドで作成します。

[ 例 ] TESTデータベースを /database上に日本語EUC コードセット、jpテリトリーで作成します

$ db2 create database TEST on /database using codeset IBM-eucJP territory jp

EEEでのcreate databaseの注意点
EEEではcreate databaseを行ったノードがカタログ・ノードとなります。また、例における/databaseディレクトリをノードごとに作成しておく必要があります。

3.3.4 データベース構成パラメータの設定
2.1.3 で抽出したdb_cfg.txtファイルの項目から必要なパラメータを選択し、ソースの環境に合わせて変更してから適用します。

$ db2 update db cfg for <DATABASE> using <PARAMETER> <VALUE>

という形式で実行します。この適用はすべてのデータベース接続がなくなった時点で有効となります。

[ 例 ]

$ db2 update db cfg for TEST using 
DBHEAP 4000 
LOGBUFSZ 512 
UTIL_HEAP_SZ 5000 
LOCKLIST 10000 
SORTHEAP 2560 
SORTHEAP 5120
NUM_IOCLEANERS 4 
NUM_IOSERVERS 12

EEEでのデータベース構成パラメータの設定
EEEでは、DB2NODE環境変数を変更してノードごとに設定する必要があります。

$ export DB2NODE=<NODE> 
$ db2 terminate 
$ db2 connect to <DATABASE> 
$ db2 update db cfg for <DATABASE> using <PARAMETER> <VALUE>

3.3.5 データベースオブジェクトの作成
2.1.4 で抽出したDDLファイルdb2look.sqlを使用してデータベースオブジェクトを作成します。DDLはターゲットの環境にあわせて編集を行う必要があります。表スペースが使用するコンテナ名の変更は必須です。また、バッファープールなどメモリに関する項目などは、ターゲットの環境にあわせてチューニングして下さい。表スペース SYSCATSPACE、TEMPSPACE1、USERSPACE1作成のための DDL も抽出されています。これらの表スペースはターゲットでデータベースを作成した時点ですでに作成されていますので、この部分を削除して下さい。

[ 例 ] 編集したdb2look.sql DDLを使用したデータベースオブジェクトの作成

$ db2 connect to <DATABASE>
$ db2 -tf db2look.sql

3.4 データの格納
データの格納にはLOADあるいはIMPORTを使用することができますが、パフォーマンスを考慮して、できるだけLOADを使用することをお勧めします。LOADとIMPORT の違いは「データ移動ユーティリティ手引きおよび解説書」

を参照してください。

3.4.1 LOAD
パフォーマンスを比較した場合LOADの方がIMPORTよりも高速ですので、初期データの格納にはLOADがお勧めです。LOADを使用すれば、新しく作成した表やすでにデータが入っている表に、大量のデータを効率よく移動することができます。このユーティリティは、ラージ・オブジェクト (LOB) やユーザー定義タイプ (UDT) を含むすべてのデータタイプを処理できます。IMPORTは SQL INSERTを実行するのに対し、LOADは形式設定したページをデータベースに直接書き込むため、IMPORT よりも処理が高速です。LOADはトリガーを起動したり、参照制約や表制約の検査を実行したりしません (索引の一意性の妥当性検査を除きます) が、全データを一様に移行する際にはLOADを使用して問題ありません。また、複数の入力ファイルを一度にLOADに渡すことができます。参照制約および表制約の検査の実施方法は後で記述します。

■REPLACEモードとINSERTモード
データが入っていない場合、REPLACEモードとINSERTモードでパフォーマンスの違いはありません。機能の違いは以下のとおりです。

REPLACE
- 表から既存のデータをすべて削除してから、ロード・データを挿入します。表定義と索引定義は変更されません。
INSERT
- 既存の表データに変更を加えることなく、ロード・データを表に追加します。

■索引とRUNSTATS
索引はLOADを実行する前にあらかじめ作成しておいた方が、LOAD終了後に索引を作成するよりも全体の処理の時間が短くなります。
また、RUNSTATSはLOAD実行中に同時に行うことでパフォーマンスが上がります。
これはLOADコマンドに

STATISTICS YES AND DETAILED INDEXES ALL

オプションをつけることで実行可能です。ただし、データの移行を段階的に行う場合は全データ移行が終わってからRUNSTATSを実行することをお勧めします。

■制約違反の検査
LOADした表に表検査制約または参照保全が定義されている場合は、LOAD操作の後にその表が検査保留状態になっていることがあります。LOADした表の検査保留状態は、その表に対応する SYSCAT.TABLES項目のSTATUSフラグに示されます。LOADした表を使用可能にするには、STATUSに値として N (通常の状態を示す) を指定しなければなりません。
検査保留状態を除去するには、SET INTEGRITY ステートメントを使用します (SQL 解説書を参照)。 SET INTEGRITYステートメントは表を検査して制約違反がないかどうかを調べ、その表の検査保留状態を解除します。すべてのLOAD操作がINSERTモードで実行される場合、SET INTEGRITY ステートメントはデフォルトでは制約を増分的に処理します(つまり表のうち追加された部分だけを検査して制約違反がないかどうかを調べます)。例えば、

$ db2 load from <EXPORT_FILE> of del insert into <TABLE> 
$ db2 set integrity for <TABLE> immediate checked

制約違反がないかどうかを検査するのは <TABLE> のうち追加部分だけです。追加部分だけを検査して制約違反がないかどうかを調べることにより、表全体を検査するよりも時間が短くてすみます。これは、大きな表にデータを少しだけ追加した場合に特に有効です。

■ANYORDER ファイルタイプ修飾子
ANYORDER は、LOADがサポートするファイルタイプ修飾子の一つです。この修飾子を指定すると、LOADするデータの順序を保証しませんので、LOADプロセス中にその順序を維持する必要がある場合は、使用しないで下さい。cpu_parallelism オプションに関連して使用され、SMPシステムではパフォーマンスが向上します。（cpu_parallelismの値が1の場合、このオプションは無視されます。）

EEEのLOAD
EEEの場合、複数ノードにまたがるターゲット表にデータを格納する場合は、LOADする前に EXPORTファイルをSPLITユーティリティを使用してターゲット表のノード数に合わせて分割しておく必要があります。このときに複数ファイルをソースとして指定可能です。また、SPLITできるソースファイルはDEL形式のみです。

■オートローダー
SPLIT と LOADを実行するツールがオートローダーです。オートローダーの SPLIT_AND_LOADモードを使用するとSPLITとLOAD を別々に実行するよりもパフォーマンスが向上します。設定は構成ファイルを編集して行います。

LOADはLOADフェーズと BUILDフェーズに分かれます。SPLIT_AND_LOADモードでは、SPLITの結果がそのまま LOADの入力ファイルになりますので、SPLITのパフォーマンスがLOADフェーズのパフォーマンスに影響します。

■ANYORDER ファイルタイプ修飾子
4ノード以上をまたがる表のLOADの場合、ANYORDERを指定すると、複数ノードで並列にSPLITを行い、パフォーマンスを向上させることができます。デフォルトでは SPLITを行うノード数は１つです。ANYORDER を指定すると LOAD は以下の計算式でSPLIT を行うノード数を算出し、並列にSPLITを行います

表の使用するノード数/4 + 1 （ただし、小数点以下は切り捨てられます。）

[ 例 ] ノード数式SPLITを行うノード数

ノード数	式	SPLIT を行うノード数
3	3/4 + 1 = 1.75 → 1 (小数点以下切り捨て)	1
4	4/4 + 1 = 2.00 → 2	2

表が使用するノード数が3以下だと小数点以下は切り捨てられるため、SPLITを行うノード数は1となり、並列に SPLITは行われません。従って、ノード数が4以上を使用する表の LOADにANYORDERを指定すると、パフォーマンスを向上させることができます。

図2はANYORDER修飾子を指定したとき、指定しない時のデータのLOAD処理時間を比較しています対象表は4ノードを使用しています。ANYORDER 修飾子を指定すると、LOADはSPLITを2ノードで並列に実行します。以下の結果では、ANYORDER修飾子を指定した方が処理時間が短くなり、LOADパフォーマンスが向上しています。

図 2 ANYORDER オプションを指定して SPLIT する NODE 数が変わった場合の処理時間の比較

3.4.2 IMPORT
LOADに比べるとコストがかかりますので、できる限りLOADを使用するようにしてください。すでに格納しているデータに変更を加えながらデータを追加したい場合のみ、IMPORT を使用する必要があります。IMPORT 実行時には統計情報を取得することはできませんので、IMPORT終了後にRUNSTATSを実行してください。 IMPORT は、実行時に必ず制約条件を検査します。これにより参照制約をつけた状態ではつけていない状態に比べてパフォーマンスがかなり（テストでは10倍以上）遅くなります。IMPORTをした後に参照制約をつけてください。

EEE での IMPORT の注意点
IMPORTはターゲット表に対して排他ロックを取得しますので、EEEにおいても並列処理を行うことができません。

■CREATE モード（IXF のみ）、INSERTモード、INSERT_UPDATEモード、REPLACEモード

CREATE
- 表定義と行の内容を作成します。データが DB2 表、副表、または階層からエクスポートされたものである場合は、索引が作成されます。このオプションを階層に対して使用する場合、データが DB2 から EXPORT されたものであるなら、タイプ階層も作成されます。このオプションは、IXF ファイルでのみ使用できます。
  EEE では CREATE モードは使用できない
  PARTITIONING KEYはソース表どおりに作成されませんので、EEEのIMPORTではCREATEモードを使用しないようにしてください。
INSERTE
- 既存の表データに変更を加えることなく、データを表に追加します。
INSERT_UPDATE
- データをターゲット表に追加するか、またはターゲット表のうち主キーが一致する既存の行があればそれを更新します。
REPLACE
- データ・オブジェクトを切り捨てることにより表から既存のデータをすべて削除してから、インポート・データを挿入します。表定義と索引定義は変更されません。このオプションを使用できるのは、表が存在する場合だけです。 DATALINK列のある表に対しては無効です。階層間でのデータ移動にこのオプションを使用した場合、個々の副表ではなく階層全体についてのデータだけが置換できます。

■DEL形式とIXF形式の違い
生データのデータ件数が大きくなるにつれ、DELの方がIMPORTの処理時間がかかる傾向にあるようです。処理時間は、単純にデータサイズだけでなく、データタイプにも依存しているようです。図3にREPLACEモードでの測定結果を示します。

図3 DEL形式とIXF形式のIMPORT処理時間の比較

EEE INSERT BUF 指定での IMPORT
EEEでは、インポート・ユーティリティでバッファー挿入を使用可能にすることができます。これによって、データのインポート時に発生するメッセージ交換が少なくなるため、パフォーマンスが向上します。ただし、バッファー挿入の失敗に関する詳細は戻されないため、このオプションを有効にするのはエラーが報告される心配がない場合だけにしてください。バッファー挿入を要求するには、DB2 バインド・ユーティリティを使用します。 INSERT BUFオプションを使って、データベースに対してインポート・パッケージ db2uimpm.bnd を再バインドする必要があります。たとえば、

$ db2 connect to <DATABASE> 
$ db2 bind db2uimpm.bnd insert buf

ただし、INSERT_UPDATEパラメータが指定されたインポート操作に対してはバッファー挿入機能を使用することはできません。

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

4 おわりに

以上でデータベースの移行は終了です。この後、アプリケーションの移行、パラメータのチューニングを忘れずに行ってください。

gold_star

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
異種プラットフォーム間におけるDB2 UDBデータベース移行ガイド

1 はじめにこの資料は異なるプラットフォーム間におけるデータベース移行の手順をガイドするものです。異種プラットフォーム間においては、データベースのバックアップイメージを使用したデータ移行を行うことができませんので、環境情報およびデータベースオブジェクトを個別に移行する必要があります。また、チューニングに関しては考慮しておりませんので、データベース移行後に改めてチューニングを行う必要があります。
复制链接

扫一扫

专栏目录