1 データベース移行プランナ

データベース移行プランナは、データベースの統合を管理するための包括的なエンドツーエンド・ソリューションを提供します。これにより、統合する管理対象ソースを新規または既存の宛先と一致させることができます。データベース移行プランナでは、次の組合せがサポートされます。

  • データベースからデータベース(D2D)統合タイプ(マルチテナントへの統合)を使用して、より少ない宛先データベースにソース・データベース(単一インスタンスまたはRAC)を統合します。宛先は、既存データベース(非CDBおよびCDB)または新しいサーバー上の新しいデータベース(Oracle Exadataデータベース・マシン、Oracle Compute Cloud形状または汎用サーバー)にすることができます。
  • データベースからサーバー(D2S)統合タイプを使用して、データベースの数が同じままのより少ないサーバーにソース・データベース(単一インスタンスまたはRAC)を統合します。宛先には、既存のサーバーまたは新規サーバー、すなわちOracle Exadataデータベース・マシン、Oracle Compute Cloud形状または汎用サーバーを指定できます。
  • ソース・データベースを、より多くのリソースを持つ別のサーバーに移行します。統合は後で実行できます。

データベース移行プランナでは、データベース統合のリソース要件の評価にデータベース・メトリックを使用します。データベース移行プランナが使用するデータベース・メトリックを収集するには、Oracle Enterprise Manager 13.5リリース5 (13.5.0.5)データベース・プラグイン以降が必要です。

次の項では、データベース移行プランナについて説明します。

データベース移行プランナの概要

データベース移行プランナは、様々な顧客シナリオに柔軟性をもたらします。

  • 10.2以上のデータベース・バージョンの統合。

  • Oracleプライベートまたはパブリック・クラウド、またはExadataへの統合。

  • ソースおよび宛先データベースのプラットフォームおよびバージョンに従って、停止時間を最小限に抑える高可用性オプションを使用。

データベース移行プランナでは、ワークロードの履歴(データベースおよびホスト・メトリック)の分析に基づいて統合するため、推測しながら作業を進める必要がなくなります。計画からデプロイメントまでの統合のすべてのフェーズを自動化し、ヒューマン・エラーを排除します。

統合の最適化アドバイスにより、ピーク時の最大負荷を表す「きわめて保守的」から、毎日の1時間当たりの使用量の平均を表す「積極的」まで、様々な統合シナリオでのリソース割当てを推定できます。ワークロードの特性とExadataの適性に基づいて競合を識別するために、最適化アドバイスを使用します。I/Oオフロードおよびフラッシュ・キャッシュ技術を含め、I/Oおよび記憶域への圧縮の影響を評価します。

サーバーがますます強力になり、ワークロード処理能力がいっそう高くなると、異なるサーバー上で実行されている多数の小規模データベースを持つ企業では、サーバーが十分に活用されていないことに気付いています。ハードウェアの購入コストと継続的なメンテナンス費を削減するために、少数のサーバー上にこれらの小規模データベースを統合しようと考えています。

同時に、データベース・カスタマは、パフォーマンス・ニーズを判定する際に、指定した全期間中のリソース使用率を評価し、ピーク需要が満たされているかどうかを確認したいと考えています。

必要となる宛先の容量を判定するために、ソースのI/O要件を計測するときに重要となるのは、一般にデータベースで共有されているExadataやExalogicなどのOracle Engineered Systemsの外部ストレージ・ユニットのI/O容量です。

データベース移行プランナは、セグメント・タイプ(表、索引、LOB、その他)ごとに各ソース・データベースに割り当てられている総容量と総使用量に関する詳細な記憶域情報を収集します。また、データの圧縮によって削減できる容量を評価します。セグメント・タイプおよびデータベース・バージョンに応じて、いくつかの圧縮のタイプおよびレベルに対する推定値が提供されます。

  • プロジェクト・レベルでは、データベース移行プランナは、圧縮値と非圧縮値を含め、データベースおよびセグメント・タイプ別にデータベース・ストレージ要件を表示します。

  • シナリオ・レベルでは、データベース移行プランナは、圧縮およびその他のストレージ・オプションに関する要件および顧客の入力に基づいて、Exadata外部ストレージ・システムの特定の種類および容量を推奨します。

データベース移行プランナは、次のI/O要件を収集します。

  • 1秒当たりのI/O要求数(IOPS)

  • I/O帯域幅(MB/秒)

データベース移行プランナは、各ソース・データベースのワークロードをOLTPまたはDSSのいずれかとして特徴付けるためにI/O帯域幅とIOPSとの比率を使用して、要件を外部ストレージ・ユニットのI/O容量に合せます。データベース移行プランナは、これらの調査結果によって、外部ストレージへの統合時にIOPSまたはI/O帯域幅、あるいはその両方を考慮するかどうかを決定します。ただし、ユーザーはこれらの推奨事項を上書きできます。

このように、データベース移行プランナはデータベースを統合する際に、データベース・ストレージとI/O容量ではなく、CPUとメモリー容量を宛先に適合しようと試みます。

データベース移行プランナ・プロジェクトの作成

各統合作業のためのデータベース統合プロジェクトを作成した後、その中の個々の統合シナリオを追加します。統合シナリオを比較して、どの統合方法が最も有用であるかを決定できます。

