OracleからMySQLへ オブジェクトとデータ型の「移行コスト評価」を実施する：実践 OSSデータベース移行プロジェクト（4）（2/2 ページ）

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

手順3：「移行評価」を実施する

オブジェクト種別ごとの移行評価

　手順2のオブジェクト種別調査の結果、株式会社豊洲部品（仮名）のOracle Database環境には7つのオブジェクトが実装されていました。これらのオブジェクトについての評価を個別に行います。

• （1）「テーブル」に関する評価結果

	種別	個数	移行コスト評価
Oracleテーブル種類	標準テーブル	139	低
MySQLオブジェクト種別	テーブル	─
「テーブル移行」に関する評価結果

　テーブルの構文については、一部データ型などに差異はあるものの、Oracle DatabaseもMySQLも概念は同じです。比較的に容易に移行を実施できるので、移行コストは「低」と考えられます。

• （2）「インデックスの移行」に関する評価結果

	種別	個数	移行コスト評価
Oracleテーブル種類	B-Treeインデックス	212	低
MySQLオブジェクト種別	B-Treeインデックス	─
「インデックスの移行」に関する評価結果

　インデックスについても、一部データ型などに差異はあるものの、Oracle DatabaseもMySQLも概念は同じです。比較的に容易に移行を実施できるので、移行コストは「低」と考えられます。

• （3）「ビューの移行」に関する評価結果

	種別	個数	移行コスト評価
Oracleテーブル種類	ビュー	238	低
MySQLオブジェクト種別	ビュー	─
「ビューの移行」に関する評価結果

　ビューについては、主に複数のテーブルを外部結合して参照に使用しています。MySQLでは、SELECT句の構文（特に外部結合）に一部差異はありますが、概念は同じです。外部結合の部分以外は、移行コストは「低」と考えられます。

• （4）「ストアドプロシージャの移行」に関する評価結果

	種別	個数	移行コスト評価
Oracleテーブル種類	ストアドプロシージャ	66	中程度
MySQLオブジェクト種別	ストアドプロシージャ	─
「ストアドプロシージャの移行」に関する評価結果

　SQL関数やPL/SQLに関しては一般的な関数を多く使用していますが、ソースコードの長いストアドプロシージャが多いようです。本システムでは、コーディング方法に注意してソースコードの移行を実施する必要があります。従って、移行コストは「中程度」と考えられます。

• （5）「シーケンスの移行」に関する評価結果

	種別	個数	移行コスト評価
Oracleテーブル種類	シーケンス	151	低
MySQLオブジェクト種別	auto_increment（機能）	─
「シーケンスの移行の移行」に関する評価結果

　カラムとシーケンスの対応が全て1対1であり、主に主キーのシステム採番用に使用されています。シーケンスについては、MySQLに用意される「auto_increment」機能を使えば対応が可能です。移行コストは「低」と考えられます。

• （6）「シノニムの移行」に関する評価結果

	種別	個数	移行コスト評価
Oracleテーブル種類	シノニム	218	低
MySQLオブジェクト種別	なし	─
「シーケンスの移行の移行」に関する評価結果

　シノニムがユーザー間のアクセス制御に使用されています。ただしMySQLには「オーナーの概念がない」ために、シノニムの移行についての特別な対応は必要ありません。このため、移行コストは「低」と考えられます。なお、セキュリティポリシーに応じてオブジェクトへのアクセス制限を行う場合には、ユーザーに対する権限を付与することで対応できます。

• （7）「トリガの移行」に関する評価結果

	種別	個数	移行コスト評価
Oracleテーブル種類	DMLトリガ	153	低
MySQLオブジェクト種別	トリガ	─
「トリガの移行の移行」に関する評価結果

　トリガは、主に「主キーのシステム採番用」に使用しています。一部構文の修正のみで移行が可能のため、移行コストは「低」と考えられます。

カラムデータ型の移行評価

　手順2のカラムデータ型調査の結果、株式会社豊洲部品（仮名）のOracle Database環境には、データ型として「CHAR型」「VARCHAR2型」「DATA型」「NUMBER型」が実装されていました。この型についての評価を個別に行います。

• （1）「CHAR型」に関する評価結果

	データ型	単位	仕様	個数	移行コスト評価
Oracle	CHAR(n)	（バイト数|文字数）	固定長文字列 最大2000バイト	83	低
MySQL	CHAR(n)	（文字数）	固定長文字列 最大255文字	─
「CHAR型」に関する評価結果

　CHAR型はOracle DatabaseとMySQLの仕様の違いから、移行時の桁あふれに留意する必要はありますが、調査の結果、本データベースではCHAR（256文字）以上の指定は存在しませんでした。そのため、移行コストは「低」と考えられます。ちなみにMySQLは「0バイト文字列を認識」するので、カラムのNULLの判断方法にも留意してください。

• （2）「VARCHAR2型」に関する評価結果

	データ型	単位	仕様	個数	移行コスト評価
Oracle	VARCHAR2(n)	（バイト数|文字数）	固定長文字列 最大4000バイト	83	低
MySQL	VARCHAR(n)	（文字数）	可変長文字列 最大65535文字 （※行内全てのカラム合計で最大64KBという制限もあり）	─
「VARCHAR2型」に関する評価結果

