Oracle Databaseへの移行 オンプレミスまたはクラウドにおける移行ガイド

Oracle ホワイト・ペーパー | 2017 年 2 月

1 | Oracle Database への移行

概要 このホワイト・ペーパーでは、Oracle SQL Developer ツールを使って他社製データベースを Oracle Database 12c に移行するプロセスについて詳述します。他社製データベースを Oracle Database インスタンスに変換する上で必要な手順を示し、既存のアプリケーションを最終製品、つまり移行済みの Oracle インスタンスと連携させる方法についても説明します。移行リポジトリを作成し、ソース・データベースをキャプチャして Oracle データ型に変換し、そのデータをコピーする方法を学びます。ここで示す例では、2 つのクラウド環境、Oracle Database Cloud Service（DBaaS）と Oracle Database Exadata Cloud Service を中心に、オンプレミスとクラウドのシナリオを取り上げます。

一般に、他社製 RDBMS から Oracle Database へのデータ移行プロセスは単純です。Oracle Database と通信できるようにアプリケーションのアーキテクチャを変更する手順は、新しい JDBC ドライバまたはODBC ドライバにドロップ操作を実行するだけなので簡単です。ストアド・プロシージャを Oracle のPL/SQL エコシステムに移動する手順はやや複雑になります。移行ごとに手順が異なり、アプリケーションによっては、テクノロジー・スタックのもっとも下のレベルで変更を行う必要があります。潜在的な障害物を特定して適宜計画を立てるには、問題を事前に正しく洗いだすことが重要です。

このホワイト・ペーパーでは、Oracle Database 12.1.0.2 以上にアクセスできることを前提としています。Oracle Database のライセンスと価格について不明な点がある場合は、オラクルの営業担当者にお問い合わせください。

Oracle Database Cloudへの移行で得られる利点 Oracle Database 12c では、他社製データベースから Oracle プラットフォームへの移行に必要なコストと時間を大幅に削減する重要な新機能がいくつか導入されています。Oracle Database Cloud Service により、従量課金制サービス、または Oracle 11g、12.1、12.2 のデータベース・サービスの月額サブスクリプションを選択できます。高可用性構成を自動的にプロビジョニングすることで、メンテナンスや予期しない障害シナリオのサービス・レベルを引き上げることができます。プロビジョニングの選択肢には、DevOps、パフォーマンス、セキュリティ、分析、モニタリング用のOracle Database オプションの、事前にパッケージ化されたバンドルが含まれます。このサービスには、統合された Oracle Application Express 環境が付属しているため、開発作業をクラウドに移行することができます。Oracle Database 12c Multitenant により、多くのデータベースを素早く統合し、これらのデータベースをクラウド・サービスとして管理することが容易になります。

移行範囲の特定 Oracle Database への移行に関する計画は通常、一連の問いから始まります。

• どのデータベースから移行するのか（SQL Server や DB2 など）

o そのデータベースのバージョンは何か。

SQL Server 2016 など、最新バージョンの場合、バージョン固有の機能を使用しているか。

• いくつのデータベースを移行するのか。

o 複数のデータベースを移行する場合、基本的に相互のデータベースをコピーするのか、またはそれぞれのデータベースを個別に移行するのか。

2 | Oracle Database への移行

• データベースの規模はどのくらいか（データ自体のディスク領域の、GB/TB 単位の容量）。

• データベース・アプリケーションは、ストアド・プロシージャに大きく依存しているか。

o 移行が必要なストアド・プロシージャおよびトリガーはいくつか。

o これらはおもに、‘select * from table return result set to application’カテゴリに分類されるのか。

• 移行プロジェクトのスケジュールの期間はどのくらいで、いつ"本稼働"する必要があるのか。

• Oracle と他社製のデータベース・システムを同時に実行する予定で、Oracle 実装環境にフェイルオーバーする計画なのか。

• 新しいデータベース・インスタンスをオンプレミスまたはクラウドに常駐させる予定か。

• 停止時間/メンテナンスを設ける場合、時間はどのくらいか。この移行でそうした時間を設けることは可能か。

