3 SQL Developer: サード・パーティ・データベースの移行

移行とは、MySQL、またはMicrosoft SQL Server、Sybase Adaptive Server、IBM DB2 (UDB)などのソースとなる(Oracle以外の)サード・パーティ・データベースからOracle Databaseにスキーマ・オブジェクトおよびデータをコピーするプロセスのことです。移行は、大部分が自動化された効率的な方法で実行できます。

したがって、SQL DeveloperでOracle Database以外のデータベースを処理する場合は、次の2つのオプションがあります。

• データベース接続を作成し、それらのデータベースのスキーマ・オブジェクトおよびデータを参照できるようにするオプション

• それらのデータベースをOracleに移行し、Oracle Databaseの特性および機能を最大限に活用できるようにするオプション

この項の内容は次のとおりです。

• 移行: 基本の選択肢とステップ

• 移行: バックグラウンド情報とガイドライン

• 移行に使用するSQL Developerユーザー・インタフェース

• 移行のコマンドライン・インタフェース

3.1 移行: 基本の選択肢とステップ

サード・パーティ・データベースのすべてまたは一部をOracleに移行する場合、次の基本的な選択肢があります。

• 移行ウィザードを使用した移行

• Oracleへの選択した表のコピー

ただし、どの移行アクションを実行する前にも、適切な移行ユーザー・プリファレンス(日付とタイムスタンプのマスク、「引用符付き識別子が有効」など)を設定し、「移行: バックグラウンド情報とガイドライン」の関連トピックを読んで準備してください。

ウィザードを使用するか、または表をOracleにコピーして移行した後に、結果が期待どおりであることを確認します。

ヒント:

標準的な移行のウォーク・スルーは、sqldeveloper\sqldeveloper\binフォルダに移動して、次のコマンドを入力してください。

sdcli migration -help=guide

3.1.1 移行ウィザードを使用した移行

移行ウィザードでは、データベース移行に関係するアクション(ソース・データベースの取得、Oracle形式への変換、変換を実行するDDLの生成など)の便利で総合的なガイダンスが提供されます。移行の実行時にはこの方法を使用することをお薦めします(各フェーズで発生する問題を解決し、要件に合うようにオブジェクトを調査したり変更することができます)。

移行ウィザードは、サード・パーティ・データベース接続を右クリックして「Oracleへの移行」を選択したとき、「ツール」、「移行」、「移行」の順にクリックしたときなど、様々なコンテキストで起動されます。このウィザードは、最初のステップ以外のページで起動される場合もあります。

最後以外のすべてのページで、「サマリー・ページに進む」を有効にすると、「次」を使用して「サマリー」ページに移動できます。

3.1.1.1 リポジトリ

ウィザードの「リポジトリ」ページでは、使用する移行リポジトリのデータベース接続を指定する必要があります。

移行リポジトリは、SQL Developerが移行メタデータの管理に使用するスキーマ・オブジェクトのコレクションです。移行リポジトリおよびそのリポジトリへのデータベース接続がまだない場合は、次のように作成します。

1. MIGRATIONSというOracleユーザーとそのデフォルト表領域USERSおよび一時表領域TEMPを作成し、RESOURCE以上のロールおよびCREATE SESSION、CREATE VIEWおよびCREATE MATERIALIZED VIEW権限を付与します。複数スキーマの移行では、RESOURCEロールをADMINオプション付きで付与する必要があります。また、このユーザーには、CREATE ROLE、CREATE USERおよびALTER ANY TRIGGER権限のすべてをADMINオプション付きで付与する必要があります。

2. MIGRATIONSユーザーに接続するデータベース接続Migration_Repositoryを作成します。

3. Migration_Repository接続を右クリックし、「移行リポジトリ」→「移行リポジトリの関連付け」を選択して、リポジトリを作成します。

移行対象のサード・パーティ・データベースへのデータベース接続がまだない場合は、作成します。(移行では、接続を作成する前にサード・パーティのJDBCドライバ・プリファレンスを設定しておく必要があります。)たとえば、salesというSybaseデータベースに対してSales_Sybaseというデータベース接続を作成します。

接続: 使用する移行リポジトリへのデータベース接続。

切捨て: このオプションを有効にすると、現在の移行用のデータが作成される前にリポジトリがクリアされます(前の移行のデータはすべて削除されます)。

3.1.1.2 プロジェクト

ウィザードの「プロジェクト」ページでは、この移行の移行プロジェクトを指定します。移行プロジェクトとは、移行オブジェクトのコンテナです。

「新規」で新規プロジェクトを作成でき、「既存」で既存のプロジェクトのリストから選択できます。

名前: この移行プロジェクトに関連付けられる名前。

説明: オブジェクトに関するオプションの説明コメント。

出力ディレクトリ: 移行ウィザードで生成されるすべてのスクリプトが配置されるディレクトリまたはフォルダ。パスを入力するか、「選択」をクリックして場所を選択します。

3.1.1.3 ソース・データベース

ウィザードの「ソース・データベース」ページでは、移行対象のサード・パーティ・データベースを指定します。

モード: 「オンライン」の場合は、ウィザードで必要な情報の入力が完了するとSQL Developerによって移行が実行され、「オフライン」の場合は、指定したファイル(オフライン取得ソース・ファイル)を使用してSQL Developerによって移行が実行されます。

接続(オンライン・モード): 移行対象のサード・パーティ・データベースへのデータベース接続。リストに接続を追加するには「追加」(+)アイコンをクリックし、選択した接続を編集するには「編集」(鉛筆)アイコンをクリックします。

使用可能なソース・プラットフォーム(オンライン・モード): 移行可能なサード・パーティ・データベースのリスト。目的のプラットフォームがリストされない場合、適切なJDBCドライバが必要な可能性があり、このドライバを入手するには、「ヘルプ」、「更新のチェック」の順にクリックするか、または「プラットフォームの追加」リンクをクリックして「データベース: サード・パーティJDBCドライバ」プリファレンス・ページで必要なエントリを追加します。

オフライン取得ソース・ファイル: (「オフライン」モード): .ocpファイル。これは、前に「ツール」、「移行」、「データベース取得スクリプトの作成」の順にクリックして作成したファイルです。

ノート:

「接続できません」エラーを受信した場合は、通常は生成されたオフライン取得データに存在する.ocpファイルが存在しないためデータベースのタイプが識別されず、したがって、SQL Developerが移行を行うための適切なプラグインを選択できないということを意味しています。正しい有効な.ocpファイルが使用されていることを確認します。

3.1.1.4 取得

ウィザードの「取得」ページでは、指定したプラットフォームの移行対象のデータベースを指定できます。「使用可能なデータベース」で目的のアイテムを選択し、矢印アイコンを使用して「選択したデータベース」に個別に、またはまとめて移動します。

3.1.1.5 変換

ウィザードの「変換」ページでは、ソース・データベース内の各データ型に関して、移行データベース内のそのソース・データ型の列の変換先のOracle Databaseデータ型を調査し、変更できます。ソース・データ型のエントリごとに、可能なOracleデータ型の値が、有効かつ可能性のあるマッピング(複数の場合も、1つの場合もある)として示されます。

新規ルールの追加: 他のソース・データ型のマッピングを指定できます。

ルールの編集: 選択したソース・データ型のマッピングを変更できます。

拡張オプション: 「移行: 識別子オプション」プリファレンス・ページを表示します。

3.1.1.6 変換

ウィザードの「変換」ページで、変換するSQLオブジェクトを指定します。「使用可能なSQLオブジェクト」で目的のアイテムを選択し、矢印アイコンを使用して「選択したSQLオブジェクト」に個別に、またはまとめて移動します。

3.1.1.7 ターゲット・データベース

ウィザードの「ターゲット・データベース」ページでは、サード・パーティ・データベースの移行先のOracle Databaseを指定します。

モード: 「オンライン」の場合は、ウィザードで必要な情報の入力が完了するとSQL Developerによって移行が実行され、「オフライン」の場合は、ウィザードで必要な情報の入力が完了した後にSQL Developerによってスクリプトが生成され、後でこのスクリプトを実行して移行を実行する必要があります。

接続: サード・パーティ・データベースの移行先のスキーマがあるOracle Databaseユーザーへのデータベース接続。リストに接続を追加するには「追加」(+)アイコンをクリックし、選択した接続を編集するには「編集」(鉛筆)アイコンをクリックします。

生成済スクリプトのディレクトリ: 移行スクリプト・ファイルが生成されるディレクトリまたはフォルダ(プロジェクトの「出力ディレクトリ」に対する前の入力内容に基づいて導出される)。

ターゲット・オブジェクトの削除: このオプションを有効にすると、ターゲット・スキーマ内の既存のデータベース・オブジェクトは、移行の実行前に削除されます(したがって、移行は必ず空のスキーマに対して行われます)。

拡張オプション: 「移行: 生成オプション」プリファレンス・ページを表示します。

3.1.1.8 データの移動

ウィザードの「データの移動」ページでは、移行の一環として表データの移行オプションを指定できます。表データの移動は、表の定義(メタデータ)の移行とは独立しています。表データを移動しない場合は、モードに「オフライン」を指定して、単純にデータの移動にスクリプトが実行されないようにできます。

モード: 「オンライン」の場合は、ウィザードで必要な情報の入力が完了するとSQL Developerによって表データが移動され、「オフライン」の場合は、ウィザードで必要な情報の入力が完了した後にSQL Developerによってスクリプトが生成され、データを移動する場合に後でこのスクリプトを実行する必要があります。(オンラインでの移動は、小規模なデータ・セットの移動に便利で、オフラインでの移動は大規模なデータの移動に便利です。)

オンライン・データ移動に使用する接続: サード・パーティ接続およびOracle接続のそれぞれのソース接続および宛先接続。どちらのリストでも、接続を追加するには「追加」(+)アイコンをクリックし、選択した接続を編集するには「編集」(鉛筆)アイコンをクリックします。