プロジェクトを定義した後で、指定したターゲットで使用可能なデータを管理リポジトリから収集するために、Cloud Controlジョブが発行されます。ジョブが終了すると、そのプロジェクトがアクティブなプロジェクトになります。プロジェクトがアクティブ状態にあるかぎり、データの収集が続きます。

プロジェクトの作成に含まれるステップは次のとおりです。

データベース移行プロジェクト・タイプの選択

次のように、データベース移行プロジェクト作成プロセスのステップ1を完了します。

  1. 「エンタープライズ」メニューから、「統合」「データベース移行プランナ」を選択します。これは、データベース・ターゲット・ホーム・ページの「管理」メニューからも選択できます。
  2. 「プロジェクトの作成」ボタンをクリックします。
  3. 統合プロジェクト名と、オプションで説明を入力します。
  4. 適切な統合タイプを選択します。
    • データベースからサーバー・コンテナ(D2S)

    • データベースからデータベース・コンテナ(D2D)。

  5. 「次へ」をクリックして、ソースの候補を指定します。

データベースのソース候補の指定

次のように、データベース統合プロジェクト作成プロセスのステップ2を完了します。

  1. データベース統合の適切なベンチマークとして、SPECrate®2017_int_baseが事前に選択されています。「ソース・データベースの選択」をクリックして、Oracle Enterprise Manager管理対象データベース候補のリストから、統合するソース・データベースを選択します。フィルタ基準を使用してターゲット検索を絞り込みます。フィルタした結果から選択し、「選択」をクリックします。

    選択したソースが表に表示されます。選択したソース・データベースを削除して、リストを間引くことができます。

  2. オプションで、行をクリックして値を変更することにより、見積もられたCPU容量率を編集します。
  3. 「次へ」をクリックして、宛先の候補を指定します。

データベースの宛先候補の指定

次のように、データベース統合プロジェクト作成プロセスのステップ3を完了します。

  1. オプションで、ソースを統合する1つ以上の既存の宛先を選択します。
    • データベースからサーバー・コンテナに統合する場合は(D2S)、「既存の仮想サーバーを宛先として追加」をクリックして、ソース・データベースを統合する既存の宛先サーバーのリストを表示します。フィルタ基準を使用して検索を絞り込みます。追加するサーバーを選択し、「選択」をクリックします。

      選択した宛先が表に表示されます。選択した宛先サーバー・コンテナを削除して、リストを間引くことができます。

    • データベースからデータベース・コンテナに統合する場合は(D2D)、「接続先の選択」をクリックして、ソース・データベースを統合するデータベース・コンテナを検索します。フィルタ基準を使用して検索を絞り込みます。追加するデータベース・コンテナを選択し、「選択」をクリックします。

      選択した宛先が表に表示されます。選択した宛先データベース・コンテナを削除して、リストを間引くことができます。

    ノート:

    既存の宛先を選択しない場合は、新規(ファントム)の宛先に統合されます。

  2. 「次へ」をクリックしてデータ収集を設定します。

データ収集パラメータの設定

プロジェクトに指定されたソース・データベースに対するデータベース統合シナリオの生成のために使用されるデータを収集する期間を指定します。このデータは、宛先のサーバーまたはデータベースが満たす必要があるリソース要件を決定するのに使用されます。

  1. データを収集する最小日数を指定します。デフォルトの最小値は21日です。実行に既存の履歴データを使用し、統合シナリオを即時に表示するには、日の最小値に0を指定します。
  2. データを収集する最大日数を指定します。デフォルトの最大値は90日です。
  3. データ収集プロセスの開始時を指定します。

    データ収集が開始した後、統合コンソールの「アクション」メニューから、いつでも収集を中断および再開することができます。

  4. オプションで、最大日数の間データ収集を続行を選択して、新しい日付のデータが追加された場合に古い日付のデータをパージします。
  5. 「次へ」をクリックして、事前構成済のシナリオを選択します。

事前構成済のシナリオの選択

データベース統合プロジェクトを作成するときは、必要に応じて、プロジェクトに追加するための事前構成済の統合シナリオを生成できます。

プロジェクトの作成時に統合プロジェクトで定義されたソースについて収集されたデータを使用して、これらのシナリオが生成されます。プロジェクトの作成時に使用可能なデータが十分にない場合、最小量のデータを収集すると、事前構成済のシナリオが自動的に生成されます。