• 自社製アプリケーションは何を基盤にしているのか（.NET、Java など）。

o ISV によって提供されるアプリケーションは一般に、独自の移行パスあり

停止時間の確保が選択肢にない場合、または移行後しばらくしてから、データベースの変更を元のシステムに複製しなければならない場合は、データの移行に必要な時間を短縮するために、Oracle GoldenGate 12c を使用することを検討してください。

データベース移行ツール Oracle SQL Developer を使用すると、移行するデータベースの物理的特性を特定できます。Oracle SQL Developer はどの Oracle Database のコピーにも含まれており、Oracle Technology Network でダウンロードすることもできます。このユーティリティは Oracle Database のグラフィカル・ユーザー・インタフェースとして、および PL/SQL の統合開発環境として機能します。

図 1：Oracle SQL Developer バージョン 4.1.2

3 | Oracle Database への移行

SQL Developer は、Oracle Database 用の公式な他社製データベース移行ソリューションでもあり、現在、SQL Server、Sybase ASE、DB2、Teradata をサポートしています。また、MySQL からの移行も支援します。サポート対象データベースの正確なバージョンについては、OTN で最新情報を調べてください。

SQL Developer は他社製データベース定義をキャプチャし、それらの定義を分析して Oracle の対応する定義に変換し、データの移動と検証に必要なツールをユーザーに提供します。こちらが、サポートされている JDBC ドライバのリンクです。

SQL Developer の 9 ステップ・ウィザードを使用すると、移行プロジェクトを作成できます。移行プロジェクトには、環境の設定、および他社製ソース・データベースのキャプチャと変換プロセスの実行が含まれます。

環境の設定 データを Oracle Cloud に移行する場合、または社内の Oracle Database をインストールする場合があります。移行するデータベースの数が 1000 でもたったの 1 つでも、移行プロセスとツールがどのようなものかを掴むには、小さい数から始めるのがベストです。次の手順を実行する必要があります。

• 以下に説明するように、プロジェクト・メタデータを保存するためのリポジトリを設定した Oracle Database 12c

• 最新バージョンの Oracle SQL Developer

• 他社製データベースに接続するための正しい JDBC ドライバ

オラクルは、Oracle Database 12c に付属の VirtualBox アプライアンス、最新バージョンの SQL Developer、およびデータベースの移行方法の例を示すハンズオン・ラボを提供します。仮想マシンは商用利用向けに認定または提供されていませんが、Oracle Database の移行を実行するプロセスの一部始終を学ぶ上で役立ちます。

他社製JDBCドライバの追加およびソース・データベースへの接続 サポートされる JDBC ドライバ・リストから、データベースのタイプに合った適切なドライバをダウンロードしてください。Oracle SQL Developer の「Preferences」に移動します。Database ページの「Third Party JDBC Drivers」ページを選択します。「Add Entry…」をクリックし、以下に示すように適切な jar ファイルにナビゲートします。

4 | Oracle Database への移行

図 2：Sybase ASE と Microsoft SQL Server の移行には jtds v1.3 を推奨。

ドライバを追加したら、そのドライバと互換性のあるデータベースへの接続を定義できます。

ソース・データベースへの接続を作成します。移行するオブジェクトとデータを参照できることを確認します。ターゲット Oracle Database で、移行リポジトリ用の新規ユーザー/スキーマを作成します。リポジトリの作成に使用できるように、このスキーマへの SQL Developer 接続を定義します。

SQL Developerのウィザードの起動 SQL Developer の「Tools」メニューに移動し、「Migration」 -> 「Migrate…」の順に選択します。

ウィザードが起動して、移行リポジトリの作成、オブジェクトのキャプチャ、Oracle Database への移行実行のプロセスをガイドします。

リポジトリは事前に作成することも、ウィザードで作成することもできます。

5 | Oracle Database への移行

図 3：移行ウィザード

次のページでは、移行リポジトリの接続を選択します。すでに作成した接続を選択するか、「Create new connection」ボタンを使って新しい接続を作成します。

移行リポジトリが Oracle インスタンス内に作成されます。移行先にするインスタンスと同じインスタンスである必要はありません。

