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ジョブが発行されます。ジョブが終了すると、そのプロジェクトがアクティブなプロジェクトになります。プロジェクトがアクティブ状態にあるかぎり、データの収集が続きます。
プロジェクトの作成に含まれるステップは次のとおりです。
データ収集パラメータの設定
プロジェクトに指定されたソース・データベースに対するデータベース統合シナリオの生成のために使用されるデータを収集する期間を指定します。このデータは、宛先のサーバーまたはデータベースが満たす必要があるリソース要件を決定するのに使用されます。
事前構成済のシナリオの選択
データベース統合プロジェクトを作成するときは、必要に応じて、プロジェクトに追加するための事前構成済の統合シナリオを生成できます。
プロジェクトの作成時に統合プロジェクトで定義されたソースについて収集されたデータを使用して、これらのシナリオが生成されます。プロジェクトの作成時に使用可能なデータが十分にない場合、最小量のデータを収集すると、事前構成済のシナリオが自動的に生成されます。
Enterprise Manager統合には、積極的、中間、保守的な統合スキームを表す3つの即時利用可能なシナリオが付属しています。
統合プロジェクトに定義されたデータベースのために収集されたデータを使用してプロジェクトを作成すると、事前構成済のシナリオが生成されます。
統合プロジェクトが完了すると、独自のカスタム・シナリオを作成するよう選択することもできます。
データベース移行プランナ・シナリオの作成
事前構成済のシナリオを使用するだけでなく、それらに加えて、独自のデータベース統合シナリオを作成できます。1つのプロジェクトで複数のシナリオを作成でき、ソリューションを決定する前に異なるシナリオを比較できます。既存の統合プロジェクト内に新しい統合シナリオが作成されます。
ノート:
シナリオにはすべてのデータベースのサブセットを含むことができるため、この状況ではプロジェクトとは多少異なるとみなされる可能性があります。プランニング目的で統合シナリオを作成できます。また、シナリオを実装することもでき、これによりデータベース移行をオンデマンドで実行できます。
シナリオの作成に含まれるステップは次のとおりです。
データベース統合の制約の定義
適用する必要があるビジネス、企業または技術的な制約を指定します。制約により、ソースから宛先への自動マッピング中における割当てプロセスをガイドできます。ソースと宛先間の手動マッピングの場合、制約によって違反を計算できます。
次のように、データベース統合シナリオのステップ2を完了します。
宛先へのデータベース・ソースのマッピング
次に、データベース・ソースを統合する宛先にマップします。目的は、ソース要件を、各宛先の使用可能なリソースにできるだけ厳密に適合させることです。
このマッピングは、データベース移行プランナで自動的に実行することをお薦めします。そうすることで、リソース性能および指定されている様々な統合制約に基づいて、宛先のリソース使用率を最大化できます。手動マッピングを使用する場合、宛先に十分な容量がない場合でも、ソースは宛先にマップされます。さらに、手動マッピングは以前宣言した制約に違反することがあります。
既存の宛先を選択した場合は、オプションで、各ソースおよび宛先を手動でマップできます。
データベース統合シナリオの確認および保存
最後に、新しいデータベース・シナリオに設定されている様々なパラメータを確認します。変更が必要な場合は、「戻る」ボタンを使用します。それ以外の場合は、次のように続行します。
-
オプションで、テンプレートとしてシナリオを保存し、他のユーザーと共有できます。このことを実行する場合は、「シナリオをテンプレートとして保存」をクリックします。開かれたダイアログで、ローカル・ファイル・システムの場所を参照し、XMLファイルとしてテンプレートを保存します。
-
「発行」をクリックします。ジョブがシナリオのより詳細な分析のために発行されたことを確認するメッセージが表示されます。終了すると、統合ホーム・ページの下部に結果が表示されます。
その他のデータベース統合シナリオ作成オプション
既存のシナリオに基づいて、データベース統合シナリオを作成できます。統合プロジェクトの下で適用可能なシナリオを選択し、「アクション」メニューから「シナリオの類似作成」を選択します。必要に応じてシナリオを変更し、意味のある名前を指定して、通常どおり分析のために発行します。
テンプレートとしてシナリオを保存した場合、後でシナリオを別の環境にインポートできます。
データベース統合のシナリオの評価
統合コンソールを使用して、統合シナリオの詳細を表示できます。統合シナリオの結果を評価したら、別のシナリオを定義することも、既存のシナリオを再実行し、使用可能な最新のデータで、前に指定された条件に基づいて再評価することもできます。前の分析の結果は上書きされます。既存のシナリオに基づいて新しいシナリオを作成し、特定の値を微調整して新しいシナリオをカスタマイズすることも可能です。この反復プロセスは、様々な要因に折り合いを付け、それぞれのトレードオフを秤にかけて生成される、最適化された統合シナリオを得るために役立ちます。
作成した統合シナリオを比較して、どの統合計画が最も要件を満たすかを決定します。
目的は次のとおりです。
-
ソース・リソースの要件を、その要件を最も満たす宛先と一致させます。
-
宛先の使用可能な容量がすべてのソース・データベースの合算されたワークロードに対応できるようにします。
-
リソース要件の係数としてヘッドルームを準備しておくことで、宛先におけるサイズ増加に備えて余裕を作ります。
-
オプションで、使用可能なすべての宛先全体で、ソースの作業負荷のバランスをとります。
図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)からデータベース・パフォーマンス・データを収集し、ルールへの入力としてデータを使用します。パフォーマンス・ボトルネックがソース・データベースまたは宛先データベースに存在するかを判断するためにルールは評価され、問題を取り除く方法がアドバイスされます。シナリオ・レベルで、ルールは宛先仕様に加えてソース・データベースも組み合せて参照し、統合がパフォーマンスの問題を引き起こす可能性があるかどうかを判断します。
アドバイザ結果は、データベース移行プランナのホーム・ページでは列として、またそれぞれのプロジェクトおよびシナリオの詳細リージョンではタブとして、プロジェクトとシナリオのいずれについても表示可能です。
圧縮アドバイザについて
圧縮アドバイザは、サポートされる圧縮のタイプごとに、各ソース・データベースで圧縮によって削減可能な容量を推定し、非圧縮データのために必要となる容量を計算します。結果は、データベース統合シナリオの「記憶域」タブに表示されます。必要な記憶域の容量を決定する際に削減できるように、宛先でデータを圧縮する方法も指定できます。圧縮の見積りを有効にするには、各ソース・データベースにジョブをデプロイし、圧縮アドバイスを実行して、結果をデータベース移行プランナで使用できるようにする必要があります。
圧縮記憶域要件の見積り
データベース統合の一部としてソース・データベースで圧縮率を考慮する場合、「データベース移行プランナ・パッケージのデプロイ」ジョブを発行して各ソースの圧縮アドバイスを収集する必要があります。これは事前に行うこともプロジェクト作成後に行うこともできます。
これらのアクションの結果、予測される圧縮率がデータベース移行プランナで使用可能になります。メトリックによってシナリオ分析用のデータが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) ) )
ファイルの更新後、暗号化された表領域のデータにアクセスするには、ウォレットを開いておく必要があります。
- 「ターゲット」メニューから「データベース」を選択し、宛先データベースを検索します。
- 宛先データベースのホームページで、「セキュリティ」メニューから「透過的データ暗号化」を選択します。
- 必要なパスワードを入力してウォレットを開きます。
これで、暗号化された表領域のデータにアクセスできるようになります。
暗号化、ウォレットおよび他のセキュリティ関連問題の詳細は、『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パフォーマンス・アナライザ」を参照してください。