日本語PDF

14 DBMS_ROLLINGを使用したローリング・アップグレードの実行

Oracle Active Data Guardを使用したローリング・アップグレード機能は、ローリング・アップグレードを実行する効率的な方法を提供します。

これはDBMS_ROLLING PL/SQLパッケージを使用すると実装され、Oracle Data Guard構成内のデータベース・ソフトウェアをローリング方式でアップグレードできます。Oracle Active Data Guardを使用したローリング・アップグレード機能には、Oracle Active Data Guardオプションのライセンスが必要です。

この機能は、Oracle Database 12cの最初パッチセット以降、データベース・バージョン・アップグレードを実行するために使用できます。最初のOracle Database 12cパッチセットより前のバージョンからアップグレードするためには使用できません。つまり、Oracle Database 11gからOracle Database12cへのアップグレード時またはOracle Database 12cの初期リリースからOracle Database 12cの最初のパッチセットへのアップグレード時には、手動の一時ロジカル・スタンバイ・アップグレード手順を引き続き使用する必要があります。

DBMS_ROLLINGパッケージは、Oracle Data Guardのスイッチオーバーを実行してプライマリ・データベース・サービスの停止時間を最小化します。DBMS_ROLLINGを使用する前に、スイッチオーバーを受け入れるようにOracle Data Guard環境を適切に構成する必要があります。設定要件は、Oracle Data Guard BrokerがDBMS_ROLLINGの実行中にアクティブかどうかによって異なります。

• ブローカがDBMS_ROLLING中にアクティブになる場合、ブローカにスイッチオーバーを設定する詳細について、Oracle Data Guard Brokerを参照してください。

• ブローカがDBMS_ROLLING中にアクティブにならない場合、ロジカル・スタンバイ・データベースが関与するロールの推移を参照してください。Oracle Data Guard Brokerが存在しないということは、LOG_ARCHIVE_DEST_nパラメータをターゲット・プライマリ・データベース上でREDO送信がスイッチオーバー後に再開するように適切に構成する必要があることを意味します。

また、この機能は、Oracle Database 12c リリース1 (12.1)以降、他のデータベース・メンテナンス・タスクにすぐに使用できます。メンテナンスが実行されるデータベースは、Oracle 12.1以上で動作する必要があります。このようなメンテナンス・タスクには、次のものが含まれます。

• パーティション化されていない表へのパーティションの追加

• BasicFiles LOBからSecureFiles LOBへの変更

• CLOBとして格納されるXMLTypeからバイナリXMLとして格納されるXMLtypeへの変更

• OLTP圧縮化対象への表の変更

次のトピックを参照してください。

• ローリング・アップグレードの新しい概念

• DBMS_ROLLINGアップグレードとCDB

• DBMS_ROLLINGの使用の概要

• ローリング・アップグレードの計画

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

• ローリング・アップグレードの監視

• ローリング・アップグレードのロールバック

• ローリング・アップグレード中に発生したロール変更の処理

• ローリング・アップグレードの例

14.1 ローリング・アップグレードの新しい概念

Oracle Data Guard構成内のデータベース・ソフトウェアをローリング方式でアップグレードするには、最初にフィジカル・スタンバイを将来のプライマリ・データベースとして指定します。

概念的には、ローリング・アップグレード・プロセスはOracle Data Guard構成を2つのグループに分割します。先行グループ(LG)と後続グループ(TG)です。

先行グループのデータベースは先にアップグレードされるので先行グループという名前です。先行グループには、指定した将来のプライマリ・データベースと、それを保護するように構成できるフィジカル・スタンバイが含まれます。将来のプライマリは最初にロジカル・スタンバイ・データベースに変換されてから、新しいデータベース・ソフトウェアがそこにインストールされ、アップグレード・プロセスが実行します。先行グループのその他のスタンバイ・データベースも、この時点でそのソフトウェアをアップグレードする必要があります。

後続グループには、元のプライマリ・データベースと、ローリング・アップグレード・プロセス中に元のプライマリを保護するように構成できるフィジカル・スタンバイが含まれます。先行グループのデータベースのアップグレード・プロセス中は、ユーザー・アプリケーションは引き続き元のプライマリに接続し、変更できます。先行グループのすべてのデータベースがアップグレードされ、アップグレード・ウィンドウ中に元のプライマリ・データベースで生成された変更が適用されることにより、将来のプライマリが元のプライマリに追い付くまで、後続グループのデータベースは古いデータベース・ソフトウェアの実行を継続します。この時点で、スイッチオーバーはプライマリ・ロールの指定した将来のプライマリ・データベースへの転送を完了し、ユーザー・アプリケーションは新しいプライマリ・データベースにスイッチオーバーされています。次に新しいソフトウェアが後続グループの一部であるデータベースにインストールされ、新しいプライマリ・データベースへのスタンバイとして構成内に回復されます。

それぞれのグループのスタンバイは先行グループ・スタンバイ(LGS)および後続グループ・スタンバイ(TGS)と呼ばれます。指定した将来のプライマリ以外の、先行グループのその他のすべてのスタンバイは、フィジカル・スタンバイにのみなることができます。後続グループはフィジカルおよびロジカル・スタンバイの両方を含むことができます。そのスタンバイ・タイプを区別する必要がある場合は、後続グループ・フィジカル(TGP)と後続グループ・ロジカル(TGL)と呼びます。指定した将来のプライマリも、先行グループ・マスター(LGM)と呼ばれ、元のプライマリ・データベースは後続グループ・マスター(TGM)と呼ばれます。

DBMS_ROLLINGパッケージは次のように、ローリング・アップグレード・プロセスの堅牢性を向上させます。

• ローリング・アップグレード・プロセス中にエラーを処理できます。元のプライマリまたはTGMデータベースの失敗が許されます。後続グループ内のその他のフィジカル・スタンバイには通常のフェイルオーバー操作を開始でき、その後で新しいプライマリ・データベースをTGMとして指定します。

• ローリング・アップグレード・プロセス中にLGM (指定した将来のプライマリ)のデータ保護が可能です。LGMデータベースへのフィジカル・スタンバイを設定でき、アップグレード・プロセス中にそれを保護でき、アップグレード後にデータ消失ゼロも達成できます。LGMが正常にアップグレードされたら、フィジカル・スタンバイ・データベースへのフェイル・オーバーにより、LGMでの失敗は調整できます。次にファイルオーバー・ターゲット・データベースを指定して、LGMのロールを引き継ぐことができます。

表14-1では、スイッチオーバー操作の前と後の、TGPスタンバイとLGPスタンバイの特徴を比較します。

表14-1 後続グループ・フィジカル(TGP)と先行グループ・フィジカル(LGP)

スタンバイ・タイプ	スイッチオーバー前	スイッチオーバー後	ノート
後続グループ・フィジカル(TGP)	低い適用ラグ より低いデータ消失リスク	高い適用ラグ より高いデータ消失リスク	プライマリ・ロールへのフェイルオーバーが可能 元のプライマリのようにフラッシュバックが必要
先行グループ・フィジカル(LGP)	高い適用ラグ より高いデータ消失リスク	低い適用ラグ より低いデータ消失リスク	一時ロジカル・スタンバイ・ロールへのファイルオーバーが可能 元のプライマリのようなフラッシュバックは不要

関連項目:

• DBMS_ROLLING PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

• DBMS_ROLLING PL/SQLパッケージを使用したアップグレードの実行中に、アップグレードに含まれるいずれかの表にサポートされないデータ型が含まれるかどうかを判別する方法の詳細は、「ローリング・アップグレード中にサポートされない表」を参照してください。

