3 SQL Developer: サード・パーティ・データベースの移行
移行とは、MySQL、またはMicrosoft SQL Server、Sybase Adaptive Server、IBM DB2 (UDB)などのソースとなる(Oracle以外の)サード・パーティ・データベースからOracle Databaseにスキーマ・オブジェクトおよびデータをコピーするプロセスのことです。移行は、大部分が自動化された効率的な方法で実行できます。
したがって、SQL DeveloperでOracle Database以外のデータベースを処理する場合は、次の2つのオプションがあります。
-
データベース接続を作成し、それらのデータベースのスキーマ・オブジェクトおよびデータを参照できるようにするオプション
-
それらのデータベースをOracleに移行し、Oracle Databaseの特性および機能を最大限に活用できるようにするオプション
この項の内容は次のとおりです。
3.1 移行: 基本の選択肢とステップ
サード・パーティ・データベースのすべてまたは一部をOracleに移行する場合、次の基本的な選択肢があります。
ただし、どの移行アクションを実行する前にも、適切な移行ユーザー・プリファレンス(日付とタイムスタンプのマスク、「引用符付き識別子が有効」など)を設定し、「移行: バックグラウンド情報とガイドライン」の関連トピックを読んで準備してください。
ウィザードを使用するか、または表をOracleにコピーして移行した後に、結果が期待どおりであることを確認します。
ヒント:
標準的な移行のウォーク・スルーは、sqldeveloper\sqldeveloper\bin
フォルダに移動して、次のコマンドを入力してください。
sdcli migration -help=guide
関連項目
3.1.1 移行ウィザードを使用した移行
移行ウィザードでは、データベース移行に関係するアクション(ソース・データベースの取得、Oracle形式への変換、変換を実行するDDLの生成など)の便利で総合的なガイダンスが提供されます。移行の実行時にはこの方法を使用することをお薦めします(各フェーズで発生する問題を解決し、要件に合うようにオブジェクトを調査したり変更することができます)。
移行ウィザードは、サード・パーティ・データベース接続を右クリックして「Oracleへの移行」を選択したとき、「ツール」、「移行」、「移行」の順にクリックしたときなど、様々なコンテキストで起動されます。このウィザードは、最初のステップ以外のページで起動される場合もあります。
最後以外のすべてのページで、「サマリー・ページに進む」を有効にすると、「次」を使用して「サマリー」ページに移動できます。
3.1.1.1 リポジトリ
ウィザードの「リポジトリ」ページでは、使用する移行リポジトリのデータベース接続を指定する必要があります。
移行リポジトリは、SQL Developerが移行メタデータの管理に使用するスキーマ・オブジェクトのコレクションです。移行リポジトリおよびそのリポジトリへのデータベース接続がまだない場合は、次のように作成します。
-
MIGRATIONSというOracleユーザーとそのデフォルト表領域USERSおよび一時表領域TEMPを作成し、RESOURCE以上のロールおよびCREATE SESSION、CREATE VIEWおよびCREATE MATERIALIZED VIEW権限を付与します。複数スキーマの移行では、RESOURCEロールをADMINオプション付きで付与する必要があります。また、このユーザーには、CREATE ROLE、CREATE USERおよびALTER ANY TRIGGER権限のすべてをADMINオプション付きで付与する必要があります。
-
MIGRATIONSユーザーに接続するデータベース接続Migration_Repositoryを作成します。
-
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.2 Oracleへの選択した表のコピー
サード・パーティ・データベースからOracle Databaseに1つ以上の表をコピーする場合は、サード・パーティ表を選択して「Oracleへのコピー」機能を使用できます。この方法では、移行リポジトリを作成または使用したり、オブジェクトを取得して変換する必要はありません。
この方法では、完全な移行は実行されないことに注意してください。表および表データ(必要に応じて)を、サード・パーティ・データベースからOracle Databaseにコピーできるだけです。主キーや外部キー定義およびほとんどの制約を移行または再作成することはできません。(UNIQUE制約またはデフォルト値はコピーでは保持されません。NOT NULL制約は、ほとんどの場合、維持されます。)この方法では、プロシージャなど、表以外のオブジェクトについても考慮されていません。
また、この方法では、INCREMENT BY
値が1の場合および順序が1から開始するかまたはトリガーへの最初のコールでMAX VAL
+ 1に調整されている場合のみ、列の自動増分をサポートします。
このような制限が許容される場合であれば、この方法はすばやくて便利な方法といえます。たとえば、一部のデータベース所有者は、基本の表定義およびデータのみをOracle Databaseにコピーする必要があり、その後SQL Developerを使用してOracle Databaseにキーおよび制約を追加できます。
選択した表をコピーするには、次のステップを実行します。
-
サード・パーティ・データベースへのデータベース接続を作成してオープンします。(移行では、接続を作成する前にサード・パーティのJDBCドライバ・プリファレンスを設定しておく必要があります。)
-
「接続」ナビゲータで、サード・パーティ・データベース接続の「表」の表示を展開し、移行する表を選択します。
複数の表を選択するには、適宜、個別選択および範囲選択の標準的な方法を使用します([Ctrl]キーおよび[Shift]キーを使用します)。
-
右クリックして「Oracleへのコピー」を選択します。
-
「Oracleへコピーするデータベースの選択」ダイアログ・ボックスで、適切なエントリを選択します。
接続先データベース名: Oracle Databaseに選択した表をコピーするために使用するデータベース接続。(選択には、Oracle Database接続のみが表示されます。)
データを含める: このオプションを有効にすると、Oracle Database内に新規表が作成されてから、この表にサード・パーティ・データベースの表のデータがコピーされます。このオプションが無効の場合、Oracle Databaseに表は作成されますが、データはコピーされません。
表が存在する場合: コピー元の表と同じ名前の表が宛先Oracle Databaseにすでに存在している場合のアクションとして、「エラーの表示」(エラーが生成され、コピーは実行されない)、「追加」(コピー元の表から宛先Oracle表に行が追加される)、「置換」(宛先Oracle表内のデータがコピー元の表の行に置き換えられる)を指定します。名前が同じ2つの表があり、その列定義が異なる場合、「データを含める」を指定すると、ソース列のデータ型と宛先列のデータ型に互換性があるかどうかによって、データがコピーされるときと、コピーされないときがあります。
-
コピー操作を実行するには、「適用」をクリックします。
コピー元と同じ名前の表が、宛先Oracle Databaseにすでに存在する場合は、次のようになります。
-
その2つの表に同じ列定義がない場合、コピーは実行されます。
-
2つの表に同じ列定義があり、「データを含める」が指定されている場合、データは追加されます(つまり、コピー元の表からの行が、既存のOracle表に挿入されます)。
3.2 移行: バックグラウンド情報とガイドライン
次のトピックでは、データベースの移行計画に役立つバックグラウンド情報とガイドラインを示します。
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 移行計画の準備
ここでは、移行の計画を作成するプロセスについて説明します。移行計画に含めるタスクを特定し、それぞれのタスクの内容を判断する方法、および移行プロジェクトに伴うリスクを回避する方法について説明します。内容は次のとおりです。
3.2.2.1 タスク1: 移行プロジェクトの要件の確認
このタスクでは、移行するデータベース、およびそのデータベースにアクセスするアプリケーションを特定します。また、業務要件を評価し、テスト基準を定義します。
移行プロジェクトの要件を確認するには:
3.2.2.4 タスク4: アプリケーションの分析
このタスクでは、ソース・データベースで実行されているアプリケーションのユーザー、ソース・データベースに必要なハードウェア、アプリケーションの機能、およびソース・データベースに対するアプリケーションのインタフェースを確認します。また、データベースに接続して必要な変更を特定するためにアプリケーションで使用される方法も分析します。
ノート:
移行プロジェクトが複雑な計画の場合は、示すすべての項目を検討することをお薦めします。単純な計画の場合は、関連するほとんどの項目を検討してください。
アプリケーションを分析するには:
-
アプリケーションを移行先データベースで効果的に実行するためにアプリケーションに変更を行う必要があるかどうかを判断します。
-
アプリケーションへの変更が必要な場合は、アプリケーションの再作成または変更のいずれがより効果的かを判断します。
Oracle Databaseを使用するためにアプリケーションを再作成する場合は、次のことを考慮します。
-
アプリケーションの再作成に必要なプロジェクト・ドキュメントを作成します。たとえば、設計仕様および要件ドキュメントが必要です。
-
仕様に従ってアプリケーションを再作成します。
-
アプリケーションがOracle Databaseに対して動作することをテストします。
Oracle Databaseを使用するためにアプリケーションを変更する場合は、次のことを考慮します。
-
アプリケーションに存在するデータベースへの接続数を確認し、Oracle Databaseが使用されるようにこれらの接続を変更します。
ODBC接続またはJDBC接続を使用するために、接続情報の変更が必要な場合があります。
-
Oracle Databaseに対してアプリケーションのテストを行う前に、アプリケーションで変更が必要な埋込みSQL文を特定します。
-
Oracle Databaseを使用してアプリケーションをテストします。
-
-
アプリケーションの再作成または変更に関連する各問題に対処するための時間およびリソースを割り当てます。
-
タスク1で作成した、このプロジェクトについての一般的な要件ドキュメントを更新します。
3.2.3 移行を始める前に: 一般的な情報
サード・パーティ・データベースからOracle Databaseへの移行を開始する前に、特定のタスクの実行が必要になる場合があります。詳細は、次を参照してください:
移行しようとしているソース・データベースに固有の要件の詳細は、「移行を始める前に: ソース固有の情報」を参照してください。
ノート:
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に移行するサード・パーティ・データベースによっては、接続情報を構成し、ドライバをインストールする必要がある場合があります。サード・パーティ・データベースに固有の要件の詳細は、次の項を参照してください。
3.2.4.1 IBM DB2からの移行の前に
IBM DB2データベースを移行用に構成するには:
-
ソース接続用にSQL Developerで使用されるIBM DB2データベース・ユーザーがソース・データベースにアクセス可能であることを確認します。このユーザーは、IBM DB2データベースで取得するオブジェクトを参照できる必要があり、参照できないオブジェクトは取得できません。たとえば、ユーザーがあるストアド・プロシージャを実行できても、そのソース・コードを参照するのに十分な権限を持っていない場合には、そのストアド・プロシージャは取得できません。
-
SQL DeveloperがインストールされているシステムからIBM DB2データベースに接続できることを確認します。
-
IBMから
db2jcc.jar
ファイルとdb2jcc_license_cu.jar
ファイルをダウンロードしてあることを確認します。 -
SQL Developerで、次の手順を実行します。
-
「ツール」→「プリファレンス」→「データベース」→「サード・パーティJDBCドライバ」をクリックします。
-
「エントリの追加」をクリックします。
-
db2jcc.jar
ファイルを選択します。 -
「OK」をクリックします。
-
db2jcc_license_cu.jar
ファイルに対してステップbからdを繰り返します。
-
3.2.4.2 Microsoft SQL ServerまたはSybase Adaptive Serverからの移行の前に
Microsoft SQL ServerデータベースまたはSybase Adaptive Serverデータベースを移行用に構成するには:
-
ソース接続用にSQL Developerで使用されるMicrosoft SQL ServerユーザーまたはSybase Adaptive Serverユーザーがソース・データベースにアクセス可能であることを確認します。このユーザーは、Microsoft SQL ServerデータベースまたはSybase Adaptive Serverデータベースで取得するオブジェクトを参照できる必要があります。ユーザーが参照できないオブジェクトは取得できません。たとえば、ユーザーがあるストアド・プロシージャを実行できても、そのソース・コードを参照するのに十分な権限を持っていない場合には、そのストアド・プロシージャは取得できません。
-
SQL DeveloperがインストールされているシステムからMicrosoft SQL ServerデータベースまたはSybase Adaptive Serverデータベースに接続できることを確認します。
-
http://sourceforge.net/projects/jtds/
からJTDS JDBCドライバをダウンロードしてあることを確認します。 -
SQL Developerでは、「更新を自動的にチェックする」を使用してJTDSドライバがまだインストールされていない場合、次の処理を実行します。
-
「ツール」→「プリファレンス」→「データベース」→「サード・パーティJDBCドライバ」をクリックします。
-
「エントリの追加」をクリックします。
-
http://sourceforge.net/projects/jtds/
からダウンロードしたJTDSドライバのjarファイルを選択します。 -
「OK」をクリックします。
-
-
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プリファレンスを設定します。次のステップを実行します。
-
SQL DeveloperがインストールされているシステムからMySQLデータベースに接続できることを確認します。
-
http://www.mysql.com/
のMySQLのWebサイトから、MySQLConnector/J APIがダウンロードされていることを確認します。 -
SQL Developerでは、「更新を自動的にチェックする」を使用してMySQL JDBCドライバがまだインストールされていない場合、次の処理を実行します。
-
「ツール」→「プリファレンス」→「データベース」→「サード・パーティJDBCドライバ」をクリックします。
-
「エントリの追加」をクリックします。
-
http://www.mysql.com/
からダウンロードしたMySQLドライバのjarファイルを選択します。 -
「OK」をクリックします。
-
-
ソース接続用にSQL Developerで使用されるMySQLユーザーがソース・データベースにアクセス可能であることを確認します。このユーザーは、MySQLデータベースで取得するオブジェクトを参照できる必要があります。ユーザーが参照できないオブジェクトは取得できません。たとえば、ユーザーがあるストアド・プロシージャを実行できても、そのソース・コードを参照するのに十分な権限を持っていない場合には、そのストアド・プロシージャは取得できません。
3.2.4.4 Teradataからの移行の前に
現在のリリースのSQL Developerでは、プロシージャ、ファンクション、トリガー、ビュー、マクロ、BTEQスクリプトなどのTeradataオブジェクトはOracleに移行されないことに注意してください。
Teradataデータベースを移行用に構成するには:
-
ソース接続用にSQL Developerで使用されるTeradataデータベース・ユーザーがソース・データベースにアクセス可能であることを確認します。このユーザーは、Teradataデータベースで取得するオブジェクトを参照できる必要があり、参照できないオブジェクトは取得できません。
-
SQL DeveloperがインストールされているシステムからTeradataデータベースに接続できることを確認します。
-
Teradataから
tdgssconfig.jar
ファイルとterajdbc4.jar
ファイルをダウンロードしてあることを確認します。 -
SQL Developerで、次の手順を実行します。
-
「ツール」→「プリファレンス」→「データベース」→「サード・パーティJDBCドライバ」をクリックします。
-
「エントリの追加」をクリックします。
-
tdgssconfig.jar
ファイルを選択します。 -
「OK」をクリックします。
-
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.7 Oracleスキーマ・オブジェクト用のDDLの生成
Oracleスキーマ・オブジェクトを作成するDDL文を生成するには、事前に取得モデルを取得し、変換モデルを作成しておく必要があります。DDLを生成した後、DDL文を実行して、Oracle Databaseにオブジェクトを作成できます。この時点で、データベース・スキーマがOracleに移行されます。
DDL文を生成および実行してスキーマ・オブジェクトを移行した後、元のソース・データベースからデータを移行できます。
関連項目
3.2.8 データの移行
移行ウィザードでは、既存のデータをソース・データベースからOracle Databaseに移行(移動)するかどうかを選択できます。データの移行を選択する場合、次のようになります。
-
移行をオンライン・モードで実行する場合は、データ移行をオンラインまたはオフライン・モードで実行できます。(ただし、PostgreSQLの移行の場合は、データ移行をオンライン・モードで実行する必要があります。)
-
移行をオフライン・モードで実行する場合は、データの移行は生成されるファイルに含められます。
オンライン・データ移動は小規模なデータ・セットに適しており、オフライン・データ移動は大規模データの移動に役立ちます。
3.2.8.1 オフラインでのデータの送信
データをオフラインで送信するには、データをソース・データベースから移行先データベースにコピーするスクリプトを生成して使用します。このプロセスでは、次の操作を行う必要があります。
-
SQL Developerを使用して、ソース・データベース用のデータ・アンロード・スクリプト、および移行先データベース用の対応するデータ・ロード・スクリプトを生成します。
-
ソース・データベースに適した手順で、データ・アンロード・スクリプトを実行してソース・データベースからデータファイルを作成します。
-
Teradataの場合、BTEQとSQL*Loaderを使用してオフライン・データの移動を実行します。
-
SQL*Loaderを使用してデータ・ロード・スクリプトを実行し、これらのデータファイルから移行先データベースにデータを移入します。
3.2.8.1.1 Microsoft SQL ServerまたはSybase Adaptive Serverからのデータファイルの作成
Microsoft SQL ServerデータベースまたはSybase Adaptive Serverデータベースからデータファイルを作成するには:
3.2.8.1.3 データファイルを使用した移行先データベースへの移入
データファイルを使用して移行先データベースへの移入を行うには、SQL*Loaderでデータ・ロード・スクリプトを実行します。
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モデルの例を示します。
移行プロセスで使用するテストには、複数の種類があります。テスト段階では、複数のサイクルのテストを実行してデータベースの質を向上させます。使用するテスト・ケースで、以前のバージョンのOracle Databaseで発生したいずれの問題も再発していないことを確認する必要があります。
たとえば、移行したスキーマをテスト結果に基づいて変更する必要がある場合は、新しいバージョンのOracle Databaseスキーマの作成が必要になることがあります。実際には、テストの開始時にSQL Developerを使用してベースラインとなるOracleスキーマを作成し、テストの進捗に合わせてこのスキーマを編集します。
ノート:
テスト・サイクルで検出された問題は、問題追跡システムで追跡することをお薦めします。テスト用バージョンのデータベースまたはアプリケーションに対して、これらの問題を追跡してください。
3.2.10.2 Oracle Databaseのテスト
テスト・ケースを使用して、Oracle Databaseでのビジネス・ロジックの結果がソース・データベースでの結果と同じであることを検証します。
ノート:
移行が正常に実行されたかどうかを判断できるように達成基準を定義することをお薦めします。
次の手順では、移行したデータベースをテストする1つの方法について説明します。他の方法も使用可能であり、業務要件によっては他の方法のほうが適している場合もあります。
Oracle Databaseをテストするには:
-
移行したデータベースのテスト用バージョンを作成します。
データベースの移行スクリプトは、ソースの制御システムに保存することをお薦めします。
-
Oracle Databaseに対するユニット・レベルからシステム・レベルまでのテストに使用する一連のテスト・ケースを計画します。テスト・ケースでは、次のことを実行する必要があります。
-
次の項目を確認します。
-
ソース・データベースのすべてのユーザーが正常に移行されたかどうか
-
ユーザーに対する権限付与が適切かどうか
-
表の構造が正しいかどうか、デフォルトで正常に機能しているかどうか、およびマッピング時または生成時にエラーが発生しなかったかどうか
-
-
次の方法を使用して、データが正常に移行されたことを確認します。
-
Oracle Databaseの行数とソース・データベースの行数を比較
-
Oracle Databaseの数値列の合計を計算し、ソース・データベースの数値列の合計と比較
-
-
次の条件が制約に適用されていることを確認します。
-
重複する主キーは入力できない
-
外部キーによって、一貫性のないデータ入力が防止される
-
チェック制約によって、無効なデータ入力が防止される
-
-
索引および順序が正常に作成されていることを確認します。
-
次の方法を使用して、ビューが正常に移行されたことを確認します。
-
Oracle Databaseの行数とソース・データベースの行数を比較
-
Oracle Databaseの数値列の合計を計算し、ソース・データベースの数値列の合計と比較
-
-
トリガー、プロシージャおよびファンクションが正常に移行されたことを確認します。トリガーおよびファンクションに対して、適切な値が戻されることを確認します。
-
-
移行したデータベースに対して、テスト・ケースを実行します。
-
テスト・ケースの結果を評価するレポートを作成します。
これらのレポートを使用すると、データを評価してエラーを限定したり、問題レポートを保存したり、顧客に対してデータベースのテスト用バージョンを提供できます。
-
テストを通過した場合は、ステップ7に進みます。
テスト・ケースのすべての評価基準が満たされているか、または発生しているエラーが許容可能な場合、テストを通過できます。許容可能なエラーが発生した場合は、それらをエラー・レポートに記録して、監査の目的で使用できるようにします。
-
テスト・ケースでエラーが発生した場合は、次の作業を実行します。
-
エラーの原因を特定します。
-
エラーの確認に必要なテスト・ケースを特定します。
-
問題レポートに、テスト用バージョンの移行済データベース・コードでの問題を記録します。
-
ユーザーの組織で使用されている問題追跡システムに、テスト・ケースおよび問題の説明を追加します。問題追跡システムは、スプレッドシートでも、不具合のレポート・システムでもかまいません。インシデント・ログには、テスト・ケース以外に次の内容を含めます。
-
発生した問題についての明快で簡潔な説明
-
環境の詳細な説明(プラットフォーム、ソースの制御バージョンなど)
-
テストの出力(役に立つ場合)
-
問題の発生頻度および予測可能性
-
問題が発生するまでのイベントの順序
-
現行のテストでの影響、実行した診断ステップおよび要注意の結果
-
後で現れる永続的な影響(存在する場合)
-
-
エラーの修正を試行します。
-
ステップ1に戻ります。
-
-
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 |
ソース・データベースの各表に対して次の文を実行します。
移行先データベースの各表に対して次の文を実行します。
|
ソース・データベースでは、count(*)によって数値が生成されます。この場合、生成される数値は各表の行数です。 移行先データベースでは、count(*)の数値は新しいOracle表の行数に対応します。 |
はい 各表の行数は、ソース・データベースと移行先データベースで同じになります。 |
2 |
ソース・データベースの各表に対して次の文を実行します。
移行先データベースの各表に対して次の文を実行します。
|
ソース・データベースでは、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.3 移行に使用するSQL Developerユーザー・インタフェース
データベースの移行を実行する場合は、移行固有の機能を使用する必要があります。ユーザー・インタフェースでは、「ツール」の「移行」サブメニューとしてナビゲータ(「移行プロジェクト」)が追加され、インタフェース全体にわたって多くの細かな変更が行われています。図3-2に、Sybaseデータベースの移行を反映するオブジェクトが表示された、SQL Developerのメイン・ウィンドウを示します。「移行」サブメニューも示します。
この図の内容を次に示します。
-
「接続」ナビゲータに、
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ワークシート・ウィンドウで構成されています。
![変換スクラッチ・エディタのインタフェース 変換スクラッチ・エディタのインタフェース](img/scratch_editor.jpg)
ある文を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