構成を確認する

DR設定が完了したら、完全なスイッチオーバーを実行するか、またはセカンダリサイトを開いて検証を行うことによって、設定が正しいことをすぐに検証します。検証のためにセカンダリ・サイトをオープンしても、プライマリで実行されているシステムには影響しません。

検証用のセカンダリのオープン

スタンバイ・データベースをスナップショット・スタンバイに変換することで、完全なスイッチオーバーを実行せずにスタンバイ・サイトを検証できます。これにより、セカンダリSOAサーバーをスタンバイ・サイトで起動し、セカンダリ・システムを検証できます。スナップショット・スタンバイ・モード中にスタンバイ・サイト・データベースで実行された変更は、再度物理スタンバイに変換されると破棄されます。プライマリ・データはセカンダリ・サイト検証の影響を受けません。

ノート:

この操作は注意して実行する必要があります: スナップショットに変換された時点でデータベースに保留中のメッセージまたはコンポジットがある場合、スタンバイ・サイトのSOAサーバーは起動時にそれらを処理します。スナップショット・スタンバイへの変換時に、プライマリ・データベースに保留中のアクションがないことを確認します。それ以外の場合は、スナップショット・スタンバイ・データベースへの変換後、セカンダリ・サイトのSOAサーバーの起動前に、スタンバイ・データベースのランタイムSOA表からレコードを削除します。スイッチオーバーを実行せずにスタンバイ・サイトを検証するステップは、表削除なしでの実行時表からのレコードの削除を参照してください。

oracleユーザーとして、プライマリ・データベース・ホストでOracle Data Guardブローカを使用して、セカンダリをスナップショット・スタンバイに変換します。
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
コマンドshow configurationを使用して、変換が正しく実行されたことを確認します。
セカンダリ環境に保留中のアクションがないことを確認します。
スタンバイがスナップショットに変換されるときにプライマリDBに保留中のアクション(トランザクション、メッセージ)がある場合、セカンダリSOAサーバーは、セカンダリ・サーバーを起動する前に、セカンダリ・データベースのSOAランタイム表からレコードを消去するために、start.YouでSOA切捨てスクリプトを使用してセカンダリ・データベースのSOAランタイム表からレコードを削除できるときに処理を試みます。このアクションは注意して実行してください。プライマリ・データベースの表を切り捨てないでください。表削除なしでの実行時表からのレコードの削除に関する項を参照してください。
まだ起動していない場合は、セカンダリ・サイトでOracle HTTP Serverシステムを起動します。
セカンダリ・サイトで管理サーバーを起動します。
セカンダリ・サイトでセカンダリ管理対象サーバーを起動します。
WebLogicコンソールまたはスクリプトを使用して、セカンダリ管理対象サーバーを起動します。
セカンダリ・サイトを検証します。

これはスイッチオーバーではなく、プライマリ・サイトがまだアクティブであるため、仮想フロントエンド名はプライマリ・サイトのロード・バランサIPアドレスに解決されるため、ブラウザ・アクセスはデフォルトでアクティブなプライマリ・サイトにリダイレクトされます。

セカンダリ・サイトのSOAサービスに直接アクセスするには、制御されたクライアント(ラップトップなど)で/etc/hostsファイルを更新し、仮想フロントエンド名を設定してセカンダリ・サイトのフロントエンド・ロード・バランサのIPアドレスに解決し、このクライアントから検証を実行する必要があります。

ノート:
検証に使用されるクライアントがHTTPプロキシを介してシステムにアクセスしないことを確認します。これは、HTTPプロキシがクライアントの/etc/hostsにある名前に関係なく、プライマリ・サイトのロード・バランサIPアドレスを使用して仮想フロントエンド名を解決し続ける可能性があるためです。

Linux以外のクライアントでは、ブラウザがカスタマイズされたホストファイルエントリを使用してIPアドレスを解決する前に、ローカル DNSキャッシュのリセットが必要になる場合があります。

セカンダリ・サイトが検証されたら、次のステップに進み、スタンバイ・ロールに戻します。

ノート:
セカンダリ・サイトの検証には時間がかかる場合があります。
セカンダリ・サイトで管理対象サーバーおよび管理サーバーを停止します。
セカンダリ・サイトで管理対象サーバーと管理サーバーを停止するには、セカンダリWebLogicコンソールを使用します。
oracleユーザーとして、プライマリ・データベース・ホストでOracle Data Guardブローカを使用して、セカンダリをフィジカル・スタンバイに再変換します。
システム・パスワードとプライマリ・データベースの一意の名前が必要です。
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
show configurationを使用して、変換を確認します。
更新された/etc/hostsファイルを元に戻します。
検証のためにセカンダリ・サイトを指すようにクライアント内の/etc/hostsファイルを更新した場合、仮想フロントエンド名がプライマリ・フロントエンドIPアドレスを再度指すように元に戻します。