• DBMS_ROLLINGアップグレードの場合でのみサポートされるPL/SQLパッケージの詳細は、「DBMS_ROLLINGアップグレードの場合でのみ使用可能な追加のPL/SQLパッケージのサポート」を参照してください。

14.1.1 Data GuardブローカでのDBMS_ROLLINGアップグレードのサポート

Oracle Database 12cリリース2 (12.2.0.1)以降、DBMS_ROLLINGローリング・アップグレード時にData Guard Brokerは残ることができるようになり、無効化する必要はなくなりました。

Data Guard BrokerでのDBMS_ROLLINGアップグレードのサポートについては、次の点に注意してください。

• ブローカ・サポートは、ブローカが呼出し時に有効であればデフォルトでDBMS_ROLLING.BUILD_PLANプロシージャの実行時に有効です。ブローカ・サポートが有効になっている場合、ブローカは必要に応じて元のプライマリ・データベースとローリング・アップグレード・ターゲットからREDO転送先を設定します。

• DBMS_ROLLINGアップグレードを開始する前に、ファスト・スタート・フェイルオーバー機能を無効化する必要があります。

• ローリング・アップグレードの進行中にファスト・スタート・フェイルオーバーを有効化しようとすると、拒否されます。

• ローリング・アップグレードの進行中は、ロールの変更は現在のプライマリ・データベースを保護しているスタンバイ・データベースに対してのみ許可されます。ブローカは、SHOW CONFIGURATIONコマンドの実行時にローリング・アップグレード・ターゲットのロールをTransient Logical Standbyとしてレポートし、構成ステータスをROLLING DATABASE MAINTENANCE IS IN PROGRESSとしてレポートします。元のプライマリ・データベースとアップグレード・ターゲットの両方を保護しているスタンバイ・データベースがある場合、このトポロジは、SHOW CONFIGURATIONコマンドが現在のプライマリから発行されたときと同様にアップグレード・ターゲットから発行されたとき(プライマリ・データベースとして引継ぎが完了する前)に反映されます

• ブローカは、現在のプライマリを保護していないフィジカル・スタンバイへのロールの変更を回避します。これにより、スイッチオーバー・フェーズの前は後続グループ・スタンバイへのロールの変更が許可され、スイッチオーバー・フェーズの後は先行グループ・スタンバイへのロールの変更のみが許可されます。

• アップグレード・プロセスの開始時に、アップグレード・ターゲットがOracle RACデータベースの場合、ブローカはターゲット・スタンバイを自動的に1つのインスタンスに削減して、アップグレードの続行を許可します。ブローカがない環境では、ターゲットで複数のインスタンスが実行されていることが検出された場合、アップグレードの開始は拒否されます。

• ブローカは、ローリング・アップグレードの過程で必要に応じてOracle ClusterwareおよびGlobal Data Servicesに通知します。

• ロールの推移は通常、ブローカを使用して実行されますが、ローリング・アップグレードのスイッチオーバー・ステップは引き続きDBMS_ROLLING.SWITCHOVERプロシージャを使用して実行する必要があります。

• PL/SQLパッケージDBMS_ROLLINGを使用して実行されているローリング・アップグレードのステータスについての情報は、ブローカのコマンドSHOW CONFIGURATIONおよびSHOW DATABASEの出力に表示されます。

  SHOW CONFIGURATIONコマンドは、アップグレード・ターゲットのロールとして一時ロジカル・スタンバイ・データベース、構成ステータスとしてROLLING DATABASE MAINTENANCE IN PROGRESSを示します。この出力の例は次のとおりです。

  Configuration - DRSolution
  
    Protection Mode: MaxPerformance
    Members:
    North_Sales - Primary database
      South_Sales - Transient logical standby database
  
  Fast-Start Failover: DISABLED
  
  Configuration Status:
     ROLLING DATABASE MAINTENANCE IN PROGRESS

  SHOW DATABASEコマンドは、アップグレード・ターゲットおよび後続または先行スタンバイに対して、現在のローリング・アップグレードの進行に応じてWARNINGを該当するORAエラーとともに示します。この出力の例は次のとおりです。

  Database - South_Sales
  
    Role: Physical standby database
    Intended State: APPLY-ON
    Transport Lag: ***
    Apply Lag: ***
    Average Apply Rate: ***
    Real Time Query: OFF
    Instance(s):
      South
    Database Warning(s):
      ORA-16866: database converted to transient logical standby database for rolling
      database maintenance
  Database Status:
  WARNING

関連項目:

• DBMS_ROLLING

• SHOW CONFIGURATION

• SHOW DATABASE

14.2 DBMS_ROLLINGアップグレードとCDB

マルチテナント・コンテナ・データベース(CDB)でDBMS_ROLLINGを使用してローリング・アップグレードを実行するステップは、非CDB環境と変わりませんが、追加の要件と考慮事項があります。

CDBでのDBMS_ROLLINGアップグレードに固有の要件

DBMS_ROLLINGを使用してCDBでローリング・アップグレードを実行するための追加の要件は、次のとおりです。

• LOG_ARCHIVE_DEST_nパラメータで参照されるTNSサービスは、宛先データベースのルート・コンテナに解決されるサービスである必要があります。DBMS_ROLLINGを支援するプロセスでは、ルート・コンテナからのみ実行可能な数多くの操作が実行されます。

• DBMS_ROLLING.SWITCHOVERを呼び出す前に、一時ロジカル・スタンバイ上のすべてのコンテナ・データベースをプラグインして開く必要があります。これにより、特定のPDBに適用できないためにロジカル・スタンバイ適用エンジンが停止する可能性が排除されます。

DBMS_ROLLINGを使用したローリング・アップグレードの例は、例14-5を参照してください。

CDBでのDBMS_ROLLINGアップグレードの追加の考慮事項

DBMS_ROLLINGアップグレードの進行中は、アプリケーション・コンテナにインストールされたアプリケーションのインストール、アップグレード、パッチ適用はサポートされません。

• DBMS_ROLLINGアップグレードの進行中に、DDLを実行してアプリケーション・コンテナのインストール、アップグレード、パッチ適用を開始すると、エラーが返されます。(DBMS_ROLLINGアップグレードは続行されます。)

• アプリケーション・コンテナのアップグレードが進行中の場合、DBMS_ROLLINGアップグレードを開始しようとすると、エラーが発生します。(アプリケーション・コンテナのアップグレードは続行されます。)

• DBMS_ROLLINGアップグレードが実行され、データベースの互換性が12.2以上に設定されている場合、アプリケーション・コンテナのレプリケーションがサポートされます。DBMS_ROLLINGアップグレードを除き、ロジカル・スタンバイはアプリケーション・コンテナのサポートを提供しません。このようなコンテナはスキップされ、アプリケーション・コンテナがスキップされたことを示すメッセージがアラート・ログに書き込まれます。

• DBMS_ROLLINGを使用してアップグレードするCDBには、異なる文字セットのプラガブル・データベース(PDB)を含めることができます。

14.3 DBMS_ROLLINGの使用の概要

DBMS_ROLLING PL/SQLパッケージを使用したローリング・アップグレード・プロセスには、指定、コンパイル、実行という3つのステージがあります。

1. 指定: 最初に、ローリング・アップグレード・プロセスの実装方法を指定します。将来のプライマリ・データベースを指定することは必須です。この動作は概念的には先行および後続グループの作成です。この時点では、先行グループのみにLGMが含まれます。オプションでLGMを保護する別のスタンバイを指定できます。

   指定フェーズでは次のプロシージャを使用します。

   • DBMS_ROLLING.INIT_PLAN

   • DBMS_ROLLING.SET_PARAMETER