データの切捨て: このオプションを有効にすると、ソース表と同じ名前を持つターゲット(Oracle)表の既存のデータは、データの移動前に削除されます。このオプションが無効の場合は、対応するターゲット(Oracle)表と同じ名前を持つソース表のデータは、ターゲット表の既存データに追加されます。

3.1.1.9 サマリー

ウィザードの「サマリー」ページでは、プロジェクト、リポジトリおよびアクションに対する指定内容のサマリーが、展開可能なツリー形式で表示されます。変更する場合は、関連するウィザード・ページに戻ります。

指定した移行アクションを実行するには、「終了」をクリックします。

3.1.2 Oracleへの選択した表のコピー

サード・パーティ・データベースからOracle Databaseに1つ以上の表をコピーする場合は、サード・パーティ表を選択して「Oracleへのコピー」機能を使用できます。この方法では、移行リポジトリを作成または使用したり、オブジェクトを取得して変換する必要はありません。

この方法では、完全な移行は実行されないことに注意してください。表および表データ(必要に応じて)を、サード・パーティ・データベースからOracle Databaseにコピーできるだけです。主キーや外部キー定義およびほとんどの制約を移行または再作成することはできません。(UNIQUE制約またはデフォルト値はコピーでは保持されません。NOT NULL制約は、ほとんどの場合、維持されます。)この方法では、プロシージャなど、表以外のオブジェクトについても考慮されていません。

また、この方法では、INCREMENT BY値が1の場合および順序が1から開始するかまたはトリガーへの最初のコールでMAX VAL + 1に調整されている場合のみ、列の自動増分をサポートします。

このような制限が許容される場合であれば、この方法はすばやくて便利な方法といえます。たとえば、一部のデータベース所有者は、基本の表定義およびデータのみをOracle Databaseにコピーする必要があり、その後SQL Developerを使用してOracle Databaseにキーおよび制約を追加できます。

選択した表をコピーするには、次のステップを実行します。

1. サード・パーティ・データベースへのデータベース接続を作成してオープンします。(移行では、接続を作成する前にサード・パーティのJDBCドライバ・プリファレンスを設定しておく必要があります。)

2. 「接続」ナビゲータで、サード・パーティ・データベース接続の「表」の表示を展開し、移行する表を選択します。

   複数の表を選択するには、適宜、個別選択および範囲選択の標準的な方法を使用します([Ctrl]キーおよび[Shift]キーを使用します)。

3. 右クリックして「Oracleへのコピー」を選択します。

4. 「Oracleへコピーするデータベースの選択」ダイアログ・ボックスで、適切なエントリを選択します。

   接続先データベース名: Oracle Databaseに選択した表をコピーするために使用するデータベース接続。(選択には、Oracle Database接続のみが表示されます。)

   データを含める: このオプションを有効にすると、Oracle Database内に新規表が作成されてから、この表にサード・パーティ・データベースの表のデータがコピーされます。このオプションが無効の場合、Oracle Databaseに表は作成されますが、データはコピーされません。

   表が存在する場合: コピー元の表と同じ名前の表が宛先Oracle Databaseにすでに存在している場合のアクションとして、「エラーの表示」(エラーが生成され、コピーは実行されない)、「追加」(コピー元の表から宛先Oracle表に行が追加される)、「置換」(宛先Oracle表内のデータがコピー元の表の行に置き換えられる)を指定します。名前が同じ2つの表があり、その列定義が異なる場合、「データを含める」を指定すると、ソース列のデータ型と宛先列のデータ型に互換性があるかどうかによって、データがコピーされるときと、コピーされないときがあります。

5. コピー操作を実行するには、「適用」をクリックします。

コピー元と同じ名前の表が、宛先Oracle Databaseにすでに存在する場合は、次のようになります。

• その2つの表に同じ列定義がない場合、コピーは実行されます。

• 2つの表に同じ列定義があり、「データを含める」が指定されている場合、データは追加されます(つまり、コピー元の表からの行が、既存のOracle表に挿入されます)。

3.2 移行: バックグラウンド情報とガイドライン

次のトピックでは、データベースの移行計画に役立つバックグラウンド情報とガイドラインを示します。

• 移行の概要

• 移行計画の準備

• 移行を始める前に: 一般的な情報

• 移行を始める前に: ソース固有の情報

• ソース・データベースの取得

• 変換モデルの作成およびカスタマイズ

• Oracleスキーマ・オブジェクト用のDDLの生成

• データの移行

• 大/小文字を区別しない問合せの作成

• Oracle Databaseのテスト

• Oracle Databaseのデプロイ

3.2.1 移行の概要

Oracle Databaseでは、サード・パーティ・データベースより高いスケーラビリティ、信頼性、パフォーマンスおよびセキュリティが提供されます。このため、多くの企業が、現行のデータベース(Microsoft SQL Server、Sybase Adaptive Server、IBM DB2など)からOracle Databaseに移行しています。データベースの移行は複雑になる場合がありますが、SQL Developerを使用すると、サード・パーティ・データベースからOracle Databaseに移行するプロセスを簡略化できます。

SQL Developerは、ソース・データベースから情報を取得し、その情報を取得モデルに表示します。取得モデルは、ソース・データベースの構造表現です。この表現は移行リポジトリに格納されます。移行リポジトリは、SQL Developerが移行情報の格納に使用するスキーマ・オブジェクトの集合です。

リポジトリに格納されている情報を使用して、変換モデルが生成されます。変換モデルは、Oracle Databaseで実装される移行先データベースの構造表現です。この後、取得モデルおよび変換モデルの情報を使用して、データベース・オブジェクトの比較、Oracle予約語との競合の確認および移行の進捗状況の管理を行うことができます。移行の準備が整ったら、Oracleスキーマ・オブジェクトを生成して、データを移行します。

SQL Developerには、ソース・データベースのデータ・ディクショナリからデータを抽出し、取得モデルを作成し、取得モデルを変換モデルに変換するためのロジックが含まれています。

サード・パーティ・データベースからOracle Databaseへの移行にSQL Developerを使用すると、次のメリットがあります。

• 移行プロジェクトに伴う労力とリスクが軽減します。

• トリガーやストアド・プロシージャを含むサード・パーティ・データベース全体を移行できます。

• 取得モデルと変換モデルを表示して比較し、それぞれを必要に応じてカスタマイズすることができるため、移行プロセスの自動化の程度を制御できます。

3.2.1.1 SQL Developerの拡張機能としての移行の実装

移行のサポートは、一連の拡張機能としてSQL Developerに実装されます。必要に応じて、移行のサポートまたは個々のサード・パーティ・データベースの移行のサポートを無効にすることができます。

インストールされている拡張機能を表示したり、個々の拡張機能を有効または無効にするには、「ツール」→「プリファレンス」→「拡張機能」をクリックします。SQL Developerにはリリース時に使用可能なすべての拡張機能およびサード・パーティ・データベース用のプラグインが付属しているため、移行を開始する場合はサード・パーティ・ドライバのみをインストールする必要があります。

3.2.2 移行計画の準備

ここでは、移行の計画を作成するプロセスについて説明します。移行計画に含めるタスクを特定し、それぞれのタスクの内容を判断する方法、および移行プロジェクトに伴うリスクを回避する方法について説明します。内容は次のとおりです。

• タスク1: 移行プロジェクトの要件の確認

• タスク2: ワークロードの見積り

• タスク3: 操作要件の分析

• タスク4: アプリケーションの分析

• タスク5: 移行プロジェクトの計画

3.2.2.1 タスク1: 移行プロジェクトの要件の確認

このタスクでは、移行するデータベース、およびそのデータベースにアクセスするアプリケーションを特定します。また、業務要件を評価し、テスト基準を定義します。

移行プロジェクトの要件を確認するには:

1. プロジェクトの範囲を定義します。

   移行プロジェクトの範囲を定義するには、サード・パーティ・データベースおよびそのデータベースにアクセスするアプリケーションに関していくつかの項目を選択する必要があります。移行の問題および依存性のリストを作成する場合は、次のことを考慮します。

   • 移行するサード・パーティ・データベースについて

     • バージョン

     • 文字セット

   • サード・パーティ・データベースをOracle Databaseに移行することによって影響を受けるソース・アプリケーションについて

     • サード・パーティ・アプリケーションの言語

     • 使用しているアプリケーション言語のバージョン

     プロジェクトの範囲で、移行する必要があるアプリケーションを特定しておく必要があります。データベースを移行することによって影響を受けるすべての必要なアプリケーションが含まれていることを確認します。

   • Oracle Databaseへの移行に関連する接続性の問題のタイプについて

     • アプリケーションをサード・パーティ・データベースに接続するために接続ソフトウェアを使用するかどうか。アプリケーションをOracle Databaseに接続するために接続ソフトウェアを変更する必要があるかどうか。

     • 使用する接続ソフトウェアのバージョンは何か。Oracle Databaseに接続するためにこの同じバージョンを使用できるかどうか。

   • Oracle Databaseで動作するように、アプリケーションを再作成または変更するかどうかについて

2. ソース・データベース環境が複雑か、単純かを判断します。個々の移行計画に基づいて要件を確認します。

   複雑な計画には、次の2つ以上が含まれています。

   • 大規模データベース(25GBを超える)

   • データ・ウェアハウス

   • 大規模アプリケーション(100以上のフォーム、レポートおよびバッチ・ジョブ)

   • 複数のビジネス系列で使用されるデータベース

   • 分散デプロイメント

   • 大規模ユーザー・ベース(100を超える)

   • 高可用性要件(24時間365日体制の環境など)

   単純な計画には、次が含まれています。

   • 小規模データベース(25GB未満)

   • 単純なオンライン・トランザクション処理(OLTP)

   • 小規模アプリケーション(フォーム、レポートおよびバッチ・ジョブが100未満)

   • 1部門で使用されるデータベース

   • 集中デプロイメント

   • 小規模ユーザー・ベース(100未満)

   • 平均的な可用性(営業時間)

   移行プロジェクトが単純な計画の場合は、考えられるすべての移行タスクを実行する必要はありません。ユーザーの使用環境に基づいて決定してください。たとえば、複雑な計画の場合は、データベースにアクセスしているアプリケーションの複雑さに基づいて追加のテストが必要になる場合があります。

