| Oracle Database SQL Developerユーザーズ・ガイド リリース1.2 E06017-01 |
|
 戻る |
 次へ |
|
注意: SQL Developerの移行機能は、Oracle Migration Workbench製品を発展させたものです。 |
移行とは、MySQL、Microsoft SQL Server、Microsoft Accessなどのソースとなる（Oracle以外の）サード・パーティ・データベースからOracle Databaseにスキーマ・オブジェクトおよびデータをコピーするプロセスのことです。移行は、大部分が自動化された効率的な方法で実行できます。この方法では、ソース・スキーマ・オブジェクトがOracleスキーマ・オブジェクトとして実装され、実装に必要な（順序やトリガーなどの）関連オブジェクトが自動的に作成されます。
したがって、SQL Developerでサード・パーティ・データベースを処理する場合は、次の2つのオプションがあります。
データベース接続を作成し、それらのデータベースのスキーマ・オブジェクトおよびデータを参照できるようにするオプション
それらのデータベースをOracleに移行し、Oracle Databaseの特性および機能を最大限に活用できるようにするオプション
この章の内容は次のとおりです。
2.8「Oracleスキーマ・オブジェクト用のDDLの生成」
2.13「移行に使用するSQL Developerユーザー・インタフェース」
サード・パーティ・データベースをOracleに移行するための基本的な操作には、移行の準備、移行リポジトリの作成または選択、ソース・データベースの取得、取得したデータベースの変換、新しいOracleスキーマ・オブジェクト用のDDLの生成および実行、およびオプションで、ソース・データベースから新しいデータベースへのデータの移動があります。（手順1を終えた後は、一部の手順を別の順序で実行できます。）
第2章「サード・パーティ・データベースの移行」の該当する関連項目を参照して移行の準備を行います。
新しいOracle接続または既存のOracle接続に移行リポジトリを作成します。 移行作業用に個別のOracle DatabaseユーザーおよびOracle接続を作成する操作は簡単かつ有効です。その後、接続を選択してリポジトリを作成します。次に例を示します。
デフォルトの表領域USERおよび一時表領域TEMPを持つOracleユーザーMIGRATIONSを作成し、このユーザーに少なくともRESOURCE、CREATE SESSIONおよびCREATE VIEW権限を付与します。
MIGRATIONSユーザーに接続するデータベース接続Migration_Repositoryを作成します。
Migration_Repository接続を右クリックし、「Associate Migration Repository」を選択して、リポジトリを作成します。
Oracleユーザーを作成してそのユーザーのスキーマをオブジェクトの移行先として使用するか、または既存のOracleユーザーおよびスキーマを使用します。このユーザーには十分な権限を付与します。
たとえば、sales.mdbというMicrosoft Accessデータベースを移行するには、OracleユーザーSALESを作成して、このユーザーのスキーマにOracle Databaseオブジェクトを生成します。
前述の手順で作成または選択したスキーマにOracle接続を作成してオープンします。
たとえば、ユーザーSALESに関連付けられているスキーマに、Sales_OracleというOracle接続を作成して接続します。
サード・パーティ・データベースへのデータベース接続を作成してオープンします。
たとえば、sales.mdbというMicrosoft Accessデータベースへのデータベース接続Sales_Accessを作成して接続します。
必要に応じて、クイック移行機能または手動による方法（あるいはこれらの組合せ）を使用して移行を実行します。 クイック移行は迅速かつ簡単ですが、手動操作はより柔軟に実行できます。 （クイック移行機能を使用せずに、かわりに残りの操作を手動で実行する場合は、この手順の残りの操作をスキップして、2.1.1「手動による残りの移行操作の実行」に進みます。）
クイック移行機能を使用するには、「Migration」→「Quick Migrate」をクリックし、ダイアログ・ボックスに示される手順に従います。
「Source Connection」では、移行するサード・パーティ・データベースの接続を選択します。 例: Sales_Access
「Target Connection」では、サード・パーティ・データベースの移行先となるOracle Databaseスキーマの接続を選択します。 例: Sales_Oracle
「Repository」では、選択した既存のリポジトリを使用します。リポジトリが存在しない場合は、SQL Developerでターゲット接続のスキーマに移行リポジトリを作成できるようにします。
「Verify」をクリックして、移行前チェックを開始します。
移行前チェックが問題なく完了した後で、「Migrate」をクリックしてスキーマおよびデータの移行を実行します。
実行する具体的な操作は、移行するサード・パーティ・データベースのタイプによって異なります。 たとえば、Microsoft Accessデータベースの場合は、Exporter for Microsoft Accessツールが自動的に起動されます。 移行操作はいずれも中断しないでください。
クイック移行機能を使用せずに2.1「移行のクイック・スタート」の残りの移行操作を実行する場合は、この項の手順に従います。 また、クイック移行機能の使用時にエラーが発生した場合は、残りの手順の一部を手動で実行して移行を完了できます。
移行するソース・スキーマ・オブジェクトを取得します。これを行うには、「Connections」ナビゲータで接続名を右クリックし、「Capture product-name」（たとえば、「Capture MySQL」、「Capture Microsoft Access」、「Capture Microsoft SQL Server」など）を選択します。
ソース・データベースを取得する場合は、「Quick Migrate」オプションの一部として取得を自動的に実行するか、または個別の操作として実行できます。個別の操作として実行するには、「Connections」ナビゲータで接続名を右クリックし、「Capture product-name」（たとえば、「Capture MySQL」、「Capture Microsoft Access」、「Capture Microsoft SQL Server」など）を選択します。
「Capture Microsoft Access」を選択すると、Microsoft Accessのエクスポータ・ツールが自動的に起動され、スキーマおよび表データを移行するためのXMLファイルが作成されます。 ただし、（特定のオプションを制御する目的などで）エクスポータ・ツールを手動で実行する場合は、「Migration」→「Microsoft Access Exporter」をクリックしてから、使用しているバージョンのMicrosoft Accessの項目をクリックします。 エクスポータ・ツールの手順に従います。エクスポータ・ツールには、独自のオンライン・ヘルプがあります。
取得が終了すると、「Captured Objects」ナビゲータに、取得したオブジェクトの展開可能なノードが表示されます（たとえば、2.13「移行に使用するSQL Developerユーザー・インタフェース」の図に示されているように、sales.mdbというオブジェクトを取得した場合は、sales (Access) と表示されます）。
取得したオブジェクトをOracle形式のオブジェクトに変換します。「Captured Objects」ナビゲータで該当するノードを右クリックし、「Convert to Oracle Model」を選択して、データ・マッピングにデフォルト値を使用します（必要に応じて、選択したマッピングを指定します）。
変換が終了すると、「Converted Models」ナビゲータに、変換されたオブジェクトの展開可能なノードが表示されます（たとえば、Converted sales (Access)と表示されます）。
ソース・データベース・オブジェクトに対応するOracle Databaseオブジェクトを作成するためのDDL文を作成するSQL*Plusスクリプトを生成します。「Captured Models」ナビゲータで該当するノードを右クリックし、「Generate」を選択します。SQLワークシート・ウィンドウが開き、SQL*Plus文が表示されます。
表示されたSQLワークシート・ウィンドウの右側のドロップダウン・リストで、スクリプトの実行（次の手順）の対象となるOracle Database接続を選択します。
生成されたSQL*Plus文を確認し、必要に応じて変更を行います。たとえば、生成されたオブジェクトを所有するデータベース・ユーザーがすでに存在する場合（ここで説明するクイック・スタートの手順に従うと、この状況が発生します）は、CREATE USERおよび関連する文を削除または変更します。
SQLワークシート・ウィンドウで「Run Script」ボタンをクリックしてスクリプトを実行します。
生成されたオブジェクトのOracleユーザーへの接続（Sales_Oracleなど）を切断し、再接続します。「Connections」ナビゲータに、移行したサード・パーティ・データベースのオブジェクトに対応する新しいデータベース・オブジェクトが表示されます。
必要に応じて、既存のデータをソース・データベースからOracle Databaseに移行（移動）できます。データの移行には、オンライン（データをすぐに移動する）およびオフライン（データを後で移動する）の2つのオプションがあります。
オンラインでデータを移動するには、「Migration」→「Migrate Data」をクリックします。ダイアログ・ボックスで、「Source Connection」、「Target Connection」および「Converted Model」を指定します。
オフラインでデータを移動するには、「Migration」→「Script Generation」→「Generate Data Move Scripts」をクリックし、変換モデル、およびSQL*Loaderを使用したソース・データベースからのデータのアンロードとOracleへのインポートに使用するファイルを生成するディレクトリを指定します。
Oracle Databaseでは、サード・パーティ・データベースより高いスケーラビリティ、信頼性、パフォーマンスおよびセキュリティが提供されます。このため、多くの企業が、現行のデータベース（Microsoft SQL Server、Microsoft Accessなど）からOracle Databaseに移行しています。データベースの移行は複雑になる場合がありますが、SQL Developerを使用すると、サード・パーティ・データベースからOracle Databaseに移行するプロセスを簡略化できます。
SQL Developerは、ソース・データベースから情報を取得し、その情報を取得モデルに表示します。取得モデルは、ソース・データベースの構造表現です。この表現は移行リポジトリに格納されます。移行リポジトリは、SQL Developerが移行情報の格納に使用するスキーマ・オブジェクトの集合です。
リポジトリに格納されている情報を使用して、変換モデルが生成されます。変換モデルは、Oracle Databaseで実装される移行先データベースの構造表現です。この後、取得モデルおよび変換モデルの情報を使用して、データベース・オブジェクトの比較、Oracle予約語との競合の確認および移行の進捗状況の管理を行うことができます。移行の準備が整ったら、Oracleスキーマ・オブジェクトを生成して、データを移行します。
SQL Developerには、ソース・データベースのデータ・ディクショナリからデータを抽出し、取得モデルを作成し、取得モデルを変換モデルに変換するためのロジックが含まれています。
サード・パーティ・データベースからOracle Databaseへの移行にSQL Developerを使用すると、次のメリットがあります。
移行プロジェクトに伴う労力とリスクが軽減します。
トリガーやストアド・プロシージャを含むサード・パーティ・データベース全体を移行できます。
取得モデルと変換モデルを表示して比較し、それぞれを必要に応じてカスタマイズすることができるため、移行プロセスの自動化の程度を制御できます。
移行に関するフィードバックがレポートされます。
SQL Developerのコンポーネントは、連動してサード・パーティ・データベースをOracle Databaseに移行します。図2-1「SQL Developerによる移行のアーキテクチャ」に、SQL Developerでソース・データベースから情報を読み取り、Oracle Databaseのスキーマ・オブジェクトを作成する方法を示します。SQL Developerは、移行リポジトリに格納されている情報を使用して、Oracleスキーマへの移行を行います。移行前に、取得モデルまたは変換モデル（あるいはその両方）を変更できます。変換モデルの情報を使用して、移行が行われ、移行先のOracleスキーマにデータベース・オブジェクトが生成されます。
ここでは、移行プロジェクトの計画を作成するプロセスについて説明します。移行計画に含めるタスクを特定し、それぞれのタスクの内容を判断する方法、および移行プロジェクトに伴うリスクを回避する方法について説明します。内容は次のとおりです。
このタスクでは、移行するデータベース、およびそのデータベースにアクセスするアプリケーションを特定します。また、業務要件を評価し、テスト基準を定義します。
移行プロジェクトの要件を確認するには、次の手順を実行します。
プロジェクトの範囲を定義します。
移行プロジェクトの範囲を定義するには、サード・パーティ・データベースおよびそのデータベースにアクセスするアプリケーションに関していくつかの項目を選択する必要があります。移行の問題および依存性のリストを作成する場合は、次のことを考慮します。
移行するサード・パーティ・データベースについて
バージョン
キャラクタ・セット
サード・パーティ・データベースをOracle Databaseに移行することによって影響を受けるソース・アプリケーションについて
サード・パーティ・アプリケーションの言語
使用しているアプリケーション言語のバージョン
プロジェクトの範囲で、移行する必要があるアプリケーションを特定しておく必要があります。データベースを移行することによって影響を受けるすべての必要なアプリケーションが含まれていることを確認します。
Oracle Databaseへの移行に関連する接続性の問題のタイプについて
アプリケーションをサード・パーティ・データベースに接続するために接続ソフトウェアを使用するかどうか。アプリケーションをOracle Databaseに接続するために接続ソフトウェアを変更する必要があるかどうか。
使用する接続ソフトウェアのバージョンは何か。Oracle Databaseに接続するためにこの同じバージョンを使用できるかどうか。
Oracle Databaseで動作するように、アプリケーションを再作成または変更するかどうかについて
表2-1を使用して、ソース・データベース環境が複雑か、単純かを判断します。個々の移行計画に基づいて要件を確認します。
移行プロジェクトが単純な計画の場合は、このマニュアルで説明するすべてのタスクを実行する必要はありません。ユーザーの使用環境に基づいて決定してください。たとえば、複雑な計画の場合は、データベースにアクセスしているアプリケーションの複雑さに基づいて追加のテストが必要になる場合があります。
表2-1 複雑な計画と単純な計画
| 複雑な計画 | 単純な計画 |
|---|---|
|
次の項目のうち複数に該当する。
|
次の項目に該当する。
|
移行先データベースにハードウェアの追加およびバックアップ・スケジュールの再作成が必要かどうかを判断します。
テストおよび評価基準を定義します。
移行の精度が測定されるようにテストを定義します。その後、評価基準によって、移行が正常に実行されたかどうかを確認します。要件に基づいて作成されたテストでは、安定性の測定、パフォーマンスの評価およびアプリケーションのテストも行われます。Oracle Databaseおよびアプリケーションを本番環境にデプロイする前に必要なテストの範囲を判断する必要があります。
移行プロジェクトの要件が記載されたドキュメントを作成します。
要件ドキュメントでは、タスクを明確に定義し、個々の要件に番号を付け、必要に応じてそれらの要件を詳細な要件に分割します。
このタスクでは、SQL Developerを使用して、自動化が可能な作業および手動で行う作業の量を計算して決定します。
ワークロードを見積もるには、次の手順を実行します。
取得モデルの取得、変換モデルの作成、および移行先データベースへの移行を行います。
取得モデルを使用してソース・データベースを分析し、変換モデルを使用して移行先データベースのプレビューを分析することができます。ソース・データベースを取得した後で、取得モデルおよび変換モデルに含まれている取得データを分析します。移行リポジトリの内容と構造が正しいことを確認し、プロセス全体にかかる時間を判断します。
「Migration Log」ペインを使用して、取得プロセスおよび移行プロセスの評価、データベース・オブジェクトの合計数の分類、および自動的に変換かつ移行可能なオブジェクトの数の確認を行います。
移行ログには、実行されたアクションに関する情報が提供され、警告およびエラーが記録されます。警告およびエラーによって、変換モデルに対して行われた変更が特定されるため、移行先データベースにアクセスするアプリケーションに対して変更を行う必要があるかどうかを評価できます。
発生した問題を評価および分類します。 移行ログには、次のものについての有効な情報が提供されます。
ソース・データベースの取得時にロードされなかった表
変換モデルの作成時に解析されなかったストアド・プロシージャ、ビューおよびトリガー
手動操作が必要な構文
移行先データベースへの移行時に正常に作成されなかったデータベース・オブジェクト
移行先データベースへの移行時に正常に移行されなかったデータ
移行ログ内の各エラーまたは警告に対して、次の項目を評価します。
問題が発生した回数
問題の修正に必要な時間（人時）
問題の修正に必要なリソースの数
複雑な問題を解決した後、次に同様の問題が発生した場合は、より簡単かつ迅速にその問題を解決できるようになります。
このタスクでは、次の手順を実行して操作要件を分析します。
ソース・データベースを移行先データベースに移行する場合の操作上の考慮点について検討します。次の項目を確認します。
必要なバックアップおよびリカバリの変更
移行時に必要な停止時間
パフォーマンス要件に適合しているかどうか
操作時間枠を変更するかどうか
停止時間が業務に与える影響
トレーニング要件、または従業員に関する追加の考慮点
サード・パーティ・データベースとOracle Databaseを同時に実行する必要があるかどうか
各タスクについて、実行に必要なリソースおよび時間を判断します。
要件の確認および計画の段階で収集した情報を使用して、最初のプロジェクト計画を作成します。
このタスクでは、ソース・データベースで実行されているアプリケーションのユーザー、ソース・データベースに必要なハードウェア、アプリケーションの機能、およびソース・データベースに対するアプリケーションのインタフェースを確認します。また、データベースに接続して必要な変更を特定するためにアプリケーションで使用される方法も分析します。
アプリケーションを分析するには、次の手順を実行します。
アプリケーションを移行先データベースで効果的に実行するためにアプリケーションに変更を行う必要があるかどうかを判断します。
アプリケーションへの変更が必要な場合は、アプリケーションの再作成または変更のいずれがより効果的かを判断します。
Oracle Databaseを使用するためにアプリケーションを再作成する場合は、次のことを考慮します。
アプリケーションの再作成に必要なプロジェクト・ドキュメントを作成します。たとえば、設計仕様および要件ドキュメントが必要です。
仕様に従ってアプリケーションを再作成します。
アプリケーションがOracle Databaseに対して動作することをテストします。
Oracle Databaseを使用するためにアプリケーションを変更する場合は、次のことを考慮します。
アプリケーションに存在するデータベースへの接続数を確認し、Oracle Databaseが使用されるようにこれらの接続を変更します。
ODBC接続またはJDBC接続を使用するために、接続情報の変更が必要な場合があります。
Oracle Databaseに対してアプリケーションのテストを行う前に、アプリケーションで変更が必要な埋込みSQL文を特定します。
Oracle Databaseを使用してアプリケーションをテストします。
アプリケーションの再作成または変更に関連する各問題に対処するための時間およびリソースを割り当てます。
タスク1で作成した、このプロジェクトについての一般的な要件ドキュメントを更新します。
このタスクでは、移行プロジェクトに含まれている可能性がある不確定要素（ソース・データベースと移行先データベースでのテクノロジの違いなど）を分析します。計画段階では、次のことを行います。
プロジェクトの予算制約を見積もります。
移行計画を作成するための情報を収集します。
移行プロジェクトにかかる時間を見積もります。
移行を完了し、テストするために必要なリソースの量を計算します。
移行プロジェクトを計画するには、次の手順を実行します。
タスク1の移行プロジェクト要件を完全に満たすために必要なタスクのリストを定義します。
移行プロジェクトを完了するために必要なタスクのリストを分類します。
これらのタスクを業務別にグループ化する必要があります。これによって、リソースのスケジュールおよび割当てをより正確に行うことができます。
タスク3および4で収集した情報に基づいて移行プロジェクトの計画を更新し、最終版を確定します。
移行プロジェクトの計画が移行プロジェクトの要件を満たしていることを確認します。
移行計画には、プロジェクトの説明、割り当てられたリソース、トレーニング要件、移行結果、全体要件、環境分析、リスク分析、アプリケーションの評価、および移行スケジュールを含める必要があります。
サード・パーティ・データベースからOracle Databaseへの移行を開始する前に、特定のタスクの実行が必要になる場合があります。内容は次のとおりです。
2.5で説明する、移行するソース・データベース固有の情報も参照してください。
|
注意: 移行を開始する前に、ソース・データベースの完全バックアップを行うことをお薦めします。ソース・データベースのバックアップの詳細は、そのデータベースのタイプ固有のドキュメントを参照してください。 |
サード・パーティ・データベースをOracle Databaseに移行するには、SQL Developerに移行リポジトリが必要です。移行リポジトリにOracle Databaseを使用するには、データベース・ユーザー・アカウントを使用してそのデータベースにアクセスできる必要があります。移行には専用のユーザー・アカウントを使用することをお薦めします。たとえば、MIGRATIONSというユーザーを作成し、このユーザーに対するデータベース接続を作成して、その接続を移行リポジトリに使用します。必要に応じて、後でMIGRATIONSユーザーを削除して、データベースから移行のすべての形跡を削除できます。
移行用のユーザーを作成する場合は、表領域のデフォルトを使用するのではなく、次の例に示すように表領域の情報を指定します。
CREATE USER migrations IDENTIFIED BY migrations DEFAULT TABLESAPACE users TEMPORARY TABLESPACE temp,
移行には、標準アカウント（SYSTEMなど）は使用しないでください。
SQL Developerは、移行リポジトリの作成時に、SQL Developerでの使用のみを目的とした多くのスキーマ・オブジェクトを作成します。たとえば、表、ビュー、索引、パッケージおよびトリガーを作成します。これらの多くの名前はMD_およびMIGRで始まります。これらのオブジェクト、またはこれらのオブジェクトに格納されているデータは直接変更しないでください。
移行の実行（生成された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 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 migrations DEFAULT TABLESAPACE users TEMPORARY TABLESPACE temp; GRANT CONNECT, RESOURCE, CREATE 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を実行すると、現在の状況で必要となる権限がスクリプトから明らかになります。
Oracle Databaseに移行するサード・パーティ・データベースによっては、接続情報を構成し、ドライバをインストールする必要がある場合があります。サード・パーティ・データベースに固有の要件の詳細は、次の項を参照してください。
Microsoft SQL Serverデータベースを移行用に構成するには、次の手順を実行します。
SQL Developerで使用されるMicrosoft SQL Serverユーザーがソース・データベースにアクセス可能であることを確認します。このユーザーには、Microsoft SQL Serverデータベースに対するDBA権限が必要です。
SQL DeveloperがインストールされているシステムからMicrosoft SQL Serverデータベースに接続できることを確認します。
http://jtds.sourceforge.net/からJTDS JDBCドライバをダウンロードしてあることを確認します。
SQL Developerで、次の手順を実行します。
「Tools」→「Preferences」→「Database」→「Third Party JDBC Drivers」をクリックします。
「Add Entry」をクリックします。
http://jtds.sourceforge.net/からダウンロードしたJTDSドライバのjarファイルを選択します。
「OK」をクリックします。
Microsoft Accessデータベースを移行用に構成するには、次の手順を実行します。
データベース・ファイルのバックアップを作成します。
必要なソフトウェア（Microsoft Access、Microsoft ODBCドライバ、Microsoft Data Access Objectおよびその他のコンポーネント）がSQL Developerと同じシステムにインストールされていることを確認します。
「Create/Edit/Select Database Connection」ダイアログ・ボックスの「「Access」タブ」で説明されているように、Adminユーザーに、名前がMsysで始まるシステム・テーブルに対して少なくとも構造の読取り権限およびデータの読取り権限が付与されていることを確認します。
セキュリティが有効になっている場合は、次の手順を実行して、保護されたデータベースの内容を新しいデータベースにコピーすることによってセキュリティを無効にする必要があります。
SQL Developerでは、セキュリティが有効になっているMicrosoft Accessデータベースの移行はサポートされていません。デフォルトでは、SQL Developerは、Microsoft Access MDBファイルの名前を移行先のOracleユーザーのユーザー名として使用します。この方法でOracleユーザーを作成する場合、パスワードはORACLEです。
Microsoft Accessの「ファイル」メニューから、「データベースの新規作成」を選択します。
「空のデータベース」アイコンを選択し、「OK」をクリックします。
「新しいデータベース」オプションで、データベースの名前を入力し、「作成」をクリックします。
新しいデータベースで、「ファイル」メニューから「外部データの取り込み」→「インポート」を選択します。
インポート対象の保護されたMicrosoft Accessデータベースを選択し、「インポート」をクリックします。
「インポートのオプション」ダイアログ・ボックスで、「オプション」をクリックします。
「リレーションシップ」オプションと「テーブル構造とデータ」オプションを選択します。
「テーブル」タブで、「すべて選択」を選択します。
「OK」をクリックします。
セキュリティ設定を除くすべてのMicrosoft Accessオブジェクトが、新しいMicrosoft Accessデータベースにコピーされます。
他のMicrosoft Accessデータベースへのリンク・テーブルがアプリケーションに含まれている場合は、Microsoft Accessでアプリケーションを開いて次の手順を実行することによって、それらのリンクを更新します。
Microsoft Access 97では、「ツール」メニューから「アドイン」→「リンク テーブル マネージャ」を選択します。
Microsoft Access 2000では、「ツール」メニューから「データベース ユーティリティ」→「リンク テーブル マネージャ」を選択します。
|
注意: SQL Developerでは、他のMicrosoft Accessデータベースへのリンク・テーブルがサポートされます。SQL Developerは、移行された各Microsoft Accessデータベースに対してOracle Database内にユーザー・スキーマを自動的に作成します。ただし、移行先データベースに単一のユーザー・スキーマが作成されるように、すべての表を単一のMicrosoft Accessデータベースに移動することをお薦めします。 |
Microsoft Accessデータベースがレプリカ・データベースではなく、マスター・データベースであることを確認します。
データベースがレプリカの場合にExporter for Microsoft Accessを使用してエクスポートを行うと、エラー・メッセージが表示されます。SQL Developerでは、レプリカ・データベースの移行はサポートされていません。
Microsoft Accessの「ツール」メニューから、「データベース・ユーティリティ」→「最適化/修復」を選択して、Microsoft Accessデータベース・ファイルを圧縮します。
SQL DeveloperがインストールされているシステムからMicrosoft Access MDBファイルにアクセス可能であることを確認します。
Oracle Universal Installerを使用して、Oracle ODBCドライバがインストールされていることを確認します。このドライバをインストールする必要がある場合は、Oracle Database ServerまたはDatabase Clientのインストール・メディアで入手可能です。Oracle ODBCドライバは、Oracle Technology Network（OTN）のWebサイトからダウンロードすることもできます。
http://www.oracle.com/technology/software/tech/windows/odbc/
Oracle ODBCドライバをインストールすると、移行したデータをMicrosoft Accessのフォームおよびレポートで処理できます。Oracle ODBCドライバは、Oracle Net Servicesが含まれているOracleホーム・ディレクトリにインストールします。Oracle Net Servicesは、Oracle ClientまたはOracle Databaseのインストール・メディアで入手できます。Oracle Net Servicesをインストールして、Net Configuration AssistantおよびNet Managerを取得します。これらを使用すると、tnsnames.oraファイルにネット構成を作成できます。
|
注意: Oracle Databaseへの接続に必要なネットワーク製品のインストールの詳細は、ご使用のリリースのOracle Databaseのインストレーション・ガイドを参照してください。 |
ODBCデータソース・アドミニストレータで、Oracle ODBCデータソースを設定します。
「スタート」オプションから、「設定」→「コントロール パネル」を選択します。
「コントロール パネル」ウィンドウが表示されます。
Microsoft Windows 2000を使用している場合は、「管理ツール」アイコンを選択します。
「データ ソース (ODBC)」アイコンを選択します。
「ODBC Data Source Administrator」ダイアログ・ボックスが表示されます。
「User DSN」タブで、「Add」をクリックします。
「Oracle New Data Source」ダイアログ・ボックスが表示されます。
|
注意: 同じシステムで複数のユーザーにデータソース名（DSN）を使用する場合は、ユーザーDSNではなくシステムDSNを作成する必要があります。 |
システムにインストールされているODBCドライバのリストから「Oracle ODBC Driver」を選択し、「完了」をクリックします。
「データ ソース名」フィールドに、ODBCデータソースの名前を入力します。
このデータソース名が、SQL Developerの「Modify Microsoft Access Database」ダイアログ・ボックスで指定する必要があるODBCデータソースの名前となります。
Microsoft Accessデータベースを取得するための準備を行うには、Exporter for Microsoft Accessツールを自動または手動のいずれかで実行する必要があります（2.6「ソース・データベースの取得」を参照）。このツールは、Microsoft Access MDEファイルとしてパッケージ化されています。このツールを使用して、Microsoft Access MDBファイルをXMLファイルにエクスポートできます。選択したMicrosoft Accessデータベースでリンク・テーブルを使用している場合は、そのリンク・テーブルのスキーマ情報もXMLファイルにエクスポートされます。
|
注意: エクスポータ・ツールによって作成されたファイルは変更しないでください。 |
選択した各Microsoft AccessデータベースがXMLファイルにエクスポートされます。エクスポータ・ツールでは、現在、保護されたデータベースまたはレプリカ・データベースからのXMLファイルの作成はサポートされていません。
移行用にMySQLデータベースを構成するには、SQL DeveloperがインストールされているシステムにMySQLConnector/Jリリース3.0をインストールし、適切なSQL Developerプリファレンスを次のように設定します。
http://www.mysql.com/のMySQLのWebサイトから、MySQLConnector/J APIをダウンロードします。
SQL Developerで、次の手順を実行します。
「Tools」→「Preferences」→「Database」→「Third Party JDBC Drivers」をクリックします。
「Add Entry」をクリックします。
http://www.mysql.com/からダウンロードしたMySQLドライバのjarファイルを選択します。
「OK」をクリックします。
サード・パーティ・データベースを移行する前に、データベースから情報を抽出する必要があります。この情報は、ソース・データベースの構造表現であり、取得モデルと呼ばれます。データベースから情報を抽出するプロセスは、ソース・データベースの取得と呼ばれます。
この取得は、オンラインまたはオフラインのいずれでも実行できます。
オンライン取得は、SQL Developerインタフェースによって提供される便利なガイド付きの手順で実行します（2.6.1「オンライン取得」を参照）。 オンライン取得は、サポートされているすべてのサード・パーティ・データベースで使用できます。
オフライン取得には、後で実行するスクリプトの作成が含まれています（2.6.2「オフライン取得」を参照）。 オフライン取得は、MySQLおよびMicrosoft SQL Serverデータベースで使用できます。
ソース・データベースの取得後、SQL Developerの取得モデルにソース・データベース情報を表示できます。必要に応じて、取得モデルを変更し、データ型マッピングを変更できます。
|
注意: 経験豊富なOracle Database管理者以外は、デフォルトのデータ型マッピングを変更しないことをお薦めします。 |
ソース・データベースのオンライン取得を実行する場合は、「Quick Migrate」オプションの一部として自動で実行するか、または個別の操作として実行できます。個別の操作として実行するには、「Connections」ナビゲータで接続名を右クリックし、「Capture product-name」（たとえば、「Capture MySQL」、「Capture Microsoft Access」、「Capture Microsoft SQL Server」など）を選択します。
Microsoft Accessデータベースの場合、「Capture product-name」を選択すると、Microsoft Accessのエクスポータ・ツールが自動的に起動され、スキーマおよび表データを移行するためのXMLファイルが作成されます。 ただし、（特定のオプションを制御する目的などで）エクスポータ・ツールを手動で実行する場合は、「Migration」→「Microsoft Access Exporter」をクリックしてから、使用しているバージョンのMicrosoft Accessの項目をクリックします。エクスポータ・ツールの手順に従います。エクスポータ・ツールには、独自のオンライン・ヘルプがあります。
MySQLまたはMicrosoft SQL Serverデータベースのオフライン取得を実行するには、スクリプト・ファイルを作成し、そのスクリプト・ファイルをSQL Developer以外の場所で実行して変換モデルを作成し、SQL Developerを使用してスクリプトの出力（変換モデルが含まれている.ocpファイル）をロードします。
スクリプト・ファイル（Windowsでは.batファイル、LinuxまたはUNIXでは.shファイル）および関連ファイルを作成するには、「Migration」→「MySQL and SQL Server Offline Capture」→「Create Database Capture Scripts」をクリックします。
この操作が完了すると、いくつかのファイル（.bat、.sql、.ocp）が作成されたことが通知されます。これらのファイルの1つが制御スクリプトです。 制御スクリプトを（SQL Developer以外の場所で）実行し、変換モデルに関する情報をオブジェクト取得プロパティ（.ocp）・ファイルに移入する必要があります。
オフライン取得の制御スクリプトによって生成されたオブジェクト取得プロパティ（.ocp）・ファイルから変換モデルをロードするには、「Migration」→「MySQL and SQL Server Offline Capture」→「Load Database Capture Script Output」をクリックします。
サード・パーティ・データベースを移行する前に、変換モデルを作成する必要があります。変換モデルは、移行先データベースの構造表現です。SQL Developerは、取得モデルの情報を使用して変換モデルを作成します。
デフォルトでは、変換中にすべてのプロシージャ、ファンクション、トリガーおよびビューが変換モデルにコピーされ、Oracle PL/SQLに変換されます。 ただし、変換に失敗したオブジェクトは、変換モデルには表示されますが、その元のSQLコードは変更されないままになります。 元のSQLコードのままであるオブジェクトは、生成スクリプトの作成時に使用されません。 したがって、このようなオブジェクトを移行するには、スクリプトの生成前に元のSQLコードの問題を修正するか、または生成後のスクリプトを編集して元のSQLコードを有効なPL/SQLコードに置換する必要があります。
取得モデルを変換モデルに変換するには、「Captured Objects」ナビゲータで該当するノードを右クリックして「Convert to Oracle」を選択し、データ・マッピングを指定するか、またはデータ・マッピングのデフォルト値を使用します。
移行したデータベースから最高の結果を得るために、変換モデルをカスタマイズしてOracle Database固有の機能（複数の表領域など）を使用できます。ただし、経験豊富なOracle Database管理者以外は、次の項をスキップして2.8の説明に従ってデータベースを移行することをお薦めします。
次の項では、変換モデルの変更が必要になった場合に変換モデルの変更を行う方法について説明します。
進捗画面にParse Exceptionという接頭辞の付いたエラー・メッセージが表示された場合は、関連するスキーマ・オブジェクトが変換モデルに表示されていません。変換モデルを完全なものにするには、次の手順を実行します。
エラーが発生した取得モデルのスキーマ・オブジェクトを書き留めます。
取得モデルのそのスキーマ・オブジェクトを選択します。
取得モデルのスキーマ・オブジェクトのプロパティで、考えられるエラーの原因を調べます。
取得モデルのスキーマ・オブジェクトのプロパティを変更します。
たとえば、ストアド・プロシージャの1行をコメント・アウトします。
モデル名を右クリックし、「Convert to Oracle Model」を選択します。
SQL Developerによって、取得モデルのスキーマ・オブジェクトから変換モデルのスキーマ・オブジェクトの作成が試行されます。
進捗画面が表示されます。
必要に応じて、そのスキーマ・オブジェクトの編集可能なプロパティをすべてコメント・アウトします。これによって、スキーマ・オブジェクトが変換モデル（移行先データベース）に作成されるようになります。移行したスキーマ・オブジェクトは、移行前と同様には動作しませんが、適切な機能を持つ同等のOracleスキーマ・オブジェクトを作成できるようにプレースホルダとしては機能します。
Oracleスキーマ・オブジェクトを作成するDDL文を生成するには、事前に取得モデルを取得し、変換モデルを作成しておく必要があります。DDLを生成した後、DDL文を実行して、Oracle Databaseにオブジェクトを作成します。この時点で、データベース・スキーマがOracleに移行されます。
DDL文を生成および実行してスキーマ・オブジェクトを移行した後、元のソース・データベースからデータを移行できます（2.9を参照）。
DDL文を生成および実行して、移行したデータベースにOracleスキーマ・オブジェクトを作成した後、ソース・データベースからOracle Databaseに既存のデータを移行（移動）できます。データの移行には、オンライン（データをすぐに移動する）およびオフライン（データを後で移動する）の2つのオプションがあります。
オンラインでデータを移動するには、「Migration」→「Migrate Data」をクリックします。ダイアログ・ボックスで、「Source Connection」、「Captured Model」、「Target Connection」および「Converted Model」を指定します。
オフラインでデータを移動するには、「Migration」→「Generate Offline Data Move Scripts」をクリックし、変換モデル、およびSQL*Loaderを使用したソース・データベースからのデータのアンロードとOracleへのインポートに使用するファイルを生成するディレクトリを指定します。
データをオフラインで送信するには、データをソース・データベースから移行先データベースにコピーするスクリプトを生成して使用します。このプロセスでは、次の操作を行う必要があります。
SQL Developerを使用して、ソース・データベース用のデータ・アンロード・スクリプト、および移行先データベース用の対応するデータ・ロード・スクリプトを生成します。
ソース・データベースに適した手順で、データ・アンロード・スクリプトを実行してソース・データベースからデータファイルを作成します。
SQL*Loaderを使用してデータ・ロード・スクリプトを実行し、これらのデータファイルから移行先データベースにデータを移入します（2.9.1.4を参照）。
Microsoft SQL Serverデータベースからデータファイルを作成するには、次の手順を実行します。
ソース・データベースがインストールされているコンピュータに、SQL Developerによってデータ・アンロード・スクリプトが生成されたディレクトリの内容をコピーします。
ソース・データベース・サーバーの名前が含まれるようにBCP抽出スクリプトを編集します。
Windowsの場合は、unload_script.batスクリプトを編集して、適切な変数が含まれるようにbcp行を変更します。
unload_script.batスクリプトの例の1行を次に示します。
bcp "AdventureWorks.dbo.AWBuildVersion" out "[AdventureWorks].[dbo].[AWBuildVersion].dat" -q -c -t "<EOFD>" -r "<EORD>" -U<Username> -P<Password> -S<ServerName>
BCP抽出スクリプトを実行します。
Windowsの場合は、次のとおり入力します。
prompt> unload_script.bat
このスクリプトによって、現行のディレクトリにデータファイルが作成されます。
これらのデータファイルを、SQL Developerによってデータ・アンロード・スクリプトが生成されたディレクトリのoracleサブディレクトリにコピーします。
Microsoft Accessデータベースからデータファイルを作成するには、Exporter for Microsoft Accessツールを使用します。
|
注意: Microsoft Accessデータベースからデータファイルを作成する方法の詳細は、エクスポータ・ツールのオンライン・ヘルプを参照してください。 |
MySQLデータベースからデータファイルを作成するには、次の手順を実行します。
ソース・データベースがインストールされているコンピュータに、SQL Developerによってデータ・アンロード・スクリプトが生成されたディレクトリの内容をコピーします。
データファイルの正しいホスト、ユーザー名、パスワードおよび移行先ディレクトリが含まれるようにunload_scriptスクリプトを編集します。
Windowsの場合は、unload_script.batスクリプトを編集します。
UNIXの場合は、unload_script.shスクリプトを編集します。
unload_script.batスクリプトの例の1行を次に示します。
mysqldump -h <HOST> -u <USERNAME> -p<PASSWORD> -T <DESTINATION_PATH> --fields-terminated-by="<ec>" --lines-terminated-by="<er>" CarrierDb CarrierPlanTb
HOST、USERNAME、PASSWORDおよびDESTINATION PATHに適切な値が含まれるようにこの行を編集します。このファイルの編集時に、山カッコは使用しないでください。
スクリプトを実行します。
Windowsの場合は、次のとおり入力します。
prompt> unload_script.bat
UNIXの場合は、次のとおり入力します。
prompt> chmod 755 unload_script.sh prompt> sh ./unload_script.sh
このスクリプトによって、現行のディレクトリにデータファイルが作成されます。
これらのデータファイルを、SQL Developerによってデータ・アンロード・スクリプトが生成されたディレクトリのoracleサブディレクトリにコピーします。
データファイルを使用して移行先データベースへの移入を行うには、SQL*Loaderでデータ・ロード・スクリプトを実行します。
データ・アンロード・スクリプトを作成したディレクトリに移動します。
移行先データベースがインストールされているコンピュータ上のディレクトリにoracleサブディレクトリの内容をコピーします。
移行先データベースが実行されているコンピュータにログオンします。
SQLロード・スクリプトを実行します。
Windowsの場合は、次のとおり入力します。
prompt> sql_load_script.bat
UNIXの場合は、次のとおり入力します。
prompt> ./sql_load_script.sh
SQL*Loaderを使用してBLOBフィールドへの挿入を行うと、次のエラーが表示されます。
SQL*Loader-309: No SQL string allowed as part of LARGEOBJECT field specification
解決策としては、データ（16進フォーマット）を追加のCLOBフィールドにロードしてから、PL/SQLプロシージャを介してCLOBをBLOBに変換する方法があります。
Microsoft SQL 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
テスト・フェーズでは、アプリケーションおよびOracle Databaseをテストして次のことを確認します。
移行したデータが完全かつ正確であるかどうか
アプリケーションの機能がソース・データベースと同じかどうか
Oracle Databaseで生成される結果がソース・データベースでの結果と同じかどうか
アプリケーションおよびOracle Databaseが操作要件およびパフォーマンス要件を満たしているかどうか
Oracle Databaseのテストに、元のアプリケーションで行われた一連のユニット・テストおよびシステム・テストを使用できる場合があります。これらのテストは、ソース・データベースに対するテストと同じ方法で実行する必要があります。ただし、追加機能に関係なく、アプリケーションがOracle Databaseに接続され、そのアプリケーションから発行されたSQLによって正しい結果が生成されることを確認する必要があります。
|
注意: アプリケーションに対して実行するテストは、アプリケーションの用途によって異なります。アプリケーションで変更される各SQL文は、十分にテストすることをお薦めします。また、システムをテストして、アプリケーションがサード・パーティ・データベースの場合と同様に機能することも確認する必要があります。 |
次の関連項目も参照してください。
データベースに対して実行するテストの種類と量は、多くの制約によって決まります。テストには、次の1つまたはすべてを含めることができます。
簡単なデータ検証
個々のユニット・テストに対応するライフ・サイクル全体のテスト
システム・テストおよび受入れテスト
ユーザーの組織および環境に適したテスト計画に従う必要があります。その計画には、移行したアプリケーションおよびOracle Databaseをテストするプロセスを定義する必要があります。一般的なテスト方法はVモデルです。Vモデルは、データベースの作成で使用される各機能がテスト・フェーズでミラー化される段階的な方法です。
図2-2「データベースの移行で使用するVモデル」に、データベースの移行計画で使用するVモデルの例を示します。
移行プロセスで使用するテストには、複数の種類があります。テスト段階では、複数のサイクルのテストを実行してデータベースの質を向上させます。使用するテスト・ケースで、以前のバージョンのOracle Databaseで発生したいずれの問題も再発していないことを確認する必要があります。
たとえば、移行したスキーマをテスト結果に基づいて変更する必要がある場合は、新しいバージョンのOracle Databaseスキーマの作成が必要になることがあります。実際には、テストの開始時にSQL Developerを使用してベースラインとなるOracleスキーマを作成し、テストの進捗に合わせてこのスキーマを編集します。
|
注意: テスト・サイクルで検出された問題は、問題追跡システムで追跡することをお薦めします。テスト用バージョンのデータベースまたはアプリケーションに対して、これらの問題を追跡してください。 |
テスト・ケースを使用して、Oracle Databaseでのビジネス・ロジックの結果がソース・データベースでの結果と同じであることを検証します。
|
注意: 移行が正常に実行されたかどうかを判断できるように達成基準を定義することをお薦めします。 |
次の手順では、移行したデータベースをテストする1つの方法について説明します。他の方法も使用可能であり、業務要件によっては他の方法のほうが適している場合もあります。
Oracle Databaseをテストするには、次の手順を実行します。
移行したデータベースのテスト用バージョンを作成します。
データベースの移行スクリプトは、ソースの制御システムに保存することをお薦めします。
Oracle Databaseに対するユニット・レベルからシステム・レベルまでのテストに使用する一連のテスト・ケースを計画します。テスト・ケースでは、次のことを実行する必要があります。
次の項目を確認します。
ソース・データベースのすべてのユーザーが正常に移行されたかどうか
ユーザーに対する権限付与が適切かどうか
表の構造が正しいかどうか、デフォルトで正常に機能しているかどうか、およびマッピング時または生成時にエラーが発生しなかったかどうか
次の方法を使用して、データが正常に移行されたことを確認します。
Oracle Databaseの行数とソース・データベースの行数を比較
Oracle Databaseの数値列の合計を計算し、ソース・データベースの数値列の合計と比較
次の条件が制約に適用されていることを確認します。
重複する主キーは入力できない
外部キーによって、一貫性のないデータ入力が防止される
チェック制約によって、無効なデータ入力が防止される
索引および順序が正常に作成されていることを確認します。
次の方法を使用して、ビューが正常に移行されたことを確認します。
Oracle Databaseの行数とソース・データベースの行数を比較
Oracle Databaseの数値列の合計を計算し、ソース・データベースの数値列の合計と比較
トリガー、プロシージャおよびファンクションが正常に移行されたことを確認します。トリガーおよびファンクションに対して、適切な値が戻されることを確認します。
移行したデータベースに対して、テスト・ケースを実行します。
テスト・ケースの結果を評価するレポートを作成します。
これらのレポートを使用すると、データを評価してエラーを限定したり、問題レポートを保存したり、顧客に対してデータベースのテスト用バージョンを提供できます。
テストを通過した場合は、手順7に進みます。
テスト・ケースのすべての評価基準が満たされているか、または発生しているエラーが許容可能な場合、テストを通過できます。許容可能なエラーが発生した場合は、それらをエラー・レポートに記録して、監査の目的で使用できるようにします。
テスト・ケースでエラーが発生した場合は、次の作業を実行します。
エラーの原因を特定します。
エラーの確認に必要なテスト・ケースを特定します。
問題レポートに、テスト用バージョンの移行済データベース・コードでの問題を記録します。
ユーザーの組織で使用されている問題追跡システムに、テスト・ケースおよび問題の説明を追加します。問題追跡システムは、スプレッドシートでも、不具合のレポート・システムでもかまいません。インシデント・ログには、テスト・ケース以外に次の内容を含めます。
発生した問題についての明快で簡潔な説明
環境の詳細な説明（プラットフォーム、ソースの制御バージョンなど）
テストの出力（役に立つ場合）
問題の発生頻度および予測可能性
問題が発生するまでのイベントの順序
現行のテストでの影響、実行した診断手順および要注意の結果
後で現れる永続的な影響（存在する場合）
エラーの修正を試行します。
手順1に戻ります。
Oracle Databaseの品質が許容レベルであることを確認するために使用可能な受入れテストを指定します。
Oracle Databaseのテストに、元のアプリケーションで行われた一連のユニット・テストおよびシステム・テストを使用できる場合があります。ただし、ユニット・テストおよびシステム・テストがない場合は作成する必要があります。テスト・ケースを作成する場合は、次のガイドラインに従います。
テスト・ケースを計画、指定および実行して、その結果を記録します。
実行するテストの量は、その移行プロジェクトで使用可能な時間およびリソースに比例します。通常、移行プロジェクトのテスト・フェーズでは、プロジェクト全体の40%から60%の労力が想定されます。
テストの対象となるコンポーネント、テスト計画の方法およびテストの達成基準を指定します。
各テスト・ケースを再現できるように定義します。
再現できないテストは、問題の追跡または監査プロセスでは使用できません。
ソース・データベースをファンクションとプロシージャに分割し、それぞれに対してテスト・ケースを作成します。テスト・ケースでは、テストする内容を明確にし、テスト基準を定義し、予想される結果を記述します。
各テスト・ケースでの予想される結果を記録します。
各テストで、実際の結果が予想される結果と一致しているかどうかを検証します。
予想される結果が肯定的なテスト・ケースのみでなく、結果が否定的なテスト・ケースも定義します。
Windowsでのユニット・テスト計画の例を次に示します。
名前 Jane Harrison
モジュール Table Test Emp
テストの完了日 2007年5月23日
対象とするログ・ファイルの位置 mwb\database\TableTestEmp
説明 このユニット・テストでは、emp表が正常に移行されたことをテストします。
確認者 John Smith
| タスクID | タスクの説明 | 予想される結果 | 確認済（はい/いいえ） |
|---|---|---|---|
| 1 | ソース・データベースの各表に対して次の文を実行します。
移行先データベースの各表に対して次の文を実行します。
|
ソース・データベースでは、count(*)によって数値が生成されます。この場合、生成される数値は各表の行数です。
移行先データベースでは、count(*)の数値は新しいOracle表の行数に対応します。 |
はい
各表の行数は、ソース・データベースと移行先データベースで同じになります。 |
| 2 | ソース・データベースの各表に対して次の文を実行します。
移行先データベースの各表に対して次の文を実行します。
|
ソース・データベースでは、sum(salary)によって各表のデータの合計に対するチェックサムが算出されます。
移行先データベースでは、sum(salary)はemp表のsalaryの合計に対応します。 |
はい
各表の合計は、ソース・データベースと移行先データベースで同じになります。 |
移行およびテスト済のOracle Databaseを業務環境内にデプロイする場合、困難が伴うことがあります。そのため、環境に応じて、別のロールアウト方法の検討が必要になる場合があります。いくつかのロールアウト方法を示しますが、組織で推奨されている方法がある場合はその方法を使用できます。
デプロイメント・フェーズでは、移行先データベースを開発環境から本番環境に移動します。移行およびテスト・チームとは別のグループ（組織内のIT部門など）がデプロイメント・フェーズを担当する場合があります。
デプロイメントでは、次の作業を行います。
サード・パーティ・データベースからOracle Databaseに移行する場合に使用する計画では、移行期間中に影響を受ける可能性があるユーザーおよび業務の種類について考慮する必要があります。たとえば、ソース・データベースおよびOracle Databaseを同時に実行するための十分なシステムがない場合は、ビッグ・バン・アプローチを使用できます。また、システムを一般のユーザーに開放する前に、そのシステムがユーザー環境で正常に動作することを確認する場合は、段階的アプローチを使用できます。次のいずれかの方法を使用できます。
段階的アプローチを使用すると、ユーザー・グループを異なるタイミングで移行できます。1つの部門またはユーザー・ベース全体の一部を移行することができます。選択するユーザーは、ユーザー・ベース全体の一部を代表するユーザーである必要があります。この方法を使用すると、Oracle Databaseへのユーザーの導入時に、ユーザーをプロファイルできます。選択したユーザーのみが移行の影響を受け、一部のユーザーのみがスケジューリングされていない停止の影響を受けるように、システムを再構成できます。この方法は、移行したユーザーの作業に影響を与える場合があります。ただし、ユーザー数が限られているため、サポート・サービスが問題によってオーバーロードされることはありません。
段階的アプローチを使用すると、移行ユーザー数の増加に伴い発生するスケーラビリティの問題をデバックできます。ただし、この方法を使用すると、移行時にレガシー・システムとの間でデータを移行する必要がある場合があります。アプリケーションのアーキテクチャでは、段階的アプローチがサポートされている必要があります。
ビッグ・バン・アプローチを使用すると、すべてのユーザーを同時に移行することができます。この方法では、古いシステムの削除中、データの移行中、Oracleシステムのデプロイ中、およびシステムが正常に動作しているかどうかのテスト中に、スケジューリングされた停止が発生する場合があります。この方法では、元のデータベースと同じ規模のデータベースをテストする必要があります。この方法では、データベースをオフラインにするため、元のデータベースとのデータ変換および同期化を最小限に抑えることができるというメリットがあります。デメリットは、Oracle Databaseのインストールおよびその他の移行プロジェクト・タスクの実行にスイッチオーバー期間が必要なため、労力がかかり、業務に悪影響を与える可能性があることです。
パラレル・アプローチを使用すると、ソース・データベースと移行先のOracle Databaseの両方を同時に保持できます。アプリケーションが本番環境でソース・データベースおよび移行先データベースに対して同じように動作するかを確認するには、両方のデータベースにデータを入力し、データの結果を分析します。この方法のメリットは、移行先データベースで問題が発生した場合に、ユーザーがソース・データベースの使用を継続できることです。パラレル・アプローチのデメリットは、ソース・データベースと移行先データベースの両方を実行して保持するために、他の方法より多くのリソースとハードウェアが必要になる場合があることです。
移行先データベースをデプロイするには、いくつかの方法があります。移行先データベースをデプロイする際のガイドラインとして使用するタスクの例を次に示します。
|
注意: 複雑な計画（表2-1を参照）の場合は、すべてのデプロイメント・タスクを完了することをお薦めします。ただし、単純な計画の場合は、所属する組織に適したデプロイメント・タスクを選択する必要があります。 |
必要に応じて、ハードウェアを構成します。
大規模な環境または複雑な環境では、データベース設計に対応するようにディスクのレイアウトを設計する必要があります。冗長ディスクを使用する場合は、移行先データベースの増大に伴って増加できるように冗長ディスクをストライプ化します。必要なディスクを設置および構成して、メモリーを確認し、システムを構成する必要があります。
オペレーティング・システムがOracle構成のパラメータに対応していることを確認します。
Oracleソフトウェアをインストールする前に、すべてのシステム・パラメータが変更されていることを確認します。システム・パラメータの変更の詳細は、ご使用のプラットフォーム（Solarisオペレーティング・システムなど）のインストレーション・ガイドを参照してください。
Oracleソフトウェアをインストールします。
Oracle Databaseの作成のために使用するOracleソフトウェア以外に、アプリケーションをサポートする付属のソフトウェア（データ・ウェアハウスのExtract Transformation and Load（ETL）ソフトウェアなど）のインストールが必要になる場合があります。
ソース・データベースから移行先データベースを作成し、Oracle Databaseにデータを移行します。
移行先データベースを、テストした後に本番環境に配置するには、次のいくつかの方法があります。
テストが正常に完了したデータベースを本番環境に配置します。この時点で、テスト・システムが本番システムになります。
Oracle Exportを使用して、テストが正常に完了したデータベースから移行先データベースを抽出し、Oracle Importを使用してそのデータベースを本番環境内に作成します。
テスト済の移行スクリプトを使用してOracle Databaseを作成し、SQL*Loaderを使用してそのOracle Databaseにデータを移入します。
移行先データベースおよびアプリケーションで最終確認を行います。
いずれかのロールアウト方法を使用して、移行先データベースを本番環境に配置します。
次のことを実行して、最終監査を行います。
データ整合性の監査
プロセス（バックアップやリカバリなど）の妥当性の監査
プロジェクトのサインオフの取得（必要な場合）
SQL Developerでは、いくつかのレポートに、サード・パーティ・データベースからOracleへの移行を目的とした操作の実行時に取得、変換および生成されたオブジェクトに関する情報が提供されます。 各レポートでは、選択した移行リポジトリからの情報が使用されます。 これらのレポートは、「Reports」ナビゲータに表示されます。表示するには、「Shared Reports」→「Migration Workbench Reports」をクリックします。
Capture Summary: 各取得モデルおよびその取得日が表示されます。
Automatic Name Changes: 変換モデルの生成時に自動的に行われた名前の変更が表示されます。
Converted Summary: 各変換モデルおよびその変換日が表示されます。
Migration Dependency: 移行オブジェクト間の依存性に関する情報が表示されます。
データベースの移行を実行する場合は、1.2「SQL Developerユーザー・インタフェース」で説明されている機能に加えて、移行に固有のいくつかの機能を使用する必要があります。ユーザー・インタフェースには、いくつかのナビゲータ・タブとペイン（「Captured Objects」と「Converted Objects」）および「Migration」メニューが追加され、インタフェース全体に小さな変更が多数行われています。図2-3「データベースの移行のためのメイン・ウィンドウ」に、sales.mdbというMicrosoft Accessアプリケーションの移行を反映するオブジェクトが表示された、SQL Developerのメイン・ウィンドウを示します。
この図の内容を次に示します。
「Connections」ナビゲータには、3つのデータベース接続が表示されています。migration_repositoryは移行リポジトリに使用される（ユーザーMIGRATIONへの）接続、sales_accessはMicrosoft Accessデータベースsales.mdbへの接続、sales_oracleは移行されたスキーマ・オブジェクトを所有するスキーマを持つOracleユーザーSALESへの接続です。
「Captured Objects」ナビゲータには、1つの取得モデルが表示されています。この取得モデルは、Accessアプリケーションのエクスポータ・ツールによって作成されたXMLファイルを使用して作成されています。（ソース・データベースのタイプがMicrosoft Access以外の場合、取得モデルの作成手順は異なります。この場合は、ソース・データベース接続から取得モデルを直接生成できます。）
「Converted Objects」ナビゲータには、ソース・データベースのOracle表現である変換モデルが1つ表示されています。取得モデルから変換モデルが作成され、その変換モデルを使用してスキーマ・オブジェクトが生成されます。スキーマ・オブジェクトは、Oracle Database接続（この図ではsales_oracle）を使用して表示できます。
「Migration」メニューには、Oracleへのサード・パーティ・データベースの移行に関連するオプションが含まれています。
Quick Migrate: 多数のデフォルト値を使用してクイック移行を実行するためのダイアログ・ボックスが表示されます。
Repository Management: 移行リポジトリの作成、削除、切捨て（すべてのデータの削除）、現行の移行リポジトリの選択、および現行の移行リポジトリへの接続の切断（現行のリポジトリは無効になるがデータベースへの接続は切断されない）を行うことができます。
Microsoft Access Exporter: 取得モデルの作成に使用されるXMLファイルの作成に使用するエクスポータ・ツールのバージョンを指定するためのサブメニュー項目が含まれています。エクスポータ・ツールは、表データのエクスポートにも使用できます。PC上のAccess、および.mdbファイルの作成に使用されたAccessのバージョンに対応するエクスポータ・ツールのバージョンを指定します。
Migrate Data: ソース・データベースからOracleスキーマへの表データのオンライン移行を実行するためのダイアログ・ボックスが表示されます。
Script Generation: 「Generate Oracle DDL」によって、SQLワークシート・ウィンドウにDDL（データ定義言語）文が表示されます。このウィンドウで、スクリプトを実行してOracleスキーマおよびスキーマ・オブジェクトを作成できます。「Generate Data Move Scripts」によって、ソース・データベースからOracleスキーマへの表データのオフライン移行を実行するための、ファイルの作成場所を指定するダイアログ・ボックスが表示されます。
Capture Microsoft Access Exporter XML: エクスポータ・ツールによって作成されたXMLファイルからMicrosoft Accessデータベースの取得モデルが作成されます。
MySQL and SQL Server Offline Capture: 「Create Database Capture Scripts」によって、オフライン取得プロパティ（.ocp）・ファイルを作成するためのオプションが指定されます。このファイルは、後でロードして実行できます。「Load Database Capture Script Output」によって、ロードして実行するスクリプトを選択できます。
Script Generation: 「Generate Oracle DDL」によって、Oracle DDLを生成する対象となる変換モデルが指定されます。また、オフライン生成に使用するSQL*Plusスクリプト・ファイルが生成されます（このスクリプトを実行すると、Oracle Databaseに適切なオブジェクトを作成できます）。オフラインでデータ移行を実行する場合は、「Generate Data Move Scripts」によって変換モデルおよび移行先ディレクトリが指定されます。
Translation Scratch Editor: 変換スクラッチ・エディタ（2.13.5を参照）が表示されます。
「View」メニューには、データベースの移行に関連する次の項目があります。
Captured Objects: 「Captured Objects」ナビゲータが表示されます。
Converted Objects: 「Converted Objects」ナビゲータが表示されます。
（「Tools」→「Preferences」をクリックすると表示される）SQL Developerユーザー・プリファレンス・ウィンドウには、「Migration」ペインといくつかの関連サブペイン、および「Translation」ペインと「Translation Preferences」サブペインが含まれています。
これらのプリファレンスの詳細は、ペインで「Help」をクリックするか、または1.12.9「Migration」を参照してください。
Migration Log: 移行操作に関連するエラー、警告および情報メッセージが含まれています。
Logging Page: 移行に関連する各操作のエントリが含まれています。
Data Editor Log: SQL Developerによってデータが操作されている場合のエントリが含まれています。 たとえば、Microsoft Excelのインポート操作での出力は、一連のINSERT文としてここにレポートされます。
変換スクラッチ・エディタを使用すると、入力したサード・パーティ・データベースのSQL文をOracle PL/SQL文に変換できます。T-SQLからPL/SQLへの変換、またはMicrosoft Access SQLからPL/SQLへの変換を指定できます。
「Migration」→「Translation Scratch Editor」をクリックすると、スクラッチ・エディタを表示できます。 スクラッチ・エディタは、次の図に示すように、隣り合う2つのSQLワークシート・ウィンドウで構成されています。
ある文をOracleでの同等文に変換するには、変換のタイプ（「Access SQL to PL/SQL」または「T-SQL to PL/SQL」）を選択し、サード・パーティのSQL文を入力してから「Translate」アイコン（>>）をクリックして、生成されたPL/SQL文を表示します。
複数の文の場合、PL/SQL以外の各文は、セミコロンまたは（改行後の）スラッシュ（/）のいずれかで終了する必要があります。各PL/SQL文は、改行後にスラッシュ（/）で終了する必要があります。SQLキーワードは、自動的にハイライト表示されます。
変換スクラッチ・エディタでいずれかのワークシート・ウィンドウの内容を初めて保存する場合は、ファイルの場所と名前の入力を求められます。 以降の「Save」操作では、（ウィンドウの内容を削除したか変更したかに関係なく）ウィンドウの内容は同じファイルに保存されます。 別のファイルに内容を保存するには、「File」→「Save As」をクリックします。
ワークシート・ウィンドウの詳細は、1.7「SQLワークシートの使用」を参照してください。
