http://dev.mysql.com/tech-resources/articles/migration-software.html

Dmitry Tolpeko

Oracle, SQL Server, Informix、 Sybase上のデータベース
をMySQLにマイグレートする際には全部のマイグレーションを
自動化するにが必要です、一部だけ変換すると、目に見えないコストが
発生する恐れがあります。

初めに

最新の版のMySQLはエンタープライズのアプリに高性能、信頼性、
スケーラビリティと経費節減という恩恵をもたらします。このため
に Oracle, Microsoft SQL Server, Sybase、Informix 上
のミッションクリティカルのデータベースをMySQLへ変更しよう
という会社が多いです。

データベースのマイグレーションはITのスタッフにとっては大きな
仕事です。それは様々な変換の問題や主なデータベース間の
非整合性や現存のデータベースのアプリを正しく実行させ続けさせる
というような幾つもの問題があるからです。

ITの専門家はデータベースの変換の複雑さを簡単に見積もりすぎます。
そして、その変換のプロセスの問題を良く検討しません。そのため
一部のみの変換を行うツールを使い残りは手で行います。しかし、
エンタープライズのデータベース内にある莫大な量のオブジェクト
(テーブル、procedures その他) のために、手動のプロセスでは
プロジェクト遂行の際に生じる予測しなかった問題が生じると大きな
遅れやマイグレーションに掛かる経費を劇的に増加します。

この記事の目的はエンタープライズのデータベースをMySQLへ
マイグレートする際の問題点と必要なタスクに関して述べることです。
また、データベースの専門家に包括的で途切れない変換を
保障し、予定した時間と予算で完結するような情報をもたらすことです。

エンタープライズ　データベースのマイグレーション要求

異なったデータベース管理システムのSQLのシンタクスや機能差
の他に、マイグレーションの複雑さとマイグレーションの方法と
ツールに影響を与える次の要素を考慮しなければなりません。

データベースとそのアプリケーションの変換 ーー データ変換だけではない

OracleやSQL Serverその他のエンタープライズ・クラスのデータベース
管理システムはアプリケーションの開発に様々な機能を提供します。
データベースは、アプリと密につながっており、ビジネス・ロジックと
ルールを実装します。更に、ミッション・クリティカルなアプリの
性能、セキュリティやモジュール化を促進させます。

このため、データベースマイグレーションは単にデータの変換と
考えるわけにはいきません。データ・スキーマ(テーブル、
ビューの定義, 一貫性制約など) とサーバー側の
ビジネスロジック(stored procedure と関数)の変換も含みます。

全てのデータベースの機能とデータベースのオブジェクトはアプリ
にとって大変重要です。そしてこれらはアプリの動きや
機能を保持するために完全に変換されなければなりません。

大量のデータベースのオブジェクト ーー手動では高価

企業のデータベースは何十万というデータベースのオブジェクト
(テーブル, ビュー, procedure　など)を含んでいます。この大量の
オブジェクトと様々な機能が使用されているため、マイグレーション
のツールはできるだけ多くの変換のタスクを処理できる必要があります。
手動による方法は比較的簡単な問題であったとしても、
多くのオブジェクトを扱いますので、時間がかかり結局コスト高
になります。

もう１つの問題はデータベース間の相互依存です。殆ど全てのプロシージャは
テーブル、ビュー、その他のプロシージャを参照します。こういった
依存関係は変換の最中でも維持されなければなりません。

例えば、もしソースのＩＤ (テーブルまたはコラムの名前など)
がMySQLのキーワードであれば、それは特別の文字で囲まれる
かMySQLにマイグレートする時には変更が必要です。変更はこのＩＤ
に関する全てのビュー、プロシージャー、アプリに適用される
べきです。

大量のデータ

エンタープライズのデータベースは大量のデータを格納します。
このため、MySQLにデータを移行するには使用するデータインポート
の方法によっては何十時間もかかるかも知れません。かかる時間
は大きく異なることがあります。スピードをあげるために
もっとも適したツールを使用することが肝要です。

マイグレーションのソフトへの要求

上で述べたようなエンタープライズ・データベースとアプリの
状況を考慮して、大分の変換のタスクを自動化して手動を
を避けるためのマイグレーション・ソフトの要求を定義できます。

包括的で統合された解

マイグレーション・ソフトはデータだけでなく、データベース
のスキーマ全部とビジネスロジックも変換する必要があります。

このソフトはLOB コラム（イメージ、ビデオ等）やデータタイプ
を含むテーブル定義、NULLとidentity properties、
デフォルトの値、プライマリとフォーリンキー、 固有制約、
ビュー、stored proceduresと関数の変換もサポートしなければなりません。

