Technical Blog テクニカルブログ
  1. HOME
  2. テクニカルブログ
  3. IIASからDb2 Warehouseへの定義・データ移行を検討してみた
2023年5月9日
テクニカルTIPS データファブリック

IIASからDb2 Warehouseへの定義・データ移行を検討してみた

投稿者：ビッグデータ編集者

概要

皆さん、こんにちは。
Db2 Warehouse(エンジンはDb2)をベースとした、ハイパフォーマンスDWHアプライアンスとして好評を博したIBM Integrated Analytics System(以下IIAS)ですが、現在販売フェーズにおいてはその役割を終え、その後継ソリューションへの注目が高まってきています。今回は、同じエンジンであるDb2が内部で稼動するIIASからDb2Warehouseへの移行の検討を実施しました。

2023年5月時点において考えられる移行先

  1. オンプレミス環境におけるDb2 Warehouse 

    • IIAS向けに作成したオブジェクト類はもちろん、運用で作成されたIIAS内で動作するスクリプト類なども変更無し、または最小限の変更にて移行できる可能性があります。

  2. Db2 Warehouse on Cloud

    • IBM CloudもしくはAmazon Web Services(AWS)環境にDb2 Warehouse on Cloudをデプロイし、使用することが可能です。クラウド移行、特にSaaSサービスをご希望の場合にはこちらが候補となります。
      この場合、IIAS向けに作成されたオブジェクト類については移行可能ですが、運用で作成されたIIAS内で動作するスクリプト類であったり、またシェルへのログインが前提となるオペレーションが必要な場合には、構成の変更など考慮が必要になりそうです。

  3. 他のRDBMS
    • Db2に限らず、CP4DS/NPS(Netezza Performance Server for IBM Cloud Pak for Data System)の他、Amazon Redshift、Google BigQueryといった他のDBMSも考えられるかもしれません。いずれも弊社にてお取り扱いがございます。

確認観点

ここでは、上記のうち主に [1. オンプレミス環境におけるDb2 Warehouse] に関して検討を行ってみたいと思います(Db2 Warehouse on Cloudについての検討も一部記載しております)。
確認観点としては、以下のようなものになります。

  1. オブジェクトの移行確認

    • テーブル、ビュー、GRANT、SQLのみで実装可能なFUNCTIONおよびStored Procedureが主。IIAS側にてdb2lookコマンドでDDLを抽出し、新環境に反映。

  2. データの移行確認
    1. IBM純正の移行ツール(db_migrate_iias)の単体挙動確認
    2. db_migrate_iiasを組み込んだスクリプトの動作確認
    3. 従来からのDb2汎用データアンロード/データロードコマンドを組み込んだスクリプトの動作確認

なお、今回は以下のような確認は行っておりません。

  • 移行先のDb2動作環境自体の構築観点
    • Db2 Warehouseが動作する環境自体の構築に関しては今回は対象外です。
  • データ量観点
    • 上記の通り、手順とツールの動作確認までを行います。
  • バックアップ・リストアを使用しての移行

移行元、移行先ともDb2ベースのエンジンということで、バックアップ・リストアでもデータ移行を行える可能性はありますが、今回はDb2のパーティション数を揃える、データ量を合わせるなどの環境起因によりバックアップリストアでの移行確認は対象外となります。

バックアップ・リストアでの移行可能か現時点では不明ですが、少なくともCPUエンディアンを揃える必要があるとは考えられます。

https://www.ibm.com/docs/en/db2/11.5?topic=dbrs-backup-restore-operations-between-different-operating-systems-hardware-platforms

IIASにおけるDb2はPower CPUのLinux上で動作しています。リンク先表中における”Linux on IBM Power Systems for Little Endian”となります。つまり、バックアップ・リストアでの移行を検討する場合、少なくとも移行先もLittle endianのCPUを使用する環境である必要があると考えられます。

検証の成功基準

上記を踏まえ、以下のような評価ポイントにて検証を行ってみました。

実施内容評価ポイント
IIAS-Db2 Warehouse移行検証　　対象の定義およびデータを移行できること。検証を踏まえ、移行方式をある程度定型化できること。

まずは対象の移行ということ自体を行えるのか、そのうえでそのための方式が決して1つ1つ個別対応が必要となるような非現実的なものではなく、ある程度定型化(可能であれば自動化)できるようなものであるのかどうかを確かめる、という意味となります。

確認方法

1. オジェクトの移行確認 

まず、データベースオブジェクトの移行に関する確認となります。
以下のような方法が考えられます。