Enterprise Manager統合には、積極的、中間、保守的な統合スキームを表す3つの即時利用可能なシナリオが付属しています。

  1. 適切なラジオ・ボタンをクリックして、事前構成済のシナリオを使用するかどうかを選択します。オプションを選択すると、使用できる即時利用可能な統合シナリオのリストが表示されます。デフォルトで、ソース・ターゲットのリソース使用量を集計するのに使用される方法で、シナリオが指定されます。
    • 積極的: 平均の日次の使用量に基づいて、時間ごとにデータを集計します。

      この場合、通常、多くのソースが各宛先に適合するため、高い統合の比率(ソース:宛先)となります。しかし、多くのソースが含まれるため、1つ以上がリソースの要件を満たさない可能性が高くなります。

    • 中: 80%の使用率に基づいてデータが集計されます。

      この場合、通常、積極的な集計と保守的な集計の間の比率(ソース:宛先)となります。

    • 保守的: 最大の日次の使用量に基づいて、時間ごとにデータを集計します。

      この場合、通常、ほとんどのソースが各宛先に適合しないため、低い比率(ソース:宛先)となります。

    使用量の統計は、次の基準に基づいて計算されます。

    • リソース要件: CPU、メモリー(GB)、ディスク記憶域など、宛先によって満たされる必要があるソースの要件。

    • 適用可能日: リソース使用量メトリックを収集する曜日。

    • ターゲット・サーバー使用率制限: 宛先で使用できる最大のリソース使用率(パーセンテージ)。有効なシナリオの方法によって使用率が決定されます。

  2. 使用する事前構成済のシナリオを選択します。
  3. シナリオの新規または既存の宛先を繰り込むかどうかを選択します。D2Sプロジェクトの場合、選択肢は新規(ファントム)または既存のExadataデータベース・マシンのどちらかです。D2Dプロジェクトの場合、新規または既存のExadataデータベース・マシンで新規または既存のデータベースを選択するほかに、適切なデータベース・アーキテクチャを選択する必要があります。
  4. 「次へ」をクリックして、統合プロジェクトを確認します。

統合プロジェクトに定義されたデータベースのために収集されたデータを使用してプロジェクトを作成すると、事前構成済のシナリオが生成されます。

統合プロジェクトが完了すると、独自のカスタム・シナリオを作成するよう選択することもできます。

データベース統合プロジェクトの確認および保存

データベース統合プロジェクトの詳細を確認します。「戻る」ボタンを使用して、変更するステップに戻ります。問題ない場合は、「発行」をクリックします。メッセージにより、プロジェクトが作成され、ジョブが発行されたことが確認されます。

プロジェクトが作成されると、統合コンソールに表示されます。統合シナリオをこのプロジェクトに定義できます。

データベース移行プランナ・シナリオの作成

事前構成済のシナリオを使用するだけでなく、それらに加えて、独自のデータベース統合シナリオを作成できます。1つのプロジェクトで複数のシナリオを作成でき、ソリューションを決定する前に異なるシナリオを比較できます。既存の統合プロジェクト内に新しい統合シナリオが作成されます。

ノート:

シナリオにはすべてのデータベースのサブセットを含むことができるため、この状況ではプロジェクトとは多少異なるとみなされる可能性があります。

プランニング目的で統合シナリオを作成できます。また、シナリオを実装することもでき、これによりデータベース移行をオンデマンドで実行できます。

シナリオの作成に含まれるステップは次のとおりです。

シナリオの設定

次のように、データベース統合シナリオ作成プロセスのステップ1を完了します。

  1. 「エンタープライズ」メニューから、「統合」「データベース移行プランナ」を選択します。これは、データベース・ターゲット・ホーム・ページの「管理」メニューからも選択できます。
  2. シナリオの適用対象となる統合プロジェクトをクリックします。
  3. シナリオの作成ボタンをクリックします。
  4. シナリオ名など、シナリオの詳細を指定します。
  5. 宛先の概要で、次のオプションを使用して宛先データベースの候補を選択します。
    • まだ存在しない宛先データベースを使用する場合は、「新規(ファントム)サーバー上の新規(ファントム)データベースの使用」をクリックします。宛先データベース要件を指定します。
      • 宛先はコンテナ・データベース(CDB)と単一インスタンス・データベースのどちらであるか。
      • データベースをクラスタ化するか。
      • クラスタ化する場合、RACインスタンスの最小数はいくつか(少なくとも2つ)。
      • サーバーはExadata、クラウド、汎用のいずれであるか。

      必要に応じて、メモリーおよびストレージの推定量を調整します。

    • 「既存のデータベースの使用」をクリックして、プロジェクトの既存の認定宛先データベース候補のセットから表示します。
  6. 対象となるソース・リソースを指定します。データベース移行プランナでは、指定されたリソースを集計して合計の要件を決定します。
    • リソース・タイプ: CPUやメモリー(GB)など、考慮する必要のあるサーバー要件。
    • スケール係数: 各ソースの宛先におけるサイズ増加に備えて余裕を作ります。スケール計数は、統合の見積もりに余裕を持たせるために、リソース要件の見積に使用されます。たとえば、使用状況データに基づくと、指定されたソースの見積もり要件が、スケール係数1に相当するメモリー2GBで、1.1のスケール係数を指定している場合、そのソースの統合には2.2GBが必要です。
    • 該当する日数: 週のうち、リソース使用量メトリックを収集する日数。
    • リソース割当て: 全体のデータベース・ソース・リソース使用量の集計に使用する方法。値は次のとおりです。
      • 積極的: 平均の日次の使用量に基づいて、時間ごとにデータを集計します。

        この場合、通常、多くのソースが各宛先に適合するため、高い統合の比率(ソース:宛先)となります。しかし、多くのソースが含まれるため、1つ以上がリソースの要件を満たさない可能性が高くなります。

      • : 80%の使用率に基づいてデータが集計されます。

        この場合、通常、積極的な集計と保守的な集計の間の比率(ソース:宛先)となります。

      • 保守的: 最大の日次の使用量に基づいて、時間ごとにデータを集計します。

        この場合、通常、ほとんどのソースが各宛先に適合しないため、低い比率(ソース:宛先)となります。

      • きわめて保守的: 時間単位の使用量でデータを集計しないでください。かわりに、指定した日付範囲で監視された最大使用量を使用します。これはデータベース統合のデフォルトです。
    • 日付範囲には、標準的なリソース要件でよく使用される期間を定義する必要があります。
  7. 推定される合計のリソース要件を表示するには、推定要件をクリックします。データベース統合では、日付範囲に渡る要件を特徴付けるのは単一の値です。
  8. 必要に応じて、オプションでソースを除外または含めてください。
  9. 「次へ」をクリックして、統合制約を定義します。

