| Oracle® Data Guard概要および管理 12c リリース1 (12.1) B71304-07 |
|
 前 |
 次 |
Oracle Database 12c リリース1 (12.1)時点で新機能である、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の最初のパッチセットへのアップグレード時には、手動の一時ロジカル・スタンバイ・アップグレード手順を引き続き使用する必要があります。
また、この機能は、Oracle Database 12c リリース1 (12.1)以降、他のデータベース・メンテナンス・タスクにすぐに使用できます。メンテナンスが実行されるデータベースは、Oracle 12.1以上で動作する必要があります。このようなメンテナンス・タスクには、次のものが含まれます。
パーティション化されていない表へのパーティションの追加
BasicFiles LOBからSecureFiles LOBへの変更
CLOBとして格納されるXMLTypeからバイナリXMLとして格納されるXMLtypeへの変更
OLTP圧縮化対象への表の変更
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パッケージのサポート」を参照してください。
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-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');
この項では、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;
ローリング・アップグレードに関与するデータベースに関する情報を提供するいくつかのビューが使用できます。
DBA_ROLLING_STATUS
アップグレードの全体的なステータスに関する情報を提供します。
DBA_ROLLING_DATABASES
ローリング・アップグレードに関与する各データベースのロール、保護、およびリカバリ状態に関する情報を提供します。
DBA_ROLLING_STATISTICS
開始および終了時間、サービスがオフラインだった時間などの統計情報を提供します。
関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
ローリング・アップグレード手順をロールバックするには、次のように、DBMS_ROLLING.ROLLBACK_PLANプロシージャを呼び出すことができます。
DBMS_ROLLING.ROLLBACK_PLAN;
ROLLBACK_PLANプロシージャには次の要件があります。
ROLLBACK_PLANプロシージャはDBMS_ROLLING.SWITCHOVERプロシージャがこれまで呼び出されたことがない場合にのみ呼び出すことができます。
ROLLBACK_PLANプロシージャを使用する前に、フラッシュバック・データベースが差し迫っているので、一時ロジカル・スタンバイ・データベースをマウント状態に戻す必要があります。
Oracle Databaseソフトウェアがすでにアップグレードされている場合、古いバージョンで結果のフィジカル・スタンバイを再起動し、メディア・リカバリを開始する必要があります。
ローリング・アップグレードが進行中で、ロールオーバーが完了する前にOracle Data Guard構成でフェイルオーバーを実行する必要がある状況が発生した場合、次の状況でのみ実行することができます。
DBMS_ROLLINGプロシージャの進行中にフェイルオーバーが実行されなかった。
フェイルオーバーがプライマリ・データベースとフィジカル・スタンバイ・データベース間で発生し、これがデータ消失なしのファイルオーバーだった。
フェイルオーバーが一時ロジカル・スタンバイ・データベースと一時ロジカル・スタンバイ・データベースのフィジカル・スタンバイ間で発生した。
ロール変更は、様々な構成に応じたアップグレード計画内の手順を必ず無効化する重要なイベントです。ローリング・アップグレードを再開するには、新しい計画を作成する必要があります。FAILOVERパラメータを設定して、構成が変更されたことを示す必要があります。このパラメータはBUILD_PLANプロシージャの次の起動時に検出され、それに応じて既存の計画が修正されます。
修正された計画が作成されると、ローリング・アップグレードを再開できます。
このトピックでは様々なローリング・アップグレードのシナリオ例を提供します。すべてのシナリオのいくつかの地点で、同じ基本的なローリング・アップグレードの手順が使用されています。これらの手順を例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;
ローリング・アップグレードを再開します。
