| Oracle® Data Guard Broker 12cリリース1 (12.1) B71305-08 |
|
 前 |
 次 |
次のトピックでは、ブローカ構成の様々なメンバーを管理する方法を説明します。ブローカ構成そのものを管理する方法に関する情報は、「ブローカ構成の管理」を参照してください。
ブローカは構成ファイルの情報を使用して、構成の各メンバーの状態を管理および監視します。
ブローカでは、ブローカ構成に含まれる様々なタイプのメンバーが区別されます。各タイプのメンバーは、そのタイプのメンバーに適切な、状態とプロパティの組合せを持っています。
構成が有効化されている場合、構成内のメンバーの状態は、REDOデータの転送中またはREDOデータの適用中など、Oracle Data Guardの動作を指示するいずれかの状態になります。表4-1に、様々な状態を示します。
スナップショット・スタンバイ・データベースは、状態を持たず、REDOデータを受信するのみであるため、この表にはリストされていません。
状態がないため、遠隔同期インスタンスもこの表に含まれません。それはREDOを受け取って、スタンバイ・データベースに転送するだけです。
表4-1 データベースの状態と説明
| データベース・ロール | 状態名 | 説明 |
|---|---|---|
プライマリ |
|
REDO転送サービスは、プライマリ・データベースが読取り/書込みアクセス用にオープンされるとREDOデータをスタンバイ・データベースまたは遠隔同期インスタンスに転送するように設定されます。 これがOracle RACデータベースの場合は、読取り/書込みモードでオープンされているすべてのインスタンスでREDO転送サービスが実行されます。 これは、プライマリ・データベースが初めて有効化されるときのデフォルト状態です。 |
プライマリ |
|
プライマリ・データベースのREDO転送サービスが停止します。 これがOracle RACデータベースの場合は、どのインスタンスでもREDO転送サービスが実行されません。 |
フィジカル・スタンバイ |
|
フィジカル・スタンバイ・データベースのREDO Applyが開始します。 スタンバイ・データベースがOracle RACデータベースの場合、ブローカは適用インスタンスと呼ばれる単一のスタンバイ・インスタンスでのみREDO Applyを起動します。このインスタンスに障害が発生すると、ブローカは、マウントされているか読取り専用でオープンされている他のインスタンスを自動的に選択します。この新規インスタンスが適用インスタンスとなります。 これは、フィジカル・スタンバイ・データベースが初めて有効化されるときのデフォルト状態です。 Oracle Active Data Guardオプションのライセンスを購入済の場合は、REDO Applyがアクティブなときにフィジカル・スタンバイ・データベースをオープン状態にしておくことができます。この機能はリアルタイム問合せと呼ばれます。詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
フィジカル・スタンバイ |
|
REDO Applyが停止します。 これがOracle RACデータベースの場合は、データベースの状態を |
ロジカル・スタンバイ |
|
ロジカル・スタンバイ・データベースがオープンされている場合、ロジカル・スタンバイのデータベース・ガードがオンであれば、そのデータベースでSQL Applyが起動します。 これがOracle RACデータベースの場合は、単一のインスタンス(適用インスタンス)でSQL Applyが実行されます。このインスタンスに障害が発生すると、ブローカは自動的に他のオープン・インスタンスを選択します。この新規インスタンスが適用インスタンスとなります。 これは、ロジカル・スタンバイ・データベースが初めて有効化されるときのデフォルト状態です。 |
ロジカル・スタンバイ |
|
SQL Applyは実行されません。ロジカル・スタンバイのデータベース・ガードはオンです。 これがOracle RACデータベースの場合は、状態を |
DGMGRLのEDIT DATABASEコマンドを使用して、データベースの状態を明示的に変更できます。たとえば、次の例に示すEDIT DATABASEコマンドは、North_Salesデータベースの状態をTRANSPORT-OFFに変更します。
DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='TRANSPORT-OFF'; Succeeded.
参照:
EDIT DATABASEコマンドの詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」を参照してください。
次の各項では、プライマリ・データベースおよびスタンバイ・データベースにおいて考えられる状態遷移について詳細に説明します。
プライマリ・データベースの状態遷移
プライマリ・データベースをTRANSPORT-ON状態に遷移する際に、ブローカは構成メンバーのREDO転送関連プロパティと、プライマリ・データベースのRedoRoutesプロパティを使用して、REDO転送サービスを設定します。(REDO転送関連のプロパティの一覧は「REDO転送サービスの管理」を、RedoRoutesプロパティの説明は「高度なREDO転送設定」を参照してください。)REDO転送サービスを設定するために、プライマリ・データベースのLOG_ARCHIVE_DEST_nおよびLOG_ARCHIVE_DEST_STATE_n初期化パラメータと全データベース(プライマリまたはスタンバイ)および遠隔同期インスタンスのLOG_ARCHIVE_CONFIG初期化パラメータが設定されます。必要な場合は、データベースのデータ保護モードもブローカ構成ファイルに記録されている保護モードに合せて設定されます。最後に、データベースがオープンされている場合、各スレッドのログが切り替えられ、REDO転送サービスが開始されます。
プライマリ・データベースをTRANSPORT-OFF状態に遷移する際、ブローカはLOG_ARCHIVE_DEST_STATE_n初期化パラメータをリセットし、すべての管理対象スタンバイへのREDO転送サービスをオフにします。ブローカ管理のすべてのスタンバイへのREDOデータの転送が停止されます。ログ・ファイルは、引き続きプライマリ・データベース側でアーカイブされます。
プライマリ・データベースがOracle RACデータベースの場合、ブローカはすべてのプライマリ・インスタンス上で、まったく同じ設定を使用してREDO転送サービスを構成します。
参照:
REDO転送サービスの管理の詳細は、「REDO転送サービスの管理」を参照してください
フィジカル・スタンバイ・データベースの状態遷移
フィジカル・スタンバイ・データベースをAPPLY-ON状態に遷移する際に、ブローカはREDO Apply関連プロパティで指定されたオプションを使用してREDO Applyを起動します(プロパティ・リストについては「ログ適用サービスの管理」を参照してください)。スタンバイがOracle RACデータベースの場合、ブローカは適用インスタンスと呼ばれる単一のスタンバイ・インスタンスでREDO Applyを起動します。
Oracle Active Data Guardオプションのライセンスを購入済の場合は、REDO Applyがアクティブなときにフィジカル・スタンバイ・データベースをオープン状態にしておくことができます。この機能はリアルタイム問合せと呼ばれます。詳細は、『Oracle Data Guard概要および管理』を参照してください。
注意:
他のインスタンスがオープンされている場合、REDO Applyを開始する前に適用インスタンスをオープンする必要があります。
APPLY-OFF状態に遷移すると、ブローカはREDO Applyを停止します。
注意:
フィジカル・スタンバイ上のOracle RAC One Nodeでオンライン・データベース再配置を実行する場合、新しいインスタンスは現在実行中のインスタンスと同じモードで開始されます。そのため、データベースが元のインスタンスにマウントされている場合、そのデータベースは新しいインスタンスにマウントされることになります。同様に、データベースが元のインスタンスでオープンしている場合、そのデータベースは新しいインスタンスでオープンされることになります。これにより、新しいインスタンスは、データベースのOracle Clusterwareで記録された開始オプションと一致しないモードで開始される可能性があります。
ロジカル・スタンバイ・データベースの状態遷移
ロジカル・スタンバイ・データベースがAPPLY-ON状態に遷移すると、ブローカは、データベースがオープンされるまで待機し、データベース・ガードを有効化してロジカル・スタンバイ・データベース内の表への変更を防ぎ、ログ適用関連プロパティで指定されたオプションを使用してSQL Applyを起動します。ロジカル・スタンバイ・データベースがOracle RACデータベースの場合、ブローカは単一のスタンバイ・インスタンス(適用インスタンス)でSQL Applyを起動します。
APPLY-OFF状態に遷移すると、ブローカはSQL Applyを停止します。
参照:
SQL Applyの管理の詳細は、「ログ適用サービスの管理」を参照してください
データベース・ガードの詳細は、『Oracle Data Guard概要および管理』を参照してください。
データベース・プロパティには、監視可能なタイプと構成可能なタイプがあります。どちらのタイプのプロパティも、データベース単位の有効範囲を持つプロパティとインスタンス固有の有効範囲を持つプロパティとしてさらに分類できます。
監視可能なプロパティの値は、関連データベースが有効である場合にのみ表示できます。
監視可能なプロパティを使用するとデータベース関連のランタイム情報を表示できますが、このタイプのプロパティの値は変更できません。
構成可能なプロパティは、ブローカの操作や構成に影響を与えます。これらのプロパティの値は、DGMGRLまたはCloud Controlを使用して変更できます。プロパティは、構成とそのメンバーが有効か無効かに関係なく編集できます。ただし、構成メンバーが無効化されている場合は、該当する構成またはメンバーを有効にするまで、新しいプロパティ値は有効になりません。
参照:
すべてのデータベース・プロパティの詳細リストは、「Oracle Data Guard Brokerのプロパティ」を参照してください
これらのプロパティを表示するには、DGMGRLのSHOWコマンドを使用するか、Cloud Controlの「プロパティの編集」ページを使用できます。例4-1では、SHOW DATABASE VERBOSEコマンドを使用して、North_Salesデータベースに関する情報を表示しています。
参照:
DGMGRLコマンドライン・インタフェースの詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」を参照
例4-1 SHOW DATABASE VERBOSEコマンドの使用によるプロパティの表示
DGMGRL> SHOW DATABASE VERBOSE 'North_Sales';
Database - North_Sales
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
north_sales1
Properties:
DGConnectIdentifier = 'North_Sales.example.com'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
RedoRoutes = ''
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '30'
NetTimeout = '300'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyLagThreshold = '0'
TransportLagThreshold = '0'
TransportDisconnectedThreshold = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '5'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = 'dbs/bt, dbs/t, dbs/ct, dbs/t'
LogFileNameConvert = 'dbs/bt, dbs/t, dbs/ct, dbs/t'
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
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)'
Database Status:
SUCCESS
監視可能なプロパティを使用すると構成メンバー関連の情報を表示できますが、このタイプのプロパティの値は変更できません。これらのプロパティは、ブローカ構成内の問題を診断しようとするときに、非常に役立つ場合があります。たとえば、監視可能なプロパティInconsistentLogXptPropsを表示して、REDO転送サービス・プロパティの値に矛盾がある(ブローカ構成ファイルと、データベースで現在使用されている実際の値との間に一貫性がない)箇所を判断できます。
DGMGRLのSHOW DATABASE VERBOSEコマンドを使用すると、すべての監視可能なプロパティを表示できます。特定のプロパティの詳細を知るには、SHOW DATABASEコマンドを使用します。たとえば、次にInconsistentLogXptPropsプロパティの使用例を示します。
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
Cloud Controlでは、これらのプロパティから取得された情報が「プロパティの編集」ページに表示されます。
構成可能なプロパティは、データベースまたは遠隔同期インスタンスの操作や構成に影響を与えます。DGMGRLまたはCloud Controlを使用してプライマリ・データベースを作成し、既存のスタンバイ・データベースおよび遠隔同期インスタンスを新しいブローカ構成にインポートすると、データベース・インスタンスまたは遠隔同期インスタンスの設定から、最初にプロパティ値がインポートされます。
多くのプロパティ値は、構成メンバーが無効の場合でも有効の場合でも更新できます。新しいメンバーが構成に追加されると、ブローカはそのメンバーに接続して、メンバーのプロパティの初期値を現在のメンバー設定からインポートします。次に例を示します。
DGMGRL> SHOW DATABASE 'North_Sales' 'ArchiveLagTarget'; ArchiveLagTarget = '0' DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'ArchiveLagTarget'=1200; Property "ArchiveLagTarget" updated DGMGRL> SHOW DATABASE 'North_Sales' 'ArchiveLagTarget'; ArchiveLagTarget = '1200'
構成が有効な場合、ブローカは、ブローカ構成ファイル内のメンバーのプロパティの値と、メンバーで使用されている値の一貫性を維持します。初期化パラメータ関連のプロパティの場合、ブローカは、ブローカ構成ファイル内の値、現在の値およびサーバー・パラメータ・ファイルの初期化パラメータ値の間の一貫性を次のように維持します。
動的パラメータの場合、ブローカは、そのインスタンスのシステム・グローバル領域(SGA)内、ブローカ構成ファイル内およびサーバー・パラメータ・ファイル内でパラメータの値の一貫性を維持します。
静的パラメータとプロパティの場合、インスタンスのシステム・グローバル領域(SGA)内のパラメータの値は、ブローカ構成ファイル内およびサーバー・パラメータ・ファイル内の値と一時的に異なる場合があります。通常、インメモリーの値は、次回にインスタンスの停止と再起動が行われたときに、サーバー・パラメータ・ファイルの値およびブローカ構成ファイルの値と同じになります。
プロパティの値は、構成が無効の場合でもブローカを使用して更新できます。ブローカはプロパティの設定を(値を検証せずに)保持し、次回ブローカ構成が有効化されたときに、サーバー・パラメータ・ファイル内の初期化パラメータおよびメモリー内の設定を更新します。
注意:
プロパティの値は構成が無効な場合にも変更できますが、変更結果は構成が有効化されるまで構成メンバーに対して有効になりません。また、一部のプロパティ値は無効な状態でのみ変更可能なことに注意してください。
ブローカの大部分の構成可能なプロパティには、デフォルト値があります。異なる値を指定してデフォルトを上書きすることができます。Oracle Database 12cリリース1 (12.1)より前のリリースでは、一度デフォルト値を変更すると、プロパティを後で以前のデフォルト値に設定しなおした場合も、ユーザーが設定した値とみなされました。
Oracle Database 12cリリース1 (12.1)では、プロパティのデフォルト値が回復されたことを認識し、ユーザー設定の値とはみなさなくなりました。これはアップグレード・シナリオで好都合です。これにより、プロパティのデフォルト値がリリースによって異なっても、アップグレードの完了後、新しいデフォルト値が自動的に有効になります。ユーザー設定とみなされる値は、自動的にアップグレードされません。
デフォルト値をリセットするために実際のデフォルト値を知っている必要はありません。デフォルト値は、構成、構成メンバーまたはインスタンスのレベルでリセットすることができます。
REDO転送サービスを管理するには、各構成メンバーに次の構成可能プロパティ・セットを指定します。
DGConnectIdentifier
AlternateLocation
Binding
LogShipping
LogXptMode
MaxConnections
MaxFailure
NetTimeout
RedoCompression
RedoRoutes
ReopenSecs
StandbyArchiveLocation
これらのプロパティを使用して、スタンバイ・データベースに対するREDO転送サービスのブローカによる設定方法を指定できます。LOG_ARCHIVE_DEST_n初期化パラメータの設定など、実際のREDO転送の設定(StandbyArchiveLocationプロパティを除く)は、ブローカによりプライマリ・データベース上で実行されます。プロパティの変更によりLOG_ARCHIVE_DEST_n初期化パラメータの属性変更が必要な場合、ブローカは各スレッド上でログを強制的に切り替えます。これにより、プライマリ・データベースでは新規設定が即時に使用されます。
また、スタンバイ・データベースに切り替える準備として、これらのプロパティをプライマリ・データベース上で事前に設定する必要があります。
REDOデータは、Oracle Netを使用してスタンバイ・データベースに転送されます。Oracle Netサービス名は、LOG_ARCHIVE_DEST_n初期化パラメータのSERVICE属性で指定され、スタンバイ・データベースへのREDOデータの転送に使用されます。Oracle Netサービス名は、スタンバイ・データベースへの接続に必要な情報が記述された接続記述子に変換されます。
SERVICE属性は、データベース・プロパティDGConnectIdentifierを使用して設定または変更できます。DGConnectIdentifierプロパティは、構成にデータベースを初めて追加するときに設定されます。このプロパティの初期値は、ADD DATABASEコマンドのオプションのCONNECT IDENTIFIER IS句に指定した接続識別子です。
DGConnectIdentifierプロパティの値は、FAL_SERVER初期化パラメータの設定にも使用されます。いずれかのデータベースのDGConnectIdentifierプロパティが変更されると、対応するLOG_ARCHIVE_DEST_n初期化パラメータのSERVICE属性も変更されます。また、構成内で有効化されたすべてのスタンバイ・データベースで、FAL_SERVER初期化パラメータが更新されます。
ブローカによるデータ保護モードの処理方法については、「データ保護モードの管理」で説明します。構成全体の保護モードの一部として、REDO転送サービスも、選択したデータ保護モードに対して正しく設定されていることを確認する必要があります。
REDO転送サービスをSYNC、ASYNCまたはFASTSYNCモードに設定するには、LogXptModeまたはRedoRoutesデータベース・プロパティを使用します。
次のREDO転送モードがサポートされています。
SYNC
このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのSYNCおよびAFFIRM属性を使用して構成します。このモードとスタンバイREDOログ・ファイルは、最大保護モードまたは最大可用性モードのいずれかで動作している構成に必要です。このREDO転送サービスでは、プライマリ・データベースに対して最高レベルのデータ保護が可能ですが、パフォーマンスへの影響も大きくなる可能性があります。
ASYNC
このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのASYNCおよびNOAFFIRM属性を使用して構成します。このモードとスタンバイREDOログ・ファイルでは、プライマリ・データベースに対して適度なレベルのデータ保護が可能になり、パフォーマンスへの影響も小さくなります。
FASTSYNC
このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのSYNCおよびNOAFFIRM属性を使用して構成します。このモードは、最大可用性保護モードでのみ利用できます。
デフォルトでは、プライマリ・データベースは、REDOを構成内のすべての可能なREDO転送先に送信します。RedoRoutesプロパティを使用すると、より複雑なREDO転送トポロジを作成することができます。たとえば、フィジカル・スタンバイまたは遠隔同期インスタンスが、プライマリ・データベースから受け取ったREDOを1つ以上の接続先に転送するものや、指定された接続先に対して使用されるREDO転送モードが、どのデータベースがプライマリ・ロールであるかによって異なるものなどです。
RedoRoutesプロパティは、1つ以上のREDOルーティング・ルールを含む文字列に、次に示すようにカッコに囲まれて設定されます。
(redo_routing_rule_1) [(redo_routing_rule_n)]
redo routing ruleには、redo sourceフィールドとredo destinationフィールドが含まれ、それらは次のようにコロンで区切られます。
(redo source : redo destination)
redo sourceフィールドには、次のように、キーワードLOCAL、ANY、またはDB_UNIQUE_NAME値のカンマ区切りリストが含まれる必要があります。
{LOCAL | ANY | db_unique_name_1,[,db_unique_name_n]}
キーワードLOCALは、ローカル・データベース名の別名です。このキーワードは、遠隔同期インスタンスでは使用できません。
ANYキーワードは、構成内の任意のデータベースの別名です。
1つのデータベースは、明示的にも、暗黙的(LOCALキーワードを使用)にも、指定されたデータベースで定義されている複数のREDOルーティング・ルールにおけるREDOソースとして指定することはできません。
redo destinationフィールドには、キーワードALL、またはデータベース名のカンマ区切りリストが含まれる必要があります。それぞれに続けて、オプションでREDO転送属性を指定することができます。
{ALL [attribute] | db_unique_name_1 [attribute] [,db_unique_name_n [attribute]]}
ALLキーワードは、構成において可能なすべての接続先の別名です。
オプションのREDO転送属性は、REDOを関連の接続先に送信するために使用されるREDO転送モードを指定します。可能な値は、次の3つの値のいずれかです。
[ASYNC | SYNC | FASTSYNC]
REDO転送属性を指定しない場合、使用される転送モードは、そのREDO接続先のLogXptModeプロパティで指定されたものになります。
オプションのALTキーワードは、非代替宛先へのREDO転送ができない場合にREDOを受信する代替REDO宛先のDB_UNIQUE_NAMEを指定するために使用します。
[ALT=(alternate db_unique_name [ASYNC | SYNC | FASTSYNC] [FALLBACK])]
オプションのFALLBACKキーワードは、非代替メンバーへのREDO転送が可能になった時点で再開することを指定するために使用します。FALLBACKキーワードを使用することをお薦めします。それを省略し、その後にALTERNATE REDO転送先に障害が発生すると、代替転送先によりサービスが提供されるターミナル・スタンバイ・データベースにREDOが送信されません。
注意:
代替を指定するためには、非代替宛先で、そのMaxFailureプロパティがゼロ以外の値になっている必要があります。
高度なREDO転送設定の使用では、次のことに注意してください。
RedoRoutesプロパティのデフォルト値はNULLです。プライマリ・データベースは、(LOCAL : ALL)として扱われます。
REDOルーティング・ルールがアクティブになるのは、そのREDOソース・フィールドで現在のプライマリ・データベースが指定されている場合です。ルールがアクティブになっている場合、プライマリ・データベースのREDOは、ルールが定義されているデータベースによって、そのルールのREDO接続先フィールドで指定されている各接続先に送信されます。
カスケード接続先で、その接続先へのリアルタイム・カスケーディングを有効にするには、ASYNCREDO転送属性を明示的に指定する必要があります。
RedoRoutesプロパティは、ロジカルまたはスナップショットのスタンバイ・データベースでは設定できません。
ロジカル・スタンバイ・データベースにRedoRoutesプロパティを設定できるのは、REDO宛先フィールドがLOCALに設定されている場合のみです。
代替を指定するためには、非代替メンバーで、その構成可能なプロパティMaxFailureがゼロ以外の値になっている必要があります。
参照:
例4-2 リアルタイム・カスケードに対するRedoRoutesプロパティの使用
プライマリ・データベース(North_Sales)と2つのフィジカル・スタンバイ・データベース(Local_SalesとRemote_Sales)がある構成を考えます。Local_Salesデータベースは、高可用性のために、プライマリと同じデータセンターに置かれています。Remote_Salesデータベースは、障害回復目的で、リモート・データセンターに置かれています。プライマリから両方のデータベースにREDOを送信するかわりに、RedoRoutesプロパティを使用して、ローカルのフィジカル・スタンバイ・データベースが、North_Salesからリモートのフィジカル・スタンバイ・データベース(Remote_Sales)にREDOを転送するようにリアルタイム・カスケードを構成することができます。そのためには、RedoRoutesプロパティを次のように設定する必要があります。
North_Salesデータベースでは、North_Salesがプライマリ・ロールである場合、同期転送モードを使用してLocal_SalesデータベースにREDOを送信するように、RedoRoutesプロパティを指定する必要があります。このルールにより、プライマリがRemote_Salesデータベースに直接REDOデータを送信することがなくなります。
Local_Salesデータベースでは、North_Salesがプライマリ・ロールの場合、Local_Salesが、North_Salesから受け取ったREDOをRemote_Salesに転送するように、RedoRoutesプロパティを指定する必要があります。
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : Local_Sales SYNC)'; DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales ASYNC)';
実行時のRedoRoutes構成を表示するには、SHOW CONFIGURATIONコマンドを使用します。次に例を示します。
DGMGRL> SHOW CONFIGURATION;
Configuration - Sales_Configuration
Protection Mode: MaxAvailability
Databases:
North_Sales - Primary database
Local_Sales - Physical standby database
Remote_Sales - Physical standby database (receiving current redo)
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
Remote_Sales接続先のREDOルート・ルールで、ASYNCREDO転送属性が明示的に指定されることで、その接続先へのREDOのリアルタイム・カスケーディングが有効にされたことに注意してください。
REDOのリアルタイム・カスケーディングを無効にするには、ASYNCREDO転送属性を指定しないでください。次に例を示します。
DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales)';
例4-3 リモート代替宛先に対するRedoRoutesプロパティの使用
RedoRoutesプロパティを使用すると、端末メンバーがREDOデータの受信元のメンバーに障害が発生してもREDOデータを受信できるように、(ALTキーワードを使用して)リモート代替宛先を設定することもできます。前述の例を使用すると、プライマリ・データベースとしてNorth_Salesを使用し、スタンバイ・データベースLocal_Salesに障害が発生したときにREDOデータを直接Remote_Salesに送信できます。また、FALLBACKキーワードを使用して、Local_Salesの障害が解決された時点でRemote_SalesへのREDOの送信を再開できるように設定することもできます。常にFALLBACKキーワードを使用することをお薦めします。設定せずにRemote_Salesへの接続に失敗した場合、Local_Salesが再度使用可能になっても、REDOはLocal_SalesとRemote_Salesのどちらにも送信されません。
リモート代替を設定するための最初の手順は、構成可能なプロパティMaxFailureを使用して、Local_Salesデータベースに最大障害件数を設定することです。Local_SalesのMaxFailureプロパティをゼロ以外の値に設定した場合、Local_Salesの最大障害件数に達すると、REDOは直接Remote_Salesに送信されます。次の例では、Local_Salesの最大障害件数は1に設定されています。
DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'MaxFailure' = 1;
Property "MaxFailure" updated
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' =
'(LOCAL : Local_Sales ASYNC ALT=(Remote_Sales ASYNC FALLBACK))';
Property "RedoRoutes" updated
DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' =
'(North_Sales : Remote_Sales ASYNC)';
Property "RedoRoutes" updated
DGMGRL> SHOW CONFIGURATION;
Configuration - Sales_Configuration
Protection Mode: MaxPerformance
Databases:
North_Sales - Primary database
Local_Sales - Physical standby database
Remote_Sales - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
RedoRoutes構成全部を表示するには、SHOW CONFIGURATION VERBOSEコマンドを使用します。次に例を示します。
DGMGRL> SHOW CONFIGURATION VERBOSE;
Configuration - Sales_Configuration
Protection Mode: MaxPerformance
Members:
North_Sales - Primary database
Local_Sales - Physical standby database
Remote_Sales - Physical standby database
Remote_Sales - Physical standby database (alternate of Local_Sales)
Properties:
FastStartFailoverThreshold = '30'
OperationTimeout = '30'
TraceLevel = 'USER'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
ObserverReconnect = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
ObserverOverride = 'FALSE'
ExternalDestination1 = ''
ExternalDestination2 = ''
PrimaryLostWriteAction = 'CONTINUE'
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
REDO転送サービスのオンとオフを切り替えるには、プライマリ・データベースの状態を設定します。プライマリ・データベースの状態をTRANSPORT-ONに設定するとプライマリ・データベースでREDO転送サービスが起動し、TRANSPORT-OFFに設定するとプライマリ・データベースのREDO転送サービスが停止します。
注意:
すべてのスタンバイ・データベースへのREDO転送サービスをオフにしないことをお薦めします。オフにすると、プライマリ・データベースに障害が発生した場合にデータが消失する危険性があります。
スタンバイ・データベースへのREDO転送サービスのオンとオフを個別に切り替えるには、対象のスタンバイ・データベースにデータベース・プロパティLogShippingを使用します。LogShippingプロパティは、値ONおよびOFFを受け入れます。スタンバイ・データベースに対してLogShippingプロパティをOFFに設定すると、そのスタンバイ・データベースへのREDO転送サービスはオフになりますが、他のデータベースへのREDO転送サービスは影響を受けません。LogShippingをONに設定すると、スタンバイ・データベースへのREDO転送サービスをオンに戻せます。
プライマリ・データベースの状態の設定とLogShippingプロパティの設定の関係は、次のとおりです。
プライマリ・データベースの状態がTRANSPORT-OFFに設定されている場合、各スタンバイ・データベースの個々のLogShippingプロパティ値に関係なく、すべてのスタンバイ・データベースへのREDO転送サービスが停止します。
プライマリ・データベースの状態がTRANSPORT-ONに設定されている場合は、各スタンバイ・データベースへのREDO転送サービスは、それぞれのデータベースのLogShippingプロパティにより決定されます。
例4-4 すべてのスタンバイ・データベースへのREDO転送サービスをオフにする場合
DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='TRANSPORT-OFF';
DGMGRL> SHOW DATABASE 'North_Sales';
Database - North_Sales
Role: PRIMARY
Intended State: TRANSPORT-OFF
Instance(s):
north_sales1
Database Status:
SUCCESS
例4-5 特定のスタンバイ・データベースへのREDO転送サービスをオフにする場合
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogShipping'='OFF'; Property "LogShipping" updated DGMGRL> SHOW DATABASE 'South_Sales' 'LogShipping'; LogShipping = 'OFF'
スタンバイ・データベースのログ適用サービスに使用されるアーカイブREDOログ・ファイルの格納場所をスタンバイ・データベース上に設定できます。そのためには、スタンバイ・データベース上でデータベース・プロパティStandbyArchiveLocationおよびAlternateLocationを設定します。
StandbyArchiveLocationでは、アーカイブREDOログ・ファイルが格納されるスタンバイ位置を指定します。ブローカが使用するのは、プライマリ・データベースから受け取ったアーカイブREDOログ・ファイルの格納場所のみです。データベースがプライマリ・データベースまたはロジカル・スタンバイ・データベースの場合、ローカルに生成されるアーカイブREDOログ・ファイルについては、LOG_ARCHIVE_DEST_n初期化パラメータを介して直接ローカルのアーカイブ先を設定する必要があります。ブローカでは、StandbyArchiveLocationの値をローカルに生成されるログ用に設定したのと同じ位置に設定できます。この場合、ブローカによりアーカイブ先のVALID_FOR属性が適切に設定されるため、プライマリ・データベースから受け取るアーカイブREDOログ・ファイルとローカルに生成されるアーカイブREDOログ・ファイルの両方に同じ位置を使用できます。
注意:
データベース・リカバリ領域を使用する場合を除き、ロジカル・スタンバイ・データベースでは、ローカルの格納先を示すLOG_ARCHIVE_DEST_n初期化パラメータのLOCATION属性とStandbyArchiveLocationプロパティまたはAlternateLocationプロパティのいずれかの値には、異なる値を設定することをお薦めします。
また、スタンバイ・データベース上でAlternateLocationプロパティを使用すると、スタンバイ・データベース上でのアーカイブREDOログ・ファイルについて代替格納場所を設定できます。これは、スタンバイ・データベースにプライマリREDOをアーカイブする場合に、ディスク容量の問題やディスク・エラーを回避する上で役立ちます。AlternateLocationでは、StandbyArchiveLocationで指定した位置に障害が発生した場合に、アーカイブREDOログ・ファイルが格納されるスタンバイ位置を指定します。ブローカは、LOG_ARCHIVE_DEST_n初期化パラメータのALTERNATE属性を使用して、代替位置を正しく設定します。
注意:
スタンバイ上のデータベース・リカバリ領域をアーカイブREDOログ・ファイルの格納に使用できます。この場合、StandbyArchiveLocationプロパティまたはAlternateLocationプロパティの値をUSE_DB_RECOVERY_FILE_DESTに設定できます。
データベース・プロパティBinding、MaxFailure、MaxConnections、NetTimeout、RedoCompression、およびReopenSecsを使用して、REDO転送サービスのパフォーマンスをチューニングし、その障害ポリシーを設定できます。これらのプロパティは、LOG_ARCHIVE_DEST_n初期化パラメータの属性に対応します。
参照:
これらのデータベース・プロパティの詳細は「Oracle Data Guard Brokerのプロパティ」を参照
プライマリ・データベースがOracle RACデータベースの場合、ブローカは各プライマリ・データベース・インスタンス上のREDO転送サービスが同一に設定されていることを確認します。各インスタンスのリモート接続先は同じで、すべてのインスタンスで、各リモート接続先には同じREDO転送サービス、パフォーマンス関連設定などが設定されます。インスタンスの設定が異なる場合、ブローカはそのインスタンスに関して健全性チェックの警告を発行します。
REDO転送サービスに関連する設定は、ブローカ構成ファイルにプロパティとして保存されます。スタンバイ・データベース上のREDO転送関連のプロパティを更新すると、すべてのプライマリ・データベース・インスタンス上のLOG_ARCHIVE_DEST_n初期化パラメータに対しても、ブローカによって自動的に対応する変更が実行されます。プライマリ・データベース上で新規インスタンスが作成されると、ブローカは現在管理している全スタンバイ・データベースのREDO転送関連プロパティを使用して、新規インスタンス用のREDO転送サービスを設定します。新規インスタンスがアクティビティ用にオープンされた後、このインスタンス上で生成された全アーカイブREDOログ・ファイルについて、スタンバイ・データベースへの転送が開始されます。
参照:
LOG_ARCHIVE_DEST_n初期化パラメータの詳細は、『Oracle Data Guard概要および管理』を参照してください。
転送ラグは、スタンバイ・データベースへのREDOの転送がプライマリ・データベースでのREDOの生成からどの程度遅れているかを測定する尺度です。
スタンバイ・データベースで1つ以上のREDOギャップがある場合は、最初のREDOギャップの発生後にREDOは受信されなかったものとして、転送ラグが計算されます。
Cloud ControlとDGMGRLクライアントのいずれでも、管理対象スタンバイ・データベースごとにREDO転送ラグが表示されます。Cloud Controlでは、Oracle Data Guardホームページに転送ラグが表示されます。DGMGRLクライアントでは、スタンバイ・データベースの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: 255.00 KByte/s
Real Time Query: OFF
Instance(s):
south_sales1
Database Status:
SUCCESS
転送ラグにより、REDO転送サービスで発生する可能性のある問題を識別することができます。
構成可能なデータベース・プロパティTransportLagThresholdを設定すると、スタンバイ・データベースへのREDOデータの転送がプライマリ・データベース上でのREDOデータの生成より遅れる場合にヘルス・チェック警告を生成することができます。
次のコマンドは、TransportLagThresholdプロパティを15秒に設定します。
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'TransportLagThreshold'=15; Property TransportLagThreshold updated
さらに、構成可能なデータベース・プロパティTransportDisconnectedThresholdを設定すると、スタンバイがプライマリ・データベースとの間にいかなるREDO転送関連の通信も持っていないことを検出したときにヘルス・チェック警告を生成することができます。プロパティのデフォルト値は30秒です。
次のコマンドは、TransportDisconnectedThresholdプロパティを15秒に設定します。
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'TransportDisconnectedThreshold'=15; Property TransportDisconnectedThreshold updated
次に示すログ適用に関連するデータベース・プロパティを使用して、フィジカルまたはロジカル・スタンバイ・データベース上のREDO ApplyおよびSQL Applyを管理できます。
REDO ApplyおよびSQL Applyに共通のプロパティ
ApplyInstanceTimeout
DelayMins
PreferredApplyInstance
REDO Applyに固有のプロパティ
ApplyParallel
SQL Applyに固有のプロパティ
LsbyMaxEventsRecorded
LsbyPreserveCommitOrder
LsbyRecordSkipErrors
LsbyRecordSkipDdl
LsbyRecordAppliedDdl
LsbyMaxSga
LsbyMaxServers
現在のデータベースの状態がAPPLY-ONの場合、SQL Apply関連のプロパティを変更すると、SQL Applyの再起動が必要になる場合があります。SQL Applyの再起動が必要なプロパティを調べるには、「Oracle Data Guard Brokerのプロパティ」のSQL Apply関連のプロパティの情報を参照してください。
データベースの現在の状態がAPPLY-OFFの場合、プロパティ変更はデータベースの状態が次回にAPPLY-ONに変化したときに有効になります。
スタンバイ・データベースへのREDOの適用を遅延させるように適用サービスを設定できます。これにより、スタンバイ・データベースとプライマリ・データベース間にずれが生じ、この期間中にユーザー・エラー(表の削除など)が発生した場合も、スタンバイ・データベースには正しいデータが含まれているため、それをプライマリ・データベースに転送してデータを修復できます。
デフォルトでは遅延は設定されておらず、REDOデータはできるかぎり速やかにスタンバイ・データベースに適用されます。スタンバイ・データベースでREDOログが構成されると、ブローカは、リアルタイム適用を有効化します。REDO ApplyおよびSQL ApplyがリアルタイムでREDOを適用する場合、REDOデータは、書き込まれると同時に、スタンバイREDOログ・ファイルから直接リカバリされます。つまり、スタンバイ・データベースは、アーカイブREDOログ・ファイルからREDOデータを適用するのにログ・ファイルがアーカイブされるのを待つ必要はありません。これにより、プライマリとスタンバイのトランザクション・ラグが最小限に抑えられます。
データベース・プロパティDelayMinsを使用して、スタンバイ・データベースにREDOデータが適用されるまでのログ適用サービスの待機時間(分)を指定します。スタンバイ・データベースへのログ適用サービスのみが遅延されることに注意してください。プライマリ・データベースのREDO転送サービスは遅延されないため、プライマリ・データベースのデータは引き続きスタンバイ・データベースにより適切に保護されます。
注意:
ブローカではスタンバイ・データベースへのリアルタイム適用が自動的に有効化されるため、フラッシュバック・データベースを使用するようにすべてのデータベースを構成することをお薦めします。
REDO Applyでは、データベース・プロパティApplyParallelを使用して、プライマリ・データベースから受け取ったREDOデータの適用に複数のパラレル・プロセスを使用するかどうかを構成できます。並列性はデフォルトで有効化されています。つまり、REDO ApplyではシステムのCPUの数に基づいて最適なパラレル・プロセス数が自動的に選択されます。(これは、ApplyParallelプロパティをAUTOに設定することと同じです。)ApplyParallelプロパティをNOに設定することで並列性を無効化できます。
注意:
データベース・プロパティApplyParallelは、Cloud Controlの「プロパティの編集」ページには表示されません。
参照:
「ApplyParallel」のApplyParallelプロパティ
SQL Applyに使用可能なSGAメモリーの量を制御できます。この設定には、データベース・プロパティLsbyMaxSgaを使用します。
SQL Applyで使用されるパラレル問合せサーバーの数を制御するには、データベース・プロパティLsbyMaxServersを使用します。
ユーザーは、SQL Applyのパフォーマンスとトランザクションのコミット順序との間のトレード・オフを制御できます。データベース・プロパティLsbyPreserveCommitOrderは、プライマリ・データベースでコミットされた順序と同じ順序でトランザクションがロジカル・スタンバイ・データベースにコミットされるかどうかを制御します。コミット順序を保持すると、パフォーマンスに影響する場合があります。
DBA_LOGSTDBY_EVENTS表は、SQL Applyに影響する重要なイベントを記録します。この表に記録されるイベント・セットのうち、どのイベントが重要であるかはロジカル・スタンバイ・データベースごとに異なるため、Oracle Data Guardにはイベント記録を制御する手段が用意されています。Oracle Data Guard Brokerから、データベース・プロパティLsbyRecord* (LsbyRecordSkipDdlまたはLsbyRecordSkipErrorsなど)を使用して、特定のイベント・セットの記録を制御できます。これらのプロパティの値は、イベント記録のオンまたはオフを示すTRUEまたはFALSEです。
スタンバイ・データベースがOracle RACデータベースの場合、ログ適用サービスが実行されるOracle RACデータベース・インスタンスは常に1つのみです。このインスタンスを適用インスタンスと呼びます。適用インスタンスに障害が発生すると、ブローカはログ適用サービスを自動的に異なるインスタンスに移動します。これを適用インスタンスのフェイルオーバーと呼びます。
注意:
この項の情報は、スナップショット・スタンバイ・データベースまたは遠隔同期インスタンスには適用されません。
Oracle RACスタンバイ・データベースでどのインスタンスを適用インスタンスにしてもよい場合、ブローカが適用インスタンスを任意に選択します。特定のインスタンスを適用インスタンスとして選択するには、次の2つの方法があります。
最初の方法は、データベース・プロパティPreferredApplyInstanceの値を、適用インスタンスとして指定するインスタンスの名前(SidNameプロパティを参照)に設定することです。ブローカは、Oracle RACスタンバイ・データベースで適用インスタンスが選択されていない場合に、そのインスタンス上でログ適用サービスを起動します。この方法を使用するのは、スタンバイ・データベースをまだ1度も有効化していない場合、適用インスタンスに障害が発生したばかりで、ブローカが適用インスタンスをフェイルオーバーしようとしている場合、またはOracle RACデータベースが現在プライマリ・データベースとして稼働中で、スイッチオーバーの準備として適用インスタンスを指定する必要がある場合などです。適用インスタンスが選択されており、かつ、その適用インスタンスが実行中の場合は、PreferredApplyInstanceプロパティを変更しても、ブローカでは変更後の値が無視されます。
第2の方法では、選択され実行されている適用インスタンスを変更します。適用インスタンスを変更するには、特定の適用インスタンス引数を指定してDGMGRLのSET STATEコマンドを発行し、スタンバイ・データベースの状態をAPPLY-ONに設定します。SET STATEコマンドを実行すると、PreferredApplyInstanceプロパティが新しい適用インスタンスの値に更新されてから、ログ適用サービスが新規インスタンスに移動します。たとえば、DGMGRLのSHOWコマンドを使用してスタンバイ・データベースで使用可能なインスタンスを表示し、EDIT DATABASEコマンドを発行してログ適用サービスを新規インスタンスに移動します。
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: 1017.00 KByte/s
Real Time Query: OFF
Instance(s):
south_sales1 (apply instance)
south_sales2
Database Status:
SUCCESS
DGMGRL> EDIT DATABASE 'South_Sales' SET STATE='APPLY-ON' WITH APPLY INSTANCE='south_sales2'; Succeeded. DGMGRL> SHOW DATABASE 'South_Sales' 'PreferredApplyInstance'; PreferredApplyInstance = 'south_sales2'
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: 1017.00 KByte/s
Real Time Query: OFF
Instance(s):
south_sales1
south_sales2 (apply instance)
Database Status:
SUCCESS
コマンドの発行時には、新規適用インスタンスが実行中であることを確認してください。それ以外の場合は、適用インスタンスが変更されません。
適用インスタンスの選択後、ブローカは適用インスタンス情報をブローカ構成ファイルに保存します。これにより、スタンバイ・データベースが停止されて再起動されても、ブローカは停止前と同じインスタンスを選択してログ適用サービスを起動できます。適用インスタンスは、ユーザーが変更するか、なんらかの原因で障害が発生してブローカが適用インスタンスのフェイルオーバーを実行すると決定するまで変更されません。
適用インスタンスの障害に対するフォルト・トレラントを持たせるために、ブローカはログ適用サービスを異なるスタンバイ・インスタンスに自動的にフェイルオーバーすることで、Oracle RACスタンバイ・データベースの可用性を利用します。ブローカが提供する適用インスタンスのフェイルオーバー機能により、データ保護が強化されます。
適用インスタンスのフェイルオーバーを設定するには、データベース・プロパティApplyInstanceTimeoutを設定してブローカの待機時間を指定します。この待機時間は、適用インスタンス障害を検出してから適用インスタンスのフェイルオーバーを開始するまでの期間です。適切なタイムアウト値を選択するには、次のことを考慮する必要があります。
クラスタに、障害が発生した適用インスタンスのリカバリを試みる他のメカニズムがあるかどうか(Oracle Clusterwareなど)。
ビジネスで、REDOデータがスタンバイ・データベースに適用されないことを容認できる時間。
ログ適用サービスを他のインスタンスに移動する操作に関連するオーバーヘッド。オーバーヘッドには、障害の発生した適用インスタンス上に累積されていて未適用のログ・ファイルすべてが、他のスタンバイ・インスタンスからアクセスできる共有ファイル・システムに保存されていない場合に、それをプライマリ・データベースから再転送する操作が含まれる場合があります。
ブローカのApplyInstanceTimeoutプロパティのデフォルト値は0秒です。これは、現在の適用インスタンスの障害検出後ただちに、適用インスタンスのフェイルオーバーが開始されることを示しています。
ブローカでは、適用インスタンスのフェイルオーバー開始後に、次のルールに従って新規の適用インスタンスが選択されます。PreferredApplyInstanceプロパティが現在実行中のインスタンスを示している場合は、それが新規の適用インスタンスとして選択されます。それ以外の場合は、現在実行中の任意のインスタンスが新規の適用インスタンスとして選択されます。
また、適用インスタンスの障害発生時にフィジカル・スタンバイ・データベースがリアルタイム問合せモードで動作していた場合、Oracleリカバリ・クリーンアップの完了後、自動的にクローズされたインスタンスはすべてブローカによってオープンされます。障害の発生した適用インスタンスが唯一のオープン・インスタンスであった場合、リアルタイム問合せを再度有効にするため、適用サービスを開始する前に、新しい適用インスタンスとして選択されたインスタンスがオープンされます。
参照:
リアルタイム問合せモードの詳細は、『Oracle Data Guard概要および管理』を参照してください。
Oracle Active Data GuardのOracle RACスタンバイにおける適用インスタンス障害の詳細は、http://support.oracle.comにあるMy Oracle Supportノート1357597.1を参照してください。
適用ラグは、REDOのスタンバイ・データベースへの伝播および適用の遅延により、スタンバイ・データベースのデータがプライマリ・データベースのデータからどの程度遅れているかを測定する尺度です。
Cloud ControlとDGMGRLクライアントのいずれでも、管理対象スタンバイ・データベースごとに適用ラグが表示されます。Cloud Controlでは、Oracle Data Guardホームページに適用ラグが表示されます。DGMGRLクライアントでは、スタンバイ・データベースのSHOW DATABASE出力に適用ラグが表示されます。プライマリ・データベースに対する適用ラグは表示されません。次に例を示します。
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: 255.00 KByte/s
Real Time Query: OFF
Instance(s):
south_sales1
Database Status:
SUCCESS
適用ラグでは、REDO転送サービスとログ適用サービスで発生する可能性のある問題を識別することができます。
構成可能なデータベース・プロパティApplyLagThresholdを設定すると、スタンバイ・データベースがプライマリ・データベースのデータに遅れを取る場合にヘルス・チェック警告を生成することができます。
次のコマンドは、ApplyLagThresholdプロパティを15秒に設定します。
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'ApplyLagThreshold'=15; Property ApplyLagThreshold updated
各データ保護モードでは、データ保護、データ可用性およびデータベース・パフォーマンスが様々なバランスで提供されます。ビジネス・ニーズに合うデータ保護モードを選択するには、データ保護の要件とユーザーが要求するパフォーマンスを慎重に考慮します。
注意:
最大保護モードは、次の状況では使用できません。
構成の唯一のスタンバイ・データベースがスナップショット・スタンバイである場合
遠隔同期インスタンスが、プライマリ・データベースから同期モードでREDOを受け取っている唯一の構成メンバーである場合
最大可用性
この保護モードは、プライマリ・データベースの可用性を低下させない範囲で可能な最高レベルのデータ保護を提供します。トランザクションのリカバリに必要なすべてのREDOデータがオンラインREDOログと1つ以上の同期スタンバイ・データベース上のスタンバイREDOログに書き込まれるまで、トランザクションはコミットされません。1つ以上の同期スタンバイ・データベースにREDOストリームを書き込めない場合、プライマリ・データベースは最大パフォーマンス・モードの場合と同様に動作して、同期スタンバイ・データベースへのREDOストリームの書込みが再び可能になるまでプライマリ・データベースの可用性を維持します。
このモードでは、プライマリ・データベースの障害発生時に、第2の障害が発生してもプライマリ・データベースから1つ以上のスタンバイ・データベースにREDOデータの完全なセットを送信できるときにのみ、データが消失しないことが保証されます。
保護モードが最大可用性の場合、ファスト・スタート・フェイルオーバーを有効化できます。
最大パフォーマンス
この保護モードは、プライマリ・データベースのパフォーマンスに影響しない範囲で可能な最高レベルのデータ保護を提供します。これを実現するため、トランザクションで生成されたすべてのREDOデータがオンライン・ログに書き込まれると、トランザクションをすぐにコミットできます。REDOデータは1つ以上のスタンバイ・データベースにも書き込まれますが、この書込みはトランザクションのコミットとは非同期に実行されるため、スタンバイ・データベースへのREDOデータの書込みの遅延は、プライマリ・データベースのパフォーマンスに影響を与えません。
最大可用性モードと比較して、この保護モードではデータ保護が若干弱くなり、プライマリ・データベースのパフォーマンスへの影響を最小限に抑えます。
これはデフォルトの保護モードです。
保護モードが最大パフォーマンスの場合、ファスト・スタート・フェイルオーバーを有効化できます。
最大保護
この保護モードは、プライマリ・データベースに障害が発生した場合でも、データ消失がないことを保証します。この保護レベルを提供するには、トランザクションのコミット前に、トランザクションのリカバリに必要なREDOデータを、オンラインREDOログと1つ以上の同期スタンバイ・データベース上のスタンバイREDOログに書き込む必要があります。データの消失が起こり得ないようにするため、1つ以上の同期スタンバイ・データベースにREDOストリームを書き込めない場合、プライマリ・データベースは停止し、トランザクション処理を継続しません。
Oracle Data GuardがREDOデータをスタンバイREDOログ・ファイルの永久記憶域に書き込むとすぐに、プライマリのトランザクションは保護されたものとみなされます。その後すぐにプライマリ・データベースに確認通知を戻し、次のトランザクションに進めるようにします。これによって、プライマリ・データベースでの同期転送スループットやレスポンス時間による影響を最小化できます。スタンバイ・データベースでの完全なOracle Data Guardの検証機能を最大限活用するには、必ずリアルタイムの適用モードで操作し、REDOの変更を受信と同時にスタンバイ・データベースに適用します。Oracle Data Guardは検出したすべての破損を通知するので、迅速な修正処理を実行できます。
このデータ保護モードでは、プライマリ・データベースの可用性よりもデータ保護を優先するため、単一のスタンバイ・データベースの障害によってプライマリ・データベースが停止しないように、少なくとも2つのスタンバイ・データベースを使用して最大保護モードで実行するプライマリ・データベースを保護することをお薦めします。1つのスタンバイ・データベースのみが最大保護モードをサポートしている場合、Oracle Data Guard Brokerは適用インスタンスのシャットダウンを禁止します。これによりプライマリ・データベースはシャットダウンされなくなります。
保護モードが最大保護の場合、ファスト・スタート・フェイルオーバーを有効化できません。
参照:
ファスト・スタート・フェイルオーバーの詳細は、「ファスト・スタート・フェイルオーバー」を参照
データ保護モードの詳細は、『Oracle Data Guard概要および管理』を参照してください。
使用している保護モードに関係なく、スタンバイREDOログ・ファイルをすべてのスタンバイ・データベースに追加する必要があります。また、スイッチオーバーやフェイルオーバーに備えてプライマリ・データベース上にもスタンバイREDOログ・ファイルを追加する必要があります。ファスト・スタート・フェイルオーバーを有効にする場合は、プライマリ・データベース上にスタンバイREDOログ・ファイルが必要です。
Cloud Controlでは、構成内の1つ以上のスタンバイ・データベースを選択するように要求され、将来のロール変更に備えて、スタンバイ・データベースおよびプライマリ・データベース上にスタンバイREDOログ(SRL)ファイルが設定されます。
データ保護モードによって、スタンバイ・データベースのいずれかが使用しているREDO転送モードの変更が必要になる場合、各スタンバイ・データベース上でLogXptModeデータベース・プロパティを変更するか、プライマリ・データベース上、またはスタンバイ・データベースに直接接続している遠隔同期インスタンス上で、RedoRoutesプロパティを設定します。REDO転送サービスの設定の詳細は、「REDO転送サービスの管理」を参照してください。表4-2では、保護モードおよび対応するREDO転送サービスを示します。
Cloud Controlでは自動的に、将来のスイッチオーバーに備えて、プライマリ・データベース上に適切なREDO転送サービスが設定されます。
表4-2 Oracle Data Guard保護モードと要件
| 保護モード | REDO転送 | スタンバイREDOログ・ファイルの要否 | ファスト・スタート・フェイルオーバーとの併用 |
|---|---|---|---|
|
|
必要 |
いいえ |
|
|
必要 |
あり脚注1 |
|
|
必要 |
はい |
脚注1
FASTSYNC転送モードはLOG_ARCHIVE_DEST_nパラメータのNOAFFIRM属性を使用するため、データが失われる可能性があります。FASTSYNCを使用していて、スタンバイにREDOデータがない場合、ファスト・スタート・フェイルオーバーを開始できません。
DGMGRLコマンドまたはCloud Controlを使用した保護モードの設定
DGMGRLを使用する場合
EDIT DATABASE(プロパティ)コマンドを使用して、設定する保護モードに対応するようにREDO転送サービスを変更する必要のあるスタンバイ・データベースを指定します。たとえば、Oracle Data Guard構成全体を最大可用性モードで動作するように設定する場合は、EDIT DATABASEコマンドを使用して、REDO転送サービスに対してSYNCモードを設定する必要があります。次に例を示します。
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY LogXptMode='SYNC';
この確認を構成内のプライマリ・データベースまたは他のスタンバイ・データベースについても行い、選択した保護モードをスイッチオーバー後もサポートできることを確認します。
次のように、RedoRoutesプロパティを使用することもできます。
EDIT DATABASE 'North_Sales' SET PROPERTY RedoRoutes = '(LOCAL : South_Sales SYNC)';
EDIT CONFIGURATION SET PROTECTION MODE AS protection-modeコマンドを使用して、構成全体の保護モードを設定します。次に例を示します。
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
保護モードの設定方法を示すDGMGRLの使用例については、「使用例4: 構成保護モードの設定」を参照してください。
Cloud Controlで、次の手順を実行します。
SYSDGまたはSYSDBA権限でデータベースにログインして「ログイン」をクリックします。最大保護モードにアップグレードする場合、DGMGRLまたはCloud Controlを使用して保護モードを最大パフォーマンス・モードから最大保護モードにアップグレードすると、プライマリ・データベースは自動的に再起動されます。保護モードをダウングレードした後でプライマリ・データベースを再起動する必要はありません。
保護モードを最大パフォーマンスから最大可用性に、または最大可用性から最大保護にアップグレードする場合、再起動は不要です。
注意:
最大パフォーマンス・モードから最大保護モードにアップグレードする際、まず最大可用性モードにアップグレードすることで、プライマリ・データベースの再起動を回避できます。最大可用性モードにしたら、次に最大保護モードにアップグレードします。
注意:
Oracle RAC One Nodeのオンライン・データベース再配置は、最大保護モードをサポートするフィジカル・スタンバイ・データベースのみで実行することはできません。
オンライン・データベース再配置を実行する必要がある場合、まず、保護モードを最大可用性にダウングレードします。フィジカル・スタンバイ・データベースのオンライン・データベース再配置を実行した後で、保護モードを最大保護にアップグレードすることができます。プライマリ・データベースの再起動は必要ありません。
この項では、スイッチオーバー、フェイルオーバー、Oracle Data Guard構成の無効化または有効化などの操作が、構成の保護モードやREDO転送サービスに与える影響について説明します。この項の内容は、次のとおりです。
現在のOracle Data Guard保護モードを最大可用性モードにアップグレードする場合または現在のOracle Data Guard保護モードをダウングレードする場合、再起動は不要です。Oracle Data Guard保護モードのアップグレード時またはダウングレード時には、次の推奨事項に従ってください。
保護モードをアップグレードするときは、全体の保護モードをアップグレードする前にREDO転送サービスをアップグレードします。保護モードの変更時やスタンバイ・データベースのREDO転送サービスのリセット時に、ブローカは、必要なレベルの保護をサポートできるスタンバイ・データベースが構成内に少なくとも1つ存在していることを確認します。この条件が満たされない場合、保護モードは変更されず、エラーが戻されます。
保護モードをダウングレードするときは、最初に保護モードをダウングレードしてから、REDO転送サービスを変更します(必要な場合)。REDO転送サービスの変更によって現在の全体の保護モードが無効になる場合、ブローカはREDO転送サービスの変更を許可しません。
最大パフォーマンス・モードから保護モードをアップグレードする場合、ブローカは、直接、または、遠隔同期インスタンスを介して、SYNC転送を使用してREDOを受け取るスタンバイ・データベースが少なくとも1つあることを確認します。また、最大保護モードへのアップグレードの場合、ブローカは、スタンバイ・データベースのREDOデータにギャップがないことを確認します。これらの要件を満たすスタンバイ・データベースが構成内に存在していない場合、保護モードのアップグレード要求はエラーとなり拒否されます。
ファスト・スタート・フェイルオーバーが有効化されても、保護モードは変更されません。
警告:
保護モードを最大パフォーマンスから最大保護にアップグレードすると、プライマリ・データベースは、停止され再起動されます。まず最大可用性にアップグレードすると、この動作を回避できます。最大可用性モードにしたら、次に最大保護モードにアップグレードします。
スイッチオーバーでは、全体のOracle Data Guard保護モードは変更されません。保護モードはスイッチオーバー前と同じです。
スイッチオーバーの完了後に現在の保護モードをサポートするために、適切に構成されているスタンバイ・データベースが必要です。これは、構成内の他のスタンバイ・データベースでも、スイッチオーバー完了後にスタンバイ・データベースとなる現行のプライマリ・データベースでもかまいません。
必要な場合は、スイッチオーバーを起動する前に、現行のプライマリ・データベース上または構成内の他のスタンバイ・データベース上に、スタンバイREDOログ・ファイルを追加して、REDO転送サービスをOracle Data Guard保護モードのサポートに必要な転送モードに設定できます。その後スイッチオーバーが開始されると、次の処理が実行されます。
ブローカでは、各スタンバイ・データベース上と現行のプライマリ・データベース上で、スタンバイREDOログ・ファイルが存在することとREDO転送サービスの設定が検証されます。
ブローカは、ターゲット・スタンバイ・データベースに存在するREDOデータに差分がないことを検証します。
検証が正常終了した場合は、スイッチオーバーが続行されます。正常終了しなかった場合、スイッチオーバーは失敗し、データベース・ロールとブローカ構成ファイルは変更されません。
警告:
スイッチオーバーのターゲットがフィジカル・スタンバイ・データベースの場合、ブローカはシャットダウンして、プライマリ・データベースを再起動します。
構成された保護モードが最大保護モードで、そのモードをサポートするスタンバイが1つしかない場合、スイッチオーバーが実行されると、プライマリとスタンバイの両方が再起動されます。
参照:
スイッチオーバーの詳細は、「スイッチオーバー」を参照
保護モードが最大保護だった場合、手動フェイルオーバーを実行した後に、Oracle Data Guard保護モードが最大パフォーマンス・モードにダウングレードされます。必要な場合、保護モードは後でアップグレードできます。保護モードが最大可用性または最大パフォーマンスだった場合は、変更されません。スタンバイ・データベースのREDO転送サービスは変更されません。
ファスト・スタート・フェイルオーバーが実行された場合、ブローカにより、フェイルオーバー前に有効になっていた保護モードが保持されます。
参照:
手動フェイルオーバーおよびファスト・スタート・フェイルオーバーの詳細はそれぞれ、「手動フェイルオーバー」および「ファスト・スタート・フェイルオーバー」を参照
あるスタンバイ・データベースのブローカ管理を無効化すると、ブローカによって、残りのスタンバイ・データベースのいずれかが、全体の保護モードの要件を引き続き満たしているかがチェックされます。この条件が満たされない場合、無効化操作はブローカによって拒否されます。この条件が満たされる場合は、ファスト・スタート・フェイルオーバーが有効化されていないかぎり、無効化操作は続行されます。ファスト・スタート・フェイルオーバーが有効化されている場合でも、そのスタンバイ・データベースが、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースでなければ、無効化操作は続行されます。
警告:
ブローカ構成内のスタンバイ・データベースに関してブローカによる管理を無効化すると、プライマリ・データベースが消失した場合にも、そのスタンバイ・データベースはブローカでフェイルオーバー・ターゲットとして使用できなくなります。
スタンバイ・データベースが正常に無効化された後は、そのデータベースのREDO転送サービスを変更できます。変更内容は、ブローカによってブローカ構成ファイルに記録されます。この変更が全体の保護モードに影響を与えることはありません。これは、有効なスタンバイ・データベースの少なくとも1つが、全体の保護モード要件をすでに満たしているためです。
ファスト・スタート・フェイルオーバーが有効化されていないかぎり、構成全体は保護モードに関係なく無効化できます。ファスト・スタート・フェイルオーバーが有効化されている場合は、構成を無効にできません。詳細は、「ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項」を参照してください。
構成全体が無効な場合は、スタンバイ・データベースのREDO転送サービスや構成の保護モードなどのブローカの設定を変更できます。ブローカはブローカ構成ファイルに変更を保存しますが、データベース自体には変更は行われません。
構成全体のブローカ管理を有効化するときは、ブローカによって、有効化されるスタンバイ・データベースのREDO転送サービスが保護モードの要件を満たしているかどうかが最初にチェックされます。この条件が満たされていない場合、有効化操作は失敗し、構成は無効のままになります。条件が満たされている場合は、有効化操作によって構成が正常に有効化され、ブローカは、ブローカ構成ファイルに保存されている設定を使用してデータベースを有効化します。
ブローカ構成で行われる一部の操作、特にREDO転送サービスに関連する操作は、全体の保護モードに影響を与える場合があります。次のような操作があります。
プライマリ・データベースのREDO転送サービスを停止する操作
個々のスタンバイ・データベースへのREDO転送サービスを停止する操作
最大可用性モードまたは最大保護モードで動作している構成をサポートする唯一のスタンバイ・データベースで、REDO転送モードをSYNCからASYNCにダウングレードする操作
これらの操作の前には、ブローカによって、操作完了後にスタンバイ・データベースのREDO転送モード設定が保護モードをサポートするかどうかがチェックされます。この条件が満たされていない場合、操作は失敗し、エラーが戻されます。
Oracle Data Guard遠隔同期インスタンスは、プライマリ・データベースからREDOを受け取るREDO転送先で、そのREDOを構成内の1つ以上のREDO接続先に転送します。それは制御ファイルを持つ点でフィジカル・スタンバイ・データベースに類似しており、REDOをスタンバイREDOログ・ファイル(SRL)に受信し、それらのSRLをローカルのアーカイブREDOログ(ARL)にアーカイブします。しかしスタンバイ・データベースとは異なり、遠隔同期インスタンスにはデータ・ファイルがなく、オープンすることもできず、受け取ったREDOを適用することもできません。これらの制限のために、ディスクと処理リソースの使用量が少なくなる利点があります。より重要なこととして、遠隔同期インスタンスは、同期転送モードを使用してREDOデータを受け取り、構成保護モードが最大可用性に設定されている場合、データ損失なしでターミナル・データベースにフェイルオーバーすることができます。
次の例は、ブローカ構成に遠隔同期インスタンスを追加する方法を示します。
DGMGRL> ADD FAR_SYNC FS1 AS CONNECT IDENTIFIER IS FS1.example.com;
Far Sync FS1 added
DGMGRL> ENABLE FAR_SYNC FS1;
Enabled.
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxPerformance
Databases:
North_Sales - Primary database
FS1 - Far Sync
South_Sales - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
遠隔同期インスタンスが構成に追加された後、REDO転送を設定して最大可用性をサポートし、その後で保護モードを次のようにアップグレードします。
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : FS1 SYNC)';
DGMGRL> EDIT FAR_SYNC 'FS1' SET PROPERTY 'RedoRoutes' = '(North_Sales : South_Sales ASYNC)';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxAvailability
Databases:
North_Sales - Primary database
FS1 - Far Sync
South_Sales - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
South_Salesがプライマリ・データベースの場合に、最大可用性保護モードを保持できるようにするには、スイッチオーバーまたはフェイルオーバー後に、2番目の遠隔同期インスタンスを構成に追加して、South_SalesがREDOを同期モードで送信できるようにし、ロール遷移後に新しいターミナル・データベースのNorth_Sales,にREDOが送信されるようにします。
次の例は、ブローカ構成に2番目の遠隔同期インスタンスを追加する方法を示します。
DGMGRL> ADD FAR_SYNC FS2 AS CONNECT IDENTIFIER IS FS2.example.com;
Far Sync FS2 added
DGMGRL> EDIT FAR_SYNC 'FS2' SET PROPERTY 'RedoRoutes' = '(South_Sales : North_Sales ASYNC)';
DGMGRL> ENABLE FAR_SYNC FS2;
Enabled.
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : FS2 SYNC)';
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxAvailability
Databases:
North_Sales - Primary database
FS1 - Far Sync
South_Sales - Physical standby database
FS2 - Far Sync (inactive)
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
遠隔同期インスタンスの可用性が、(たとえばOracle Restart、Oracle Real Application Clusters (Oracle RAC)またはOracle RAC One Nodeのインストールにおいて) Oracle Clusterwareによって監視されている場合、SRVCTLユーティリティを使用して、デフォルトのオープン・マウント・モードを指定します。次のようなコマンドを使用できます。
srvctl modify database -d <db_unique_name> -startoption MOUNT
参照:
遠隔同期インスタンスの作成およびREDO転送の詳細は、『Oracle Data Guard概要および管理』を参照してください。
olink:ADMIN-GUID-79B9EC11-9711-424F-94D1-6B0EFCF77173『Oracle Database管理者ガイド』
完全自動管理の場合、ファスト・スタート・フェイルオーバーを有効にすると、ブローカによるフェイルオーバーの必要性の判断と、事前に指定されたターゲット・スタンバイ・データベースへのフェイルオーバーの開始が可能になります。これに伴うデータの消失はない場合と、構成可能なデータ量を消失する場合があります。また、フェイルオーバーが開始される条件やエラーも指定できます。DBMS_DG PL/SQLパッケージを使用すると、アプリケーションでファスト・スタート・フェイルオーバーを要求できます。
ブローカ構成プロパティを使用して、ファスト・スタート・フェイルオーバーの動作を制御します。また、Cloud ControlまたはDGMGRLのENABLE FAST_START FAILOVER CONDITIONコマンドおよびDISABLE FAST_START FAILOVER CONDITIONコマンドを使用して、ファスト・スタート・フェイルオーバーが実行される条件を指定することもできます。
ファスト・スタート・フェイルオーバーに関する構成可能なプロパティは、次のとおりです。
FastStartFailoverThreshold
FastStartFailoverThreshold構成プロパティを設定して、(プライマリ・データベースが使用できないことが検出されてから)フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。詳細および例は、「ファスト・スタート・フェイルオーバーの有効化」を参照してください。
FastStartFailoverPmyShutdown
FastStartFailoverPmyShutdown構成プロパティは、REDOの生成が停止され(V$DATABASEのFS_FAILOVER_STATUS列の値がSTALLED)、オブザーバおよびターゲット・スタンバイ・データベースとの接続が失われてから経過した時間がFastStartFailoverThreshold構成プロパティに指定された秒数を超過した場合、プライマリ・データベースを停止するかどうかを制御します。FastStartFailoverPmyShutdownのデフォルト値はTRUEです。
注意:
ユーザーによる構成可能な条件が検出された場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーが開始された場合、プライマリ・データベースは常に停止します。
FastStartFailoverLagLimit
ファスト・スタート・フェイルオーバー機能は、最大パフォーマンス・モードで動作するデータベースで構成できます。ASYNCモードでREDOを受け取る宛先は、許容可能なファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースであり、これらの宛先はREDOの受取りおよび適用に関してプライマリより遅れる可能性があります。FastStartFailoverLagLimit構成プロパティを使用して、構成可能な時間ベースの制限を指定できます。スタンバイ・データベースでREDOが適用された時点がプライマリのREDO生成時点からこの秒数以内であれば、ファスト・スタート・フェイルオーバーが許可されます。適用時点がこの制限よりも遅れていると、ファスト・スタート・フェイルオーバーは許可されません。FastStartFailoverLagLimit構成プロパティは、構成が最大可用性モードで動作しているときに、ファスト・スタート・フェイルオーバーが有効化されている場合は使用されません。ASYNC宛先は、最大パフォーマンス・モードで動作している構成でのみ有効なファスト・スタート・フェイルオーバー・ターゲットです。保護モードを変更したり宛先をSYNCに変更する場合は、まず、ファスト・スタート・フェイルオーバーを無効化する必要があります。同様に、MAXAVAILABILITYからMAXPERFORMANCEに保護モードを変更する場合も、ファスト・スタート・フェイルオーバーを無効にしてから、REDOをプライマリとターゲット・スタンバイに送信するのに使用するREDO転送モードをASYNCに変更する必要があります。元のプライマリの回復は、ASYNCターゲット・スタンバイへのファスト・スタート・フェイルオーバー後に可能になります。オブザーバは元のプライマリを再検出すると、自動的に元のプライマリを回復し、指定されたラグ以内で生成されたすべてのREDOが失われます。
参照:
FastStartFailoverAutoReinstate
FastStartFailoverAutoReinstate構成プロパティは、プライマリ・データベースがクラッシュしたか、FastStartFailoverThresholdの秒数を超えて停止したためにファスト・スタート・フェイルオーバーが発生した場合、元のプライマリ・データベースを自動的に回復するかどうかを制御します。FastStartFailoverAutoReinstateのデフォルト値はTRUEです。
フェイルオーバーの完了後に診断または修復作業を行う場合は、FastStartFailoverAutoReinstate構成プロパティをFALSEに設定すると、自動回復を回避できます。
注意:
ユーザーによる構成可能なファスト・スタート・フェイルオーバー条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを開始した場合、元のプライマリ・データベースの自動回復は実行されません。
FastStartFailoverTarget
FastStartFailoverTarget構成プロパティは、このデータベースがプライマリ・データベースの場合、ファスト・スタート・フェイルオーバーのターゲットになるデータベースのDB_UNIQUE_NAMEを指定します。
ObserverReconnect
ObserverReconnect構成プロパティは、オブザーバがプライマリ・データベースに対して新しい接続を確立する頻度を指定します。このプロパティがデフォルト値の0に設定されている場合、オブザーバはプライマリ・データベースへの新しい接続を定期的に確立しません。これによりプライマリ・データベースに新しいオブザーバ接続を定期的に確立することによる処理オーバーヘッドがなくなる一方、オブザーバがプライマリ・データベースに新しい接続を作成できないことを検出できなくなります。このプロパティは、プライマリ・データベースの障害を適時に検出できる程度には小さいが、定期的なオブザーバ接続によるオーバーヘッドが許容できるレベルに収まる程度には大きい値に設定することをお薦めします。
ObserverOverride
ObserverOverride構成プロパティをTRUEに設定すると、スタンバイがプライマリに正常に接続していても、オブザーバのプライマリへの接続が失われた場合、自動フェイルオーバーが発生します。
デフォルトでは、構成済の時間しきい値(FastStartFailoverThreshold)の経過後にオブザーバもスタンバイもプライマリにアクセスできないと、ファスト・スタート・フェイルオーバーが実行されます。また、別の条件でファスト・スタート・フェイルオーバーを実行する必要がある場合もあります。
構成可能な条件は、データベースの健全性チェック・メカニズムによって検出されるものとOracleサーバーで発生するエラー(ORAエラーなど)によって検出されるものの2種類に分類されます。指定された条件が発生すると、オブザーバは、スタンバイがフェイルオーバーを受け入れるために適した状態であれば、FastStartFailoverThresholdを超えるまで待機せずにファスト・スタート・フェイルオーバーを開始します。
各条件は、個別に有効化または無効化できます。Oracle Data Guard構成では、ユーザー指定のすべての構成可能なファスト・スタート・フェイルオーバー条件がブローカ構成ファイルに保持されます。
プライマリ・データベースが有効な健全性チェック条件のいずれかを示すと、オブザーバによって検出され、スタンバイがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)ただちにファスト・スタート・フェイルオーバーが開始されます。
Oracle ORAエラー条件が指定されている場合、エラーが示されるとプライマリ・データベースがオブザーバに通知し、オブザーバは、スタンバイがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)ただちにファスト・スタート・フェイルオーバーを開始します。
注意:
プライマリ・データベースは停止し、オブザーバは元のプライマリ・データベースの自動回復を試行しません。
参照:
Cloud Controlオンライン・ヘルプ
DBMS_DG PL/SQLパッケージを使用して、特定の条件が満たされたときにアプリケーションによりファスト・スタート・フェイルオーバーを指示することができます。「アプリケーションによるファスト・スタート・フェイルオーバーの指示」を参照してください。
DGMGRLのCONVERT DATABASEコマンドを使用すると、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換できます。スナップショット・スタンバイ・データベースは完全に更新可能なスタンバイ・データベースです。
フィジカルまたはロジカル・スタンバイ・データベースと同様に、スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信し、アーカイブします。ただし、フィジカルまたはロジカル・スタンバイ・データベースとは異なり、スナップショット・スタンバイ・データベースは、受信したREDOデータを適用しません。スナップショット・スタンバイ・データベースが受信したREDOデータは、スナップショット・スタンバイが元のフィジカル・スタンバイ・データベースに変換され、スナップショット・スタンバイ・データベースに対するすべてのローカルな更新が破棄された後に適用されます。
フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換するには、フラッシュバック・データベースを有効にする必要があります。次の例に、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換する方法を示します。
DGMGRL> CONVERT DATABASE 'South_Sales' TO SNAPSHOT STANDBY;
スナップショットを元のフィジカル・スタンバイに戻すときは、次に示すように、DGMGRLのCONVERT DATABASEコマンドを使用します。
DGMGRL> CONVERT DATABASE 'South_Sales' TO PHYSICAL STANDBY;
データベースのステータスは、データベースの健全性を示します。通常、ブローカは、実際のデータベースの状態と設定がブローカ構成ファイル内の記述と一致するかどうかを検証し、データベースの健全性をチェックします。そのためには、Oracle Data Guard構成のコンポーネントで正常に機能していないものがないかどうか(REDO転送サービスにエラーがないかどうかなど)、その他の必須のデータベースの設定が正しく行われているかどうか(サーバー・パラメータ・ファイルが使用可能かどうか、ARCHIVELOGモードがオンになっているかどうかなど)をチェックします。ここでは、ブローカによりプライマリ・データベース上とスタンバイ・データベース上でチェックされる項目を詳しく説明します。
プライマリ・データベースの健全性チェックでは、次の条件が満たされているかどうかを判別します。
データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。
データベースが正しいデータ保護モードであるかどうか。
データベースでサーバー・パラメータ・ファイルが使用されているかどうか。
データベースがARCHIVELOGモードであるかどうか。
データベース・ガードがオフになっているかどうか。
補助ロギングがオンになっているかどうか(構成にロジカル・スタンバイ・データベースが含まれている場合)。
REDO転送サービスにエラーがあるかどうか。
データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。
REDO転送設定が、スタンバイ・データベースのREDO転送関連プロパティで指定された設定と一致しているかどうか。
現行のデータ保護レベルが構成済のデータ保護モードと一致しているかどうか。
プライマリ・データベースで、すべてのスタンバイ・データベースのすべてのギャップを解決できるかどうか。
スタンバイ・データベースの健全性チェックでは、次の条件が満たされているかどうかを判別します。
データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。
データベースでサーバー・パラメータ・ファイルが使用されているかどうか。
データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。
データベース・ガードがオンになっているかどうか(データベースがロジカル・スタンバイ・データベースの場合)。
ファスト・スタート・フェイルオーバーが有効化されている場合は、プライマリ・データベースおよびターゲット・スタンバイ・データベースが同期化されているかどうか、またはラグ制限内であるかどうか。
ステータスの問合せには、次の監視可能なデータベース・プロパティを使用できます。
LogXptStatus
InconsistentProperties
InconsistentLogXptProps
注意:
これらのプロパティには、DGMGRLコマンドライン・インタフェースを介して直接アクセスします。Cloud Controlでは、GUIで表示するためにこれらのプロパティの値が並べ替えられます。
SHOW DATABASE <db_unique_name>コマンドを使用して、データベースの簡単な説明(名前、ロールなど)、データベースの状態、および健全性チェックの問題に関する情報を入手できます。たとえば、次のSHOW DATABASEコマンドの出力は、一部のREDO転送サービス・エラーおよびREDO転送関連プロパティの不一致という2つの問題を示しています。
DGMGRL> SHOW DATABASE 'North_Sales';
Database - North_Sales
Role: PRIMARY
Intended State: TRANSPORT-OFF
Instance(s):
north_sales1
Error: ORA-16737: the redo transport service for standby
database "South_Sales" has an error
north_sales2
Error: ORA-16737: the redo transport service for standby
database "South_Sales" has an error
Warning: ORA-16715: redo transport-related property
ReopenSecs of standby "South_Sales" is inconsistent
Database Status:
ERROR
データベース・ステータスの詳細をさらにチェックするには、監視可能なプロパティLogXptStatus、InconsistentPropertiesおよびInconsistentLogXptPropsを使用できます。LogXptStatusを使用すると、プライマリ・データベースの全インスタンス上で検出されたログ転送エラーがすべて表示されます。InconsistentPropertiesを使用すると、ブローカ構成ファイルとデータベース設定間で値が一致しないプロパティがすべて表示されます。InconsistentLogXptPropsを使用すると、ブローカ構成ファイルとREDO転送設定間で値が一致しない、スタンバイ・データベースのREDO転送関連プロパティがすべて表示されます。
次のSHOW DATABASEコマンドを発行して、問題の詳細を取得します。
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
north_sales2 South_Sales ORA-12541: TNS:no listener
DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';
INCONSISTENT LOG TRANSPORT PROPERTIES
INSTANCE_NAME STANDBY_NAME PROPERTY_NAME MEMORY_VALUE BROKER_VALUE
north_sales2 South_Sales ReopenSecs 600 300
参照:
データベース・プロパティの詳細は、「Oracle Data Guard Brokerのプロパティ」を参照
VALIDATE DATABASEコマンドを使用して、ロール変更を実行する前に包括的なデータベース・チェックを実行できます。このコマンドは、次の項目を確認します。
スタンバイ・データベースに、失われたREDOデータがあるかどうか
フラッシュバックが有効かどうか
構成されている一時表領域ファイルの数
オンライン・データ・ファイルの移動が進行中かどうか
フィジカル・スタンバイ・データベースの場合、オンラインREDOログがクリアされているかどうか
プライマリ・データベースの場合、スタンバイREDOログがクリアされているかどうか
オンライン・ログ・ファイル構成
スタンバイ・ログ・ファイル構成
適用関連のプロパティ設定
転送関連のプロパティ設定
自動診断リポジトリにエラーがあるかどうか(制御ファイルの破損、システム・データ・ファイルの問題、ユーザー・データ・ファイルの問題など)
参照:
コマンドの説明や様々な使用例のコマンド出力の例示は、「VALIDATE DATABASE」を参照してください