データベース統合の制約の定義

適用する必要があるビジネス、企業または技術的な制約を指定します。制約により、ソースから宛先への自動マッピング中における割当てプロセスをガイドできます。ソースと宛先間の手動マッピングの場合、制約によって違反を計算できます。

次のように、データベース統合シナリオのステップ2を完了します。

  1. 互換性のあるデータベースの基準を選択します。

    データベースは、同じターゲット・プロパティと構成が指定されている場合に互換性があると判断されます。ターゲット・プロパティおよび構成を使用して、機能領域またはデータベース・リリースおよびバージョンに基づいてデータベースを統合します。

  2. 相互に排他的なソース・データベースの基準を指定します。

    Data Guard/スタンバイ・データベースの統合を制限する条件を使用します。

  3. 「制約の結果のプレビュー」をクリックし、定義済の制約に基づいて、互換性のないソース・データベースのリストを表示します。
  4. 「次へ」をクリックして、宛先サーバーの候補を指定します。

データベースからデータベースへのプロジェクト用の宛先のプランニング

D2Dプロジェクトの場合:

  1. ステップ1の宛先の概要(候補者)の選択に従って続行します:
    • 新規の場合:
      • ステップ1でサーバーに「Oracle Exadata」を選択した場合は、検索アイコンをクリックしてExadataデータベース・マシン構成タイプを選択します。
      • ステップ1でサーバーにOracle Compute Cloudを選択した場合、検索アイコンをクリックして、宛先として使用するクラウド計算構成(形状)を選択します。形状の詳細は、「Oracle Compute Cloudの形状について」を参照してください。
      • ステップ1でサーバーに汎用サーバーを選択した場合、可能な場合は予想されるCPU容量を指定します。それ以外の場合はCPU容量入力フィールドの横にある検索アイコンをクリックして、要件を最も満たすサーバー構成を選択します。GB単位でメモリー容量を入力します。
    • 既存の場合: アクションは必要ありません。表示できるのは候補者のみです。
  2. 共有ストレージを構成します。
    • 共有ストレージ・ユニット–汎用ストレージ・ユニット(汎用サーバーのデフォルト)、または多くのExadataストレージ・ユニットの1つを選択できます。
      • 汎用サーバーで実行される宛先データベースは、使用可能なストレージ領域、IOPSおよびI/Oバンド幅として単一ストレージ・システムを共有します。デフォルトを受け入れるか、それぞれのメトリックの容量値を指定します。
      • Exadataデータベース・マシンで実行されている宛先データベースは、特定のラック・レベルで単一ストレージ・システムを共有します。つまり、使用可能なストレージ領域、IOPSおよびI/Oバンド幅は、データベース・マシンの1つのラックで共有されます。これらのメトリックの容量の値は編集できません。
    • ASM冗長性–使用する冗長性のレベルを指定します。たとえば、ミッション・クリティカルなシステムでは、高いレベルを設定し、テストや開発システムでは通常が適切な可能性があります。
  3. 様々なセグメント・タイプで使用する圧縮を指定します。ストレージ領域要件に適応するために圧縮タイプを使用します。
    • 表圧縮タイプ–選択肢には、「基本」、「OLTP」、「問合せ高」または「問合せ低」、「アーカイブ高」または「アーカイブ低」があります。11.2より前のデータベース・バージョンでは、OLTPのみがサポートされています。
    • 索引圧縮タイプ–選択肢には、「高」または「低」があります。
    • LOB圧縮タイプ–選択肢には、「高」、「中」または「低」があります。
  4. 「宛先サーバーで許可される最大リソース使用量」で、デフォルトを受け入れるか、割合を編集します。宛先サーバーにヘッドルームを提供するこれらの許容値を、個々のソース・サーバーにヘッドルームを提供するスケール係数と対比します。
  5. 「次へ」をクリックしてソース・データベースを宛先データベースにマップします。

データベースからサーバーへのプロジェクト用の宛先のプランニング

