OracleからMySQLへ「トリガ」の移行手順と工数評価：実践 OSSデータベース移行プロジェクト（7）（1/2 ページ）

本連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。今回は、トリガの移行に関する難易度評価の手順を解説します。

[荻野邦裕，SCSK株式会社]

　商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けする本連載「実践 OSSデータベース移行プロジェクト」。前回までは、「株式会社豊洲部品」（仮名）社内システムの移行事例を用いて「オブジェクト種別」「データ型」「ビューおよびストアドプロシージャのSQL」「テーブルおよびインデックスのDDL」「SQL以外のストアドプロシージャ」に関する移行コストの評価を実施しました。

　本稿では、「DMLトリガ」にフォーカスして説明します。当該社内システムで利用しているOracleDBの構成情報は、下記の通りです。

現行（移行前）Oracle環境

OS	Windows2008R2 64bit
プロダクト名（バージョン）	Oracle Database 11gR2 SE1(11.2.0.4.0)
データベース名	APODB
ブロックサイズ	8192バイト
キャラクタセット	JA16SJIS
各国語キャラクタセット	AL16UTF16
接続モード	専用サーバモード
ユーザーデータ容量	約200GB
最大同時接続数	100
アプリケーション	VB（oo4o）、PL/SQLストアドプロシージャ

　なお、本稿で評価結果として提示したトリガの数や、データ型の数などは、全て架空の値となります。

手順1：トリガの評価目的を理解する

　本評価は、MySQLに移行する場合の「コスト（＝作業量）を把握する」ことが目的です。次の手順で、現時点で実装しているトリガのソースコードを取得して、MySQLに移行する場合のSQL以外のソースコードを確認していきます。

　作業コストは、以下の3段階で評価します。

• 移行コスト：低（0〜0.5人月）
• 移行コスト：中程度（0.5〜1人月）
• 移行コスト：高（1人月以上）

手順2：トリガのソースコードを取得する方法

　トリガのソースコードは、以下の方法で取得します。

1. 「DBMS_METADATA」パッケージの「GET_DDL」ファンクションを使用する
2. 「DataPumpユーティリティ」を使用する

　（1）については第5回「SQLとDDLの移行評価を実施する」を、（2）については第4回「オブジェクトとデータ型の“移行コスト評価”を実施する」で解説した方法を参照してください。

手順3：「トリガの移行評価」を行う

　手順2におけるトリガのソースコードの調査結果、SQLを除き、MySQLに移行する場合にコスト高となる要素を含む6事項について評価を行いました。

評価1「Oracle　独自DMLトリガ構文」に関する評価結果

移行前のOracle　DMLトリガ構文（画像＝左）と移行後のMySQL　DMLトリガ構文（画像＝右）

• 評価1-（1）：「UPDATEトリガ起動条件」の移行評価

　Oracleの「UPDATEトリガ起動条件」には、MySQLの「UPDATEトリガ起動条件」にはない、「UPDATE [ OF カラム名　]」のOFで指定されたカラムが更新されたときのみ起動するOracleトリガがあります。当該トリガが実装されているか調査した結果、当該トリガが実装されていませんでした。

　よって、「UPDATEトリガ起動条件」については、本システムにおける移行コストは、0と評価しました。

• 評価1-（2）：「同一テーブルに対するトリガの順序指定」の移行評価

　Oracleは、「FOLLOWS トリガ名 [,トリガ名…… ]」と記述することにより「同一テーブルに対するトリガの順序指定」が可能です。MySQLには、当該機能は、ありません。当該トリガが実装されているか調査した結果、当該トリガは、実装されていませんでした。

　よって、「同一テーブルに対するトリガの順序指定」については、本システムにおける移行コストは、0と評価しました。

• 評価1-（3）：「使用不能状態」の移行評価

　Oracleは、「DISABLE」と記述することによりトリガを「使用不能状態」で実装可能です。当該トリガが実装されているか調査した結果、当該トリガは、実装されていませんでした。

　よって、「使用不能状態で実装」については、本システムにおける移行コストは、0と評価しました。

• 評価1-（4）：「FOR EACH ROW句」の移行評価

　「FOR EACH ROW句」について評価を実施しました。

「FOR EACH ROW句」に関する評価結果

起動単位	内容	本システムでの個数
FOR EACH ROW	行トリガ（DML文が影響を与える行ごとに起動） Oracle、MySQL共通	153
FOR EACH ROW 　WHEN 条件……	行トリガを起動する条件を指定する Oracleのみ	0
FOR EACH ROWを記述しない	文トリガ（DML文に対して一度だけ起動） Oracleのみ	0

　本システムでは、「FOR EACH ROW」を明記する行トリガのみを使用しておりますので移行コストは、「低い」と評価しました。

• 評価1-（5）：「EXCEPTION句」の移行評価

　Oracleは「EXCEPTION句」によって例外セクションを使用できますが、MySQLは使用できません。

　本システムでは、「EXCEPTION句」が使用されているか調査した結果、使用されていないので、移行コストは、0と評価しました。

評価2「自動採番専用トリガ」に関する評価結果

CREATE OR REPLACE TRIGGER tri_ins_shain
  BEFORE
  INSERT
  ON shain
  FOR EACH ROW
DECLARE
  val NUMBER;
BEGIN
  SELECT seq_shain1.NEXTVAL INTO val FROM dual;
  :NEW.shain_id := val;
END;
/

例：自動採番専用トリガ

　上記「例：自動採番専用トリガ」のようにカラムに対して、自動採番のみ実施している「シーケンス」「インサートトリガ」は、MySQLに移行した場合、当該カラムに「SHAIN_ID DOUBLE(38,0) NOT NULL auto_increment,」とCreate Table文に記載することで代用可能となるため不要となります。

　当該「シーケンス」「インサートトリガ」は、それぞれ約100オブジェクトあり、本システムでの「自動採番専用トリガ」の移行コストは、「中程度」と評価しました。