2. コンパイル: これはDBMS_ROLLING.BUILD_PLANプロシージャを呼び出すことで開始されます。BUILD_PLANプロシージャは、ローリング・アップグレードに関与するすべてのデータベースと通信し、ローリング・アップグレード計画を組み立てます。BUILD_PLANプロシージャも、既存のローリング・アップグレード計画を変更するために呼び出されます。変更は、DBMS_ROLLINGパラメータに対する変更の後、およびフェイルオーバーの結果としてのトポロジに対する変更の後に必要です。正常なローリング・アップグレードを確実にするために数多くの検証が必要なため、関与しているすべてのデータベースがBUILD_PLANプロシージャの実行中にアクセス可能である必要があります。

3. 実行: ローリング・アップグレードの実行には5つのステージがあります。

   ステージ1: DBMS_ROLLING.START_PLANプロシージャはローリング・アップグレードの実行を開始します。これによりLGMデータベースがロジカル・スタンバイに変換され、LGMでSQL Applyプロセスが開始します。

   ステージ2: 先行グループの一部のデータベースでデータベース・ソフトウェアをアップグレードします。LGMでアップグレード・スクリプトも実行します。これの完了後、LGMデータベースでSQL Applyプロセスを再起動する必要があります。(アップグレード・スクリプトの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。)より高いバージョンのバイナリを使用して再マウントすることにより、このステージ中に先行グループ・フィジカル・スタンバイも対応されます。これらのデータベースはLGMからREDOのリカバリによりアップグレードされます。

   ステージ3: 適用ラグが指定したしきい値(デフォルトでは10分に設定されていますが、指定ステージで変更できます)に達すると、DBMS_ROLLING.SWITCHOVERプロシージャはスイッチオーバー処理を続行します。スイッチオーバーが完了すると、LGMはプライマリ・データベースになります。

   ステージ4: LGMは新しいデータベース・ソフトウェアを実行するプライマリ・データベースとなり、先行グループ内のデータベースはそれを保護します。TGMはマウントされ、後続グループのデータベースはまだ古いバージョンのデータベース・ソフトウェアを実行しています。データベース・ソフトウェアのアップグレードと、より高いバージョンのバイナリへのデータベースの再マウントにより、アップグレード用にTGMおよびTGSデータベースを準備する必要があります。(アップグレード・スクリプトの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。)

   ステージ5: 現在のプライマリ・データベース(元のLGM)でDBMS_ROLLING.FINISH_PLANプロシージャを実行します。後続グループのすべてのデータベースを、現在のプライマリ・データベースのスタンバイになるように修復し、Applyプロセスを再起動します。FINISH_PLANプロシージャは、後続グループ内のすべてのデータベースが新しいリリースにアップグレードされるのを待機します(後続グループのデータベースのデータベース・ソフトウェアはステージ4で変更されましたが、後続グループのデータベースのデータ・ディクショナリは後続グループのロジカル・スタンバイを除き、LGMデータベースでアップグレード中に生成されたREDOのメディア・リカバリに基づいて更新されます)。

ローリング・アップグレードが正常に実行された後は、DBMS_ROLLING.DESTROY_PLANプロシージャを呼び出すことで、ローリング・アップグレードの指定を削除できます。

14.4 ローリング・アップグレードの計画

ローリング・アップグレードの計画は、正常にアップグレードするために不可欠です。計画フェーズでは、様々なアップグレード・パラメータを指定し、アップグレード計画を作成します。

パラメータとアップグレード計画は、環境に一意なすべての操作の詳細に焦点を当てます。アップグレード計画ではサイト特有の検証を実行し、ローリング・アップグレードを中断させる可能性のある構成およびリソースの問題を確認できます。

アップグレード・パラメータの定義およびアップグレード計画の作成に必要なタスクは、次のとおりです。

• アップグレード・パラメータを初期化します

• 現在のアップグレード・パラメータの値を表示します

• 必要に応じてアップグレード・パラメータの値を変更します

• アップグレード計画を作成します。

• 現在のアップグレード計画を表示します

• 必要に応じてアップグレード計画を修正します

これらの各ステップの詳細は、この項の残りの部分で説明します。これらは、表示されている順序で実行する必要があります。

1. 計画パラメータは、カスタマイズされる前に、システム生成のデフォルト値に初期化される必要があります。計画パラメータを初期化するには、DBMS_ROLLING.INIT_PLANプロシージャを呼び出します。このプロシージャは将来のプライマリ・データベースのDB_UNIQUE_NAME(先行グループのマスターまたはLGM)を識別します。LGMはSTART_PLANプロシージャ・コールの一部としてロジカル・スタンバイ・データベースに変換されます。次に、bostonが将来のプライマリ・データベースとして識別される、INIT_PLANプロシージャを呼び出すサンプルを示します。

   DBMS_ROLLING.INIT_PLAN(future_primary=>'boston');
   

   INIT_PLANプロシージャはシステム生成の計画パラメータの最初のセットを戻します。ここでは、ローリング・アップグレードの参加者としてDG_CONFIGのinit.oraパラメータに指定した各フィジカルおよびロジカル・スタンバイ・データベースを追加します。その他のデータベース(GoldenGateダウンストリーム・デプロイメントをサービスするダウンストリーム・データベースやスナップショット・スタンバイなど)は自動的に除外されます。

   デフォルトでは、将来のプライマリ以外のスタンバイ・データベースはプライマリ・データベースを保護するように構成され、ローリング・アップグレードの必須参加者として構成されます。

   データベース関連のパラメータを定義したら、INIT_PLANプロシージャでシステム提供のデフォルトを使用して操作パラメータを定義します。ほとんどの場合、計画パラメータは計画検証の準備ができていますが、必要性を満たしていることを確認するために、各パラメータを確認してください。

   DESTROY_PLANプロシージャを呼び出してローリング・アップグレードに関連するすべての状態を削除するまで、計画パラメータはデータベース内に保持されます。

2. INIT_PLANプロシージャが完了したら、DBA_ROLLING_PARAMETERSビューを問い合せて計画パラメータと現在の値を表示できます。計画パラメータはグローバルまたはローカルのいずれかの範囲です。グローバル・パラメータはローリング・アップグレード全体の属性で、データベースの参加者とは独立しています。グローバル・パラメータではSCOPE列にNULL値が含まれます。ローカル・パラメータではSCOPE列に関連する特定のデータベース名が含まれます。問合せの例を次に示します。

   SQL> select scope, name, curval from dba_rolling_parameters order by scope, name;
   
   SCOPE          NAME                        CURVAL
   -------------- ------------------------    ------------------------------
   seattle        INVOLVEMENT                 FULL
   seattle        MEMBER                      NONE
   boston         INVOLVEMENT                 FULL
   boston         MEMBER                      TRAILING
   oakland        INVOLVEMENT                 FULL
   oakland        MEMBER                      TRAILING
   atlanta        INVOLVEMENT                 FULL
   atlanta        MEMBER                      LEADING
                  ACTIVE_SESSIONS_TIMEOUT     3600
                  ACTIVE_SESSIONS_WAIT        0
                  BACKUP_CONTROLFILE          rolling_change_backup.f
                  DGBROKER                    0
                  DICTIONARY_LOAD_TIMEOUT     3600
                  DICTIONARY_LOAD_WAIT        0
                  DICTIONARY_PLS_WAIT_INIT    300
                  DICTIONARY_PLS_WAIT_TIMEOUT 3600
                  EVENT_RECORDS               10000
                  FAILOVER                    0
                  GRP_PREFIX                  DBMSRU_
                  IGNORE_BUILD_WARNINGS       0
                  IGNORE_LAST_ERROR           0
                  LAD_ENABLED_TIMEOUT         600
                  LOG_LEVEL                   INFO
                  READY_LGM_LAG_TIME          600
                  READY_LGM_LAG_TIMEOUT       60
                  READY_LGM_LAG_WAIT          0
                  SWITCH_LGM_LAG_TIME         600
                  SWITCH_LGM_LAG_TIMEOUT      60
                  SWITCH_LGM_LAG_WAIT         1
                  SWITCH_LGS_LAG_TIME         60
                  SWITCH_LGS_LAG_TIMEOUT      60
                  SWITCH_LGS_LAG_WAIT         0
                  UPDATED_LGS_TIMEOUT         10800
                  UPDATED_LGS_WAIT            1
                  UPDATED_TGS_TIMEOUT         10800
                  UPDATED_TGS_WAIT            1
   35 rows selected.

   出力例で、データベースatlanta、boston、oaklandおよびseattleがすべてDG_CONFIGにより検出され、現在の計画のパラメータに割り当てられました。

   関連項目:

   • DBA_ROLLING_PARAMETERSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

