Enterprise Managerの統合

52 Enterprise Managerの統合

Enterprise Manager統合では、次の2つの統合ソリューションを提供しています。

ホスト統合プランナ: 物理または仮想のソース・サーバーを物理または仮想の宛先サーバーに統合することを目的としています。
データベース統合ワークベンチ: 新規または既存のサーバーにデータベースを統合または移行させることを目的としています。データベース統合ワークベンチは、「実際のアプリケーション・テスト」オプションの一部です。詳細は、Oracle Databaseのライセンス情報ユーザー・マニュアルを参照してください。

この章の構成は、次のとおりです。

統合の概要

主要な概念

統合の中心テーマは、既存のサーバーまたはデータベース・ソースを、既存または未購入の宛先サーバーまたはデータベースに統合することです。

統合は、見込まれる作業の範囲を定義するプロジェクトから開始します。

統合のタイプサポートされる統合タイプは次のとおりです。
- P2V: 物理的なソース・サーバーからOracle仮想マシン(VM)の宛先サーバー
- P2P: 物理的なソース・サーバーから物理的な宛先サーバー
- D2D: データベース・ソースから新しいサーバー上の新しいデータベース宛先または既存のデータベース宛先へ
- D2S: データベース・ソースから新規または既存のサーバーへ
統合元の検討対象とするソース・サーバー候補の仮のセット
統合先の検討対象とするソース・サーバー候補の仮のセット
統合シナリオの生成に使用されるデータがソース・サーバーから収集される期間
宛先サーバーに統合できるソース・サーバーの数を決定するときの、CPU容量の測定に使用されるベンチマーク

各統合プロジェクトには、提供された入力に基づいて生成される、1つまたは複数の統合シナリオがあります。次のようなものです。

宛先サーバーが満たさなくてはならないソース・サーバーのリソース要件(CPU、メモリー、ディスクI/O、ネットワークI/Oおよびディスク・ストレージの1つ以上)。
考慮する必要のある、なんらかのビジネス、コンプライアンスまたは技術的制約
シナリオで検討される宛先

事前構成された統合シナリオのセットが提供されており、それらは積極的、中間的および保守的な統合スキームを表しています。それぞれのシナリオは、お客様の入力を基に生成されます。また、お客様の状況に最適な独自のカスタム・シナリオを作成することもできます。作成したら、どの統合計画が要求に最適かを判断するため、様々なシナリオを比較できます。

各シナリオには、ソースとそれに統合できる宛先との間の最初のマッピングも含まれています。マッピングは手動で作成するか、Enterprise Managerの統合によって自動的に作成されるように選択できます。すべての入力を指定したら、シナリオを実行してその結果を評価できます。その後、前に指定された条件に基づくシナリオを、使用可能な最新のデータを使用して再評価するために、シナリオを返すこともできます。前の分析の結果は上書きされます。既存のシナリオに基づいて新しいシナリオを作成し、特定の値を微調整して新しいシナリオをカスタマイズすることも可能です。

プロセス

統合プロジェクトを作成します。
プロジェクトに1つ以上の統合シナリオを定義します。次の2つのオプションがあります。
- 事前構成済の統合シナリオを使用。
- カスタム統合シナリオを作成。
統合コンソールで統合シナリオを評価します。
シナリオの設定を変更し、異なる結果を生成します。お客様の状況にとって最良のシナリオが得られるまでこの手順を続けます。

複数のソースを複数の宛先に統合する場合、ソースのリソース要件は、宛先のリソース容量に対してチェックされます。特定されたソースをすべて最小限の数の宛先に統合するために、Enterprise Manager統合では、宛先の対応する使用可能なリソースにできるだけ緊密に適合するリソース要件が認識されたソースのセットを特定しようとします。

ホスト統合では時間当たりの要件を使用し、あるソースの最大使用量期間を他のソースの低使用量期間とマッチングすることで、宛先リソースを最大限に使用できるようにします。きわめて保守的なリソース割当て方法(デフォルト)を使用する場合を除き、データベース統合でも同じことが行われます。この場合、最適な宛先適合を捜し求めて、指定された日付範囲内で確認された最高の使用量が使用されます。　

ホスト統合プランナ

ホスト統合プランナでは、統合する管理対象ソースを新規または既存の宛先と適合させることができます。ホスト統合プランナでは、次の組合せがサポートされます。

汎用的な物理マシンであるOracle Engineered System (Exadataデータベース・マシンまたはExalogic Elastic Cloudシステム)またはOracle Virtual Machine (VM)サーバーにソース・サーバーを統合します。
Oracle Cloudで構成されている物理マシンにソース・サーバーを統合します。このタイプの統合では、Oracle Compute Cloud構成はホストを模倣します(検討するリソースとして重要なメモリーおよびCPU性能だけは除く)。

ホスト統合プランナでは、Cloud Controlによって管理対象ターゲットから収集されたデータや、ビジネス要件および技術要件のファクタを利用して、最適なシナリオの判断を支援します。

次の項では、ホスト統合プランナについて説明します。

ホスト統合プランナの概要

長年にわたり、標準的なエンタープライズ・データ・センターは、ビジネスのニーズを満たすために必要とされるサーバーの追加のため、絶え間なく成長を続けています。この成長は、多くの場合、ラック・スペースを占領し、冷却のために多くの電力を消費し、セキュリティやパッチなどのシステムのメンテナンスを必要とする、多すぎるサーバーという事態を招きます。

調達サイクルまたは特定のハードウェア・ベンダーと結んだ契約のため、企業は異なるタイプのサーバー・ハードウェアおよびオペレーティング・システムを手にすることになり、ふとしたことからシステム配置の混乱を生み、管理者による管理や運用、パッチ、アップグレードを必要とすることになります。その結果、仕事を増やし、IT予算における、絶え間のないメンテナンスとサポートのコストが増加します。企業は、コスト削減の究極の目標である、種々雑多なシステムを標準化されたオペレーティング・システムおよびハードウェアに移行する手段として、統合に注目しています。

企業はまた、物理サーバーから仮想サーバーに移行する、Oracle仮想マシンのような仮想化テクノロジについての調査を進めています。これは、仮想化がもたらす独立性の利益を得る一方で、共有ハードウェア・インフラストラクチャの使用を可能にします。

統合の目的は、そのような十分に活用されていないサーバーを見つけ出し、それを統合する手段を発見し、企業がそのサービス・レベルを維持しながら、できるかぎり多くのサーバーを解放できるようにすることです。サーバーは異なるレベルのCPU処理能力を持つので、ホスト統合プランナは、統合プロセスの指定されたハードウェアのCPU使用率を正規化するために、コンピュータのベンチマーク・データを使用します。特に、ホスト統合プランナでは、異なるクラスのハードウェアのために、次のCPUベンチマークを使用しています。

