1. データベースの移行中の停止時間の短縮について学ぶ
  2. データベース移行時の停止時間の短縮について

データベース移行時の停止時間の短縮について

本番データベースを新しいプラットフォームに移行する計画停止時間は、計画外停止時間として動作に悪影響を与える場合があります。これは、複数のタイム・ゾーンのユーザーをサポートしているグローバルな企業や、1日24時間、1週間、7日間でインターネットにアクセスできる企業で特に当てはまります。データベースをオンプレミスからクラウドに移行するか、現在のクラウド・サービスから新しいインフラストラクチャまたはプラットフォームに移行するかにかかわらず、高可用性を提供するOracleテクノロジを使用すると、停止時間を短縮できます。

予想ダウンタイムについて

データベースをオンプレミスからクラウドに移行すると、一部のオプションは他のオプションより停止時間が短くなります。

次の表に、高可用性移行ソリューションで予想される停止時間を示します。

Oracleソリューション 予期した停止時間

Oracle GoldenGate

ゼロから秒

Oracle Data Guard

5分未満

Oracle Recovery Manager

2時間未満

Oracle Cloudバックアップからのインスタンス化

データベース・サイズに応じた分数(時間数)

データベースのOracle Database Cloud Serviceへの移行に関する考慮事項

オンプレミスのOracle DatabaseをOracle Database Cloud Serviceに移行するために、様々な方法およびツールを使用できます。

移行方法がすべて移行シナリオに適用されるわけではありません。移行方法の多くは、ソース・データベースと宛先データベースの特性が一致するか、または互換性がある場合にのみ適用されます。移行シナリオに技術的に適用できる方法の中から、移行に選択する方法には、追加の要因が影響することがあります。

移行方法を選択する際に考慮する必要がある特性およびデータベース・オプションの一部を次に示します。

  • ソース・データベースのバージョン

  • Oracle Database Cloud Serviceデータベース・バージョン

  • オンプレミスのホスト・オペレーティング・システムとバージョン

  • オンプレミスのデータベース・キャラクタ・セット

  • データ量(索引を含む)

  • オンプレミス・データベースで使用されるデータ型

  • データ・ステージング用の記憶域

  • 許容できるシステム停止の長さ

  • ネットワーク帯域幅と接続性

移行シナリオに適用可能な移行方法を決定するには、次の情報を収集します。

  1. ソースのデータベース・バージョン。オンプレミス・データベース。

    Oracle Database 11 gリリース2以前は、11.2.0.4より前のバージョンでは、11.2.0.4.以上のバージョンへのアップグレードが必要です

  2. オンプレミスOracle Database 12 cリリース1 12.1.0.2以降のデータベースの場合、データベースのアーキテクチャは次のとおりです。

    • コンテナ・データベース(CDB)は、1つ(シングルテナント)または複数(マルチテナント)のプラガブル・データベース(pdb)をサポートできます。

    • 非CDB

  3. オンプレミス・ソースのデータベース・ホストのプラットフォームおよびエンディアン形式。

    プラットフォームは、使用するバイト順序に応じて、リトル・エンディアンまたはビッグ・エンディアンです。Oracle Database Cloud Serviceでは、リトル・エンディアンであるLinux x 86 -64プラットフォームが使用されます。

    V$DATABASEを問い合せて、ソース・データベースのプラットフォーム名を確認します。

    V$TRANSPORTABLE_PLATFORMを問い合せて、クロス・プラットフォーム表領域トランスポートをサポートするすべてのプラットフォームを、各プラットフォームのエンディアン形式で表示します。

  4. オンプレミス・データベースおよびOracle Database Cloud Serviceデータベースのデータベース・キャラクタ・セット。

    移行方法の中には、ソース・データベースとターゲット・データベースで互換性のあるデータベース・キャラクタ・セットを使用している必要があるものがあります。デフォルトでは、データベースはAL32UTF8データベース・キャラクタ・セットを使用するように構成されています。

  5. Oracle Database Cloud Service上に移行するターゲット・データベースのバージョン。

    Oracle Database 12 c以上を使用するOracle Cloudのデータベースは、CDBアーキテクチャを使用します。Enterprise Editionオプションを使用して作成されたデータベースはシングルテナントであり、Enterprise Edition - High PerformanceまたはEnterprise Edition - Extreme Performanceオプションを使用して作成されたデータベースはマルチテナントです。

    • Oracle Database 11gリリース2

    • Oracle Database 12cリリース1

    • Oracle Database 12cリリース2

    • Oracle Database 18c