Db2のdb2look コマンドを用いることで、テーブルなど各種オブジェクト類の定義をテキストファイルでDDLとして抽出することが可能です。そのファイルより、IIAS固有の記述、環境由来による記述の他、あらかじめ設計した内容を踏まえて不要なものを削除ないしコメントアウトして保存します。
その編集版DDLファイルをDb2 Warehouseに適用、反映することで、定義移行が完了します(適用にはdb2 -tvf <ファイル名>, dbsql -ef <ファイル名>等で行います)。
以下の例では、db2lookコマンドを用いてBLUDBデータベースのオブジェクトを抽出していますが、-z <スキーマ名>オプションを併用することでDB内個別のスキーマ単位で、-t <テーブル名>を指定することで個別のテーブル単位で定義を抽出することもできます。

(例)

[bluadmin@node0101-fab – Db2wh ~]$ db2look -e -d bludb -x > `date +%Y%m%d_%H%M%S`_db2look-e-d_bludb-x.txt 2>&1

[bluadmin@node0101-fab – Db2wh ~]$

[bluadmin@node0101-fab – Db2wh ~]$ ls -lrt  | tail

：

(略)

-rw-rw-r–.  1 bluadmin db2iadm1   14907129 Feb 13 15:40 20230213_153943_db2look-e-d_bludb-x.txt

[bluadmin@node0101-fab – Db2wh ~]$

抽出したテキストファイルには各種Db2オブジェクトが含まれています。こちらを編集(不要箇所の削除が主)し、Db2 Warehouse側に適用します。

(例)

[bluadmin@node0101-fab – Db2wh ~]$ vi 20230213_153943_db2look-e-d_bludb-x.txt

：

(略)

：

————————————————

— DDL Statements for Table “BLUADMIN”.”DBTEST”

————————————————

CREATE TABLE “BLUADMIN”.”DBTEST”  (

                  “COL1” VARCHAR(50 OCTETS) ,

                  “COL2” VARCHAR(50 OCTETS) )

                 DISTRIBUTE BY HASH(“COL1”)

                   IN “USERSPACE1”

                 ORGANIZE BY COLUMN;

————————————————

— DDL Statements for Table “BLUADMIN”.”TEST_TABLE7″

————————————————

CREATE TABLE “BLUADMIN”.”TEST_TABLE7″  (

                  “C1” INTEGER ,

                  “C2” BIGINT ,

                  “C3” DECIMAL(10,0) ,

                  “C4” DATE ,

                  “C5” TIMESTAMP ,

                  “C6” VARCHAR(10 OCTETS) ,

                  “C7” VARCHAR(10 CODEUNITS32) )

                 DISTRIBUTE BY RANDOM IN “USERSPACE1”

                 ORGANIZE BY COLUMN;

：

(略)

：

—————————————-

— Authorization Statements on Database

—————————————-

GRANT CONNECT ON DATABASE  TO ROLE “TEST_ROLE” ;

：

(略)

：

——————————————–

— Authorization Statements on Tables/Views

——————————————–

GRANT SELECT ON TABLE “TEST_SCHEMA”.”TEST_TABLE123″ TO USER “USER1  ” ;

GRANT SELECT ON TABLE “TEST_SCHEMA”.”TEST_TABLE999” TO USER “USER2  ” ;

：

(略)

：

[bluadmin@node0101-fab – Db2wh ~]$

なお、ユーザー定義ファンクション、ライブラリーを作り込んでいる場合には、SQLのみで完結するものを除き上記のようなDDLファイルの移行といった方法ではなく、移行先環境において再度のコンパイル、インストールが必要となることにご注意ください。

2.1. IBM純正の移行ツール(db_migrate_iias)の単体挙動確認

データ移行としては、まずIBM社純正の移行ツールであるdb_migrate_iiasコマンドを確認します。

db_migrate_iias コマンドは移行元で実行します。移行元(IIAS)で以下を指定して実行することで、IIASの対象テーブルデータの抽出、アンロード(エクスポート)から移行先(Db2 Warehouse)へのテーブル作成、データ転送、ロードまで一括で行える優れものです。

  • 移行元/移行先DB名
  • 移行元/移行先スキーマ名
  • 移行元/移行先テーブル名
  • 移行先ホスト名(IPアドレス)
  • 移行元/移行先のDB接続ユーザ名/接続パスワード
  • 移行先のテーブル作成有無