SPECint®_base_rate2006: データベース・ホスト、アプリケーション・ホストまたは混合ワークロード・ホスト
SPECjbb®2005: ミドルウェア・プラットフォーム

ホスト統合プランナは、統合する管理対象ソースを新規または既存のターゲット宛先と一致させることができます。汎用的な物理マシンであるOracle Engineered System (Exadataデータベース・マシンまたはExalogic Elastic Cloudシステム)またはOracle Virtual Machine (VM)サーバーにソース・サーバーを統合します。

また、Oracle Cloudで構成されている物理マシンにソース・サーバーを統合できます。このタイプの統合では、Oracle Cloud Compute構成はホストを模倣します(検討するリソースとして重要なメモリーおよびCPU性能だけは除く)。

ホスト統合プランナは、Enterprise Manager Cloud Controlによって管理対象ターゲット・サーバーから収集されたメトリックおよび構成データを利用することで、統合プロセスでのビジネスや技術的な制約も反映された最適な統合シナリオを決定するのに役立ちます。

ホスト統合プランナ・プロジェクトの作成

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

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

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

ホスト統合プロジェクト・タイプの選択

次のように、ホスト統合プロジェクト作成プロセスのステップ1を完了します。

「エンタープライズ」メニューから、「統合」→「ホスト統合プランナ」を選択します。
「プロジェクトの作成」ボタンをクリックします。
統合プロジェクト名と、オプションで説明を入力します。
ホスト統合タイプを選択します。
- 物理ソース・サーバーからOracle VMサーバー(P2V)
- 物理ソース・サーバーから物理サーバー(P2P)
「次へ」をクリックして、ソースの候補を指定します。

ホストのソース候補の指定

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

ドロップダウン・メニューから適切なベンチマークを選択します。
- データベース・ホスト、アプリケーション・ホストまたは混合ワークロード・ホストには、SPECint®_base_rate2006を指定します。
- ミドルウェア・プラットフォームには「SPECjbb®2005」を指定します。
「ソース・サーバーの追加」をクリックして、管理対象サーバー候補のリストから、統合するソース・サーバーを選択します。フィルタ基準を使用してターゲット検索を絞り込みます。フィルタした結果から選択し、「選択」をクリックします。

選択したソースが表に表示されます。選択したソース・サーバーを削除して、リストを間引くことができます。
オプションで、ディスクI/OリクエストのサーバーI/O容量とネットワークI/Oボリューム容量を設定します。「サーバーI/O容量の指定」をクリックして、統合プロジェクトに関係するすべてのソースについてこれらのI/O容量を見積もります。行をクリックし、様々な容量の値を編集することで、これらの見積もりを後で微調整できます。
「次へ」をクリックして、宛先の候補を指定します。

ホストの宛先候補の指定

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

オプションで、ソース・サーバーを統合する1つ以上の既存のサーバーを選択します。
- 物理サーバーからOracle Virtual Server (P2V)に統合する場合は、「既存の仮想サーバーを宛先として追加」をクリックし、ソース・サーバーの統合先となる既存のVMベースのExalogic Elastic CloudシステムとOracle Virtual Machineの宛先サーバーのリストを表示します。2つを区別するには、ターゲット・タイプ・フィルタを使用します。追加するサーバーを選択し、「選択」をクリックします。
  
  選択した宛先が表に表示されます。選択した宛先サーバーを削除して、リストを間引くことができます。
- 物理サーバーから物理サーバーに統合する場合は(P2P)、既存のOracleエンジニアド・システムを宛先として追加をクリックして、ソース・サーバーを統合するExadataデータベース・マシン・サーバーまたはExalogic Elastic Cloudサーバーを検索します。2つを区別するには、ターゲット・タイプ・フィルタを使用します。追加するサーバーを選択し、「選択」をクリックします。
  
  選択した宛先が表に表示されます。選択した宛先サーバーを削除して、リストを間引くことができます。
注意:

既存の宛先を選択しない場合は、新規(ファントム)の宛先に統合されます。P2Pプロジェクトでは、既存の宛先を選択しない場合、選択したソース・サーバーも宛先サーバーとみなされます。これにより、統合先のソース・サーバーのサブセットを選択できます。
オプションで、行をクリックして値を変更することにより、見積もられたCPU容量、I/OリクエストおよびネットワークI/Oボリュームを編集します。「サーバーI/O容量の指定」をクリックしてI/O値を編集し、統合プロジェクトに関係するすべての宛先サーバーについてこれらのI/O容量を見積もることもできます。
「次へ」をクリックしてデータ収集を設定します。

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

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

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

データ収集が開始した後、統合コンソールの「アクション」メニューから、いつでも収集を中断および再開することができます。
オプションで、最大日数の間データ収集を続行を選択して、新しい日付のデータが追加された場合に古い日付のデータをパージします。
「次へ」をクリックして、事前構成済のシナリオを選択します。

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

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

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

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

適切なラジオ・ボタンをクリックして、事前構成済のシナリオを使用するかどうかを選択します。オプションを選択すると、使用できる即時利用可能な統合シナリオのリストが表示されます。デフォルトで、ソース・ターゲットのリソース使用量を集計するのに使用される方法で、シナリオが指定されます。
- 積極的: 平均の日次の使用量に基づいて、時間ごとにデータを集計します。
  
  この場合、通常、多くのソースが各宛先に適合するため、高い統合の比率(ソース:宛先)となります。しかし、多くのソースが含まれるため、1つ以上がリソースの要件を満たさない可能性が高くなります。
- 中: 80%の使用率に基づいてデータが集計されます。
  
  この場合、通常、積極的な集計と保守的な集計の間の比率(ソース:宛先)となります。
- 保守的: 最大の日次の使用量に基づいて、時間ごとにデータを集計します。
  
  この場合、通常、ほとんどのソースが各宛先に適合しないため、低い比率(ソース:宛先)となります。