DBCSデータベースの新しいクラウド・サービスへの移行に関する考慮事項

Oracle Databaseは、Oracle Database Cloud Service環境間で移行できます。

移行に影響を及ぼす可能性のある要因(データベース・ファイルのサイズ、ワークロード・レベル、使用するソフトウェアのバージョンなど)について、現在の環境を確認します。

バージョン、パッチ、記憶域など、移行前のソース・データベースの最適化に影響するターゲット環境の要件を考慮してください。

移行に適したクラウド・サービスの判断に役立つように、次の情報を収集します。

  • ソース・データベースのデータベース・ファイルのサイズを決定し、ターゲット・データベース・システムに割り当てる領域のサイズを決定します。

    移行するデータベース内のデータベース・ファイルの合計サイズ(Redoログのサイズなど)は、次の問合せを実行して確認できます。

    SELECT SUM(BYTES)/1024/1024 SIZE_IN_MB FROM DBA_SEGMENTS;

    Redoログのサイズを確認するには、V$LOG動的ビューを問い合せます。

    SELECT GROUP#, BYTES FROM V$LOG;

  • ワークロード・レベルを決定します。

    Oracle Automatic Workload Repository (AWR)レポートを生成して、ソース・データベースのワークロードのサンプルを見つけることができます。また、自動データベース診断モニター(ADDM)レポートを生成すると、指定したスナップショット間の期間のソース・データベースのパフォーマンスを検出できます。オペレーティング・システムの容量において、タイム・モデル統計、オペレーティング・システム統計および待機イベントは、作業負荷を比較的明確に測定します。

  • ソース・データベースに設定される環境変数を決定します。

    これらの同じ設定をターゲット・データベースで使用できます。

  • ソース・データベースでデータベース・キャラクタ・セットを確認します。

    次の問合せを実行して、データベース・キャラクタ・セットを検索できます。

    SELECT NLS_CHARACTERSET, NLS_NCHAR_CHARACTERSET
 FROM NLS_DATABASE_PARAMETERS;

    ターゲット・データベースにもこれらのキャラクタ・セットが必要です。

  • 現在配置されている障害回復計画を決定します。

    たとえば、Oracle Data Guardがすでにデプロイされている場合、移行プロシージャのスタンバイ・データベースを作成できます。オフサイト・バックアップを使用する場合は、Oracle Recovery Manager (RMAN)を使用したOracle Cloudへの新しいバックアップの作成を計画する必要があります。

  • ソース・データベースでOracle GoldenGateが構成されていることを確認してください。

    Oracle GoldenGateの情報を検索するには、ggsciユーティリティを実行します。移行にOracle Data Guardを使用しない場合は、Oracle GoldenGateを代替移行ツールとして使用できます。

移行前のデータベースの簡略化および最適化

データベースを移行する前に、ターゲット・プラットフォーム・バージョンにアップグレードし、未使用のオブジェクトを削除し、他の最適化を実行すると、停止時間を短縮できます。

どのデータベース・プラットフォーム移行にも、次の単純化および最適化戦略に加えて、大量のテストを含める必要があります。

  • 簡潔:バージョンの異なる方から展開したデータベース環境および異なるデータベース管理者が古い情報を含むほとんどのデータベース環境(また、現在のDBAがオブジェクト、データ、ポリシー、または類似オブジェクトなどをシステムで使用する理由を質問する場合があります)。単純化の目的は、管理をより容易にし、信頼性を高めることです。この単純化によって、より可用性の高いシステムに移行します。

    移行前にソース・データベースで必要ないスキーマ・オブジェクトを削除することを検討してください。これによって、移行されるデータの量を削減できます。

  • 最適化:多くの場合、移行には、新機能を含む更新されたデータベース・バージョンが含まれます。移行の実行中に、新機能およびベスト・プラクティスの推奨事項を採用することを検討する必要があります。

    移行が改善される可能性があるため、ターゲット・データベースのバージョンにあわせてソース・データベースをアップグレードすることを検討してください(場合によっては大幅に)。たとえば、データ・ポンプのパラレル機能は、新しいOracle Databaseリリースで拡張されるため、ソース・システムからのデータベース・エクスポートは、ソース・データベースがターゲット・データベースのバージョンと一致するようにアップグレードされると向上し、完了するまでの時間を短縮できます。

    移行をステージで実行できるかどうかを検討します。たとえば、ソース・データベースに大量の読取り専用データが含まれている場合、停止時間を短縮するために、ライブ・データ移行の前に移行される可能性があります。