3. 移行先データベースにハードウェアの追加およびバックアップ・スケジュールの再作成が必要かどうかを判断します。
4. テストおよび評価基準を定義します。

   移行の精度が測定されるようにテストを定義します。その後、評価基準によって、移行が正常に実行されたかどうかを確認します。要件に基づいて作成されたテストでは、安定性の測定、パフォーマンスの評価およびアプリケーションのテストも行われます。Oracle Databaseおよびアプリケーションを本番環境にデプロイする前に必要なテストの範囲を判断する必要があります。

5. 移行プロジェクトの要件が記載されたドキュメントを作成します。

   要件ドキュメントでは、タスクを明確に定義し、個々の要件に番号を付け、必要に応じてそれらの要件を詳細な要件に分割します。

3.2.2.2 タスク2: ワークロードの見積り

このタスクでは、SQL Developerを使用して、自動化が可能な作業および手動で行う作業の量を計算して決定します。

ワークロードを見積もるには:

1. 取得モデルの取得、変換モデルの作成、および移行先データベースへの移行を行います。

   取得モデルを使用してソース・データベースを分析し、変換モデルを使用して移行先データベースのプレビューを分析することができます。ソース・データベースを取得した後で、取得モデルおよび変換モデルに含まれている取得データを分析します。移行リポジトリの内容と構造が正しいことを確認し、プロセス全体にかかる時間を判断します。

2. 「移行ログ」ペインを使用して、取得プロセスおよび移行プロセスの評価、データベース・オブジェクトの合計数の分類、および自動的に変換かつ移行可能なオブジェクトの数の確認を行います。

   移行ログには、実行されたアクションに関する情報が提供され、警告およびエラーが記録されます。警告およびエラーによって、変換モデルに対して行われた変更が特定されるため、移行先データベースにアクセスするアプリケーションに対して変更を行う必要があるかどうかを評価できます。

3. 発生した問題を評価および分類します。移行ログには、次のものについての有効な情報が提供されます。

   • ソース・データベースの取得時にロードされなかった表

   • 変換モデルの作成時に解析されなかったストアド・プロシージャ、ビューおよびトリガー

   • 手動操作が必要な構文

   • 移行先データベースへの移行時に正常に作成されなかったデータベース・オブジェクト

   • 移行先データベースへの移行時に正常に移行されなかったデータ

4. 移行ログ内の各エラーまたは警告に対して、次の項目を評価します。

   • 問題が発生した回数

   • 問題の修正に必要な時間(人時)

   • 問題の修正に必要なリソースの数

     複雑な問題を解決した後、次に同様の問題が発生した場合は、より簡単かつ迅速にその問題を解決できるようになります。

3.2.2.3 タスク3: 操作要件の分析

このタスクでは、次の手順を実行して操作要件を分析します。

1. ソース・データベースを移行先データベースに移行する場合の操作上の考慮点について検討します。具体的には、次の点を検討してください。

   ノート:

   移行プロジェクトの範囲が複雑な計画の場合は、これらすべての項目を確認することをお薦めします。単純な計画の場合は、該当する項目のみを確認します。

   • 必要なバックアップおよびリカバリの変更

   • 移行時に必要な停止時間

   • パフォーマンス要件に適合しているかどうか

   • 操作時間枠を変更するかどうか

   • 停止時間が業務に与える影響

   • トレーニング要件、または従業員に関する追加の考慮点

   • サード・パーティ・データベースとOracle Databaseを同時に実行する必要があるかどうか

2. 各タスクについて、実行に必要なリソースおよび時間を判断します。
3. 最初のプロジェクト計画を作成します。

   要件の確認および計画の段階で収集した情報を使用して、最初のプロジェクト計画を作成します。

3.2.2.4 タスク4: アプリケーションの分析

このタスクでは、ソース・データベースで実行されているアプリケーションのユーザー、ソース・データベースに必要なハードウェア、アプリケーションの機能、およびソース・データベースに対するアプリケーションのインタフェースを確認します。また、データベースに接続して必要な変更を特定するためにアプリケーションで使用される方法も分析します。

ノート:

移行プロジェクトが複雑な計画の場合は、示すすべての項目を検討することをお薦めします。単純な計画の場合は、関連するほとんどの項目を検討してください。

アプリケーションを分析するには:

1. アプリケーションを移行先データベースで効果的に実行するためにアプリケーションに変更を行う必要があるかどうかを判断します。

2. アプリケーションへの変更が必要な場合は、アプリケーションの再作成または変更のいずれがより効果的かを判断します。

   Oracle Databaseを使用するためにアプリケーションを再作成する場合は、次のことを考慮します。

   1. アプリケーションの再作成に必要なプロジェクト・ドキュメントを作成します。たとえば、設計仕様および要件ドキュメントが必要です。

   2. 仕様に従ってアプリケーションを再作成します。

   3. アプリケーションがOracle Databaseに対して動作することをテストします。

   Oracle Databaseを使用するためにアプリケーションを変更する場合は、次のことを考慮します。

   1. アプリケーションに存在するデータベースへの接続数を確認し、Oracle Databaseが使用されるようにこれらの接続を変更します。

      ODBC接続またはJDBC接続を使用するために、接続情報の変更が必要な場合があります。

   2. Oracle Databaseに対してアプリケーションのテストを行う前に、アプリケーションで変更が必要な埋込みSQL文を特定します。

   3. Oracle Databaseを使用してアプリケーションをテストします。

3. アプリケーションの再作成または変更に関連する各問題に対処するための時間およびリソースを割り当てます。

4. タスク1で作成した、このプロジェクトについての一般的な要件ドキュメントを更新します。

3.2.2.5 タスク5: 移行プロジェクトの計画

このタスクでは、移行プロジェクトに含まれている可能性がある不確定要素(ソース・データベースと移行先データベースでのテクノロジの違いなど)を分析します。計画段階では、次のことを行います。

• プロジェクトの予算制約を見積もります。

• 移行計画を作成するための情報を収集します。

• 移行プロジェクトにかかる時間を見積もります。

• 移行を完了し、テストするために必要なリソースの量を計算します。

移行プロジェクトを計画するには:

1. タスク1の移行プロジェクト要件を完全に満たすために必要なタスクのリストを定義します。
2. 移行プロジェクトを完了するために必要なタスクのリストを分類します。

   これらのタスクを業務別にグループ化する必要があります。これによって、リソースのスケジュールおよび割当てをより正確に行うことができます。

3. タスク3および4で収集した情報に基づいて移行プロジェクトの計画を更新し、最終版を確定します。
4. 移行プロジェクトの計画が移行プロジェクトの要件を満たしていることを確認します。

   移行計画には、プロジェクトの説明、割り当てられたリソース、トレーニング要件、移行結果、全体要件、環境分析、リスク分析、アプリケーションの評価、および移行スケジュールを含める必要があります。

3.2.3 移行を始める前に: 一般的な情報

サード・パーティ・データベースからOracle Databaseへの移行を開始する前に、特定のタスクの実行が必要になる場合があります。詳細は、次を参照してください:

• 移行リポジトリのデータベース・ユーザーの作成

• 移行先のOracleオブジェクトを作成するための要件

移行しようとしているソース・データベースに固有の要件の詳細は、「移行を始める前に: ソース固有の情報」を参照してください。

ノート:

SQL Developerでは、権限付与情報がソース・データベースから移行されません。移行後、Oracle DBAはユーザー、ログインおよび権限付与に関する指定内容を(適切に)調整する必要があります。

ノート:

移行を開始する前に、ソース・データベースの完全バックアップを行うことをお薦めします。ソース・データベースのバックアップの詳細は、そのデータベースのタイプ固有のドキュメントを参照してください。

可能であれば、本番データベースではなく、開発環境またはテスト環境を使用して移行を開始してください。

3.2.3.1 移行リポジトリのデータベース・ユーザーの作成

サード・パーティ・データベースをOracle Databaseに移行するには、SQL Developerに移行リポジトリが必要です。移行リポジトリにOracle Databaseを使用するには、データベース・ユーザー・アカウントを使用してそのデータベースにアクセスできる必要があります。移行には専用のユーザー・アカウントを使用することをお薦めします。たとえば、MIGRATIONSというユーザーを作成し、このユーザーに対するデータベース接続を作成して、その接続を移行リポジトリに使用します。必要に応じて、後でMIGRATIONSユーザーを削除して、データベースから移行のすべての形跡を削除できます。

移行用のユーザーを作成する場合は、表領域のデフォルトを使用するのではなく、次の例に示すように表領域の情報を指定します。

CREATE USER migrations IDENTIFIED BY <password>
  DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp,

移行には、標準アカウント(SYSTEMなど)は使用しないでください。

SQL Developerは、移行リポジトリの作成時に、SQL Developerでの使用のみを目的とした多くのスキーマ・オブジェクトを作成します。たとえば、表、ビュー、索引、パッケージおよびトリガーを作成します。これらの多くの名前はMD_およびMIGRで始まります。これらのオブジェクト、またはこれらのオブジェクトに格納されているデータは直接変更しないでください。

3.2.3.2 移行先のOracleオブジェクトを作成するための要件

移行の実行(生成されたDDL文が含まれているスクリプトの実行)に使用されるOracle Database接続に関連付けられているユーザーには、次のロールおよび権限が必要です。

ノート:

これらの権限は、ユーザー・アカウントに直接付与する必要があります。ロールに権限を付与した後で、そのロールをユーザー・アカウントに付与するのみでは不十分です。ユーザーSYSは、データベースを移行できません。

ロール

CONNECT WITH ADMIN OPTION
RESOURCE WITH ADMIN OPTION

権限