次に、プロジェクトの名前を付け、移行プロジェクトの出力用のディレクトリを選択します。移行する他社製データベースを選択します。データ・モデルへのアクセスには、‘ライブ’接続、およびシェル・スクリプトでキャプチャされるオフライン・モデルの 2 つの選択肢があります。デフォルトの選択肢は'オンライン'です。

オフラインを選ぶのは、移行を実行するエンジニアが他社製ソース・データベースへのアクセス権を持っていない場合です。このシナリオでは、'Tools -> Migration -> Create Database Capture Scripts…'のインタフェースを使用します。

このコマンドによって、Windows バッチ・ファイルまたは Linux シェル・スクリプトのいずれかが生成されます。管理者がこのファイルまたはスクリプトを実行すると、ソース・データベースのデータ・モデルがキャプチャされてファイルに書き込まれます。これらのファイルは、移行ウィザードの'Source Database'ページで参照できます。

6 | Oracle Database への移行

図 4：他社製ソース・データベースへのアクセス権がない場合は、オフライン・モードを使用。

接続が確立されたら、移行するデータベースを 1 つ以上選択します。変換する適切な Oracle データ型を決定します。たとえば、Sybase ASE データ型‘DateTime’は Oracle で‘Date’として保存されます。同様に、‘Time’は‘Timestamp’として保存されます。独自のデータ定義ルールを作成する必要がある場合は、デフォルト値をオーバーライドしてもかまいません。

予約語の衝突、オブジェクト名の長さの制限（Oracle Database 12c Release 1 の 30 語の制限など）を避けるため、オブジェクトの名前は移行プロセス中に変更されます。データ・オブジェクトは別として、SQL Developer は制約、ビュー、関数、プロシージャ、トリガーも変換します。他社製データベースごとに変換されるサポート対象オブジェクトのリストについては、こちらを参照してください。

デフォルトでは、SQL Developer は、使用可能なすべての‘SQL’オブジェクト、つまり、ネイティブの埋込み SQL または T-SQL のあるオブジェクトを変換しようとします。

ターゲット・データベースの指定 ターゲット・データベースのステップでは、移行した Oracle ユーザーとオブジェクトを生成する方法を指定できます。その手順では、2 つのモード（オンラインとオフライン）があります。

7 | Oracle Database への移行

図 5：移行済みオブジェクトは任意の Oracle インスタンスに送信することが可能。リポジトリ接続は使用不可。

Oracle Cloudでのターゲット・ロケーションの選択 Oracle SQL Developer は、Oracle Database Cloud Service および Oracle Database Exadata Cloud Service への接続を促進します。ただし、SSH を介したオープン・インターネットからポート 22 へのトラフィックは両方のサービスで制限されます。これらのクラウド環境で実行中のターゲットOracle Database に接続する前に、SQL Developer SSH トンネリング機能を使ってデータベースに接続します。

8 | Oracle Database への移行

図 6：トンネルを作成するときに、ポート転送を設定することも可能。

ホストは、DBaaS インスタンスのネットワーク・ロケーションです。ユーザー名は、SSH 経由で接続している DBaaS サーバー上の OS ユーザーです。Port forward 画面では、ポート 22 からポート1521 の DBaaS リスナー・ポートへのトラフィックを許可できます。このパスを定義すると、DBaaS 接続はこのトンネル経由で接続を行い、この接続は移行ターゲット用に使用することができます。

9 | Oracle Database への移行

図 7：Oracle SQL Developer での SSH トンネルを介した DBaaS 接続。

接続後、以下に示すプロセスに従って、Oracle Database のクラウドベースまたはオンプレミスのインスタンスへの移行を実行できます。いずれの場合も、新しい Oracle ユーザーを定義し、そのユーザーへの接続を行い、必要な表、索引、ビュー、プロシージャなどを作成する"生成スクリプト”が SQL Developer によって作成されます。このステップの間、データの移動は行われません。

オンライン・モードでは、ウィザードを使ってターゲット Oracle Database を選択し、次に、生成スクリプトを自動的に実行します。選択する接続には、新しいユーザーを作成し、関連するすべてのオブジェクトを移行するための権限があることが必要です。

