6 DGMGRLコマンドライン・インタフェースの使用例
次の各使用例では、Oracle Data Guard Broker構成の作成、管理および使用を開始するために必要なものを例をあげて説明します。
Oracle Data Guardコマンドライン・インタフェース(DGMGRL)の使用を開始するための前提条件を知ることで、自身の事例に備えることができます。さらに、使用例を読んで、DGMGRLを使用してブローカ構成を作成、管理および監視する方法を理解してください。
6.1 初期使用の前提条件
DGMGRL使用の前提条件の1つは、1つのプライマリ・データベースと任意の数のスタンバイ・データベースが存在していることです。
構成内のすべてのデータベースについて、DG_BROKER_START
初期化パラメータをTRUE
に設定する必要があります。ブローカではサーバー・パラメータ・ファイルを使用する必要があります。
必要な場合は、プライマリ・データベースとスタンバイ・データベースの初期化パラメータ・ファイル(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
です。 -
スタンバイ・データベースはフィジカル・スタンバイ・データベースです。
-
6.2 使用例1: 構成の作成
これらの例では、North_Sales
およびSouth_Sales
という名前のプライマリ・データベースおよびスタンバイ・データベースを含むDRSolution
という名前のブローカ構成を作成します。
構成を作成してフィジカル・スタンバイ・データベースを1つ追加するには、次のタスクを実行します。
6.2.1 構成の作成(タスク1): DGMGRLの起動
DGMGRLを起動するには、Oracle Data Guardがインストールされているシステム上で、コマンドライン・プロンプトからdgmgrl
と入力します。
$ dgmgrl
DGMGRLプロンプトが表示されます。
DGMGRL>
6.2.2 構成の作成(タスク2): プライマリ・データベースへの接続
任意のコマンド(HELP
、EXIT
またはQUIT
以外)を指定する前に、まずDGMGRL CONNECT
コマンドを使用してプライマリ・データベースに接続する必要があります。
データベースへの接続に使用するアカウント(この例ではSYS
)には、プライマリ・データベースとスタンバイ・データベースでのSYSDG
またはSYSDBA
権限が必要です。
注意:
CONNECT
コマンドのデフォルト設定であるため、AS SYSDBA
を指定する必要はありません。
次の例は、CONNECT
コマンドの2つのバリエーションを示しています。例6-1に、ローカル・システム上のデフォルト・データベースに接続する方法を示し、例6-2に、リモート・システムにあるデータベースに接続するためのOracle Net Services接続識別子(North_Sales.example.com)を示します。
この2つの例ではどちらもパスワードの入力を要求されます。
例6-1 ローカル・システム上のプライマリ・データベースへの接続
DGMGRL> CONNECT sysdg;
Password: password
Connected to "North_Sales"
Connected as SYSDG.
例6-2 リモート・システム上のプライマリ・データベースへの接続
DGMGRL> CONNECT sysdg@North_Sales.example.com;
Password: password
Connected to "North_Sales"
Connected as SYSDG.
6.2.3 構成の作成(タスク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
属性のどちらがあるか)は、そのままでかまいません。
6.2.4 構成の作成(タスク4): ブローカ構成の作成
ブローカ構成は最初にプライマリ・データベースで作成されます。
この例では、プライマリはNorth_Sales
と呼ばれます。後のコマンドで、スタンバイ・データベースSouth_Sales
を追加します。
注意:
プライマリ・データベース名とスタンバイ・データベース名では、それぞれのデータベースの一意名が一致する必要があります。これらの一意名は、次のコマンドを使用してDB_UNIQUE_NAME
初期化パラメータからフェッチします。
SQL> SHOW PARAMETER DB_UNIQUE_NAME;
CREATE CONFIGURATION
コマンドを使用し、DRSolution
構成を作成してプライマリ・データベースNorth_Sales
を定義します。
DGMGRL> CREATE CONFIGURATION 'DRSolution' AS > PRIMARY DATABASE IS 'North_Sales' > CONNECT IDENTIFIER IS North_Sales.example.com;
DGMGRLは次の情報を戻します。
Configuration "DRSolution" created with primary database "North_Sales"
名前North_Sales
は、このデータベースのDB_UNIQUE_NAME
初期化パラメータの値です。
6.2.5 構成の作成(タスク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.2.6 構成の作成(タスク6): 構成へのスタンバイ・データベースの追加
DRSolution
構成にスタンバイ・データベースを追加するには、 ADD DATABASE
コマンドを使用します。
次のコマンドは、スタンバイ・データベースとしてSouth_Sales
を定義しています。これは、プライマリ・データベースNorth_Sales
に関連付けられているスタンバイ・データベースです。
DGMGRL> ADD DATABASE 'South_Sales' AS > CONNECT IDENTIFIER IS South_Sales.example.com;
DGMGRLは次の情報を戻します。
Database "South_Sales" added
名前South_Sales
は、データベースのDB_UNIQUE_NAME
初期化パラメータの値です。
SHOW CONFIGURATION
コマンドを使用して、South_Sales
データベースがDRSolution
構成に追加されたことを確認します。
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 DGMGRL>
6.3 使用例2: データベース・プロパティの設定
DGMGRLを使用して構成を作成した後は、いつでもデータベース・プロパティを設定できます。
たとえば、次の文は、South_Sales
スタンバイ・データベースのデータベース・プロパティLogArchiveFormat
およびStandbyArchiveLocation
を設定します。
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogArchiveFormat'='log_%t_%s_%r_%d.arc'; Property "LogArchiveFormat" updated. 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: OFFLINE
Transport Lag: (unknown)
Apply Lag: (unknown)
Average Apply Rate: (unknown)
Active Apply Rate: (unknown)
Maximum Apply Rate: (unknown)
Real Time Query: OFF
Instance(s):
south_sales1
Properties:
DGConnectIdentifier = 'South_Sales.example.com'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
RedoRoutes = ''
DelayMins = '0'
Binding = 'OPTIONAL'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyLagThreshold = '0'
TransportLagThreshold = '0'
TransportDisconnectedThreshold = '0'
ApplyParallel = 'AUTO'
ApplyInstances = '0'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '5'
LogArchiveMinSucceedDest = '1'
DataGuardSyncLatency = '0'
DbFileNameConvert = 'dbs/cdb1_, dbs/cdb2_, dbs/t, dbs/bt, dbs/cdb4_, dbs/cdb2_, dbs/dt, dbs/bt'
LogFileNameConvert = 'dbs/cdb1_, dbs/cdb2_, dbs/t, dbs/bt, dbs/cdb4_, dbs/cdb2_, dbs/dt, dbs/bt'
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
PreferredObserverHosts = ''
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=south_sales1.example.com)(PORT=2879))
(CONNECT_DATA=(SERVICE_NAME=South_Sales_DGMGRL.example.com)(INSTANCE_NAME=south_sales1)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '255'
LogArchiveFormat = 'db2r_%d_%t_%s_%R.arc'
TopWaitEvents = '(monitor)'
Log file locations:
Unknown
Database Status:
DISABLED
データベースのブローカ管理が有効な場合は、データベース・プロパティ値を設定すると、対応するデータベースの基礎となるパラメータ値が変更され、変更されたパラメータの値がサーバー・パラメータ・ファイルに反映されます。したがって、データベースがOracle Enterprise Manager Cloud Control (Cloud Control)およびDGMGRL以外(SQL*Plusインタフェースなど)から停止および再起動された場合は、更新されたサーバー・パラメータ・ファイルの新規パラメータ値がデータベースの起動時に使用されます。ただし、SQL文を使用してREDO転送サービスの初期化パラメータを変更しないでください。それを行うと、データベースとブローカ間の一貫性が失われます。
注意:
通常、データベース・プロパティは、対応する初期化パラメータ、SQL文またはPL/SQLプロシージャ(通常は大文字)と視覚的に区別しやすいように、大/小文字混合表記(LogArchiveFormat
など)で表示されます。ただし、プロパティ管理コマンドでは大/小文字は区別されないため、大文字、小文字または混合表記でコマンドを発行できます。
プロパティは、データベースが有効な場合でも無効な場合でも変更できます。ただし、プロパティの変更時にデータベースが無効な場合、変更結果はデータベースが有効化されるまで有効になりません。
6.4 使用例3: 構成とデータベースの有効化
これまでDRSolution
構成は無効化されており、Data Guard Brokerの制御下にはありませんでした。
ブローカ構成に対するデータベースの構成および必要なデータベース・プロパティの設定を完了した後に、構成を有効化してData Guard Brokerで管理できるようにする必要があります。
次のいずれかを有効化できます。
-
すべてのデータベースを含む構成全体
-
スタンバイ・データベース
構成全体の有効化
構成を表示します
SHOW
コマンドを使用して、構成とそのデータベースが正常に有効化されていることを確認します。
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: SUCCESS
データベースの有効化
この手順は、前に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) Apply Rate: 1.54 MByte/s Real Time Query: OFF Instance(s): south_sales1 Database Status: SUCCESS
6.5 使用例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ログ・ファイルを使用するように構成されたスタンバイ・データベースが構成内に含まれていないかぎり、このコマンドは正常終了しません。
-
構成全体の保護モードを変更します。
EDIT
CONFIGURATION
コマンドを使用して、ブローカ構成の保護モードを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
関連項目:
6.6 使用例5: 遠隔同期インスタンスでの「最大可用性」モードの設定
プライマリ・データベースとスタンバイ・データベースが地理的に遠すぎて同期転送モードが実用的でない場合、遠隔同期インスタンスを最大可用性保護モードで使用することができます。
このトピックの例は、遠隔同期インスタンスを構成に追加し、構成のすべてのメンバーに対してRedoRoutes
プロパティを設定する方法を示しています。遠隔同期インスタンスに対してRedoRoutes
プロパティを設定すると、North_Sales
データベースとSouth_Sales
データベースのいずれかプライマリである方に基づいてREDOデータを送信できます。
6.7 使用例6: ファスト・スタート・フェイルオーバーの有効化とオブザーバの起動
ブローカ構成のデータベースに接続されているかぎり、オブザーバ・サイトを含め、任意のサイトからファスト・スタート・フェイルオーバーを有効化できます。
ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、フェイルオーバーの条件が満たされた場合に、構成を監視しているオブザーバがファスト・スタート・フェイルオーバーを起動できるようになります。この項では、ファスト・スタート・フェイルオーバーを有効化し、構成の保護モードが最大可用性モードに設定されるオブザーバを起動する手順を説明します。
6.8 使用例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
のファスト・スタート・フェイルオーバー・ターゲットとして指定されていない点に注意してください。
6.9 使用例8: 定期的な管理タスクの実施
1つ以上のデータベースの定期的なメンテナンスを実行するために、ブローカ構成に含まれるデータベースの状態やプロパティの変更が必要になる場合があります。
また、構成に含まれるデータベースのブローカ管理を一時的に無効化する必要が生じる場合もあります。
6.9.1 プロパティと状態の変更
構成の監視中に、データベースやそのプロパティの状態を動的に変更する操作が必要になる場合があります。
次の各トピックで、構成内のデータベースの状態またはプロパティを変更する方法について説明します。
6.9.1.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
コマンドでブローカ構成を有効化するまで、データベースで新規プロパティ値が使用されません。
6.9.1.2 デフォルト値へのプロパティのリセット
データベースや構成が有効/無効のいずれの場合も、構成や設定可能なプロパティを、いつでもそのデフォルト値にリセットできます。
次の例は、EDIT
DATABASE
コマンドを使用してLogXptMode
データベースの設定可能なプロパティをNorth_Sales
データベースのデフォルト値にリセットする方法を示しています。
EDIT DATABASE 'North_Sales' RESET PROPERTY LogXptMode;
次の例は、EDIT
CONFIGURATION
コマンドを使用してTraceLevel
構成プロパティをデフォルト値にリセットする方法を示しています。
EDIT CONFIGURATION RESET PROPERTY TraceLevel;
6.9.1.3 スタンバイ・データベースの状態変更
フィジカル・スタンバイのREDO Applyを一時的に停止できます。
スタンバイ・データベースの状態をAPPLY-OFF
に変更するには、次の例のようにEDIT DATABASE
コマンドを入力します。
DGMGRL> EDIT DATABASE 'South_Sales' SET STATE='APPLY-OFF'; Succeeded.
フィジカル・スタンバイ・データベースをAPPLY-OFF
状態にしても、REDOデータは引き続き受信されます。
6.9.2 構成とデータベースの無効化
ブローカ構成またはそのデータベースのいずれかを無効化すると、それらのブローカによる管理が無効化されるため、DGMGRLを使用してそれらを管理および監視できなくなります。
ただし、ブローカによるブローカ構成の管理を無効にしても、基礎となるOracle Data Guard構成またはデータベースの実際の操作には影響しません。たとえば、Oracle Data Guard構成内のREDO転送サービスとログ適用サービスは、管理できなくなりますが、そのまま機能し続けます。
6.9.2.1 構成の無効化
プライマリ・データベースを含むブローカ構成全体の管理を無効化するには、DISABLE CONFIGURATION
コマンドを使用する必要があります。
次に例を示します。
DGMGRL> DISABLE CONFIGURATION;
プライマリ・データベースのブローカ管理を無効化するには、DISABLE CONFIGURATION
コマンドを使用する必要があります。DISABLE DATABASE
コマンドで無効化されるのは、スタンバイ・データベースの管理のみです。同様に、DISABLE
FAR_SYNC
コマンドは、遠隔同期インスタンスの管理のみを無効にします。
注意:
スタンバイ・データベースまたは遠隔同期インスタンスへの接続時に構成の管理を無効化する場合、構成を再び有効化するには、プライマリ・データベース(制御ファイルのロールがプライマリであるデータベース)に接続する必要があります。
構成メンバーのブローカの管理を無効にしても、そのメンバーはブローカ構成ファイルから削除されません。該当するENABLE
CONFIGURATION
またはENABLE DATABASE
コマンドを入力すると、DGMGRL (またはCloud Control)によるメンバー管理機能を再び有効化できます。
6.9.2.2 スタンバイ・データベースの無効化
ブローカによるスタンバイ・データベースの管理と監視が一時的に不要になった場合は、DISABLE DATABASE
コマンドを使用します。
構成の他の部分が有効な場合は、スタンバイ・データベースが有効化されないようにブローカ管理を明示的に無効化できます。次の例は、スタンバイ・データベースSouth_Sales
を無効化する方法を示しています。
DGMGRL> DISABLE DATABASE 'South_Sales'; Disabled.
注意:
構成内のスタンバイ・データベースを無効にするとき、ファスト・スタート・フェイルオーバーが有効化されている場合、ターゲット・スタンバイ・データベースは無効化できません。
注意:
スタンバイ・データベースへの接続中にそのスタンバイ・データベースの管理を無効化した場合は、スタンバイ・データベースのブローカ管理を再び有効化するために、プライマリ・データベースまたは別の有効化されたスタンバイ・データベースに接続する必要があります。
警告:
ブローカ構成内のスタンバイ・データベースに関してブローカによる管理を無効化すると、プライマリ・データベースが消失した場合にも、そのスタンバイ・データベースはブローカでフェイルオーバー・ターゲットとして使用できなくなります。
最大保護モードまたは最大可用性モードのいずれかで動作している場合、ブローカでは、保護モードをサポートする最後の1つのスタンバイ・データベースを無効化できません。
6.9.2.3 遠隔同期インスタンスの無効化
ブローカによる遠隔同期インスタンスの管理と監視が一時的に不要になった場合は、DISABLE
FAR_SYNC
コマンドを使用します。
構成の他の部分が有効な場合は、遠隔同期インスタンスが有効化されないようにブローカ管理を明示的に無効化できます。次の例は、遠隔同期インスタンスを無効化する方法を示しています。
DGMGRL> DISABLE FAR_SYNC 'FS'; Disabled.
注意:
遠隔同期インスタンスを無効にすると、次の制約が適用されます。
-
他の構成メンバーの
RedoRoutes
プロパティで指定されている遠隔同期インスタンスは無効化できません。 -
遠隔同期インスタンスに接続している間にその遠隔同期インスタンスの管理を無効にした場合、遠隔同期インスタンスのブローカ管理を再び有効化するには、プライマリ・データベースまたは別の有効なスタンバイ・データベースに接続する必要があります。
注意:
ブローカ構成で遠隔同期インスタンスのブローカ管理を無効にした場合、他の構成メンバーのRedoRoutes
プロパティで、その遠隔同期インスタンスを指定することはできません。
6.9.3 構成、スタンバイ・データベースまたは遠隔同期インスタンスの削除
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
プロパティで指定されている場合、それらを削除することはできません。
6.9.3.1 構成からのスタンバイ・データベースの削除
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
DGMGRLのREMOVE DATABASE
コマンドを発行して、South_Sales
データベース情報をData Guard構成ファイルから削除します。
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
最大保護モードまたは最大可用性モードのいずれかで動作している場合、ブローカでは、保護モードをサポートする最後の1つのスタンバイ・データベースを削除できません。
6.9.3.2 構成からの遠隔同期インスタンスの削除
Oracle Data Guard構成ファイルから遠隔同期インスタンス情報を削除するには、REMOVE FAR_SYNC
コマンドを使用します。
たとえば、次のコマンドを使用して、FS
遠隔同期インスタンス情報を削除します。
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
6.9.3.3 ブローカ構成の削除
DGMGRL REMOVE CONFIGURATION
コマンドを使用すると、構成全体がブローカによって管理および監視されなくなります。
次に例を示します。
DGMGRL> REMOVE CONFIGURATION;
注意:
ファスト・スタート・フェイルオーバーが有効化されている場合、構成を削除できません。
DGMGRLは次のメッセージを戻します。このメッセージは、コマンドによりData Guard構成ファイルからすべての構成情報が正常に削除されたことを示します。
Removed configuration DGMGRL> SHOW CONFIGURATION; Error: ORA-16532: Data Guard broker configuration does not exist Configuration details cannot be determined by DGMGRL
6.10 使用例9: スイッチオーバー操作の実行
プライマリ・データベースとスタンバイ・データベースのロールは、SWITCHOVER
コマンドを使用して切り替えることができます。
SWITCHOVER
コマンドを発行する前に、次のことを確認する必要があります。
-
プライマリ・データベースとスタンバイ・データベースの状態がそれぞれ
TRANSPORT-ON
およびAPPLY-ON
であること。 -
関係するすべてのデータベースが健全な状態で、エラーや警告がないこと。
-
スタンバイ・データベースのプロパティがプライマリ・データベース上で設定されていること。これにより、プライマリ・データベースはスタンバイ・データベースへ遷移するときに正常に機能できます(次の例の太字表記を参照してください)。
-
プライマリ・データベースでスタンバイREDOログ・ファイルが構成されています。
-
構成が最大可用性モードの場合、現在のプライマリは、新しいプライマリから直接REDOを受け取る場合、
SYNC
またはFASTSYNC
モードでREDOを受け取るように構成されます。遠隔同期インスタンスを介してREDOを受け取る場合、遠隔同期インスタンスはSYNC
またはFASTSYNC
モードでREDOを受け取るように構成され、現在のプライマリはASYNC
モードでREDOを受け取るように構成されます。構成が最大保護モードの場合、現在のプライマリは、SYNC
モードでREDOを受け取るように構成されます。 -
ファスト・スタート・フェイルオーバーが有効化されている場合は、ターゲット・スタンバイ・データベースとして指定されたスタンバイ・データベースへのスイッチオーバーのみ実行できる。
SWITCHOVER
コマンドを使用してスイッチオーバーを実行するために必要なタスクは次のとおりです。
6.10.1 SWITCHOVERコマンドの使用(タスク1): プライマリ・データベースのチェック
SHOW DATABASE VERBOSE
コマンドを使用して、プライマリ・データベースの状態、健全性およびプロパティをチェックします。
次に例を示します。
SHOW DATABASE VERBOSE 'North_Sales';
Database - North_Sales
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
c0
Properties:
DGConnectIdentifier = 'North_Sales.example.com'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
RedoRoutes = ''
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyLagThreshold = '0'
TransportLagThreshold = '0'
TransportDisconnectedThreshold = '0'
ApplyParallel = 'AUTO'
ApplyInstances = '0'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '5'
LogArchiveMinSucceedDest = '1'
DataGuardSyncLatency = '0'
DbFileNameConvert = 'dbs/cdb2_, dbs/cdb1_, dbs/bt, dbs/t, dbs/cdb4_, dbs/cdb1_, dbs/dt, dbs/t'
LogFileNameConvert = 'dbs/cdb2_, dbs/cdb1_, dbs/bt, dbs/t, dbs/cdb4_, dbs/cdb1_, dbs/dt, dbs/t'
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
PreferredObserverHosts = ''
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=North_Sales.example.com)(PORT=2840))
(CONNECT_DATA=(SERVICE_NAME=North_Sales_DGMGRL.example.com)
(INSTANCE_NAME=north_sales1)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = 255
LogArchiveFormat = 'db1r_%d_%t_%s_%R.arc'
TopWaitEvents = '(monitor)'
Log file locations:
Alert log : /dev/oracle/log/diag/rdbms/North_Sales/north1/trace/alert_north1.log
Data Guard Broker log : /dev/oracle/log/diag/rdbms/North_Sales/north1/trace/drcnorth1.log
Database Status:
SUCCESS
特に、プライマリ・データベースの太字のプロパティおよび現在のステータスをチェックする必要があります。
6.10.2 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: SUCCESS
6.10.3 SWITCHOVERコマンドの使用(タスク3): データベースのロール変更可能確認
ロール変更を実行する前に、VALIDATE
DATABASE
コマンドを使用して、データベースがロール変更に即時対応可能かどうかを確認する、一連の徹底チェックを実行することができます。
この手順に示す例では、DRSolution
構成の3つのデータベース(プライマリ、ロジカル・スタンバイおよびフィジカル・スタンバイの各データベース)すべてにVALIDATE
DATABASE
コマンドを使用しています。構成は次のようになります。
DGMGRL> SHOW CONFIGURATION; Configuration - DRSolution Protection Mode: MaxAvailability Members: North_Sales - Primary database West_Sales - Logical standby database South_Sales - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
例: プライマリ・データベースの検証
DGMGRL> VALIDATE DATABASE 'North_Sales'; Database Role: Primary database Ready for Switchover: Yes
例: ロジカル・スタンバイ・データベースの検証
次のようにしてロジカル・スタンバイ・データベースを検証します。
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
例: フィジカル・スタンバイ・データベースの検証
次のようにしてフィジカル・スタンバイ・データベースを検証します。
DGMGRL> VALIDATE DATABASE 'South_Sales'; Database Role: Physical standby database Protection Mode: MaxAvailability Error: Switchover to this standby is not possible since there are no other standbys that can support the protection mode Primary Database: North_Sales Ready for Switchover: No Ready for Failover: Yes (Primary Running) Transport-Related Property Settings: Property North_Sales Value South_Sales Value LogXptMode ASYNC SYNC
構成保護は最大可用性モードに設定されており、データベースSouth_Sales
のみ、LogXptMode
プロパティがSYNC
に設定されているため、スイッチオーバーできないことを示すエラーが表示されます。データベースが、RedoRoutes
プロパティが転送モードに構成されているデータベースまたは遠隔同期インスタンスからREDOを受け取る場合、そのモードがLogXptMode
で指定されている転送モードを上書きする点に注意してください。
6.10.4 SWITCHOVERコマンドの使用(タスク4): スイッチオーバー・コマンドの発行
SWITCHOVER
コマンドを発行して、プライマリ・データベースとスタンバイ・データベースのロールを交換します。
次の例では、ブローカが、元のプライマリ・データベースの停止および再起動を、スイッチオーバーの一部として自動的に実行する方法を示します。(DGMGRLによってプライマリ・データベースとスタンバイ・データベースが自動的に再起動されるようにブローカ環境を設定する方法は、DGMGRLコマンドの使用上の注意を参照してください。)
DGMGRL> SWITCHOVER TO 'South_Sales'; Performing switchover NOW, please wait... Operation requires a connection to instance "south_sales1" on database "South_Sales" Connecting to instance "south_sales1"... Connected as SYSDBA. New primary database "South_Sales" is opening... Operation requires startup of instance "north_sales1" on database "North_Sales" Starting instance "north_sales1"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "South_Sales"
スイッチオーバーの完了後、SHOW CONFIGURATION
およびSHOW DATABASE
コマンドを使用して、スイッチオーバー操作が正常終了したかどうかを検証します。
6.10.5 SWITCHOVERコマンドの使用(タスク5): 構成の表示
SHOW CONFIGURATION
コマンドを使用して、スイッチオーバーが正常終了したことを確認します。
DGMGRL> SHOW CONFIGURATION; Configuration - DRSolution Protection Mode: MaxAvailability Members: South_Sales - Primary database West_Sales - Logical standby database North_Sales - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
6.11 使用例10: 手動フェイルオーバー操作の実行
フェイルオーバー操作は、緊急時(通常はプライマリ・データベースにアクセスできない場合または使用できない場合)の対応策として起動します。
フェイルオーバー前にターゲット・スタンバイ・データベースの選択を参照し、どのスタンバイ・データベースをフェイルオーバーのターゲットにするかを判断してください。次の使用例では、リモート・データベースSouth_Sales
へのフェイルオーバーについて説明します。
注意:
ファスト・スタート・フェイルオーバーが有効化されている場合、ファスト・スタート・フェイルオーバーのターゲットとして指定されているスタンバイ・データベースにかぎり、またオブザーバが実行中で現在スタンバイ・データベースと接続されている場合のみ、手動フェイルオーバーを実行できます。
ファスト・スタート・フェイルオーバーのターゲットではないスタンバイ・データベースへの手動フェイルオーバーを実行する場合は、まずフェイルオーバー先のスタンバイ・データベースでFORCE
オプションを使用してファスト・スタート・フェイルオーバーを無効にする必要があります。FORCE
オプションの詳細は、「ファスト・スタート・フェイルオーバーの無効化」を参照してください。
6.12 使用例11: 障害が発生したプライマリ・データベースの回復
前のプライマリ・データベースがフラッシュバック・データベースを使用して構成された場合は、障害が発生したプライマリ・データベースを新しいプライマリ・データベースのスタンバイ・データベースとしてすぐに回復できます。
障害が発生したプライマリ・データベースは、元のスタンバイ・データベースと同じスタンバイ・タイプとして回復します。たとえば、フィジカル・スタンバイ・データベースへのフェイルオーバーであった場合、元のプライマリはフィジカル・スタンバイ・データベースとして回復されます。
障害が発生したプライマリ・データベースを回復するには、データベースを起動してマウントされた状態にします。次に、DGMGRLを実行し、新しいプライマリ・データベースに接続して元のプライマリ・データベースを回復します。
6.13 使用例12: フィジカル・スタンバイからスナップショット・スタンバイへの変換
スナップショット・スタンバイ・データベースに変換するフィジカル・スタンバイ・データベースがある場合は、DGMGRLのCONVERT DATABASE
コマンドを使用します。
データベースがスナップショット・スタンバイ・データベースとして動作中の間は、REDOデータはデータベースで引き続き受信されますが、スナップショット・スタンバイ・データベースが元のフィジカル・スタンバイ・データベースに変換されるまでREDOデータは適用されません。
フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換するには、フィジカル・スタンバイ・データベースをファスト・リカバリ領域で構成する必要があります。これは、変換プロセス中に作成される保証付きリストア・ポイントにファスト・リカバリ領域が必要であるためです。
DGMGRL> convert database 'South_Sales' to snapshot standby; Converting database "South_Sales" to a Snapshot Standby database, please wait... Database "South_Sales" converted successfully DGMGRL> SHOW CONFIGURATION; Configuration - DRSolution Protection Mode: MaxPerformance Members: North_Sales - Primary database South_Sales - Snapshot standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
データベースを元のフィジカル・スタンバイ・データベースに戻すときは、次に示すように、DGMGRLのCONVERT DATABASE
コマンドを再び使用します。スナップショット・スタンバイ・データベースとして動作中にデータベースに加えられた更新はすべて破棄されます。データベースが元のフィジカル・スタンバイ・データベースに変換されると、REDO Applyサービスによって、すべての累積REDOデータが適用されます。
DGMGRL> CONVERT DATABASE 'South_Sales' to PHYSICAL STANDBY; Converting database "South_Sales" to a Physical Standby database, please wait... Operation requires shutdown of instance "south_sales1" on database "South_Sales" Shutting down instance "south_sales1"... Database closed. Database dismounted. ORACLE instance shut down. Operation requires startup of instance "south_sales1" on database "South_Sales" Starting instance "south_sales1"... ORACLE instance started. Database mounted. Continuing to convert database "South_Sales" ... Database "South_Sales" converted successfully
6.14 使用例13: Data Guard構成の監視
次の手順では、SHOW
コマンドとデータベースの監視可能なプロパティを使用し、障害状況を識別して解決するために必要なタスクを示します。
6.14.1 構成の監視(タスク1): 構成のステータス・チェック
ブローカ構成のステータスは、ブローカ構成のすべてのデータベースとインスタンスのステータスが集計されたものです。
最初に構成ステータスをチェックすると、さらに処置が必要かどうかを判断できます。構成ステータスがSUCCESSの場合は、ブローカ構成全体が正常に動作しています。一方、WARNINGまたはERRORステータスが表示される場合は、構成の一部に問題があることを意味します。
たとえば、次の例は、プライマリ・データベースに複数の警告があることを示しています。
DGMGRL> SHOW CONFIGURATION; Configuration - DRSolution Protection Mode: MaxPerformance Members: North_Sales - Primary database Warning: ORA-16809: multiple warnings detected for the database South_Sales - Physical standby database Fast-Start Failover: DISABLED Configuration Status: WARNING
6.14.2 構成の監視(タスク2): データベースのステータス・チェック
プライマリ・データベースの警告を確認するには、SHOW DATABASE
コマンドを使用してステータスを表示します。
次に例を示します。
DGMGRL> SHOW DATABASE 'North_Sales'; Database - North_Sales Role: PRIMARY Intended State: TRANSPORT-ON Instance(s): north_sales1 Warning: ORA-16737: the redo transport service for standby "South_Sales" has an error Warning: ORA-16714: the value of property LogArchiveTrace is inconsistent with the database setting Warning: ORA-16715: redo transport-related property ReopenSecs of standby database "South_Sales" is inconsistent Database Status: WARNING
6.14.3 構成の監視(タスク3): 監視可能なプロパティLogXptStatusのチェック
手順2のSHOW DATABASE
の出力には、エラーORA-16737の警告が示されています。
正確な転送エラーを確認するには、監視可能なプロパティLogXptStatus
を使用します。
DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus'; LOG TRANSPORT STATUS PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME STATUS north_sales1 South_Sales ORA-12541: TNS:no listener
出力は、フィジカル・スタンバイ・データベースのリスナーが実行されていないことを示しています。このエラーを修正するには、フィジカル・スタンバイ・データベースSouth_Sales
のリスナーを起動します。
6.14.4 構成の監視(タスク4): 監視可能なプロパティInconsistentPropertiesのチェック
手順2のSHOW DATABASE
の出力には、エラーORA-16714の警告が示されています。正確なエラーを確認するには、監視可能なプロパティInconsistentProperties
を使用します。
DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentProperties'; INCONSISTENT PROPERTIES INSTANCE_NAME PROPERTY_NAME MEMORY_VALUE SPFILE_VALUE BROKER_VALUE north_sales1 LogArchiveTrace 511 255 255
現在のデータベース・メモリー値(511)が、サーバー・パラメータ・ファイル(SPFILE)の値(255)ともOracle Data Guard Brokerのプロパティ値(255)とも異なっています。データベース・メモリー値が正しいと判断した場合は、次のコマンドを使用してOracle Data Guard Brokerのプロパティ値を更新できます。
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogArchiveTrace'=511; Property "LogArchiveTrace" updated
このコマンドを発行すると、LogArchiveTrace
の値の一貫性が保たれるようにサーバー・パラメータ・ファイル(SPFILE)の値が更新されます。
6.14.5 構成の監視(タスク5): 監視可能なプロパティ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
にリセットして、非一貫性を解決することもできます。
6.15 使用例14: ブローカ構成へのリカバリ・アプライアンスの追加
これらの手順では、Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)をブローカ構成に追加する方法について説明します。
関連項目:
リカバリ・アプライアンスをフィジカル・スタンバイのREDO接続先として設定する方法の例は、「例4-6」を参照