D2Sプロジェクトの場合:

  1. 次のいずれかのオプションを使用して、宛先サーバーの候補を選択します。
    • まだプロビジョニングされていないか購入されていない宛先サーバーを使用する場合は、「新規(ファントム)サーバーの使用」をクリックし、次のいずれかのオプションを選択します。

      • 「Oracle Exadata On Premise」を選択し、検索アイコンをクリックして、Exadataデータベース・マシンに適した構成タイプを選択します。

      • Oracle Exadata Cloud at Customerを選択し、検索アイコンをクリックして、Exadataデータベース・マシンに適した構成タイプを選択します。

      • 「Oracle Exadata Cloud Service」を選択し、検索アイコンをクリックして、Exadataデータベース・マシンに適した構成タイプを選択します。

      • 「汎用サーバー」を選択し、可能な場合は予想されるCPU容量を指定します。それ以外の場合はCPU容量入力フィールドの横にある検索アイコンをクリックして、要件を最も満たすサーバー構成を選択します。

        必要に応じて、メモリーの推定量を調整します。

      • 「Oracle Compute Cloud」を選択し、検索アイコンをクリックして、宛先として使用するクラウド計算構成(形状)を選択します。形状の詳細は、「Oracle Compute Cloudの形状について」を参照してください。

    • プロジェクトの宛先として使用する既存の管理対象サーバーのセットを指定するには、「既存のサーバーの使用」をクリックします。

      これが、統合プロジェクトの範囲を定義する際に指定したサーバーです。データベース移行プランナにより、収集された使用量のデータに基づいて、使用可能なハードウェア・リソースが決定されます。

      デフォルトでは、できるだけ少ない数の宛先サーバーを使用して統合プロセスが実行されるよう設定されています。必要な場合は、宛先全体でソース負荷を平均化することを選択します。

  2. 共有ストレージを構成します。
    • 共有ストレージ・ユニット–汎用ストレージ・ユニット(汎用サーバーのデフォルト)、または多くのExadataストレージ・ユニットの1つを選択できます。

      • 汎用サーバーで実行される宛先データベースは、使用可能なストレージ領域、IOPSおよびI/Oバンド幅として単一ストレージ・システムを共有します。デフォルトを受け入れるか、それぞれのメトリックの容量値を指定します。

      • Exadataデータベース・マシンで実行されている宛先データベースは、特定のラック・レベルで単一ストレージ・システムを共有します。つまり、使用可能なストレージ領域、IOPSおよびI/Oバンド幅は、データベース・マシンの1つのラックで共有されます。これらのメトリックの容量の値は編集できません。

    • ASM冗長性–使用する冗長性のレベルを指定します。たとえば、ミッション・クリティカルなシステムでは、高いレベルを設定し、テストや開発システムでは通常が適切な可能性があります。

  3. 様々なセグメント・タイプで使用する圧縮を指定します。ストレージ領域要件に適応するために圧縮タイプを使用します。
    • 表圧縮タイプ–選択肢には、「基本」、「OLTP」、「問合せ高」または「問合せ低」、「アーカイブ高」または「アーカイブ低」があります。11.2より前のデータベース・バージョンでは、OLTPのみがサポートされています。

    • 索引圧縮タイプ–選択肢には、「高」または「低」があります。

    • LOB圧縮タイプ–選択肢には、「高」、「中」または「低」があります。

  4. 「宛先サーバーで許可される最大リソース使用量」で、デフォルトを受け入れるか、割合を編集します。宛先サーバーにヘッドルームを提供するこれらの許容値を、個々のソース・サーバーにヘッドルームを提供するスケール係数と対比します。
  5. 「次へ」をクリックして、ソース・データベースを宛先サーバーにマップします。

宛先へのデータベース・ソースのマッピング

次に、データベース・ソースを統合する宛先にマップします。目的は、ソース要件を、各宛先の使用可能なリソースにできるだけ厳密に適合させることです。

このマッピングは、データベース移行プランナで自動的に実行することをお薦めします。そうすることで、リソース性能および指定されている様々な統合制約に基づいて、宛先のリソース使用率を最大化できます。手動マッピングを使用する場合、宛先に十分な容量がない場合でも、ソースは宛先にマップされます。さらに、手動マッピングは以前宣言した制約に違反することがあります。

既存の宛先を選択した場合は、オプションで、各ソースおよび宛先を手動でマップできます。

  1. リスト内のソースをクリックします。
  2. 懐中電灯アイコンをクリックし、ソースにマップする宛先を選択します。宛先には単一のソースまたは複数のソースをマップできますが、宛先は1つのみ指定できます

    結果の統合レポートには、手動マッピングが原因のリソースまたは制約の違反(あるいはその両方)が表示されます。

  3. 「次へ」をクリックして、統合シナリオを確認します。

データベース統合シナリオの確認および保存

最後に、新しいデータベース・シナリオに設定されている様々なパラメータを確認します。変更が必要な場合は、「戻る」ボタンを使用します。それ以外の場合は、次のように続行します。

  • オプションで、テンプレートとしてシナリオを保存し、他のユーザーと共有できます。このことを実行する場合は、「シナリオをテンプレートとして保存」をクリックします。開かれたダイアログで、ローカル・ファイル・システムの場所を参照し、XMLファイルとしてテンプレートを保存します。

  • 「発行」をクリックします。ジョブがシナリオのより詳細な分析のために発行されたことを確認するメッセージが表示されます。終了すると、統合ホーム・ページの下部に結果が表示されます。

その他のデータベース統合シナリオ作成オプション

既存のシナリオに基づいて、データベース統合シナリオを作成できます。統合プロジェクトの下で適用可能なシナリオを選択し、「アクション」メニューから「シナリオの類似作成」を選択します。必要に応じてシナリオを変更し、意味のある名前を指定して、通常どおり分析のために発行します。

