| Oracle Database SQL Developerユーザーズ・ガイド リリース1.1.2 E05698-01 |
|
 戻る |
 次へ |
|
注意: 移行に関する情報は、サード・パーティ・データベースからOracleへの移行をサポートしているバージョンのSQL Developerを使用している場合にのみ適用されます。 移行のサポートは、現在、SQL Developerリリース1.2で導入される予定です。 |
移行とは、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接続を右クリックし、「Manage Migration Repository」を選択して、リポジトリを作成します。
Oracleユーザーを作成してそのユーザーのスキーマをオブジェクトの移行先として使用するか、または既存のOracleユーザーおよびスキーマを使用します。このユーザーには十分な権限を付与します。
たとえば、sales.mdbというMicrosoft Accessデータベースを移行するには、OracleユーザーSALESを作成して、このユーザーのスキーマにOracle Databaseオブジェクトを生成します。
前述の手順で作成または選択したスキーマにOracle接続を作成してオープンします。
たとえば、SALESというユーザーに関連付けられたスキーマに、Sales_MigratedというOracle接続を作成して接続します。
サード・パーティ・データベースへのデータベース接続を作成してオープンします。
たとえば、sales.mdbというMicrosoft Accessデータベースへのデータベース接続Sales_Accessを作成して接続します。
移行するソース・スキーマ・オブジェクトを取得します。 Microsoft Accessデータベースを移行するか、別のタイプのデータベースを移行するかによって、手順が異なります。
Microsoft Accessの移行の場合、エクスポータ・ツールを実行します。「Migration」→「Microsoft Access Exporter」をクリックして、使用しているバージョンのMicrosoft Accessの項目をクリックします。エクスポータ・ツールの手順に従います。エクスポータ・ツールには、独自のオンライン・ヘルプがあります。 次に、SQL Developerで、「Migration」→「Capture Exporter XML」をクリックし、エクスポータ・ツールを使用して作成したXMLファイルを指定します。
その他のサード・パーティ・データベースの移行の場合、「Connections」ナビゲータで接続名を右クリックし、「Capture product-name」（たとえば、「Capture MySQL」、「Capture Microsoft SQL Server」など）を選択します。
取得が終了すると、「Captured Objects」ナビゲータに、取得したオブジェクトの展開可能なノードが表示されます（たとえば、2.13「移行に使用するSQL Developerユーザー・インタフェース」の図に示されているように、sales.mdbというオブジェクトを取得した場合は、sales (Access) と表示されます）。
取得したオブジェクトをOracle形式のオブジェクトに変換します。「Captured Objects」ナビゲータで適切なノードを右クリックし、「Convert to Oracle」を選択して、データ・マッピングを指定するか、デフォルトのデータ・マッピングを使用します。
変換が終了すると、「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_Migratedなど）を切断し、再接続します。「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を使用して、自動化が可能な作業および手動で行う作業の量を計算して決定します。
ワークロードを見積もるには、次の手順を実行します。
取得モデルの取得、変換モデルの作成、および移行先データベースへの移行を行います。
取得モデルを使用してソース・データベースを分析し、変換モデルを使用して移行先データベースのプレビューを分析することができます。ソース・データベースを取得した後で、取得モデルおよび変換モデルに含まれている取得データを分析します。移行リポジトリの内容と構造が正しいことを確認し、プロセス全体にかかる時間を判断します。
レポートを生成および使用して、取得プロセスおよび移行プロセスの評価、データベース・オブジェクトの合計数の分類、および自動的に変換かつ移行可能なオブジェクトの数の確認を行います。
サマリー、詳細、エラーおよび警告のレポートでは、実行されたアクションに関する情報が提供され、警告およびエラーが記録されます。警告およびエラーによって、変換モデルに対して行われた変更が特定されるため、移行先データベースにアクセスするアプリケーションに対して変更を行う必要があるかどうかを評価できます。
発生した問題を評価および分類します。 レポートには、次のものについての有効な情報が提供されます。
ソース・データベースの取得時にロードされなかった表
変換モデルの作成時に解析されなかったストアド・プロシージャ、ビューおよびトリガー
手動操作が必要な構文
移行先データベースへの移行時に正常に作成されなかったデータベース・オブジェクト
移行先データベースへの移行時に正常に移行されなかったデータ
レポート内の各エラーまたは警告に対して、次の項目を評価します。
問題が発生した回数
問題の修正に必要な時間（工数）
問題の修正に必要なリソースの数
複雑な問題を解決した後、次に同様の問題が発生した場合は、より簡単かつ迅速にその問題を解決できるようになります。
これらのレポートを使用して各エラーを評価し、修正にかかる時間を判断します。 これらのレポートは、作成されたデータベースのサイズを確認するのに役立ちます。
このタスクでは、次の手順を実行して操作要件を分析します。
ソース・データベースを移行先データベースに移行する場合の操作上の考慮点について検討します。次の項目を確認します。
必要なバックアップおよびリカバリの変更
移行時に必要な停止時間
パフォーマンス要件に適合しているかどうか
操作時間枠を変更するかどうか
停止時間が業務に与える影響
トレーニング要件、または従業員に関する追加の考慮点
サード・パーティ・データベースと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 password
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 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
たとえば、次のコマンドを使用すると、データベースの移行に最小限必要な権限を持つmigrationsというユーザーを作成できます。
CREATE USER migrations IDENTIFIED BY password
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;
Microsoft Windowsシステムで、マルチバイト・キャラクタ・セット用などの非標準文字エンコーディングを使用するようにSQL Developerを構成する必要がある場合は、次の手順を実行します。
JREファイルのエンコーディング・プロパティを設定します。
テキスト・エディタを使用して、OMWB_install_dir/Omwb/binディレクトリに格納されているomwb.batファイルを編集し、SQL Developerの起動ファイルを開きます。
startコマンドの-jarの前に次の情報を追加します。
-Dfile.encoding="file_encoding"
前述の行のfile_encoding は、必要なファイル・エンコーディングです。 マルチバイトのMicrosoft Accessデータベースの場合、ファイル・エンコーディングをUTF-8に設定する必要があります。omwb.batファイルは次のようになります。
start ..\jre\bin\javaw -ms30m -mx256m -Dfile.encoding="UTF-8" -jar ..\lib\boot.jar oracle.mtg.migrationUI.MigrationApp
マルチバイトのMicrosoft Accessデータベース（日本語、中国語など）を移行する場合、移行先のOracle Databaseインスタンスのキャラクタ・セットをUTF-8に設定する必要があります。
ファイルを保存し、終了します。
必要なファイル・エンコーディング用の適切なfont.propertiesファイルをインストールします。
OMWB_install_dir/Omwb/jre/libディレクトリにある既存のfont.propertiesファイルをバックアップします。
次のWebサイトから必要なJava font.propertiesファイルをダウンロードします。
http://www.sun.com/
ダウンロードしたファイルの名前をfont.propertiesに変更します。たとえば、日本語のfont.propertiesファイルの名前をfont.properties.jaからfont.propertiesに変更します。
新しいfont.propertiesファイルをOMWB_install_dir/Omwb/jre/libディレクトリにコピーします。
オフライン取得を実行する場合、オフライン取得スクリプトにデリミタ文字を指定する必要があります。
テキスト・エディタを使用して、OMWB_install_dir/Omwb/binディレクトリに格納されているomwb.propertiesファイルを開きます。
次のフィールドを編集または追加します。
OFFLINE_CAPTURE_COLUMN_DELIMITER="delimiter_column" OFFLINE_CAPTURE_ROW_DELIMITER="delimiter_row"
前述の行のdelimiter_column はユーザーが指定する列デリミタ、delimiter_row はユーザーが指定する行デリミタです。
|
注意: これらのデリミタ値は、オフライン取得スクリプトに使用されているデリミタ値と一致している必要があります。 |
ファイルを保存し、終了します。
これで、SQL Developerで新しい文字エンコーディングを処理できます。
Oracle Databaseに移行するサード・パーティ・データベースによっては、接続情報を構成し、ドライバをインストールする必要がある場合があります。サード・パーティ・データベースに固有の要件の詳細は、次の項を参照してください。
Microsoft SQL Serverデータベースを移行用に構成するには、次の手順を実行します。
SQL Developerで使用されるMicrosoft SQL Serverユーザーがソース・データベースにアクセス可能であることを確認します。このユーザーには、Microsoft SQL Serverデータベースに対するDBA権限が必要です。
SQL DeveloperがインストールされているシステムからMicrosoft SQL Serverデータベースに接続できることを確認します。
SQL Developerと同じシステム上に、リリース3.70.06.23以上のMicrosoft SQL Server ODBCドライバをインストールします。
Microsoft SQL Server ODBCドライバは、Microsoft SQL Serverクライアント・ソフトウェアに付属しています。 インストール手順は、Microsoft SQL Serverのバージョンによって異なります。 Microsoft SQL Server ODBCドライバの詳細は、Microsoft SQL Server固有のドキュメントを参照してください。
Oracle ODBCデータソースは、データソース名（DSN）の設定に使用されます。 DSNはユーザー・レベルまたはシステム・レベルで作成できます。
「スタート」オプションから、「設定」→「コントロール パネル」を選択します。
「コントロール パネル」ウィンドウが表示されます。
Microsoft Windows 2000を使用している場合は、「管理ツール」アイコンを選択します。
「データ ソース (ODBC)」アイコンを選択します。
「ODBC Data Source Administrator」ダイアログ・ボックスが表示されます。
「User DSN」タブで、「Add」をクリックします。
「Oracle New Data Source」ダイアログ・ボックスが表示されます。
「SQL Server」を選択し、「完了」をクリックします。
「SQL Server に接続するための新規データ ソースを作成する」ダイアログ・ボックスが表示されます。
「名前」フィールドにデータソースの名前を入力します。
接続するSQL Serverデータベースをドロップダウン・リストから選択するか、または入力した後、「次へ」をクリックします。
ログインIDの認証を確認して、「次へ」をクリックします。
オプションを確認して、「次へ」をクリックします。
「次へ」をクリックします。
「完了」をクリックします。
「ODBC Microsoft SQL Server セットアップ」ページが表示されます。
「データ ソースのテスト」オプションをクリックして、ODBC接続が正しく設定されていることを確認し、「OK」をクリックします。
接続に失敗した場合は、手順dに戻り、接続の詳細を変更します。
「OK」をクリックします。
これで、DSN接続が作成されました。
Microsoft Accessデータベースを移行用に構成するには、次の手順を実行します。
データベース・ファイルのバックアップを作成します。
必要なソフトウェア（Microsoft Access、Microsoft ODBCドライバ、Microsoft Data Access Objectおよびその他のコンポーネント）がSQL Developerと同じシステムにインストールされていることを確認します。
セキュリティが有効になっている場合は、次の手順を実行して、保護されたデータベースの内容を新しいデータベースにコピーすることによってセキュリティを無効にする必要があります。
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ツールを使用する必要があります。このツールは、Microsoft Access MDEファイルとしてパッケージ化されています。このツールを使用して、Microsoft Access MDBファイルをXMLファイルにエクスポートできます。選択したMicrosoft Accessデータベースでリンク・テーブルを使用している場合は、そのリンク・テーブルのスキーマ情報もXMLファイルにエクスポートされます。
Microsoft AccessデータベースをXMLファイルにエクスポートするには、次の手順を実行します。
「Migration」→「Microsoft Access Exporter」をクリックし、使用しているリリースのMicrosoft Accessの「Run」オプションをクリックします。
エクスポータ・ツールのインタフェースが表示されます。
最初に表示されるダイアログ・ボックスの指示に従います。 エクスポータ・ツールの使用方法の詳細を表示するには、「Help」ボタンをクリックしてください。
|
注意: エクスポータによって作成されたファイルは変更しないでください。 |
選択した各Microsoft AccessデータベースがXMLファイルにエクスポートされます。エクスポータ・ツールでは、現在、保護されたデータベースまたはレプリカ・データベースからのXMLファイルの作成はサポートされていません。
MySQLデータベースを移行用に構成するには、次の手順を実行します。
SQL Developerをインストールしたシステムに、MySQLConnector/Jリリース3.0をインストールします。
次に示すMySQLのWebサイトから、MySQLConnector/J APIをダウンロードします。
http://www.mysql.com/
mysql-connector-java-3.x.xx-stable.zipファイルを解凍します。
comサブディレクトリを使用して、解凍したファイルを圧縮します。
|
注意: zipファイルにcomというパス名で始まるパス情報が含まれていることを確認します。 |
zipファイルの名前を次のように変更します。
mysql-connector-java.zip
mysql-connector-java.zipファイルを次のディレクトリにコピーします。
Windowsの場合は、次のディレクトリにコピーします。
OMWB_install_dir\Omwb\drivers
UNIXの場合は、次のディレクトリにコピーします。
OMWB_install_dir/Omwb/drivers
rootユーザーがMySQLデータベースにアクセスできることを確認します。 このユーザーにはデータベース管理権限が必要です。
サード・パーティ・データベースを移行する前に、データベースから情報を抽出する必要があります。この情報は、ソース・データベースの構造表現であり、取得モデルと呼ばれます。データベースから情報を抽出するプロセスは、ソース・データベースの取得と呼ばれます。
ソース・データベースを取得するには、ソース・データベースのタイプに応じて次のいずれかの手順を実行します。
Microsoft Accessの移行の場合、エクスポータ・ツールを実行します。「Migration」→「Microsoft Access Exporter」をクリックして、使用しているバージョンのMicrosoft Accessの項目をクリックします。エクスポータ・ツールの手順に従います。エクスポータ・ツールには、独自のオンライン・ヘルプがあります。 次に、SQL Developerで、「Migration」→「Capture Exporter XML」をクリックし、エクスポータ・ツールを使用して作成したXMLファイルを指定します。
その他のサード・パーティ・データベースの移行の場合、「Connections」ナビゲータで接続名を右クリックし、「Capture product-name」（たとえば、「Capture MySQL」、「Capture Microsoft SQL Server」など）を選択します。
ソース・データベースの取得後、SQL Developerの取得モデルにソース・データベース情報を表示できます。必要に応じて、取得モデルを変更し、データ型マッピングを変更できます。
|
注意: 経験豊富なOracle Database管理者以外は、デフォルトのデータ型マッピングを変更しないことをお薦めします。 |
サード・パーティ・データベースを移行する前に、変換モデルを作成する必要があります。変換モデルは、移行先データベースの構造表現です。SQL Developerは、取得モデルの情報を使用して変換モデルを作成します。
取得モデルを変換モデルに変換するには、「Captured Objects」ナビゲータで該当するノードを右クリックして「Convert to Oracle」を選択し、データ・マッピングを指定するか、またはデータ・マッピングのデフォルト値を使用します。
移行したデータベースから最高の結果を得るために、変換モデルをカスタマイズしてOracle Database固有の機能（複数の表領域など）を使用できます。ただし、経験豊富なOracle Database管理者以外は、次の項をスキップして2.8の説明に従ってデータベースを移行することをお薦めします。
次の項では、変換モデルの変更が必要になった場合に変換モデルの変更を行う方法について説明します。
進捗画面にParse Exceptionという接頭辞の付いたエラー・メッセージが表示された場合は、関連するスキーマ・オブジェクトが変換モデルに表示されていません。変換モデルを完全なものにするには、次の手順を実行します。
エラーが発生した取得モデルのスキーマ・オブジェクトを書き留めます。
取得モデルのそのスキーマ・オブジェクトを選択します。
取得モデルのスキーマ・オブジェクトのプロパティで、考えられるエラーの原因を調べます。
取得モデルのスキーマ・オブジェクトのプロパティを変更します。
たとえば、ストアド・プロシージャの1行をコメント・アウトします。
「Object」メニューから、「Parse」を選択します。
|
注意: 「Parse」オプションは、変換モデルを作成してから使用可能になります。 |
SQL Developerによって、取得モデルのスキーマ・オブジェクトから変換モデルのスキーマ・オブジェクトの作成が試行されます。
進捗画面が表示されます。
必要に応じて、そのスキーマ・オブジェクトの編集可能なプロパティをすべてコメント・アウトします。これによって、スキーマ・オブジェクトが変換モデル（移行先データベース）に作成されるようになります。移行したスキーマ・オブジェクトは、移行前と同様には動作しませんが、適切な機能を持つ同等のOracleスキーマ・オブジェクトを作成できるようにプレースホルダとしては機能します。
変換モデルをカスタマイズして、計画フェーズで指定したOracle機能を利用できます。 たとえば、変換モデルを次のように変更できます。
変換モデルのスキーマ・オブジェクトのプロパティを変更するには、「Converted Objects」ナビゲータで変換モデルの表示を開いて、オブジェクトを選択し、そのオブジェクト・タイプ（表、プロシージャなど）のインタフェースと方法を使用して必要な編集を行います。
Oracle Databaseは、表領域と呼ばれる1つ以上の論理的な記憶域の単位で構成されています。表領域には、データベースのすべてのデータがまとめて格納されています。 表領域の詳細は、『Oracle Database概要』を参照してください。
SQL Developerのデフォルトの表領域設定では不十分である場合は、表領域の作成、名前の変更、既存の表領域へのオブジェクトの再割当てを行うことができます。
SQL Developerでは、変換モデルの作成時に自動的に表領域が作成されます。 この機能が動作しないようにするには、「Options」ダイアログ・ボックスの「General」ページで「Automatically Create Tablespaces During converted model Creation」オプションの選択を解除します。
SQL Developerでは、ソース・データベースからパスワードを復号化できないため、変換モデルのすべてのユーザーにoracleというパスワードが割り当てられます。 このパスワードを変更しない場合は、移行先データベースのすべてのユーザーのパスワードもoracleになります。 ユーザーのパスワードを変更する場合は、変換モデルでそのユーザーを選択し、「User」プロパティ・シートでパスワードを必要な値に変更します。
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またはSybase Adaptive Serverデータベースからデータファイルを作成するには、次の手順を実行します。
|
注意: Sybase Adaptive Server for Linux x86のデフォルトのデリミタは、UTF-8エンコーディング・ファイルを使用すると機能しません。 そのため、LANG変数がen_US.UTF-8に設定されている場合、LANG変数をen_USに設定してデフォルトをISO-8859-1にする必要があります。 |
ソース・データベースがインストールされているコンピュータに、SQL Developerによってデータ・アンロード・スクリプトが生成されたディレクトリの内容をコピーします。
ソース・データベース・サーバーの名前が含まれるようにBCP抽出スクリプトを編集します。
Windowsの場合は、bcp_extract.batスクリプトを編集して、適切な変数が含まれるようにisql行を変更します。
UNIXの場合は、bcp_extract.shスクリプトを編集して、適切な変数が含まれるようにisql行を変更し、次のコマンドを追加します。
chmod 755 bcp_extract.sh
bcp_extract.batスクリプトの例の一部を次に示します。
isql -Usa -P -S<SERVER NAME> -iCreate_View.sql bcp pubs.dbo].[authors out AUTHORS.dat -c -t "<ec>" -r "<er>" -Usa -P -S<SERVER NAME> isql -Usa -P -S<SERVER NAME> -iDrop_View.sql
WindowsおよびUNIXのいずれの場合も、SERVER NAME に適切な値が含まれるように各行を編集します。このファイルの編集時に、山カッコは使用しないでください。
BCP抽出スクリプトを実行します。
Windowsの場合は、次のとおり入力します。
prompt> bcp_extract.bat
UNIXの場合は、次のとおり入力します。
./bcp_extract.sh
このスクリプトによって、現行のディレクトリにデータファイルが作成されます。
これらのデータファイルを、SQL Developerによってデータ・アンロード・スクリプトが生成されたディレクトリのoracleサブディレクトリにコピーします。
Microsoft Accessデータベースからデータファイルを作成するには、Exporter for Microsoft Accessツールを使用します。
|
注意: Microsoft Accessデータベースからデータファイルを作成する方法の詳細は、エクスポータ・ツールのオンライン・ヘルプを参照してください。 |
MySQLデータベースからデータファイルを作成するには、次の手順を実行します。
ソース・データベースがインストールされているコンピュータに、SQL Developerによってデータ・アンロード・スクリプトが生成されたディレクトリの内容をコピーします。
データファイルの正しいホスト、ユーザー名、パスワードおよび移行先ディレクトリが含まれるように、Dump Extractスクリプトを編集します。
Windowsの場合は、dump_extract.batスクリプトを編集します。
UNIXの場合は、dump_extract.shスクリプトを編集します。
dump_extract.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に適切な値が含まれるようにこの行を編集します。このファイルの編集時に、山カッコは使用しないでください。
Dump Extractスクリプトを実行します。
Windowsの場合は、次のとおり入力します。
prompt> dump_extract.bat
UNIXの場合は、次のとおり入力します。
prompt> chmod 755 dump_extract.sh
このスクリプトによって、現行のディレクトリにデータファイルが作成されます。
これらのデータファイルを、SQL Developerによってデータ・アンロード・スクリプトが生成されたディレクトリのoracleサブディレクトリにコピーします。
データファイルを使用して移行先データベースへの移入を行うには、SQL*Loaderでデータ・ロード・スクリプトを実行します。
データ・アンロード・スクリプトを作成したディレクトリに移動します。
移行先データベースがインストールされているコンピュータ上のディレクトリにoracleサブディレクトリの内容をコピーします。
移行先データベースが実行されているコンピュータにログオンします。
SQLロード・スクリプトを実行します。
Windowsの場合は、次のとおり入力します。
prompt> sql_load_script.bat
UNIXの場合は、次のとおり入力します。
prompt> ./sql_load_script.sh
テスト・フェーズでは、アプリケーションおよび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 Doe
モジュール Table Test Emp
テストの完了日 2002年8月20日
対象とするログ・ファイルの位置 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への移行を目的とした操作の実行時に取得、変換および生成されたオブジェクトに関する情報が提供されます。
データベースの移行を実行する場合は、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へのサード・パーティ・データベースの移行に関連するオプションが含まれています。
Show Getting Started Guide: 移行をすぐに始めるための手順を表示します。
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 Exporter XML（Microsoft Accessの移行の場合）: エクスポータ・ツールによって作成されたXMLファイルからMicrosoft Accessデータベースの取得モデルを作成します。
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文をPL/SQL文に変換できます。T-SQLからPL/SQLへの変換、またはMicrosoft Access SQLからPL/SQLへの変換を指定できます。
「Migration」→「Translation Scratch Editor」をクリックすると、スクラッチ・エディタを表示できます。 スクラッチ・エディタには、次の図に示すインタフェースがあります。
スクラッチ・エディタ・ツールバー（「Scratch Editor」タブの下）には、次の操作を行うためのアイコンが含まれます。
Open: 「Enter SQL Statement」ボックスに入力するSQL文が含まれるファイルを開きます。
Translate: ドロップダウン・メニューで指定する変換のタイプに応じてSQL文が変換され、変換後の文のボックスに結果が表示されます。
Translation Dif Viewer: 元の文と変換後の文を表示する読取り専用ペインが表示されます。 ソース・コードと変換後のコードのセマンティックの類似点を示すため、元のSQL文と変換後のSQL文が色分けして比較されます。
Save Original SQL File: 元のファイルを任意の場所と名前で保存できます。
Erase All: 「Enter SQL Statement」ボックスの内容を消去します。
ドロップダウン・メニュー: 変換のタイプを選択できます。Transact-SQLの場合は「T-SQL to PL/SQL」、Microsoft Accessの場合は「Access to PL/SQL」を選択します。
「Enter SQL Statement」には、変換する文を指定します。複数の文の場合、PL/SQL以外の各文は、セミコロンまたは（改行後の）スラッシュ（/）のいずれかで終了する必要があります。各PL/SQL文は、改行後にスラッシュ（/）で終了する必要があります。SQLキーワードは、自動的にハイライト表示されます。
変換後の文のツールバー（「Enter SQL Statement」の下）には、変換後の文に対して次の操作を行うためのアイコンが含まれます。
Save Generated PL/SQL File: 生成された文をPL/SQLスクリプト・ファイルに保存できます。
Erase All: 生成された文を消去します。
Validate SQL: SQL文を検証します。
タブには、次の情報を持つペインが表示されます。
Result: 最新の変換操作の結果が表示されます。
Source Tree: 展開可能なツリー形式で結果が表示されます。
