8 DGMGRLコマンドライン・インタフェースの使用例
次の各使用例では、Oracle Data Guard Broker構成の作成、管理および使用を開始するために必要なものを例をあげて説明します。
Oracle Data Guardコマンドライン・インタフェース(DGMGRL)の使用を開始するための前提条件を知ることで、自身の事例に備えることができます。さらに、使用例を読んで、DGMGRLを使用してブローカ構成を作成、管理および監視する方法を理解してください。
初期使用の前提条件
DGMGRL使用の前提条件の1つは、1つのプライマリ・データベースと任意の数のスタンバイ・データベースが存在していることです。
構成内のすべてのデータベースについて、DG_BROKER_START初期化パラメータをTRUEに設定する必要があります。また、各データベースがサーバー・パラメータ・ファイル(SPFILE)を使用するように構成されている必要があります。
必要な場合は、プライマリ・データベースとスタンバイ・データベースの初期化パラメータ・ファイル(PFILE)をサーバー・パラメータ・ファイル(SPFILE)に変換します。次のSQL*Plusコマンドを使用します。
CREATE SPFILE='spfilename' FROM PFILE='pfilename';
サーバー・パラメータ・ファイルを使用してインスタンスが起動されていない場合は、そのインスタンスを停止し、サーバー・パラメータ・ファイルを使用して再起動します。
Oracleインスタンスの起動後に、SQLのALTER SYSTEM文を使用してDG_BROKER_START=TRUE初期化パラメータを設定します。パラメータ値は、サーバー・パラメータ・ファイルに保存されます。Oracleインスタンスの次回起動時にブローカが自動的に起動されるため、SQLのALTER SYSTEM文の再発行は不要です。
これらの使用例では、次を前提としています。
-
プライマリ・データベースとスタンバイ・データベースへの接続にTCP/IPが使用されていること。
-
プライマリ・データベースの制御ファイルとデータファイルのバックアップから、スタンバイ・データベースが作成されていること(詳細は『Oracle Data Guard概要および管理』を参照)
-
使用例は、次のブローカ構成を前提としています。
-
構成名は
DRSolutionです。 -
プライマリ・データベースの一意名(
DB_UNIQUE_NAME)はNorth_Salesです。 -
リモート・スタンバイ・データベースの一意名(
DB_UNIQUE_NAME)はSouth_Salesです。 -
保護モードは最大パフォーマンス・モードです。
-
プライマリ・データベースおよびスタンバイ・データベースの両方にスタンバイREDOログ・ファイルが構成されます。両方のデータベースの転送モードは
ASYNCです。 -
スタンバイ・データベースはフィジカル・スタンバイ・データベースです。
-
使用例1: 構成の作成
これらの例では、North_SalesおよびSouth_Salesという名前のプライマリ・データベースおよびスタンバイ・データベースを含むDRSolutionという名前のブローカ構成を作成します。
構成を作成してフィジカル・スタンバイ・データベースを1つ追加するには、次のタスクを実行します。
構成の作成(タスク1): DGMGRLの起動
DGMGRLを起動するには、Oracle Data Guardがインストールされているシステム上で、コマンドライン・プロンプトからdgmgrlと入力します。
$ dgmgrl
DGMGRLプロンプトが表示されます。
DGMGRL>
構成の作成(タスク2): プライマリ・データベースへの接続
コマンド(HELP、EXIT、QUIT以外)を実行する前に、まずDGMGRL CONNECTコマンドを使用してプライマリ・データベースに接続します。プライマリ・データベースへの接続に使用するアカウントには、SYSDGまたはSYSDBA権限が必要です。OS認証の使用によるローカル・データベースへの接続は、可能ですが、リモート・ホスト上の構成メンバーへの接続も必要なブローカ操作が失敗することになるためお薦めしません。
ノート:
AS句がCONNECTコマンドで指定されていない場合、接続はSYSDBAとして作成されます。
次の例では、TNS別名north_salesを使用し、SYSユーザーを使用してプライマリ・データベースNorth_Salesに接続します。次の例で示すように、コマンドラインにパスワードが含まれていない場合は、DGMGRLによってパスワードの入力が求められます:
DGMGRL> CONNECT sys@north_sales Password: password Connected to "North_Sales" Connected as SYSDBA.
ノート:
ユーザーとしてのSYSDGは、Oracle Database 23aiでは削除されています。ただし、SYSDGロールについては、以前のリリースと同様であり変更はありません。CONNECTコマンドにAS句を指定しなかった場合は、その接続により、最初にAS SYSDGが試行された後、それに失敗するともう一度AS SYSDBAが試行され、それでも失敗した場合はエラーが返されます。
構成の作成(タスク3): 追加するスタンバイおよび遠隔同期インスタンス上での既存のリモートREDO転送先のクリア。
スタンバイ・データベースおよび遠隔同期インスタンス上でリモートREDO転送先をすべてクリアしてからでないと、そのスタンバイ・データベースおよび遠隔同期インスタンスを構成に追加できません。
リモートのREDO転送先がクリアされていない場合、構成を作成しようとすると、次のエラー・メッセージが返されます。
ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added Failed.
LOG_ARCHIVE_DEST_n設定をクリアするには、SQL*PlusコマンドALTER SYSTEM SET LOG_ARCHIVE_DEST_n=" "を使用します。
プライマリ上のリモートREDO転送先(REGISTER属性またはNOREGISTER属性のどちらがあるか)は、そのままでかまいません。
構成の作成(タスク4): ブローカ構成の作成
ブローカ構成は最初にプライマリ・データベースで作成されます。
この例では、プライマリはNorth_Salesと呼ばれます。後のコマンドで、スタンバイ・データベースSouth_Salesを追加します。
ノート:
プライマリ・データベース名とスタンバイ・データベース名では、それぞれのデータベースの一意名が一致する必要があります。これらの一意名は、次のコマンドを使用してDB_UNIQUE_NAME初期化パラメータからフェッチします。
SQL> SHOW PARAMETER DB_UNIQUE_NAME;
CREATE CONFIGURATIONコマンドを使用して、プライマリ・データベースNorth_Salesを含めてDRSolution構成を作成します。名前North_Salesはプライマリ・データベースのDB_UNIQUE_NAME初期化パラメータの値であり、north_salesは、構成のメンバーをホストしているすべてのシステム上のプライマリ・データベースの接続識別子に解決されるTNS別名です。
DGMGRL> CREATE CONFIGURATION 'DRSolution' AS > PRIMARY DATABASE IS 'North_Sales' > CONNECT IDENTIFIER IS north_sales; Connected to "North_Sales" Configuration "DRSolution" created with primary database "North_Sales"
名前North_Salesは、このデータベースのDB_UNIQUE_NAME初期化パラメータの値です。
構成の作成(タスク5): 構成情報の表示
SHOW CONFIGURATIONコマンドを使用して、構成について現在の状態のサマリーを表示します。
DGMGRL> SHOW CONFIGURATION;
DGMGRLは次の情報を戻します。
Configuration - DRSolution Protection Mode: MaxPerformance Members: North_Sales - Primary database Fast-Start Failover: Disabled Configuration Status: DISABLED
構成の作成(タスク6): 構成へのスタンバイ・データベースの追加
DRSolution構成にスタンバイ・データベースを追加するには、 ADD DATABASEコマンドを使用します。
ADD DATABASEコマンドを使用して、プライマリ・データベースNorth_Salesに関連付けられているスタンバイ・データベースSouth_Salesを構成に追加します。名前South_Salesはスタンバイ・データベースのDB_UNIQUE_NAME初期化パラメータの値であり、south_salesは、構成のメンバーをホストしているすべてのシステム上のスタンバイ・データベースの接続識別子に解決されるTNS別名です。
DGMGRL> ADD DATABASE 'South_Sales' AS > CONNECT IDENTIFIER IS south_sales; Database "South_Sales" added
SHOW CONFIGURATIONを使用して、更新された構成状態を表示します:
DGMGRL> SHOW CONFIGURATION;
DGMGRLは次の情報を戻します。
Configuration - DRSolution
Protection Mode: MaxPerformance
Members:
North_Sales - Primary database
South_Sales - Physical standby database
Fast-Start Failover: Disabled
Configuration Status:
DISABLED
使用例2: データベース・プロパティの設定
DGMGRLを使用して構成を作成した後は、いつでもデータベース・プロパティを設定できます。
たとえば、次の文は、South_Salesスタンバイ・データベースのデータベース・プロパティStandbyArchiveLocationを設定します。
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'StandbyArchiveLocation'='/archfs/arch/'; Property "StandbyArchiveLocation" updated.
データベースのすべてのプロパティとその値を表示するには、SHOW DATABASE VERBOSEコマンドを使用します。次の例は、South_Salesデータベースのプロパティを示しています。
DGMGRL> SHOW DATABASE VERBOSE 'South_Sales'
Database - South_Sales
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Average Apply Rate: 2.00 KByte/s
Active Apply Rate: 0 Byte/s
Maximum Apply Rate: 0 Byte/s
Real Time Query: ON
Instance(s):
South_sales1
Properties:
DGConnectIdentifier = 'South_Sales.example.com'
ObserverConnectIdentifier = ''
FastStartFailoverTarget = ''
PreferredObserverHosts = ''
LogShipping = 'ON'
RedoRoutes = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyLagThreshold = '0'
TransportLagThreshold = '0'
TransportDisconnectedThreshold = '0'
ApplyParallel = 'AUTO'
ApplyInstances = '0'
ArchiveLocation = ''
AlternateLocation = ''
StandbyArchiveLocation = ''
StandbyAlternateLocation = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
LogXptStatus = '(monitor)'
SendQEntries = '(monitor)'
RecvQEntries = '(monitor)'
HostName = 'South_Sales.example.com'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=South_Sales.example.com)(PORT=2879)))(CONNECT_DATA=(SERVICE_NAME=South_Sales_DGMGRL.example.com)(INSTANCE_NAME=south_sales1)(SERVER=DEDICATED)))'
TopWaitEvents = '(monitor)'
SidName = '(monitor)'
Log file locations:
Alert log : /db/oracle/log/diag/rdbms/South_Sales/south_sales1/trace/alert_south_sales1.log
Data Guard Broker log : /db/oracle/log/diag/rdbms/South_Sales/south_sales1/trace/drcsouth_sales1.log
Database Status:
SUCCESS
データベースのブローカ管理が有効な場合は、データベース・プロパティ値を設定すると、対応するデータベースの基礎となるパラメータ値が変更され、変更されたパラメータの値がサーバー・パラメータ・ファイルに反映されます。したがって、データベースがOracle Enterprise Manager Cloud Control (Cloud Control)およびDGMGRL以外(SQL*Plusインタフェースなど)から停止および再起動された場合は、更新されたサーバー・パラメータ・ファイルの新規パラメータ値がデータベースの起動時に使用されます。ただし、SQL文を使用してREDO転送サービスの初期化パラメータを変更しないでください。それを行うと、データベースとブローカ間の一貫性が失われます。
ノート:
通常、データベース・プロパティは、対応する初期化パラメータ、SQL文またはPL/SQLプロシージャ(通常は大文字表記)と視覚的に区別しやすいように、大/小文字混合表記(LogXptModeなど)で表示されます。ただし、プロパティ管理コマンドでは大/小文字は区別されないため、大文字、小文字または混合表記でコマンドを発行できます。
プロパティは、データベースが有効な場合でも無効な場合でも変更できます。ただし、プロパティの変更時にデータベースが無効な場合、変更結果はデータベースが有効化されるまで有効になりません。
使用例3: 構成とデータベースの有効化
これまでDRSolution構成は無効化されており、Data Guard Brokerの制御下にはありませんでした。
ブローカ構成に対するデータベースの構成および必要なデータベース・プロパティの設定を完了した後に、構成を有効化してData Guard Brokerで管理できるようにする必要があります。
次のいずれかを有効化できます。
-
すべてのデータベースを含む構成全体
-
スタンバイ・データベース
構成全体の有効化
構成を表示します
SHOWコマンドを使用して、構成とそのデータベースが正常に有効化されていることを確認します。
DGMGRL> SHOW CONFIGURATION; Configuration - DRSolution Protection Mode: MaxPerformance Members: North_Sales - Primary database South_Sales - Physical standby database Fast-Start Failover: Disabled Configuration Status: SUCCESS (status updated 52 seconds ago)
データベースの有効化
このステップは、前にDISABLE DATABASEコマンドを使用してスタンバイ・データベースを無効化している場合にのみ実行します。通常は、構成を有効化するとスタンバイ・データベースも有効化されます。
DGMGRL> ENABLE DATABASE 'South_Sales'; Enabled.
データベースの表示
DGMGRL> SHOW DATABASE 'South_Sales';
Database - South_Sales
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 0 seconds (computed 1 second ago)
Average Apply Rate: 9.00 KByte/s
Real Time Query: OFF
Instance(s):
SouthSales
Database Status:
SUCCESS
使用例4: 構成保護モードの設定
構成の保護モードはいつでも変更できます。
ノート:
保護モードを最大パフォーマンス・モードから最大保護モードへは変更できません。まず保護モードを最大可用性に変更してから、最大保護モードに変更します。
保護モードを変更する場合、プライマリ・データベースの再起動は不要です。
この使用例では、構成の保護モードをMAXAVAILABILITYモードに設定します。この保護モードに設定するには、少なくとも1つのスタンバイ・データベースをスタンバイREDOログ・ファイルを使用するように構成し、同期またはFASTSYNCモードを介してREDOを受け取る必要があります。スタンバイが遠隔同期インスタンスを介してREDOを受け取る場合、遠隔同期インスタンスはSYNCまたはFASTYSYNCモードでREDOを受け取り、スタンバイはASYNCモードで遠隔同期インスタンスからREDOを受け取る必要があります。
-
スタンバイREDOログ・ファイルを構成します(必要な場合)。
保護モードを
MAXAVAILABILITYモードに設定するため、スタンバイ・データベースに十分なスタンバイREDOログ・ファイルが構成されていることを確認する必要があります。REDO転送の設定方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。 -
REDO転送モードを適切に構成します。
スタンバイがプライマリ・データベースから直接REDOを受け取る場合、
SYNCまたはFASTSYNCモードでREDOを受け取るようにスタンバイを構成します。スタンバイが遠隔同期インスタンスを介してプライマリREDOを受け取る場合、SYNCまたはFASTSYNCモードでREDOを受け取るように遠隔同期インスタンスを構成し、遠隔同期インスタンスからASYNCモードでREDOを受け取るようにスタンバイを構成します。たとえば:DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogXptMode'='SYNC'; Property "LogXptMode" updated
スタンバイREDOログ・ファイルを使用するように構成されたスタンバイ・データベースが構成内に含まれていないかぎり、このコマンドは正常終了しません。
-
構成全体の保護モードを変更します。
EDITCONFIGURATIONコマンドを使用して、ブローカ構成の保護モードをMAXAVAILABILITYにアップグレードします。DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY; Succeeded.
このコマンドを入力したときに構成が無効な場合、実際の保護モードの変更は、
ENABLE CONFIGURATIONコマンドで構成が有効化されるまで適用されません。保護モードの要件をサポートできるスタンバイ・データベースが構成内に存在しない場合、構成は有効化できません。 -
保護モードが変更されたことを確認します。
SHOW CONFIGURATIONコマンドを使用して構成の現在の保護モードを表示します。DGMGRL> SHOW CONFIGURATION; Configuration - DRSolution Protection Mode: MaxAvailability Members: North_Sales - Primary database South_Sales - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
関連項目:
使用例5: 遠隔同期インスタンスでの「最大可用性」モードの設定
プライマリ・データベースとスタンバイ・データベースが地理的に遠すぎて同期転送モードが実用的でない場合、遠隔同期インスタンスを最大可用性保護モードで使用することができます。
このトピックの例は、遠隔同期インスタンスを構成に追加し、構成のすべてのメンバーに対してRedoRoutesプロパティを設定する方法を示しています。遠隔同期インスタンスに対してRedoRoutesプロパティを設定すると、North_SalesデータベースとSouth_Salesデータベースのいずれかプライマリである方に基づいてREDOデータを送信できます。
使用例6: ファスト・スタート・フェイルオーバーの有効化とオブザーバの起動
ブローカ構成のデータベースに接続されているかぎり、オブザーバ・サイトを含め、任意のサイトからファスト・スタート・フェイルオーバーを有効化できます。
ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、フェイルオーバーの条件が満たされた場合に、構成を監視しているオブザーバがファスト・スタート・フェイルオーバーを起動できるようになります。この項では、ファスト・スタート・フェイルオーバーを有効化し、構成の保護モードが最大可用性モードに設定されるオブザーバを起動するステップを説明します。
使用例7: 遠隔同期インスタンスが使用中の場合のファスト・スタート・フェイルオーバーの有効化
ファスト・スタート・フェイルオーバーのターゲットが、遠隔同期インスタンスからREDOデータを受け取る論理またはフィジカル・スタンバイ・データベースの場合、ファスト・スタート・フェイルオーバーを最大可用性モードで有効化できます。
遠隔同期インスタンスを使用してREDOデータをスタンバイ・データベースに送信している場合にファスト・スタート・フェイルオーバーを有効にするには、次のようにして、先にプライマリおよびターゲット・スタンバイ・データベース上でFastStartFailoverTargetプロパティを設定する必要があります。
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget='South_Sales'; DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY FastStartFailoverTarget='North_Sales';
その場合、次のようにしてファスト・スタート・フェイルオーバーを有効化できます。
DGMGRL> ENABLE FAST_START FAILOVER;
遠隔同期インスタンス・データベースが、North_SalesやSouth_Salesのファスト・スタート・フェイルオーバー・ターゲットとして指定されていない点に注意してください。
使用例8: 定期的な管理タスクの実施
1つ以上のデータベースの定期的なメンテナンスを実行するために、ブローカ構成に含まれるデータベースの状態やプロパティの変更が必要になる場合があります。
また、構成に含まれるデータベースのブローカ管理を一時的に無効化する必要が生じる場合もあります。
プロパティと状態の変更
構成の監視中に、データベースやそのプロパティの状態を動的に変更する操作が必要になる場合があります。
次の各トピックで、構成内のデータベースの状態またはプロパティを変更する方法について説明します。
データベース・プロパティの変更
データベース・プロパティの値は、データベースが有効か無効かに関係なくいつでも変更できます。
次の例は、EDIT DATABASEコマンドを使用してNorth_Salesデータベースのデータベース・プロパティLogXptModeを値ASYNCに変更する方法を示しています。
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogXptMode'=ASYNC;
DGMGRLは次のメッセージを戻します。このメッセージは、LogXptModeプロパティがData Guard構成ファイル内で正常に更新されたことを示します。
Property "LogXptMode" updated
構成が現在無効の場合は、ENABLE CONFIGURATIONコマンドでブローカ構成を有効化するまで、データベースで新規プロパティ値が使用されません。
デフォルト値へのプロパティのリセット
データベースや構成が有効/無効のいずれの場合も、構成や設定可能なプロパティを、いつでもそのデフォルト値にリセットできます。
次の例は、EDIT DATABASEコマンドを使用してLogXptModeデータベースの設定可能なプロパティをNorth_Salesデータベースのデフォルト値にリセットする方法を示しています。
EDIT DATABASE 'North_Sales' RESET PROPERTY LogXptMode;
次の例は、EDIT CONFIGURATIONコマンドを使用してTraceLevel構成プロパティをデフォルト値にリセットする方法を示しています。
EDIT CONFIGURATION RESET PROPERTY TraceLevel;
スタンバイ・データベースの状態変更
フィジカル・スタンバイのREDO Applyを一時的に停止できます。
スタンバイ・データベースの状態をAPPLY-OFFに変更するには、次の例のようにEDIT DATABASEコマンドを入力します。
DGMGRL> EDIT DATABASE 'South_Sales' SET STATE='APPLY-OFF'; Succeeded.
フィジカル・スタンバイ・データベースをAPPLY-OFF状態にしても、REDOデータは引き続き受信されます。
構成とデータベースの無効化
ブローカ構成またはそのデータベースのいずれかを無効化すると、それらのブローカによる管理が無効化されるため、DGMGRLを使用してそれらを管理および監視できなくなります。
ただし、ブローカによるブローカ構成の管理を無効にしても、基礎となるOracle Data Guard構成またはデータベースの実際の操作には影響しません。たとえば、Oracle Data Guard構成内のREDO転送サービスとログ適用サービスは、管理できなくなりますが、そのまま機能し続けます。
構成の無効化
プライマリ・データベースを含むブローカ構成全体の管理を無効化するには、DISABLE CONFIGURATIONコマンドを使用する必要があります。
たとえば:
DGMGRL> DISABLE CONFIGURATION;
プライマリ・データベースのブローカ管理を無効化するには、DISABLE CONFIGURATIONコマンドを使用する必要があります。DISABLE DATABASEコマンドで無効化されるのは、スタンバイ・データベースの管理のみです。同様に、DISABLE FAR_SYNCコマンドは、遠隔同期インスタンスの管理のみを無効にします。
ノート:
スタンバイ・データベースまたは遠隔同期インスタンスへの接続時に構成の管理を無効化する場合、構成を再び有効化するには、プライマリ・データベース(制御ファイルのロールがプライマリであるデータベース)に接続する必要があります。
構成メンバーのブローカの管理を無効にしても、そのメンバーはブローカ構成ファイルから削除されません。該当するENABLE CONFIGURATIONまたはENABLE DATABASE コマンドを入力すると、DGMGRL (またはCloud Control)によるメンバー管理機能を再び有効化できます。
スタンバイ・データベースの無効化
ブローカによるスタンバイ・データベースの管理と監視が一時的に不要になった場合は、DISABLE DATABASEコマンドを使用します。
構成の他の部分が有効な場合は、スタンバイ・データベースが有効化されないようにブローカ管理を明示的に無効化できます。次の例は、スタンバイ・データベースSouth_Salesを無効化する方法を示しています。
DGMGRL> DISABLE DATABASE 'South_Sales'; Disabled.
ノート:
構成内のスタンバイ・データベースを無効にするとき、ファスト・スタート・フェイルオーバーが有効化されている場合、ターゲット・スタンバイ・データベースは無効化できません。
ノート:
スタンバイ・データベースへの接続中にそのスタンバイ・データベースの管理を無効化した場合は、スタンバイ・データベースのブローカ管理を再び有効化するために、プライマリ・データベースまたは別の有効化されたスタンバイ・データベースに接続する必要があります。
警告:
ブローカ構成内のスタンバイ・データベースに関してブローカによる管理を無効化すると、プライマリ・データベースが消失した場合にも、そのスタンバイ・データベースはブローカでフェイルオーバー・ターゲットとして使用できなくなります。
最大保護モードまたは最大可用性モードのいずれかで動作している場合、ブローカでは、保護モードをサポートする最後の1つのスタンバイ・データベースを無効化できません。
遠隔同期インスタンスの無効化
ブローカによる遠隔同期インスタンスの管理と監視が一時的に不要になった場合は、DISABLE FAR_SYNCコマンドを使用します。
構成の他の部分が有効な場合は、遠隔同期インスタンスが有効化されないようにブローカ管理を明示的に無効化できます。次の例は、遠隔同期インスタンスを無効化する方法を示しています。
DGMGRL> DISABLE FAR_SYNC 'FS'; Disabled.
ノート:
遠隔同期インスタンスを無効にすると、次の制約が適用されます。
-
他の構成メンバーの
RedoRoutesプロパティで指定されている遠隔同期インスタンスは無効化できません。 -
遠隔同期インスタンスに接続している間にその遠隔同期インスタンスの管理を無効にした場合、遠隔同期インスタンスのブローカ管理を再び有効化するには、プライマリ・データベースまたは別の有効なスタンバイ・データベースに接続する必要があります。
注意:
ブローカ構成で遠隔同期インスタンスのブローカ管理を無効にした場合、他の構成メンバーのRedoRoutesプロパティで、その遠隔同期インスタンスを指定することはできません。
構成、スタンバイ・データベースまたは遠隔同期インスタンスの削除
REMOVE CONFIGURATION、REMOVE DATABASE、またはREMOVE FAR_SYNCコマンドを使用すると、ブローカ構成ファイルから構成、スタンバイ・データベースまたは遠隔同期インスタンスが実質的に削除され、Oracle Data Guard Brokerを使用してそれらを管理できなくなります。
削除操作でPRESERVE DESTINATIONS句を使用した場合、実際のOracle Data Guard構成は削除されず、実際のOracle Data Guard構成とそのデータベースの操作には影響しません。
ノート:
REMOVE CONFIGURATION、REMOVE DATABASEまたはREMOVE FAR_SYNCコマンドを使用した後で、削除したオブジェクトを再作成することに決めた場合、当初発行したコマンドを再び発行する必要があります。必要な場合は「使用例1: 構成の作成」のステップに従って、DGMGRL (またはCloud Control)で管理できるブローカ構成を作成する必要があります。
ノート:
次の制限があります。
-
構成内のスタンバイ・データベースを削除するとき、ファスト・スタート・フェイルオーバーが有効化されている場合、ターゲット・スタンバイ・データベースは削除できません。
-
スタンバイ・データベースまたは遠隔同期インスタンスが、構成に含まれる他のメンバーの
RedoRoutesプロパティで指定されている場合、それらを削除することはできません。
構成からのスタンバイ・データベースの削除
REMOVE DATABASEコマンドを使用すると、ブローカによるデータベースの管理と監視が停止され、データベースがブローカ構成ファイルから削除されます。
South_Salesスタンバイ・データベースを削除する前の構成を示します。
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxPerformance
Members:
North_Sales - Primary database
FS - Far Sync
South_Sales - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 32 seconds ago)
データベースSouth_Salesを指定しないように遠隔同期インスタンスFSのRedoRoutesプロパティをリセットしてから、DGMGRL REMOVE DATABASEコマンドを発行してSouth_Salesデータベース情報をData Guard構成ファイルから削除します。
DGMGRL> EDIT FAR_SYNC ‘FS' RESET PROPERTY RedoRoutes; Property "redoroutes" updated for member "FS". DGMGRL> REMOVE DATABASE ‘South_Sales’; Removed database "South_Sales" from the configuration
South_Salesスタンバイ・データベースを削除した後の構成を示します。
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxPerformance
Members:
North_Sales - Primary database
FS - Far Sync
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 19 seconds ago)
最大保護モードまたは最大可用性モードのいずれかで動作している場合、ブローカでは、保護モードをサポートする最後の1つのスタンバイ・データベースを削除できません。
構成からの遠隔同期インスタンスの削除
Oracle Data Guard構成ファイルから遠隔同期インスタンス情報を削除するには、REMOVE FAR_SYNCコマンドを使用します。
たとえば、次のコマンドを使用してFS遠隔同期インスタンス情報を削除します:
DGMGRL> EDIT DATABASE 'North_Sales' RESET PROPERTY RedoRoutes; Property "redoroutes" updated for member "North_Sales". DGMGRL> REMOVE FAR_SYNC 'FS'; Removed far sync instance "FS" from the configuration
FS遠隔同期インスタンスを削除した後の構成を示します。
DGMGRL> SHOW CONFIGURATION; Configuration - DRSolution Protection Mode: MaxPerformance Members: North_Sales - Primary database Fast-Start Failover: DISABLED Configuration Status: SUCCESS (status updated 44 seconds ago)
ブローカ構成の削除
DGMGRL REMOVE CONFIGURATIONコマンドを使用すると、構成全体がブローカによって管理および監視されなくなります。
たとえば:
DGMGRL> REMOVE CONFIGURATION; Removed configuration
ノート:
ファスト・スタート・フェイルオーバーが有効化されている場合、構成を削除できません。
DGMGRLは次のメッセージを戻します。このメッセージは、コマンドによりData Guard構成ファイルからすべての構成情報が正常に削除されたことを示します。
DGMGRL> SHOW CONFIGURATION; Error: ORA-16532: Data Guard broker configuration does not exist Configuration details cannot be determined by DGMGRL
使用例9: スイッチオーバー操作の実行
プライマリ・データベースとスタンバイ・データベースのロールは、SWITCHOVERコマンドを使用して切り替えることができます。
SWITCHOVERコマンドを発行する前に、次のことを確認する必要があります。
-
プライマリ・データベースとスタンバイ・データベースの状態がそれぞれ
TRANSPORT-ONおよびAPPLY-ONであること。 -
関係するすべてのデータベースが健全な状態で、エラーや警告がないこと。
-
スタンバイ・データベースのプロパティがプライマリ・データベース上で設定されていること。これにより、プライマリ・データベースはスタンバイ・データベースへ遷移するときに正常に機能できます(次の例の太字表記を参照してください)。
-
プライマリ・データベースでスタンバイREDOログ・ファイルが構成されています。
-
構成が最大可用性モードの場合、現在のプライマリは、新しいプライマリから直接REDOを受け取る場合は
SYNC、FASTSYNCまたはASYNCモードでREDOを受け取るように構成されます。遠隔同期インスタンスを介してREDOを受け取る場合、遠隔同期インスタンスはSYNCまたはFASTSYNCモードでREDOを受け取るように構成され、現在のプライマリはASYNCモードでREDOを受け取るように構成されます。構成が最大保護モードの場合、現在のプライマリは、SYNCモードでREDOを受け取るように構成されます。 -
ファスト・スタート・フェイルオーバーが有効化されている場合は、ターゲット・スタンバイ・データベースとして指定されたスタンバイ・データベースへのスイッチオーバーのみ実行できる。
SWITCHOVERコマンドを使用してスイッチオーバーを実行するために必要なタスクは次のとおりです。
SWITCHOVERコマンドの使用(タスク1): プライマリ・データベースのチェック
SHOW DATABASE VERBOSEコマンドを使用して、プライマリ・データベースの状態、健全性およびプロパティをチェックします。
たとえば:
DGMGRL> SHOW DATABASE VERBOSE 'North_Sales';
Database - North_Sales
Role: PRIMARY
Intended State: TRANSPORT-ON
Redo Rate: 104 Byte/s in 15 seconds (computed 9 seconds ago)
Instance(s):
NorthSales
Properties:
AlternateLocation = ''
ApplyInstanceTimeout = '0'
ApplyInstances = '0'
ApplyLagThreshold = '30'
ApplyParallel = 'AUTO'
ArchiveLocation = ''
Binding = 'OPTIONAL'
DGConnectIdentifier = 'north_sales'
DelayMins = '0'
FastStartFailoverTarget = 'South_Sales'
HostName = 'sales1'
InconsistentLogXptProps = '(monitor)'
LogShipping = 'ON'
LogXptMode = 'SYNC'
LogXptStatus = '(monitor)'
MaxFailure = '0'
NetTimeout = '30'
ObserverConnectIdentifier = ''
PreferredApplyInstance = ''
PreferredObserverHosts = ''
RecvQEntries = '(monitor)'
RedoCompression = 'DISABLE'
RedoRoutes = ''
ReopenSecs = '300'
SendQEntries = '(monitor)'
SidName = '(monitor)'
StandbyAlternateLocation = ''
StandbyArchiveLocation = ''
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales1.example.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=North_Sales_DGMGRL.example.com)(INSTANCE_NAME=NorthSales)(SERVER=DEDICATED)))'
TopWaitEvents = '(monitor)'
TransportDisconnectedThreshold = '30'
TransportLagThreshold = '30'
Log file locations:
Alert log : /sales/oracle/diag/rdbms/north_sales/NorthSales/trace/alert_NorthSales.log
Data Guard Broker log : /sales/oracle/diag/rdbms/north_sales/NorthSales/trace/drcNorthSales.log
Database Status:
SUCCESS
特に、プライマリ・データベースの太字のプロパティおよび現在のステータスをチェックする必要があります。
SWITCHOVERコマンドの使用(タスク2): スイッチオーバーのターゲットとなるスタンバイ・データベースのチェック
SHOW DATABASE コマンドを使用して、スイッチオーバーのターゲットとなるスタンバイ・データベースのステータスをチェックします。
たとえば:
DGMGRL> SHOW DATABASE 'South_Sales';
Database - South_Sales
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Apply Rate: 1.44 MByte/s
Real Time Query: OFF
Instance(s):
south_sales1
Database Status:
SUCCESSSWITCHOVERコマンドの使用(タスク3): データベースのロール変更可能確認
ロール変更を実行する前に、VALIDATE DATABASEコマンドを使用して、データベースがロール変更に即時対応可能かどうかを確認する、一連の徹底チェックを実行することができます。
このステップに示す例では、DRSolution構成の3つのデータベース(プライマリ、ロジカル・スタンバイおよびフィジカル・スタンバイの各データベース)すべてにVALIDATE DATABASEコマンドを使用しています。構成は次のようになります。
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxAvailability
Members:
North_Sales - Primary database
South_Sales - Physical standby database
West_Sales - Logical standby database
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 46 seconds ago)
例: プライマリ・データベースの検証
DGMGRL> VALIDATE DATABASE North_Sales;
Database Role: Primary database
Ready for Switchover: Yes
Managed by Clusterware:
North_Sales: NO
The static connect identifier allows for a connection to database "North_Sales".
例: ロジカル・スタンバイ・データベースの検証
次のようにしてロジカル・スタンバイ・データベースを検証します。
DGMGRL> VALIDATE DATABASE West_Sales;
Database Role: Logical standby database
Primary Database: North_Sales
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
Warning: Physical and snapshot standby databases will
be disabled if a role change is performed to this database
Flashback Database Status:
Database Status Retention Target
North_Sales On 1440
West_Sales Off 1440
Managed by Clusterware:
North_Sales: NO
West_Sales : NO
The static connect identifier allows for a connection to database "North_Sales".
Parameter Settings:
Parameter North_Sales Value West_Sales Value
DB_BLOCK_CHECKING FALSE FALSE
DB_BLOCK_CHECKSUM TYPICAL TYPICAL
DB_LOST_WRITE_PROTECT AUTO AUTO
例: フィジカル・スタンバイ・データベースの検証
次のようにしてフィジカル・スタンバイ・データベースを検証します。
sentences.
DGMGRL> VALIDATE DATABASE South_Sales;
Database Role: Physical standby database
Primary Database: North_Sales
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
Managed by Clusterware:
North_Sales: NO
South_Sales: NO
The static connect identifier allows for a connection to database "North_Sales".
Transport-Related Property Settings:
Property North_Sales Value South_Sales Value
LogXptMode ASYNC SYNC
Parameter Settings:
Parameter North_Sales Value South_Sales Value
DB_BLOCK_CHECKING FALSE FALSE
DB_BLOCK_CHECKSUM TYPICAL TYPICAL
DB_LOST_WRITE_PROTECT AUTO AUTO
データベースSouth_Salesは、そのLogXptModeプロパティが SYNCに設定されている唯一のデータベースです。これにより、スイッチオーバーは防止されませんが、スイッチオーバー後の構成は最大可用性モードで機能できず、ロール変更前に問題が修正されなかった場合はエラーが表示されます(タスク5を参照)。
SWITCHOVERコマンドの使用(タスク4): スイッチオーバー・コマンドの発行
SWITCHOVERコマンドを発行して、プライマリ・データベースとスタンバイ・データベースのロールを交換します。
次の例では、ブローカが、元のプライマリ・データベースの停止および再起動を、スイッチオーバーの一部として自動的に実行する方法を示します。(DGMGRLによってプライマリ・データベースとスタンバイ・データベースが自動的に再起動されるようにブローカ環境を設定する方法は、DGMGRLコマンドの使用上のノートを参照してください。)
DGMGRL> SWITCHOVER TO 'South_Sales'; 2023-01-11T20:52:23.010+00:00 Performing switchover NOW, please wait... 2023-01-11T20:52:23.233+00:00 Operation requires a connection to database "South_Sales" Connecting ... Connected to "South_Sales" Connected as SYSDBA. 2023-01-11T20:52:24.189+00:00 Continuing with the switchover... 2023-01-11T20:52:36.113+00:00 New primary database "South_Sales" is opening... 2023-01-11T20:52:36.113+00:00 Operation requires start up of instance "NorthSales" on database "North_Sales" Starting instance "NorthSales"... Connected to an idle instance. ORACLE instance started. Connected to "North_Sales" Database mounted. Database opened. 2023-01-11T20:53:41.190+00:00 Switchover succeeded, new primary is "South_Sales" 2023-01-11T20:53:41.196+00:00 Switchover processing complete, broker ready.
スイッチオーバーの完了後、SHOW CONFIGURATIONおよびSHOW DATABASEコマンドを使用して、スイッチオーバー操作が正常終了したかどうかを検証します。
SWITCHOVERコマンドの使用(タスク5): 構成の表示
SHOW CONFIGURATIONコマンドを使用して、スイッチオーバーが正常終了したことを確認します。
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxAvailability
Members:
South_Sales - Primary database
Warning: ORA-16627: No member available to support the protection mode.
North_Sales - Physical standby database
West_Sales - Logical standby database
Fast-Start Failover: Disabled
Configuration Status:
WARNING (status updated 46 seconds ago)
タスク3で説明したように、データベースNorth_Salesによって受信されたREDOがASYNC転送モードを使用するように構成されているため、ロール変更後に構成は最大可用性モードで機能できず、警告が報告されます。この問題を修正するには、SYNC転送モードを使用してREDOを受信するようにデータベースNorth_SalesのLogXptModeプロパティ値を設定するか、SYNC転送モードを使用してREDOを送信するようにデータベースSouth_SalesのRedoRoutesプロパティ値を構成します。データベースが、RedoRoutesプロパティがREDO転送モードに構成されているデータベースまたは遠隔同期インスタンスからREDOを受け取る場合、そのモードがLogXptModeで指定されている転送モードを上書きする点に注意してください。
使用例10: 手動フェイルオーバー操作の実行
フェイルオーバー操作は、緊急時(通常はプライマリ・データベースにアクセスできない場合または使用できない場合)の対応策として起動します。
フェイルオーバー前にターゲット・スタンバイ・データベースの選択を参照し、どのスタンバイ・データベースをフェイルオーバーのターゲットにするかを判断してください。次の使用例では、リモート・データベースSouth_Salesへのフェイルオーバーについて説明します。
ノート:
複数のファスト・スタート・フェイルオーバー・ターゲットが構成されている場合、手動フェイルオーバーのみが現在のファスト・スタート・フェイルオーバーのターゲットに対して可能です。
ファスト・スタート・フェイルオーバーのターゲットではないスタンバイ・データベースへの手動フェイルオーバーを実行する場合は、まずフェイルオーバー先のスタンバイ・データベースでFORCEオプションを使用してファスト・スタート・フェイルオーバーを無効にする必要があります。FORCEオプションの詳細は、「ファスト・スタート・フェイルオーバーの無効化」を参照してください。
使用例11: 障害が発生したプライマリ・データベースの回復
前のプライマリ・データベースがフラッシュバック・データベースを使用して構成された場合は、障害が発生したプライマリ・データベースを新しいプライマリ・データベースのスタンバイ・データベースとしてすぐに回復できます。
障害が発生したプライマリ・データベースは、元のスタンバイ・データベースと同じスタンバイ・タイプとして回復します。たとえば、フィジカル・スタンバイ・データベースへのフェイルオーバーであった場合、元のプライマリはフィジカル・スタンバイ・データベースとして回復されます。
障害が発生したプライマリ・データベースを回復するには、データベースを起動してマウントされた状態にします。次に、DGMGRLを実行し、新しいプライマリ・データベースに接続して元のプライマリ・データベースを回復します。
使用例12: フィジカル・スタンバイからスナップショット・スタンバイへの変換
スナップショット・スタンバイ・データベースに変換するフィジカル・スタンバイ・データベースがある場合は、DGMGRLのCONVERT DATABASEコマンドを使用します。
データベースがスナップショット・スタンバイ・データベースとして動作中の間は、REDOデータはデータベースで引き続き受信されますが、スナップショット・スタンバイ・データベースが元のフィジカル・スタンバイ・データベースに変換されるまでREDOデータは適用されません。
フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換するには、フィジカル・スタンバイ・データベースをファスト・リカバリ領域で構成する必要があります。これは、変換プロセス中に作成される保証付きリストア・ポイントにファスト・リカバリ領域が必要であるためです。
DGMGRL> CONVERT DATABASE 'North_Sales' TO SNAPSHOT STANDBY;
2022-12-20T01:24:38.396+00:00
Converting database "North_Sales" to a Snapshot Standby database, please wait...
2022-12-20T01:25:12.244+00:00
Database "North_Sales" converted successfully
2022-12-20T01:25:12.244+00:00
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxAvailability
Members:
South_Sales - Primary database
North_Sales - Snapshot standby database
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 33 seconds ago)
データベースを元のフィジカル・スタンバイ・データベースに戻すときは、次に示すように、DGMGRLのCONVERT DATABASEコマンドを再び使用します。スナップショット・スタンバイ・データベースとして動作中にデータベースに加えられた更新はすべて破棄されます。データベースが元のフィジカル・スタンバイ・データベースに変換されると、REDO Applyサービスによって、すべての累積REDOデータが適用されます。
DGMGRL> CONVERT DATABASE 'North_Sales' TO PHYSICAL STANDBY; 2022-12-20T01:28:35.434+00:00 Converting database "North_Sales" to a Physical Standby database, please wait... 2022-12-20T01:28:35.495+00:00 Operation requires shut down of instance "NorthSales" on database "North_Sales" Shutting down instance "NorthSales"... Connected to "North_Sales" Database closed. Database dismounted. ORACLE instance shut down. 2022-12-20T01:28:52.049+00:00 Operation requires start up of instance "NorthSales" on database "North_Sales" Starting instance "NorthSales"... Connected to an idle instance. ORACLE instance started. Connected to "North_Sales" Database mounted. 2022-12-20T01:29:06.816+00:00 Continuing to convert database "North_Sales" ... 2022-12-20T01:29:27.289+00:00 Database "North_Sales" converted successfully 2022-12-20T01:29:27.289+00:00
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxAvailability
Members:
South_Sales - Primary database
Warning: ORA-16629: Database reports a different protection level from the protection mode.
North_Sales - Physical standby database
Warning: ORA-16854: apply lag could not be determined
Fast-Start Failover: Disabled
Configuration Status:
WARNING (status updated 41 seconds ago)
ただし、REDO Applyで再びREDOの適用が開始されると、構成はSUCCESS状態に戻ります。
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxAvailability
Members:
South_Sales - Primary database
North_Sales - Physical standby database
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 59 seconds ago)
使用例13: Data Guard構成の監視
次のステップでは、SHOWコマンドとデータベースの監視可能なプロパティを使用し、障害状況を識別して解決するために必要なタスクを示します。
構成の監視(タスク1): 構成のステータス・チェック
ブローカ構成のステータスは、ブローカ構成のすべてのデータベースとインスタンスのステータスが集計されたものです。
ブローカ構成のステータスは、ブローカ構成内のすべての構成メンバーについての集約されたステータスです。
最初に構成ステータスをチェックすると、さらに処置が必要かどうかを判断できます。SUCCESSステータスは、ブローカ構成内のすべてが正しく機能していることを示しています。WARNINGまたはERRORステータスは、構成内のどれかが正しく機能していないか確認を必要としていることを示しています。
たとえば、スタンバイ・データベースに複数の警告があるとします:
DGMGRL> SHOW CONGIGURATION
Configuration - DRSolution
Protection Mode: MaxAvailability
Members:
South_Sales - Primary database
Warning: ORA-16627: No member available to support the protection mode.
North_Sales - Physical standby database (disabled)
ORA-16906: The member was shutdown.
Fast-Start Failover: Disabled
Configuration Status:
WARNING (status updated 31 seconds ago)
To resolve these warnings, restart standby database North_Sales and recheck the configuration status again.
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxAvailability
Members:
South_Sales - Primary database
North_Sales - Physical standby database
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 19 seconds ago)
構成の監視(タスク2): データベースのステータス・チェック
SHOW CONFIGURATIONからの出力のみでは問題の解決方法がわからない場合があります。プライマリ・データベースの警告を確認するには、SHOW DATABASEコマンドを使用してステータスを表示します。
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxAvailability
Members:
South_Sales - Primary database
Error: ORA-16810: Multiple errors or warnings detected for the member.
North_Sales - Physical standby database
Warning: ORA-16857: member disconnected from redo source for longer than specified threshold
Fast-Start Failover: Disabled
Configuration Status:
ERROR (status updated 25 seconds ago)
この例では、SHOW CONFIGURATIONによってプライマリ・データベースSouth_Salesに関する複数の問題を特定しています。複数のエラーまたは警告がある場合は、次のようにSHOW DATABASEコマンドを使用してそれらを特定します:
DGMGRL> SHOW DATABASE 'South_Sales';
Database - South_Sales
Role: PRIMARY
Intended State: TRANSPORT-ON
Redo Rate: (unknown)
Instance(s):
SouthSales
Error: ORA-16738: Redo transport service for member "North_Sales" is not running.
Database Warning(s):
ORA-16629: Database reports a different protection level from the protection mode.
Database Status:
ERROR
構成の監視(タスク3): 監視可能なプロパティLogXptStatusのチェック
ステップ2のSHOW DATABASEの出力には、エラーORA-16737の警告が示されています。
LogXptStatusブローカ監視可能プロパティは、ORA-16738 REDO転送エラーの具体的な原因を特定するのに役立ちます:
DGMGRL> SHOW DATABASE 'South_Sales' LogXptStatus;
LOG TRANSPORT STATUS
PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME STATUS ERROR
SouthSales North_Sales DEFERRED
スタンバイ・データベースNorth_SalesへのREDO転送は現在遅延しています。データベースSouth_Salesのアラート・ログを調べると、log_archive_dest_2へのREDO転送が遅延していることがわかります。
2022-12-20T02:42:38.960566+00:00 ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH; 2022-12-20T02:42:41.650221+00:00 LGWR (PID:3620211): LAD:2 no longer supports SYNCHRONIZATION [krsl.c:7650]
または、DGMGRL SHOW DATABASE ... PARAMETERコマンドを使用すると、データベースSouth_Salesに対して構成されているREDO転送先の状態をチェックして、遅延しているログ・アーカイブ先を特定できます。
DGMGRL> CONNECT sys@south_sales Password: password Connected to "South_Sales" Connected as SYSDBA. DGMGRL> SHOW DATABASE 'South_Sales' PARAMETER log_archive_dest_state_2; log_archive_dest_state_2 = 'DEFER'
DGMGRL> SQL 'alter system set log_archive_dest_state_2=ENABLE scope=both';
Succeeded.
DGMGRL> SHOW CONFIGURATION
Configuration - DRSolution
Protection Mode: MaxAvailability
Members:
South_Sales - Primary database
North_Sales - Physical standby database
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 26 seconds ago)
構成の監視(タスク4): 監視可能なプロパティInconsistentLogXptPropsのチェック
REDO転送のデータベース・プロパティReopenSecsについて一貫性のない値を識別するには、監視可能なプロパティInconsistentLogXptPropsを使用します。
これは、たとえばステップ2のSHOW DATABASEの出力に示された警告がORA-16715の場合に役立ちます。
DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps'; INCONSISTENT LOG TRANSPORT PROPERTIES INSTANCE_NAME STANDBY_NAME PROPERTY_NAME MEMORY_VALUE BROKER_VALUE south_sales1 South_Sales ReopenSecs 600 300
現行のデータベース・メモリー値(600)は、Oracle Data Guard Brokerのプロパティ値(300)と一致しません。ブローカのプロパティ値が正しいと判断した場合は、次の例に示すように、スタンバイ・データベースのプロパティを同じ値で再編集して一貫性のある値にできます。
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'ReopenSecs'=300; Property "ReopenSecs" updated
スタンバイ・データベースを再び有効化するか、プライマリ・データベースの状態をTRANSPORT-ONにリセットして、非一貫性を解決することもできます。
使用例14: ブローカ構成へのリカバリ・アプライアンスの追加
これらのステップでは、Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)をブローカ構成に追加する方法について説明します。
関連項目:
リカバリ・アプライアンスをフィジカル・スタンバイのREDO接続先として設定する方法の例は、「例4-9」を参照
シナリオ15: ブローカ構成ファイルのエクスポートおよびインポート
ブローカ構成は、traceディレクトリ内のテキスト・ファイルにエクスポートできます。エクスポートした構成メタデータをインポートすることで、構成を再作成できます。
このシナリオでは、構成メタデータをテキスト・ファイルにエクスポートすることでブローカ構成をtraceディレクトリに保存した後、前にエクスポートしたテキスト・ファイルをインポートすることで構成をリストアします。
シナリオ16: ファスト・スタート・フェイルオーバーの監視専用モードの使用
監視専用モードでは、構成に実際に変更を加えることなく、使用している構成でファスト・スタート・フェイルオーバーを使用した場合の影響をテストできます。DGMGRLコマンドまたはデータ・ディクショナリ・ビューを使用して、監視専用モードの設定を検証できます。
内容は次のとおりです。
ファスト・スタート・フェイルオーバーの監視専用モードの構成
ファスト・スタート・フェイルオーバーの監視専用モードを構成するには、ENABLE FAST_START FAILOVERコマンドを使用します。
監視専用モードでのログ・ファイルの内容の例
この項では、監視専用モードでファスト・スタート・フェイルオーバーを構成した場合にログ・ファイルに書き込まれるエントリを示します。
例1: ファスト・スタート・フェイルオーバーを開始する必要がある場合
オブザーバ・ログ
A fast-start failover would have been initiated...
Unable to failover since this observer is in observe-only modeブローカ・ログ
Fast-Start Failover cannot proceed because: "observe-only mode"例2: オブザーバまたはターゲット・スタンバイからの応答なしで、起動中にプライマリ・データベースがオープンした
ブローカのログ・ファイル(drc*.log)およびアラート・ログには、次の内容が含まれています。
This database is allowed to open in observe-only mode. An acknowledgement from observer or target standby would have been required in normal FSFO mode.例3: その他のデータベースへのスイッチオーバーまたは手動フェイルオーバー
ブローカのログ・ファイル(drc*.log)およびアラート・ログには、次の情報が含まれています。
FAILOVER to database 'database name' is allowed even though observe-only mode is enabled. It would have been rejected since database 'database name' is a bystander database.ファスト・スタート・フェイルオーバーの監視専用モードの無効化
ファスト・スタート・フェイルオーバーの監視専用モードを終了するには、DISABLE FAST_START FAILOVERコマンドを使用します。最初にファスト・スタート・フェイルオーバーを無効にしてから、OBSERVE ONLY句なしでファスト・スタート・フェイルオーバーを有効にする必要があります。
次のコマンドを使用して、ファスト・スタート・フェイルオーバーの監視専用モードを無効にします。
DGMGRL> DISABLE FAST_START FAILOVER;
DGMGRL> ENABLE FAST_START FAILOVER;ファスト・スタート・フェイルオーバーが監視専用モードではなく有効になります。