上記はあくまで指定可能なパラメータの一部となりますので、詳細は以下も併せてご確認いただけますと幸いです。
https://www.ibm.com/docs/en/ias?topic=overview-db-migrate-iias-command

このようにdb_migrate_iias は強力なツールですが、確認を行ってみた限りでは下記が少し気になります。

  • 移行先のテーブルを直接作成可能だがテーブルのオーナー、GRANTまでは移行されないため、別途設定要。
  • 移行元/移行先で直接通信を行えない環境の場合には使用不可能(SSHポートフォワード等の工夫を行って、複数サーバーまたぎではあっても透過的に通信を行えるようにすることで回避できる可能性はあります)。
  • データ転送時の帯域制御に関しての考慮はされていないため、移行元でサービスを止めずに業務サービス提供を継続したままデータ移行したい場合など、実行して問題無いかは検討が必要。

この辺りを理解いただいたうえでご要件と合うようであれば、db_migrate_iias コマンドを使用したデータ移行というのは具体的な選択肢として検討の価値ありと考えられます。

db_migrate_iias コマンドの実行例です。

(例)

# IIAS側のBLUDBデータベース、BLUADMINスキーマ上のTEST_TABLEというテーブルのデータを抽出し、

# xxx.xxx.xxx.xxxに存在するDb2 Warehouseの同DB、スキーマ、テーブルにデータロードします。

[bluadmin@node0101-fab – Db2wh ~]$ db_migrate_iias -shost 127.0.0.1 -sdb BLUDB -sschema BLUADMIN -suser BLUADMIN -spass ******** -thost xxx.xxx.xxx.xxx -tdb BLUDB -tschema BLUADMIN -tuser BLUADMIN -tpass ******** -t TEST_TABLE -tempdir /scratch/home/bluadmin/test/iias-db2wh/02_migrate/20220207152437/temp -logdir /scratch/home/bluadmin/test/iias-db2wh/02_migrate/20220207152437/log –preserve-tempdir

[DEBUG] Created temporary directory at /scratch/home/bluadmin/test/iias-db2wh/02_migrate/20220207152437/temp/com.ibm.migration.iias.QGyh99

[INFO] Searching for “BLUADMIN”.”TEST_TABLE” on source…

[INFO] Searching for “BLUADMIN”.”TEST_TABLE” on target…

[INFO] Preparing to unload “BLUADMIN”.”TEST_TABLE”…

[INFO] Starting the transferring process…

INSERT 0 2

[INFO] The transfer has finished successfully

[INFO] “BLUADMIN”.”TEST_TABLE” -> “BLUADMIN”.”TEST_TABLE” time: 0.60735 (0:00:00)

[INFO] Total time: 1.36290693283 (0:00:01)

[INFO] Migration summary

        Source table: “BLUADMIN”.”TEST_TABLE”

        Target table: “BLUADMIN”.”TEST_TABLE”

        Success:      True

        Elapsed:      0.607347011566

        Start time:   2022-02-07 15:24:39.626722

Log file: /scratch/home/bluadmin/test/iias-db2wh/02_migrate/20220207152437/log/db_migrate_iias-20220207_152437.789235.log

More logs: /scratch/home/bluadmin/test/iias-db2wh/02_migrate/20220207152437/temp/com.ibm.migration.iias.QGyh99/

[bluadmin@node0101-fab – Db2wh ~]$

2.2. db_migrate_iiasを組み込んだスクリプトの動作確認

続けて、db_migrate_iias コマンドを組み込んだスクリプトの確認となります。

 

db_migrate_iias コマンドを組み込んだスクリプトの実行例です。

(例)

# list5.txtファイル記載のテーブル(BLUDBデータベースのIKOTスキーマ上のMEISAIというテーブル)の

# データを抽出し、

# xxx.xxx.xxx.xxxに存在するDb2 Warehouseの同DB、スキーマ、テーブルにデータロー

ドします。

# list5.txtファイルに複数テーブル情報を記載することで、複数テーブルを順番に処理します。

[bluadmin@node0101-fab – Db2wh ~]$ ./db2_migrate_iias_data.sh list5.txt

2022/03/02 13:36:48 INFO: Script db2_migrate_iias_data.sh started[listfile=list5.txt]

2022/03/02 13:36:48 INFO: TRUNCATE TABLE is skipped[table=IKOT.MEISAI]

2022/03/02 13:38:17 INFO: Migrating the DB data to the destination finished normally[dest=xxx.xxx.xxx.xxx,table=IKOT.MEISAI,replace=no,rc=0]

