3 Oracle Data Guardスタンバイを含むデータベースのアップグレード
データベースを新しいリリースにアップグレードする場合は、プライマリをアップグレードしてから、プライマリのアーカイブ・ログを使用してトランザクションをスタンバイにレプリケートします。
このシナリオは、Oracle Data Guard Brokerを使用していることを前提としています。
- Oracle Data Guardを使用したデータベースのアップグレードの準備
このシナリオでは、Data Guard BrokerでOracle Data Guardを使用してアップグレードを実行し、アップグレードを開始する前にData Guard Broker構成ファイルを移動します。 - Data Guardスタンバイを使用した非CDBからPDBへの手動変換およびアップグレード
非CDBをPDBにアップグレードするOracle Data Guardを使用したアップグレードおよび非CDBスタンバイ・データファイルの再利用には、特別な手順が必要です。 - Oracle Databaseソフトウェアをパッチ適用またはアップグレードする前に
Oracle Databaseソフトウェアをパッチ適用またはアップグレードする前に、様々なユースケース・シナリオの前提条件を確認してください。 - NOLOGGING句を指定した後のリカバリ
一部のSQL文では、操作がオンラインREDOログ・ファイルに記録されないように、NOLOGGING句を指定できます。 - 適切なロギング・モードの有効化
スタンバイ・データベースを作成するためのプライマリ・データベースの準備の一環として、Oracle Data Guard構成の使用方法に適したロギング・モードを有効にする必要があります。 - フィジカル・スタンバイの作成タスク1: プライマリ・データベースのデータファイルのバックアップ・コピーの作成
データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルがあるかぎり、プライマリ・データベースの任意のバックアップ・コピーを使用してフィジカル・スタンバイ・データベースを作成できます。 - フィジカル・スタンバイの作成タスク2: スタンバイ・データベース用の制御ファイルの作成
スタンバイ・データベース用の制御ファイルを作成します。プライマリ・データベースはオープンしている必要はありませんが、少なくともマウントされている必要があります。 - フィジカル・スタンバイの作成タスク3: スタンバイ・データベース用のパラメータ・ファイルの作成
プライマリ・データベースで使用されるサーバー・パラメータ・ファイル(SPFILE)からパラメータ・ファイル(PFILE)を作成します。 - フィジカル・スタンバイ・データベースが設定されているOracle Databaseのアップグレード
次のステップでは、構成にフィジカル・スタンバイ・データベースが存在する場合にOracle Databaseにアップグレードする方法を示します。 - フィジカル・スタンバイの作成タスク4: プライマリ・システムからスタンバイ・システムへのファイルのコピー
必要なディレクトリがすべて作成されていることを確認します。オペレーティング・システムのコピー・ユーティリティを使用して、プライマリ・システムからスタンバイ・システムの正しい場所にバイナリ・ファイルをコピーします。 - フィジカル・スタンバイの作成タスク5: スタンバイ・データベースをサポートする環境の設定
Microsoft Windowsベースのサービス、パスワード・ファイルおよびSPFILEを作成してからOracle Net環境を設定して、環境を設定します。 - フィジカル・スタンバイの作成タスク6: フィジカル・スタンバイ・データベースの起動
フィジカル・スタンバイ・データベースおよびREDO Applyを起動するステップを次に示します。 - フィジカル・スタンバイの作成タスク7: フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認
フィジカル・スタンバイ・データベースを作成してREDO転送サービスを設定した後、データベースの変更がプライマリ・データベースからスタンバイ・データベースに正常に転送されているかどうかの確認が必要な場合があります。
Oracle Data Guardを使用したデータベースのアップグレードの準備
このシナリオでは、Data Guard BrokerでOracle Data Guardを使用してアップグレードを実行し、アップグレードを開始する前にData Guard Broker構成ファイルを移動します。
DB_BROKER_CONFIGファイルのデフォルトの場所は、以前のリリースのOracle Database Oracleホームのdbsディレクトリ内です。Oracle Data Guardを使用してデータベース・インスタンスのローリング・アップグレードを実行する場合、DG_BROKER_CONFIGファイルを前のリリースのOracleホーム外のマウント・ポイント場所に移動する必要があります。また、DG_BROKER_CONFIG_FILEnパラメータでは、必ずその場所を以前のリリースのOracleホーム内の場所のかわりに指定してください。データベースのアップグレード中にリスナーを移行しないでください。アップグレードが完了した後、リスナーを停止し、データベースを停止し、以前のソースのOracle Databaseリリース環境から新しいOracle Databaseリリース環境にlistener.oraおよびtnsnames.oraをコピーして、リスナーおよびデータベースを起動します。
アップグレード開始前の作業
ローリング・アップグレード中にDB_BROKER_CONFIGファイルにアクセスできるようにするには、アップグレードを開始する前に、次の作業を完了する必要があります
-
アップグレードを開始する前に、ストレージにOracle Automatic Storage Management (Oracle ASM)を使用していない場合は、Oracle Data Guardファイル
DG_BROKER_CONFIG_FILE1およびDG_BROKER_CONFIG_FILE2を、ソースまたはターゲットのOracle Database OracleホームのOracleホーム・パス以外の場所にあるサーバー上の別のマウント・ポイントに設定します。ノート:
Oracle Database 21cより前のデフォルトの
ORACLE_HOMEレイアウトでは、ORACLE_HOME、ORACLE_BASE_HOMEおよびORACLE_BASE_CONFIGが1つの場所にまとめられていました。Oracle Database 21c以降では、使用可能な構成は読取り専用のORACLE_HOMEのみであり、ORACLE_BASE_HOMEとORACLE_BASE_CONFIGは、ORACLE_HOMEとは別に配置されています。以前にフォルダdbsにあったOracle Data Guardファイルなどのファイルは、現在はORACLE_BASE_CONFIG/dbsにあります。 -
以前のリリースのOracleホームから新しいOracle Databaseリリースへのアップグレードを正常に完了します。
アップグレード中の作業
アップグレード中に、リスナーを移行しないでください。
AutoUpgradeを使用してアップグレードを完了することをお薦めします。
次を参照してください。
アップグレード完了後の作業
- 新しいリリースのOracle Databaseのリスナーを停止します。
- 新しいリリースのOracle Databaseを停止します。
- 以前のリリースのOracle Databaseから新しいリリースのOracle Databaseに
listener.oraおよびtnsnames.oraファイルをコピーします。 - リスナーと新しいリリースのOracle Databaseを起動します
Data Guard Broker構成ファイルの移動の詳細は、『Oracle Data Guard Broker』を参照してください。
AutoUpgradeおよびOracle Data Guardでアップグレードする方法のデモを確認してください
Daniel Overby Hansenが、AutoUpgradeを使用し、Oracle Data Guardスタンバイ・データベースを使用してOracle Databasesのアップグレードを実行する方法の概要を示します。
Data Guardスタンバイを使用した非CDBからPDBへの手動変換およびアップグレード
非CDBをPDBにアップグレードするOracle Data Guardを使用したアップグレードおよび非CDBスタンバイ・データファイルの再利用には、特別な手順が必要です。
非CDBソースのOracle Database構成にOracle Data Guardデプロイメントがあり、非CDBをPDBとしてOracle Data Guard構成のプライマリ・データベースに接続した後、ターゲットPDBでソース・スタンバイ・データベース・ファイルを再利用する場合は、手動で実行する必要がある特定のステップがあります。AutoUpgradeの現在のリリースでは、この機能はサポートされていません。
このシナリオでのアップグレードの完了方法の詳細は、Data Guard構成のプライマリ・データベースに非CDBをPDBとして接続する場合のソース・スタンバイ・データベース・ファイルの再利用(ドキュメントID 2273304.1)を参照してください
Oracle Databaseソフトウェアをパッチ適用またはアップグレードする前の注意事項
Oracle Databaseソフトウェアをパッチ適用またはアップグレードする前に、様々なユースケース・シナリオの前提条件を確認してください。
-
Oracle Data Guard Brokerを使用して構成を管理している場合は、Oracle Data Guard Brokerの手順に従います。
-
これらのトピックで説明する手順は、Oracle Databaseアップグレード・ガイドに記載されている他のアップグレード手順およびガイドラインと組み合せて使用してください。
-
NOLOGGING操作をチェックします。NOLOGGING操作が実行されていた場合は、スタンバイ・データベースを更新する必要があります。NOLOGGING句を指定した後のリカバリを参照してください
-
OFFLINE IMMEDIATEが原因でリカバリを必要とする表領域またはデータファイルをノートにとっておきます。アップグレードを開始する前に、表領域またはデータファイルをリカバリし、オンラインまたはオフラインにする必要があります。 -
Oracle Data Guard構成では、すべてのフィジカルおよびスナップショット・スタンバイ・データベースはプライマリ・データベースからのパスワード・ファイルのコピーを使用する必要があります。プライマリ・データベースで実行されたパスワード・ファイルの変更は、スタンバイ・データベースに自動的に伝搬されます。パスワード・ファイルの変更は、管理権限(
SYSDG、SYSOPER、SYSDBAなど)が付与または取り消されたとき、および管理権限を持つユーザーのパスワードが変更されたときのイベントです。遠隔同期インスタンスは、自動更新機能の例外です。更新したパスワード・ファイルは、引き続き手動で遠隔同期インスタンスにコピーする必要があります。遠隔同期インスタンスはREDOを受け取りますが、適用しないためです。遠隔同期インスタンスでパスワード・ファイルが手動で更新されると、プライマリ・データベースからの同じパスワード変更内容を含むREDOが、遠隔同期インスタンスからREDOを受け取るように設定されているすべてのスタンバイ・データベースに自動的に伝播されます。REDOが適用されると、スタンバイでパスワード・ファイルが更新されます。
ノート:
カスケード・スタンバイが構成にある場合、これらのカスケード・スタンバイは他のスタンバイと同じルールに従う必要がありますが、最後に停止し、新しいホームで最初に再起動します。
NOLOGGING句を指定した後のリカバリ
一部のSQL文では、NOLOGGING句を指定して、操作がオンラインREDOログ・ファイルに記録されないようにできます。
実際には、NOLOGGINGを指定すると、REDOレコードはオンラインREDOログ・ファイルに書き込まれますが、レコードに関連付けられたデータはありません。この指定により、スタンバイ・サイトでログ・アプリケーションまたはデータ・アクセス・エラーが発生する可能性があります。ログ・ファイルの適用を再開するには、手動リカバリが必要な場合があります。ロジカル・スタンバイとフィジカル・スタンバイのどちらを使用するかに応じて次の操作を行うことで、これらのエラーを防止できます。
-
ロジカル・スタンバイ
CREATE DATABASE文またはALTER DATABASE文にFORCE LOGGING句を指定します。 -
フィジカル・スタンバイ
Data Guard構成の使用方法に適したロギング・モードを指定します。
適切なロギング・モードの有効化を参照してください。
現在のロギング・モードは、V$DATABASE.FORCE_LOGGING列(CDBの場合)またはDBA_PDBS.FORCE_LOGGING列(PDBの場合)で確認できます。
適切なロギング・モードの有効化
スタンバイ・データベースを作成するためのプライマリ・データベースの準備の一環として、Data Guard構成の使用方法に適したロギング・モードを有効にする必要があります。
Oracle Data Guard構成の一部ではないデータベースのデフォルトのロギング・モードでは、特定のデータ・ロード操作をログに記録されない方法で実行できます。このデフォルト・モードは、ロードされたデータがスタンバイから欠落し、修正に手動操作が必要になるため、スタンバイを含むデータベースには適していません。
デフォルトのロギング・モードに加えて、プライマリ・データベースに適したモードが他に3つあります。
-
FORCE LOGGINGモードでは、ログに記録されない方法でロード操作が実行されることを防止できます。このモードでは、ロードされたデータをREDOログにコピーする必要があるため、ロード・プロセスの速度が低下する可能性があります。FORCE LOGGINGモードを有効化するには、次のコマンドを使用します。SQL> ALTER DATABASE FORCE LOGGING; -
STANDBY NOLOGGING FOR DATA AVAILABILITYモードでロード操作を実行すると、ロードされたデータがスタンバイ固有の接続を介して各スタンバイに送信されます。コミットは、すべてのスタンバイがActive Data Guard環境内の管理リカバリ実行の一部としてデータを適用するまで遅延されます。これは、次のコマンドを使用して有効化されます。SQL> ALTER DATABASE SET STANDBY NOLOGGING FOR DATA AVAILABILITY; -
STANDBY NOLOGGING FOR LOAD PERFORMANCEは、前述のモードに似ていますが、プライマリにデータをロードする際のネットワーク速度を維持できない場合に、ロード・プロセスによるスタンバイへのデータ送信を停止できる点が異なります。このモードでは、スタンバイからデータが欠落する可能性がありますが、各スタンバイはActive Data Guard環境内の管理リカバリ実行の通常の一部として、プライマリ・データベースのデータを自動的にフェッチします。これは、次のコマンドを使用して有効化されます。SQL> ALTER DATABASE SET STANDBY NOLOGGING FOR LOAD PERFORMANCE;
これらの文のいずれかを発行する場合は、プライマリ・データベースを少なくともマウントしておく(また、オープンもできるようにしておく)必要があります。この文は、完了までに非常に時間がかかる場合があります。これは、ログに記録されないダイレクト書込みI/Oがすべて完了するまで待機するためです。
ノート:
プライマリ・データベースでSTANDBY NOLOGGING FOR DATA AVAILABILITYまたはSTANDBY NOLOGGING FOR LOAD PERFORMANCEを有効にすると、複数インスタンスのREDO Apply機能を使用しているすべてのスタンバイはREDOの適用を停止し、エラーORA-10892が発生します。まず、REDO Applyを再開し、影響を受けたスタンバイがNOLOGGING操作期間を超えて進行できるようにしてから、複数インスタンスのREDO Applyを有効化する必要があります。
関連項目
参照:
FORCE LOGGINGモード指定の影響の詳細は、Oracle Database管理者ガイドを参照してください。
フィジカル・スタンバイの作成 タスク1: プライマリ・データベース・データファイルのバックアップ・コピーの作成
データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルがあるかぎり、プライマリ・データベースのバックアップ・コピーを使用して、フィジカル・スタンバイ・データベースを作成できます。
Oracleでは、Recovery Managerユーティリティ(RMAN)を使用することをお薦めします。
フィジカル・スタンバイの作成 タスク2: スタンバイ・データベース用の制御ファイルの作成
スタンバイ・データベース用の制御ファイルを作成します。プライマリ・データベースはオープンしている必要はありませんが、少なくともマウントされている必要があります。
スタンバイ・データベース用の制御ファイルを作成する必要があります。プライマリ・データベースとスタンバイ・データベースの両方に単一の制御ファイルを使用することはできません。それぞれに独自のファイルが必要です。
例3-1 スタンバイ・データベース用の制御ファイルの作成
ALTER DATABASEコマンドは、スタンバイ・ロールで操作するデータベースを指定します。この例では、そのスタンバイ・データベースの名前はbostonです。
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl';
ノート:
制御ファイルのバックアップがプライマリで作成され、スタンバイでリストアされる場合(またはその逆)、リストアされたシステム上のスナップショット制御ファイルの場所がデフォルトになるように構成されます。スナップショット制御ファイル名のデフォルト値はプラットフォーム固有であり、Oracleホームに依存します。RMANコマンドCONFIGURE SNAPSHOT CONTROLFILEを使用して、手動で正しい値に再構成します。詳細は、Oracleグローバル分散データベース・ガイドを参照してください
フィジカル・スタンバイの作成 タスク3: スタンバイ・データベース用のパラメータ・ファイルの作成
プライマリ・データベースで使用されるサーバー・パラメータ・ファイル(SPFILE)からパラメータ・ファイル(PFILE)を作成します。
スタンバイ・データベースのパラメータ・ファイルを作成するには、次のステップを実行します。
例3-2 フィジカル・スタンバイ・データベース用の初期化パラメータの変更
この例は、プライマリで以前に作成された、変更する必要のあるパラメータを示しています。フィジカル・スタンバイ・データベースの場合に変更する必要があるパラメータは、太字で示されています。太字で示されていないパラメータ(DB_NAMEなど)は、スタンバイ・データベースでの値が、プライマリ・データベース上と同じである必要があります。
. . . DB_NAME=chicago DB_UNIQUE_NAME=boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)' CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl' DB_FILE_NAME_CONVERT='/chicago/','/boston/' LOG_FILE_NAME_CONVERT='/chicago/','/boston/' LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc LOG_ARCHIVE_DEST_1= 'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=chicago ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE STANDBY_FILE_MANAGEMENT=AUTO FAL_SERVER=chicago . . .
プライマリ・データベースとスタンバイ・データベースでは、COMPATIBLE初期化パラメータを同じ値に設定する必要があります。値が異なる場合、REDO転送サービスがREDOデータをプライマリ・データベースからスタンバイ・データベースに転送できない可能性があります。
SHOW PARAMETERSコマンドを使用して、他に変更を必要とするパラメータがないことを確認することをお薦めします。
次の表に、プライマリ・データベースとは異なる設定を持つパラメータ設定に関する簡単な説明を示します。
| パラメータ | お薦めする設定 |
|---|---|
|
|
このデータベースの一意の名前を指定します。この名前はこのデータベースを一意に識別し、プライマリ・データベースとスタンバイ・データベースのロールが逆になっても変更されません。 |
|
|
スタンバイ・データベースの制御ファイルのパス名を指定します。このトピックの例では、2つの制御ファイルのパス名を指定する方法を示します。Oracleでは、制御ファイルが破損した場合に、問題のない制御ファイルを問題のある制御ファイルの場所にコピーした後でインスタンスを簡単に再起動できるように、制御ファイルのコピーを使用可能にすることをお薦めします。 |
|
|
プライマリ・データベースのデータファイルのパス名とファイル名の場所を指定し、その後にスタンバイの場所を指定します。 |
|
|
プライマリ・データベースのオンラインREDOログ・ファイルの位置を指定し、その後にスタンバイの位置を指定します。このパラメータにより、プライマリ・データベースのログ・ファイルのパス名がスタンバイ・データベースのパス名に変換されます。 |
|
|
REDOデータのアーカイブ先を指定します。このトピックの例では、次の宛先を指定しています。
ノート: 高速リカバリ領域が( |
|
|
スタンバイ・データベースのFAL (フェッチ・アーカイブ・ログ)サーバーのOracle Netサービス名を指定します。通常、このサービス名はプライマリ・ロールで実行されているデータベース名です。ボストンのデータベースがスタンバイ・ロールで実行されている場合、シカゴのデータベースが欠落ログ・ファイルを自動的に送信できないと、シカゴのデータベースがFALサーバーとして使用され、そこから欠落しているアーカイブREDOログ・ファイルがフェッチ(要求)されます。 |
ノート:
変更が必要なその他のパラメータがないか、初期化パラメータ・ファイルを確認してください。たとえばスタンバイ・データベース上のディレクトリ場所がプライマリ・データベースでの指定と異なる場合は、ダンプ先パラメータを変更する必要があります。
フィジカル・スタンバイ・データベースが存在する場合のOracle Databaseのアップグレード
これらのステップでは、構成にフィジカル・スタンバイ・データベースが存在する場合にOracle Databaseにアップグレードする方法について説明します。
ノート:
アップグレードするデータベースがOracle Data Guard Broker構成のメンバーである場合は、続行する前にファスト・スタート・フェイルオーバーを無効化し、ブローカを停止する必要があります。これを実行する方法の詳細は、Oracle Data Guard Brokerを参照してください。フィジカル・スタンバイの作成 タスク4: プライマリ・システムからスタンバイ・システムへのファイルのコピー
必要なディレクトリがすべて作成されていることを確認してください。オペレーティング・システムのコピー・ユーティリティを使用して、プライマリ・システムからスタンバイ・システムの正しい場所にバイナリ・ファイルをコピーします。
次のバイナリ・ファイルをスタンバイ・システムの正しい場所にコピーします。
-
プライマリOracle Databaseバックアップ。
プライマリ・データベース・データファイルのバックアップ・コピーの作成を参照してください
-
スタンバイ制御ファイル。
スタンバイ・データベース用の制御ファイルの作成を参照してください
-
スタンバイ・データベースの初期化パラメータ・ファイル。
スタンバイ・データベース用のパラメータ・ファイルの作成を参照してください
フィジカル・スタンバイの作成 タスク5: スタンバイ・データベースをサポートする環境の設定
Microsoft Windowsベースのサービス、パスワード・ファイルおよびSPFILEを作成してからOracle Net環境を設定して、環境を設定します。
環境を設定するには、次のステップを実行します。
フィジカル・スタンバイの作成 タスク7: フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認
フィジカル・スタンバイ・データベースを作成してREDO転送サービスを設定した後、データベースの変更がプライマリ・データベースからスタンバイ・データベースに正常に転送されているかどうかの確認が必要な場合があります。
REDOがプライマリ・データベースから送信されてスタンバイ・データベースに適用されていることを確認するには、スタンバイ・データベースに接続し、V$DATAGUARD_PROCESSビューを問い合せます。
例3-3 プライマリからセカンダリ・データベースへのREDO送信を検証するためのV$DATAGUARD_PROCESSの問合せ
SQL> SELECT ROLE, THREAD#, SEQUENCE#, ACTION FROM V$DATAGUARD_PROCESS;
ROLE THREAD# SEQUENCE# ACTION
------------------------ ---------- ---------- ------------
RFS ping 1 9 IDLE
recovery apply applier 0 0 IDLE
recovery apply applier 0 0 IDLE
managed recovery 0 0 IDLE
recovery logmerger 1 9 APPLYING_LOG
RFS archive 0 0 IDLE
RFS async 1 9 IDLErecovery logmergerロールは、REDOがスタンバイに適用されていることを示しています。
ノート:
V$MANAGED_STANDBYビューのかわりにV$DATAGUARD_PROCESSビューを使用します。V$MANAGED_STANDBYは、Oracle Database 12c リリース2 (12.2.0.1)で非推奨になり、将来のリリースではサポートされなくなる可能性があります。