オフライン・モードでは、ターゲット Oracle Database を選択する必要はありません。代わりに、SQL Developer の SQL Worksheet で生成スクリプトを開くことができるので、最初にこのスクリプトを確認することができます。次に、SQL Worksheet でターゲット Oracle Database を選択し、ワークシートに対してスクリプトを実行します。

Oracle表へのデータのロード データの移行には常に‘オフライン’モードを使用します。このモードでは、データを Oracle ソース表にロードする SQL*Loader スクリプトが作成されます。‘オンライン’モードは、特にデータ量が少ない場合にテストとして実行する分には最適です。オンライン・モードで大規模インスタンスを移行すると、数日かかる場合があります。この機能を SQL Developer インタフェースから実行することは推奨されません。

10 | Oracle Database への移行

図 8：‘オンライン’モードはテスト実行と小規模なデータベースの場合に、

‘オフライン’モードはそれ以外の場合に使用すること。

移行結果の確認 移行終了後、移行プロジェクトを開いて、オブジェクトがどのようにキャプチャされ、変換されたのか、その詳細を確認できます。オブジェクトごとにソートされ、要約された問題に関するレポートが複数あります。ほとんどのレポートは、上から下に情報が表示される構成になっています。ページ上部の項目を選択すると、ページ下部にその項目のタイプの情報が表示されます。

各オブジェクトは‘ホットリンク’されているため、即座にオブジェクトの詳細を表示して、問題を確認し、修正することができます。

11 | Oracle Database への移行

図 9：このレポートには、オブジェクトのグループとステータスが表示されている。

ホットリンクにより、個々のオブジェクトの詳細を表示。

Oracle Database の移行は大部分が自動化されています。ほとんどのお客様は、80 パーセントもの高い変換率になっています。ただし、移行はそれぞれのケースによって異なり、結果も異なる場合があります。たとえば、ストアド・プロシージャは、対処が必要なエラーとともにコンパイルされることがあります。一般には、オラクルの自動手順によって、全体的な移行作業量が劇的に軽減されます。

変換問題の対処方法 Oracle 以外のストアド・プロシージャを Oracle PL/SQL オブジェクトに変換する、SQL Developerによって採用されるトランスレータは、これらのプロシージャを 100 パーセント変換するわけではありません。各 RDBMS の独自のコーディング手法のため、これらのデータベース・アーチファクトの一部は自動的に Oracle に変換できません。各開発チームにこれらの RDBMS 機能を独自の手法で利用しているため、これらのコーディング・ギャップはサイト間でも異なります。

すべての RDBMS コードが変換された場合でも、移行終了後の Oracle Database を徹底的にテストして精度とパフォーマンスを調べてください。他社製データベースで採用されているプログラミング構造と手法の一部は、Oracle で直接対応していません。移行プロセス中、変換の問題にはフラグが付けられます。ほとんどの場合、移行を完了とするには、追加のコーディングが必要かどうかを示すコメントが挿入されます。

SQL Developer の PL/SQL エディタで無効なオブジェクトを開けば、組込みのエラー・メッセージの参照、プロファイラ、デバッガを利用できるので、コードを分析し、問題を修正する作業がはるかに容易になります。

12 | Oracle Database への移行

図 10：コンパイラ・エラー、および移行済み T-SQL 関数用に変換されるコードを示す Procedure Editor。

たとえば、上の図では、行 37 と 38 のストアド・プロシージャに注意する必要があることを示しています。この場合、問題を解決する作業には、DBMS_STATS パッケージのコールをストアド・プロシージャに直接挿入するのではなく、表の統計情報を収集するためのストアド・プロシージャを作成する作業が伴います。Oracle の場合、表のすべてまたは一部の統計情報を生成できます（たとえば、表データの 25 パーセントを使って、オプティマイザの統計情報を生成できます）。このような決定には、アプリケーションとデータ・モデルに関する詳細な知識、つまり手動の操作が必要です。

