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圧縮化対象への表の変更
次のトピックを参照してください。
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は残ることができるようになり、無効化する必要はなくなりました。
ただし、ファスト・スタート・フェイルオーバー機能を、DBMS_ROLLING
アップグレードを開始する前に、およびローリング・アップグレードが進行中にファスト・スタート・フェイルオーバーを有効化しようとして拒絶される前に無効化する必要があります。さらに、ローリング・アップグレードが進行中は、ロールの変更は現在のプライマリ・データベースを保護しているスタンバイ・データベースに対してのみ許可されます。ブローカは、ローリング・アップグレード・ターゲットのロールをSHOW CONFIGURATION
コマンド時にTransient Logical Standby
としてレポートすると同様に、構成ステータスをROLLING DATABASE MAINTENANCE IS IN PROGRESS
としてレポートします。元のプライマリ・データベースとアップグレード・ターゲットの両方を保護しているスタンバイ・データベースがある場合、このトポロジは、SHOW CONFIGURATION
コマンドが現在のプライマリから発行されたときと同様にアップグレード・ターゲットから発行されたとき(プライマリ・データベースとして引継ぎが完了する前)に反映されます
ブローカ・サポートは、ブローカが呼出し時に有効であればデフォルトでDBMS_ROLLING.BUILD_PLAN
プロシージャの実行時に有効です。ブローカ・サポートが有効な場合、ブローカはREDO転送の宛先を必要に応じて元のプライマリからと同様にローリング・アップグレード・ターゲットからも設定し、アップグレード・ターゲットがOracle RACデータベースの場合にはその上のインスタンス数を管理し、Oracle ClusterwareおよびGlobal Data Servicesにローリング・アップグレードの経過中に適宜通知します。ブローカ・サポートは、DBMS_ROLLING
パラメータDGBROKER
を使用して手動で制御できます。
ロールの推移は通常、ブローカを使用して実行されますが、ローリング・アップグレードのスイッチオーバー手順は引き続き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
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つのステージがあります。
-
指定: 最初に、ローリング・アップグレード・プロセスの実装方法を指定します。将来のプライマリ・データベースを指定することは必須です。この動作は概念的には先行および後続グループの作成です。この時点では、先行グループのみにLGMが含まれます。オプションでLGMを保護する別のスタンバイを指定できます。
指定フェーズでは次のプロシージャを使用します。
-
DBMS_ROLLING.INIT_PLAN
-
DBMS_ROLLING.SET_PARAMETER
-
-
コンパイル: これは
DBMS_ROLLING.BUILD_PLAN
プロシージャを呼び出すことで開始されます。BUILD_PLAN
プロシージャは、ローリング・アップグレードに関与するすべてのデータベースと通信し、ローリング・アップグレード計画を組み立てます。BUILD_PLAN
プロシージャも、既存のローリング・アップグレード計画を変更するために呼び出されます。変更は、DBMS_ROLLING
パラメータに対する変更の後、およびフェイルオーバーの結果としてのトポロジに対する変更の後に必要です。正常なローリング・アップグレードを確実にするために数多くの検証が必要なため、関与しているすべてのデータベースがBUILD_PLAN
プロシージャの実行中にアクセス可能である必要があります。 -
実行: ローリング・アップグレードの実行には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 ローリング・アップグレードの計画
ローリング・アップグレードの計画は、正常にアップグレードするために不可欠です。計画フェーズでは、様々なアップグレード・パラメータを指定し、アップグレード計画を作成します。
パラメータとアップグレード計画は、環境に一意なすべての操作の詳細に焦点を当てます。アップグレード計画ではサイト特有の検証を実行し、ローリング・アップグレードを中断させる可能性のある構成およびリソースの問題を確認できます。
アップグレード・パラメータの定義およびアップグレード計画の作成に必要なタスクは、次のとおりです。
-
アップグレード・パラメータを初期化します
-
現在のアップグレード・パラメータの値を表示します
-
必要に応じてアップグレード・パラメータの値を変更します
-
アップグレード計画を作成します。
-
現在のアップグレード計画を表示します
-
必要に応じてアップグレード計画を修正します
これらの各手順の詳細は、この項の残りの部分で説明します。これらは、表示されている順序で実行する必要があります。
例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 |
|
START |
手順2 |
将来のプライマリ・データベースとそれを保護するスタンバイでOracle Databaseソフトウェアを手動でアップグレードします。 |
SWITCH PENDING |
手順3 |
|
SWITCH |
手順4 |
以前のプライマリと残りのスタンバイ・データベースをより高いバージョンのOracle Databaseで手動で再起動します。 |
FINISH PENDING |
手順5 |
|
FINISH |
表14-2のPHASE列に示された、ローリング・アップグレードの特定のフェーズに属する各手順の間に実行するアクティビティ。ローリング・アップグレード操作は任意の時点で1つのフェーズです。ローリング・アップグレードの現在のフェーズは、DBA_ROLLING_STATUS
ビューのPHASE
列にレポートされます。
各アップグレード手順の詳細は、この項の残りの部分で説明します。
-
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;
-
-
将来のプライマリ・データベースとそれを保護するスタンバイでOracle Databaseソフトウェアを手動でアップグレードします。
START_PLAN
プロシージャが完了した後、将来のプライマリ・データベースとそれを保護するスタンバイでOracle Databaseソフトウェアを手動でアップグレードする必要があります。これを行うには次の手順が必要になります。-
一時ロジカル(LGM)および先行グループ・スタンバイ(LGS)のOracle Databaseソフトウェアをアップグレードします。
-
LGSデータベースでメディア・リカバリを開始します。
-
手動またはOracle Database Upgrade Assistant(DBUA)を使用して、一時ロジカル・スタンバイ・データベースをアップグレードします。
-
一時ロジカル・スタンバイを読取り/書込みモードで再度開きます。
一時ロジカル・スタンバイおよびLGSデータベースは機能グループです。LGSデータベースは一時ロジカル・スタンバイがアップグレードされる前に、より高いバージョンのアクティブに実行中のメディア・リカバリで再起動する必要があります。LGSデータベースが最初に構成されない場合は、一時ロジカルのアップグレードは保護されません。この手順の最後に、一時ロジカルのアップグレードは完了し、メディア・リカバリがすべてのLGSデータベースで実行しています。
スイッチオーバーを実行する前に、すべてのLGSデータベースが完全にアップグレードされるまで待機することをお薦めします。
DBA_ROLLING_DATABASES
ビューで関連レコードがUPDATED
列にYES
の値を報告している場合、LGSデータベースは完全にアップグレードされています。 -
-
DBMS_ROLLING.SWITCHOVER
プロシージャを呼び出し、現在と将来のプライマリ・データベース間でロールを切り替えます。SWITCHOVER
プロシージャは現在と将来のプライマリ・データベース間でロールを切り替えます。このプロシージャは、プライマリ・サービスの提示時間を最小化する、適用ラグが最小のときにスイッチオーバーが発生するように調整します。SWITCHOVER
プロシージャはSWITCHOVER
のPHASE
値を含むアップグレード計画内のすべての手順を実行します。実行される手順のタイプには次のものがあります。-
現在の一時ロジカル・スタンバイである先行グループ・マスター(LGM)で適用ラグがしきい値を下回るまで待機する
-
LGSデータベースで適用ラグがしきい値を下回るまで待機する
-
プライマリからロジカル・スタンバイ・ロールへ切り替える
-
現在のロジカル・スタンバイである先行グループ・マスター(LGM)からプライマリ・ロールへ切り替える
-
新しいプライマリになった後で先行グループ・マスター(LGM)でログ・アーカイブ宛先を有効化する
次のように
SWITCHOVER
プロシージャを呼び出します(引数は必要ありません)。SQL> EXECUTE DBMS_ROLLING.SWITCHOVER;
プライマリからスタンバイ・ロールへのスイッチオーバー後にスイッチオーバー・エラーが発生したものの、一時ロジカルがプライマリ・ロールに正常に変換される前の場合、正常に完了するまで、引き続き以前のプライマリ・サイトで
SWITCHOVER
プロシージャを実行します。 -
-
この時点で、以前のプライマリと残りのスタンバイ・データベースをより高いバージョンのOracle Databaseで手動で再起動し、マウントする必要があります。ローリング・アップグレードを継続するために、
DBMS_ROLLING
パッケージはスタンバイ・データベースと通信する必要があるため、スタンバイ・データベースのマウントは特に重要です。 -
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 基本ローリング・アップグレード手順
-
ローリング・アップグレードを開始します。
SQL> EXECUTE DBMS_ROLLING.START_PLAN;
-
一時ロジカル・スタンバイとその保護しているスタンバイをアップグレードします。
-
Oracle Databaseソフトウェアの上位バージョンを使用してLGPスタンバイをマウントします。
-
先行グループ・フィジカル(LGP)でメディア・リカバリを開始します。
-
Oracle Databaseソフトウェアの上位バージョンを使用してアップグレード・モードで、一時ロジカル・スタンバイである先行グループ・マスター(LGM)を開きます。
-
手動またはOracle Database Upgrade Assistant(DBUA)を使用して、一時ロジカル・スタンバイである先行グループ・マスター(LGM)をアップグレードします。
-
一時ロジカル・スタンバイである先行グループ・マスター(LGM)を読取り/書込みモードで再起動します。
-
-
先行グループ・マスター(LGM)にスイッチオーバーします。
SQL> EXECUTE DBMS_ROLLING.SWITCHOVER;
-
後続グループのデータベースを再起動します。これには、元のプライマリ・データベースと、後続グループ(TGP)内の保護しているすべてのスタンバイが含まれます。
-
Oracle Databaseの上位バージョンを使用して前のプライマリをマウントします。
-
Oracle Databaseの上位バージョンを使用して前のプライマリのフィジカル・スタンバイをマウントします。
-
-
ローリング・アップグレードを終了します。
SQL> EXECUTE DBMS_ROLLING.FINISH_PLAN;
例14-6 2つのデータベース間のローリング・アップグレード
次の例では、プライマリ・データベースおよびフィジカル・スタンバイ・データベースで構成されている2サイト構成でのローリング・アップグレードについて説明します。この例では、seattle
が現在のプライマリで、boston
が将来のプライマリです。seattle
データベースが後続グループ・マスター(TGM)として自動的に選択され、操作に参加します。デフォルトで、seattle
に対しては何も設定する必要はありません。
-
アップグレード計画を初期化します。
SQL> EXECUTE DBMS_ROLLING.INIT_PLAN(future_primary=>'boston');
-
アップグレード計画を作成します。
SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
-
例14-5の説明のように、ローリング・アップグレードを実行します。
例14-7 3つのデータベース間のローリング・アップグレード
次の例では、プライマリ・データベースおよび2つのフィジカル・スタンバイ・データベースで構成されている3サイト構成でのローリング・アップグレードについて説明します。この例では、seattle
が現在のプライマリ、boston
が将来のプライマリで、oakland
がseattle
のフィジカル・スタンバイです。
-
アップグレード計画を初期化します。
SQL> EXECUTE DBMS_ROLLING.INIT_PLAN (future_primary => 'boston');
-
アップグレード計画を作成します。
SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
-
例14-5の説明のように、ローリング・アップグレードを実行します。
例14-8 4つのデータベース間のローリング・アップグレード
次の例では、プライマリ・データベースおよび3つのフィジカル・スタンバイ・データベースで構成されている4サイト構成でのローリング・アップグレードについて説明します。この例では、seattle
がプライマリ・データベース、boston
が将来のプライマリ、oakland
がseattle
のフィジカル・スタンバイで、atlanta
がboston
のフィジカル・スタンバイです。
-
アップグレード計画を初期化します。
SQL> EXECUTE DBMS_ROLLING.INIT_PLAN (future_primary => 'boston');
-
atlanta
を先行グループのスタンバイとして構成します。SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(scope=>'atlanta',name=>'member', value=>'leading');
-
アップグレード計画を作成します。
SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
-
例14-5の説明のように、ローリング・アップグレードを実行します。
例14-9 リーダー・ファームでのローリング・アップグレード
次の例では、1つのプライマリ・データベースおよび9つのフィジカル・スタンバイ・データベースで構成されているリーダー・ファーム構成でのローリング・アップグレードについて説明します。この例では、スイッチオーバーの前後でフィジカル・スタンバイがOracle Active Data Guardスタンバイとして使用可能になるために、8つのフィジカル・スタンバイ・データベースが4つずつの2つのグループに分けられます。この例では、seattle
がプライマリ、boston
が将来のプライマリ、データベースrf[a-d]
がseattle
のフィジカル・スタンバイで、データベースrf[e-h]
がboston
のフィジカル・スタンバイです。将来のプライマリ・データベースのリーダー・ファーム・グループ間の適用ラグが60秒よりも短くなるまで、新しいプライマリへのスイッチオーバーが待機するように、ローリング・アップグレードが構成されます。
-
アップグレード計画を初期化します。
SQL> EXECUTE DBMS_ROLLING.INIT_PLAN ( future_primary => 'boston');
-
将来のプライマリを保護するようにリーダー・ファーム・グループを構成します。
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');
-
将来のプライマリのリーダー・ファームに60秒の最大許容適用ラグを設定します。
SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(name=>'SWITCH_LGS_LAG_WAIT', value=>'1');
-
アップグレード計画を作成します。
SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
-
例14-5の説明のように、ローリング・アップグレードを実行します。
例14-10 Application Testingのローリング・アップグレード
次の例では、上位バージョンのデータベースのアプリケーションを検証するための、一時ロジカル・スタンバイおよび一時ロジカル・スタンバイのフィジカルを構成する、4サイト構成でのローリング・アップグレードの使用について説明します。プライマリ・データベースはseattle
で、boston
は将来のプライマリ、oakland
はseattle
のフィジカル・スタンバイで、atlanta
はboston
のフィジカル・スタンバイです。そのため、この例では、seattle
およびoakland
が後続グループを構成し、boston
およびatlanta
が先行グループを構成します。テストの終わりに、seattle
の保護を再開するために、boston
およびatlanta
が元のフィジカル・スタンバイにリストアされます。
-
アップグレード計画を初期化します。
SQL> EXECUTE DBMS_ROLLING.INIT_PLAN (future_primary => 'boston');
-
将来のプライマリを保護するように
atlanta
を構成します。SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(scope=>'atlanta',name=>'member', value=>'leading');
-
アップグレード計画を作成します。
SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
-
ローリング・アップグレードを開始します。
SQL> EXECUTE DBMS_ROLLING.START_PLAN;
-
boston
およびatlanta
をアップグレードします。-
上位バージョンのデータベースを使用して
atlanta
をマウントします。 -
atlanta
でメディア・リカバリを開始します。 -
上位バージョンのデータベースを使用してアップグレード・モードで
boston
を開きます。 -
手動またはOracle Database Upgrade Assistant(DBUA)を使用して、データベース
boston
をアップグレードします。 -
boston
を読取り/書込みモードで再起動します。
-
-
必要に応じてアプリケーションをテストします。
-
構成をロールバックします。
-
boston
をマウント・モードで再起動します。 -
アップグレードをロールバックします。
SQL> EXECUTE DBMS_ROLLING.ROLLBACK_PLAN;
-
-
下位バージョンのデータベースを使用して
boston
およびatlanta
でメディア・リカバリを開始します。-
下位バージョンのデータベースを使用して
boston
およびatlanta
をマウントします。 -
boston
およびatlanta
でメディア・リカバリを開始します。
-
例14-11 新しいプライマリへのフェイルオーバー後のローリング・アップグレードの再開
次の例では、フィジカル・スタンバイのプライマリ・ロールへのデータ消失なしのファイルオーバーと、その後の3サイト構成でのローリング・アップグレード計画の再構成について説明します。この例では、seattle
が現在のプライマリ、boston
が将来のプライマリで、oakland
がseattle
のフィジカル・スタンバイです。データベースoakland
はフェイルオーバーされて新しいプライマリになります。(後続グループは(seattle
、oakland
)で先行グループはboston
です。)
-
oakland
の残りのREDOがリカバリされ、新しいプライマリ・ロールにフェイルオーバーされます。SQL> ALTER DATABASE RECOVER MANAGED STANDBY FINISH; SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN; SQL> STARTUP OPEN;
-
必要に応じて、
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> EXECUTE DBMS_ROLLING.SET_PARAMETER(name=>'failover', value=>'1');
-
アップグレード計画を修正します。
SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
-
ローリング・アップグレードを再開します。
例14-12 新しい一時ロジカルへのフェイルオーバー後のローリング・アップグレードの再開
次の例では、フィジカル・スタンバイの一時ロジカル・ロールへのフェイルオーバーと、その後の5サイト構成でのローリング・アップグレード計画の再構成について説明します。この例では、seattle
がプライマリ、boston
が将来のプライマリ、oakland
がseattle
のフィジカル・スタンバイで、atlanta
とmiami
がboston
のフィジカル・スタンバイです。データベースatlanta
はフェイルオーバーされて新しい一時ロジカル・スタンバイになります。
-
atlanta
の残りのREDOがリカバリされ、新しい一時ロジカル・ロールにフェイルオーバーされます。SQL> ALTER DATABASE RECOVER MANAGED STANDBY FINISH; SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE; SQL> ALTER DATABASE OPEN;
-
必要に応じて、
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_3='service="miami" reopen=5 2 LGWR ASYNC NET_TIMEOUT=180 valid_for=(ONLINE_LOGFILE, ALL_ROLES) 3 DB_UNIQUE_NAME="atlanta"';
-
新しい一時ロジカル・スタンバイ・データベースとして
atlanta
を指定します。SQL> EXECUTE DBMS_ROLLING.SET_PARAMETER(name=>'failover', value=>'1');
-
アップグレード計画を修正します。
SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN;
-
ローリング・アップグレードを再開します。