　VARCHAR2型も同様に、移行時の桁あふれに留意する必要がありますが、本データベースでは、行内全てのカラム合計で64KB以上のテーブルは存在しませんでした。そのため、移行コストは「低」と考えられます。CHAR型と同様に、MySQLは「0バイト文字列を認識」するのでカラムのNULL判断方法にも留意してください。

• （3）「DATE型」に関する評価結果

	データ型	単位	仕様	個数	移行コスト評価
Oracle	DATE	年月日・時分秒	西暦前4712年1月1日0時0分0秒 〜西暦9999年12月31日23時59分59秒	250	低
MySQL	DATETIME	年月日・時分秒＋小数秒（最大6桁）	西暦1000年1月1日0時0分0秒.000000 〜西暦9999年12月31日23時59分59秒.999999	─
「DATE型」に関する評価結果

　DATE型では、「西暦1000年1月1日0時0分0秒より前」の日付データが格納されている場合には留意する必要がありますが、本データベースには格納されておりませんでした。そのため、移行コストは「低」と考えられます。

　ちなみに、Oracle DatabaseのTIMESTAMP型の場合にも、少数点以下6桁秒までのデータならばMySQLのDATETIME型に移行が可能です。

• （4）「NUMBER型」に関する評価結果

	データ型	単位	仕様	個数	移行コスト評価
Oracle	NUMBER(p,s)	(精度,位取り)	数値 精度（p）：38桁、 位取り(s)：-84〜127桁	751	低
MySQL	DECIMAL(p,s)	(精度,位取り)	数値 精度（p）：65桁、 位取り(s)：0〜30桁（“p”より大きくはできない）	─
「NUMBER型」に関する評価結果

　NUMBER型では、位置指定が「負」の場合、あるいは「31以上」が指定されていた場合に桁あふれが発生する可能性があります。本データベースの位置取り指定は「0〜30」の範囲で、問題はありません。

　また、Oracleのシーケンスにて自動採番を実現しているカラムは、MySQLの「auto_increment」設定が必要です。「auto_increment」のカラムはDECIMAL型への移行はできないので、INT型70カラム、DOUBLE型35カラムを上の表とは別に移行する必要があります。しかしながら、その移行作業も容易です。移行コストは「低」と考えられます。

　なお、Oracle DatabaseのNUMBER型で、位取りが負の場合、あるいは31以上だった場合には、MySQLでは「DOUBLE型（桁数, 小数点以下の桁数）」への移行で対処可能です。

調査結果のまとめ

　調査の結果、本データベースでは「ビュー」と「ストアドプロシージャ」以外のオブジェクトについては、そのままMySQLへ移行できることから、ほぼ問題ありません。移行コストは「低い」と考えられます。一方の「ビュー」と「プロシージャ」のオブジェクトについては、ソースコードのSELECT文とSQL関数の内容によって、移行コストに影響がある可能性があります。もう少し移行コスト考察が必要です。

　データ型については、本データベースではおおむね標準的なデータ型が使われています。このため移行にはほぼ問題はなく、移行コストも「低い」と考えられます。一応、文字型データの移行においては、Oracle DatabaseとMySQLの格納データ量仕様の違いから、桁あふれが発生しないか、実際のデータを使用してMySQLのテーブルへ移行する検証を行うことを推奨します。

　この他に、アプリケーション内の文字型カラムのNULL判定で「COL = ''」を使用しているソースコードがある場合には、「COL IS NULL」のNULL判定に変更する必要があります。こちらも注意してください。

---

　以上、ここではDMBS移行プロジェクトの移行評価作業のうち、オブジェクト種別とデータ型のコスト評価を行いました。移行評価作業は、これらのような情報から確認していきます。株式会社豊洲部品はあくまで架空の会社ですが、Standard Edition、あるいはStandard Edition Oneで運用する場合に多く見られるデータベースシステムの平均値を取って例にしました。Oracle SE1からの移行を計画する皆さんのデータベースシステムとも似た構成ではないでしょうか。

　次回は、Oracle DatabaseからMySQLへの移行に向けた「SQLとDDLの移行手順」を解説します。

筆者紹介（共著）

廣濱顕司（ひろはま けんじ）

SCSK株式会社 ITマネジメント事業部門 基盤インテグレーション事業本部 通信基盤インテグレーション部所属。東京都出身　東京都在住。MySQLやMySQL Clusterのコンサルティング、設計構築、プリセールスなどを行っていたが、最近は営業やマーケティング活動もカバーするようになり、技術が分かる営業として日本国内を縦断中。

荻野邦裕（おぎの くにひろ）

SCSK株式会社所属。神奈川県横浜市在住。1983年よりIT業界へ。その間Oracleを中心とした、DB関連作業を多数経験。DBの移行を得意とする。趣味は自己チューニング（水泳、マラソン、筋トレ）及び愛犬アポロ（チワワ）と遊ぶこと。

潮雅人（うしお まさと）

SCSK株式会社 ITマネジメント事業部門 基盤インテグレーション事業本部 通信基盤インテグレーション部所属。神奈川県川崎市在住。入社当初よりデータベースの設計構築や技術サポート業務に従事。MySQLを中心にしつつもOracle Database、Oracle RACなどの構築にも携わる。趣味はスノーボード、スキューバダイビング、海外旅行など。