どの程度、手動の操作が必要なのかというと、最近実施した移行プロジェクトでは、52 の PL/SQLオブジェクトと 132000 行のコードに対して 256 の“やること”項目が記録されました。項目数がコードの性質によって異なる一方で、自動移行手順を実行するたびに、コードをテストし、コードの問題を修正する作業に十分な時間を割り当てることが必要です。これから行う作業範囲を適切に評価できるように、プロジェクトの早い段階で‘キャプチャ’プロセスを実施します。

データの移動 – オフライン手法とオンライン手法 移行するテスト・データベースが小規模でない場合は、オフライン手法を使用してください。プロジェクトから移行を開始するには、プロジェクト・キャプチャを右クリックして「Move data…」を選択します。

このコマンドにより、移行ウィザードがデータのステップに進むので、オンラインまたはオフラインかを選択します。オンラインを選択すると、ソース・データベースと移行先データベースの両方に接続され、ソース・テーブルからデータが読み取られてターゲット表に挿入されます。この手法は、データ量が少ないテスト環境にしか推奨されません。大規模データベースと本番データベースにはオフライン・モードを使用してください。

オフライン手法では、データがローカルのデリミタ付きテキスト・ファイルにキャプチャされ、これらのファイルから Oracle SQL*Loader ユーティリティにデータがフィードされます。SQL*Loader は、大量のデータを非常に迅速にロードするように設計されています。拒否された

13 | Oracle Database への移行

レコードは、後続の実行時に修正し、移動できるように自動的に記録されます。SQL*Loader は、ターゲット Oracle サーバー上のどの Oracle Database のコピーにも含まれています。

キャプチャを実行するには、SQL Developer によって生成されたスクリプトを実行します。SQL Serverと Sybase の場合、これらのスクリプトでは BCP ユーティリティが使用されます。BCP ユーティリティは、各 SQL Server ダウンロードに付属する Microsoft コマンドライン・ユーティリティです。

図 11：MicrosoftSQLServer_data.bat ファイルを実行して、データをローカル・フラット・ファイルにエクスポート

スクリプトの終了後、プロジェクト・ディレクトリの‘datamove’サブディレクトリと‘data’サブディレクトリを見ると、一連のスクリプトと SQL*Loader の制御ファイルとデータファイルがあることが確認できます。

14 | Oracle Database への移行

図 12：SQL*Loader データファイルを示すディレクトリ一覧表示。

SQL*Loader を実行するには、Oracle クライアントまたは Oracle Database のいずれかのインストールが必要です。クライアントがある場合は、ローカル・マシン上で oracle_loader.bat ファイルを実行できます。あるいは、ファイルを直接 Oracle Database サーバーに移動することも可能です。

ターゲット・データベースが DBaaS クラウドである場合は、SQL*Loader ファイルを DBaaS マシンに移動して、そこから直接スクリプトを実行します。

15 | Oracle Database への移行

データ品質の検証 データの移行が完了したら、データ品質評価を実施できます。データ品質評価では、元の表と変換後の表で生レコード数が比較され、差分がハイライト表示されます。非常に大規模なデータベースの場合、評価の生成には長時間かかるので注意してください。

図 13：元の表と変換後の表が左右に並んでいるデータ品質レポート

Oracle GoldenGate 12cによる高度なデータ移行 移行によっては、高度なツールが必要です。特定のアプリケーションのニーズと品質保証契約によっては、停止時間を最小限にするために、データ移行をより迅速に実施する必要があります。同様に、データ同期を実行できるように他社製データベース・アプリケーションと新しい Oracle アプリケーションを同時に実行する必要がある場合は、Oracle GoldenGate 12c などのレプリケーション・テクノロジーの使用を検討する必要があります。このテクノロジーは、異種環境でリアルタイムのデータ統合とレプリケーションを実行するための包括的なソフトウェア・パッケージです。