2022/03/02 13:38:18 INFO: SELECT statement finished normally[dest=xxx.xxx.xxx.xxx,table=IKOT.MEISAI,rc=0]

2022/03/02 13:38:18 INFO: Data Migration from all the listed tables finished normally[done=1/1,file=list5.txt]

2022/03/02 13:38:18 INFO: Script db2_migrate_iias_data.sh finished[listfile=list5.txt,logfile=./db2_migrate_iias_data_20220302/db2_migrate_iias_data_20220302133648_list5.log]

[bluadmin@node0101-fab – Db2wh ~]$

スクリプトでは、ログファイルの他に1テーブルごとに実行結果を1行書き込むようなCSVファイルを作成するようなロジックを組み込んでおくと、実行後の結果確認に便利です。

以下は、db_migrate_iias コマンドを組み込んだスクリプトのCSVファイル出力例です。

(例)

[bluadmin@node0101-fab – Db2wh ~]$ cat db2_migrate_iias_data_20220302133648_list5.csv

“Migrate from Db2 to Db2″,””,””,””,””,””,””,””,””,””,””

“TableListFile”,”DBName”,”SchemaName”,”TableName”,”WhereClause”,”SrcRecordNum”,”MigrateStartTime”,

“MigrateEndTime”,”MigrateEndStatus”,”PreTruncate”,”DstRecordNum”,”RecordNumCheck”

“list5.txt”,”BLUDB”,”IKOT”,”MEISAI”,”N/A”,”100000069″,”2022/03/02 13:36:48″,”2022/03/02 13:38:17″,”SUCC”,”no”,”100000069″,”OK”

[bluadmin@node0101-fab – Db2wh ~]$

CSVファイルをMicrosoft Excelで開いてみました。結局のところスクリプトの作り次第ということにはなりますが、開始・終了時刻(下記MigrateStartTimeおよびMigrateEndTime)の他、移行元と移行先のロード後にSELECT件数を取得しておくと便利です(下記SrcRecordNumおよびDstSRecordNum)。

2.3. 既存のアンロード/ロードコマンドを組み込んだスクリプトの動作確認

最後に、既存のアンロード(エクスポート)、ロードコマンドを組み込んだスクリプトの確認となります。

この方法では、IIASからのデータアンロード(エクスポート)、アンロードしたデータ転送、Db2 Warehouseへのデータロードをそれぞれ個別の処理で実施します。db_migrate_iias コマンドのような一括での移行は行えないことになりますが、汎用コマンドを使用することで db_migrate_iias コマンド単独では行えない部分のケアをきめ細かく行うことが可能となります。

  • 移行元/移行先DB名
  • 移行元/移行先スキーマ名
  • 移行元/移行先テーブル名

上記をテーブルごとに一行でリストファイルとして記載しておき、このファイルを1行ずつ読み取って処理するようなスクリプトを同様に実装可能です。各処理がリストファイル記載に従って1テーブルずつ実行されていきます。リストファイルを分けることで、スクリプトを複数同時実行することも可能です。何並行まで同時に実施するかは同じく環境にも依存しますが、まずは2から4並行くらいから試していけばよいのではと考えられます。

また、データ転送では、単独のscpコマンドを使用することで転送帯域を設定することが可能です。Db2では、アンロード処理ではgz圧縮されたファイルで書き出すことが可能であり、かつロード処理でもgzファイルを直接ロードすることが可能です。処理を分ける関係上、db_migrate_iias コマンドと比較すると手数は増えるものの、ある程度データ転送量を抑えつつネットワーク帯域にも配慮したデータ移行を行うことが可能になります。

以下は、データロードスクリプトの実行例です。

(例)

# IIASから抽出され転送されてきたデータファイルを用いて、

# list5_2.txtファイル記載のテーブル(BLUDBデータベースのIKOTスキーマ上のMEISAIというテーブル)に

# データロードします(ここではデータ置換を想定しロード前にTRUNCATEしています)。

# list5_2.txtファイルに複数テーブル情報を記載することで、複数テーブルを順番に処理します。

[bluadmin@db2wh – Db2wh iias-db2wh]$ ./db2_dbload_table_data.sh list5_2.txt

2022/03/03 22:24:45 INFO: Script db2_dbload_table_data.sh started[listfile=list5_2.txt]

#### Source:BLUDB.IKOT.MEISAI –> Destination:IKOT.MEISAI

============================== Load session:   1 ==============================

Connecting to: ‘BLUDB’

Connected to: ‘BLUDB’