ALTER ANY ROLE
ALTER ANY SEQUENCE
ALTER ANY TABLE
ALTER TABLESPACE
ALTER ANY TRIGGER
COMMENT ANY TABLE
CREATE ANY SEQUENCE
CREATE ANY TABLE
CREATE ANY TRIGGER
CREATE VIEW WITH ADMIN OPTION
CREATE MATERIALIZED VIEW WITH ADMIN OPTION
CREATE PUBLIC SYNONYM WITH ADMIN OPTION
CREATE ROLE
CREATE USER
DROP ANY SEQUENCE
DROP ANY TABLE
DROP ANY TRIGGER
DROP USER
DROP ANY ROLE
GRANT ANY ROLE
INSERT ANY TABLE
SELECT ANY TABLE
UPDATE ANY TABLE

たとえば、次のコマンドを使用すると、データベースの移行に最小限必要な権限を持つmigrationsというユーザーを作成できます。

CREATE USER migrations IDENTIFIED BY password
  DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp;
 
GRANT CONNECT, RESOURCE, CREATE VIEW, CREATE MATERIALIZED VIEW,
   CREATE PUBLIC SYNONYM TO migrations WITH ADMIN OPTION;
 
GRANT  ALTER ANY ROLE, ALTER ANY SEQUENCE, ALTER ANY TABLE, ALTER TABLESPACE,
ALTER ANY TRIGGER, COMMENT ANY TABLE, CREATE ANY SEQUENCE, CREATE ANY TABLE,
CREATE ANY TRIGGER, CREATE ROLE, CREATE TABLESPACE, CREATE USER, DROP ANY
SEQUENCE, DROP ANY TABLE, DROP ANY TRIGGER, DROP TABLESPACE, DROP USER, DROP ANY
ROLE, GRANT ANY ROLE, INSERT ANY TABLE, SELECT ANY TABLE, UPDATE ANY TABLE TO 
migrations;

変換モデルを作成し、新しいデータベース対して実行される最初のDDLを実行すると、現在の状況で必要となる権限がスクリプトから明らかになります。

3.2.4 移行を始める前に: ソース固有の情報

Oracle Databaseに移行するサード・パーティ・データベースによっては、接続情報を構成し、ドライバをインストールする必要がある場合があります。サード・パーティ・データベースに固有の要件の詳細は、次の項を参照してください。

• IBM DB2からの移行の前に

• Microsoft SQL ServerまたはSybase Adaptive Serverからの移行の前に

• MySQLからの移行の前に

• Teradataからの移行の前に

3.2.4.1 IBM DB2からの移行の前に

IBM DB2データベースを移行用に構成するには:

1. ソース接続用にSQL Developerで使用されるIBM DB2データベース・ユーザーがソース・データベースにアクセス可能であることを確認します。このユーザーは、IBM DB2データベースで取得するオブジェクトを参照できる必要があり、参照できないオブジェクトは取得できません。たとえば、ユーザーがあるストアド・プロシージャを実行できても、そのソース・コードを参照するのに十分な権限を持っていない場合には、そのストアド・プロシージャは取得できません。

2. SQL DeveloperがインストールされているシステムからIBM DB2データベースに接続できることを確認します。

3. IBMからdb2jcc.jarファイルとdb2jcc_license_cu.jarファイルをダウンロードしてあることを確認します。

4. SQL Developerで、次の手順を実行します。

   1. 「ツール」→「プリファレンス」→「データベース」→「サード・パーティJDBCドライバ」をクリックします。

   2. 「エントリの追加」をクリックします。

   3. db2jcc.jarファイルを選択します。

   4. 「OK」をクリックします。

   5. db2jcc_license_cu.jarファイルに対してステップbからdを繰り返します。

3.2.4.2 Microsoft SQL ServerまたはSybase Adaptive Serverからの移行の前に

Microsoft SQL ServerデータベースまたはSybase Adaptive Serverデータベースを移行用に構成するには:

1. ソース接続用にSQL Developerで使用されるMicrosoft SQL ServerユーザーまたはSybase Adaptive Serverユーザーがソース・データベースにアクセス可能であることを確認します。このユーザーは、Microsoft SQL ServerデータベースまたはSybase Adaptive Serverデータベースで取得するオブジェクトを参照できる必要があります。ユーザーが参照できないオブジェクトは取得できません。たとえば、ユーザーがあるストアド・プロシージャを実行できても、そのソース・コードを参照するのに十分な権限を持っていない場合には、そのストアド・プロシージャは取得できません。

2. SQL DeveloperがインストールされているシステムからMicrosoft SQL ServerデータベースまたはSybase Adaptive Serverデータベースに接続できることを確認します。

3. http://sourceforge.net/projects/jtds/からJTDS JDBCドライバをダウンロードしてあることを確認します。

4. SQL Developerでは、「更新を自動的にチェックする」を使用してJTDSドライバがまだインストールされていない場合、次の処理を実行します。

   1. 「ツール」→「プリファレンス」→「データベース」→「サード・パーティJDBCドライバ」をクリックします。

   2. 「エントリの追加」をクリックします。

   3. http://sourceforge.net/projects/jtds/からダウンロードしたJTDSドライバのjarファイルを選択します。

   4. 「OK」をクリックします。

5. SQL Developerでは、「ツール」、「プリファレンス」、「移行: 識別子オプション」の順にクリックして、「次で引用された識別子です」オプションに対する設定が適切である(つまり、移行するデータベースが設定に反映されている)ことを確認します。

   このオプションを有効にした場合、引用符(二重引用符)を使用して識別子を示すことができます。このオプションを有効にしない場合、引用符は文字列のリテラルを示します。動作の違いの例として、次のT-SQLコードについて考えます。

   select col1, "col 2" "column_alias"
   from tablex "table_alias"
   

   「次で引用された識別子です」オプションを有効にすると、次のPL/SQLコードが生成されます。

   SELECT col1, col_2 "column_alias"
     FROM tablex "table_alias";
   

   「次で引用された識別子です」オプションを無効にすると、次のPL/SQLコードが生成されます。

   SELECT col1, 'col 2' "column_alias"
     FROM tablex "table_alias";

3.2.4.3 MySQLからの移行の前に

移行用にMySQLデータベースを構成するには、SQL DeveloperがインストールされているシステムにMySQLConnector/Jリリース3.1.12または5.0.4をインストールし、適切なSQL Developerプリファレンスを設定します。次のステップを実行します。

1. SQL DeveloperがインストールされているシステムからMySQLデータベースに接続できることを確認します。

2. http://www.mysql.com/のMySQLのWebサイトから、MySQLConnector/J APIがダウンロードされていることを確認します。

3. SQL Developerでは、「更新を自動的にチェックする」を使用してMySQL JDBCドライバがまだインストールされていない場合、次の処理を実行します。

   1. 「ツール」→「プリファレンス」→「データベース」→「サード・パーティJDBCドライバ」をクリックします。

   2. 「エントリの追加」をクリックします。

   3. http://www.mysql.com/からダウンロードしたMySQLドライバのjarファイルを選択します。

   4. 「OK」をクリックします。

4. ソース接続用にSQL Developerで使用されるMySQLユーザーがソース・データベースにアクセス可能であることを確認します。このユーザーは、MySQLデータベースで取得するオブジェクトを参照できる必要があります。ユーザーが参照できないオブジェクトは取得できません。たとえば、ユーザーがあるストアド・プロシージャを実行できても、そのソース・コードを参照するのに十分な権限を持っていない場合には、そのストアド・プロシージャは取得できません。

3.2.4.4 Teradataからの移行の前に

現在のリリースのSQL Developerでは、プロシージャ、ファンクション、トリガー、ビュー、マクロ、BTEQスクリプトなどのTeradataオブジェクトはOracleに移行されないことに注意してください。

Teradataデータベースを移行用に構成するには:

1. ソース接続用にSQL Developerで使用されるTeradataデータベース・ユーザーがソース・データベースにアクセス可能であることを確認します。このユーザーは、Teradataデータベースで取得するオブジェクトを参照できる必要があり、参照できないオブジェクトは取得できません。

2. SQL DeveloperがインストールされているシステムからTeradataデータベースに接続できることを確認します。

3. Teradataからtdgssconfig.jarファイルとterajdbc4.jarファイルをダウンロードしてあることを確認します。

4. SQL Developerで、次の手順を実行します。

   1. 「ツール」→「プリファレンス」→「データベース」→「サード・パーティJDBCドライバ」をクリックします。

   2. 「エントリの追加」をクリックします。

   3. tdgssconfig.jarファイルを選択します。

   4. 「OK」をクリックします。

   5. terajdbc4.jarファイルに対してステップbからdを繰り返します。

3.2.5 ソース・データベースの取得

サード・パーティ・データベースを移行する前に、データベースから情報を抽出する必要があります。この情報は、ソース・データベースの構造表現であり、取得モデルと呼ばれます。データベースから情報を抽出するプロセスは、ソース・データベースの取得と呼ばれます。

この取得は、オンラインまたはオフラインのいずれでも実行できます。

• オンライン取得は、移行ウィザードを使用した移行プロセスで、便利なガイド付き順序内で実行されます。

• オフライン取得には、後で実行するスクリプトを作成することが関与します。オフライン取得は、IBM DB2、MySQL、Microsoft SQL ServerデータベースおよびSybase Adaptive Serverで使用できます。

ソース・データベースの取得後、SQL Developerの取得モデルにソース・データベース情報を表示できます。必要に応じて、取得モデルを変更し、データ型マッピングを変更できます。

ノート:

経験豊富なOracle Database管理者以外は、デフォルトのデータ型マッピングを変更しないことをお薦めします。

3.2.5.1 オフライン取得

IBM DB2、MySQL、Microsoft SQL ServerまたはSybase Adaptive Serverデータベースのオフライン取得を実行するには、一連のオフライン取得スクリプトを作成し、これらのスクリプトをSQL Developer以外の場所で実行してスクリプトの出力(サード・パーティ・メタデータ表のダンプ)を作成します。次に、SQL Developerを使用してスクリプトの出力(変換モデルが含まれている.ocpファイル)をロードします。

