昨今、Cloud化の流れやMySQLなどフリーデータベースの隆盛により、データベースの移行を検討するケースが増えてきています。手動でデータベースを移行することは、とても大変な作業です。ただ闇雲に行うだけでは失敗の可能性だけが高くなってしまいます。ここでは異種データベース間でのデータベース移行をテーマに、「ここだけは抑えておきたい」ポイントをご紹介します。
移行先にテーブルを作る
まずは移行先データベースにテーブルを作ります。移行成功の多くはここに懸かっていると言っても過言ではなく、チェックするポイントも一番多くなります。
SQLの方言
テーブルごとにCREATE文を用意していきます。その構文はほとんどのデータベースで大筋は同じですが、細かな点で違いがあります。たとえばオブジェクト名の大文字小文字を区別する場合などに引用符で囲みますが、データベースによって異なります。また、SQL文を連続して発行する場合の「区切り文字」もデータベースに合わせて変更していきましょう。
ほとんどのデータベースは引用符で囲む事によって大文字小文字の区別がなされますが、PostgreSQLは引用符をつける事によって区別しなくなります。(「”Test”」は「TEST」として生成)ほかのデータベースと逆になりますので、特に注意が必要です。
囲み引用符、区切り文字の違い
| Oracle | SQL Server | PostgreSQL | MySQL | |
|---|---|---|---|---|
| 囲み引用符 | ”Test” | [Test] | ”Test” | `Test` |
| 区切り文字 | / | go | / | ; |
Oracleのオブジェクト名はほかと比べて短い
移行先がOracleの場合、オブジェクト名の長さにも注意が必要です。制限が30byteと意外に短く、テーブル名などに日本語を設定していると、思いのほかすぐに制限に抵触してしまいます。場合によりテーブル名の見直しが必要になるでしょう。なお、Oracle 12c R2より、128byteに拡張されます。今後はそれほど神経質になる必要はありませんが、現状は心に留めておく必要があります。
オブジェクト名の制限
| Oracle | SQL Server | PostgreSQL | MySQL |
|---|---|---|---|
| 30byte※ | 128文字 | 63文字 | 64byte |
※Oracle12 c R2より128byteに拡張
データ型を考える
データ型もデータベースによって名称が変わります。Oracleで「NUMBER」で定義しているものはSQL Serverでは「Numeric」か「Decimal」に変更する必要があります。
このように名称は違いますが同じ意味を持つデータ型にそれぞれ置き換えて行きます。変換ゆれなどを防ぐためにもマッピングテーブルを作成して整理しておく事をお勧めします。
データ型マッピングの一例(Oracle基準)
| Oracle | SQL Server | PostgreSQL | MySQL |
|---|---|---|---|
| BLOB | IMAGE | BYTEA | BLOB |
| CHAR | CHAR | CHAR | CHAR |
| DATE | DATETIME | DATE | DATETIME |
| LONG | TEXT | TEXT | TEXT |
| NCHAR | NCHAR | CHAR | CHAR |
| NUMBER | NUMERIC | NUMERIC | DECIMAL |
| NVARCHAR2 | NVARCHAR | VARCHAR | VARCHAR |
| VARCHAR2 | VARCHAR | VARCHAR | VARCHAR |
| BFILE | VARBINARY | BYTEA | BLOB |
| CLOB | TEXT | TEXT | TEXT |
| FLOAT | FLOAT | FLOAT | FLOAT |
| RAW | BINARY | BYTEA | BLOB |
| NCLOB | NTEXT | TEXT | TEXT |
同じ名前でも注意が必要
VARCHAR、CHARは、どのデータベースにも存在しておりますが(OracleはVARCHAR2)データベースによってUniCode文字が格納できる、できないの差があります。例に挙がっているデータベースのなかでは、SQL ServerのみUniCodeが格納できません(NVARCHARなどのN系のデータ型を使用する)。また、VARCHAR(20)とした場合、「(20)」の部分はOracleとSQL Serverは 通常は文字のbyte数を表しますが、PostgreSQLとMySQLは文字数をそのまま表します。移行元データベースのデータ格納状況に合わせて、柔軟に設定していきましょう。
日付型DEFAULT
最後に制約まわりを確認します。大きなところでは、やはり日付型DEFAULT関数でしょうか。Oracleは「SYSDATE」、SQL Serverは「GETDATE()」など、データベースごとに置き換えていきます。
代表的な日付型DEFAULT関数
| Oracle | SQL Server | PostgreSQL | MySQL |
|---|---|---|---|
| SYSDATE | GETDATE() | CURRENT_DATE | CURRENT_TIMESTAMP※ |
※5.6.5以降
移行先がMySQLの場合、Check制約への考慮が必要です。というのも、MySQLにはCheck制約がないのです。移行先でもチェックを行いたい場合、代替させる仕組みを用意する必要があります。下記はその一例です。
- ENUM型、SET型を使用する
ENUM、SETはデータ型の一種です。格納可能なデータを列挙して宣言する事ができ、それ以外のデータを排除する事ができます。 - トリガーを作成する
更新時に発生するトリガーで、エラーチェックやロールバック処理を生成します。
ここまででテーブル生成の処理が一通り終わりました。
ポイントを下記にまとめましたので確認しましょう。
ここがポイント
|
データを移行する
バイナリデータは扱いがむずかしい
ではいよいよデータを移行します。移行方法そのものについては、それほど問題はないと思います。先にあげたようにUniCodeデータに注意するくらいでしょうか。
CSVなどのテキストデータとして出力し、移行元でインポートするなどの方法が取れるデータベースもあります。単純なインポートが難しい場合でも、移行元でINSERT文を生成するプロシージャを作成し、移行先でそのSQLを実行することで比較的容易に移行できます。この場合、合間にCOMMIT命令を挟み込めば、データを確定しながらの移行も可能です。
ただ、バイナリ系のデータだけはテキストで扱えない分、工夫が必要になります。データの取り出し処理、読込処理をそれぞれ移行元データベース、移行先データベースで作成する必要があるでしょう。
また、この時点では移行の妨げになる可能性がある外部キーやトリガーは構築しておかないほうが無難です。
ここがポイント
|
移行データをチェックする
まずは件数確認からはじめよう
移行が済んだら、処理がうまくいったか確認します。一番簡単なチェックは、移行元データと移行先データの件数確認です。何らかのエラーが発生しデータの投入に失敗している場合は件数に差異が出ているはずです。ほかにも文字化けていないかなどの確認も必要に応じて行いましょう。全データを移行元、移行先でそれぞれテキストに出力し、比較ツールを使用して差分がないかを比較するのも有効です。
しかしながら、数万、数十万件のデータからエラーデータを特定していくのは、なかなか骨の折れる作業です。地道にいきましょう。
ここがポイント
|
ツールを使って自動化
SI Object Browser ER を使えば簡単にデータベース移行できます
データベース移行の流れ、及びそのポイントについてご紹介していきました。いかがでしたか？たぶん「大変な作業だ」と思われたと思います。確かに最初から最後まで手動で行なうのは大変です。
そこで、弊社では異種データベースの方言の違いを変換し、データベース移行、データベース・マイグエ―ションを簡単にできるツール「SI Object Browser ER(以下OBER)」を用意しました。このツールを使えば、RDBMSマイグレーションとデータ移行をあっという間に実施することができます。
【特長１】移行ナビに従って操作するだけでメタデータをコンバージョン
もともとOBERはデータモデリングツールでしたが、Ver.9.0より「データベース移行機能」を実装し、データベース移行を簡単に行えるようにしました。次のような移行手順に沿ったナビゲーションを用意していますので、ナビに従って操作するだけでスムーズにデータベースとデータの移行を行うことができます。
- 移行元データベースからテーブルをリバース
リバースエンジニアリング機能を使い、OBERから移行元データベースに接続して、テーブル情報を自動で取込みます。
- データベースタイプ一括変更
モデルのタイプを移行先データベースのものへと変更します。この操作で、引用符や区切り文字といったデータベースごとのSQLの方言が変更され、データ型、日付型DEFAULT関数もあらかじめマッピングされた内容に基づいて自動で変換されます。
- モデル検証
この機能では、移行元にそぐわない誤ったデータ型や日付DEFAULT関数が設定されていないかなど、モデルの正当性を検証します。オブジェクト名の長さ制限などもここで抽出できます。
- 移行先データベースにフォワード
移行先データベースに接続し、フォワードエンジニアリング機能を使用してテーブルを作成します。これでテーブル移行までは完了です。
- データ移行
あとはデータ移行画面にて、移行元、移行先双方に接続し、データを移行するだけです。同名テーブルであれば自動でマッピングされます。また、手動でマッピングを変更する事もできます。
データベースにテーブルを作成し、データを移行するまで特に迷う事もなく、あっという間に完了させる事ができます。①～⑤までの詳細や、データ移行機能については、下記特設ページをご用意しておりますので、興味のある方はご参照ください。
https://products.sint.co.jp/ober/support/history
OBERでは上記手順をナビゲートする「移行ナビ」画面もご用意しております。画面上の解説にあわせて順番に進めるだけ移行完了までご案内しますので、初めての方でも安心です。
【特長２】中間ファイルを介さず「右から左」へ驚くほど簡単にデータを移行
OBERでは移行時にデータベース間のデータ型の差異を埋めるため、移行元、移行先双方をいったん互換性のあるテーブルとして展開する手法を採用しております。そのテーブル間でダイレクトにデータコピーを行なうので、CSVなどのファイルに出力したり、INSERT文を作成したりしません。ファイルの出力、移送、取込といった手順を大幅に削減できるので、データ移行をより簡単に行うことができます。
バイナリデータも気にならない
この仕組みにより、手動移行の場合に特別に対応しなければならなかったバイナリデータも、ほかのデータと同じように「右から左」へ移行が可能です。また、一時的に外部キー、トリガーを解除する事もできます。(データ移行後に復元)
エラーデータはログで確認
データ移行後、成功件数/全体件数が表示されます。さらに、何らかの原因により移行(移行先テーブルへのINSERT)に失敗したデータは、１レコードごとにログとして吐き出されますので、移行失敗の原因究明に役立ちます。
まとめ
データベース移行におけるポイントや注意点は、データーベース移行ツールOBERを使用することによって解決できます。ツールを使って機械的な変換やチェックを行なう事によって移行ミスを防ぐ事ができますし、移行に関わる作業工数を大幅に削減することができます。
また、もともとOBERは設計効率を高めるデータモデリングツールです。移行後はそのままER図でデータベース設計・保守ができますので、移行作業だけでなく移行後も大幅に工数削減できます。