使用量の統計は、次の基準に基づいて計算されます。
- リソース要件: CPU、メモリー(GB)、ディスク記憶域など、宛先によって満たされる必要があるソースの要件。
- 適用可能日: リソース使用量メトリックを収集する曜日。
- ターゲット・サーバー使用率制限: 宛先で使用できる最大のリソース使用率(パーセンテージ)。有効なシナリオの方法によって使用率が決定されます。
使用する事前構成済のシナリオを選択します。いずれかまたはすべてのシナリオを選択できます。
シナリオの新規(ファントム)または既存の宛先を繰り込むかどうかを選択します。
プロジェクト・タイプおよび選択に基づいて、次のように進めます。
- 新規サーバーを使用するP2Vプロジェクトの場合、CPU容量、メモリー、ディスク記憶域のリソース要件を指定します。オプションで、仮想化ソフトウェアのために準備しておくリソースの数量を入力できます。これらのリザーブは、使用率を計算する前にシステム容量から差し引かれます。
- 既存のサーバーを使用するP2Vプロジェクトの場合、指定するものは何もありません。シナリオの方法によってリソース要件が決定されます。このオプションを使用できるのは、ウィザードのステップ3で既存の仮想サーバーが宛先候補として追加された場合のみです。
- 新規サーバーおよびエンジニアド・システムを使用するP2Pプロジェクトの場合、指定するものは何もありません。システムで、要件に基づいて適切なExadata構成が選択されます。
- 新規サーバーおよび汎用サーバーを使用するP2Pプロジェクトの場合、CPU容量、メモリー、ディスク記憶域のリソース要件を指定します。ただし、準備しておくリソースを入力することはできません。
- 既存のサーバーを使用するP2Pプロジェクトの場合、指定するものは何もありません。シナリオの方法によってリソース要件が決定されます。このオプションを使用できるのは、ウィザードのステップ3で既存の仮想サーバーが宛先候補として追加された場合のみです。
「次へ」をクリックして、統合プロジェクトを確認します。

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

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

ホスト統合プロジェクトの確認および保存

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

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

ホスト統合プランナ・シナリオの作成

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

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

シナリオの設定

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

「エンタープライズ」メニューから、「統合」→「ホスト統合プランナ」を選択します。
シナリオの適用対象となる統合プロジェクトをクリックします。
シナリオの作成ボタンをクリックします。
シナリオ名など、シナリオの詳細を指定します。
対象となるソース・リソースを指定します。ホスト統合プランナは指定されたリソースを集計して合計の要件を決定します。
- リソース・タイプ: CPU、メモリー(GB)、I/O容量など、考慮する必要のあるサーバー要件。
- スケール係数: 各ソースの宛先におけるサイズ増加に備えて余裕を作ります。スケール計数は、統合の見積もりに余裕を持たせるために、リソース要件の見積に使用されます。たとえば、使用状況データに基づくと、指定されたソースの見積もり要件が、スケール係数1に相当するメモリー2GBで、1.1のスケール係数を指定している場合、そのソースの統合には2.2GBが必要です。
- 該当する日数: 週のうち、リソース使用量メトリックを収集する日数。
- リソース割当て: 毎日のサーバー・ソース・リソース使用量の集計に使用する方法。値は次のとおりです。
  - 積極的: 平均の日次の使用量に基づいて、時間ごとにデータを集計します。
    
    この場合、通常、多くのソースが各宛先に適合するため、高い統合の比率(ソース:宛先)となります。しかし、多くのソースが含まれるため、1つ以上がリソースの要件を満たさない可能性が高くなります。
  - 中: 80%の使用率に基づいてデータが集計されます。この場合、通常、積極的な集計と保守的な集計の間の比率(ソース:宛先)となります。
  - 保守的: 最大の日次の使用量に基づいて、時間ごとにデータを集計します。
    
    この場合、通常、ほとんどのソースが各宛先に適合しないため、低い比率(ソース:宛先)となります。
- 日付範囲には、標準的なリソース要件でよく使用される期間を定義する必要があります。
推定される合計のリソース要件を表示するには、推定要件をクリックします。

サーバー統合では、リソース要件は集計された1時間ごとの要件の平均に基づいて表示されます。表示される要件は、リソースに指定されたスケール係数(存在する場合)を反映しています。24時間の要件パターンは、統合宛先が満たす必要のある最低要件として使用されます。
必要に応じて、オプションでソースを除外または含めてください。
「次へ」をクリックして、統合制約を定義します。

ホスト統合の制約の定義

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

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

互換性のあるサーバーの基準を選択します。

サーバーは、同じターゲット・プロパティと構成が指定されている場合に互換性があると判断されます。複数のソース・サーバーを1つの宛先サーバーに統合している場合は、互換性のあるサーバーのみが同じ宛先サーバーに統合されます。
相互に排他的なサーバーの基準を指定します。

特定タイプのソース・サーバーは相互に排他的であり、様々な理由で同じ宛先サーバー上に統合することができません。たとえば、Oracleクラスタのノードは、同じ障害グループに配置しないでください。
「制約の結果のプレビュー」をクリックし、定義済の制約に基づいて、互換性のないソース・サーバーのリストを表示します。
「次へ」をクリックして、宛先サーバーの候補を指定します。

物理サーバーから仮想サーバーへのプロジェクト用の宛先のプランニング

P2Vプロジェクトの場合:

次のいずれかのオプションを使用して、宛先サーバーの候補を選択します。
- まだプロビジョニングされていないか購入されていない宛先サーバーを使用する場合は、「新規(ファントム)サーバーの使用」をクリックし、次のいずれかのオプションを選択します。
  - 「Oracle Engineered Systemの使用」を選択し、検索アイコンをクリックして、Exalogic Elastic Cloudシステムの適切な構成タイプを選択します。
  - 「汎用サーバーの使用」を選択し、可能な場合は予想されるCPU容量を指定します。それ以外の場合はCPU容量入力フィールドの横にある検索アイコンをクリックして、要件を最も満たすサーバー構成を選択します。
    
    必要に応じて、メモリーおよびストレージの推定量を調整します。
    
    仮想環境では、データベース・マシンでスーパーバイザ・ソフトウェアが使用できるように確保(予約)しておくリソースの量を指定することもできます。この量は、ソース・サーバーを残りのリソースに統合する前に、宛先の合計容量から差し引かれます。たとえば、予想されるメモリー要件が12GBで、2GBの予約を指定した場合、統合に使用できるのは10GBのみです。
    
    ホスト統合プランナにより、統合結果の一部として、必要な宛先サーバー数が決定されます。
- 宛先として使用する既存の管理対象サーバーのセットを指定するには、「既存のサーバーの使用」をクリックします。
  
  これが、統合プロジェクトの範囲を定義する際に指定したサーバーです。収集された使用量のデータに基づいて、使用可能なハードウェア・リソースが決定されます。
  
  デフォルトでは、できるだけ少ない数の宛先サーバーを使用して統合プロセスが実行されるよう設定されています。必要な場合は、宛先全体でソース負荷を平均化することを選択します。
「宛先サーバーで許可される最大リソース使用量」で、デフォルトを受け入れるか、割合を編集します。宛先サーバーにヘッドルームを提供するこれらの許容値を、個々のソース・サーバーにヘッドルームを提供するスケール係数と対比します。
「次へ」をクリックして、ソース・サーバーを宛先サーバーにマップします。

物理サーバーから物理サーバーへのプロジェクト用の宛先のプランニング

P2Pプロジェクトの場合:

次のいずれかのオプションを使用して、宛先サーバーの候補を選択します。
- まだプロビジョニングされていないか購入されていない宛先サーバーを使用する場合は、「新規(ファントム)サーバーの使用」をクリックし、次のいずれかのオプションを選択します。
  - 「Oracle Engineered Systemの使用」を選択して、Exadataデータベース・マシンまたはExalogic Elastic Cloudのいずれかを選択します。検索アイコンをクリックして、いずれかの選択に適した構成タイプを選択します。
  - 「汎用サーバーの使用」を選択し、可能な場合は予想されるCPU容量を指定します。それ以外の場合はCPU容量入力フィールドの横にある検索アイコンをクリックして、要件を最も満たすサーバー構成を選択します。
  - Oracle Compute Cloudの使用を選択し、宛先として使用するクラウド計算構成(形状)を選択します。形状の詳細は、「Oracle Compute Cloudの形状について」を参照してください。
- プロジェクトの宛先として使用する既存の管理対象サーバーのセットを指定するには、「既存のサーバーの使用」をクリックします。
  
  これが、統合プロジェクトの範囲を定義する際に指定したサーバーです。収集された使用量のデータに基づいて、使用可能なハードウェア・リソースが決定されます。宛先の候補を明示的に指定しなかった場合は、すべてのソース・サーバーが統合の潜在的な宛先になります。
  
  デフォルトでは、できるだけ少ない数の宛先サーバーを使用して統合プロセスが実行されるよう設定されています。必要な場合は、宛先全体でソース負荷を平均化することを選択します。
「宛先サーバーで許可される最大リソース使用量」で、デフォルトを受け入れるか、割合を編集します。宛先サーバーにヘッドルームを提供するこれらの許容値を、個々のソース・サーバーにヘッドルームを提供するスケール係数と対比します。
「次へ」をクリックして、ソース・サーバーを宛先サーバーにマップします。

ホスト・ソースから宛先へのマッピング

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

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

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

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

結果の統合レポートには、手動マッピングが原因のリソースまたは制約の違反(あるいはその両方)が表示されます。
「次へ」をクリックして、統合シナリオを確認します。

ホスト統合シナリオの確認および保存

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

オプションで、テンプレートとしてシナリオを保存し、他のユーザーと共有できます。このことを実行する場合は、「シナリオをテンプレートとして保存」をクリックします。開かれたダイアログで、ローカル・ファイル・システムの場所を参照し、XMLファイルとしてテンプレートを保存します。
「発行」をクリックしますジョブがシナリオのより詳細な分析のために発行されたことを確認するメッセージが表示されます。終了すると、統合ホーム・ページの下部に結果が表示されます。

その他のホスト統合シナリオ作成オプション

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

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

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

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

ホスト統合のシナリオの評価

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

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

目的は次のとおりです。

ソース・リソースの要件を、その要件を最も満たす宛先と一致させます。
ソースの要件と各宛先の使用可能なリソースをできるだけ緊密に適合させ、宛先の容量を最大限に使用できるようにします。
リソース要件の係数としてヘッドルームを準備しておくことで、宛先におけるサイズ増加に備えて余裕を作ります。
オプションで、使用可能なすべての宛先全体で、ソースの作業負荷のバランスをとります。

「エンタープライズ」メニューから、「統合」→「ホスト統合プランナ」を選択します。
まず、表示するシナリオを含むプロジェクトを調査します。
- 「ステータス」列は、プロジェクトに指定された最小および最大の収集日数に基づいて、データ収集のステータスを示します。
- 「一般」タブは、プロジェクトをタイプ、収集の詳細、ソース数などで要約します。
- 「ソース候補」タブをクリックして、プロジェクトで定義されたソースに対して収集された様々な使用状況データを表示します。データには、プロジェクト・タイプに応じてCPU、メモリー、記憶域およびディスクとネットワークのI/Oの使用率が含まれます。
- 「ソース・ワークロード」タブをクリックして、収集されたソースのリソース使用量データを表示します。デフォルトの表示はヒート・マップ(24時間30日のグリッド)で、指定した時間のワークロードを、容量の100%に対するロードを示す色、および実際の割合を示す数値で表示します。また、同じデータを棒グラフで表示することもできます。ビューは、ソース、リソース・タイプおよび月のいずれかでフィルタできます。
- 「宛先候補」タブをクリックして、統合されるソースに基づいて、ハードウェア詳細および予測されるリソース使用率を宛先候補ごとに分類して表示できます。
- プロジェクトが選択されているときに「レポート」ボタンをクリックし、要約された情報および詳細を表示します。
次に、特定のシナリオのデータを表示します。「一般」タブでは、リソース・タイプおよび割当て、制約、宛先タイプなどの観点からシナリオを要約します。完了済の分析の場合は、各タブで次のように、詳細を表示する行で任意のメトリックをクリックします。
- ソース: 予想されるCPUおよびメモリー容量および要件を含む、統合するソースのリスト。
- 宛先: ソースの統合先の宛先のリスト。宛先ごとにリソース構成および計算された使用量が表示されます。
  
  クラウドへの統合で重要なリソースはCPU性能とメモリーです。
- 比率: 宛先に対するソースの比率。デフォルトでは、ホスト統合プランナはできるだけ少ない宛先にソースを適合させようとします。
- マッピング: 特定のソースがマップされる宛先。分析には予想されるCPUとメモリーの要件および使用率が含まれ、考慮する推奨のCPUおよびメモリー割当ての数値で拡張されます。これらの推奨は、要件と宛先サーバーの容量の間での合理的な妥協点を表します。
- 信頼度: シナリオで定義したソースの使用要件を満たすソースについて収集されたデータの割合。この値は、プロジェクトで定義されたすべてのソースについて集計されます。
- 違反: シナリオで定義された技術的な違反またはビジネス制約の数。このメトリックは、シナリオでソースから宛先への自動マッピングが使用される場合のみ適用可能です。
- 排他: 宛先への修飾されたマッピングがないソースの数。これらは、使用可能な宛先の容量を超えたソースです。

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

データベース統合ワークベンチ

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

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

データベース統合ワークベンチでは、データベース統合のリソース要件の評価にデータベース・メトリックを使用します。データベース統合ワークベンチが使用するデータベース・メトリックを収集するには、Oracle Enterprise Manager 13cリリース1データベース・プラグインまたはそれ以上が必要です。

次の項では、データベース統合ワークベンチについて説明します。

データベース統合ワークベンチの概要

データベース統合ワークベンチは、様々なカスタマ・シナリオに柔軟性を提供します。

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とメモリー容量を宛先に適合しようと試みます。

データベース統合ワークベンチ・プロジェクトの作成

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

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

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

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

