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

» 2017年03月31日 05時00分 公開
[荻野邦裕SCSK株式会社]
前のページへ 1|2       

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


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。