3. 既存のローリング・アップグレード・パラメータを変更するには、DBMS_ROLLING.SET_PARAMETER PL/SQLプロシージャを使用します。次に、SET_PARAMETERプロシージャの使用例を示します。

   DBMS_ROLLING.SET_PARAMETER(
     scope IN VARCHAR2,
     name IN VARCHAR2,
     value IN VARCHAR2);
   

   SCOPEにはローカル・パラメータ用のDB_UNIQUE_NAME値、またはグローバル・パラメータ用のNULLのいずれかを指定します。データベース特有ではないパラメータにはNULLの範囲を指定する必要はありません。

   NAMEは変更するパラメータの名前です。

   VALUEにはそのパラメータの値を指定します。NULLの値はパラメータをシステム提供のデフォルト(存在する場合)に戻します。

   関連項目:

   • すべての使用可能なローリング・アップグレード・パラメータの完全なリストは、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

   次の例では、いくつかのローリング・アップグレード・パラメータの使用例を示しています。

4. すべての必要なパラメータが指定されたら、アップグレード計画を作成します。アップグレード計画は、Oracle Data Guard構成をローリング・アップグレードに沿ってガイドする、カスタム生成の手順のセットです。(生成される計画は、Data Guardブローカを使用して構成を管理するかどうかによって異なります。)

   アップグレード計画を作成するには、DBA_ROLLING.BUILD_PLAN PL/SQLプロシージャを使用します。このプロシージャには、計画パラメータで説明したとおりの構成と、すべてのインスタンスが開始され、ネットワーク経由でアクセス可能であることが必要です。

   プロシージャは次のように呼び出されます。

   DBMS_ROLLING.BUILD_PLAN;
   

   プロシージャはすべての入力をDBA_ROLLING_PARAMETERSビューから取得するため、指定する引数はありません。プロシージャは計画パラメータを検証し、ログ転送やフラッシュ・リカバリ領域の設定など、サイト特有のリソースの検証を実行します。通常、ベスト・プラクティスの値の条件を満たさない構成設定は警告として扱われ、DBA_ROLLING_EVENTSビューに記録されます。デフォルトで、IGNORE_BUILD_WARNINGSパラメータは1に設定され、警告によって、アップグレード計画が使用可能な状態に達するのを妨げられないことを意味します。計画の策定時に、より厳しいルールの実施が必要な場合には、このパラメータを0に設定できます。

   ノート:

   計画の生成時に実行される検証はローリング・アップグレードに特有です。これはアップグレードの準備状況を評価するアップグレード前情報ツールを実行する、推奨プラクティスのかわりではありません。

   計画の生成後、次のステップに移動してそれを表示し、問題がないかどうか診断して、必要ならば修正します。

