38 Oracle Cloudへの移行のベスト・プラクティス

クラウド移行のベスト・プラクティスの概要と、詳細を参照できるリソースへのリンクを次に示します。

ゼロ・ダウンタイム移行(ZDM)の使用

Oracle DatabaseをOracle Cloudに移行するための、Oracle MAAのシンプルな自動化されたワンボタン手法のソリューション

最新のZDMバージョンを使用します。製品情報とソフトウェア・キットのダウンロードの詳細は、ゼロ・ダウンタイム移行を参照してください。

クロスプラットフォーム移行の場合(AIX、SparcまたはWindowsベースのプラットフォームからLinuxプラットフォームへの移行など)、ZDMでは、データ・ポンプ、RMAN、トランスポータブル表領域(XTTS)およびOracle GoldenGateのインスタンス化と移行のオプションが使用されます。ZDMでは、データ・ポンプとOracle GoldenGateを使用したオンライン移行、またはデータ移行にRMAN XTTS、メタデータ移行にデータ・ポンプを使用したオフライン移行がサポートされています。

トランスポータブル表領域とRMAN増分バックアップを使用したクロスプラットフォーム移行については、M5 Cross Endian Platform Migration using Full Transportable Data Pump Export/Import and RMAN Incremental Backups (Doc ID 2999157.1)を参照してください。ZDMでは、フル・トランスポータブル・データ・ポンプとRMAN増分バックアップによる移行はサポートされていません。

ネットワークの評価と高帯域幅ネットワークの使用

リフレッシュと最適化の計画と実行

計画:

  • HAとDRのサービス・レベル合意を理解し、それらのニーズを満たす正しいクラウドMAAリファレンス・アーキテクチャを選択していることを確認してください(Oracle Cloud最大可用性アーキテクチャを参照)。また、「Oracle Database Cloudのベスト・プラクティスの概要」を参照してください。
  • アプリケーション・パフォーマンスのキー・パフォーマンス・インジケータ(KPI)を理解し文書化します。
  • ターゲット・クラスタに1つ以上のデータベースが含まれるかどうかを把握し、後述するように、それに応じてサイズを設定します。
  • Exadata、Exascale、その他のOracle Database CloudサービスまたはAutonomous Databaseを使用する場合は、新しい利点を活用することを計画します。
  • アプリケーションで許容できる、データ移行のための最長停止時間を把握します。なお、いくらか停止時間を許容できるときは、移行オプションが大幅にシンプルになります。それらのオプションは、許容可能なのが数時間であるか(例: バックアップ/リストア、RMAN XTTSまたはデータ・ポンプの使用)、数秒から数分であるか(例: Data Guardの使用)、ほぼゼロであるか(Oracle GoldenGateの使用)に応じて異なります。また、可能な場合は、物理移行が、運用とアプリケーションに必要な投資がより少ない、よりシンプルなソリューションです。

リフレッシュと最適化:

  • 論理データベース移行では、ビッグファイルの使用によってデータファイルの数を減らすことで最適化する機会や、表と索引を再構築する機会があり、索引を削除してスキーマを再設計する機会さえあります。論理移行や最適化により、移行の計画とテストへの投資が増えることになります。
  • Oracle Cloudで提供されるシステム構成、サーバー・パラメータ・ファイル(SPFILE)および自動化を使用します。リソースのパフォーマンス・サイジングに関連するデータベース初期化パラメータのみを変更します。MAAでは、様々なデータベース・クラウド・サービスとの連携によって、必ずMAAベスト・プラクティスに準拠するようになり、最大限の安定性と可用性が実現されます。
  • 記載されていないパラメータを移行しないでください。
  • オンプレミスのカスタム・スクリプトではなく、クラウド自動化(Cloud Control Planや、Oracle提供のクラウド自動化など)を使用します。

成功のためのサイズ設定

現在のワークロードとリソース使用率の評価

  • 使用状況メトリックの収集: Oracle Automatic Workload Repository (AWR)、PerfHub、Enterprise Managerなどのツールを使用して、少なくとも7日間から30日間、実際のワークロード・データ(CPU、メモリー、ストレージ、IOPS、スループット)を収集します。
  • ピーク時のワークロードの分析: 平均のみでなく最大必要容量のサイズを測るためにピーク期間を特定します。