• スクリプト・ファイル(Windowsでは.batファイル、LinuxまたはUNIXでは.shファイル)および関連ファイルを作成するには、「ツール」、「移行」、「データベース取得スクリプトの作成」の順にクリックします。

  この操作が完了すると、いくつかのファイル(.bat、.sql、.ocp)が作成されたことが通知されます。これらのファイルの1つが制御スクリプトです。制御スクリプトを(SQL Developer以外の場所で)実行し、変換モデルに関する情報をオブジェクト取得プロパティ(.ocp)・ファイルに移入する必要があります。

• オフライン取得の制御スクリプトによって生成されたオブジェクト取得プロパティ(.ocp)・ファイルから変換モデルをロードするには、「ツール」、「移行」、「サード・パーティ・データベース・オフライン取得」、「データベース取得スクリプト出力のロード」の順にクリックします。

3.2.5.1.1 IBM DB2オフライン取得のノート

スクリプト・ファイルとdb2_x.ocpファイルがターゲット表に生成されます。主となるスクリプトは、スキーマ・ダンプを生成するために実行が必要なstartDump.xxxです。これらのスクリプト・ファイルでは、データベース名、ユーザー名およびパスワードの入力を求められ、ローカルのDB2データベースに接続するためにこれらの情報が使用されます。これらのスクリプトでは、オブジェクト固有のフォルダ内にデータベース・オブジェクト用のスキーマ・ダンプが生成されます。

オフライン・ファイル形式でスキーマ情報を取得するには、(実行パスにdb2実行可能ファイルを指定して)次の形式でコマンドを使用します。

db2 -x +o -r <file name> <schema query>

オフライン・ファイル形式でスキーマ・データをエクスポートするには、(実行パスにdb2実行可能ファイルを指定して)次の形式でコマンドを使用します。

• DB2バージョン9のデータのエクスポートの場合:

  db2 export to <file name> of DEL modified by lobsinsepfiles coldel"#" timestampformat=\"YYYY/MM/DD HH.mm.ss\" datesiso nochardel <select query>
  

• DB2バージョン8のデータのエクスポートの場合:

  db2 export to <file name> of DEL modified by coldel"#" timestampformat=\"YYYY/MM/DD HH.mm.ss\" datesiso nochardel <select query>
  

DB2バージョン9は、複数の分かれたファイルでLOBデータをサポートするため、大きいデータ・サイズの移行により適しています。バージョン8で大きいLOBデータをサポートするには、unload_script.batまたはunload_script.shでoracle ctlファイル・コマンドとdb2コマンドを変更する必要があります。

表データは、<catalog>.<schema>.<table>.datという形式の名前のファイルにエクスポートされます。ファイルの形式は、data1#<COL_DEL> #data2#<COL_DEL>…<ROW_DEL>(COL_DELとROW_DELは移行オフライン・プリファレンスの設定からのもの)です。

DB2データ・ダンプ・スクリプトを実行する前に、次の形式でコマンドを入力してログインする必要があります。

db2 connect to <catalog> user <user name> using <password>

その後、ログインした接続セッションを使用してスクリプトを実行できます。

3.2.6 変換モデルの作成およびカスタマイズ

サード・パーティ・データベースを取得したら、次はこれを変換して、変換モデルを作成します。変換モデルは、移行先データベースの構造表現です。SQL Developerは、取得モデルの情報を使用して変換モデルを作成します。

デフォルトでは、変換中にすべてのプロシージャ、ファンクション、トリガーおよびビューが変換モデルにコピーされ、Oracle PL/SQLに変換されます。ただし、変換に失敗したオブジェクトは、変換モデルには表示されますが、その元のSQLコードは変更されないままになります。元のSQLコードのままであるオブジェクトは、生成スクリプトの作成時に使用されません。したがって、このようなオブジェクトを移行するには、スクリプトの生成前に元のSQLコードの問題を修正するか、または生成後のスクリプトを編集して元のSQLコードを有効なPL/SQLコードに置換する必要があります。

取得モデルを変換モデルに変換する操作は、移行ウィザードを使用した移行の一環として実行されます。データ・マッピングのデフォルトを指定したり、受け入れることができます。

3.2.6.1 変換モデルのエラーの修正

移行ログにParse Exceptionという接頭辞の付いたエラー・メッセージが表示された場合、問題を解決するには手動操作が必要になります。変換モデルを完全なものにするには:

1. 失敗した変換モデルのスキーマ・オブジェクトを書き留めます。
2. 変換モデルのそのスキーマ・オブジェクトを選択します。
3. スキーマ・オブジェクトのDDLをコピーして、変換スクラッチ・エディタに貼り付けます。スクラッチ・エディタは、「移行」→「翻訳検索エディタ」をクリックすると表示できます。
4. 変換スクラッチ・エディタのスキーマ・オブジェクトのプロパティで、考えられるエラーの原因を調べます。
5. 変換スクラッチ・エディタのスキーマ・オブジェクトのプロパティを変更します。

   たとえば、ストアド・プロシージャの1行をコメント・アウトします。

6. 適切なトランスレータを使用して変換します。
7. 再度エラーが表示された場合は、ステップ2から6を繰り返します。
8. この方法でエラーが解決しない場合は、変換モデルのオブジェクトを手動で変更することをお薦めします。

3.2.7 Oracleスキーマ・オブジェクト用のDDLの生成

Oracleスキーマ・オブジェクトを作成するDDL文を生成するには、事前に取得モデルを取得し、変換モデルを作成しておく必要があります。DDLを生成した後、DDL文を実行して、Oracle Databaseにオブジェクトを作成できます。この時点で、データベース・スキーマがOracleに移行されます。

DDL文を生成および実行してスキーマ・オブジェクトを移行した後、元のソース・データベースからデータを移行できます。

3.2.8 データの移行

移行ウィザードでは、既存のデータをソース・データベースからOracle Databaseに移行(移動)するかどうかを選択できます。データの移行を選択する場合、次のようになります。

• 移行をオンライン・モードで実行する場合は、データ移行をオンラインまたはオフライン・モードで実行できます。(ただし、PostgreSQL移行では、「Oracleへのコピー」機能のみがサポートされています。)

• 移行をオフライン・モードで実行する場合は、データの移行は生成されるファイルに含められます。

オンライン・データ移動は小規模なデータ・セットに適しており、オフライン・データ移動は大規模データの移動に役立ちます。

3.2.8.1 オフラインでのデータの送信

データをオフラインで送信するには、データをソース・データベースから移行先データベースにコピーするスクリプトを生成して使用します。このプロセスでは、次の操作を行う必要があります。

• SQL Developerを使用して、ソース・データベース用のデータ・アンロード・スクリプト、および移行先データベース用の対応するデータ・ロード・スクリプトを生成します。

• ソース・データベースに適した手順で、データ・アンロード・スクリプトを実行してソース・データベースからデータファイルを作成します。

  • Microsoft SQL ServerまたはSybase Adaptive Serverからのデータファイルの作成

  • MySQLからのデータファイルの作成

  • Teradataの場合、BTEQとSQL*Loaderを使用してオフライン・データの移動を実行します。

• SQL*Loaderを使用してデータ・ロード・スクリプトを実行し、これらのデータファイルから移行先データベースにデータを移入します。

3.2.8.1.1 Microsoft SQL ServerまたはSybase Adaptive Serverからのデータファイルの作成

Microsoft SQL ServerデータベースまたはSybase Adaptive Serverデータベースからデータファイルを作成するには:

1. ソース・データベースがインストールされているコンピュータに、SQL Developerによってデータ・アンロード・スクリプトが生成されたディレクトリの内容をコピーします。
2. ソース・データベース・サーバーの名前が含まれるようにBCP抽出スクリプトを編集します。

   • Windowsの場合は、MicrosoftSqlServer_data.batまたはSybase_data.batスクリプトを編集して、適切な変数が含まれるようにbcp行を変更します。

   MicrosoftSqlServer_data.batスクリプトの例の1行を次に示します。

   bcp "AdventureWorks.dbo.AWBuildVersion" out "[AdventureWorks].[dbo].[AWBuildVersion].dat" -q -c -t "<EOFD>" -r "<EORD>" -U<Username> -P<Password> -S<ServerName>
   

3. BCP抽出スクリプトを実行します。

   • Windowsの場合は、次のうちいずれか適切なコマンドを入力します。

     prompt> MicrosoftSqlServer_data.bat
     prompt> Sybase_data.bat
     

   このスクリプトによって、現行のディレクトリにデータファイルが作成されます。

4. 必要に応じて、データファイルおよびスクリプトをターゲットのOracle Databaseシステムにコピーします。または、ターゲットのOracle Databaseにアクセスすることができ、SQL*Loader(Oracle Client)がインストールされたシステムにコピーします。

3.2.8.1.2 MySQLからのデータファイルの作成

MySQLデータベースからデータファイルを作成するには:

1. 必要に応じて、SQL Developerによってデータ・アンロード・スクリプトが生成されたディレクトリの内容を、ソース・データベースがインストールされているシステム、またはソース・データベースにアクセスすることができ、mysqldumpツールがインストールされているシステムにコピーします。
2. データファイルの正しいホスト、ユーザー名、パスワードおよび移行先ディレクトリが含まれるようにunload_scriptスクリプトを編集します。

   • Windowsの場合、MySQL_data.batスクリプトを編集します。

   • LinuxまたはUNIXの場合、MySQL_data.shスクリプトを編集します。

   MySQL_data.batスクリプトの例の1行を次に示します。

   mysqldump -h localhost -u <USERNAME> -p<PASSWORD>  -T <DESTINATION_PATH> 
   --fields-terminated-by="<EOFD>" --fields-escaped-by="" 
   --lines-terminated-by="<EORD>" "CarrierDb" "CarrierPlanTb"
   

   USERNAME、PASSWORDおよびDESTINATION PATHに適切な値が含まれるようにこの行を編集します。このファイルの編集時に、山カッコは使用しないでください。

   このコマンドラインのlocalhostはループバック接続を示しています。これは、-Tオプションで必要になります。(詳細は、mysqldumpのマニュアルを参照してください。)