‘log’ file: ‘/mnt/blumeta0/home/bluadmin/logs/dbload/MEISAI.IKOT.BLUDB.log’

‘bad’ file: not found

Load session of table ‘BLUDB.IKOT.MEISAI’ completed successfully

Session started: 2022-03-03 22:24:55

Session ended:   2022-03-03 22:26:06

Elapsed time [hh:mm:ss]: 00:01:11

===============================================================================

2022/03/03 22:26:06 INFO: Loading the data files finished normally[table=IKOT.MEISAI,replace=yes,nullValue=no,rc=0]

2022/03/03 22:26:06 INFO: Removing the data files finished normally[table=IKOT.MEISAI,path=/mnt/blumeta0/home/bluadmin/test/iias-db2wh/temp_data_load/BLUDB/IKOT/MEISAI,rc=0]

2022/03/03 22:26:07 INFO: SELECT statement finished normally[table=IKOT.MEISAI,rc=0]

2022/03/03 22:26:07 INFO: Loading data of all the listed tables finished normally[done=1/1,file=list5_2.txt]

2022/03/03 22:26:07 INFO: Script db2_dbload_table_data.sh finished[listfile=list5_2.txt,logfile=./db2_dbload_table_data_20220303/db2_dbload_table_data_20220303222445_list5_2.log]

[bluadmin@db2wh – Db2wh iias-db2wh]$

[2.2. db_migrate_iiasを組み込んだスクリプトの動作確認]でも記載したように、スクリプトでは、ログファイルの他に1テーブルごとに実行結果を1行書き込みCSVファイルを作成するようなロジックを組み込んでおくと、実行後の結果確認に便利です。アンロード、データ転送、データロードそれぞれで同様の考え方で作成しておくことで最終的なとりまとめにも有用です。

以下は、データロードスクリプトのCSVファイル出力例です。

(例)[bluadmin@db2wh – Db2wh iias-db2wh]$ cat ./db2_dbload_table_data_20220303/db2_dbload_table_data_20220303222445_list5_2.csv”Load data to Db2wh”,””,””,””,””,””,””,””,””,””,””,””,”””TableListFile”,”SrcDBName”,”SrcSchemaName”,”SrcTableName”,”DstSchemaName”,”DstTableName”,”LoadStartTime”,”LoadEndTime”,”LoadEndStatus”,”DstRecordNum”,”SelectStatus”,”PreTruncate”,”NullValue””list5_2.txt”,”BLUDB”,”IKOT”,”MEISAI”,”IKOT”,”MEISAI”,”2022/03/03 22:24:55″,”2022/03/03 22:26:06″,”SUCC”,”100000069″,”SUCC”,”yes”,”no”[bluadmin@db2wh – Db2wh iias-db2wh]$

データロードスクリプト実行後のCSVファイルをMicrosoft Excelで開いてみました。こちらも同様にスクリプトの作り次第ということにはなりますが、移行元と移行先のロード後にSELECT件数を取得しておくと実行後の確認に便利です。今回の例はデータロードスクリプトなので、ロードの開始・終了時刻(下記LoadStartTimeおよびLoadEndTime)の他、ロード後のSELECT件数を取得しています(下記DstRecordNum)。アンロード時にもSELECT件数を取得しておき、ロード後のSELECT件数と比較する、といった確認が考えられます。

結果サマリー

各検証の結果サマリーとなります。

項番項目　　　 　　　 　　　メリット・デメリット見解
1　　オブジェクトの移行確認メリット/デメリット：明確なメリット、デメリットとも特に無いように思われる。db2lookによりテキストを書き出して編集後適用するのが実質唯一の方法。基本的なエンジンは同一のため、互換性の観点では問題無し。
ただし、DDLファイル編集および編集したファイル反映時に勘所が必要。
編集時：移行元、移行先のDB設計を踏まえて削除する箇所、残す箇所を把握するスキル要。
反映時：移行元とオブジェクトのオーナーを合わせる必要があるため、BLUADMINスキーマ以外のオブジェクトが存在する場合には、DDL反映前に移行元と同じユーザーに遷移しておくか、反映後にオーナー変更(TRANSFER OWNERSHIP)が必要。
ユーザー定義ファンクション、ライブラリーなど、DDL移行のみで完結しないものについては移行先であらためて登録する必要がある。
また、移行対象オブジェクトについてお客様との擦り合わせ、合意が必要。
項番 項目 メリット・デメリット 見解
2.1 IBM純正の移行ツール(db_migrate_iias)の単体挙動確認