テンプレートとしてシナリオを保存した場合、後でシナリオを別の環境にインポートできます。

  1. データベース移行プランナ・ホームページで、「アクション」メニューから「テンプレートからのシナリオの作成」を選択します。
  2. ローカル・ファイル・システムで保存されたテンプレートXMLファイルを参照します。「開く」をクリックします。
  3. テンプレートで表されるリソース、制約および宛先プランニングの観点から、保存したテンプレートを複製する範囲を指定します。変更する場合は、「更新」をクリックします。
  4. 「OK」をクリックして、保存されたテンプレートをインポートします。

    ウィザードにインポートされたシナリオが開き、編集してデータベース移行プランナに保存できます。

データベース統合のシナリオの評価

統合コンソールを使用して、統合シナリオの詳細を表示できます。統合シナリオの結果を評価したら、別のシナリオを定義することも、既存のシナリオを再実行し、使用可能な最新のデータで、前に指定された条件に基づいて再評価することもできます。前の分析の結果は上書きされます。既存のシナリオに基づいて新しいシナリオを作成し、特定の値を微調整して新しいシナリオをカスタマイズすることも可能です。この反復プロセスは、様々な要因に折り合いを付け、それぞれのトレードオフを秤にかけて生成される、最適化された統合シナリオを得るために役立ちます。

作成した統合シナリオを比較して、どの統合計画が最も要件を満たすかを決定します。

目的は次のとおりです。

  • ソース・リソースの要件を、その要件を最も満たす宛先と一致させます。

  • 宛先の使用可能な容量がすべてのソース・データベースの合算されたワークロードに対応できるようにします。

  • リソース要件の係数としてヘッドルームを準備しておくことで、宛先におけるサイズ増加に備えて余裕を作ります。

  • オプションで、使用可能なすべての宛先全体で、ソースの作業負荷のバランスをとります。

  1. 「エンタープライズ」メニューから、「統合」「データベース移行プランナ」を選択します。これは、データベース・ターゲット・ホーム・ページの「管理」メニューからも選択できます。
  2. まず、表示するシナリオを含むプロジェクトを調査します。
    • 「ステータス」列は、プロジェクトに指定された最小および最大の収集日数に基づいて、データ収集のステータスを示します。

    • 「一般」タブは、プロジェクトをタイプ、収集の詳細、ソース数などで要約します。

    • 「ソース候補」タブをクリックして、プロジェクトで定義されたソースに対して収集された様々な使用状況データを表示します。データには、プロジェクト・タイプに応じてCPU、メモリー、記憶域およびディスクとネットワークのI/Oの使用率が含まれます。

      データには、予測される圧縮率が含まれることもあります。ページに記述されているように、使用不可としてリストされている場合、シナリオを作成する前に圧縮見積りを収集できます。詳細の上にある画面上のテキストの「データベース移行プランナ・パッケージのデプロイ」リンクをクリックして、「圧縮アドバイス」ジョブを発行します。

    • 「ソース・ワークロード」タブをクリックして、収集されたソースのリソース使用量データを表示します。デフォルト表示は折れ線グラフです。同じデータをヒート・マップ(24時間30日のグリッド)で表示し、指定した時間のワークロードを、容量の100%に対するロードを示す色、および実際の割合を示す数値で示すこともできます。ビューは、ソース、リソース・タイプおよび月のいずれかでフィルタできます。

    • 「宛先候補」タブをクリックして、統合されるソースに基づいて、ハードウェア詳細および予測されるリソース使用率を宛先候補ごとに分類して表示できます。

    • 「アドバイザの結果」タブをクリックして、データベース・パフォーマンス・データに対して実行したチェックの結果を表示します。結果は潜在的なパフォーマンス・ボトルネックを明らかにし、それらを減らして解消する方法を提案します。

      本来、重大度には情報、警告、クリティカルがあります。ルールでチェックする内容の説明や解決のための提案を参照するには、ルールの上にマウスを乗せます。結果は切り捨てられることがあります。完全な説明を参照するには、その上にマウスを乗せます。

    • プロジェクトが選択されているときに「レポート」ボタンをクリックし、要約された情報および詳細を表示します。

  3. 次に、特定のシナリオのデータを表示します。「一般」タブでは、リソース・タイプおよび割当て、制約、宛先タイプなどの観点からシナリオを要約します。完了済の分析の場合は、各タブで次のように、詳細を表示する行で任意のメトリックをクリックします。
    • ソース: 予想されるCPUおよびメモリー容量および要件を含む、統合するソースのリスト。

    • 宛先: ソースの統合先の宛先のリスト。宛先ごとにリソース構成および計算された使用量が表示されます。

      クラウドへの統合で重要なリソースはCPU性能とメモリーです。

    • 比率: 宛先に対するソースの比率。デフォルトでは、データベース移行プランナはできるだけ少ない宛先にソースを適合させようとします。

    • マッピング: 特定のソースがマップされる宛先。分析には予想されるCPUとメモリーの要件および使用率が含まれ、考慮する推奨のCPUおよびメモリー割当ての数値で拡張されます。これらの推奨は、要件と宛先サーバーの容量の間での合理的な妥協点を表します。一般的な統合のマッピングの画面キャプチャは、図1-1を参照してください。

    • 「記憶域」: 記憶域要件のサマリーおよび各ソース・データベースの圧縮見積り。記憶域見積りの計算において、データベース移行プランナではExadataコンピュート・ノード(システム・ソフトウェアのあるローカル・ディスク)のローカルの記憶域を無視し、Exadata記憶域ユニットに含まれるデータ記憶域に的を絞ります。そのようなユニットに必要な数は、ソース記憶域要件およびシナリオの圧縮仕様に基づいて薦められます。

      詳細情報を参照するには、ドリルダウンします。たとえば、領域(GB) (推定)列の数値はリンクです。ソース・データベースのリンクをクリックすると、圧縮見積りのポップアップが開きます。ハイライト表示された行は、シナリオの作成時に選択した表圧縮タイプを表します。

      同様に、「IOPS」と「IOバンド幅」の各列でリンクをクリックすると、IOPSおよびIOバンド幅の詳細が読取りおよび書込みコンポーネントに、場合によっては、小規模および大規模I/Oサブコンポーネントにも分かれて表示されます。また、SQLパフォーマンス・アナライザのシミュレーションの場合には、ソース・データベースに対するExadataシミュレーションの影響を確認することもできます。

      宛先が自動ストレージ管理(ASM)を使用する既存のサーバーまたはデータベースの場合、各ASM宛先で、ストレージ領域の容量、予想される使用率(%)、予想される領域使用量(GB)、必要とされる追加のストレージ容量(GB)がチェックされてレポートされます。

    • 信頼度: シナリオで定義したソースの使用要件を満たすソースについて収集されたデータの割合。この値は、プロジェクトで定義されたすべてのソースについて集計されます。

    • 違反: シナリオで定義された技術的な違反またはビジネス制約の数。このメトリックは、シナリオでソースから宛先への自動マッピングが使用される場合のみ適用可能です。

    • 排他: 宛先への修飾されたマッピングがないソースの数。これらは、使用可能な宛先の容量を超えたソースです。除外は、ソースのためのリソースが十分でないことが原因で発生する可能性があります。

      制約のセットが異なると、最適なシナリオが異なることがあります。別のシナリオ結果を得るには、制約を変更します。

    • スキーマ競合: 複数のソース・データベースに存在するスキーマまたは宛先データベースにも存在するスキーマをリストします。これは、シナリオ作成の「宛先計画」のステップで非CDB (単一インスタンス)データベース・アーキテクチャを選択したD2Dシナリオに固有です。スキーマ競合には、オラクル社提供のシステム・スキーマは含まれません。

    • アドバイザの結果: 潜在的なパフォーマンスのボトルネックと、それらを減らしたり、解消するための推奨方法。統合仕様に基づいて発生する可能性のある問題も示します。

      本来、重大度には情報、警告、クリティカルがあります。ルールでチェックする内容の説明や解決のための提案を参照するには、ルールの上にマウスを乗せます。結果は切り捨てられることがあります。完全な説明を参照するには、その上にマウスを乗せます。