3. スクリプトを実行します。

   • Windowsの場合は、次のとおり入力します。

     prompt> MySQL_data.bat
     

   • LinuxまたはUNIXの場合は、次のとおり入力します。

     prompt> chmod 755 MySQL_data.sh
     prompt> sh ./MySQL_data.sh
     

   このスクリプトによって、現行のディレクトリにデータファイルが作成されます。

4. 必要に応じて、データファイルおよびスクリプトをターゲットのOracle Databaseシステムにコピーします。または、ターゲットのOracle Databaseにアクセスすることができ、SQL*Loader(Oracle Client)がインストールされたシステムにコピーします。

3.2.8.1.3 データファイルを使用した移行先データベースへの移入

データファイルを使用して移行先データベースへの移入を行うには、SQL*Loaderでデータ・ロード・スクリプトを実行します。

1. データ・アンロード・スクリプトを作成したディレクトリに移動します。
2. oracle_ctl.bat(Windowsシステム)またはoractl_ctl.sh(LinuxまたはUNIXシステム)を編集して、適切なユーザー名およびパスワード文字列を指定します。
3. SQLロード・スクリプトを実行します。

   • Windowsの場合は、次のとおり入力します。

     prompt> oracle_ctl.bat
     

   • LinuxまたはUNIXの場合は、次のとおり入力します。

     prompt> ./oracle_ctl.sh
     

Microsoft SQL ServerおよびSybaseの移行の場合、SQL*Loaderを使用してBLOBフィールドへの挿入を行うと、次のエラーが表示されます。

SQL*Loader-309: No SQL string allowed as part of LARGEOBJECT field specification

このエラーによって示された状況は、次のいずれかのオプションを使用して処理することができます。

• 「移行BLOBオフラインのストアド・プロシージャの生成」SQL Developerプリファレンスを有効にする(「移行: 生成オプション」を参照)。

• 次の解決策を使用する。

解決策

解決策としては、データ(16進フォーマット)を追加のCLOBフィールドにロードしてから、PL/SQLプロシージャを介してCLOBをBLOBに変換する方法があります。

Microsoft SQL ServerまたはSybase Adaptive ServerのBCPを介してバイナリ・データを適切にエクスポートする方法は、データを16進フォーマットでエクスポートする方法のみです。ただし、その16進値をOracleに含めるには、(テキストを保持する)CLOB列に保存してからバイナリ値に変換し、BLOB列に挿入します。ここでの問題は、OracleのHEXTORAWファンクションで変換される16進ペアの数は最大で2000のみであるということです。このため、16進データをバイナリに(1つずつ)変換するユーザー独自のプロシージャを作成します。(次のステップおよび例では、ユーザーの環境に合うようにSTART.SQLおよびFINISH.SQLを変更します。)

次に、この解決策を実装する2つのスクリプト(start.sqlおよびfinish.sql)のコードを示します。コード内のコメントを参照し、必要に応じてユーザーの環境およびニーズに合うようにSQL文を変更します。

ノート:

start.sqlを実行した後、BCPを実行してからfinish.sqlを実行します。BCPを実行する前に、.ctlファイル内の次の関連する行を変更します。

<blob_column> CHAR(2000000) "HEXTORAW (:<blob_column>)"

次のように変更します。

<blob_column>_CLOB CHAR(2000000)

-- START.SQL
-- Modify this for your environment.
 
-- This should be executed in the user schema in Oracle that contains the table.
-- DESCRIPTION:
-- ALTERS THE OFFENDING TABLE SO THAT THE DATA MOVE CAN BE EXECUTED
-- DISABLES TRIGGERS, INDEXES AND SEQUENCES ON THE OFFENDING TABLE
 
-- 1) Add an extra column to hold the hex string;
alter table <tablename> add (<blob_column>_CLOB CLOB);
 
-- 2) Allow the BLOB column to accept NULLS
alter table <tablename> MODIFY <blob_column> NULL;
 
-- 3) Disable triggers and sequences on <tablename>
alter trigger <triggername> disable;
 
alter table <tablename> drop primary key cascade;
 
drop index <indexname>;
 
-- 4) Allow the table to use the tablespace
alter table <tablename> move lob (<blob_column>) store as (tablespace lob_tablespace);
 
alter table <tablename> move lob (<blob_column>_clob) store as (tablespace lob_tablespace);
 
COMMIT;
 
-- END OF FILE
 
 
-- FINISH.SQL
-- Modify this for your enironment.
 
-- This should be executed in the table schema in Oracle.
-- DESCRIPTION:
-- MOVES THE DATA FROM CLOB TO BLOB
-- MODIFIES THE TABLE BACK TO ITS ORIGINAL SPEC (without a clob)
-- THEN ENABLES THE SEQUENCES, TRIGGERS AND INDEXES AGAIN
 
-- Currently we have the hex values saved as 
-- text in the <blob_column>_CLOB column
-- And we have NULL in all rows for the <blob_column> column.
-- We have to get BLOB locators for each row in the BLOB column
 
-- put empty blobs in the blob column
UPDATE <tablename> SET <blob_column>=EMPTY_BLOB();
 
COMMIT;
 
-- create the following procedure in your table schema
CREATE OR REPLACE PROCEDURE CLOBTOBLOB
AS
inputLength NUMBER; -- size of input CLOB
offSet NUMBER := 1;
pieceMaxSize NUMBER := 2000; -- the max size of each peice
piece VARCHAR2(2000); -- these pieces will make up the entire CLOB
currentPlace NUMBER := 1; -- this is where were up to in the CLOB
blobLoc BLOB; -- blob locator in the table
clobLoc CLOB; -- clob locator pointsthis is the value from the dat file
 
-- THIS HAS TO BE CHANGED FOR SPECIFIC CUSTOMER TABLE 
-- AND COLUMN NAMES
CURSOR cur IS SELECT <blob_column>_clob clob_column , <blob_column> blob_column FROM /*table*/<tablename> FOR UPDATE;
 
cur_rec cur%ROWTYPE;
 
BEGIN
 
OPEN cur;
FETCH cur INTO cur_rec;
 
WHILE cur%FOUND
LOOP
--RETRIVE THE clobLoc and blobLoc
clobLoc := cur_rec.clob_column;
blobLoc := cur_rec.blob_column;
 
currentPlace := 1; -- reset evertime
-- find the lenght of the clob
inputLength := DBMS_LOB.getLength(clobLoc);
 
-- loop through each peice
LOOP
-- get the next piece and add it to the clob
piece := DBMS_LOB.subStr(clobLoc,pieceMaxSize,currentPlace);
 
-- append this piece to the BLOB
DBMS_LOB.WRITEAPPEND(blobLoc, LENGTH(piece)/2, HEXTORAW(piece));
 
currentPlace := currentPlace + pieceMaxSize ;
 
EXIT WHEN inputLength < currentplace;
END LOOP;
 
FETCH cur INTO cur_rec;
END LOOP;
 
END CLOBtoBLOB;
/
 
-- now run the procedure
-- It will update the blob column with the correct binary representation
-- of the clob column
EXEC CLOBtoBLOB;
 
-- drop the extra clob cloumn
alter table <tablename> drop column <blob_column>_clob;
 
-- 2) apply the constraint we removed during the data load
alter table <tablename> MODIFY FILEBINARY NOT NULL;
 
-- Now re enable the triggers, indexes and primary keys
alter trigger <triggername> enable;
 
ALTER TABLE <tablename> ADD ( CONSTRAINT <pkname> PRIMARY KEY ( <column>) ) ;
 
CREATE INDEX <index_name> ON <tablename>( <column> );
 
COMMIT;
 
-- END OF FILE

3.2.9 大/小文字を区別しない問合せの作成

いくつかのサード・パーティ・データベースでは、一般的に問合せの大/小文字は区別されません。次のような問合せでは、同じ結果が戻されます。

SELECT * FROM orders WHERE sales_rep = 'Oracle';
SELECT * FROM orders WHERE sales_rep = 'oracle';
SELECT * FROM orders WHERE sales_rep = 'OrAcLe';

Oracle Databaseのあるユーザーに対する問合せを大/小文字が区別されないようにする場合は、AFTER LOGON ON DATABASEトリガーを作成し、そのデータベース・ユーザーに対するNLS_SORTセッション・パラメータに_CI(大/小文字を区別しない)を追加したOracleソート名を設定します。

次の例では、ユーザーSMITHに対する問合せが、Germanソート名を使用し、大/小文字を区別せずに実行されます。

CREATE OR REPLACE TRIGGER set_sort_order AFTER LOGON ON DATABASE
 DECLARE
  username VARCHAR2(30);
 BEGIN
  username:=SYS_CONTEXT('USERENV','SESSION_USER');
  IF username LIKE 'SMITH' then
   execute immediate 'alter session set NLS_COMP=LINGUISTIC';
   execute immediate  'alter session set NLS_SORT=GERMAN_CI';
  END IF;
 END; 

関連項目

• 『Oracle Database 2日で開発者ガイド』で大/小文字とアクセントを区別しないソートに関する項を参照してください。

3.2.10 Oracle Databaseのテスト

テスト・フェーズでは、アプリケーションおよびOracle Databaseをテストして次のことを確認します。

• 移行したデータが完全かつ正確であるかどうか

• アプリケーションの機能がソース・データベースと同じかどうか

• Oracle Databaseがソース・データベースと同じ結果を生成するかどうか

• アプリケーションおよびOracle Databaseが操作要件およびパフォーマンス要件を満たしているかどうか

Oracle Databaseのテストに、元のアプリケーションで行われた一連のユニット・テストおよびシステム・テストを使用できる場合があります。これらのテストは、ソース・データベースに対するテストと同じ方法で実行する必要があります。ただし、追加機能に関係なく、アプリケーションがOracle Databaseに接続され、そのアプリケーションから発行されたSQLによって正しい結果が生成されることを確認する必要があります。

ノート:

アプリケーションに対して実行するテストは、アプリケーションの用途によって異なります。アプリケーションで変更される各SQL文は、十分にテストすることをお薦めします。また、システムをテストして、アプリケーションがサード・パーティ・データベースの場合と同様に機能することも確認する必要があります。

3.2.10.1 テストの方法論

データベースに対して実行するテストの種類と量は、多くの制約によって決まります。テストには、次の1つまたはすべてを含めることができます。

• 簡単なデータ検証

• 個々のユニット・テストに対応するライフ・サイクル全体のテスト

• システム・テストおよび受入れテスト

ユーザーの組織および環境に適したテスト計画に従う必要があります。その計画には、移行したアプリケーションおよびOracle Databaseをテストするプロセスを定義する必要があります。一般的なテスト方法はVモデルです。Vモデルは、データベースの作成で使用される各機能がテスト・フェーズでミラー化される段階的な方法です。

図3-1に、データベースの移行計画で使用するVモデルの例を示します。

図3-1 データベースの移行で使用するVモデル

図3-1「データベースの移行で使用するVモデル」の説明

移行プロセスで使用するテストには、複数の種類があります。テスト段階では、複数のサイクルのテストを実行してデータベースの質を向上させます。使用するテスト・ケースで、以前のバージョンのOracle Databaseで発生したいずれの問題も再発していないことを確認する必要があります。

たとえば、移行したスキーマをテスト結果に基づいて変更する必要がある場合は、新しいバージョンのOracle Databaseスキーマの作成が必要になることがあります。実際には、テストの開始時にSQL Developerを使用してベースラインとなるOracleスキーマを作成し、テストの進捗に合わせてこのスキーマを編集します。

ノート:

テスト・サイクルで検出された問題は、問題追跡システムで追跡することをお薦めします。テスト用バージョンのデータベースまたはアプリケーションに対して、これらの問題を追跡してください。

3.2.10.2 Oracle Databaseのテスト

テスト・ケースを使用して、Oracle Databaseでのビジネス・ロジックの結果がソース・データベースでの結果と同じであることを検証します。

ノート:

移行が正常に実行されたかどうかを判断できるように達成基準を定義することをお薦めします。

次の手順では、移行したデータベースをテストする1つの方法について説明します。他の方法も使用可能であり、業務要件によっては他の方法のほうが適している場合もあります。

Oracle Databaseをテストするには:

1. 移行したデータベースのテスト用バージョンを作成します。

   データベースの移行スクリプトは、ソースの制御システムに保存することをお薦めします。

2. Oracle Databaseに対するユニット・レベルからシステム・レベルまでのテストに使用する一連のテスト・ケースを計画します。テスト・ケースでは、次のことを実行する必要があります。

   1. 次の項目を確認します。

      • ソース・データベースのすべてのユーザーが正常に移行されたかどうか

      • ユーザーに対する権限付与が適切かどうか

      • 表の構造が正しいかどうか、デフォルトで正常に機能しているかどうか、およびマッピング時または生成時にエラーが発生しなかったかどうか

   2. 次の方法を使用して、データが正常に移行されたことを確認します。

      • Oracle Databaseの行数とソース・データベースの行数を比較

      • Oracle Databaseの数値列の合計を計算し、ソース・データベースの数値列の合計と比較

   3. 次の条件が制約に適用されていることを確認します。

      • 重複する主キーは入力できない

      • 外部キーによって、一貫性のないデータ入力が防止される

      • チェック制約によって、無効なデータ入力が防止される

   4. 索引および順序が正常に作成されていることを確認します。

   5. 次の方法を使用して、ビューが正常に移行されたことを確認します。

      • Oracle Databaseの行数とソース・データベースの行数を比較

      • Oracle Databaseの数値列の合計を計算し、ソース・データベースの数値列の合計と比較

   6. トリガー、プロシージャおよびファンクションが正常に移行されたことを確認します。トリガーおよびファンクションに対して、適切な値が戻されることを確認します。

3. 移行したデータベースに対して、テスト・ケースを実行します。

4. テスト・ケースの結果を評価するレポートを作成します。

   これらのレポートを使用すると、データを評価してエラーを限定したり、問題レポートを保存したり、顧客に対してデータベースのテスト用バージョンを提供できます。

5. テストを通過した場合は、ステップ7に進みます。

   テスト・ケースのすべての評価基準が満たされているか、または発生しているエラーが許容可能な場合、テストを通過できます。許容可能なエラーが発生した場合は、それらをエラー・レポートに記録して、監査の目的で使用できるようにします。

6. テスト・ケースでエラーが発生した場合は、次の作業を実行します。

   1. エラーの原因を特定します。

   2. エラーの確認に必要なテスト・ケースを特定します。

   3. 問題レポートに、テスト用バージョンの移行済データベース・コードでの問題を記録します。

   4. ユーザーの組織で使用されている問題追跡システムに、テスト・ケースおよび問題の説明を追加します。問題追跡システムは、スプレッドシートでも、不具合のレポート・システムでもかまいません。インシデント・ログには、テスト・ケース以外に次の内容を含めます。

      • 発生した問題についての明快で簡潔な説明

      • 環境の詳細な説明(プラットフォーム、ソースの制御バージョンなど)

      • テストの出力(役に立つ場合)

      • 問題の発生頻度および予測可能性

      • 問題が発生するまでのイベントの順序

      • 現行のテストでの影響、実行した診断ステップおよび要注意の結果

      • 後で現れる永続的な影響(存在する場合)

   5. エラーの修正を試行します。

   6. ステップ1に戻ります。

7. Oracle Databaseの品質が許容レベルであることを確認するために使用可能な受入れテストを指定します。

3.2.10.2.1 テストの作成ガイドライン

Oracle Databaseのテストに、元のアプリケーションで行われた一連のユニット・テストおよびシステム・テストを使用できる場合があります。ただし、ユニット・テストおよびシステム・テストがない場合は作成する必要があります。テスト・ケースを作成する場合は、次のガイドラインに従います。

• テスト・ケースを計画、指定および実行して、その結果を記録します。

  実行するテストの量は、その移行プロジェクトで使用可能な時間およびリソースに比例します。通常、移行プロジェクトのテスト・フェーズでは、プロジェクト全体の40%から60%の労力が想定されます。

• テストの対象となるコンポーネント、テスト計画の方法およびテストの達成基準を指定します。

• 各テスト・ケースを再現できるように定義します。

  再現できないテストは、問題の追跡または監査プロセスでは使用できません。

• ソース・データベースをファンクションとプロシージャに分割し、それぞれに対してテスト・ケースを作成します。テスト・ケースでは、テストする内容を明確にし、テスト基準を定義し、予想される結果を記述します。

• 各テスト・ケースでの予想される結果を記録します。

• 各テストで、実際の結果が予想される結果と一致しているかどうかを検証します。

• 予想される結果が肯定的なテスト・ケースのみでなく、結果が否定的なテスト・ケースも定義します。

3.2.10.2.2 ユニット・テスト・ケースの例

Windowsでのユニット・テスト計画の例を次に示します。

名前                                         Jane Harrison

モジュール                                      Table Test Emp

テストの完了日                2007年5月23日

対象とするログ・ファイルの位置      mwb\database\TableTestEmp

説明                               このユニット・テストでは、emp表が正常に移行されたことをテストします。

確認者                             John Smith

タスクID	タスクの説明	予想される結果	確認済(はい/いいえ)
1	ソース・データベースの各表に対して次の文を実行します。 select count(*) from emp 移行先データベースの各表に対して次の文を実行します。 select count(*) from emp	ソース・データベースでは、count(*)によって数値が生成されます。この場合、生成される数値は各表の行数です。 移行先データベースでは、count(*)の数値は新しいOracle表の行数に対応します。	はい 各表の行数は、ソース・データベースと移行先データベースで同じになります。
2	ソース・データベースの各表に対して次の文を実行します。 select sum(salary) from emp 移行先データベースの各表に対して次の文を実行します。 select sum(salary) from emp	ソース・データベースでは、sum(salary)によって各表のデータの合計に対するチェックサムが算出されます。 移行先データベースでは、sum(salary)はemp表のsalaryの合計に対応します。	はい 各表の合計は、ソース・データベースと移行先データベースで同じになります。

3.2.11 Oracle Databaseのデプロイ

移行およびテスト済のOracle Databaseを業務環境内にデプロイする場合、困難が伴うことがあります。そのため、環境に応じて、別のロールアウト方法の検討が必要になる場合があります。いくつかのロールアウト方法を示しますが、組織で推奨されている方法がある場合はその方法を使用できます。

デプロイメント・フェーズでは、移行先データベースを開発環境から本番環境に移動します。移行およびテスト・チームとは別のグループ(組織内のIT部門など)がデプロイメント・フェーズを担当する場合があります。

デプロイメントでは、次の作業を行います。

• ロールアウト方法の選択

• 移行先データベースのデプロイ

3.2.11.1 ロールアウト方法の選択

サード・パーティ・データベースからOracle Databaseに移行する場合に使用する計画では、移行期間中に影響を受ける可能性があるユーザーおよび業務の種類について考慮する必要があります。たとえば、ソース・データベースおよびOracle Databaseを同時に実行するための十分なシステムがない場合は、ビッグ・バン・アプローチを使用できます。また、システムを一般のユーザーに開放する前に、そのシステムがユーザー環境で正常に動作することを確認する場合は、段階的アプローチを使用できます。次のいずれかの方法を使用できます。

3.2.11.1.1 段階的アプローチ

段階的アプローチを使用すると、ユーザー・グループを異なるタイミングで移行できます。1つの部門またはユーザー・ベース全体の一部を移行することができます。選択するユーザーは、ユーザー・ベース全体の一部を代表するユーザーである必要があります。この方法を使用すると、Oracle Databaseへのユーザーの導入時に、ユーザーをプロファイルできます。選択したユーザーのみが移行の影響を受け、一部のユーザーのみがスケジューリングされていない停止の影響を受けるように、システムを再構成できます。この方法は、移行したユーザーの作業に影響を与える場合があります。ただし、ユーザー数が限られているため、サポート・サービスが問題によってオーバーロードされることはありません。