「エンタープライズ」メニューから、「統合」→「データベース統合ワークベンチ」を選択します。これは、データベース・ターゲット・ホーム・ページの「管理」メニューからも選択できます。
「プロジェクトの作成」ボタンをクリックします。
統合プロジェクト名と、オプションで説明を入力します。
適切な統合タイプを選択します。
- データベースからサーバー・コンテナ(D2S)
- データベースからデータベース・コンテナ(D2D)。
「次へ」をクリックして、ソースの候補を指定します。

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

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

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

選択したソースが表に表示されます。選択したソース・データベースを削除して、リストを間引くことができます。
オプションで、行をクリックして値を変更することにより、見積もられたCPU容量率を編集します。
「次へ」をクリックして、宛先の候補を指定します。

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

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

オプションで、ソースを統合する1つ以上の既存の宛先を選択します。
- データベースからサーバー・コンテナに統合する場合は(D2S)、「既存の仮想サーバーを宛先として追加」をクリックして、ソース・データベースを統合する既存の宛先サーバーのリストを表示します。フィルタ基準を使用して検索を絞り込みます。追加するサーバーを選択し、「選択」をクリックします。
  
  選択した宛先が表に表示されます。選択した宛先サーバー・コンテナを削除して、リストを間引くことができます。
- データベースからデータベース・コンテナに統合する場合は(D2D)、「接続先の選択」をクリックして、ソース・データベースを統合するデータベース・コンテナを検索します。フィルタ基準を使用して検索を絞り込みます。追加するデータベース・コンテナを選択し、「選択」をクリックします。
  
  選択した宛先が表に表示されます。選択した宛先データベース・コンテナを削除して、リストを間引くことができます。
注意:

既存の宛先を選択しない場合は、新規(ファントム)の宛先に統合されます。
「次へ」をクリックしてデータ収集を設定します。

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

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

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

データ収集が開始した後、統合コンソールの「アクション」メニューから、いつでも収集を中断および再開することができます。
オプションで、最大日数の間データ収集を続行を選択して、新しい日付のデータが追加された場合に古い日付のデータをパージします。
「次へ」をクリックして、事前構成済のシナリオを選択します。

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

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

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

適切なラジオ・ボタンをクリックして、事前構成済のシナリオを使用するかどうかを選択します。オプションを選択すると、使用できる即時利用可能な統合シナリオのリストが表示されます。デフォルトで、ソース・ターゲットのリソース使用量を集計するのに使用される方法で、シナリオが指定されます。
- 積極的: 平均の日次の使用量に基づいて、時間ごとにデータを集計します。
  
  この場合、通常、多くのソースが各宛先に適合するため、高い統合の比率(ソース:宛先)となります。しかし、多くのソースが含まれるため、1つ以上がリソースの要件を満たさない可能性が高くなります。
- 中: 80%の使用率に基づいてデータが集計されます。
  
  この場合、通常、積極的な集計と保守的な集計の間の比率(ソース:宛先)となります。
- 保守的: 最大の日次の使用量に基づいて、時間ごとにデータを集計します。
  
  この場合、通常、ほとんどのソースが各宛先に適合しないため、低い比率(ソース:宛先)となります。
使用量の統計は、次の基準に基づいて計算されます。
- リソース要件: CPU、メモリー(GB)、ディスク記憶域など、宛先によって満たされる必要があるソースの要件。
- 適用可能日: リソース使用量メトリックを収集する曜日。
- ターゲット・サーバー使用率制限: 宛先で使用できる最大のリソース使用率(パーセンテージ)。有効なシナリオの方法によって使用率が決定されます。
使用する事前構成済のシナリオを選択します。
シナリオの新規または既存の宛先を繰り込むかどうかを選択します。D2Sプロジェクトの場合、選択肢は新規(ファントム)または既存のExadataデータベース・マシンのどちらかです。D2Dプロジェクトの場合、新規または既存のExadataデータベース・マシンで新規または既存のデータベースを選択するほかに、適切なデータベース・アーキテクチャを選択する必要があります。
「次へ」をクリックして、統合プロジェクトを確認します。

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

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

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

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

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

データベース統合ワークベンチ・シナリオの作成

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

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

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

シナリオの設定

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

「エンタープライズ」メニューから、「統合」→「データベース統合ワークベンチ」を選択します。これは、データベース・ターゲット・ホーム・ページの「管理」メニューからも選択できます。
シナリオの適用対象となる統合プロジェクトをクリックします。
シナリオの作成ボタンをクリックします。
シナリオ名など、シナリオの詳細を指定します。
対象となるソース・リソースを指定します。データベース統合ワークベンチでは、指定されたリソースを集計して合計の要件を決定します。
- リソース・タイプ: CPUやメモリー(GB)など、考慮する必要のあるサーバー要件。
- スケール係数: 各ソースの宛先におけるサイズ増加に備えて余裕を作ります。スケール計数は、統合の見積もりに余裕を持たせるために、リソース要件の見積に使用されます。たとえば、使用状況データに基づくと、指定されたソースの見積もり要件が、スケール係数1に相当するメモリー2GBで、1.1のスケール係数を指定している場合、そのソースの統合には2.2GBが必要です。
- 該当する日数: 週のうち、リソース使用量メトリックを収集する日数。
- リソース割当て: 全体のデータベース・ソース・リソース使用量の集計に使用する方法。値は次のとおりです。
  - 積極的: 平均の日次の使用量に基づいて、時間ごとにデータを集計します。
    
    この場合、通常、多くのソースが各宛先に適合するため、高い統合の比率(ソース:宛先)となります。しかし、多くのソースが含まれるため、1つ以上がリソースの要件を満たさない可能性が高くなります。
  - 中: 80%の使用率に基づいてデータが集計されます。この場合、通常、積極的な集計と保守的な集計の間の比率(ソース:宛先)となります。
  - 保守的: 最大の日次の使用量に基づいて、時間ごとにデータを集計します。
    
    この場合、通常、ほとんどのソースが各宛先に適合しないため、低い比率(ソース:宛先)となります。
  - きわめて保守的: 時間ごとの使用率でデータを集計するのではなく、指定した日付範囲で最も高いと確認された使用率を使用してください。これはデータベース統合のデフォルトです。
- 日付範囲には、標準的なリソース要件でよく使用される期間を定義する必要があります。
推定される合計のリソース要件を表示するには、推定要件をクリックします。データベース統合では、日付範囲に渡る要件を特徴付けるのは単一の値です。
必要に応じて、オプションでソースを除外または含めてください。
「次へ」をクリックして、統合制約を定義します。

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

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

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

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

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

Data Guard/スタンバイ・データベースの統合を制限する条件を使用します。
「制約の結果のプレビュー」をクリックし、定義済の制約に基づいて、互換性のないソース・データベースのリストを表示します。
「次へ」をクリックして、宛先サーバーの候補を指定します。

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

D2Dプロジェクトの場合:

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

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

D2Sプロジェクトの場合:

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

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

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

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

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

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