5. BUILD_PLANプロシージャが正常に戻った後、完全なアップグレード計画がDBA_ROLLING_PLANビューで表示可能です。ビューの各レコードは、実行がスケジュールされた特定の手順を識別します。

   次の出力は、ローリング・アップグレード計画の表示例です。

   SQL> SELECT instid, target, phase, description FROM DBA_ROLLING_PLAN;
   
   INSTID TARGET       PHASE   DESCRIPTION
   ------ ------------ ------- -----------------------------------------------------
        1 seattle      START   Verify database is a primary
        2 seattle      START   Verify MAXIMUM PROTECTION is disabled
        3 boston       START   Verify database is a physical standby
        4 boston       START   Verify physical standby is mounted
        5 oakland      START   Verify database is a physical standby
        6 oakland      START   Verify physical standby is mounted
        7 atlanta      START   Verify database is a physical standby
        8 atlanta      START   Verify physical standby is mounted
        9 seattle      START   Verify server parameter file exists and is modifiable
       10 boston       START   Verify server parameter file exists and is modifiable
       11 oakland      START   Verify server parameter file exists and is modifiable
       12 atlanta      START   Verify server parameter file exists and is modifiable
       13 seattle      START   Verify Data Guard Broker configuration is disabled
       14 boston       START   Verify Data Guard Broker configuration is disabled
       15 oakland      START   Verify Data Guard Broker configuration is disabled
       16 atlanta      START   Verify Data Guard Broker configuration is disabled
       17 seattle      START   Verify flashback database is enabled
       18 seattle      START   Verify available flashback restore points
       19 boston       START   Verify flashback database is enabled
       20 boston       START   Verify available flashback restore points
       21 oakland      START   Verify flashback database is enabled
       22 oakland      START   Verify available flashback restore points
       23 atlanta      START   Verify flashback database is enabled
       24 atlanta      START   Verify available flashback restore points
       25 boston       START   Scan LADs for presence of atlanta destination
       26 boston       START   Test if atlanta is reachable using configured TNS service
       27 boston       START   Stop media recovery
       28 oakland      START   Stop media recovery
       29 atlanta      START   Stop media recovery
       30 boston       START   Drop guaranteed restore point DBMSRU_INITIAL
       31 boston       START   Create guaranteed restore point DBMSRU_INITIAL
       32 oakland      START   Drop guaranteed restore point DBMSRU_INITIAL
       33 oakland      START   Create guaranteed restore point DBMSRU_INITIAL
       34 atlanta      START   Drop guaranteed restore point DBMSRU_INITIAL
       35 atlanta      START   Create guaranteed restore point DBMSRU_INITIAL
       36 seattle      START   Drop guaranteed restore point DBMSRU_INITIAL
       37 seattle      START   Create guaranteed restore point DBMSRU_INITIAL
   
   INSTID TARGET       PHASE   DESCRIPTION
   ------ ------------ ------- ----------------------------------------------------------
       38 boston       START   Start media recovery
       39 boston       START   Verify media recovery is running
       40 oakland      START   Start media recovery
       41 oakland      START   Verify media recovery is running
       42 atlanta      START   Start media recovery
       43 atlanta      START   Verify media recovery is running
       44 seattle      START   Verify user_dump_dest has been specified
       45 seattle      START   Backup control file to rolling_change_backup.f
       46 boston       START   Verify user_dump_dest has been specified
       47 boston       START   Backup control file to rolling_change_backup.f
       48 oakland      START   Verify user_dump_dest has been specified
       49 oakland      START   Backup control file to rolling_change_backup.f
       50 atlanta      START   Verify user_dump_dest has been specified
       51 atlanta      START   Backup control file to rolling_change_backup.f
       52 seattle      START   Get current redo branch of the primary database
       53 boston       START   Wait until recovery is active on the primary's redo branch
       54 boston       START   Stop media recovery
       55 seattle      START   Execute dbms_logstdby.build
       56 boston       START   Convert into a transient logical standby
       57 boston       START   Open database
       58 boston       START   Configure logical standby parameters
       59 boston       START   Start logical standby apply
       60 boston       START   Get redo branch of transient logical standby
       61 boston       START   Get reset scn of transient logical redo branch
       62 atlanta      START   Stop media recovery
       63 atlanta      START   Flashback database
       64 seattle      START   Disable log file archival to atlanta
       65 boston       START   Enable log file archival to atlanta
       66 boston       START   Wait for log archive destination to atlanta to reach a valid state
       67 atlanta      START   Wait until transient logical redo branch has been registered
       68 atlanta      START   Start media recovery
       69 atlanta      START   Wait until v$dataguard_stats has been initialized
       70 atlanta      START   Wait until recovery has started on the transient redo branch
       71 seattle      START   Log pre-switchover instructions to events table
       72 boston       START   Record start of user upgrade of boston
       73 boston       SWITCH  Verify database is in OPENRW mode
       74 boston       SWITCH  Record completion of user upgrade of boston
   
   INSTID TARGET       PHASE   DESCRIPTION
   ------ ------------ ------- ---------------------------------------------------------
       75 boston       SWITCH  Scan LADs for presence of seattle destination
       76 boston       SWITCH  Scan LADs for presence of oakland destination
       77 boston       SWITCH  Scan LADs for presence of atlanta destination
       78 boston       SWITCH  Test if seattle is reachable using configured TNS service
       79 boston       SWITCH  Test if oakland is reachable using configured TNS service
       80 boston       SWITCH  Test if atlanta is reachable using configured TNS service
       81 seattle      SWITCH  Enable log file archival to boston
       82 boston       SWITCH  Enable log file archival to atlanta
       83 boston       SWITCH  Start logical standby apply
       84 atlanta      SWITCH  Start media recovery
       85 atlanta      SWITCH  Wait until upgrade redo has been fully recovered
       86 boston       SWITCH  Wait until apply lag has fallen below 600 seconds
       87 seattle      SWITCH  Log post-switchover instructions to events table
       88 seattle      SWITCH  Switch database to a logical standby
       89 boston       SWITCH  Wait until end-of-redo has been applied
       90 oakland      SWITCH  Wait until end-of-redo has been applied
       91 seattle      SWITCH  Disable log file archival to oakland
       92 boston       SWITCH  Switch database to a primary
       93 oakland      SWITCH  Stop media recovery
       94 seattle      SWITCH  Synchronize plan with new primary
       95 seattle      FINISH  Verify only a single instance is active
       96 seattle      FINISH  Verify database is mounted
       97 seattle      FINISH  Flashback database
       98 seattle      FINISH  Convert into a physical standby
       99 oakland      FINISH  Verify database is mounted
      100 oakland      FINISH  Flashback database
      101 boston       FINISH  Verify database is open
      102 boston       FINISH  Save the DBID of the new primary
      103 boston       FINISH  Save the logminer session start scn
      104 seattle      FINISH  Wait until transient logical redo branch has been registered
      105 oakland      FINISH  Wait until transient logical redo branch has been registered
      106 seattle      FINISH  Start media recovery
      107 oakland      FINISH  Start media recovery
      108 seattle      FINISH  Wait until apply/recovery has started on the transient branch
      109 oakland      FINISH  Wait until apply/recovery has started on the transient branch
      110 seattle      FINISH  Wait until upgrade redo has been fully recovered
   
   INSTID TARGET       PHASE   DESCRIPTION
   ------ ------------ ------- ------------------------------------------------
      111 oakland      FINISH  Wait until upgrade redo has been fully recovered
      112 seattle      FINISH  Drop guaranteed restore point DBMSRU_INITIAL
      113 boston       FINISH  Drop guaranteed restore point DBMSRU_INITIAL
      114 oakland      FINISH  Drop guaranteed restore point DBMSRU_INITIAL
      115 atlanta      FINISH  Drop guaranteed restore point DBMSRU_INITIAL
   
   115 rows selected.
   
   SQL> 
   

   このビューの列には次の情報が表示されます。

   • INSTID - 手順IDで、実行する手順の順序です。手順は通常、グループ内で実行されます。

   • PHASE - アップグレード計画の各手順は特定のフェーズと関連付けられます。フェーズとはDBMS_ROLLING PL/SQLパッケージ内のプロシージャにより実行される手順の論理グループです。DBMS_ROLLINGプロシージャが呼び出されると、そのフェーズのアップグレード計画内の関連するすべての手順が実行されます。可能なフェーズは次のとおりです。

     • START: リストア・ポイントの取得、一時ロジカル・スタンバイ・データベースのインスタンス化、LGSデータベースの構成などの、設定に関連するアクティビティから構成されます。このフェーズのアクティビティはDBMS_ROLLING.START_PLANプロシージャを呼び出すと開始します。「ローリング・アップグレードの実行」のステップ1を参照してください。

     • SWITCH: 一時ロジカル・スタンバイの新しいプライマリ・データベースへのスイッチオーバーに関連するアクティビティから構成されます。このフェーズのアクティビティはDBMS_ROLLING.SWITCHOVERプロシージャを呼び出すと開始します。「ローリング・アップグレードの実行」のステップ3を参照してください。

     • FINISH: アップグレードREDOのリカバリ用のスタンバイ・データベースの構成に関連するアクティビティから構成されます。このフェーズのアクティビティはDBMS_ROLLING.FINISH_PLANプロシージャを呼び出すと開始します。「ローリング・アップグレードの実行」のステップ5を参照してください。

   • EXEC_STATUS - 手順の全体的なステータスです。

   • PROGRESS - 手順の実行の進捗です。REQUESTINGの値は、実行のためにターゲット・データベースに転送されている手順を示します。EXECUTINGの値は、アクティブに実行中の手順を示します。REPLYINGの値は、完了情報が戻されていることを示します。

   • DESCRIPTION - 実行をスケジュールされた特定の操作です。

   • TARGET - 指定の手順が実行されるサイトです。

   • EXEC_INFO - 手順に関連する追加のコンテキスト情報です。

   関連項目:

   • DBA_ROLLING_PLANビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

6. ローリング・アップグレードまたはデータベース構成に変更があった後は、アップグレード計画は修正される必要があります。構成変更には次のものがあります。

   • 任意のデータベースのローリング・アップグレードへの参加時のinit.oraパラメータ・ファイルの変更

   • フェイルオーバー・イベントの結果としてのデータベース・ロールの変更

   • ローリング・アップグレード・パラメータの変更

   アクティブなアップグレード計画を修正するには、BUILD_PLANプロシージャを再度呼び出します。場合によっては、BUILD_PLANプロシージャで、特定の変更が受け入れられない場合に、エラーが発生する可能性があります。たとえば、ACTIVE_SESSIONS_WAITパラメータの設定は、スイッチオーバーがすでに発生していると、何も影響しません。

   パラメータを個別に処理するのではなく、BUILD_PLANプロシージャを呼び出して、パラメータのグループの変更を処理することをお薦めします。

例14-1 適用ラグ要件を強制するスイッチオーバーの設定

次の例で、将来のプライマリにスイッチオーバーする前に、適用ラグが60秒を下回るのを待つように計画を構成する方法を示します。

DBMS_ROLLING.SET_PARAMETER('SWITCH_LGM_LAG_WAIT', '1');
DBMS_ROLLING.SET_PARAMETER('SWITCH_LGM_LAG_TIME', '60');

例14-2 ログのデフォルト値へのリセット

次の例では、LOG_LEVELグローバル・パラメータのデフォルト値へのリセットを示します。