段階的アプローチを使用すると、移行ユーザー数の増加に伴い発生するスケーラビリティの問題をデバッグできます。ただし、この方法を使用すると、移行時にレガシー・システムとの間でデータを移行する必要がある場合があります。アプリケーションのアーキテクチャでは、段階的アプローチがサポートされている必要があります。

3.2.11.1.2 ビッグ・バン・アプローチ

ビッグ・バン・アプローチを使用すると、すべてのユーザーを同時に移行することができます。この方法では、古いシステムの削除中、データの移行中、Oracleシステムのデプロイ中、およびシステムが正常に動作しているかどうかのテスト中に、スケジューリングされた停止が発生する場合があります。この方法では、元のデータベースと同じ規模のデータベースをテストする必要があります。これでは、データベースをオフラインにするため、元のデータベースとのデータ変換および同期化を最小限に抑えることができるというメリットがあります。デメリットは、Oracle Databaseのインストールおよびその他の移行プロジェクト・タスクの実行にスイッチオーバー期間が必要なため、労力がかかり、業務に悪影響を与える可能性があることです。

3.2.11.1.3 パラレル・アプローチ

パラレル・アプローチを使用すると、ソース・データベースと移行先のOracle Databaseの両方を同時に保持できます。アプリケーションが本番環境でソース・データベースおよび移行先データベースに対して同じように動作するかを確認するには、両方のデータベースにデータを入力し、データの結果を分析します。この方法のメリットは、移行先データベースで問題が発生した場合に、ユーザーがソース・データベースの使用を継続できることです。パラレル・アプローチのデメリットは、ソース・データベースと移行先データベースの両方を実行して保持するために、他の方法より多くのリソースとハードウェアが必要になる場合があることです。

3.2.11.2 移行先データベースのデプロイ

移行先データベースをデプロイするには、いくつかの方法があります。移行先データベースをデプロイする際のガイドラインとして使用するタスクの例を次に示します。

ノート:

複雑な計画の場合は、すべてのデプロイメント・タスクを完了することをお薦めします。ただし、単純な計画の場合は、所属する組織に適したデプロイメント・タスクを選択する必要があります。

1. 必要に応じて、ハードウェアを構成します。

   大規模な環境または複雑な環境では、データベース設計に対応するようにディスクのレイアウトを設計する必要があります。冗長ディスクを使用する場合は、移行先データベースの増大に伴って増加できるように冗長ディスクをストライプ化します。必要なディスクを設置および構成して、メモリーを確認し、システムを構成する必要があります。

2. オペレーティング・システムがOracle構成のパラメータに対応していることを確認します。

   Oracleソフトウェアをインストールする前に、すべてのシステム・パラメータが変更されていることを確認します。システム・パラメータの変更の詳細は、ご使用のプラットフォーム(Solarisオペレーティング・システムなど)のインストレーション・ガイドを参照してください。

3. Oracleソフトウェアをインストールします。

   Oracle Databaseの作成のために使用するOracleソフトウェア以外に、アプリケーションをサポートする付属のソフトウェア(データ・ウェアハウスのExtract Transformation and Load(ETL)ソフトウェアなど)のインストールが必要になる場合があります。

4. ソース・データベースから移行先データベースを作成し、Oracle Databaseにデータを移行します。

   移行先データベースを、テストした後に本番環境に配置するには、次のいくつかの方法があります。

   • テストが正常に完了したデータベースを本番環境に配置します。この時点で、テスト・システムが本番システムになります。

   • Oracle Exportを使用して、テストが正常に完了したデータベースから移行先データベースを抽出し、Oracle Importを使用してそのデータベースを本番環境内に作成します。

   • テスト済の移行スクリプトを使用してOracle Databaseを作成し、SQL*Loaderを使用してそのOracle Databaseにデータを移入します。

5. 移行先データベースおよびアプリケーションで最終確認を行います。
6. いずれかのロールアウト方法を使用して、移行先データベースを本番環境に配置します。
7. 次のことを実行して、最終監査を行います。

   • データ整合性の監査

   • プロセス(バックアップやリカバリなど)の妥当性の監査

   • プロジェクトのサインオフの取得(必要な場合)

関連項目

• 移行: 基本の選択肢とステップ

• 移行: バックグラウンド情報とガイドライン

• 移行に使用するSQL Developerユーザー・インタフェース

3.3 移行に使用するSQL Developerユーザー・インタフェース

データベースの移行を実行する場合は、移行固有の機能を使用する必要があります。ユーザー・インタフェースでは、「ツール」の「移行」サブメニューとしてナビゲータ(「移行プロジェクト」)が追加され、インタフェース全体にわたって多くの細かな変更が行われています。図3-2に、Sybaseデータベースの移行を反映するオブジェクトが表示された、SQL Developerのメイン・ウィンドウを示します。「移行」サブメニューも示します。

図3-2 データベースの移行のためのメイン・ウィンドウ

図3-2「データベースの移行のためのメイン・ウィンドウ」の説明

この図の内容を次に示します。

• 「接続」ナビゲータに、sybase_15という接続が示されており、これがOracleに移行するSybaseデータベースです。接続名は、右上のドロップダウン・コントロールにも表示されています。

• 移行プロジェクト・ナビゲータの「プロジェクト - 」の後の<repository-connection>が移行リポジトリでの実際の接続名です。

• 移行プロジェクト名が、sybase_15_migrです。

• プロジェクト名の下には、「取得されたデータベース・オブジェクト」および「変換されたデータベース・オブジェクト」のツリー(階層)があります。

ノート:

移行タスクにSQL Developerグラフィカル・インタフェースを使用するかわりに、コマンドラインを使用できます。

3.3.1 「移行」サブメニュー

「移行」サブメニューには、Oracleへのサード・パーティ・データベースの移行に関連するオプションが含まれています。「移行」サブメニューを表示するには、「ツール」、「移行」の順にクリックします。

移行: 効率的な移行を実行するためのウィザードを表示します。ウィザードには、指定した移行に関連するステップおよびオプションが表示されます。

クラウド移行: Amazon RedshiftからOracle Autonomous Data Warehouse Cloudにデータベース・ファイルを移行するためのクラウド移行ウィザードを表示します。

アプリケーションのスキャン: アプリケーションの移行ウィザードを表示します。

スクラッチ・エディタ: 変換スクラッチ・エディタを表示します。変換スクラッチ・エディタの使用を参照してください。

データベース取得スクリプトの作成では、オフライン取得プロパティ(.ocp)ファイルなど、スクリプト・ファイルを作成するオプションを指定します(このファイルは、後でロードして実行することができます)。

リポジトリ管理: 移行リポジトリの作成(関連付け)または削除、現在のリポジトリからの切断(現在のリポジトリは無効になるがデータベースからは切断されない)またはリポジトリの切捨て(すべてのデータを削除)を行うことができます。

3.3.2 その他のメニュー: 移行に関する項目

「ビュー」メニューには、データベースの移行に関連する次の項目があります。

• 移行プロジェクト: 「移行プロジェクト」ナビゲータを表示します(現在選択されている移行リポジトリ内の取得モデルおよび変換モデルが含まれます)。

3.3.3 移行のプリファレンス

(「ツール」→「プリファレンス」をクリックすると表示される)SQL Developerユーザー・プリファレンス・ウィンドウには、「移行」ペインといくつかの関連サブペイン、および「変換」ペインと「変換プリファレンス」サブペインが含まれています。

3.3.4 移行のログ・ペイン

移行ログ: 移行操作に関連するエラー、警告および情報メッセージが含まれています。

ロギング・ページ: 移行に関連する各操作のエントリが含まれています。

データ・エディタ・ログ: SQL Developerによってデータが操作されている場合のエントリが含まれています。たとえば、Microsoft Excelのインポート操作での出力は、一連のINSERT文としてここにレポートされます。

3.3.5 変換スクラッチ・エディタの使用

変換スクラッチ・エディタを使用すると、入力したサード・パーティ・データベースのSQL文をOracle PL/SQL文に変換できます。Microsoft SQL Server T-SQLからPL/SQLへの変換、またはSybase T-SQLからPL/SQLへの変換を指定できます。

「ツール」、「移行」、「翻訳検索エディタ」の順にクリックすると、スクラッチ・エディタを表示できます。スクラッチ・エディタは、次の図に示すように、隣り合う2つのSQLワークシート・ウィンドウで構成されています。

ある文をOracleでの同等文に変換するには、変換のタイプを選択し、サード・パーティのSQL文を入力し、「変換」ドロップ・ダウンから特定の変換を選択し(Access SQL to PL/SQLなど)、必要に応じて取得済スキーマ・ドロップ・ダウンから適用可能なスキーマを選択し、「翻訳」(>>)アイコンをクリックして、生成されたPL/SQL文を表示します。

SQLキーワードは、自動的にハイライト表示されます。

ノート:

Microsoft SQL ServerまたはSybase Adaptive Server接続の場合、ワークシートではT-SQL文の実行をサポートしていません。SELECT、CREATE、INSERT、UPDATE、DELETEおよびDROP文のみをサポートしています。

変換スクラッチ・エディタでいずれかのワークシート・ウィンドウの内容を初めて保存する場合は、ファイルの場所と名前の入力を求められます。以降の「保存」操作では、(ウィンドウの内容を削除したか変更したかに関係なく)ウィンドウの内容は同じファイルに保存されます。別のファイルに内容を保存するには、「ファイル」→「別名保存」をクリックします。

3.4 移行のコマンドライン・インタフェース

移行操作には、SQL Developerグラフィカル・インタフェースのかわりに、コマンドライン・インタフェースを使用することもできます(「SQL Developerのコマンドライン・インタフェース」を参照)。

ヒント:

標準的な移行のウォーク・スルーは、sqldeveloper\sqldeveloper\binフォルダに移動して、次のコマンドを入力してください。

sdcli migration -help=guide