結果の統合レポートには、手動マッピングが原因のリソースまたは制約の違反(あるいはその両方)が表示されます。
「次へ」をクリックして、統合シナリオを確認します。

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

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

オプションで、テンプレートとしてシナリオを保存し、他のユーザーと共有できます。このことを実行する場合は、「シナリオをテンプレートとして保存」をクリックします。開かれたダイアログで、ローカル・ファイル・システムの場所を参照し、XMLファイルとしてテンプレートを保存します。
「発行」をクリックしますジョブがシナリオのより詳細な分析のために発行されたことを確認するメッセージが表示されます。終了すると、統合ホーム・ページの下部に結果が表示されます。

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

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

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

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

ウィザードにインポートされたシナリオが開き、編集してデータベース統合ワークベンチに保存できます。

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

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

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

目的は次のとおりです。

ソース・リソースの要件を、その要件を最も満たす宛先と一致させます。
宛先の使用可能な容量がすべてのソース・データベースの合算されたワークロードに対応できるようにします。
リソース要件の係数としてヘッドルームを準備しておくことで、宛先におけるサイズ増加に備えて余裕を作ります。
オプションで、使用可能なすべての宛先全体で、ソースの作業負荷のバランスをとります。

「エンタープライズ」メニューから、「統合」→「データベース統合ワークベンチ」を選択します。これは、データベース・ターゲット・ホーム・ページの「管理」メニューからも選択できます。
まず、表示するシナリオを含むプロジェクトを調査します。
- 「ステータス」列は、プロジェクトに指定された最小および最大の収集日数に基づいて、データ収集のステータスを示します。
- 「一般」タブは、プロジェクトをタイプ、収集の詳細、ソース数などで要約します。
- 「ソース候補」タブをクリックして、プロジェクトで定義されたソースに対して収集された様々な使用状況データを表示します。データには、プロジェクト・タイプに応じてCPU、メモリー、記憶域およびディスクとネットワークのI/Oの使用率が含まれます。
  
  データには、予測される圧縮率が含まれることもあります。ページに記述されているように、使用不可としてリストされている場合、シナリオを作成する前に圧縮見積りを収集できます。詳細の上にある画面上のテキストのデータベース統合ワークベンチ・パッケージのデプロイ・リンクをクリックして、「圧縮アドバイス」ジョブを発行します。
- 「ソース・ワークロード」タブをクリックして、収集されたソースのリソース使用量データを表示します。デフォルト表示は折れ線グラフです。同じデータをヒート・マップ(24時間30日のグリッド)で表示し、指定した時間のワークロードを、容量の100%に対するロードを示す色、および実際の割合を示す数値で示すこともできます。ビューは、ソース、リソース・タイプおよび月のいずれかでフィルタできます。
- 「宛先候補」タブをクリックして、統合されるソースに基づいて、ハードウェア詳細および予測されるリソース使用率を宛先候補ごとに分類して表示できます。
- 「アドバイザの結果」タブをクリックして、データベース・パフォーマンス・データに対して実行したチェックの結果を表示します。結果は潜在的なパフォーマンス・ボトルネックを明らかにし、それらを減らして解消する方法を提案します。
  
  本来、重大度には情報、警告、クリティカルがあります。ルールでチェックする内容の説明や解決のための提案を参照するには、ルールの上にマウスを乗せます。結果は切り捨てられることがあります。完全な説明を参照するには、その上にマウスを乗せます。
- プロジェクトが選択されているときに「レポート」ボタンをクリックし、要約された情報および詳細を表示します。
次に、特定のシナリオのデータを表示します。「一般」タブでは、リソース・タイプおよび割当て、制約、宛先タイプなどの観点からシナリオを要約します。完了済の分析の場合は、各タブで次のように、詳細を表示する行で任意のメトリックをクリックします。
- ソース: 予想されるCPUおよびメモリー容量および要件を含む、統合するソースのリスト。
- 宛先: ソースの統合先の宛先のリスト。宛先ごとにリソース構成および計算された使用量が表示されます。
  
  クラウドへの統合で重要なリソースはCPU性能とメモリーです。
- 比率: 宛先に対するソースの比率。デフォルトでは、データベース統合ワークベンチはできるだけ少ない宛先にソースを適合させようとします。
- マッピング: 特定のソースがマップされる宛先。分析には予想されるCPUとメモリーの要件および使用率が含まれ、考慮する推奨のCPUおよびメモリー割当ての数値で拡張されます。これらの推奨は、要件と宛先サーバーの容量の間での合理的な妥協点を表します。一般的な統合のマッピングの画面キャプチャは、図52-1を参照してください。
- 「記憶域」: 記憶域要件のサマリーおよび各ソース・データベースの圧縮見積り。記憶域見積りの計算において、データベース統合ワークベンチではExadataコンピュート・ノード(システム・ソフトウェアのあるローカル・ディスク)のローカルの記憶域を無視し、Exadata記憶域ユニットに含まれるデータ記憶域に的を絞ります。そのようなユニットに必要な数は、ソース記憶域要件およびシナリオの圧縮仕様に基づいて薦められます。
  
  詳細情報を参照するには、ドリルダウンします。たとえば、領域(GB) (推定)列の数値はリンクです。ソース・データベースのリンクをクリックすると、圧縮見積りのポップアップが開きます。ハイライト表示された行は、シナリオの作成時に選択した表圧縮タイプを表します。
  
  同様に、「IOPS」と「IOバンド幅」の各列でリンクをクリックすると、IOPSおよびIOバンド幅の詳細が読取りおよび書込みコンポーネントに、場合によっては、小規模および大規模I/Oサブコンポーネントにも分かれて表示されます。また、SQLパフォーマンス・アナライザのシミュレーションの場合には、ソース・データベースに対するExadataシミュレーションの影響を確認することもできます。
  
  宛先が自動ストレージ管理(ASM)を使用する既存のサーバーまたはデータベースの場合、各ASM宛先で、ストレージ領域の容量、予想される使用率(%)、予想される領域使用量(GB)、必要とされる追加のストレージ容量(GB)がチェックされてレポートされます。
- 信頼度: シナリオで定義したソースの使用要件を満たすソースについて収集されたデータの割合。この値は、プロジェクトで定義されたすべてのソースについて集計されます。
- 違反: シナリオで定義された技術的な違反またはビジネス制約の数。このメトリックは、シナリオでソースから宛先への自動マッピングが使用される場合のみ適用可能です。
- 排他: 宛先への修飾されたマッピングがないソースの数。これらは、使用可能な宛先の容量を超えたソースです。除外は、ソースのためのリソースが十分でないことが原因で発生する可能性があります。
  
  制約のセットが異なると、最適なシナリオが異なることがあります。別のシナリオ結果を得るには、制約を変更します。