ノート:

ORA-01403: ORA-06512エラーのデータが見つかりません。

ここで説明するセカンダリ・サイトの検証中(完全なスイッチオーバーを実行しない、つまり、スナップショット・スタンバイ・モードでスタンバイをオープンするのみ)、ORA-01403:スタンバイSOAサーバーのログにORA-06512エラーが表示されない場合があります。これらのエラーは、SOA自動パージ・ジョブに関連しています。データベース内のジョブにdbロールの依存関係がある可能性があるため、これらのエラーが発生します(データベースはプライマリ・ロールの場合にのみ有効にするように定義されています)。これは、ジョブが2回(プライマリとスタンバイで1回)実行されることを防ぐ、予期された望ましい動作です。SOA自動パージ・ジョブはプライマリ・ロールで定義されるため、データベースがスナップショット・スタンバイ・モードの場合はDBA_SCHEDULER_JOBSビューに表示されません。各ジョブに定義されている database_roleは、ビューDBA_SCHEDULER_JOB_ROLEに表示されます。要するに、これらのエラーは、スタンバイシステムに表示されるかぎり無視できます。SOA自動パージのスケジューラ・ジョブは、インスタンスがそのロールをPRIMARYに変更した場合にのみ、データベースで実行されます。

スイッチオーバーの実行

スイッチオーバーは、管理者が2つのサイトのロールを元に戻す計画操作です。スイッチオーバー後、プライマリ・システムはセカンダリになり、セカンダリ・システムはプライマリになります。スイッチオーバーを実行すると、プライマリ・サイトで停止時間が発生します。

SOAハイブリッドDR構成でスイッチオーバーを実行する前に、保留中の構成変更を伝播します。保留中のセカンダリ・サイトへのレプリケートされた変更がないことを確認します。

スイッチオーバーの実行中にスケジュールされたレプリケーションを無効にします。これは、フェイルオーバーが発生し、スイッチオーバー操作自体が妨げられる可能性があるためです。
プライマリ・サイトでOracle HTTP Serverシステムを停止します。
プライマリ・サイトのサーバーを停止します。
WebLogic管理サーバー・コンソールまたはスクリプトを使用して、プライマリ・サイトのWebLogicサーバーを停止します。

ノート:
プライマリ・サイトの管理サーバーは、スイッチオーバー中に稼働状態を維持できます。ただし、サイトがスタンバイ・ロールの場合は、ライフサイクル中にスタンバイ・サイトのドメイン構成がプライマリ構成によってオーバーライドされることが予期されるため、このサイトを停止することをお薦めします。これが発生したときに管理サーバーが稼働している場合は、古い構成で実行されます。
フロントエンドDNS名をスイッチオーバーします。

システムで使用される名前をホストしているDNSサーバーで必要なDNSプッシュを実行するか、クライアントのファイル・ホスト解決を変更して、システムのフロントエンド仮想名をセカンダリ・サイトのロード・バランサによって使用されるパブリックIPにポイントします。

DNSが外部フロント・エンド解決(OCI DNSや商用DNSなど)に使用されるシナリオでは、APIを使用して変更をプッシュできます。この変更をOCI DNSでプッシュする例を確認するには、GitHub (スクリプトの例)に移動します。

DNSエントリのTTL値はスイッチオーバーのRTOに影響を与えます。たとえば、TTLが高い場合(たとえば、20分)、DNSの変更はクライアント内で有効になるまでにかかることに注意してください。低いTTL値を使用すると、より高速になりますが、キャッシュ名を使用する代わりにクライアントが DNSに頻繁にアクセスするため、オーバーヘッドが発生する可能性があります。DNSを変更する前に、TTLを一時的に低い値(1分など)に設定することをお薦めします。次に、変更を実行し、スイッチオーバー手順が完了したら、TTLを元の値に戻します。
oracleユーザーとして、プライマリ・データベース・ホストでOracle Data Guardブローカを使用してデータベースのスイッチオーバーを実行します。
システム・パスワードとプライマリ・データベースの一意の名前が必要です。
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
まだ起動していない場合は、セカンダリ・サイト(新しいプライマリ)でOracle HTTP Serverシステムを起動します。
セカンダリ・サイト(新しいプライマリ)で管理サーバーを起動するか、すでに起動されている場合はサーバーを再起動します。
管理サーバーを起動すると、これがスタンバイだった間に複製された構成の変更が有効になります。
セカンダリ・サイトでセカンダリ管理対象サーバーを起動します(新しいプライマリ)。
WebLogicコンソールまたはスクリプトを使用して、セカンダリ管理対象サーバーを起動します。