DBMS_ROLLING.SET_PARAMETER (
  name=>'LOG_LEVEL', 
  value=>NULL);

例14-3 データベースのオプション参加者としての指定

次の例では、データベースで発生したエラーがローリング・アップグレード全体を妨げてはいけないことを示す、データベースatlantaのINVOLVEMENTローカル・パラメータの設定を示します。

DBMS_ROLLING.SET_PARAMETER (
  scope=>'atlanta', 
  name=>'involvement', 
  value=>'optional');

例14-4 一時ロジカル・スタンバイを保護するデータベースの設定

次の例では、ローリング・アップグレード中にデータベースにより一時ロジカル・スタンバイを保護する必要があることを示す、データベースatlantaのMEMBERローカル・パラメータの設定を示します。

DBMS_ROLLING.SET_PARAMETER (
  scope=>'atlanta', 
  name=>'member', 
  value=>'leading');

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

DBMS_ROLLING PL/SQLパッケージを使用してローリング・アップグレードを実行するには、次のステップを実行します。

表14-2に、このステップの要約を示します。これらのステップは、「ローリング・アップグレードの計画」での説明に従い、最初にアップグレード計画を正常に作成したことを前提としています。

表14-2 DBMS_ROLLINGを使用したローリング・アップグレードの実行ステップ

ステップ	説明	PHASE
ステップ1	DBMS_ROLLING.START_PLANプロシージャを呼び出し、将来のプライマリと、将来のプライマリを保護するように指定したフィジカル・スタンバイを構成します。	START
ステップ2	将来のプライマリ・データベースとそれを保護するスタンバイでOracle Databaseソフトウェアを手動でアップグレードします。	SWITCH PENDING
ステップ3	DBMS_ROLLING.SWITCHOVERプロシージャを呼び出し、現在と将来のプライマリ・データベース間でロールを切り替えます。	SWITCH
ステップ4	以前のプライマリと残りのスタンバイ・データベースをより高いバージョンのOracle Databaseで手動で再起動します。	FINISH PENDING
ステップ5	DBMS_ROLLING.FINISH_PLANプロシージャを呼び出し、以前のプライマリをフィジカル・スタンバイへ変換し、残りのスタンバイ・データベースをアップグレードREDOのリカバリ用に構成します。	FINISH

表14-2のPHASE列に示された、ローリング・アップグレードの特定のフェーズに属する各ステップの間に実行するアクティビティ。ローリング・アップグレード操作は任意の時点で1つのフェーズです。ローリング・アップグレードの現在のフェーズは、DBA_ROLLING_STATUSビューのPHASE列にレポートされます。

各アップグレード・ステップの詳細は、この項の残りの部分で説明します。

1. DBMS_ROLLING.START_PLANプロシージャを呼び出し、将来のプライマリと、将来のプライマリを保護するように指定したフィジカル・スタンバイを構成します。

   DBMS_ROLLING.START_PLANプロシージャはローリング・アップグレードの正式な開始です。START_PLANプロシージャの目的は、一時ロジカル・スタンバイ・データベースとそれを保護するように指定されたフィジカル・スタンバイ・データベースを構成することです。呼び出されると、START_PLANプロシージャはSTART_PLANのPHASE値を含むアップグレード計画内のすべての手順を実行します。実行される手順のタイプには次のものがあります。

   • 各データベースの制御ファイルのトレース・ファイルへのバックアップ

   • フラッシュバック・データベースの保証付きリストア・ポイントの作成

   • プライマリ・データベースでのLogMinerディクショナリの作成

   • 指定したフィジカル・スタンバイの一時ロジカル・スタンバイ・データベースへのリカバリ

   • LogMinerディクショナリのロジカル・スタンバイ・データベースへのロード

   • 一時ロジカル・スタンバイ・データベースを使用したLGSデータベースの構成

   次のようにSTART_PLANプロシージャを呼び出します(引数は必要ありません)。

   SQL> EXECUTE DBMS_ROLLING.START_PLAN;
   

2. 将来のプライマリ・データベースとそれを保護するスタンバイでOracle Databaseソフトウェアを手動でアップグレードします。

   START_PLANプロシージャが完了した後、将来のプライマリ・データベースとそれを保護するスタンバイでOracle Databaseソフトウェアを手動でアップグレードする必要があります。これを行うには次のステップが必要になります。

   1. 一時ロジカル(LGM)および先行グループ・スタンバイ(LGS)のOracle Databaseソフトウェアをアップグレードします。

   2. LGSデータベースでメディア・リカバリを開始します。

   3. 手動またはOracle Database Upgrade Assistant(DBUA)を使用して、一時ロジカル・スタンバイ・データベースをアップグレードします。

   4. 一時ロジカル・スタンバイを読取り/書込みモードで再度開きます。

   一時ロジカル・スタンバイおよびLGSデータベースは機能グループです。LGSデータベースは一時ロジカル・スタンバイがアップグレードされる前に、より高いバージョンのアクティブに実行中のメディア・リカバリで再起動する必要があります。LGSデータベースが最初に構成されない場合は、一時ロジカルのアップグレードは保護されません。このステップの最後に、一時ロジカルのアップグレードは完了し、メディア・リカバリがすべてのLGSデータベースで実行しています。

   スイッチオーバーを実行する前に、すべてのLGSデータベースが完全にアップグレードされるまで待機することをお薦めします。DBA_ROLLING_DATABASESビューで関連レコードがUPDATED列にYESの値を報告している場合、LGSデータベースは完全にアップグレードされています。

3. DBMS_ROLLING.SWITCHOVERプロシージャを呼び出し、現在と将来のプライマリ・データベース間でロールを切り替えます。

   SWITCHOVERプロシージャは現在と将来のプライマリ・データベース間でロールを切り替えます。このプロシージャは、プライマリ・サービスの提示時間を最小化する、適用ラグが最小のときにスイッチオーバーが発生するように調整します。SWITCHOVERプロシージャはSWITCHOVERのPHASE値を含むアップグレード計画内のすべての手順を実行します。実行される手順のタイプには次のものがあります。

   • 現在の一時ロジカル・スタンバイである先行グループ・マスター(LGM)で適用ラグがしきい値を下回るまで待機する

   • LGSデータベースで適用ラグがしきい値を下回るまで待機する

   • プライマリからロジカル・スタンバイ・ロールへ切り替える

   • 現在のロジカル・スタンバイである先行グループ・マスター(LGM)からプライマリ・ロールへ切り替える

   • 新しいプライマリになった後で先行グループ・マスター(LGM)でログ・アーカイブ宛先を有効化する

   次のようにSWITCHOVERプロシージャを呼び出します(引数は必要ありません)。

   SQL> EXECUTE DBMS_ROLLING.SWITCHOVER;
   

   プライマリからスタンバイ・ロールへのスイッチオーバー後にスイッチオーバー・エラーが発生したものの、一時ロジカルがプライマリ・ロールに正常に変換される前の場合、正常に完了するまで、引き続き以前のプライマリ・サイトでSWITCHOVERプロシージャを実行します。

4. この時点で、以前のプライマリと残りのスタンバイ・データベースをより高いバージョンのOracle Databaseで手動で再起動し、マウントする必要があります。ローリング・アップグレードを継続するために、DBMS_ROLLINGパッケージはスタンバイ・データベースと通信する必要があるため、スタンバイ・データベースのマウントは特に重要です。