図1-1は、デフォルトのファントム宛先(クラスタ化されたCDB/PDB)を使用した簡単なデータベース間統合のマッピングを示しています。この図は、表1-1で説明されているマッピングの重要なポイントを示しています。

図1-1 データベース統合のマッピング


注釈付きの説明を含む「マッピング」タブ

表1-1は、図1-1で注釈付けされているマッピングの重要なポイントを説明しています。

表1-1 図1-1の凡例

参照点 説明

1

ラック、コンピュート・ノードおよび統合データベース・インスタンスの名前

2

このインスタンスに統合されるデータベース数

3

コンピュート・ノードのCPU容量

4

既存の宛先のCPU使用率を含む(該当する場合)、このコンピュート・ノードの総CPU使用率(%)

5

このコンピュート・ノードの総CPU使用量

6

コンピュート・ノードのメモリー容量

7

既存の宛先の使用率を含む(該当する場合)、このコンピュート・ノードの総メモリー使用率(%)

8

このコンピュート・ノードの総メモリー使用量

9

プラガブル・データベースの名前。

10

このPDBに統合されるソース・データベースの名前

11

このソース・データベースによって使用されるコンピュート・ノードのCPUの割合

12

コンピュート・ノード上のこのソース・データベースのCPU使用量

13

このソース・データベースによって使用されるコンピュート・ノードのメモリーの割合

14

コンピュート・ノード上のこのソース・データベースのメモリー使用量

データベース移行プランナのアドバイザ機能について

アドバイザは「自動ワークロード・リポジトリ」(AWR)からデータベース・パフォーマンス・データを収集し、ルールへの入力としてデータを使用します。パフォーマンス・ボトルネックがソース・データベースまたは宛先データベースに存在するかを判断するためにルールは評価され、問題を取り除く方法がアドバイスされます。シナリオ・レベルで、ルールは宛先仕様に加えてソース・データベースも組み合せて参照し、統合がパフォーマンスの問題を引き起こす可能性があるかどうかを判断します。

アドバイザ結果は、データベース移行プランナのホーム・ページでは列として、またそれぞれのプロジェクトおよびシナリオの詳細リージョンではタブとして、プロジェクトとシナリオのいずれについても表示可能です。

圧縮アドバイザについて

圧縮アドバイザは、サポートされる圧縮のタイプごとに、各ソース・データベースで圧縮によって削減可能な容量を推定し、非圧縮データのために必要となる容量を計算します。結果は、データベース統合シナリオの「記憶域」タブに表示されます。必要な記憶域の容量を決定する際に削減できるように、宛先でデータを圧縮する方法も指定できます。圧縮の見積りを有効にするには、各ソース・データベースにジョブをデプロイし、圧縮アドバイスを実行して、結果をデータベース移行プランナで使用できるようにする必要があります。

