Oracle データベースの移行: 再設計

Azure SQL Managed Instance
Azure Virtual Machines

Microsoft SQL Server を問題なく操作できていますでしょうか。 そうであれば、Azure SQL Managed Instance を使用して、データベースを再設計できます。 これは、次のような点で優れたオプションです。

アーキテクチャ

プライベート エンドポイント接続を介して Azure SQL データベースに接続されている Azure SQL マネージド インスタンスを示すアーキテクチャ図。

ワークフロー

  1. SSMA を使用して、Oracle スキーマを SQL スキーマに変換します。

  2. 新しいスキーマを Azure SQL Managed Instance に移行します。

  3. SQL マネージド インスタンスを Azure SQL データベースに接続します。

コンポーネント

  • Azure SQL Managed Instance はインテリジェントでスケーラブルなクラウド データベース サービスであり、幅広い SQL Server エンジンとの互換性と、フル マネージドの常に最新のサービスとしてのプラットフォーム (PaaS) のすべての利点を兼ね備えています。

  • Azure SQL では、SQL ポートフォリオ全体にわたって統一されたエクスペリエンスと、広範なデプロイ オプションが提供されます。

  • Azure Virtual Network は、Azure 環境のプライベート ネットワークです。

このシナリオのデプロイ

Oracle データベースの評価

Microsoft Assessment and Planning (MAP) Toolkit を使用して、既存の Oracle データベースとスキーマを評価します。 詳細は、「Oracle から SQL Server: 移行ガイド」を参照してください。

Oracle オブジェクトの変換結果

SSMA をダウンロードし、Oracle スキーマとデータの移行に使用します。Microsoft SQL Server Migration Assistant for Oracle

この表は、SSMA によって実行された Oracle オブジェクトから SQL Server オブジェクトへの変換結果を示しています。

Oracle オブジェクト 結果の SQL Server オブジェクト
関数 関数を Transact-SQL に直接変換できる場合は、SSMA によって関数が作成されます。
場合によっては、関数をストアド プロシージャに変換する必要があります。 この場合、SSMA によってストアド プロシージャが作成され、ストアド プロシージャを呼び出す関数が作成されます。
手順 プロシージャを Transact-SQL に直接変換できる場合は、SSMA によってストアド プロシージャが作成されます。
場合によっては、自律的なトランザクション内でストアド プロシージャを呼び出す必要があります。 この場合は、SSMA によって 2 つのストアド プロシージャが作成されます。1 つはプロシージャを実装するストアド プロシージャで、もう 1 つは実装ストアド プロシージャを呼び出すために使用されるものです。
パッケージ SSMA により、類似したオブジェクト名で統合される一連のストアド プロシージャと関数が作成されます。
シーケンス SSMA により、シーケンス オブジェクト (SQL Server 2012 または SQL Server 2014) が作成されるか、Oracle シーケンスがエミュレートされます。
インデックスやトリガーなどの依存オブジェクトを含むテーブル SSMA によって、依存オブジェクトを含むテーブルが作成されます。
トリガーなどの依存オブジェクトを含むビュー SSMA によって、依存オブジェクトを含むビューが作成されます。
具体化されたビュー SSMA によって、いくつかの例外を除き、SQL サーバー上にインデックス付きビューが作成されます。 具体化されたビューに以下の構成要素が 1 つ以上含まれている場合、変換は失敗します。:

ユーザー定義関数

SELECT、WHERE、または GROUP BY 句での非決定的フィールド、関数、式

SELECT*、WHERE、または GROUP BY 句での Float 型列の使用 (以前の問題の特殊なケース)

カスタム データ型 (入れ子になったテーブルを含む)

COUNT(distinct <フィールド>)

FETCH
外部結合 (LEFT、RIGHT、または FULL)
サブクエリ、その他のビュー
OVER、RANK、LEAD、LOG
MIN、MAX
UNION、MINUS、INTERSECT
HAVING
トリガー SSMA では、以下のルールに基づいて、トリガーが作成されます

BEFORE トリガーは INSTEAD OF トリガーに変換されます。

AFTER トリガーは AFTER トリガーに変換されます。

INSTEAD OF トリガーは INSTEAD OF トリガーに変換されます。 同じ操作で複数の INSTEAD OF トリガーが定義されている場合は、1 つのトリガーに結合されます。

行レベルのトリガーはカーソルを使用してエミュレートされます。

カスケード トリガーは複数の個別のトリガーに変換されます。
シノニム 以下の種類のオブジェクトに対して、シノニムが作成されます

テーブルとオブジェクト テーブル
ビューとオブジェクト ビュー
ストアド プロシージャ
関数

以下のオブジェクトのシノニムは解決され、直接オブジェクト参照に置き換えられます

シーケンス

パッケージ

Java クラス スキーマ オブジェクト

ユーザー定義オブジェクト型
別のシノニムのシノニムは移行できず、エラーとしてマークされます。

具体化されたビューに対して、シノニムは作成されません。
ユーザー定義型 SSMA では、ユーザー定義型の変換はサポートされていません。 PL/SQL プログラムでの使用を含め、ユーザー定義型は、以下の規則に従って、特殊な変換エラーとしてマークされます。:

ユーザー定義型のテーブル列は、VARCHAR (8000) に変換されます。

ストアド プロシージャまたは関数に対するユーザー定義型の引数は、VARCHAR (8000) に変換されます。
PL/SQL ブロック内のユーザー定義型の変数は、VARCHAR (8000) に変換されます。

オブジェクト テーブルは、標準テーブルに変換されます。
オブジェクト ビューは、標準ビューに変換されます。

詳細については、「Oracle スキーマの変換 (OracleToSQL)」を参照してください。

Oracle オブジェクトの変換とデータの移行

SSMA のインストールが完了したら、Oracle スキーマを変換するためのレポートを作成し、データを Azure SQL Managed Instance に移行します。 ステップバイステップ ガイドについては、「SQL Server Migration Assistant を使用して Oracle スキーマを Linux 上の SQL Server 2017 に移行する」を参照してください。

移行後のタスク

移行全体が完了したら、クライアント コンポーネントをアンインストールして、ssma_oracle スキーマを削除します。

注意

移行したデータベースによって今後は sysdb データベースの ssma_oracle スキーマ内の関数が使用されない場合以外は、拡張パックを SQL Server からアンインストールしないでください。

詳細については、SSMA for Oracle コンポーネントの削除に関するページを参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

SQL への Oracle データベースの移行を開始するには、「SQL Server Migration Assistant for Oracle (OracleToSQL)」を参照してください。

注意

この移行パスがビジネス ニーズに適していないと思われる場合は、移行のデシジョン ツリーを参照してください。