アプリケーションについての一覧と概略の作成

  • データベースの特性: データベースの数、サイズ、成長率、冗長性、高可用性および障害時リカバリの要件をリストします。
  • ワークロード・タイプ: OLTP、OLAP、混合ワークロード、および使用されている特別なデータベース機能またはオプション(パーティション化や圧縮など)。

コア要件の計算

  • CPU: ピーク時のCPU使用率に基づいてサイズ設定し、将来の拡大を考慮します(通常は20-30%の余裕を持たせます)。
  • メモリー: SGAとPGAのメモリー使用量、およびOS要件を評価します。
  • 統合: 複数のデータベースまたはインスタンスを統合する場合は、追加のリソースを考慮します。

ストレージのサイズ設定

  • 容量: DATAディスク・グループについて、データ、索引、オンラインREDOログ、場合によってはスタンバイREDOログ、一時表領域、UNDO、システムおよびsysaux領域に必要なサイズを計算します。RECOディスク・グループには、アーカイブ・ログ(通常は24時間)、フラッシュバック・ログ(通常は24時間、またはアーカイブ・ログ領域と同じ)、および場合によってはデータベース・バックアップが含まれます。

    分かりやすくするために、データベース・バックアップがOracle Cloudマネージド・サービスにオフロードされている場合はクラウド・デフォルトであるDATA 80%とRECO 20%を使用し、データベース・バックアップがVMクラスタにローカルである場合はDATA 40%とRECO 60%を使用します。

  • パフォーマンス: 低遅延のためのフラッシュIOPS、ディスクIOPS、ストレージ・スループットおよび待機時間のニーズを検討します。Exadataストレージでは高パフォーマンスが実現されます。そのため、容量と速度の両方について、ストレージ必要量を具現化してみてください。計算にASM冗長性レベルを組み込みます。Oracle Cloudでは、Exadataを使用するすべてのデータベース・サービスに、デフォルトとしてASM高冗長性が使用されます(理由は、その優れたデータ保護です)。

高可用性および障害時リカバリ

  • 冗長性: 高可用性のSLAを満たすように、正しいExadataまたはデータベース・シェイプを選択します。
  • Data Guardのニーズ: Oracle Data Guardを使用している場合は、Data Guardロール・トランジションの後にパフォーマンスKPIが維持されるように、スタンバイ環境を対称的にサイズ設定することを検討してください。

適切なExadataシェイプの選択

  • 算出した要件を、使用可能なExadata Database Serviceシェイプ(たとえば、データベース/コンピュート・サーバー、ストレージ・サーバー、vCPU割当ての数)と合致させます。

役立つOracleツールとドキュメント

高可用性と障害時リカバリのための準備

  • アプリケーションの高可用性(HA)を計画し、Oracle Real Application Clusters(RAC)の利点を最大限に活用するための最良な方法を計画します。Oracle RAC環境においてアプリケーションとデータベースの統合を可能にするには、「アプリケーションの継続的な可用性」と設計およびデプロイメント方法を参照してください。
  • 障害時リカバリ(DR)を計画します。
    • DRが重要である場合は、移行前にクラウド・スタンバイをターゲットに追加します。
    • クラウド自動化とMAAベスト・プラクティスを使用してスタンバイ・データベースを作成します。
    • アプリケーションのフェイルオーバーまたはスイッチオーバーのための最良の方法を把握します。Oracle Cloud Infrastructureフル・スタック障害時リカバリ・サービスを評価します。

パフォーマンスと要件を満たしていることのテストと確認

  • ZDMの-evalモードを使用してテスト環境を作成します
  • アプリケーション・パフォーマンスを評価して、キー・パフォーマンス・インジケータ(KPI)、およびパフォーマンスのサービス・レベル合意(SLA)が満たされていることを確認します
  • 単純な停止を評価して、アプリケーションとHAのSLAを満たしていることを確認します
  • 移行を複数回実行して準備状況を確認します

低ワークロードの間のカットオーバー

  • ピーク時以外のアプリケーション・ウィンドウを選択して移行を実行します。
  • 問題が発生した場合に後方で待機するための計画を作成します。
  • 可能な場合は、フォールバック計画を作成します。Oracle GoldenGateを使用した論理移行の場合は、双方向レプリケーションを設定する必要があります。Data Guardを使用した物理移行の場合は、ZDMパラメータZDM_SKIP_DG_CONFIG_CLEANUPを使用して、移行後にData Guard転送を続行できるようにする必要があります。