5. FINISH_PLANプロシージャの全体的な目的は、アップグレードREDO全体をリカバリすることと、以前のプライマリおよびTGPスタンバイをフィジカル・スタンバイとして構成することです。呼び出されると、FINISH_PLANプロシージャはFINISHのPHASE値を含むアップグレード計画内のすべての手順を実行します。実行される手順のタイプには次のものがあります。

   • 以前のプライマリおよびTGPスタンバイのフラッシュバック

   • 以前のプライマリのフィジカル・スタンバイへの変換

   • 新しいREDOブランチでのメディア・リカバリの開始

   次のようにFINISH_PLANプロシージャを呼び出します(引数は必要ありません)。

   SQL> EXECUTE DBMS_ROLLING.FINISH_PLAN;

14.6 ローリング・アップグレードの監視

ローリング・アップグレードに関与するデータベースに関する情報を問い合せることができるビューがいくつかあります。

• DBA_ROLLING_STATUS

  アップグレードの全体的なステータスに関する情報を提供します。

• DBA_ROLLING_DATABASES

  ローリング・アップグレードに関与する各データベースのロール、保護、およびリカバリ状態に関する情報を提供します。

• DBA_ROLLING_STATISTICS

  開始および終了時間、サービスがオフラインだった時間などの統計情報を提供します。

関連項目:

• これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

14.7 ローリング・アップグレードのロールバック

ローリング・アップグレード手順をロールバックするには、DBMS_ROLLING.ROLLBACK_PLANプロシージャを呼び出すことができます。

プロシージャは次のように呼び出されます。

DBMS_ROLLING.ROLLBACK_PLAN;

ROLLBACK_PLANプロシージャには次の要件があります。

• ROLLBACK_PLANプロシージャはDBMS_ROLLING.SWITCHOVERプロシージャがこれまで呼び出されたことがない場合にのみ呼び出すことができます。

• ROLLBACK_PLANプロシージャを使用する前に、フラッシュバック・データベースが差し迫っているので、一時ロジカル・スタンバイ・データベースをマウント状態に戻す必要があります。

• Oracle Databaseソフトウェアがすでにアップグレードされている場合、古いバージョンで結果のフィジカル・スタンバイを再起動し、メディア・リカバリを開始する必要があります。

14.8 ローリング・アップグレード中に発生したロール変更の処理

ローリング・アップグレードが進行中で、ロールオーバーが完了する前にOracle Data Guard構成でフェイルオーバーを実行する必要がある状況が発生した場合は、次の状況でのみフェイルオーバーを実行できます。

• DBMS_ROLLINGプロシージャの進行中にフェイルオーバーが実行されなかった。

• フェイルオーバーがプライマリ・データベースとフィジカル・スタンバイ・データベース間で発生し、これがデータ消失なしのファイルオーバーだった。

• フェイルオーバーが一時ロジカル・スタンバイ・データベースと一時ロジカル・スタンバイ・データベースのフィジカル・スタンバイ間で発生した。

ロール変更は、様々な構成に応じたアップグレード計画内の手順を必ず無効化する重要なイベントです。ローリング・アップグレードを再開するには、新しい計画を作成する必要があります。FAILOVERパラメータを設定して、構成が変更されたことを示す必要があります。このパラメータはBUILD_PLANプロシージャの次の起動時に検出され、それに応じて既存の計画が修正されます。

修正された計画が作成されると、ローリング・アップグレードを再開できます。

14.9 ローリング・アップグレードの例

次の例は、様々なローリング・アップグレードのシナリオを示しています。

すべてのシナリオのいくつかの地点で、同じ基本的なローリング・アップグレードのステップが使用されています。これらのステップを例14-5に示します。残りの例は、同じステップを繰り返すのではなく、適切なこの例に戻って参照します。

この項のいくつかの例では、ローリング・アップグレードの再開が指示されます。つまり、停止したところから続行する必要があります。ローリング・アップグレードの再開には、ローリング・アップグレードの現在のフェーズの識別と、そのフェーズに関連するPL/SQLプロシージャまたはフェーズに関連するアクティビティのいずれかの再実行が含まれます。ローリング・アップグレードの現在のフェーズは、DBA_ROLLING_STATUSビューのPHASE列に示されます。

ノート:

この項であげたシナリオは、仮想上の例を示すためのものです。Oracle Active Data Guardを使用したローリング・アップグレード機能を使用して、Oracle Database 12cに対する最初のパッチセット以降のデータベース・アップグレードを実行できます。

例14-5 基本ローリング・アップグレード・ステップ

1. ローリング・アップグレードを開始します。

   SQL> EXECUTE DBMS_ROLLING.START_PLAN;
   

2. 一時ロジカル・スタンバイとその保護しているスタンバイをアップグレードします。

   1. Oracle Databaseソフトウェアの上位バージョンを使用してLGPスタンバイをマウントします。

   2. 先行グループ・フィジカル(LGP)でメディア・リカバリを開始します。

   3. Oracle Databaseソフトウェアの上位バージョンを使用してアップグレード・モードで、一時ロジカル・スタンバイである先行グループ・マスター(LGM)を開きます。

   4. 手動またはOracle Database Upgrade Assistant(DBUA)を使用して、一時ロジカル・スタンバイである先行グループ・マスター(LGM)をアップグレードします。

   5. 一時ロジカル・スタンバイである先行グループ・マスター(LGM)を読取り/書込みモードで再起動します。

3. 先行グループ・マスター(LGM)にスイッチオーバーします。

   SQL> EXECUTE DBMS_ROLLING.SWITCHOVER;
   

4. 後続グループのデータベースを再起動します。これには、元のプライマリ・データベースと、後続グループ(TGP)内の保護しているすべてのスタンバイが含まれます。

   1. Oracle Databaseの上位バージョンを使用して前のプライマリをマウントします。

   2. Oracle Databaseの上位バージョンを使用して前のプライマリのフィジカル・スタンバイをマウントします。

5. ローリング・アップグレードを終了します。

   SQL> EXECUTE DBMS_ROLLING.FINISH_PLAN;

例14-6 2つのデータベース間のローリング・アップグレード

次の例では、プライマリ・データベースおよびフィジカル・スタンバイ・データベースで構成されている2サイト構成でのローリング・アップグレードについて説明します。この例では、seattleが現在のプライマリで、bostonが将来のプライマリです。seattleデータベースが後続グループ・マスター(TGM)として自動的に選択され、操作に参加します。デフォルトで、seattleに対しては何も設定する必要はありません。

1. アップグレード計画を初期化します。

   SQL> EXECUTE DBMS_ROLLING.INIT_PLAN(future_primary=>'boston');
   

2. アップグレード計画を作成します。

   SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
   

3. 例14-5の説明のように、ローリング・アップグレードを実行します。

例14-7 3つのデータベース間のローリング・アップグレード

次の例では、プライマリ・データベースおよび2つのフィジカル・スタンバイ・データベースで構成されている3サイト構成でのローリング・アップグレードについて説明します。この例では、seattleが現在のプライマリ、bostonが将来のプライマリで、oaklandがseattleのフィジカル・スタンバイです。

1. アップグレード計画を初期化します。

   SQL> EXECUTE DBMS_ROLLING.INIT_PLAN (future_primary => 'boston');
   

2. アップグレード計画を作成します。

   SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
   

3. 例14-5の説明のように、ローリング・アップグレードを実行します。

例14-8 4つのデータベース間のローリング・アップグレード

次の例では、プライマリ・データベースおよび3つのフィジカル・スタンバイ・データベースで構成されている4サイト構成でのローリング・アップグレードについて説明します。この例では、seattleがプライマリ・データベース、bostonが将来のプライマリ、oaklandがseattleのフィジカル・スタンバイで、atlantaがbostonのフィジカル・スタンバイです。

1. アップグレード計画を初期化します。

   SQL> EXECUTE DBMS_ROLLING.INIT_PLAN (future_primary => 'boston');
   