SQLのシンタクスの差異のほか、このソフトはキーワードとか
ＩＤのコンフリクトなどの問題も処理できなければなりません。
それぞれのデータベースはキーワードの一覧をもっています。
キーワードはクオートなしにはＩＤとして使用できません。
マイグレートするデータベースではキーワードではないが
MySQLではキーワードであるときに問題が生じます。例えば、
「LIMIT」はOracleではキーワードではありませが、MySQLではキーワード
です。MySQLに変換する際はそのようなＩＤはクオートで包むか
全ての場所（ビューstored procedureなど）で変更する必要があります。

ツールはMySQL特有なシンタクスを理解しているだけなく、
他のテーブルでは必要とされないが、子テーブルのフォーリン・キー・コラム
のインデクスを生成することができなくてはなりません。

マイグレーションツールは関連するデータベース・オブジェクト
の変更をトラックし保守できなければなりません。例えば、
テーブルにどんな変更が加えられても、このテーブルを参照する
全てのオブジェクト（ビューとかstored procedure）に反映されなければ
なりません。

マイグレート・ソフトがこの要求を満たさず、データだけを
変換した場合、手動で変換を完了するか、幾つかのツールを
組み合わせてもっと複雑なマイグレーションの解を開発する
必要があります。後者の場合、そのようなツール同士はうまく
結合することができないでしょう。１つのツールでデーターべース
に変更が加えられたと認識されても他のツールでは認識されません。

グローバルなルールを提供する柔軟な解　　

一般的にデータベースの構造やデータを変換時に大きく
変更することは求められていません。というのも、大幅
な変更を加えるとアプリの書き直しがマイグレーションのコスト
を非常に高価なものにするからです。

大部分の場合マイグレートされたデータベースはアプリケーションの
機能を完全に保障するために大きく変更が加えられることはありません。
しかし、たびたびデータベースのスキーマを少し変更したり
アプリの新たな要求を満たすためのオプションをセットしたり
することがあります。

例えば、元のデータベースとMySQLの間でデータのタイプ
のマッピングが必要だとか、フォーリンキーをサポートする
ためにInnoDBテーブルタイプを指定する必要があるとします。

キーワードだったり特別な文字を含むＩＤを変換する場合
にはルールが必要です。デフォルトではそうしたＩＤは
クオートで（MySQLではバックチックで）で包まれます。しかし、
開発者がSQLのクエリやプロセージャーを書くときにクオート
で包まれたＩＤを使わせることはあまり例がないし、不便です。
そのためクオートが必要でないＩＤに代えようとするでしょう。

最後にデータベース・マイグレーションソフトは柔軟で、
どのような変更も認め、様々なセッティングを許すべきです。
すべての個別のオブジェクトを変更できることの他に、
ツールはグローバルにオプションや、全ての
オブジェクトに対してルールをセットできなければなりません。
でないと、複数のオブジェクトに対して同じオプションを
セットするのは非常に時間がかかります。

アプリケーションの変更の助け。

大抵の場合アプリはデータベース変更の後は変更が必要となります。
大抵の場合、変更はアプリの構造を変えるものではありません。
ネイティブのSQLステートメントを変え、データベース（ＩＤ、データタイプなど）
に変更されたを考慮して、アプリとMySQLデータベース
のインターフェースの非整合性がある場合にはそれも解決しなければ
なりません。

マイグレーション・ソフトは変換時に加えられた全ての変更を
レポートする機能が必要です。しかしながら、全てのデータベース
のオブジェクトやコラムをレポートする必要はありません。
そのような情報はデータベース管理ツールから得ることができますし、
アプリケーションの実行に影響を与え変更を解析
することができないからで、アプリの変更をしいるからです。

マイグレーション・ソフトはアプリケーションのマイグレーション
を容易にして、SQLステートメントを変換するユーティリティを
提供し、他の変換問題を解決すべきです。

高性能

エンタープライズデータベースは大量のデータを含むので
元のデータベースからMySQLへデータを転送するには長い時間
がかかります。そのために、マイグレーション・ソフトは
一番速い方法でデータをMySQLにインポートすべきです。

