| Oracle® Data Guard Broker 11gリリース2 (11.2) B56304-09 |
|
 前 |
 次 |
この章では、データベースに関係のある状態およびプロパティの管理について説明します。この章の内容は、次のとおりです。
データベース・オブジェクトは、ブローカにより管理されます。データベース・オブジェクトは、プライマリまたはスタンバイのデータベース・インスタンスに対応します。ブローカでは、各オブジェクトのプロファイルを使用して単一データベースの状態が管理および監視されます。
ブローカでは、フィジカル、スナップショットおよびロジカルの各スタンバイ・データベースが区別されます。これらのデータベースは、それぞれのスタンバイ・タイプに適した状態とプロパティを記述するプロファイルを使用して構成されます。
構成が有効化されている場合、構成内のデータベースの状態は、REDOデータの転送中またはREDOデータの適用中など、Data Guardの動作を指示するいずれかの状態になります。表4-1に、様々なデータベースの状態を示します。
スナップショット・スタンバイ・データベースは、状態を持たず、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.
次の各項では、プライマリ・データベースおよびスタンバイ・データベースにおいて考えられる状態遷移について詳細に説明します。
プライマリ・データベースをTRANSPORT-ON状態に遷移する際に、ブローカはスタンバイ・データベースのREDO転送関連プロパティを使用して、すべての管理対象スタンバイ・データベースへのREDO転送サービスを設定します(すべてのREDO関連プロパティのリストは、4.4項を参照してください)。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転送サービスを構成します。
フィジカル・スタンバイ・データベースをAPPLY-ON状態に遷移する際に、ブローカはREDO Apply関連プロパティで指定されたオプションを使用してREDO Applyを起動します(プロパティ・リストについては4.5項を参照してください)。スタンバイ・データベースが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で記録された開始オプションと一致しないモードで開始される可能性があります。 |
スナップショット・スタンバイ・データベースの状態遷移
スナップショット・スタンバイ・データベースには状態がありません。REDOデータを受信するのみです。
ロジカル・スタンバイ・データベースがAPPLY-ON状態に遷移すると、ブローカは、データベースがオープンされるまで待機し、データベース・ガードを有効化してロジカル・スタンバイ・データベース内の表への変更を防ぎ、ログ適用関連プロパティで指定されたオプションを使用してSQL Applyを起動します。ロジカル・スタンバイ・データベースがOracle RACデータベースの場合、ブローカは単一のスタンバイ・インスタンス(適用インスタンス)でSQL Applyを起動します。
APPLY-OFF状態に遷移すると、ブローカはSQL Applyを停止します。
データベース・プロパティには、監視可能なタイプと構成可能なタイプがあります。どちらのタイプのプロパティも、データベース単位の有効範囲を持つプロパティとインスタンス固有の有効範囲を持つプロパティとしてさらに分類できます。
監視可能なプロパティの値は、関連データベース・オブジェクトが有効である場合にのみ表示できます。
監視可能なプロパティを使用するとデータベース・オブジェクト関連のランタイム情報を表示できますが、このタイプのプロパティの値は変更できません。
構成可能なプロパティは、ブローカの操作や構成に影響を与えます。このタイプのプロパティの値は、DGMGRLまたはEnterprise Managerを使用して変更できます。プロパティは、構成とそのデータベースが有効か無効かに関係なく編集できます。ただし、データベースが無効化されている場合は、該当する構成またはデータベースを有効にするまで、新しいプロパティ値は有効になりません。
これらのプロパティを表示するには、DGMGRLのSHOWコマンドまたはEnterprise Managerの「プロパティの編集」ページを使用します。例4-1では、SHOW DATABASE VERBOSEコマンドを使用して、North_Salesデータベースに関する情報を表示しています。
例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 = 'sync'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '5'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = 'dbs/bt, dbs/t'
LogFileNameConvert = 'dbs/bt, dbs/t'
FastStartFailoverTarget = 'South_Sales'
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'north_sales1'
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'
LatestLog = '(monitor)'
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
Enterprise Managerでは、これらのプロパティの情報は「プロパティの編集」ページに表示されます。
構成可能なデータベース・プロパティは、データベースの操作や構成に影響を与えます。DGMGRLまたはEnterprise Managerを使用して、新規ブローカ構成に、プライマリ・データベース・オブジェクトを作成したり既存のスタンバイ・データベースをインポートすると、最初にプロパティ値がデータベース設定からインポートされます。
多くのプロパティ値は、データベースが無効の場合でも有効の場合でも更新できます。構成に新規データベースを追加すると、ブローカはそのデータベースに接続し、現行のデータベース設定からデータベース・プロパティの初期値をインポートします。次に例を示します。
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)内のデータベース・パラメータの値は、ブローカ構成ファイル内およびサーバー・パラメータ・ファイル内の値と一時的に異なる場合があります。通常、データベースの値は、次回データベース・インスタンスの停止と再起動が行われたときに、サーバー・パラメータ・ファイルの値およびブローカ構成ファイルの値と同じになります。
データベース・プロパティの値は、構成が無効の場合でもブローカを使用して更新できます。ブローカはプロパティの設定を(値を検証せずに)保持し、次回ブローカ構成が有効化されたときに、サーバー・パラメータ・ファイル内のデータベース初期化パラメータおよびメモリー内の設定を更新します。
|
注意: プロパティの値は構成が無効な場合にも変更できますが、変更結果は構成が有効化されるまでデータベースに対して有効になりません。また、一部のプロパティ値は無効な状態でのみ変更可能なことに注意してください。 |
REDO転送サービスを管理するには、各スタンバイ・データベースに、次の構成可能なデータベース・プロパティ・セットを指定します。
DGConnectIdentifier
AlternateLocation
Binding
LogShipping
LogXptMode
MaxConnections
MaxFailure
NetTimeout
RedoCompression
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プロパティの初期値は、ADD DATABASEコマンドに指定したデータベースのDB_UNIQUE_NAMEと一致するDB_UNIQUE_NAME属性を持つLOG_ARCHIVE_DEST_n初期化パラメータのSERVICE属性から抽出されます。
DGConnectIdentifierプロパティの値は、FAL_SERVER初期化パラメータの設定にも使用されます。いずれかのデータベースのDGConnectIdentifierプロパティが変更されると、対応するLOG_ARCHIVE_DEST_n初期化パラメータのSERVICE属性も変更されます。また、構成内で有効化されたすべてのスタンバイ・データベースで、FAL_SERVER初期化パラメータが更新されます。
ブローカによるデータ保護モードの処理方法については、4.6項で説明します。構成全体の保護モードの一部として、REDO転送サービスも、選択したデータ保護モードに対して正しく設定されていることを確認する必要があります。
REDO転送サービスにSYNCまたはASYNCモードを設定するには、データベース・プロパティLogXptModeを使用します。保護モードとREDO転送サービスの詳細は、表4-2を参照してください。
次に、LogXptModeプロパティの値について説明します。
このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのSYNCおよびAFFIRM属性を使用して構成します。このモードとスタンバイREDOログ・ファイルは、最大保護モードまたは最大可用性モードのいずれかで動作している構成に必要です。このREDO転送サービスでは、プライマリ・データベースに対して最高レベルのデータ保護が可能ですが、パフォーマンスへの影響も大きくなる可能性があります。
このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのASYNCおよびNOAFFIRM属性を使用して構成します。このモードとスタンバイREDOログ・ファイルでは、プライマリ・データベースに対して適度なレベルのデータ保護が可能になり、パフォーマンスへの影響も小さくなります。
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プロパティにより決定されます。
スタンバイ・データベースのログ適用サービスに使用されるアーカイブREDOログ・ファイルの格納場所をスタンバイ・データベース上に設定できます。そのためには、スタンバイ・データベース上でデータベース・プロパティStandbyArchiveLocationおよびAlternateLocationを設定します。
StandbyArchiveLocationでは、アーカイブREDOログ・ファイルが格納されるスタンバイ位置を指定します。ブローカが管理するのは、プライマリ・データベースから受け取ったアーカイブREDOログ・ファイルの格納場所のみです。データベースがプライマリ・データベースまたはロジカル・スタンバイ・データベースの場合、ローカルに生成されるアーカイブREDOログ・ファイルについては、LOG_ARCHIVE_DEST_n初期化パラメータを介して直接ローカルのアーカイブ先を設定する必要があります。ブローカでは、StandbyArchiveLocationの値をローカルに生成されるログ用に設定したのと同じ位置に設定できます。この場合、ブローカによりアーカイブ先のVALID_FOR属性が適切に設定されるため、プライマリ・データベースから受け取るアーカイブREDOログ・ファイルとローカルに生成されるアーカイブREDOログ・ファイルの両方に同じ位置を使用できます。
|
注意: データベース・リカバリ領域を使用する場合を除き、ロジカル・スタンバイ・データベースでは、ローカルの格納先を示すLOG_ARCHIVE_DEST_初期化パラメータの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初期化パラメータの属性に対応します。
新規スタンバイ・データベースの作成時に、ブローカはこれらのプロパティをデフォルト値に設定します。既存のスタンバイ・データベースのインポート時には、現行の宛先のサービス文字列と、構成にデータベースを追加したときに指定した接続識別子との間で一致が見つかった場合、ブローカはこれらのプロパティに対応する既存の設定をインポートします。一致が見つからなかった場合は、現行の宛先のdb_unique_nameと、構成にデータベースを追加したときに指定した名前との間で一致を探します。
ほとんどの場合、通常の操作にはデフォルト値またはインポートされる値で十分です。なんらかの理由でこれらのプロパティ値を変更する必要がある場合は、DGMGRLコマンドラインを使用して各プロパティを設定できます。Enterprise Managerでは、これらの各プロパティを変更するためのインタフェースを提供していません。
プライマリ・データベースがOracle RACデータベースの場合、ブローカは各プライマリ・データベース・インスタンス上のREDO転送サービスが同一に設定されていることを確認します。各インスタンスのリモート接続先は同じで、すべてのインスタンスで、各リモート接続先には同じREDO転送サービス、パフォーマンス関連設定などが設定されます。インスタンスの設定が異なる場合、ブローカはそのインスタンスに関して健全性チェックの警告を発行します。
REDO転送サービスに関連する設定は、ブローカ構成ファイルにプロパティとして保存されます。スタンバイ・データベース上のREDO転送関連のプロパティを更新すると、すべてのプライマリ・データベース・インスタンス上のLOG_ARCHIVE_DEST_n初期化パラメータに対しても、ブローカによって自動的に対応する変更が実行されます。プライマリ・データベース上で新規インスタンスが作成されると、ブローカは現在管理している全スタンバイ・データベースのREDO転送関連プロパティを使用して、新規インスタンス用のREDO転送サービスを設定します。新規インスタンスがアクティビティ用にオープンされた後、このインスタンス上で生成された全アーカイブREDOログ・ファイルについて、スタンバイ・データベースへの転送が開始されます。
|
参照: LOG_ARCHIVE_DEST_n初期化パラメータの詳細は、 |
転送ラグは、スタンバイ・データベースへのREDOの転送がプライマリ・データベースでのREDOの生成からどの程度遅れているかを測定する尺度です。
スタンバイ・データベースで1つ以上のREDOギャップがある場合は、最初のREDOギャップの発生後にREDOは受信されなかったものとして、転送ラグが計算されます。
Enterprise ManagerとDGMGRLクライアントでは、管理対象スタンバイ・データベースごとにREDO転送ラグが表示されます。Enterprise Managerでは、Data Guardのホームページに転送ラグが表示されます。DGMGRLクライアントでは、スタンバイ・データベースのSHOW DATABASE出力に転送ラグが表示されます。プライマリ・データベースに対する転送ラグは表示されません。次に例を示します。
DGMGRL> show database 'South_Sales';
Database - South_Sales
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: OFF
Instance(s):
south_sales1
Database Status:
SUCCESS
転送ラグにより、REDO転送サービスで発生する可能性のある問題を識別することができます。
次に示すログ適用に関連するデータベース・プロパティを使用して、フィジカルまたはロジカル・スタンバイ・データベース上のREDO ApplyおよびSQL Applyを管理できます。
REDO ApplyおよびSQL Applyに共通のプロパティ
ApplyInstanceTimeout
DelayMins
PreferredApplyInstance
REDO Applyに固有のプロパティ
ApplyParallel
SQL Applyに固有のプロパティ
LsbyASkipTxnCfgPr
LsbyDSkipTxnCfgPr
LsbyASkipCfgPr
LsbyDSkipCfgPr
LsbyASkipErrorCfgPr
LsbyDSkipErrorCfgPr
LsbyMaxEventsRecorded
LsbyPreserveCommitOrder
LsbyRecordSkipErrors
LsbyRecordSkipDdl
LsbyRecordAppliedDdl
LsbyMaxSga
LsbyMaxServers
現在のデータベースの状態がAPPLY-ONの場合、SQL Apply関連のプロパティを変更すると、SQL Applyの再起動が必要になる場合があります。SQL Applyの再起動が必要なプロパティを調べるには、第8章の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は、Enterprise Managerの「プロパティの編集」ページには表示されません。 |
SQL Applyに使用可能なSGAメモリーの量を制御できます。この設定には、データベース・プロパティLsbyMaxSgaを使用します。
SQL Applyで使用されるパラレル問合せサーバーの数を制御するには、データベース・プロパティLsbyMaxServersを使用します。
ユーザーは、SQL Applyのパフォーマンスとトランザクションのコミット順序との間のトレード・オフを制御できます。データベース・プロパティLsbyPreserveCommitOrderは、プライマリ・データベースでコミットされた順序と同じ順序でトランザクションがロジカル・スタンバイ・データベースにコミットされるかどうかを制御します。コミット順序を保持すると、パフォーマンスに影響する場合があります。
ロジカル・スタンバイ・データベースの利点の1つは、何を適用して何を適用しないかを制御できることです。そのためにはSQL Applyフィルタを設定します。フィルタの粒度は、データベース・オブジェクトに対する特定のトランザクション、特定のスキーマ上の特定クラスのSQL文などです。
Data Guard BrokerにSQL Applyフィルタを追加するには、データベース・プロパティLsbyASkip*(LsbyASkipTxnCfgPrまたはLsbyASkipCfgPrなど)を使用します。前に追加したSQL Applyフィルタを削除するには、データベース・プロパティLsbyDSkip*(LsbyDSkipTxnCfgPrまたはLsbyDSkipCfgPrなど)を使用します。
SQL Applyを微調整して、特定のスキーマの指定のSQL文セットに関する適用エラーを処理できます。この種のSQL Applyエラーが発生した場合、Data GuardではエラーをスキップしてSQL Applyを続行するか、またはエラー発生時に指定のストアド・プロシージャをコールできます。
このエラー処理機能を追加するには、データベース・プロパティLsbyASkipErrorCfgPrを使用します。前に追加したエラー処理指定を削除するには、データベース・プロパティLsbyDSkipErrorCfgPrを使用します。
データベースの現在の状態がAPPLY-ONの場合は、これらのプロパティを変更するとSQL Applyが再起動されます。データベースの現在の状態がAPPLY-OFFの場合、プロパティ変更はデータベースの状態が次回にAPPLY-ONに変化したときに有効になります。
DBA_LOGSTDBY_EVENTS表は、SQL Applyに影響する重要なイベントを記録します。この表に記録されるイベント・セットのうち、どのイベントが重要であるかはロジカル・スタンバイ・データベースごとに異なるため、Data Guardにはイベント記録を制御する手段が用意されています。Data Guard Brokerから、データベース・プロパティLsbyRecord*(LsbyRecordSkipDdlまたはLsbyRecordSkipErrorsなど)を使用して、特定のイベント・セットの記録を制御できます。これらのプロパティの値は、イベント記録のオンまたはオフを示すTRUEまたはFALSEです。
スタンバイ・データベースがOracle RACデータベースの場合、ログ適用サービスが実行されるOracle RACデータベース・インスタンスは常に1つのみです。このインスタンスを適用インスタンスと呼びます。適用インスタンスに障害が発生すると、ブローカはログ適用サービスを自動的に異なるインスタンスに移動します。これを適用インスタンスのフェイルオーバーと呼びます。
|
注意: この項の情報は、スナップショット・スタンバイ・データベースには適用されません。 |
Oracle RACスタンバイ・データベースでどのインスタンスを適用インスタンスにしてもよい場合、ブローカが適用インスタンスを任意に選択します。特定のインスタンスを適用インスタンスとして選択するには、次の2つの方法があります。
第1の方法では、適用インスタンスをOracle RACスタンバイ・データベースで実行される前に選択します。そのためには、データベース・プロパティPreferredApplyInstanceの値を、適用インスタンスとして指定するインスタンスの名前(SidNameプロパティを参照)に設定します。ブローカは、Oracle RACスタンバイ・データベースで適用インスタンスが選択されていない場合に、PreferredApplyInstanceプロパティで指定されたインスタンス上でログ適用サービスを起動します。この方法を使用するのは、スタンバイ・データベースをまだ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
Apply Lag: 0 seconds
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
Apply Lag: 0 seconds
Real Time Query: OFF
Instance(s):
south_sales1
south_sales2 (apply instance)
Database Status:
SUCCESS
コマンドの発行時には、新規適用インスタンスが実行中であることを確認してください。それ以外の場合は、適用インスタンスが変更されません。
適用インスタンスの選択後、ブローカは適用インスタンス情報をブローカ構成ファイルに保存します。これにより、スタンバイ・データベースが停止されて再起動されても、ブローカは停止前と同じインスタンスを選択してログ適用サービスを起動できます。適用インスタンスは、ユーザーが変更するか、なんらかの原因で障害が発生してブローカが適用インスタンスのフェイルオーバーを実行すると決定するまで変更されません。
適用インスタンスの障害に対するフォルト・トレラントを持たせるために、ブローカはログ適用サービスを異なるスタンバイ・インスタンスに自動的にフェイルオーバーすることで、Oracle RACスタンバイ・データベースの可用性を利用します。ブローカが提供する適用インスタンスのフェイルオーバー機能により、データ保護が強化されます。
適用インスタンスのフェイルオーバーを設定するには、データベース・プロパティApplyInstanceTimeoutを設定してブローカの待機時間を指定します。この待機時間は、適用インスタンス障害を検出してから適用インスタンスのフェイルオーバーを開始するまでの期間です。適切なタイムアウト値を選択するには、次のことを考慮する必要があります。
クラスタに、障害が発生した適用インスタンスのリカバリを試みる他のメカニズムがあるかどうか。
ビジネスで、REDOデータがスタンバイ・データベースに適用されないことを容認できる時間。
ログ適用サービスを他のインスタンスに移動する操作に関連するオーバーヘッド。オーバーヘッドには、障害の発生した適用インスタンス上に累積されていて未適用のログ・ファイルすべてが、他のスタンバイ・インスタンスからアクセスできる共有ファイル・システムに保存されていない場合に、それをプライマリ・データベースから再転送する操作が含まれる場合があります。
ブローカのApplyInstanceTimeoutプロパティのデフォルト値は0秒です。これは、現在の適用インスタンスの障害検出後ただちに、適用インスタンスのフェイルオーバーが開始されることを示しています。
ブローカでは、適用インスタンスのフェイルオーバー開始後に、次のルールに従って新規の適用インスタンスが選択されます。PreferredApplyInstanceプロパティが現在実行中のインスタンスを示している場合は、それが新規の適用インスタンスとして選択されます。それ以外の場合は、現在実行中の任意のインスタンスが新規の適用インスタンスとして選択されます。
また、適用インスタンスの障害発生時にフィジカル・スタンバイ・データベースがリアルタイム問合せモードで動作していた場合、Oracleリカバリ・クリーンアップの完了後、自動的にクローズされたインスタンスはすべてブローカによってオープンされます。障害の発生した適用インスタンスが唯一のオープン・インスタンスであった場合、リアルタイム問合せを再度有効にするため、適用サービスを開始する前に、新しい適用インスタンスとして選択されたインスタンスがオープンされます。
|
参照:
|
適用ラグは、REDOのスタンバイ・データベースへの伝播および適用の遅延により、スタンバイ・データベースのデータがプライマリ・データベースのデータからどの程度遅れているかを測定する尺度です。
Enterprise ManagerとDGMGRLクライアントでは、管理対象スタンバイ・データベースごとに適用ラグが表示されます。Enterprise Managerでは、Data Guardのホームページに適用ラグが表示されます。DGMGRLクライアントでは、スタンバイ・データベースのSHOW DATABASE出力に適用ラグが表示されます。プライマリ・データベースに対する適用ラグは表示されません。次に例を示します。
DGMGRL> show database 'South_Sales';
Database - South_Sales
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: OFF
Instance(s):
south_sales1
Database Status:
SUCCESS
適用ラグでは、REDO転送サービスとログ適用サービスで発生する可能性のある問題を識別することができます。
ブローカによって、様々なレベルのデータ保護(最大保護、最大可用性、最大パフォーマンス)に対する構成の設定処理を簡素化できます。
この項では、構成の適切な保護に役立つ項目について説明します。
各データ保護モードでは、データ保護、データ可用性およびデータベース・パフォーマンスが様々なバランスで提供されます。ビジネス・ニーズに合うデータ保護モードを選択するには、データ保護の要件とユーザーが要求するパフォーマンスを慎重に考慮します。
|
注意: 構成内の唯一のスタンバイ・データベースがスナップショット・スタンバイの場合、最大保護モードと最大可用性モードは使用できません。 |
最大可用性: この保護モードは、プライマリ・データベースの可用性を低下させずに、可能なかぎり高いレベルのデータ保護を提供します。トランザクションのリカバリに必要なすべてのREDOデータがオンラインREDOログと1つ以上の同期スタンバイ・データベース上のスタンバイREDOログに書き込まれるまで、トランザクションはコミットされません。1つ以上の同期スタンバイ・データベースにREDOストリームを書き込めない場合、プライマリ・データベースは最大パフォーマンス・モードの場合と同様に動作して、同期スタンバイ・データベースへのREDOストリームの書込みが再び可能になるまでプライマリ・データベースの可用性を維持します。
このモードでは、プライマリ・データベースの障害発生時に、第2の障害が発生してもプライマリ・データベースから1つ以上のスタンバイ・データベースにREDOデータの完全なセットを送信できるときにのみ、データが消失しないことが保証されます。
保護モードが最大可用性の場合、ファスト・スタート・フェイルオーバーを有効化できます。
最大パフォーマンス: この保護モードは、プライマリ・データベースのパフォーマンスへの影響なしに、可能なかぎり高いレベルのデータ保護を提供します。これを実現するため、トランザクションで生成されたすべてのREDOデータがオンライン・ログに書き込まれると、トランザクションをすぐにコミットできます。REDOデータは1つ以上のスタンバイ・データベースにも書き込まれますが、この書込みはトランザクションのコミットとは非同期に実行されるため、スタンバイ・データベースへのREDOデータの書込みの遅延は、プライマリ・データベースのパフォーマンスに影響を与えません。
最大可用性モードと比較して、この保護モードではデータ保護が若干弱くなり、プライマリ・データベースのパフォーマンスへの影響を最小限に抑えます。
これはデフォルトの保護モードです。
保護モードが最大パフォーマンスの場合、ファスト・スタート・フェイルオーバーを有効化できます。
最大保護: この保護モードでは、プライマリ・データベースの障害時にもデータの消失が発生しないことが保証されます。この保護レベルを提供するには、トランザクションのコミット前に、トランザクションのリカバリに必要なREDOデータを、オンラインREDOログと1つ以上の同期スタンバイ・データベース上のスタンバイREDOログに書き込む必要があります。データの消失が起こり得ないようにするため、1つ以上の同期スタンバイ・データベースにREDOストリームを書き込めない場合、プライマリ・データベースは停止し、トランザクション処理を継続しません。
Data GuardがREDOデータをスタンバイREDOログ・ファイルの永久記憶域に書き込むとすぐに、プライマリのトランザクションは保護されたものとみなされます。その後すぐにプライマリ・データベースに確認通知を戻し、次のトランザクションに進めるようにします。これによって、プライマリ・データベースでの同期転送スループットやレスポンス時間による影響を最小化できます。スタンバイ・データベースでの完全なData Guardの検証機能を最大限活用するには、必ずリアルタイムの適用モードで操作し、REDOの変更を受信と同時にスタンバイ・データベースに適用します。Data Guardは検出したすべての破損を通知するので、迅速な修正処理を実行できます。
このデータ保護モードでは、プライマリ・データベースの可用性よりもデータ保護を優先するため、単一のスタンバイ・データベースの障害によってプライマリ・データベースが停止しないように、少なくとも2つのスタンバイ・データベースを使用して最大保護モードで実行するプライマリ・データベースを保護することをお薦めします。1つのスタンバイ・データベースのみが最大保護モードをサポートしている場合、Data Guard Brokerは適用インスタンスのシャットダウンを禁止します。これによりプライマリ・データベースはシャットダウンされなくなります。
保護モードが最大保護の場合、ファスト・スタート・フェイルオーバーを有効化できません。
使用している保護モードに関係なく、スタンバイREDOログ・ファイルをすべてのスタンバイ・データベースに追加する必要があります。また、スイッチオーバーやフェイルオーバーに備えてプライマリ・データベース上にもスタンバイREDOログ・ファイルを追加する必要があります。ファスト・スタート・フェイルオーバーを有効にする場合は、プライマリ・データベース上にスタンバイREDOログ・ファイルが必要です。
Enterprise Managerでは、構成内の1つ以上のスタンバイ・データベースを選択するように要求され、将来のロール変更に備えて、スタンバイ・データベースおよびプライマリ・データベース上にスタンバイREDOログ(SRL)ファイルが設定されます。
データ保護モードで、いずれかのスタンバイ・データベースが使用するREDO転送サービスを変更する必要がある場合は、各スタンバイ・データベースでデータベース・プロパティLogXptModeの設定を適切に変更してください。REDO転送サービスの設定の詳細は、4.4項を参照してください。表4-2では、保護モードおよび対応するREDO転送サービスを示します。
Enterprise Managerでは自動的に、将来のスイッチオーバーに備えて、プライマリ・データベース上に適切なREDO転送サービスが設定されます。
DGMGRLコマンドまたはEnterprise Managerを使用した保護モードの設定
DGMGRLを使用する場合
EDIT DATABASE(プロパティ)コマンドを使用して、設定する保護モードに対応するようにREDO転送サービスを変更する必要のあるスタンバイ・データベースを指定します。たとえば、Data Guard構成全体を最大可用性モードで動作するように設定する場合は、EDIT DATABASEコマンドを使用して、REDO転送サービスに対してSYNCモードを設定する必要があります。次に例を示します。
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'LogXptMode'='SYNC';
この確認を構成内のプライマリ・データベースまたは他のスタンバイ・データベースについても行い、選択した保護モードをスイッチオーバー後もサポートできることを確認します。
EDIT CONFIGURATION SET PROTECTION MODE AS protection-modeコマンドを使用して、構成全体の保護モードを設定します。次に例を示します。
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
保護モードの設定方法を示すDGMGRLの使用例については、6.5項を参照してください。
Enterprise Managerを使用する場合
Data Guardの概要ページで、「保護モード」ラベルの右にあるリンクをクリックします。
「最大保護」、「最大可用性」または「最大パフォーマンス」を選択して「続行」をクリックします。
プロンプトが表示される場合は、SYSDBA権限でデータベースにログインして「ログイン」をクリックします。
選択した保護モードをサポートする1つ以上のスタンバイ・データベースを選択します。スタンバイREDOログ・ファイルが必要な場合は、ログ・ファイル名を確認します。「OK」をクリックします。
「確認」ページで「はい」をクリックします。
最大保護モードにアップグレードする場合、DGMGRLまたはEnterprise Managerを使用して保護モードを最大パフォーマンス・モードから最大保護モードにアップグレードすると、プライマリ・データベースは自動的に再起動されます。保護モードをダウングレードした後でプライマリ・データベースを再起動する必要はありません。
保護モードを最大パフォーマンスから最大可用性に、または最大可用性から最大保護にアップグレードする場合、再起動は不要です。
|
注意: 最大パフォーマンス・モードから最大保護モードにアップグレードする際、まず最大可用性モードにアップグレードすることで、プライマリ・データベースの再起動を回避できます。最大可用性モードにしたら、次に最大保護モードにアップグレードします。 |
|
注意: Oracle RAC One Nodeのオンライン・データベース再配置は、最大保護モードをサポートするフィジカル・スタンバイ・データベースのみで実行することはできません。オンライン・データベース再配置を実行する必要がある場合、まず、保護モードを最大可用性にダウングレードします。フィジカル・スタンバイ・データベースのオンライン・データベース再配置を実行した後で、保護モードを最大保護にアップグレードすることができます。プライマリ・データベースの再起動は必要ありません。 |
この項では、スイッチオーバー、フェイルオーバー、Data Guard構成の無効化または有効化などの操作が、構成の保護モードやREDO転送サービスに与える影響について説明します。この項の内容は、次のとおりです。
現在のData Guard保護モードを最大可用性モードにアップグレードする場合または現在のData Guard保護モードをダウングレードする場合、再起動は不要です。Data Guard保護モードのアップグレード時またはダウングレード時には、次の推奨事項に従ってください。
保護モードをアップグレードするときは、全体の保護モードをアップグレードする前にREDO転送サービスをアップグレードします。保護モードの変更時やスタンバイ・データベースのREDO転送サービスのリセット時に、ブローカは、必要なレベルの保護をサポートできるスタンバイ・データベースが構成内に少なくとも1つ存在していることを確認します。この条件が満たされない場合、保護モードは変更されず、エラーが戻されます。
保護モードをダウングレードするときは、最初に保護モードをダウングレードしてから、REDO転送サービスを変更します(必要な場合)。REDO転送サービスの変更によって現在の全体の保護モードが無効になる場合、ブローカはREDO転送サービスの変更を許可しません。
保護モードを最大パフォーマンス・モードからアップグレードする場合、ブローカは、少なくとも1つのスタンバイ・データベースのデータベース・プロパティLogXptModeがSYNCに設定されていることを確認します。また、最大保護モードへのアップグレードの場合、ブローカは、スタンバイ・データベースのREDOデータにギャップがないことを確認します。これらの要件を満たすスタンバイ・データベースが構成内に存在していない場合、保護モードのアップグレード要求はエラーとなり拒否されます。
ファスト・スタート・フェイルオーバーが有効化されても、保護モードは変更されません。
|
警告: 保護モードを最大パフォーマンスから最大保護にアップグレードすると、プライマリ・データベースは、停止され再起動されます。まず最大可用性にアップグレードすると、この動作を回避できます。最大可用性モードにしたら、次に最大保護モードにアップグレードします。 |
スイッチオーバーでは、全体のData Guard保護モードは変更されません。保護モードはスイッチオーバー前と同じです。
スイッチオーバーの完了後に現在の保護モードをサポートするために、適切に構成されているスタンバイ・データベースが必要です。これは、構成内の他のスタンバイ・データベースでも、スイッチオーバー完了後にスタンバイ・データベースとなる現行のプライマリ・データベースでもかまいません。
必要な場合は、スイッチオーバーを起動する前に、現行のプライマリ・データベース上または構成内の他のスタンバイ・データベース上に、スタンバイREDOログ・ファイルを追加して、REDO転送サービスをData Guard保護モードのサポートに必要なSYNCまたはASYNCモードに設定できます。その後スイッチオーバーが開始されると、次の処理が実行されます。
ブローカでは、各スタンバイ・データベース上と現行のプライマリ・データベース上で、スタンバイREDOログ・ファイルが存在することとREDO転送サービスの設定が検証されます。
ブローカは、ターゲット・スタンバイ・データベースに存在するREDOデータに差分がないことを検証します。
検証が正常終了した場合は、スイッチオーバーが続行されます。正常終了しなかった場合、スイッチオーバーは失敗し、データベース・ロールとブローカ構成ファイルは変更されません。
|
警告: スイッチオーバー・ターゲットがフィジカル・スタンバイ・データベースの場合、ブローカにより、プライマリ・データベースが停止され再起動されます。 |
保護モードが最大保護だった場合、手動フェイルオーバーを実行した後に、Data Guard保護モードが最大パフォーマンス・モードにダウングレードされます。必要な場合、保護モードは後でアップグレードできます。保護モードが最大可用性または最大パフォーマンスだった場合は、変更されません。スタンバイ・データベースのREDO転送サービスは変更されません。
ファスト・スタート・フェイルオーバーが実行された場合、ブローカにより、フェイルオーバー前に有効になっていた保護モードが保持されます。
あるスタンバイ・データベースのブローカ管理を無効化すると、ブローカによって、残りのスタンバイ・データベースのいずれかが、全体の保護モードの要件を引き続き満たしているかがチェックされます。この条件が満たされない場合、無効化操作はブローカによって拒否されます。この条件が満たされる場合は、ファスト・スタート・フェイルオーバーが有効化されていないかぎり、無効化操作は続行されます。ファスト・スタート・フェイルオーバーが有効化されている場合でも、そのスタンバイ・データベースが、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースでなければ、無効化操作は続行されます。
|
注意: ブローカ構成内のスタンバイ・データベースに関してブローカによる管理を無効化すると、プライマリ・データベースが消失した場合にも、そのスタンバイ・データベースはブローカでフェイルオーバー・ターゲットとして使用できなくなります。 |
スタンバイ・データベースが正常に無効化された後は、そのデータベースのREDO転送サービスを変更できます。変更内容は、ブローカによってブローカ構成ファイルに記録されます。この変更が全体の保護モードに影響を与えることはありません。これは、有効なスタンバイ・データベースの少なくとも1つが、全体の保護モード要件をすでに満たしているためです。
ファスト・スタート・フェイルオーバーが有効化されていないかぎり、構成全体は保護モードに関係なく無効化できます。ファスト・スタート・フェイルオーバーが有効化されている場合は、構成を無効にできません。詳細は、5.5.2.2項「ファスト・スタート・フェイルオーバーが有効化されている場合の制限事項」を参照してください。
構成全体が無効な場合は、スタンバイ・データベースのREDO転送サービスや構成の保護モードなどのブローカの設定を変更できます。ブローカはブローカ構成ファイルに変更を保存しますが、データベース自体には変更は行われません。
構成全体のブローカ管理を有効化するときは、ブローカによって、有効化されるスタンバイ・データベースのREDO転送サービスが保護モードの要件を満たしているかどうかが最初にチェックされます。この条件が満たされていない場合、有効化操作は失敗し、構成は無効のままになります。条件が満たされている場合は、有効化操作によって構成が正常に有効化され、ブローカは、ブローカ構成ファイルに保存されている設定を使用してデータベースを有効化します。
ブローカ構成からスタンバイ・データベースを削除するときは、ブローカによって、保護モードの要件が満たされているかどうかがチェックされます。次の場合、操作は失敗します。
そのデータベースの削除により保護モードに影響がある場合
ファスト・スタート・フェイルオーバーが有効化されているのに、ファスト・スタート・フェイルオーバーのターゲットとなるスタンバイ・データベースを削除しようとした場合
ファスト・スタート・フェイルオーバーが有効化されていない場合は、いつでも構成を削除できます。
ブローカ構成で行われる一部の操作、特にREDO転送サービスに関連する操作は、全体の保護モードに影響を与える場合があります。次のような操作があります。
プライマリ・データベースのREDO転送サービスを停止する操作
個々のスタンバイ・データベースへのREDO転送サービスを停止する操作
最大可用性モードまたは最大保護モードで動作している構成をサポートする唯一のスタンバイ・データベースで、データベース・プロパティLogXptModeをSYNCからASYNCにダウングレードする操作
これらの操作の前には、ブローカによって、操作完了後にスタンバイ・データベースのREDO転送モード設定が保護モードをサポートするかどうかがチェックされます。この条件が満たされていない場合、操作は失敗し、エラーが戻されます。
完全自動管理の場合、ファスト・スタート・フェイルオーバーを有効にすると、ブローカによるフェイルオーバーの必要性の判断と、事前に指定されたターゲット・スタンバイ・データベースへのフェイルオーバーの開始が可能になります。これに伴うデータの消失はない場合と、構成可能なデータ量を消失する場合があります。また、フェイルオーバーが開始される条件やエラーも指定できます。DBMS_DG PL/SQLパッケージを使用すると、アプリケーションでファスト・スタート・フェイルオーバーを要求できます。
次の構成プロパティを使用して、ファスト・スタート・フェイルオーバーの動作を制御します。
FastStartFailoverThreshold
FastStartFailoverPmyShutdown
FastStartFailoverLagLimit
FastStartFailoverAutoReinstate
FastStartFailoverTarget
また、Oracle Enterprise ManagerまたはDGMGRLのENABLE FAST_START FAILOVER CONDITIONコマンドおよびDISABLE FAST_START FAILOVER CONDITIONコマンドを使用して、ファスト・スタート・フェイルオーバーが実行される条件を指定することもできます。
ファスト・スタート・フェイルオーバーに関する構成可能なプロパティは、次のとおりです。
FastStartFailoverThreshold
FastStartFailoverThreshold構成プロパティを設定して、(プライマリ・データベースが使用できないことが検出されてから)フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。詳細および例は、5.5.2項「ファスト・スタート・フェイルオーバーの有効化」を参照してください。
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に保護モードを変更する場合も、ファスト・スタート・フェイルオーバーを無効にしてから、プライマリとターゲット・スタンバイのLogXptModeプロパティをASYNCに変更する必要があります。元のプライマリの回復は、ASYNCターゲット・スタンバイへのファスト・スタート・フェイルオーバー後に可能になります。オブザーバは元のプライマリを再検出すると、自動的に元のプライマリを回復し、指定されたラグ以内で生成されたすべてのREDOが失われます。
FastStartFailoverAutoReinstate
FastStartFailoverAutoReinstate構成プロパティは、プライマリ・データベースがクラッシュしたか、FastStartFailoverThresholdの秒数を超えて停止したためにファスト・スタート・フェイルオーバーが発生した場合、元のプライマリ・データベースを自動的に回復するかどうかを制御します。FastStartFailoverAutoReinstateのデフォルト値はTRUEです。
フェイルオーバーの完了後に診断または修復作業を行う場合は、FastStartFailoverAutoReinstate構成プロパティをFALSEに設定すると、自動回復を回避できます。
|
注意: ユーザーによる構成可能なファスト・スタート・フェイルオーバー条件が検出されたためにファスト・スタート・フェイルオーバーが発生した場合、またはDBMS_DG.INITIATE_FS_FAILOVER関数をコールしてアプリケーションでファスト・スタート・フェイルオーバーを開始した場合、元のプライマリ・データベースの自動回復は実行されません。 |
デフォルトでは、構成済の時間しきい値(FastStartFailoverThreshold)の経過後にオブザーバもスタンバイもプライマリにアクセスできないと、ファスト・スタート・フェイルオーバーが実行されます。また、別の条件でファスト・スタート・フェイルオーバーを実行する必要がある場合もあります。
構成可能な条件は、データベースの健全性チェック・メカニズムによって検出されるものとOracleサーバーで発生するエラー(ORAエラーなど)によって検出されるものの2種類に分類されます。指定された条件が発生すると、オブザーバは、スタンバイがフェイルオーバーを受け入れるために適した状態であれば、FastStartFailoverThresholdを超えるまで待機せずにファスト・スタート・フェイルオーバーを開始します。
各条件は、個別に有効化または無効化できます。Data Guard構成では、ユーザー指定のすべての構成可能なファスト・スタート・フェイルオーバー条件がブローカ構成ファイルに保持されます。
プライマリ・データベースが有効な健全性チェック条件のいずれかを示すと、オブザーバによって検出され、スタンバイがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)ただちにファスト・スタート・フェイルオーバーが開始されます。
Oracle ORAエラー条件が指定されている場合、エラーが示されるとプライマリ・データベースがオブザーバに通知し、オブザーバは、スタンバイがフェイルオーバーを受け入れるために適した状態であれば(監視されており、同期化されているかラグ制限内であれば)ただちにファスト・スタート・フェイルオーバーを開始します。
|
注意: プライマリ・データベースは停止し、オブザーバは元のプライマリ・データベースの自動回復を試行しません。 |
|
参照:
|
DBMS_DG PL/SQLパッケージを使用して、特定の条件が満たされたときにアプリケーションによりファスト・スタート・フェイルオーバーを指示することができます。「アプリケーションによるファスト・スタート・フェイルオーバーの指示」を参照してください。
|
参照: DBMS_DGパッケージの詳細は、『Oracle Database 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;
データベースのステータスは、データベースの健全性を示します。通常、ブローカは、実際のデータベースの状態と設定がブローカ構成ファイル内の記述と一致するかどうかを検証し、データベースの健全性をチェックします。そのためには、Data Guard構成のコンポーネントで正常に機能していないものがないかどうか(REDO転送サービスにエラーがないかどうかなど)、その他の必須のデータベースの設定が正しく行われているかどうか(サーバー・パラメータ・ファイルが使用可能かどうか、ARCHIVELOGモードがオンになっているかどうかなど)をチェックします。ここでは、ブローカによりプライマリ・データベース上とスタンバイ・データベース上でチェックされる項目を詳しく説明します。
プライマリ・データベースの健全性チェックでは、次の条件が満たされているかどうかを判別します。
データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。
データベースが正しいデータ保護モードであるかどうか。
データベースでサーバー・パラメータ・ファイルが使用されているかどうか。
データベースがARCHIVELOGモードであるかどうか。
データベース・ガードがオフになっているかどうか。
補助ロギングがオンになっているかどうか(構成にロジカル・スタンバイ・データベースが含まれている場合)。
REDO転送サービスにエラーがあるかどうか。
データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。
REDO転送設定が、スタンバイ・データベースのREDO転送関連プロパティで指定された設定と一致しているかどうか。
現行のデータ保護レベルが構成済のデータ保護モードと一致しているかどうか。
プライマリ・データベースで、すべてのスタンバイ・データベースのすべてのギャップを解決できるかどうか。
スタンバイ・データベースの健全性チェックでは、次の条件が満たされているかどうかを判別します。
データベースが、ユーザーが指定してブローカ構成ファイルに記録された状態であるかどうか。
データベースでサーバー・パラメータ・ファイルが使用されているかどうか。
データベース設定が、ブローカの構成可能なプロパティで指定された設定と一致しているかどうか。
データベース・ガードがオンになっているかどうか(データベースがロジカル・スタンバイ・データベースの場合)。
ファスト・スタート・フェイルオーバーが有効化されている場合は、プライマリ・データベースおよびターゲット・スタンバイ・データベースが同期化されているかどうか、またはラグ制限内であるかどうか。
データベース・ステータスの問合せには、次の監視可能なデータベース・プロパティを使用できます。
LogXptStatus
InconsistentProperties
InconsistentLogXptProps
|
注意: これらのプロパティには、DGMGRLコマンドライン・インタフェースを介して直接アクセスします。Enterprise Managerでは、これらのプロパティの値が並べ替えられて、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