Oracle GoldenGate 12c は、高可用性、リアルタイム・データ統合、トランザクション・データ変更取得、データ・レプリケーション、データ変換、業務系エンタープライズ・システムと分析系エンタープライズ・システムとの間のデータ検証が必要なシナリオに最適です。クラウド環境の標準サポート、異種対応の拡張、セキュリティの強化により、パフォーマンスを大きく向上させ、構成と管理を簡素化します。Oracle GoldenGate 12c は Oracle Database ライセンスに含まれていないため、ライセンスについてはオラクルの営業担当者に問い合わせてください。

アプリケーションの移行 アプリケーションとデータベース間の接続性には、移行プロジェクトの開始時に対処します。.NETアプリケーションまたは Java アプリケーションを使用している場合は、ODBC ドライバまたはJDBC ドライバを Oracle ドライバに切り替える必要があります。切り替えたら、アプリケーションが Oracle SQL 言語を介して新しい Oracle Database に接続でき、通信できることを確認します。Oracle SQL は ANSI SQL 規格の大部分をサポートしますが、Oracle によるこの規格の解釈は、SAPの Sybase に対する解釈、Microsoft の SQL Server に対する解釈、IBM の DB2 に対する解釈などとは異なります。

16 | Oracle Database への移行

SQL Developer にはアプリケーション・スキャナ・スクリプトが付属しており、このスクリプトを使ってデータベース・コードを監査して、データベース・アプリケーションで変更が必要な箇所を判別できます。また、SQL 言語とストアド・プロシージャを Oracle の対応する SQL 言語とストアド・プロシージャにその場その場で変換できる、Scratch Editor も提供します。

Oracle Database 12c SQL 変換フレームワークは、これまでよりはるかに強力なインタフェースです。Sybase ASE と SQL Server T-SQL の場合、このフレームワークはこれらの SQL 言語の問合せを受信し、Oracle の対応する問合せに変換して即座に実行できます。

また、Oracle Database 12c には、Oracle Database へのアプリケーション移行に必要なコストと時間を軽減するその他の機能が多数含まれています。詳細については、ホワイト・ペーパー『Oracle Database 12c によるアプリケーションおよびデータベースの移行』を参照してください。

実践的アドバイス 小規模なデータベースまたはテスト・データベースから始めてください。ウィザードにより、プロセス全体を 1 つのステップで進めることができますが、次の基本的な部分に分けた方が合理的です。

• キャプチャと変換を実行する

o すべてのオブジェクトがキャプチャされ、変換が許容レベルであることを確認します。

• 新しい Oracle オブジェクトをデプロイする

o オブジェクトがエラーなしでコンパイルされ、すべてのオブジェクトが存在し、それらのオブジェクトが予想どおりの Oracle スキーマ内にあることを確認します。

• データを移動する

o データを Oracle にコピーするために必要な時間がプロジェクトの要件を満たしていることを確認します。外部表などの手法、Oracle GoldenGate 12c などのライセンス製品を使って、このプロセスを加速化し、微調整することができます。

• 出力が予想どおりかを確認するために、サンプル・アプリケーション

またはレポートを実行するウィザードを使用すると、どのステップでもプロセスを開始、停止、再開することができます。

参考資料 Oracle Database 12c への移行は、Oracle SQL Developer の移行機能でより容易になります。移行を成功させるには、まず、プロジェクトの要件を特定し、移動の必要なデータとアプリケーションを分析し、トライ・アンド・エラーの精神で挑むことが必要です。Oracle Database 12c および Oracle Database Cloud への移行の詳細については、SQL Developer を使用した移行のページを参照し、これらの移行フォーラムで情報を確認してください。

Oracle Corporation, World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065, USA

海外からのお問い合わせ窓口

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

Connect with us

blogs.oracle.com/

facebook.com/Oracle

twitter.com/Oracle

oracle.com/

linkedin.com/company/oracle

youtube.com/user/Oracle

Copyright © 2017, Oracle and/or its affiliates. All rights reserved.本文書は情報提供のみを目的として提供されており、ここに

記載される内容は予告なく変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、

また、口頭による明示的保証や法律による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示的保証および条

件などのいかなる保証および条件も提供するものではありません。オラクルは本文書に関するいかなる法的責任も明確に

否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクルの書面による

許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成ま

たは送信することはできません。

Oracle および Java は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。