Oracle やBM DB2のように、 MySQLは大量のデータをロードする
のに効率的な高性能のツールを提供します。「MySQL LOAD DATA INFILE」
コマンドは 「SQL INSERT」ステートメントよりデータのインポート
では２０倍速いです。(より詳細な情報は、「MySQL オプティマイゼーション」
の章を参照してください。）

マイグレーションソフトは「LOAD DATA INFILE」でもマイグレートできる
オプションを与えるべきです。このオプションではデータ転送の時間
を削減することができるからです。（それでも数時間かかります。）
ODBCインターフェースとSQL INSERTステートメントを使ってのデータ転送
はエンタープライズのデータベースには使い物にはなりません。

データインポートの性能を増加させるために、変換ソフトは固有制約
とデータのインポートの後のインデクス生成する機能を持つべきです。

マイグレーション・ソフトのカスタマイゼーションのサービス

一般的にデータベースのマイグレーションは完全に100％全てのデータベース
とアプリに関して自動化できるものではありません。

とはいえ、データベースとアプリが限られた機能を使用するのであれば
現存するマイグレーション・ソフトは95%程度までには変換を
自動化できます。

上記のように、大量のオブジェクトと大部分のオブジェクト
での未変換機能のために、残りの5%でも手動でを使うと全体の
コストと時間を押し上げます。

そのため、マイグレーション・ソフトのベンダーは特定の
プロジェクトにソフトをカスタマイズして手動を避けるべき
です。

MySQLのマイグレーション・ツールの概略

現在エンタープライズのデータベースをMySQLに変換するツールは
市場に数個あります。

Ispirer SQLWays

SQLWaysはもっとも包括的なマイグレーションツールです。
これはデータ、データベース・スキーマ (テーブル、ビュー定義,
データタイプ, プライマリーとフォーリン　キー, 固有制約,
ＩＤとNULL properties, デイフォルトの値, コメント)
とビジネスロジック(stored procedures と関数) を変換して
Oracle, SQL Server, Sybase, IBM DB2、Informixから MySQLに
マイグレートします。.

SQLWays は特別に設定されたマイグレーションソフトで、様々な
変換プロジェクトに柔軟に適用でき非常に効果的です。

このツールはデータタイプのマッピングを再定義し、テーブルにつき
データ(例InnoDB)を格納するテーブルのタイプの選択や他の
オプションの設定をします。SQLWaysは自動的にＩＤとキーワードとの
コンフリクトを解決します。ユーザがデータベースのオブジェクトを
変更した場合、ツールは依存するテープル、ビュー、stored procedureなど
に変更を反映します。SQLWays はソースのデータベースをSQLスクリプト
にエクスポートします。これで、サードパーティのツールや
スクリプト言語(例Perl）を使ってマイグレーション・プロセスを拡張できます。

SQLWays は変換の間の変更に関してレポートを作成し、アプリの
変換の手伝いもします。

OracleとIBMが自分たちのデータベースにマイグレートする
ためのツールのように、 SQLWays はエンタープライズ
データベースのマイグレーションに効率的なエクスポート・インポート
プロセスを使い、内部で高性能のMySQLの「LOAD DATA INFILE 」コマンド
を使用してMySQLへの一番速いデータインポートを提供します。

SQLWaysの詳細は http://www.ispirer.com

Embarcadero DT/Studio

DT/Studio は高性能のETL (Extraction,
Transformation と Loading)ツールです。 それぞれの
データベースからMySQLへのデータ変換に使用できます。

DT/Studioはデータウエアハウス用のプロジェクト用に
開発されデータ変更と変換に使われます。しかし、DT/Studioはデータ
モデリングとリバースエンジニアリングの機能を持っています。
またデータベーススキーマの変換も含みます。

マイグレーション・プロジェクトにはあまり適用されませんが、
DT/Studioはデータベースの構造を大幅に設計しなおしたり、変換の
最中にデータを改造するときに有効です。変換機能をたくさん
もっているからです。

DT/Studio はサーバーサイドのビジネスロジック(stored procedureと関数など)
やアプリはMySQL用に変換しません。

DT/Studioの詳細は
http://www.embarcadero.com/products/dtstudio/

Microsoft DTS

Microsoft DTS はETLツール(Extraction, Transformation and Loading)
で様々なデータベースからMySQLにマイグレートするのに使用できます。

DTSはデータ転送と変換に重きを置き、Visual Basicのスクリプトを
使用してデータ変換を可能にします。

DTS を使えば、それぞれのテーブルにつきデータタイプを再定義でき
テーブルやコラムの名前を変更したり、テーブル用に「CREATE TABLE」ステートメント 

を指定できます。それぞれのテーブルは個別にオプションをセットすべき
です。DTS は全ての変換されたテーブルに効果的なオプションは
提供しません。

DTSはスキーマ変換に対しての機能は限られています。
プライマリーとフォーリンキー、ユニーク
制約、デフォルト値、identity コラムをサポートしません。
更に、ビューやstored procedureもMySQLに変換しません。

DTSの詳細はhttp://www.microsoft.com/sql

結論

最初にマイグレーションのプロジェクトの要求を解析する必要があります。
そして、もっとも良いツールを選択して全ての変換問題をカバーできる
用にすべきです。

エンタープライズのデータベースをMySQLへ変換する場合は手動はできるだけ
避けるべきです。でないと、マイグレーション・プロジェクトは時間が
かかり思いもしなかった経費がかかります。
---------------------
Zen Kishimoto                        zen@xxxxxxxxxx
IP Devices, Inc.                       (408) 567-9391
2175 De La Cruz Blvd., Suite 10  (801) 720-8847 (FAX)
Santa Clara, CA 95050