圧縮記憶域要件の見積り

データベース統合の一部としてソース・データベースで圧縮率を考慮する場合、「データベース移行プランナ・パッケージのデプロイ」ジョブを発行して各ソースの圧縮アドバイスを収集する必要があります。これは事前に行うこともプロジェクト作成後に行うこともできます。

  1. 「エンタープライズ」メニューから「ジョブ」「アクティビティ」の順に選択します。
  2. ジョブ・ページで「ジョブの作成」ボタンをクリックします。
  3. 「ジョブ・タイプ」リストから「データベース移行プランナ・パッケージのデプロイ」を探し、「選択」をクリックします。

    これによりジョブ作成ページが表示されます。このページは、すでに作成されているデータベース統合プロジェクト内の「ソース候補」タブで「データベース移行プランナ・パッケージのデプロイ」リンクをクリックした場合にも表示されます。

  4. 圧縮アドバイス・ジョブの名前を入力します。
  5. 統合のソース候補であるデータベース・ターゲットを追加します。複数選択することもできますが、ターゲット・タイプ(単一インスタンスまたはクラスタ)は同一である必要があります。表内で、ジョブに含めるターゲット・インスタンスを選択します。
  6. 「パラメータ」タブで、圧縮アドバイスの実行「はい」に設定します。
  7. 残りのジョブ作成プロセスを実行してジョブを発行します。ジョブを実行するには、ターゲット・データベースでSYSDBA資格証明が必要です。

これらのアクションの結果、予測される圧縮率がデータベース移行プランナで使用可能になります。メトリックによってシナリオ分析用のデータがEnterprise Managerに収集されるには、圧縮アドバイスが実行されてから最大24時間かかる場合があることに注意してください。

データベース移行および暗号化された表領域

ソース・データベースで暗号化された表領域が使用されている場合、移行後、ソースの場所から宛先の場所にウォレットをコピーするまで、これらの表のデータにはアクセスできません。ウォレットの場所は、sqlnet.oraファイル内で確認できます。ファイルのデフォルトの場所は、TNS AdminまたはORACLE_HOME/network/adminの場所に基づいています。

ウォレットを宛先にコピーした後、宛先のsqlnet.oraファイルを、ウォレットをコピーした場所で更新します。たとえば:

ENCRYPTION_WALLET_LOCATION = 
     (SOURCE = 
     (METHOD = FILE) 
     (METHOD_DATA = 
     (DIRECTORY = /scratch/jdoe/app/jdoe/admin/dben/wallet) 
     ) 
   ) 

ファイルの更新後、暗号化された表領域のデータにアクセスするには、ウォレットを開いておく必要があります。

  1. 「ターゲット」メニューから「データベース」を選択し、宛先データベースを検索します。
  2. 宛先データベースのホームページで、「セキュリティ」メニューから「透過的データ暗号化」を選択します。
  3. 必要なパスワードを入力してウォレットを開きます。

これで、暗号化された表領域のデータにアクセスできるようになります。

暗号化、ウォレットおよび他のセキュリティ関連問題の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

データベースの移行によるSQLワークロードへのパフォーマンスの影響の評価

データベースの移行などのシステム変更によって、SQL文の実行計画が変更され、SQLのパフォーマンスに重大な影響が生じる場合があります。SQLパフォーマンス・アナライザを使用して、SQLワークロードに対するデータベース移行によるパフォーマンスの影響を分析し、システム変更後にパフォーマンスが改善されたSQL文、パフォーマンスの変更がなかったSQL文またはパフォーマンスが低下したSQL文を特定できます。

SQLパフォーマンス・アナライザを使用して、SQLワークロードへのパフォーマンスの影響を分析するための一般的なフローは次のとおりです。

  1. 分析対象のSQLワークロードを取得して、SQLチューニング・セットに格納します。
  2. システム変更の前に、SQLパフォーマンス・アナライザ・タスクを作成します。
  3. SQLチューニング・セットに格納されているSQL文に対してテストを実行するか実行計画を生成して、変更前のSQL試行を作成します。
  4. システム変更を実行します。
  5. 変更後のシステムでSQLチューニング・セット内のSQL文を再実行して、変更後のSQL試行を作成します。
  6. SQL文に対する変更の影響を識別するレポートを生成します。
  7. SQLパフォーマンス・アナライザ・レポートを確認して、変更前と変更後のSQLパフォーマンスを比較します。「パフォーマンス」メニューで「SQL」、「SQLパフォーマンス・アナライザ・ホーム」の順に選択して、宛先データベースのホーム・ページからレポートにアクセスできます。

先に述べたように、これはSQLパフォーマンス・アナライザを使用する一般的なフローです。データベース移行の場合は、SQLチューニング・セットを作成してレポートを確認するという、前述の最初と最後のステップのみ実行する必要があります。残りは、移行ジョブで行われます。

  • SQLパフォーマンス・アナライザ・タスクの作成。

  • 変更前のSQL試行の作成。

  • データベース移行の実行。

  • 変更後のSQL試行の作成。

  • レポートの生成。

機能の使用の詳細は、『Oracle Database Testingガイド』の第Ⅰ部「SQLパフォーマンス・アナライザ」を参照してください。