Oracle Globally Distributed Databaseのパッチ適用およびアップグレード

分散データベースのデプロイへのパッチ適用およびアップグレードには、特別な考慮事項があります。

Oracle Globally Distributed Databaseのパッチ適用

分散データベース環境へのOracleパッチの適用は、単一のシャードまたはすべてのシャードに対して実行できます。ただし、使用する方法は、その環境で使用されているレプリケーション・オプションおよび適用されるパッチのタイプによって異なります。

Oracle Globally Distributed Databaseでは統合パッチ適用を使用してシャード・ディレクタ(GSM)のORACLE_HOMEを更新するため、Oracle Databaseリリース更新をORACLE_HOMEに適用してセキュリティおよびグローバル・データ・サービスの修正を取得する必要があります。

ほとんどのパッチは、単一のシャードに一度に適用できます。ただし、一部のパッチはすべてのシャードに適用する必要があります。分散データベースで使用されているレプリケーション方法に留意して、非分散データベースの場合と同様に、Oracleのベスト・プラクティスを使用して単一のシャードにパッチを適用します。

Oracleのopatchautoは、複数のシャードに一度にパッチを適用するために使用でき、ローリング形式で行うことができます。Data Guard構成は1つずつ適用され、場合によっては(パッチによって異なります) Standby Firstパッチ適用を使用できます。

パッチがマルチシャード問合せ、レプリケーションまたはシャーディング・インフラストラクチャの問題に対処するものである場合は、分散データベース内のすべてのシャードに適用する必要があります。

ノート:

ロジカル・スタンバイはOracle Shardingではサポートされていないため、ローリング・アップグレードではDDLリカバリの問題が発生する可能性があります。これは、ローリング・アップグレード中にフィジカル・スタンバイ・データベースが'一時ロジカル・スタンバイ'になるためです。この問題を回避するには、「ローリング・アップグレードの実行」にある手順に従います。

関連項目:

Oracle OPatchユーザーズ・ガイド

Oracle Data Guard構成でのパッチ適用の詳細は、『Oracle Data Guard概要および管理』を参照してください

Oracle Globally Distributed Databaseコンポーネントのアップグレード

コンポーネントが停止してオンライン状態に戻る際の停止時間を制限し、エラーを回避するには、Oracle Globally Distributed Databaseコンポーネントをアップグレードする順序が重要です。

Oracle Globally Distributed Database環境のアップグレードは、他のOracle Databaseおよびグローバル・サービス・マネージャ環境のアップグレードと大きな違いはありません。ただし、コンポーネントを特定の順序(最初にシャード・カタログ、次にシャード・ディレクタ、最後にシャード)でアップグレードする必要があります。

Oracle Globally Distributed Databaseコンポーネントをアップグレードする前に、次のことが必要です

  • 保留中のMOVE CHUNK操作が進行中の場合は、完了してください。

  • 新しいMOVE CHUNK操作を開始しないでください。

  • アップグレード・プロセス中に新しいシャードを追加しないでください。

  1. 次の点に注意しながら、シャードをアップグレードします。

    • システム管理の分散データベースの場合: Data Guard Broker構成内のシャードの各セットをローリング方式でアップグレードします。

    • ユーザー定義の分散データベースの場合: シャード領域内のシャードの各セットをローリング方式でアップグレードします。

    • コンポジット分散データベースの場合: 特定のシャード領域で、Data Guard Broker構成内のシャードの各セットをローリング方式でアップグレードします。

  2. シャード・カタログ・データベースをアップグレードします。

    最高の結果を得るには、ローリング・データベース・アップグレードを使用してカタログをアップグレードする必要があります(ただし、カタログが使用できない場合、アップグレード中にグローバル・サービスは引き続き使用可能ですが、サービス・フェイルオーバーは発生しません)。

  3. グローバル・サービス・マネージャ(GSM)を実行しているシャード・ディレクタを更新する前に、GDSCTLクライアントの実行に使用され、GSMサーバーを実行しないシャード・ディレクタをアップグレードします。
  4. GSMを実行しているシャード・ディレクタの場合、一度に1つのGSMで次のステップを実行します。

    停止時間をゼロにするには、1つ以上のGSMサーバーが常に稼働している必要があります。カタログより前のバージョンのGSMサーバーは、カタログに変更が発生するまで完全に動作し続けます。

    1. アップグレードするGSMの1つを停止します。

    2. 古いバージョンから新しいバージョンにtnsnames.ora, gsm.ora, gsmwalletディレクトリをコピーします。

      gsm.oraファイルをコピーした後、編集する必要があります。WALLET_LOCATION DIRECTORYパスは古いホームであるgsmwalletディレクトリを指しているため、新しいOracleホームの場所を指すように更新する必要があります。

      理想的には、Oracleベース・ディレクトリのadminなど、Oracleホームの外部にあるディレクトリにウォレットを格納してください。

    3. GDSCTLを使用して新しいGSMに接続し、GSMを起動します。

    4. 古いGSMを停止します。

    例については、Global Data Servicesのパッチ適用およびアップグレードの例を参照してください。

関連項目:

Oracle Database Global Data Services概要および管理ガイド(シャード・ディレクタのアップグレードの詳細)

DBMS_ROLLINGを使用してローリング・アップグレードを実行する方法の詳細は、『Oracle Data Guard概要および管理』を参照してください

Oracle Data Guard構成でのデータベースのアップグレードの詳細は、『Oracle Data Guard概要および管理』を参照してください

ローリング・アップグレードの実行

ロジカル・スタンバイはOracle Globally Distributed Databaseではサポートされていないため、ローリング・アップグレードではDDLリカバリの問題が発生する可能性があります。これは、ローリング・アップグレード中にフィジカル・スタンバイ・データベースが'一時ロジカル・スタンバイ'になるためです。

この問題を回避するには、次のステップを実行します。

  1. シャード・カタログ・データベースを停止します。
    シャード・カタログ・データベースを停止すると、シャード・ディレクタ(GSM)がマスターにならなくなります。この状態ではカタログによってDDLの適用は試みられませんが、シャード・ディレクタは安定した状態で続行され、本番アプリケーションの接続と実行は可能になります。
  2. ローリング・アップグレードを実行します。
  3. ローリング・アップグレードが完了したら、シャード・カタログ・データベースを起動します。

ノート:

ローリング・アップグレードの間の、シャード・カタログの停止中に、一部の操作(自動フェイルオーバーなど)を使用できない場合があります。

Oracle Globally Distributed Databaseのダウングレード

Oracle Globally Distributed Databaseでは、ダウングレードはサポートされていません。

シャード・カタログおよびシャードはダウングレードできません。