この記事では、DB2 ベースの PHP アプリケーション システムの AIX プラットフォームから Linux プラットフォームへの移植プロセスを完了する方法を主に紹介します。この記事には、基盤となる DB2 データベースと上位層の PHP アプリケーション システムを移植する詳細な手順と、移植プロセス中に発生する可能性がある問題と解決策が記載されています。
タスクの概要
システム移行作業は主に次の側面に分かれています。
1. DB2 データベース システムのクロスプラットフォーム移行
2. Apache サーバーと PHP アプリケーション システムのインストールと構成
以下では、移行と構成の具体的な手順を 2 つの側面で紹介します。 。
DB2 データベース システムのクロスプラットフォーム移行
データベース環境
ソース環境: AIX+DB2 v8.1
ターゲット環境: Linux+DB2 v8.1
ソース データベースには、SRCDB1 と SRCDB2 の 2 つのデータベース インスタンスが含まれています。 SRCDB1/SRCDB2 データベースには数百のデータベース テーブルが含まれており、多くのインデックス、外部キー制約、トリガー、ストアド プロシージャ、および自動インクリメント フィールドを持ついくつかのテーブル (GENERATED ALWAYS AS IDENTITY 定義フィールドを持つテーブル) があります。さらに問題を複雑にしているのは、これらのデータベース オブジェクトの正確な作成スクリプトがないことです。
移行計画の選択
Linux 間の移行や AIX システム間の移行など、移行元システムと移行先システムが同じタイプのオペレーティング システムに属している場合、これを実現するための関連する実用的なツールが DB2 自体によって比較的簡単に提供されます。 . BACKUP コマンドや RESTORE コマンドなど、同じタイプのプラットフォーム間でのデータベースの移行。もちろん、状況によっては、ユーティリティ ツールが提供するパラメータを明確に理解する必要があります。たとえば、ソース システムとターゲット システムが異なるテーブル スペースを使用する場合、テーブル スペースのリダイレクトの問題が発生します。この記事の焦点はクロスプラットフォームの移植であるため、このソリューションは明らかにニーズを満たすことができないため、ここでは説明しません。
では、クロスプラットフォームのデータベース移行の問題にどのように対処すればよいのでしょうか? db2move ユーティリティを使用することはできますか? db2move はテーブル内のデータのみを移行できますが、インデックス、外部キー制約、トリガー、ストアド プロシージャなどのデータベース オブジェクトは移行できません。また、db2move には自動インクリメント フィールド データを含むテーブルに対しても一定の制限があります。また、db2move は既存のデータベース表にデータをインポートすることしかできず、指定された表スペースの場所を表示することはできません。データベース システムの移行プロセスでは、テーブル内のデータだけでなく、インデックス、外部キー制約、トリガー、ストアド プロシージャなどのデータベース オブジェクトも移行する必要があるため、この記事で選択したソリューションと比較すると、後者の方が移行が必要です。さらなる利点。 db2move は、表データを移行する代替手段としてのみ使用できます。
エクスポートとインポートでは、一度に 1 つのテーブルのみをエクスポートおよびインポートできます。データベース テーブルの数が多くない場合は、エクスポートおよびインポートのコマンドと、インポートおよびエクスポートするデータ テーブルの名前を手動で入力する必要があります。 、このオプションは引き続き検討されますが、最良のオプションではありません。データベース内に多数のテーブルがある場合、このアプローチは基本的に非現実的であり、インポート コマンドでは、自動インクリメントされるフィールドのデータが元のテーブル データと一致することは保証されません。
この記事では、DB2 のデータベース オブジェクトの処理メカニズムに基づいて、db2look と DDL および DML スクリプトを組み合わせた方法を使用し、元のデータベースのトリガー、ストアド プロシージャ、および外部キー制約を個別に処理して、クロスプラットフォームの DB2 の実現可能なソリューションを提供します。データベースシステムの移行。
SRCDB1 を例として、この場合の全体的なデータベース移行プロセスを紹介します。 SRCDB1 データベースには、SRCDB1、ASN、DB2DBG、および SQLDBA の 4 つのデータベース モードがあります。 SRCDB1 データベースのユーザー名が user_srcdb1 で、パスワードが pw_srcdb1 であると仮定します。
移行元システム（AIX）での関連操作
1. db2look コマンドを使用して、データベース オブジェクトを生成する DDL スクリプト リストを抽出します
。 1. db2look コマンドとパラメーター
# db2look -d SRCDB1 -e -o srcdb1.ddl -a -i user_srcdb1 -w pw_srcdb1
db2look: オブジェクトを再作成するための DDL の生成データベースで定義された
構文: db2look -d DBname [-e] [-u Creator] [-z Schema]
[-t Tname1 Tname2...TnameN] [-tw Tname] [-h] [-o Fname] [- a]
[-m] [-c] [-r] [-l] [-x] [-xd] [-f] [-fd] [-td x]
[-noview] [-i userID] [- w パスワード]
[ -v Vname1 Vname2 ... VnameN] [-wrapper WrapperName]
[-server ServerName] [-nofed]
-d: データベース名、必須パラメータ
-e: データベースの複製に必要な DDL ファイルを抽出します、このオプションステートメントのスクリプトを含む DDL ファイルを生成します。
-o : 出力を指定されたファイル名にリダイレクトします。 -o オプションが指定されていない場合、出力はデフォルトで stdout になります。
-a : 作成されたすべてのプログラムの統計を生成します。このオプションが指定されている場合、無視されます。 -u オプション
-i: データベースが存在するサーバーにログインするためのユーザー ID を指定します。
-w: データベースが存在するサーバーにログインするためのパスワードを指定します
。オブジェクトの種類に応じてデータベース オブジェクト DDL スクリプトを区別します。
ソース データベースの各テーブル データはトリガーやストアド プロシージャなどのデータベース オブジェクトによって処理されるため、データベース内のデータの一貫性と整合性を確保します。オブジェクトは、テーブル データのインポート時にトリガーやストアド プロシージャなどのデータベース オブジェクトが繰り返し実行されて誤ったデータが生成されるのを防ぐために、データのインポート後に作成する必要があります。テキスト エディターを使用して、db2look によって生成された srcdb1.ddl を編集し、テーブルとインデックスの作成、外部キー制約の作成、トリガーとストアド プロシージャの作成を行う DDL ステートメントを 4 つのグループに分割し、次の 4 つの DDL スクリプトとして保存します。
srcdb1_tables.ddl srcdb1_foriegnkeys.ddl
srcdb1_triggers.ddl srcdb1_procedures.ddl
srcdb1_tables.ddl: SEQUENCE、UDF、TABLE、VIEW、およびその他のデータベース オブジェクトを作成するための ddl ステートメントが含まれています。
リスト 2. srcdb1_tables.ddl ステートメント
CREATE SEQUENCE "SRCDB1"."SAMPLE_SEQ_1" AS INTEGER
MINVALUE 1 MAXVALUE 9999999999
START WITH 1 INCREMENT BY 1;
CREATE FUNCTION " SRCDB1"." SAMPLE _FUNC_1" (
VARCHAR(254),
VARCHAR(25 4) ) ,
VARCHAR(254)
) VARCHAR(254)
SPECIFIC SAMPLE _FUNC_1 ……;
CREATE
TABLE " SRCDB1"." SAMPLE _TAB_1" (
"TAB_COL1" CHAR(20) NOT NULL 、
"TAB_COL2" VARCHAR(70) NOT NULL ) ;
TABLE " SRCDB1"." SAMPLE _TAB_2" (…);
…
CREATE TABLE " SRCDB1"." SAMPLE _TAB_N" (…);
CREATE VIEW SRCDB1.SAMPLE_VIEW_1 (VIEW_COL1,VIEW_COL2) AS SELECT unique
COL1 , COL2 FROM SAMPLE_TAB WHERE … …;
CREATE VIEW SRCDB1.SAMPLE_VIEW_2 …;
…
CREATE VIEW SRCDB1.SAMPLE_VIEW_N …;
srcdb1_foriegnkeys.ddl: 外部キー制約を作成するための ddl ステートメントが含まれます。
リスト 3. srcdb1_foriegnkeys.ddl ステートメント
ALTER TABLE " SRCDB1"."SAMPLE_FK_1"
ADD CONSTRAINT "SQL030903143850120" FOREIGN KEY
("FK_COL1")
REFERENCES " SRCDB1"."SAMPLE_TABLE"
("COL1");
ALTER TABLE " SRCDB1"."SアンプLE_FK_2 " ADD ……;
……
ALTER TABLE " SRCDB1"."SAMPLE_FK_N" ADD ……;
srcdb1_triggers.ddl: トリガーを作成するための ddl ステートメントが含まれています。
リスト 4. srcdb1_triggers.ddl ステートメント
CREATE TRIGGER SRCDB1.SAMPLE_TRIG_1 AFTER UPDATE OF Col1 ON SRCDB1.SAMPLE_TAB
REFERENCING NEW AS N FOR EACH ROW MODE DB2SQL WHEN ( n.col1 > 3)
BEGIN ATOMIC
update SAMPLE_TAB
set(col2) = 'anotherValue' wherecol1 = n.col1 ;--
END;
CREATE
TRIGGER SRCDB1 …
;
SRCDB1.SAMPLE_TRIG_N…;
srcdb1_procedures.ddl: SQL ストアド プロシージャおよび Java ストアド プロシージャを作成するための ddl ステートメントが含まれています。
リスト 5. srcdb1_procedures.ddl ステートメント
CREATE PROCEDURE " SRCDB1"." JAVA_PROCEDURE_1" (
OUT SQLSTATE CHARACTER(5),
OUT ROWS_SUBMITED INTEGER,
IN BATCH_ID INTEGER,
IN LEVEL VARCHAR(4000)
)
DYNAMIC RESULT SETS 0
SPECIFIC SUBMIT_BATCH
EXTERN AL NAME '送信バッチ! submit_batch'
言語 Java
パラメータ スタイル JAVA
は決定的ではありません
FENCED THREADSAFE
変更 SQL データ
NO
DBINFO;
CREATE
PROCEDURE " SRCDB1"."JAVA_PROCEDURE_2" ……;
特定の
SRCDB1
.SQL_PROCEDURE_1
言語 SQL
-------------------------------------- -------- ---
-- SQL ストアド プロシージャ
---------------------------------- ----------- -------
P1: BEGIN
……
END P1 ;
CREATE PROCEDURE SRCDB1.SQL_PROCEDURE_2 ……
CREATE
PROCEDURE SRCDB1.SQL_PROCEDURE_N ……
; db2 look の db2 v6 バージョンには、UDF、TRIGGER、UserSpace、NodeGroup、BufferPool、その他のデータベース オブジェクトの ddl ステートメントなどの抽出がまだ実装されていません。 db2 v7 以降、db2look は上記のオブジェクトの DDL を抽出できますが、ストアド プロシージャ オブジェクトを作成する ddl ステートメントを抽出することはできません。 db2 v8.2 以降、db2look 関数のサポートが改善され、ストアド プロシージャ ddl ステートメントの抽出機能が実装されました。この記事に関係するソース データベース システムは以前のバージョン (DB2 v8.1) であるため、すべてのデータベース オブジェクトの DDL 情報を取得するには、次の解決策を採用する必要があります
。 1) DB2 v8.2 システムから SRCDB1 へ。 (DB2 v8.1 バージョン) CATALOG 操作を実行します。
db2 カタログ db SRCDB1 を SRCDB1 として実行します。
2) DB2 v8.2 システムから SRCDB1 で db2look 抽出プロセスを実行します。
これにより、完全な
ファイルを取得できます。
データベース オブジェクトの DDL 情報。
3．データ エクスポート エクスポート スクリプトの生成
シェル スクリプトを使用して、すべてのデータの DML スクリプトを生成およびエクスポートし、srcdb1_export.sql ファイルにリダイレクトします。 DB2 に精通しているユーザーは、データベース内に作成された各テーブル、ビュー、および別名が SYSCAT.TABLES 内のレコードの行に対応していることを知っているはずです。したがって、必要なデータベース テーブル情報はすべて、対応するデータベース選択ステートメントを通じて取得できます。必要に応じて、次のシェル スクリプトは、システム テーブル SYSCAT.TABLES の tabname フィールドに基づいて、SRCDB1 内のすべてのタブスキーマ テーブル (SRCDB1、ASN、SQLDBA、および DB2DBG) のテーブル名を選択し、それらの名前に基づいて対応するエクスポート ステートメントを生成します。 . バッチエクスポートの目的を達成します。 rtrim 関数は、tabname フィールド データの右側のスペースを削除するために使用されます。
リスト 6. エクスポート スクリプトの生成
# db2 "select 'export to ' rtrim(tabname) '.ixf of ixf select * from '
rtrim(tabname) ';' from syscat.tables
where tabschema in('SRCDB1', 'ASN', 'SQLDBA', 'DB2DBG')" > srcdb1_export.sql;
生成された srcdb1_export.sql を編集し、ヘッダーと末尾に表示されている統計情報を削除し、必要なエクスポート ステートメントのみを保持します。上記のスクリプトに含まれるタブスキーマ情報を変更することで、エクスポートする必要があるテーブルの範囲、つまり移行プロセス中に必要なすべてのテーブル名を指定できます。生成されたエクスポート エクスポート ステートメントのコマンド形式は次のとおりです。
db2 export to tablename.ixf of ixf select * from tablename
;データ インポート ロード スクリプトの生成
シェル スクリプトを使用して、データをターゲット システムにインポートするためのロード スクリプトを生成します。 srcdb1_load.sql
リスト 7. ロード スクリプトの生成
# db2 "select 'load from ' rtrim(tabname) '.ixf of ixf insert into '
rtrim( tabname) ';' from syscat.tables
where tabschema in ('SRCDB1', 'ASN', 'SQLDBA', 'DB2DBG')" > srcdb1_load.sql;
生成された srcdb1_load.sql を編集し、先頭と末尾の統計を削除します。必要なロード ステートメントのみを保持します。エクスポート ステートメントと同様に、上記のシェル スクリプトは、システム テーブルから SRCDB1 内のすべてのテーブルの名前を選択し、それらの名前に基づいて対応するインポート ステートメントを生成して、バッチ インポートの目的を達成します。
生成された import import ステートメントの
コマンド形式は次のとおりです。