- スキーマ競合: 複数のソース・データベースに存在するスキーマまたは宛先データベースにも存在するスキーマをリストします。これは、シナリオ作成の「宛先計画」のステップで非CDB (単一インスタンス)データベース・アーキテクチャを選択したD2Dシナリオに固有です。スキーマ競合には、オラクル社提供のシステム・スキーマは含まれません。
- アドバイザの結果: 潜在的なパフォーマンスのボトルネックと、それらを減らしたり、解消するための推奨方法。統合仕様に基づいて発生する可能性のある問題も示します。
  
  本来、重大度には情報、警告、クリティカルがあります。ルールでチェックする内容の説明や解決のための提案を参照するには、ルールの上にマウスを乗せます。結果は切り捨てられることがあります。完全な説明を参照するには、その上にマウスを乗せます。

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

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

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

表52-1 図52-1の凡例

参照点	説明
1	ラック、コンピュート・ノードおよび統合データベース・インスタンスの名前
2	このインスタンスに統合されるデータベース数
3	コンピュート・ノードのCPU容量
4	既存の宛先のCPU使用率を含む(該当する場合)、このコンピュート・ノードの総CPU使用率(%)
5	このコンピュート・ノードの総CPU使用量
6	コンピュート・ノードのメモリー容量
7	既存の宛先の使用率を含む(該当する場合)、このコンピュート・ノードの総メモリー使用率(%)
8	このコンピュート・ノードの総メモリー使用量
9	プラガブル・データベースの名前。
10	このPDBに統合されるソース・データベースの名前
11	このソース・データベースによって使用されるコンピュート・ノードのCPUの割合
12	コンピュート・ノード上のこのソース・データベースのCPU使用量
13	このソース・データベースによって使用されるコンピュート・ノードのメモリーの割合
14	コンピュート・ノード上のこのソース・データベースのメモリー使用量

データベース統合ワークベンチのアドバイザ機能について

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

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

圧縮アドバイザについて

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

圧縮記憶域要件の見積り

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

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

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

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

データベース統合シナリオの実装について

データベース統合シナリオを作成した後、4つのサポートされた移行メソッドのいずれかを使用することで、マップされた宛先にソース・データベースを移行してマッピングを実装できます。

Data Guardのフィジカル・スタンバイ(最小停止時間)
RMANクローン
データ・ポンプ(完全またはスキーマ)のエクスポートおよびインポート(クロス・プラットフォーム)
完全トランスポータブル・エクスポートおよびインポート(最小停止時間、クロス・プラットフォーム)

データベース統合シナリオの実装では、データベース統合ワークベンチ内で直接編集して必要な資格証明などの補足情報を指定するXMLファイルが生成されます。その後、実際の移行を実行するデプロイメント・プロシージャを発行するEMCLIコマンドの入力用に、ファイルをローカルに保存します。

データベース統合シナリオの実装

データベース移行を実行するプロシージャをデプロイしてシナリオを実装します。

「エンタープライズ」メニューから、「統合」→「データベース統合ワークベンチ」を選択します。
データベース統合ワークベンチ・ホーム・ページで、終了したデータベース統合シナリオを選択し、「シナリオ実装」をクリックします。
使用可能なオプションから、RMANクローンなどの移行メソッドを選択します。メソッドの上にマウスを乗せると説明が表示されます。特に、最小バージョン要件には注意してください。
移行コマンドの生成をクリックして、EMCLI移行コマンドと移行XMLファイルを作成します。
移行XMLの編集をクリックして、「メッセージ」の下にリストされている問題に対処し、追加情報を追加します。生成されたファイルは、データベース資格証明とホスト資格証明、作業ディレクトリの場所などの必要な情報を示すために詳細にコメントされています。
「検証」をクリックして、XML適合を確認します。
XMLファイルおよび作成した編集を保持する場合は、「保存して戻る」をクリックしてデータベース統合ワークベンチ・ホーム・ページに戻ります。次にシナリオを実装する際にファイルが使用可能になります。
移行XMLのダウンロードをクリックして、ファイルをローカル・ファイル・システムに保存します。

ソース・データベースを移行する準備ができたら、保存したXMLファイルをローカルで入力として渡してEMCLIコマンド(emcli migrate_db -file=<migration_xml_file_path>)を実行します。実行すると、コマンドはデプロイメント・プロシージャを発行して移行を実行します。「プロシージャ・アクティビティ」ページで移行を追跡できます。「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「プロシージャ・アクティビティ」の順に選択します。

移行メソッドがData Guardフィジカル・スタンバイの場合、停止時間を制御するmigrate_dbコマンド内でパラメータを起動できます。前提条件のXML検証を無視することもできます。

get_sample_migration_xml EMCLIコマンドを使用して、選択した移行メソッドに基づいてソースおよび宛先マッピングを示す、サンプルXML移行ファイルを生成します。

移行コマンドの詳細は、Enterprise Managerコマンドライン・インタフェース・ガイドを参照してください。

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

ソース・データベースで暗号化された表領域が使用されている場合、移行後、ソースの場所から宛先の場所にウォレットをコピーするまで、これらの表のデータにはアクセスできません。ウォレットの場所は、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) 
     ) 
   )

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

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

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

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

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

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

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

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

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

SQLパフォーマンス・アナライザ・タスクの作成。
変更前のSQL試行の作成。
データベース移行の実行。
変更後のSQL試行の作成。
レポートの生成。

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

ホストおよびデータベースの統合に共通のトピック

次の項では、ホストおよびデータベースの統合に共通のトピックについて説明します。

Enterprise Manager統合での統合シナリオの分析方法

統合シナリオを分析するために、Enterprise Manager統合では定義済のプロセスに従います。

ホスト統合の場合、Enterprise Manager統合では各統合ソースの時間ごとおよび全体的なリソース要件を見積ります。Enterprise Managerで収集されたメトリック・データを使用して、(指定した収集日数内の)時間ごとおよびすべての時間の要件を計算し、選択されたリソース割当てスタイル(「積極的」、「中」または「保守的」)に応じて、平均、80パーセンタイルまたは最大値を選択します。

データベース統合の場合、Enterprise Manager統合では「きわめて保守的」リソース割当てスタイルを使用し、期間全体にわたってリソースの最大値を選択します。

スケール係数が指定されている場合、Enterprise Manager統合では値を調整します。この場合もリソース割当てスタイルに応じて、SGAに使用されるメモリー割合を50%、40%または30%削減することで、D2Dシナリオのメモリー要件をさらに調整します。ソースに対して表示されるリソース要件は、リソース割当てスタイルと調整によって決定される全体的な要件です。

統合シナリオに既存の宛先が含まれている場合、Enterprise Manager統合では同様の計算を実行して、各宛先の時間ごとおよび全体的な使用率の値を決定します。これらの値をスケーリングまたは調整せず、リソース割当てスタイルに応じて、平均、80パーセンタイルまたは最大値を使用して計算します。