・メリット：IBM公式。コマンド1つでテーブルを作成しそのままデータロード可能。テーブル作成済の状態でも動作する。

・デメリット：コマンドレベルでの帯域制御や差分移行を行うことはできない。ロード先テーブルの作成は可能だが、その権限(GRANT)や関連するビュー等は別途手動設定要。db_migrate_iiasコマンドが主処理を全て実施しているので、問題発生時にはどの部分で問題が発生したのか、IBMによる詳細確認が必要となる。

 テーブル作成からロードまで同時に行う場合には、事前にテーブルを作成しない場合よりも時間がかかるかもしれない。テーブルのデータ圧縮の対応は別途必要。
2.2 db_migrate_iiasを組み込んだスクリプトの動作確認
2.3 既存のアンロード/ロードコマンドを組み込んだスクリプトの動作確認

・メリット：アンロード、転送、ロードと考え方としてはシンプル。既存のDb2汎用コマンドを使用しているので、問題発生時の被疑箇所も明確。scpコマンドの帯域制御可能。アンロード時にwhere句を使用することで差分移行も可能。

・デメリット：複数の処理をそれぞれ実行する必要があり、手数は増える。IBM公式の移行手順ではない(メリットと表裏の関係ではある)。

事前の移行先環境構築完了が前提となる。

アンロード/転送/ロードで処理が分かれているためにdb_migrate_iiasよりはデータ移行単体での手数は増える。その代わり、処理ごとに進捗を把握することができると捉えることも可能。テーブルのデータ圧縮の対応は別途必要。

移行スクリプト

2.2および2.3.で使用したスクリプトは以下の通り。

項番　項目実行場所処理概要
1　db_migrate_iiasスクリプト移行元IIASdb_migrate_iiasを組み込み。db_migrate_iiasコマンド仕様により帯域制御および差分移行は不可。
移行先がDb2 Warehouse on Cloudの場合には、SSL通信の考慮が別途必要になると考えられる。
2データアンロードスクリプト移行元IIAS移行元IIASから、外部表を使用したアンロード(db2 exportコマンドより高速)。差分アンロード可能。
3データ転送スクリプト移行元IIAS移行元IIASから移行先Db2 Warehouseへ、アンロードデータを転送(事前にOSユーザの鍵交換要)。scpコマンドのオプションにより帯域制御可能。
移行先がDb2 Warehouse on Cloudの場合には、Db2クライアントを導入したクラウド側の中継サーバーのような場所に転送することが考えられる。
4データロードスクリプト移行先Db2 Warehouse
or
クラウド側中継サーバー		移行先Db2 Warehouseへ転送されてきたアンロードデータを、外部表を使用してロード(db2 loadコマンドより高速)。
移行先がDb2 Warehouse on Cloudの場合には、Db2クライアントを導入したクラウド側の中継サーバーのような場所から実行することで、データロード可能と考えられる(Db2接続時のSSL通信考慮は必要)。

以下の共通仕様で作成。

項番項目
11テーブル1行で記述した外部リストファイルを読み取り、そのテーブルごとに実行
2リストファイルを複数分割することで、並行実行が可能
3主処理(db_migrate_iias/データアンロード/データ転送/データロード)の開始・終了時刻記録
4db_migrate_iias前後/データアンロード前/データロード後の件数取得
51テーブルごとに処理結果をCSV形式で書き出し(MSExcel等で結果集約・まとめに使用できるような)

 

まとめ

  • データ移行観点では、IBM標準の移行ツールの動作を検証実施し、データ移行手順をある程度定型化可能であることがわかりました。
  • また、IBM標準の移行ツール以外に独自のデータアンロード、データ転送、データロードの検討を行うことができました。
  • 一方で定義移行の観点では、Db2エンジン to Db2エンジンでも必ずしも機械的な定義移行が行えるわけではないことがわかりました。それに対応する手順、余裕を持った移行内容、設定の検討および確認などが必要となります。ただし、共通エンジンであるがゆえ、他DBMSに移行時のような何らかの変換、コンバートが必要になるわけではありません。互換性を基本的には考慮しなくてよいのはやはり大きなメリットと考えられます。

最後までお読みくださり、大変ありがとうございました。

 

ご相談はこちらから

お客様の業務課題に応じ、さまざまなソリューションの中からベストな組合せで、
ご提案をさせていただきます。お困りのことがございましたらお気軽にお問い合わせください。

メールでのお問い合わせは
こちらから
ページのトップへ