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

本連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。今回は、Oracle DatabaseからMySQLへの移行に向けたステップである「オブジェクト／データ型の移行コスト評価」を行います。

[荻野邦裕，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などの構築にも携わる。趣味はスノーボード、スキューバダイビング、海外旅行など。