2. atlantaを先行グループのスタンバイとして構成します。

   SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(scope=>'atlanta',name=>'member',
    value=>'leading');
   

3. アップグレード計画を作成します。

   SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
   

4. 例14-5の説明のように、ローリング・アップグレードを実行します。

例14-9 リーダー・ファームでのローリング・アップグレード

次の例では、1つのプライマリ・データベースおよび9つのフィジカル・スタンバイ・データベースで構成されているリーダー・ファーム構成でのローリング・アップグレードについて説明します。この例では、スイッチオーバーの前後でフィジカル・スタンバイがOracle Active Data Guardスタンバイとして使用可能になるために、8つのフィジカル・スタンバイ・データベースが4つずつの2つのグループに分けられます。この例では、seattleがプライマリ、bostonが将来のプライマリ、データベースrf[a-d]がseattleのフィジカル・スタンバイで、データベースrf[e-h]がbostonのフィジカル・スタンバイです。将来のプライマリ・データベースのリーダー・ファーム・グループ間の適用ラグが60秒よりも短くなるまで、新しいプライマリへのスイッチオーバーが待機するように、ローリング・アップグレードが構成されます。

1. アップグレード計画を初期化します。

   SQL> EXECUTE DBMS_ROLLING.INIT_PLAN ( future_primary => 'boston');
   

2. 将来のプライマリを保護するようにリーダー・ファーム・グループを構成します。

   SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(scope=>'rfe',name=>'member',
   value=>'leading');
   

   SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(scope=>'rff',name=>'member',
   value=>'leading');
   

   SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(scope=>'rfg',name=>'member',
   value=>'leading');
   

   SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(scope=>'rfh',name=>'member',
   value=>'leading');
   

3. 将来のプライマリのリーダー・ファームに60秒の最大許容適用ラグを設定します。

   SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(name=>'SWITCH_LGS_LAG_WAIT',
    value=>'1');
   

4. アップグレード計画を作成します。

   SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
   

5. 例14-5の説明のように、ローリング・アップグレードを実行します。

例14-10 Application Testingのローリング・アップグレード

次の例では、上位バージョンのデータベースのアプリケーションを検証するための、一時ロジカル・スタンバイおよび一時ロジカル・スタンバイのフィジカルを構成する、4サイト構成でのローリング・アップグレードの使用について説明します。プライマリ・データベースはseattleで、bostonは将来のプライマリ、oaklandはseattleのフィジカル・スタンバイで、atlantaはbostonのフィジカル・スタンバイです。そのため、この例では、seattleおよびoaklandが後続グループを構成し、bostonおよびatlantaが先行グループを構成します。テストの終わりに、seattleの保護を再開するために、bostonおよびatlantaが元のフィジカル・スタンバイにリストアされます。

1. アップグレード計画を初期化します。

   SQL> EXECUTE DBMS_ROLLING.INIT_PLAN (future_primary => 'boston');
   

2. 将来のプライマリを保護するようにatlantaを構成します。

   SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(scope=>'atlanta',name=>'member',
    value=>'leading');
   

3. アップグレード計画を作成します。

   SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
   

4. ローリング・アップグレードを開始します。

   SQL> EXECUTE DBMS_ROLLING.START_PLAN;
   

5. bostonおよびatlantaをアップグレードします。

   1. 上位バージョンのデータベースを使用してatlantaをマウントします。

   2. atlantaでメディア・リカバリを開始します。

   3. 上位バージョンのデータベースを使用してアップグレード・モードでbostonを開きます。

   4. 手動またはOracle Database Upgrade Assistant(DBUA)を使用して、データベースbostonをアップグレードします。

   5. bostonを読取り/書込みモードで再起動します。

6. 必要に応じてアプリケーションをテストします。

7. 構成をロールバックします。

   1. bostonをマウント・モードで再起動します。

   2. アップグレードをロールバックします。

      SQL> EXECUTE DBMS_ROLLING.ROLLBACK_PLAN;
      

8. 下位バージョンのデータベースを使用してbostonおよびatlantaでメディア・リカバリを開始します。

   1. 下位バージョンのデータベースを使用して bostonおよびatlantaをマウントします。

   2. bostonおよびatlantaでメディア・リカバリを開始します。

例14-11 新しいプライマリへのフェイルオーバー後のローリング・アップグレードの再開

次の例では、フィジカル・スタンバイのプライマリ・ロールへのデータ消失なしのファイルオーバーと、その後の3サイト構成でのローリング・アップグレード計画の再構成について説明します。この例では、seattleが現在のプライマリ、bostonが将来のプライマリで、oaklandがseattleのフィジカル・スタンバイです。データベースoaklandはフェイルオーバーされて新しいプライマリになります。(後続グループは(seattle、oakland)で先行グループはbostonです。)

1. oaklandの残りのREDOがリカバリされ、新しいプライマリ・ロールにフェイルオーバーされます。

   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
   SQL> ALTER DATABASE RECOVER MANAGED STANDBY FINISH;
   SQL> ALTER DATABASE FAILOVER TO OAKLAND;
   SQL> ALTER DATABASE OPEN;

2. 必要に応じて、oaklandのログ・アーカイブ宛先を構成します。

   SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='service="boston" reopen=5
     2  LGWR ASYNC NET_TIMEOUT=180 valid_for=(ONLINE_LOGFILE, PRIMARY_ROLE)
     3  DB_UNIQUE_NAME="oakland"';

   
   SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

3. ファイルオーバーが実行されたことを示すパラメータを設定します。:

   SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(name=>'failover', value=>'1');
   

4. アップグレード計画を修正します。

   SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
   

5. ローリング・アップグレードを再開します。

例14-12 新しい一時ロジカルへのフェイルオーバー後のローリング・アップグレードの再開

次の例では、フィジカル・スタンバイの一時ロジカル・ロールへのフェイルオーバーと、その後の5サイト構成でのローリング・アップグレード計画の再構成について説明します。この例では、seattleがプライマリ、bostonが将来のプライマリ、oaklandがseattleのフィジカル・スタンバイで、atlantaとmiamiがbostonのフィジカル・スタンバイです。データベースatlantaはフェイルオーバーされて新しい一時ロジカル・スタンバイになります。

1. atlantaの残りのREDOがリカバリされ、新しい一時ロジカル・ロールにフェイルオーバーされます。

   SQL> ALTER DATABASE RECOVER MANAGED STANDBY FINISH;
   
   SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
   
   SQL> ALTER DATABASE OPEN;
   

2. 必要に応じて、atlantaのログ・アーカイブ宛先を構成します。

   SQL> alter system set log_archive_dest_2='service="seattle" reopen=5
     2  LGWR ASYNC NET_TIMEOUT=180 valid_for=(ONLINE_LOGFILE, PRIMARY_ROLE)
     3  DB_UNIQUE_NAME="atlanta"';
   
   SQL> alter system set log_archive_dest_3='service="oakland" reopen=5
     2  LGWR ASYNC NET_TIMEOUT=180 valid_for=(ONLINE_LOGFILE, PRIMARY_ROLE)
     3  DB_UNIQUE_NAME="atlanta"';
   
   SQL> alter system set log_archive_dest_4='service="miami" reopen=5
     2  LGWR ASYNC NET_TIMEOUT=180 valid_for=(ONLINE_LOGFILE, ALL_ROLES)
     3  DB_UNIQUE_NAME="atlanta"';
   

3. 新しい一時ロジカル・スタンバイ・データベースとしてatlantaを指定します。

   SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(name=>'failover', value=>'1');
   

4. アップグレード計画を修正します。

   SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
   

5. ローリング・アップグレードを再開します。