新規または既存の宛先へのホスト統合の場合、Enterprise Manager統合では各ソースの時間当たりの要件を宛先の時間当たりの使用可能容量と照合します。(既存の宛先は、既存の時間当たりのワークロードが移入されたこのプロセスを開始します。新しい宛先は空の状態で開始します。)宛先がすべてのリソースに対する時間当りの要件すべてに対応できる場合は、統合が正常に行われます。

データベース統合の場合、Enterprise Manager統合ではどのデータベースを各宛先にマップするかを決定するために、ソース・データベースごとに単一のワークロード値を合算します。

要件を統合できない場合、Enterprise Manager統合では、容量が十分な宛先が検出されるまで次の宛先を試行します。統合が既存の宛先に対するもので、十分な容量が残っていない場合、ソースは統合から除外されます。新しい宛先への統合の場合は、ソースに対応するために別の宛先が作成されます。

ワークロードが複数のインスタンス間で共有されるRACデータベースの宛先があるD2Dシナリオの場合、プロセスは異なります。各ソース・データベースのワークロードは、RACデータベースのすべてのインスタンスに統合され、すべてのインスタンスで合計ワークロードのバランスがとられます。これは、Exadataまたはクラスタ宛先のあるD2Sシナリオについても同様です。
コンテナ・データベース(CDB)が宛先のD2Dシナリオの場合、各ソース・データベースは、CDB内の別のプラガブル・データベース(PDB)に統合されます。ユーザー指定の制約のため競合状態にあるソース・データベースは、別のCDBに統合されます。
デフォルトでは、Enterprise Manager統合ではできるだけ最少の宛先にソースを統合します。ただし、複数の既存の宛先があるシナリオでは、ワークロードをすべての宛先に分散させることを選択できます。

シナリオの「マッピング」ページには、統合の結果が表示されます。このページの内容は、統合に対して選択したプロジェクト・タイプとリソースによって異なりますが、一般には次の内容が表示されます。

予測される宛先、および各宛先に統合されたソース。
各リソースについて、宛先の容量と、既存のワークロードに統合されたソースによって消費されるリソースの割合および量(存在する場合)。Enterprise Manager統合では、宛先のリソースの時間当たりの最大使用率を検出することで、この量を見積もります。ソース行は、そのソースによって使用される宛先のリソースの割合を示します。

統合レポートの表示

次の項で説明するように、統合プロジェクトおよびシナリオの詳細を、様々な書式で取得できるレポート形式で再利用し、より多くのユーザーに配布できます。

統合プロジェクト・レポートの表示

プロジェクト・レポートを表示するには、ホストまたはデータベースのプロジェクトをそれぞれの統合ホーム・ページで選択し、表の上にある「レポート」ボタンをクリックします。「レポート」ページでは、ホームページのプロジェクト詳細に表示されているタブ情報を表示するスタック済でスクロール可能な表としてプロジェクト詳細を再度表示します。

「レポートの公開」をクリックし、レポート・コンテンツを取得します。このアクションはBI Publisherと結合し、次のことができます。

様々な形式(Excel、PowerPoint、HTML、PDF)によるレポートの保存。
定義済のスケジュールに基づく、生成されたレポートの電子メール・リスト(Enterprise Managerへのアクセス権がないユーザーなど)への配信。

「OK」をクリックして統合ホーム・ページに戻ります。

統合シナリオ・レポートの表示

プロジェクトのシナリオのレポートを表示するには、統合ホームページのプロジェクト内のホストまたはシナリオを選択し、表の上にある「レポート」ボタンをクリックします。「レポート」ページでは、ホームページのシナリオ詳細に表示されているタブ情報を表示するスタック済でスクロール可能な表としてシナリオ詳細を再度表示します。

「レポートの公開」をクリックし、レポート・コンテンツを取得します。このアクションはBI Publisherと結合し、次のことができます。

様々な形式(Excel、PowerPoint、HTML、PDF)によるレポートの保存。
定義済のスケジュールに基づく、生成されたレポートの電子メール・リスト(Enterprise Managerへのアクセス権がないユーザーなど)への配信。

「OK」をクリックして統合ホーム・ページに戻ります。

データ収集の管理

ホストまたはデータベースのプロジェクトのステータスを表示してデータ収集を管理します。

各統合ホームページで、「アクション」メニューから「データ収集の表示」を選択します。
ビューには、次のタスクを実行できるプロジェクト内のソースがリストされます。
- プロジェクトによる最新の収集ステータスを表示します。
- ソースを選択して、その収集の履歴を表示し、収集の潜在的な問題をトラブルシューティングします。
- 「データ収集ジョブ」の下のリンクをクリックして、表示できるジョブ・アクティビティ・ページに移動し、最新のデータ収集ジョブを管理します。
- 最新のレートを使用してCSVファイルをダウンロードする手順に従って、最新のCPUパフォーマンス・メトリック値を更新します。ファイルをダウンロードしたら、「参照」をクリックしてローカル・ファイル・システムのファイルを検索し、「ロード」をクリックしてEnterprise Manager統合のレートを更新します。

Oracle Compute Cloud形状について

形状では、1つのインスタンスに使用可能なOracle Compute Unit (OCPU)の数およびRAM容量を定義します。OCPUは、現在ハイパー・スレッドが使用可能な3.0 GHz 2012 Intel Xeonプロセッサ相当のCPU性能を提供します。各OCPUは、vCPUと呼ばれる、2つのハードウェア実行スレッドに対応します。

広範な形状は、ビジネス要件に最適な、インスタンスの処理能力とメモリーの組合せを選択する際に役立ちます。インスタンスの形状を選択する際に、インスタンスにデプロイするアプリケーションの特性、アプリケーションの使用が予想されるユーザー数、および将来予想される負荷のスケールの程度について検討します。OSで使用されるCPUおよびメモリー・リソースも忘れずに考慮してください。

リソース要件を満たす形状を決定するために、形状を試して典型的なワークロードでテストできます。

次の表には、Oracle Compute Cloudサービスで現在利用可能な形状のリストが示されています。OC3からOC7の形状は標準のOCPUとメモリーの組合せを表しています。OC1MからOC5Mの形状は上位のメモリー構成を表していて、メモリー割当てが標準構成の2倍です。

名前	OCPU	vCPU	メモリー(GB)
OC3	1	2	7.5
OC4	2	4	15
OC5	4	8	30
OC6	8	16	60
OC7	16	32	120
OC1M	1	2	15
OC2M	2	4	30
OC3M	4	8	60
OC4M	8	16	120
OC5M	16	32	240

Oracle Cloud Computingの詳細は、http://www.oracle.com/cloud/index.htmlを参照してください。