| Oracle Database高可用性ベスト・プラクティス 11gリリース1（11.1） B54839-01 |
|
 戻る |
 次へ |
この章では、計画外の停止について説明します。また、各停止タイプを許容するか管理することで停止時間を最小化できるOracle運用ベスト・プラクティスについて説明します。
この章には、次の各項が含まれます。
この項には、プライマリまたはセカンダリ・サイト・コンポーネントに影響を与える計画外の停止について説明している『Oracle Database高可用性概要』の表1-1を補う情報を記載しています。また、それぞれの停止に関連する停止時間を回避または最小化するために推奨される方法についても説明します。
計画外の停止は、アプリケーションをサポートするテクノロジ・インフラストラクチャのいずれかの部分に予期しない障害が発生することを示します。これには、次のコンポーネントが含まれます。
ハードウェア
ソフトウェア
ネットワーク・インフラストラクチャ
ネーミング・サービス・インフラストラクチャ
データベース
監視および高可用性インフラストラクチャでは、迅速な検出作業を行って停止時間からの回復を図る必要があります。第3章「Oracle Grid Controlを使用した監視」では問題の検出について説明しましたが、この章では停止時間の短縮に重点を置きます。
プライマリ・サイトとセカンダリ・サイトにおける計画外の停止の削減、推定リカバリ時間、およびリカバリ手順に関する推奨ベスト・プラクティスは、次の各項を参照してください。
計画外の停止を解決することが、システムの最大可用性にとって不可欠です。
表4-1に、最も一般的なOracle高可用性アーキテクチャの比較と、プライマリ・サイトでの計画外の停止に対応するためのリカバリ手順の概要を示します。複数のリカバリ手順を必要とする停止については、この表に、4.2項「計画外の停止からのリカバリ」の詳細な説明へのリンクが含まれます。
表4-1 プライマリ・サイトでの計画外の停止のリカバリ時間および手順
| 停止範囲 | Oracle Database 11g | RACおよびクラスタウェアを使用したOracle Database 11g | Data Guardを使用したOracle Database 11g | Oracle Database 11g MAA |
|---|---|---|---|---|
|
|
数時間〜数日
|
数時間〜数日
|
数秒〜5分脚注1 |
数秒〜5分脚注1 |
|
|
適用なし |
数時間〜数日
|
適用なし |
数秒〜5分 |
|
コンピュータ障害（ノード） |
数分〜数時間脚注2
|
停止時間なし脚注3 計画外の停止からのOracle RACリカバリによる自動管理 |
数秒〜5分脚注2 |
停止時間なし脚注3 計画外の停止からのOracle RACリカバリによる自動管理 |
|
コンピュータ障害（インスタンス） |
数分脚注2
|
停止時間なし脚注3 計画外の停止からのOracle RACリカバリによる自動管理 |
数分脚注2
または 数秒〜5分脚注1 |
停止時間なし脚注3 計画外の停止からのOracle RACリカバリによる自動管理 |
|
|
停止時間なし脚注4 |
停止時間なし脚注4 |
停止時間なし脚注4 |
停止時間なし脚注4 |
|
|
30分未満脚注5 |
30分未満脚注5 |
30分未満脚注5 |
30分未満脚注5 |
|
|
計画外停止時間については、『Oracle Database高可用性概要』のソリューションを参照 |
計画外停止時間については、『Oracle Database高可用性概要』のソリューションを参照 |
計画外停止時間については、『Oracle Database高可用性概要』のソリューションを参照 |
計画外停止時間については、『Oracle Database高可用性概要』のソリューションを参照 |
脚注1 ここでのリカバリ時間は、データベースおよび既存の接続のフェイルオーバーに適用されます。ネットワーク接続の変更やサイト固有の他のフェイルオーバー・アクティビティによっては、リカバリ時間全体が増加する可能性があります。
脚注2 リカバリ時間の多くは、障害の発生したシステムの再起動に要する時間です。
脚注3 データベースは継続して使用できますが、障害の発生したシステムに接続するアプリケーションの一部は一時的に影響を受けます。
脚注4 ストレージ障害は、ミラー化と組み合せたASMと、その自動リバランス機能の使用により回避されます。
脚注5 人為的エラーからのリカバリ時間は、主に検出時間に依存します。不適切なDMLまたはDLLトランザクションの検出に数秒を要する場合、一般的に適切なトランザクションをフラッシュバックするのに必要な時間は、数秒間のみです（適切にリハーサルされている場合）。参照整合性制約を考慮する必要があります。
大部分の事例では、プライマリ・データベースの可用性に影響を及ぼすことなく、セカンダリ・サイトの停止を管理することができます。ただし、Data Guardが最大保護モードで構成されている場合、SYNCで動作している、稼働を続ける最後のスタンバイ・データベース上で計画外の停止が発生すると、プライマリ・データベース上での停止を招きます。これは、スタンバイ・データベースにフェイルオーバーする際に、データ損失がないことを保証するために必要です。データ保護モードのダウングレード後は、スタンバイ・データベースにアクセスできない場合でもプライマリ・データベースを再起動できます。セカンダリ・サイトで停止が発生したときにプライマリ・サイトで同時障害が発生すると、最大リカバリ時間（MTTR）に影響する可能性があります。
表4-2に、セカンダリ・サイトでのスタンバイ・データベースの計画外の停止に対応するためのリカバリ手順をまとめます。複数のリカバリ手順を必要とする停止については、この表に、4.2項「計画外の停止からのリカバリ」の詳細な説明へのリンクが含まれます。
表4-2 セカンダリ・サイトでの計画外の停止のリカバリ手順
| 停止タイプ | 単一インスタンスのスタンバイ・データベースまたはOracle RACスタンバイ・データベースのリカバリ手順 |
|---|---|
|
コンピュータ障害（インスタンス） |
ブローカにより、ログ適用サービスが自動的に再起動されます。 注意: スタンバイ・データベースが1つのみ存在し、最大データベース保護で構成されている場合、スタンバイ・データベースでデータの相違が発生しないようプライマリ・データベースが停止します。 注意: Oracle RACスタンバイ・データベースの場合、使用可能なスタンバイ・インスタンスへの接続時フェイルオーバーを実行するようプライマリ・データベースのOracle Net記述子が構成されている場合、プライマリ・データベースの可用性に対する影響はありません。ブローカを使用している場合、自動的に接続時フェイルオーバーが構成されます。 |
|
データ破損 |
スタンバイ・データベースのデータ障害後のフォルト・トレランスのリストア |
|
|
RESETLOGSによるプライマリ・データベースのオープン後のフォルト・トレランスのリストア |
この項では、様々なタイプの計画外の停止からリカバリするためのベスト・プラクティスについて説明します。
この項には、次の各項目が含まれます。
完全サイト・フェイルオーバーでは、本番環境の負荷に対応するよう準備されたセカンダリ・サイトにデータベース、中間層アプリケーション・サーバーおよびすべてのユーザー接続をフェイルオーバーします。
スタンバイ・サイトが前提条件を満たしている場合、次の状況では完全サイト・フェイルオーバーをお薦めします。
プライマリ・サイトの障害（自然災害や悪意のある攻撃など）
プライマリ・ネットワークの接続障害
プライマリ・サイトの電源障害
次のプラクティスを使用することで、サイト・フェイルオーバーを数分以内に迅速に完了できます。
2.6.4項「Data Guardの一般構成のベスト・プラクティス」で説明した、Data Guard構成ベスト・プラクティスを使用します。
目標リカバリ時間（RTO）が30秒未満の環境では、Data Guardファスト・スタート・フェイルオーバーを使用してスタンバイ・データベースに自動的にフェイルオーバーします（2.6.7.2.3項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」参照）。
セカンダリ・サイトで稼働している中間層アプリケーション・サーバーを維持して起動時間を不要にするか、高速接続フェイルオーバーのベスト・プラクティスを使用して既存のアプリケーションを新しいプライマリ・データベースにリダイレクトします。その説明は次を参照してください。
MAAホワイト・ペーパー『Client Failover for Highly Available Oracle Databases』（http://www.otn.oracle.com/goto/maa）
DNSフェイルオーバー手順を自動化します。
データ損失があるかどうかは、Oracle Data Guard構成と、同期または非同期REDO転送の使用状況に応じて変化します。
プライマリ・サイトとセカンダリ・サイトのWANトラフィック・マネージャにより、サイト・フェイルオーバー機能が提供されます。WANトラフィック・マネージャは、プライマリ・サイト（またはプライマリ・サイトの特定のアプリケーション）がアクセス不可能になった場合に、自動的にトラフィックをリダイレクトします。スイッチオーバーの際には、この操作を手動で起動してセカンダリ・サイトに切り替えることも可能です。トラフィックは、停止またはスイッチオーバーによりプライマリ・サイトでサービスを提供できなくなった場合にのみ、セカンダリ・サイトに転送されます。プライマリ・サイトが停止すると、ユーザー・トラフィックはセカンダリ・サイトに自動的に転送されます。
図4-1は、サイト・フェイルオーバー前の可能なネットワーク・ルートを示しています。
クライアント・リクエストは、プライマリ・サイトのクライアント層に入り、WANトラフィック・マネージャによって転送されます。
クライアント・リクエストは、ファイアウォールを介して非武装地帯（DMZ）からアプリケーション・サーバー層に送信されます。
リクエストは、アクティブなロード・バランサを介してアプリケーション・サーバーに転送されます。
リクエストは、別のファイアウォールを介してデータベース・サーバー層に送信されます。
アプリケーション・リクエストは、必要に応じてOracle RACインスタンスにルーティングされます。
レスポンスは、同様の経路でアプリケーションとクライアントに戻されます。
図4-2は、サイト・フェイルオーバー後のネットワーク・ルートを示しています。クライアントまたはアプリケーション・リクエストは、セカンダリ・サイトのクライアント層に入り、プライマリ・サイトと同じ経路をたどります。
次の手順では、フェイルオーバーまたはスイッチオーバーのネットワーク・トラフィックに対する影響について説明します。
管理者は、プライマリ・データベースをセカンダリ・サイトにフェイルオーバーまたはスイッチオーバーします。この操作は、Data Guardファスト・スタート・フェイルオーバーを使用している場合は自動的に処理されます。
管理者は、セカンダリ・サイトの中間層アプリケーション・サーバーを起動します（実行されていない場合）。
WANトラフィック・マネージャによるセカンダリ・サイトの選択は、サイト全体障害の場合は自動化できます。セカンダリ・サイトのWANトラフィック・マネージャは、セカンダリ・サイトのロード・バランサの仮想IPアドレスを戻します。クライアントは、その後の再接続で自動的に転送されます。この場合のサイト・フェイルオーバーは、自動ドメイン・ネーム・システム（DNS）・フェイルオーバーにより実行されます。
別の方法として、DNS管理者は、WANトラフィック・マネージャの選択をサイト全体または特定のアプリケーションに対応するセカンダリ・サイトに手動で変更できます。次に、手動DNSフェイルオーバーの例を示します。
セカンダリ・サイトのロード・バランサを参照するようDNSを変更します。
マスター（プライマリ）DNSサーバーは、新規ゾーン情報で更新され、この変更はDNS NOTIFYアナウンスで広く通知されます。
スレーブDNSサーバーは、DNS NOTIFY通知によりゾーンの更新を認識し、ゾーン情報を取得します。
|
注意: マスター・サーバーとスレーブ・サーバーは、権威ネーム・サーバーです。したがって、これらのサーバーには信頼できるDNS情報が含まれます。 |
キャッシュDNSサーバーから関連するレコードを消去します。
キャッシュDNSサーバーは、主にパフォーマンスとレスポンス速度を向上するために使用します。キャッシュ・サーバーは、ホスト問合せに応答して権威DNSサーバーから情報を取得し、そのデータをローカルに保存（キャッシュ）します。同じデータに対する2回目のリクエストや後続のリクエストがあると、キャッシュDNSサーバーは、レスポンスのTTL値が期限切れになるまでローカルに保存したデータ（キャッシュ）を使用して応答します。期限切れになると、ゾーン・マスターからのデータはリフレッシュされます。DNSレコードがプライマリDNSサーバーで変更される場合、キャッシュDNSサーバーは、TTLが期限切れになるまでキャッシュされたレコードの変更を取得しません。キャッシュをフラッシュすることでキャッシュDNSサーバーを強制的に権威DNSサーバーに再接続し、更新されたDNS情報を取得します。
キャッシュのフラッシュは、使用中のDNSサーバーがフラッシュ機能をサポートしている場合に実行します。一般的なDNS BINDバージョンのフラッシュ機能は、次のとおりです。
BIND 9.3.0: コマンドrndc flushname nameにより、キャッシュから個々のエントリをフラッシュします。
BIND 9.2.0および9.2.1: コマンドrndc flushにより、キャッシュ全体をフラッシュできます。
BIND 8およびBIND 9（9.1.3以下）: ネーム・サーバーを再起動してキャッシュを消去します。
ローカルDNSサービス・キャッシュをリフレッシュします。
一部のオペレーティング・システムでは、DNS情報がローカル・ネーム・サービス・キャッシュにローカルにキャッシュされることがあります。その場合、DNSの更新が迅速に認識されるように、このキャッシュも消去する必要があります。
Solaris: nscd
Linux: /etc/init.d/nscd restart
Microsoft Windows: ipconfig /flushdns
Apple Mac OS X: lookupd -flushcache
セカンダリ・サイトのロード・バランサで、セカンダリ・サイトの中間層アプリケーション・サーバーにトラフィックを転送します。
セカンダリ・サイトでクライアント・リクエストを処理する準備が整いました。
フェイルオーバーは、クライアントのWebブラウザにも依存します。ほとんどのブラウザ・アプリケーションでは、一定期間DNSエントリがキャッシュされます。したがって、停止の発生時に進行中だったセッションは、キャッシュ・タイムアウトの期限切れまでフェイルオーバーされない可能性があります。このようなクライアントでサービスを再開するには、ブラウザを一度終了して再起動します。
フェイルオーバーとは、1つのスタンバイ・データベースをプライマリ・データベースのロールに移行する操作です。フェイルオーバー操作は、プライマリ・データベースに計画外の障害が発生し、一定の時間内にそのデータベースをリカバリできない場合に起動します。
Oracle Data Guardでは、ブローカと、ファスト・スタート・フェイルオーバーを使用して、フェイルオーバー・プロセスを自動化することができます。手動でフェイルオーバーを実行することもできます。
ファスト・スタート・フェイルオーバーでは、手動操作を必要とするプロセスの不確実性がなく、システム停止が検出されてから数秒以内に、データ損失がゼロまたは最小限のフェイルオーバーが自動実行されます（FastStartFailoverLagLimitプロパティを使用して構成）。構成ベスト・プラクティスは、2.6.7.2.3項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」を参照してください。
手動フェイルオーバーでは、次のいずれかの方法を使用して、ユーザーの決定に基づくフェイルオーバー・プロセスが可能になります。
Oracle Enterprise Manager
ブローカ・コマンドライン・インタフェース（DGMGRL）
SQL*Plus文
項4.2.2.3「手動フェイルオーバー実行のベスト・プラクティス」を参照してください。
データベース・フェイルオーバーは、アプリケーション・フェイルオーバーにより実行されますが、先にサイト・フェイルオーバーが実行される場合もあります。Data Guardフェイルオーバー後は、セカンダリ・サイトがプライマリ・データベースをホストします。元のプライマリ・データベースを新しいスタンバイ・データベースとして回復し、構成のフォルト・トレランスを復元する必要があります。4.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。
通常、フェイルオーバー操作は、データをほとんど失わないか、まったく失うことなく1分未満で完了します。
|
関連項目:
|
プライマリ・データベースの障害を、ローカル・バックアップやフラッシュバック・テクノロジを使用して目標リカバリ時間（RTO）内に修復できない場合、Oracle Data Guardを使用してフェイルオーバーを実行する必要があります。
手動フェイルオーバーは、次のような計画外の停止が発生した場合に実行します。
プライマリ・データベースが使用不可能となるサイト障害
一定の時間内に修復できないユーザー・エラーによる障害
本番アプリケーションに影響を及ぼすデータ障害
フェイルオーバーでは、以前のプライマリ・データベースをスタンバイ・データベースとして復元し、現在の環境にフォルト・トレランスを回復する必要があります。元のプライマリ・データベースが損傷していない場合、フラッシュバック・データベースを使用して、スタンバイ・データベースを短時間で回復することができます。4.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。
ファスト・スタート・フェイルオーバーは、完全自動のため、ユーザーの操作を必要としません。
ファスト・スタート・フェイルオーバーの実行時に考慮する必要のある操作上のベスト・プラクティスはありません。ただし、2.6.7.2.3項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」に記載されているすべての構成上のベスト・プラクティスを検討することは重要です。
|
関連項目: MAAホワイト・ペーパー『Data Guard Switchover and Failover Best Practices』（http://www.otn.oracle.com/goto/maa） |
手動フェイルオーバーを実行する場合は、次のようにします。
2.6.7.2.4項「手動フェイルオーバーのベスト・プラクティス」で説明されている構成ベスト・プラクティスに従います。
次のいずれかの方法を選択します。
Oracle Enterprise Manager
Oracle Enterprise Managerを使用して手動フェイルオーバーを実行する方法の詳細は、『Oracle Data Guard Broker』を参照してください。手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方で同じです。
Oracle Data Guard Brokerコマンドライン・インタフェース（DGMGRL）
Oracle Enterprise Managerを使用して手動フェイルオーバーを実行する方法の詳細は、『Oracle Data Guard Broker』を参照してください。手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方で同じです。
SQL*Plus文
このソリューションは、ノードまたはインスタンスで障害が発生したときに自動的に使用されます。稼働を続けるインスタンスは、障害インスタンスを自動的にリカバリし、自動クライアント・フェイルオーバーを潜在的に支援します。リカバリ時間は、データベースおよびOracle RAC構成上のベスト・プラクティスを導入することで制限できます。これにより、通常は、大規模なビジー・システムでデータ損失を発生させることなくインスタンス・リカバリ時間を数秒〜数分に抑えることが可能です。
次のリカバリ方法を使用できます。
ソフトウェアまたはハードウェアの問題によりインスタンスが無効化されると、インスタンス障害が発生します。インスタンス障害の発生後、Oracleでは、オンラインREDOログ・ファイルを使用して、この項に記載されているように自動的にデータベース・リカバリを実行します。
Oracle RAC環境のインスタンス・リカバリでは、障害インスタンスの再起動や、障害インスタンスで稼働していたアプリケーションのリカバリは行われません。サービス再配置と高速アプリケーション通知を使用すると、稼働していたアプリケーションを継続して実行できます（4.2.3.2項「自動サービス再配置」を参照してください）。
いずれかのインスタンスが別のインスタンスに対してリカバリを実行する場合、リカバリする側のインスタンスは次の操作を実行します。
障害インスタンスによって生成されたREDOログ・エントリを読み取り、その情報を使用してコミット済トランザクションがデータベースに記録されていることを確認します。したがって、コミット済トランザクションのデータは失われません。
障害発生時にアクティブであったコミットされていないトランザクションをロールバックし、それらのトランザクションに使用されていたリソースを解放します。
複数のノード障害が発生しても、1つのインスタンスが稼働しているかぎり、Oracle RACでは停止した他のインスタンスに対するインスタンス・リカバリが実行されます。Oracle RACデータベースのすべてのインスタンスに障害が発生した場合、いずれか1つのインスタンスを再起動した時点でクラッシュ・リカバリが開始され、コミット済トランザクションはすべてリカバリされます。Data Guardが使用可能であれば、すべてのインスタンスが停止したときに、Data Guardファスト・スタート・フェイルオーバーを使用して自動的にフェイルオーバーを実行できます。
サービスの信頼性を確保するには、冗長インスタンスを構成してその中でフェイルオーバーを実行します。通常必要とするより多くのインスタンスを有効化して、サービスを提供します。ハードウェア障害が発生し、Oracle RACデータベース・インスタンスに悪影響を及ぼす場合、そのインスタンス上のサービスは、Cluster Ready Services（CRS）によって（DBCAまたはEnterprise Managerでの構成どおりに）別の使用可能なインスタンスに自動的に移動されます。その後、CRSは、障害の発生したノードとインスタンスを再起動するよう試みます。
CRSは、障害がサービスに影響を与えるタイミングを認識して自動的にサービスをフェイルオーバーし、サービスをサポートする稼働中のインスタンス全体にクライアントを再配置します。同時に、CRSは、障害インスタンスを再起動して依存リソースをシステムに再統合するよう試みます。高速アプリケーション通知（FAN）イベントを使用した障害の通知は、Oracleサーバー・アーキテクチャ内の様々なレベルで起動できます。レスポンスには、Oracle Notification Service（ONS）、アドバンスト・キューイングまたはFANコールアウトを通じた外部パーティへの通知に加え、追跡用の障害記録、イベント・ロギング、およびアプリケーションへの割込みを含めることが可能です。障害ノードのサービスが停止すると、稼働を続けるノードから通知が発生します。サービスを提供するノードの場所と数は、アプリケーションに対して透過的です。自動再起動およびリカバリは、データベースのみでなくリスナーやASMインスタンスなどのすべてのサブシステムで自動化されています。
Oracle Cluster Registry（OCR）ファイルが失われると、Oracle RACおよびOracleクラスタウェアの可用性が影響を受けます。OCRファイルは、自動で作成される物理バックアップからリストアするか、ocrconfigツールを使用して手動で作成されるエクスポート・ファイルからリストアすることが可能です。また、Oracle Database 10gリリース2（10.2）以上では、単一のOCRデバイス障害に対応できるようオプションでOCRをミラー化できます。OCRミラーは、必ず物理的に別々のデバイス、できれば別々のコントローラ上に置きます。
|
関連項目: 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のReal Application Clustersでのストレージ管理に関する項 |
アプリケーションは、アプリケーション・サービスが使用不可能になったときに通知を迅速かつ効率的に受信します。通知が発生すると、稼働を続けるOracle RACデータベースの最後のインスタンス、またはフェイルオーバー後にプライマリ・ロールを引き受けるはずのスタンバイ・データベースへのアプリケーション接続が透過的に発生します。
Oracle RAC構成では、迅速で透過的なアプリケーション・フェイルオーバーを実現するためにサービスは不可欠です。インスタンスまたはノードの障害のため、サービスが特定のインスタンスで使用不可能になると、そのサービスはクラスタ内の使用可能なインスタンスにフェイルオーバーされるため、アプリケーションでは処理を継続できます。クライアントは、高速アプリケーション通知（FAN）を介してサービス再配置を通知されます。
Oracle Data Guard構成では、複数サイトにわたるクライアント・フェイルオーバーを行うようにサービスを構成することができます。Data Guard構成では、サイト障害の発生後、新規プライマリ・データベースで自動的に本番サービスが公開され、障害の発生したプライマリ・データベースでサービスが中断したことが（FANイベントを通じて）関連するクライアントに通知されます。
ハングしたか、またはレスポンス時間が許容できないほどかかる状況では、アプリケーションまたはレスポンス時間の速度低下を検出し、その状況に対応するように、Oracle Enterprise Managerまたはカスタム・アプリケーション・ハートビートを構成することができます。たとえば、Enterprise Managerビーコンを構成して、アプリケーションのレスポンス時間を監視、検出することができます。特定の時間しきい値が期限切れになると、Enterprise ManagerがOracle Data Guard DBMS_DG.INITIATE_FS_FAILOVER PL/SQLプロシージャをコールしてデータベース・フェイルオーバーを即座に開始し、続いて、FAN通知とサービス再配置を使用してアプリケーション・フェイルオーバーを行うことができます。
FAN通知とサービス再配置を使用すると、Oracle RACまたはOracle Data Guardのフェイルオーバーを引き起こすあらゆる障害または計画済のメンテナンスの際に、自動の高速リダイレクションが可能になります。
|
関連項目:
|
表4-3に、様々なASM障害タイプの影響と推奨される修復方法をまとめます。
表4-3 ASM障害タイプと推奨される修復方法
| 障害 | 説明 | 影響 | 推奨される修復方法 |
|---|---|---|---|
|
ASMインスタンス障害 |
ASMインスタンスに障害が発生します。 |
同じノードからASMストレージにアクセスするすべてのデータベース・インスタンスが停止します。 |
計画外の停止からのOracle RACリカバリを自動実行します。 Oracle RACを使用していない場合、Data Guardフェイルオーバーを使用します（4.2.2.2項「ファスト・スタート・フェイルオーバーを実装するためのベスト・プラクティス」を参照）。 Oracle RACとData Guardを使用していない場合、基礎となる問題を修正してからASMとデータベース・インスタンスを再起動します。 |
|
ASMディスク障害 |
1つ以上のASMディスクに障害が発生しますが、すべてのディスク・グループはオンラインのままです。 |
引き続きすべてのデータにアクセスできます。この状況は、標準冗長性または高冗長性のディスク・グループでのみ発生します。 |
ASMは、残っているディスク・ドライブを対象にリバランス操作を自動的に実行し、冗長性を再確立します。冗長性を回復するには、残っているディスク・ドライブに十分な空き領域が存在する必要があります。領域が不足している場合、リバランス操作はORA-15041により失敗する可能性があります（2.1.2.2項「計画済のメンテナンスに関するOracleストレージ・グリッドのベスト・プラクティス」参照）。 注意: 外部冗長性ディスク・グループでは、ディスク障害から保護するためにストレージ・アレイでミラー化を使用する必要があります。ディスク障害はASMから隔離する必要があります。 |
|
データ領域ディスク・グループ障害 |
1つ以上のASMディスクに障害が発生し、データ領域ディスク・グループがオフラインになります。 |
データ領域ディスク・グループにアクセスするデータベースが停止します。 |
Data Guardフェイルオーバーまたはローカル・リカバリを実行します（4.2.5.3項「データ領域ディスク・グループ障害」を参照）。 |
|
フラッシュ・リカバリ領域ディスク・グループ障害 |
1つ以上のASMディスクに障害が発生し、フラッシュ・リカバリ領域ディスク・グループがオフラインになります。 |
フラッシュ・リカバリ領域ディスク・グループにアクセスするデータベースが停止します。 |
ローカル・リカバリまたはData Guardフェイルオーバーを実行します（4.2.5.4項「フラッシュ・リカバリ領域ディスク・グループ障害」を参照）。 |
ASMインスタンスに障害が発生すると、同じノードからASMストレージにアクセスするデータベース・インスタンスが停止します。フェイルオーバー処理の説明を次のリストに示します。
プライマリ・データベースがOracle RACデータベースの場合、アプリケーション・フェイルオーバーは自動的に発生し、データベース・インスタンスに接続しているクライアントは残っているインスタンスに再接続します。このため、サービスはクラスタ内の他のインスタンスによって提供され、処理は継続します。通常、リカバリ時間は数秒以内です。
プライマリ・データベースがOracle RACデータベースでない場合、ASMインスタンス障害が発生するとデータベース全体が停止します。
構成でOracle Data Guardを使用しており、ファスト・スタート・フェイルオーバーを有効にしている場合、データベース・フェイルオーバーが自動的に起動され、クライアントはフェイルオーバーの完了後に新規プライマリ・データベースに自動的に再接続されます。リカバリ時間は、自動Data Guardファスト・スタート・フェイルオーバー操作が完了するまでの時間と同じです。ファスト・スタート・フェイルオーバーを構成していない場合、手動でASMインスタンスとデータベース・インスタンスを再起動するか、手動Data Guardフェイルオーバーを実行することによって、この停止状態からリカバリする必要があります。
構成にOracle RACもData Guardも含まれない場合、ASMインスタンスとデータベース・インスタンスを手動で再起動する必要があります。リカバリ時間は、これらの作業の所要時間により異なります。
ASMディスクに障害が発生した場合、フェイルオーバー処理は次のようになります。
ASMディスク・グループが外部冗長性タイプとして構成されている場合、単一のディスク障害は、ストレージ・アレイにより処理されるためASMインスタンスからは認識されないのが普通です。ディスク・グループを使用するASMとデータベースのすべての操作は、通常どおり機能し続けます。
ただし、外部冗長性ディスク・グループの障害がASMインスタンスで認識された場合、ASMインスタンスはディスク・グループを即座にオフラインにするため、そのディスク・グループにアクセスしているOracleインスタンスはクラッシュします。ディスク障害が一時的な場合は、ASMインスタンスとデータベース・インスタンスを再起動できます。ディスク・グループがオンラインに戻ると、クラッシュ・リカバリが起動します。
ASMディスク・グループが標準または高冗長性タイプとして構成されている場合、ディスク障害はASMにより透過的に処理され、ディスク・グループにアクセスしているデータベースは影響を受けません。
ASMインスタンスは、自動的にASMリバランス操作を開始し、1つ以上の障害ディスクのデータをASMディスク・グループの代替ディスクに分散します。リバランス操作の進行中に、まだ再ミラー化されていないデータを含むディスクに別のディスク障害が発生すると、ディスク・グループの可用性に影響を与える可能性があります。リバランス操作が正常に完了すると、後続の障害が発生してもASMディスク・グループは影響を受けません。複数のディスク障害も、それらの障害がASMディスク・グループのただ1つの障害グループに影響を与えるかぎり、同じように処理されます。
複数の障害グループの複数のディスクで、プライマリ・エクステントとそのすべてのミラーが失われる障害が発生した場合、ディスク・グループはオフラインになります。
次のリカバリ方法を使用できます。
図4-3は、ディスク障害をレポートするEnterprise Managerを示しています。3つのアラートが11:19:29に記録されています。最初のアラートは、「オフライン・ディスク数」です。2番目と3番目のアラートは、データ領域ディスクDATA.XBBT1D06_DATAおよびリカバリ領域ディスクRECO.XBBT1D06_RECOに関する「ディスク・ステータス」メッセージです。
2 disks are offline Disk DATA.XBBT1D06_DATA is offline. Disk RECO.XBBT1D06_RECO is offline.
図4-4は、データ領域ディスク・グループDATAおよびリカバリ領域ディスク・グループRECOのステータスをレポートするEnterprise Managerを示しています。「メンバー・ディスク」の下の赤い矢印は、各ディスク・グループ内の1つのディスクに障害が発生していることを示しています。「保留中の操作」の下の数字は、各ディスク・グループで1つの操作が保留中であることを示しています。
図4-4 Enterprise ManagerによるASMディスク・グループ・ステータスのレポート
図4-5は、DATAディスク・グループに対する保留中のREBAL操作をレポートするEnterprise Managerを示しています。この操作は、「%完了」に示されているとおり約3分の1が完了しており、「残り時間」は16分と推定されています。
1つ以上の障害ディスクを置換し、ストレージへのアクセスが回復したら、次の手順を実行します。
次のSQLコマンドを使用して、障害ディスク・グループに1つ以上の置換ディスクを追加します。
ALTER DISKGROUP disk_group ADD FAILGROUP failure_group DISK 'disk1','disk2',...;
次のコマンドで操作の進行状況をチェックします。
SELECT * FROM V$ASM_OPERATION;
データ領域ディスク・グループ障害は、複数の障害が存在する場合にのみ発生するのが普通です。たとえば、データ領域ディスク・グループが外部冗長性として定義されている場合、単一のディスク障害はASMから隔離されている必要があります。ただし、ストレージ・アレイの複数のディスク障害は、ASMで認識される可能性があり、その場合ディスク・グループはオフラインになります。同様に、標準または高冗長性ディスク・グループの異なる障害グループに複数のディスク障害が発生した場合も、ディスク・グループはオフラインになる可能性があります。
標準または高冗長性ディスク・グループで1つ以上のディスク障害が発生したが、ASMディスク・グループにアクセス可能な場合、データは失われず、即座にアクセスできなくなることもありません。ASMインスタンスは、自動的にASMリバランス操作を開始し、1つ以上の障害ディスクのデータをASMディスク・グループの代替ディスクに分散します。リバランス操作が正常に完了すると、2番目の障害が発生してもASMディスク・グループは影響を受けません。リバランス操作を正常に完了するには、ディスク・グループ内の残りのディスクに十分なディスク領域が存在する必要があります。
表4-4に、データ領域のディスク・グループ障害からリカバリするために可能な解決方法をまとめます。
表4-4 データ領域ディスク・グループ障害のリカバリ・オプション
| リカバリ・オプション | 目標リカバリ時間（RTO） | 目標リカバリ時点（RPO） |
|---|---|---|
|
Data Guardフェイルオーバー |
5分以下 |
選択されているデータ保護レベルに応じて変動 |
|
ローカル・リカバリ |
データベースのリストア時間とリカバリ時間 |
0（ゼロ） |
Data Guardを使用しており、ファスト・スタート・フェイルオーバーを構成している場合、データ領域ディスク・グループがオフラインとなってデータベースが停止した時点で自動フェイルオーバーが起動されます。ファスト・スタート・フェイルオーバーを構成していない場合は、手動フェイルオーバーを実行します。
Data Guardフェイルオーバーを実行する場合、目標リカバリ時間（RTO）は、Data Guardオブザーバ・プロセスとファスト・スタート・フェイルオーバーの稼働状況に応じて数分〜数秒となります。ただし、手動フェイルオーバーを実行する場合は、スタンバイ・サイトにすべてのデータが用意されていないとデータ損失が発生する可能性があります。
Data Guardフェイルオーバーが完了し、アプリケーションが使用可能になったら、データ領域ディスク・グループ障害を解決する必要があります。引き続き、後続の「ローカル・リカバリの手順」を参照してASMディスク・グループ障害を解決します。
ローカル・リカバリのみのRTOは、次の操作時間に基づきます。
障害ストレージ・コンポーネントを修復および置換する時間
データベースをリストアおよびリカバリする時間
損失の影響はデータ領域ディスク・グループに限定されるため、データ損失は発生しません。すべてのトランザクションはフラッシュ・リカバリ領域に存在するOracle REDOログ・メンバーに記録されるため、完全なメディア・リカバリが可能です。
Data Guardを使用していない場合、次のローカル・リカバリの手順を実行します。ローカル・リカバリの実行に要する時間は、データベースをリストアおよびリカバリする時間に応じて変化します。ローカル・リカバリの実行によるデータ損失はありません。
1つ以上の障害ディスクを置換し、ストレージへのアクセスが回復したら、次の手順を実行します。
|
注意: 新規プライマリ・データベースに対してOracle Data Guardフェイルオーバーを実行した場合、次の手順を使用してそのデータベースをData Guard環境に再統合できます。4.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」も参照してください。 |
ASMインスタンス上で次のSQL*Plus文を発行することによって、新しい記憶域の場所を使用してASMディスク・グループを再構築します。
SQL> CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK 'path1','path2',...;
次のRMANコマンドを使用して、インスタンスNOMOUNTを起動します。
RMAN> STARTUP FORCE NOMOUNT;
リカバリ領域に残っているコピーから制御ファイルをリストアします。
RMAN> RESTORE CONTROLFILE FROM 'recovery_area_controlfile';
MOUNTでインスタンスを起動します。
RMAN> STARTUP FORCE MOUNT;
データベースをリストアします。
RMAN> RESTORE DATABASE
データベースをリカバリします。
RMAN> RECOVER DATABASE;
ブロック変更トラッキングを使用している場合、次のSQL*Plus文を使用して、ブロック変更トラッキング・ファイルを一度無効化してから再有効化します。
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
データベースをオープンします。
SQL> ALTER DATABASE OPEN;
障害ASMディスク・グループにログ・ファイル・メンバーを再作成します。
SQL> ALTER DATABASE DROP LOGFILE MEMBER 'filename'; SQL> ALTER DATABASE ADD LOGFILE MEMBER 'disk_group' TO GROUP group_no;
次のRMANコマンドを使用して、増分レベル0のバックアップを実行します。
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;
通常、制御ファイル・メンバーはフラッシュ・リカバリ領域に存在し、Oracleではすべての制御ファイル・メンバーにアクセスできる必要があるため、フラッシュ・リカバリ領域ディスク・グループに障害が発生すると、データベースはクラッシュします。フラッシュ・リカバリ領域には、フラッシュバック・ログ、REDOログ・メンバーおよびすべてのバックアップ・ファイルが含まれることがあります。
この障害はフラッシュ・リカバリ領域ディスク・グループのみに影響を与えるため、データの損失はありません。データファイルとオンラインREDOログ・ファイルは引き続き存在し、データ領域で使用できるため、データベースのメディア・リカバリは必要ありません。
フラッシュ・リカバリ領域ディスク・グループ障害は、複数の障害が存在する場合にのみ発生するのが普通です。たとえば、フラッシュ・リカバリ領域ディスク・グループが外部冗長性として定義されている場合、単一のディスク障害はASMから隔離されている必要があります。ただし、ストレージ・アレイの複数のディスク障害は、ASMに影響を与え、ディスク・グループがオフラインになる原因になることがあります。同様に、標準または高冗長性ディスク・グループの異なる障害グループに複数のディスク障害が発生した場合も、ディスク・グループはオフラインになる可能性があります。
表4-5に、フラッシュ・リカバリ領域ディスク・グループ障害が発生した場合に使用可能な解決方法をまとめます。
表4-5 フラッシュ・リカバリ領域ディスク・グループ障害のリカバリ・オプション
| リカバリ・オプション | 目標リカバリ時間（RTO） | 目標リカバリ時点（RPO） |
|---|---|---|
|
ローカル・リカバリ |
5分以下 |
0（ゼロ） |
|
Data Guardフェイルオーバーまたはスイッチオーバー |
5分以下 |
0（ゼロ） |
高速ローカル再起動を実行して、障害フラッシュ・リカバリ領域に存在する制御ファイル・メンバーの削除後にプライマリ・データベースを起動し、ローカル・アーカイブの新規フラッシュ・リカバリ領域を参照するよう設定する必要があります。
高速ローカル再起動を行うには、プライマリ・データベースで次の手順を実行します。
データ領域のメンバーのみを指定するようCONTROL_FILES初期化パラメータを変更します。
ALTER SYSTEM SET CONTROL_FILES='+DATA/sales/control1.dbf' SCOPE=spfile;
ローカル・アーカイブの宛先とフラッシュ・リカバリ領域を、冗長性を備えたスケーラブルなローカルの宛先に変更します。
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+DATA' SCOPE=spfile;
新規設定でデータベースを起動します。
STARTUP MOUNT:
フラッシュバック・ログの破損や損失が発生した場合、状況によってはフラッシュバック・データベースを一度無効化してから再有効化する必要があります。
ALTER DATABASE FLASHBACK OFF; ALTER DATABASE FLASHBACK ON; ALTER DATABASE OPEN;
ただし、この方法は、フラッシュ・リカバリ領域を作成して障害ストレージ・コンポーネントを置換するまでの一時的な修復手段です。「ローカル・リカバリの手順」の使用をお薦めします。
Data Guardロール移行の実行を決定した場合
RTOは、Data Guardオブザーバ・プロセスとファスト・スタート・フェイルオーバーの稼働状況に応じて数秒〜数分となります。
保護レベルが最大パフォーマンスであるか、スタンバイ・データベースがプライマリ・データベースと同期していない場合は、次のようにします。
制御ファイル・メンバーを削除し、SPFILEの一時フラッシュ・リカバリ領域（ファイル・システム）を参照することによって、一時的にプライマリ・データベースを起動します。
Data Guardスイッチオーバーを実行してデータ損失を防ぎます。
スイッチオーバーが完了し、アプリケーションが使用可能になったら、リカバリ領域ディスク・グループ障害を解決します。
関連するデータベースを停止し、「ローカル・リカバリの手順」を使用してASMディスク・グループ障害を解決します。
|
注意: 新規プライマリ・データベースに対してOracle Data Guardフェイルオーバーを実行した場合、この手順を使用して元のプライマリ・データベースをスタンバイ・データベースとして再導入することはできません。その理由は、データベースの再導入作業に必要なフラッシュバック・データベースのログ・ファイルが失われているためです。スタンバイ・データベースについては、完全な復元を実行する必要があります。 |
フラッシュ・リカバリ領域として使用できるストレージに置換するか、ストレージへのアクセスを確立します。
次のSQL*Plus文を発行することによって、記憶域の場所を使用してASMディスク・グループを再構築します。
SQL> CREATE DISKGROUP RECO NORMAL REDUNDANCY DISK 'path1','path2',...;
次のRMANコマンドを使用して、インスタンスNOMOUNTを起動します。
RMAN> STARTUP FORCE NOMOUNT;
データ領域に残っているコピーから制御ファイルをリストアします。
RMAN> RESTORE CONTROLFILE FROM 'data_area_controlfile';
MOUNTでインスタンスを起動します。
RMAN> STARTUP FORCE MOUNT;
フラッシュバック・データベースを使用している場合、次のSQL*Plus文を使用して、その機能を無効化します。
SQL> ALTER DATABASE FLASHBACK OFF;
データベースをオープンし、インスタンス・リカバリを完了します。
SQL> ALTER DATABASE OPEN;
フラッシュバック・データベースが必要な場合にのみ、次の文を発行します。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE FLASHBACK ON; SQL> ALTER DATABASE OPEN;
障害ASMディスク・グループにログ・ファイル・メンバーを再作成します。
SQL> ALTER DATABASE DROP LOGFILE MEMBER 'filename'; SQL> ALTER DATABASE ADD LOGFILE MEMBER 'disk_group' TO GROUP group_no;
次のRMANコマンドを使用して、制御ファイルおよびフラッシュ・リカバリ領域を同期します。
RMAN> CATALOG RECOVERY AREA; RMAN> CROSSCHECK ARCHIVELOG ALL; RMAN> CROSSCHECK BACKUPSET; RMAN> CROSSCHECK DATAFILECOPY ALL; RMAN> LIST EXPIRED type; RMAN> DELETE EXPIRED type;
例では、type変数はLIST EXPIRED BACKUPとLIST EXPIRED COPYコマンド、およびDELETE EXPIRED BACKUPとDELETE EXPIRED COPYコマンドのプレースホルダです。これらのコマンドをすぐにすべて実行します。
なんらかの形でデータが失われたと仮定し、バックアップを実行します。
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;
データ破損からのリカバリは、計画外の停止に関連する状況です。データ破損は、たとえ問題がデータベース内で明らかとなっても、データベース外で発生したなんらかのアクティビティまたは障害を原因とするのが普通です（常にではありません）。
データファイルのデータ破損は、次の2つのカテゴリに分類されます。
データファイル・ブロック破損
破損したデータファイル・ブロックにはアクセスできますが、ブロックの内容は無効であるか、一貫性が失われています。データファイル破損の一般的な原因は、I/Oスタックのハードウェアまたはソフトウェア・コンポーネントの障害です。I/Oスタックには、ファイル・システム、ボリューム・マネージャ、デバイス・ドライバ、ホスト・バス・アダプタ、ストレージ・コントローラおよびディスク・ドライブが含まれます（これらに限定されるわけではありません）。
通常、破損ブロックが検出された時点でデータベースは依然として使用できますが、一部の破損ブロックは広範囲に及ぶ問題（ファイル・ヘッダーまたはデータ・ディクショナリ・オブジェクトの破損や、アプリケーションを使用不可能にする重要な表の破損）を引き起こす可能性があります。
データ障害は、アプリケーションの可用性に影響を与えるため、ユーザー、管理者、RMANバックアップまたはアプリケーションによって認識された時点で明らかとなります。データ障害の例は、次のとおりです。
物理ディスクに問題箇所が存在するためにアプリケーションで読み取ることができないユーザー表の単一の破損データ・ブロック
ブロックの一貫性が失われているためにOracleによって検出された単一の破損データ・ブロック。このブロックは破損ブロックとしてマークされ、このブロックにアクセスするアプリケーションはORA-1578エラーを受信します。
ディスク・コントローラ障害によるSYSTEM表領域のデータファイルの無効ブロックを原因として自動停止するデータベース
メディア障害
このカテゴリのデータ破損の原因は、ハードウェアの物理的問題またはユーザー・エラーです。システムでは、データベースの運用に必要なファイルを正常に読み取ることができないか、ファイルに正常に書き込むことができません。
RMANブロック・メディア・リカバリでは、ターゲット・ブロックがアプリケーション機能にとって重要でないかぎり、最高度のアプリケーション可用性を得ることができます。スタンバイ・データベースへのData Guardスイッチオーバーまたはフェイルオーバーでは、予測されるRTOを最も短縮できます。
データベース・オブジェクトの可用性や一貫性を損うその他の停止は、表の削除または表データの不適切な更新などの人為的エラーにより引き起こされます。人為的エラーからのリカバリ方法の詳細は、4.2.7項「人為的エラーからのリカバリ」を参照してください。
データ破損がデータファイル以外のオブジェクトに影響を及ぼす場合、修復方法は多少異なることがあります。表4-6に、データベース以外の主要オブジェクトの破損と推奨される修復方法をマトリックス形式で示します。
表4-6 データベース以外のオブジェクトの破損と推奨される修復方法
| 関連するオブジェクトまたはコンポーネント | 影響 | 修復方法 |
|---|---|---|
|
任意の制御ファイル |
データベース停止 |
Data Guardファスト・スタート・フェイルオーバーにより、スタンバイ・データベースに自動的にフェイルオーバーされます。 |
|
REDOログ・メンバー |
なし |
|
|
アクティブREDOログ・グループ |
データベース停止 |
アクティブ・ログの損失からのリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
クラッシュ・リカバリに必要とされるアクティブな（または現行の）REDOログ・グループ |
データベース停止 |
次のいずれかの解決方法を使用します。
不完全なメディア・リカバリとフラッシュバック・データベースは、同等の解決方法です。ただし、フラッシュバック・データベースの方が、通常は高速です。 |
|
アーカイブREDOログ・ファイル脚注1 |
なし |
|
|
SPFILE |
なし |
バックアップからSPFILEをリストアして修正します。 |
脚注1 アーカイブREDOログのすべてのコピーの損失または破損を想定しています（アーカイブに複数の宛先を指定している場合）。
データ破損による停止は次のいずれかの方法を使用して解決できます。
データ・リカバリ・アドバイザを使用すると、データ障害の自動診断、適切な修復オプションの判別と提供、およびユーザー・リクエストに応じた修復の実行が行われます。データ・リカバリ・アドバイザは、データ修復を自動化することにより、Oracleデータベースの管理性と信頼性を向上させ、MTTRを減少させます。
|
注意: データ・リカバリ・アドバイザの最初のリリースでは、Oracle RACはサポートされていません。また、Data Guard構成のプライマリ・データベースの管理でデータ・リカバリ・アドバイザを使用すると、フィジカル・スタンバイ・データベースを使用してデータ・リカバリ・アドバイザを処理することはできません。 Enterprise Manager 10gのGrid Controlを使用する場合、データ・リカバリ・アドバイザは、修復戦略を推奨する際にスタンバイ・データベースの存在しか考慮に入れません。 |
データ・リカバリ・アドバイザには、コマンドライン・インタフェースとGUIインタフェースの両方があります。GUIインタフェースは、Oracle Enterprise ManagerのDatabase ControlとGrid Controlで利用できます。GUIでリカバリ・ページに移動するには、「データベース・ホーム」ページの「可用性」タブで、「リカバリの実行」をクリックします。RMANコマンドライン・インタフェースでは、データ・リカバリ・アドバイザのコマンドには、LIST FAILURE、ADVISE FAILURE、REPAIR FAILUREおよびCHANGE FAILUREなどがあります。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のデータ・リカバリ・アドバイザによる障害の診断および修復に関する章 |
フェイルオーバーは、スタンバイ・データベースをプライマリ・データベース・ロールに移行する操作です。データベース・スイッチオーバーは、スタンバイ・データベースとプライマリ・データベースのロールを切り替える計画された移行操作です。どちらの操作も、データを失うことなく5分未満で完了します。データ破損やデータ障害にData Guardスイッチオーバーまたはフェイルオーバーを使用するのは、次の場合です。
データベースが停止している状況で（またはデータベースは稼働しているがデータ破損またはデータ障害のためにアプリケーションを使用できない状況で）、ローカルでのリストアおよびリカバリ時間が長くなるか、その時間が予測できない場合。
ローカルでのリカバリ時間が、ビジネス品質保証契約またはRTOより長くなる場合。
ブロック・メディア・リカバリでは、RMAN RECOVER BLOCKコマンドを使用して、データファイルでメディア破損としてマークされた1つのブロックまたはデータ・ブロックのセットをリカバリします。メディア破損としてマークされた、メディア・リカバリを必要とするデータ・ブロックの数が少ない場合、データファイル全体ではなく、破損したブロックを選択的にリストアおよびリカバリできます。この場合、リカバリを必要とするブロックのみがリストアされ、必要な破損ブロックのみがリカバリされるため、RTOが短縮されます。ブロック・メディア・リカバリにより、REDO適用時間が最小化され、リカバリ時のI/Oオーバーヘッドが回避されます。また、破損ブロックのリカバリ中も、関連するデータファイルはオンラインのまま使用できます。ただし、破損ブロックは、完全にリカバリされるまで使用できない状態が続きます。
ブロック・メディア・リカバリを使用するのは、次の場合です。
メディア・リカバリを必要とするブロックの数が少なく、リカバリの必要なブロックが判明している場合。データファイルの重要な部分が破損しているか、破損量が不明の場合は、別のリカバリ方法を使用する必要があります。
破損したデータファイルのバックアップ・ファイルがローカルで使用可能であるか、そのバックアップ・ファイルをリモートの場所（フィジカル・スタンバイ・データベースなど）から取得できる場合。
|
注意: リリース11.1.0.7より前のリリースを実行しているデータベースでブロック・メディア・リカバリを使用する場合、破損したデータファイルのバックアップはプライマリ・データベースに存在している必要があります。バックアップがスタンバイ・データベースに存在する場合は、そのバックアップをプライマリ・データベースに移動する必要があります。 |
ブロック・メディア・リカバリは、次の停止からリカバリする場合には使用しないでください。
データ・ブロックを損わない論理破損の原因となるユーザー・エラーまたはソフトウェアの不具合。このタイプのリカバリの詳細は、4.2.7項「人為的エラーからのリカバリ」を参照してください。
破損したREDOデータを原因とする変更。ブロック・メディア・リカバリでは、使用可能なすべてのREDOデータをリカバリ対象のブロックに適用する必要があります。REDOデータが破損している場合、リカバリ・プロセスでは、推測された変更が再導入されます。
たとえば、RMANブロック・メディア・リカバリを使用して特定の破損ブロックをリカバリするには、次のようにします。
RMAN> RECOVER BLOCK DATAFILE 7 BLOCK 3;
破損が検出された場合、Grid Controlを使用すると簡単にブロックをリカバリできます。
|
注意: Active Data Guardを使用する場合、ブロック・メディア・リカバリは次のように実行されます。
|
|
関連項目:
|
データファイル・メディア・リカバリでは、RMAN RECOVERコマンドを使用して、データベースのデータファイル全体またはデータファイルのセットをリカバリします。メディア破損としてマークされた、メディア・リカバリを必要とするデータ・ブロックの数が多いか不明の場合、またはファイル全体が失われた場合、関連するデータファイルをリストアおよびリカバリする必要があります。
RMANデータファイル・メディア・リカバリを使用するのは、次の場合です。
リカバリを必要とするブロックの数が多い場合RMAN VALIDATE CHECK LOGICALコマンドを使用して、破損しているブロック数を正確に特定します。
ブロック・メディア・リカバリを利用できない場合（たとえば、不完全なリカバリが必要とされる場合）。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』の高度なユーザー管理のリカバリの例に関する項、およびホワイト・ペーパー『Using Recovery Manager with Oracle Data Guard in Oracle Database 10g』（http://www.oracle.com/technology/deploy/availability/pdf/RMAN_DataGuard_10g_wp.pdf） |
Oracleフラッシュバック・テクノロジは、データ・リカバリの概念を大きく変えるものです。フラッシュバック・テクノロジ以前は、データベースを破損するのは数秒でも、リカバリには数時間から数日を要していました。フラッシュバック・テクノロジを使用すると、エラーを修正する時間が、エラーを起こしたときの時間と同じ程度にまで短縮されます。人為的エラーが発生し、データベース、表、トランザクションまたは行レベルの変更を過去の任意の時点に戻す必要がある場合でも、データベースやオブジェクトをリストアすることなくそれらのエラーを簡単に修復できます。フラッシュバック・テクノロジでは、間違った行削除などの局所的な障害を詳細に分析して修復できます。また、フラッシュバック・テクノロジでは、不適切なアプリケーション・バッチ・ジョブを誤って実行した場合など、広範囲に影響が及ぶ障害を修復することも可能です。さらに、フラッシュバック・テクノロジは、データベース・リストアと比較して非常に高速です。
フラッシュバック・テクノロジは、次のような人為的エラーを修復する場合にのみ使用できます。
間違いによる（または悪意のある）更新、削除または挿入トランザクション
間違いによる（または悪意のある）DROP TABLE文
間違いによる（または悪意のある）バッチ・ジョブまたは広範囲に影響が及ぶアプリケーション・エラー
フラッシュバック・テクノロジは、ブロック破損、ディスク障害、ファイル削除などのメディア破損やデータ破損には使用できません。これらの障害を修復する方法の詳細は、4.2.6項「データ破損（データ障害）からのリカバリ」および4.2.2項「スタンバイ・データベースでのデータベース・フェイルオーバー」を参照してください。
表4-7に、行の破壊（不適切な更新を使用した場合など）からデータベース全体の破壊（オペレーティング・システム・レベルで基礎にあるファイルをすべて削除した場合など）まで、停止範囲に応じた各種のフラッシュバック・ソリューションをまとめます。
表4-7 様々な障害のフラッシュバック・ソリューション
| 停止範囲 | 人為的エラーの例 | フラッシュバック・ソリューション | 関連項目 |
|---|---|---|---|
|
行またはトランザクション |
意図しない行の削除 間違ったトランザクション |
|
関連項目: 「行およびトランザクションの非一貫性の解決」 |
|
表 |
表の削除 1つの表または表のセットに影響を与える間違ったトランザクション |
|
関連項目: 「表の非一貫性の解決」 |
|
表領域またはデータベース |
多くの表または不明な表のセットに影響を与える間違ったバッチ・ジョブ データベース全体を対象とする悪意のある一連のトランザクション |
フラッシュバック・データベースの有効化またはFLASHBACK TABLEコマンドの複数回使用 |
関連項目: 「データベース全体の非一貫性の解決」 |
|
単一の表領域、または複数の表領域のサブセット |
少数の表領域に影響を与える間違ったトランザクション |
RMAN表領域のPoint-in-Timeリカバリ（TSPITR） |
関連項目: 「1つまたは複数の表領域の非一貫性の解決」 |
表4-8に、各フラッシュバック機能をまとめます。
表4-8 フラッシュバック機能のまとめ
フラッシュバック・データベースでは、Oracleデータベースのフラッシュバック・ログを使用し、他のすべてのフラッシュバック・テクノロジ機能では、Oracleデータベース独自のUNDO機能とマルチバージョン読取り一貫性機能を使用します。障害時にこれらのソリューションで各リソースを使用できるようフラッシュバック・テクノロジを構成する方法の詳細は、2.2項「Oracle Database 11gの構成」に記載されているデータベース構成上のベスト・プラクティスを参照してください。
|
関連項目: フラッシュバック・テクノロジと自動UNDO管理の詳細は、『Oracle Database管理者ガイド』、『Oracle Databaseバックアップおよびリカバリ基礎』および『Oracle Database概要』を参照してください。 |
一般的に、フラッシュバック・テクノロジを使用した場合のリカバリ時間は、人為的エラーの発生に要した時間と人為的エラーの検出に要した時間の合計に等しくなります。
フラッシュバック・テクノロジでは、人為的エラーが発生した時点までリカバリすることが可能です。
次のリカバリ方法を使用できます。
誤ってデータベース・オブジェクトを削除することは、よくあります。ユーザーはすぐこの間違いに気付きますが、その時点ではすでに遅く、削除した表とその索引、制約、トリガーを簡単に元に戻す方法はなくなっています。以前は、一度削除したオブジェクトは永久的に失われていました。非常に重要な表やその他のオブジェクト（索引、パーティションまたはクラスタ）が失われた場合、DBAはポイント・イン・タイム・リカバリを実行する必要がありましたが、これは時間のかかる操作であり、最新のトランザクションは失われる可能性がありました。
Oracleでは、表の非一貫性の解決を支援するために、次の文が用意されています。
FLASHBACK TABLE文: データベースで、以前のある時点の表を復元します。
FLASHBACK DROP文: うっかりDROP TABLE文を実行した場合にリカバリします。
FLASHBACK TRANSACTION文: データベースをオンラインにしたままで、1つまたは複数のトランザクションとその依存トランザクションをロールバックします。
フラッシュバック表
FLASHBACK TABLEを使用すると、1つの表または表のセットを特定の時点に迅速にリカバリできます。多くの場合、フラッシュバック表を使用することで、ポイント・イン・タイム・リカバリ操作の複雑さが軽減されます。たとえば、次のようになります。
FLASHBACK TABLE orders, order_items
TO TIMESTAMP
TO_DATE('28-Jun-08 14.00.00','dd-Mon-yy hh24:mi:ss');
この文により、タイムスタンプで指定した過去の時点から現在までの間に発生したORDERS表とORDER_ITEMS表に対するすべての更新が元に戻されます。フラッシュバック表では、この操作がオンラインでインプレース実行されると同時に、表間の参照整合性制約も維持されます。
フラッシュバック・ドロップ
フラッシュバック・ドロップは、Oracle Database 10g以上のリリースでオブジェクトを削除する際のセーフティ・ネットとなります。ユーザーが表を削除すると、その表はごみ箱に配置されます。ごみ箱のオブジェクトは、ユーザーがそれらを永久的に削除することを決定するまで、またはその表を含む表領域の領域制限に到達するまでそのまま格納されます。ごみ箱は、すべての削除済オブジェクトが存在する仮想的なコンテナです。ユーザーは、ごみ箱を参照して、削除済の表とその依存オブジェクトを元に戻すことができます。たとえば、employees表とそのすべての依存オブジェクトを元に戻すには、次の文を使用します。
FLASHBACK TABLE employees TO BEFORE DROP;
フラッシュバック・トランザクション
Oracleフラッシュバック・トランザクションでは、データベースをオンラインにしたままで、特定のトランザクションまたはトランザクションのセットを簡単かつ迅速に取り消すことができ、ロジカル・リカバリ時の可用性が向上します。
トランザクションとその依存トランザクションをロールバックするには、DBMS_FLASHBACK.TRANSACTION_BACKOUT() PL/SQLプロシージャを使用します。このプロシージャは、UNDOデータを使用して、影響を受けたデータをトランザクション前の状態に戻す補正トランザクションを作成、実行します。
|
関連項目:
|
行およびトランザクションの非一貫性を解決するには、フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せ、および問題を修正するためのUNDO文で構成された補正SQL文を組み合せて使用する必要があります。この項では、人事管理の例を使用して、間違いによる（または悪意のある）ユーザー・エラーによって引き起こされた行およびトランザクションの非一貫性を解決するための一般的な方法について説明します。
フラッシュバック問合せ
フラッシュバック問合せでは、管理者やユーザーが以前のある時点でのデータを問合せできます。この機能は、間違って削除または変更されたデータを参照および再構築する際に使用します。
開発者は、フラッシュバック問合せを使用して、アプリケーションにセルフサービスのエラー修正機能を組み込み、エンド・ユーザーにエラーをすぐに元に戻して修正する機能を提供し、それらの作業からデータベース管理者を解放します。過去に設定された時間に合せてデータを再構築するのに必要な情報は、データベースで自動的に維持されるため、フラッシュバック問合せの管理は簡単です。
次の部分的な文により、2008年6月28日午後2時以降のEMPLOYEES表から行が選択されて表示されます。
SELECT * FROM EMPLOYEES
AS OF TIMESTAMP
TO_DATE('28-Jun-08 14:00','DD-Mon-YY HH24:MI')
WHERE ...
フラッシュバック・バージョン問合せ
フラッシュバック・バージョン問合せでは、データベースの変更を行レベルで参照できます。これは、SQLの拡張機能であり、指定した時間間隔で異なるバージョンの行をすべて取得できます。たとえば、次のようになります。
SELECT * FROM EMPLOYEES
VERSIONS BETWEEN TIMESTAMP
TO_DATE('28-Jun-08 14:00','dd-Mon-YY hh24:mi') AND
TO_DATE('28-Jun-08 15:00','dd-Mon-YY hh24:mi')
WHERE ...
この文により、2008年6月28日の午後2時から3時の間における各バージョンの行（異なるトランザクションによって変更された各エントリ）が表示されます。データベース管理者は、この機能を使用して、データがいつどのように変更されたかを特定し、関連するユーザー、アプリケーションまたはトランザクションを追跡することが可能です。これにより、データベース管理者は、データベースの論理破損の原因を追跡して修正できます。また、アプリケーション開発者は、自分のコードをデバッグできます。
フラッシュバック・トランザクション問合せ
フラッシュバック・トランザクション問合せでは、データベースの変更をトランザクション・レベルで参照できます。これは、SQLの拡張機能であり、トランザクションによるすべての変更を参照できます。たとえば、次のようになります。
SELECT UNDO_SQL FROM FLASHBACK_TRANSACTION_QUERY WHERE XID = '000200030000002D';
この文により、このトランザクションに基づくすべての変更が表示されます。また、補正SQL文が戻されるため、その文を使用してこのトランザクションで変更されたすべての行を元に戻すことができます。フラッシュバック・トランザクション問合せのような精度の高いツールを使用することで、データベース管理者とアプリケーション開発者は、データベースやアプリケーションの論理問題を正確に診断および修正できます。
ここでは、SCOTTスキーマに関連する人事管理（HR）の例について検討します。HRマネージャから、Wardの給与に食い違いがあるようだという報告がデータベース管理者に入ります。Wardの給与は、午前9時前のどこかの時点で1875ドルに上昇しました。HRマネージャは、この変更がどうして起こったのかわからないため、いつこの従業員の給与が上がったのかを把握するつもりです。また、HRマネージャは、スタッフに指示してWardの給与を以前のレベルの1250ドルに再設定しました。この作業は、午前9時15分ごろには完了しました。
この問題に対処するには、次の手順を実行します。
問題を評価します。
変更の発生した時刻に関する情報は、HRマネージャから提供されています。フラッシュバック問合せを使用して、午前9時の時点での情報を問い合せます。
SELECT EMPNO, ENAME, SAL
FROM EMP
AS OF TIMESTAMP TO_DATE('28-JUN-08 09:00','dd-Mon-yy hh24:mi')
WHERE ENAME = 'WARD';
EMPNO ENAME SAL
---------- ---------- ----------
7521 WARD 1875
Wardの給与が午前9時の時点で1875ドルであったという事実から、正しい従業員を選択したことを確認できます。後続の調査では、Wardの名前ではなく従業員番号を使用できます。
トランザクション情報を取得するため、データの以前の行またはバージョンを問い合せます。
行バージョン情報を特定の日付またはSCNの範囲に制限することも可能ですが、フラッシュバック・バージョン問合せを使用すると、従業員WARDについて使用可能なすべての行情報を問い合せることができます。
SELECT EMPNO, ENAME, SAL, VERSIONS_STARTTIME, VERSIONS_ENDTIME, VERSIONS_XID
FROM EMP
VERSIONS BETWEEN TIMESTAMP MINVALUE AND MAXVALUE
WHERE EMPNO = 7521
ORDER BY NVL(VERSIONS_STARTSCN,1);
EMPNO ENAME SAL VERSIONS_STARTTIME VERSIONS_ENDTIME VERSIONS_XID
----- ------ --- ---------------------- -------------------- ---------------
7521 WARD 1250 28-JUN-08 08.48.43 AM 28-JUN-08 08.54.49 AM 0006000800000086
7521 WARD 1875 28-JUN-08 08.54.49 AM 28-JUN-08 09.10.09 AM 0009000500000089
7521 WARD 1250 28-JUN-08 09.10.09 AM 000800050000008B
WARDの給与は、今朝の08:54:49に1250ドルから1875ドルに上がり、その後09:10:09ごろに1250ドルに戻されたことがわかります。
また、WARDの給与を1875ドルに上げた不適切なトランザクションのIDが、0009000500000089であることもわかります。
不適切なトランザクションとその影響範囲を問い合せます。
フラッシュバック・トランザクション問合せにトランザクション情報（VERSIONS_XID擬似列）を指定してデータベースに問い合せ、トランザクションの範囲を確認します。
SELECT UNDO_SQL
FROM FLASHBACK_TRANSACTION_QUERY
WHERE XID = HEXTORAW('0009000500000089');
UNDO_SQL
----------------------------------------------------------------------------
update "SCOTT"."EMP" set "SAL" = '950' where ROWID = 'AAACV4AAFAAAAKtAAL';
update "SCOTT"."EMP" set "SAL" = '1500' where ROWID = 'AAACV4AAFAAAAKtAAJ';
update "SCOTT"."EMP" set "SAL" = '2850' where ROWID = 'AAACV4AAFAAAAKtAAF';
update "SCOTT"."EMP" set "SAL" = '1250' where ROWID = 'AAACV4AAFAAAAKtAAE';
update "SCOTT"."EMP" set "SAL" = '1600' where ROWID = 'AAACV4AAFAAAAKtAAB';
6 rows selected.
このトランザクションでは、WARDの給与以外にも変更が発生していたことがわかります。WARDと同様に変更されていた他の4人の従業員情報を、確認のためHRマネージャに戻します。
修正用の文を実行するかどうかを確認します。
UNDO_SQL列に示された修正用の変更文がHRマネージャによって正しいと判断されたら、データベース管理者はその文を個別に実行できます。
FLASHBACK_TRANSACTION_QUERYビューを問い合せて追加のトランザクション情報を取得します。たとえば、間違った更新を実行したユーザーを確認するには、次の問合せを発行します。
SELECT LOGON_USER FROM FLASHBACK_TRANSACTION_QUERY
WHERE XID = HEXTORAW('0009000500000089');
LOGON_USER
----------------------------
MSMITH
この例の場合、ユーザーMSMITHが間違ったトランザクションを実行していたことがわかります。
Oracleデータベースを以前の時点に戻すための従来の方法は、ポイント・イン・タイム・リカバリです。ただし、ポイント・イン・タイム・リカバリには、数時間または数日かかる可能性があります。この理由は、データベース全体をバックアップからリストアし、エラーがデータベースで発生する直前の時点までリカバリする必要があるためです。データベース・サイズが一定の割合で増加している場合、データベース全体をリストアするだけで数時間または数日かかります。
フラッシュバック・データベースは、ポイント・イン・タイム・リカバリを実行するための手段です。この機能を使用すると、論理的データ破損またはユーザー・エラーを原因とする問題を修正するために、Oracleデータベースを過去の時点に迅速に戻すことができます。フラッシュバック・ログは、以前のバージョンの変更済ブロックを取得するのに使用されます。リカバリを実行する必要がある場合、データベースをエラー前の時点にリストアするためにフラッシュバック・ログが迅速に適用され、変更済ブロックがリストアされます。この処理は非常に高速であり、リカバリ時間は数時間から数分に短縮されます。また、この機能は簡単に使用できます。1つの文を発行することで、データベースを午後2時5分の時点にリカバリできます。データベースをリカバリするには、データベースのすべてのインスタンスを停止して、その後、インスタンスの1つをマウントする必要があります。次に、FLASHBACK DATABASE文の例を示します。
FLASHBACK DATABASE TO TIMESTAMP SYSDATE-1;
フラッシュバック・データベースを使用する場合、テープからのリストア、長い停止時間、および複雑なリカバリ手順は必要とされません。フラッシュバック・データベースを使用して、データベースを読取り専用モードでオープンし、その内容を調査することも可能です。フラッシュバックした時点が希望の位置と比べて前後した場合は、FLASHBACK DATABASE文を再発行するか、データベースが破損する前の適切な時点を見つけるために、より新しい時点にまでリカバリを続けることができます。フラッシュバック・データベースは、プライマリ・データベース、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースで動作します。
フラッシュバック・データベースを使用する際に推奨される手順は、次のとおりです。
データベースをフラッシュバックする日時またはSCNを決定します。
十分なフラッシュバック・ログ情報が存在することを確認します。
SELECT OLDEST_FLASHBACK_SCN,
TO_CHAR(OLDEST_FLASHBACK_TIME, 'mon-dd-yyyy HH:MI:SS')
FROM V$FLASHBACK_DATABASE_LOG;
データベースを特定の日時またはSCNにフラッシュバックします。（フラッシュバック・データベースを実行するにはデータベースをマウントする必要があります。）
FLASHBACK DATABASE TO SCN scn;
または
FLASHBACK DATABASE TO TIMESTAMP TO_DATE date;
データベースを読取り専用モードでオープンして、正しい状態になっていることを確認します。
ALTER DATABASE OPEN READ ONLY;
追加のフラッシュバック・データが必要な場合は、もう一度FLASHBACK DATABASE文を発行します。（フラッシュバック・データベースを実行するにはデータベースをマウントする必要があります。）
時間的に前に進めるには、次のような文を発行します。
RECOVER DATABASE UNTIL [TIME date | CHANGE scn];
データベースをオープンします。
ALTER DATABASE OPEN RESETLOGS;
フラッシュバック・データベースを使用する際のその他の考慮事項は、次のとおりです。
目的の時点にフラッシュバックするのに十分なフラッシュバック・ログが存在しない場合、次のいずれかの方法をかわりに使用します。
Data Guardを使用して、目的の時点にリカバリするか（スタンバイ・データベースがプライマリ・データベースより遅れている場合）、目的の時点にフラッシュバックします（スタンバイ・データベースに十分なフラッシュバック・ログが存在する場合）。
バックアップからリストアします。
データベースのフラッシュバック後は、スタンバイ・データベースなどの依存データベースもすべてフラッシュバックする必要があります。4.3項「フォルト・トレランスのリストア」を参照してください。
フラッシュバック・データベースでは、削除した表領域は自動的に修復されませんが、その機能を使用して停止時間を大幅に短縮できます。表領域が削除される前の時点にプライマリ・データベースをフラッシュバックして、関連する表領域から対応するデータファイルのバックアップをリストアし、表領域が削除される前の時点にリカバリできます。削除された表領域の修復に使用できる順次操作手順は、サポート・ノート783471.1を参照してください。
Recovery Manager（RMAN）の自動化された表領域のPoint-in-Timeリカバリ（TSPITR）を使用すると、データベースの1つまたは複数の表領域を、以前の時点まで迅速にリカバリでき、表領域の他の部分とデータベースのオブジェクトには影響を与えません。TSPITRは、データベースの他の部分からデータが完全に分離された表領域でのみ使用できます。つまり、通常、TSPITRの使用にあたっては、あらかじめ計画する必要があります。
RMAN TSPITRが最も有効なのは、次の状況です。
複数のロジカル・データベースが1つのフィジカル・データベースの別々の表領域に存在するときに、ロジカル・データベースをフィジカル・データベースの他の部分と異なる時点にリカバリする場合。たとえば、ロジカル・データベースのOrders表領域とPersonnel表領域を管理しているとします。不適切なバッチ・ジョブまたはDML文は、1つの表領域のデータのみを破損します。
表の構造を変更するDDL操作の後で失われたデータを回復する場合。FLASHBACK TABLEを使用しても、表の切捨て操作などの構造変更の時点以前に表を巻き戻すことはできません。
PURGEオプションで表を削除した後でその表をリカバリする場合。
表の論理破損からリカバリする場合。
RMAN RECOVER TABLESPACEコマンドを使用することにより、TSPITRを実行します。
|
関連項目: RMAN TSPITRの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Siebel、Peoplesoft、SAPなどの一部のアプリケーションは、複数のデータベースを更新し、分散トランザクションに参加する可能性があります。参加するデータベース間におけるグローバルな一貫性は、アプリケーションにとっての前提であり、非常に重要です。分散データベース環境の1つのデータベースを以前のある時点にリカバリする必要がある場合、通常は、構成内の他のすべてのデータベースを、アプリケーションによりグローバルなデータ一貫性が求められる過去の同じ時点までリカバリする必要があります。時間ベースの協調分散データベース・リカバリを行うには、次の手順を実行します。
時間ベースのリカバリを使用して、リカバリ操作を必要とするデータベースをリカバリします。
たとえば、メディア障害のためにデータベースをリカバリする必要がある場合、時間ベースのリカバリを使用して最初にこのデータベースをリカバリします。この時点では他のデータベースをリカバリしないでください。
データベースをリカバリし、RESETLOGSオプションを使用してデータベースをオープンしたら、データベースのalert_SID.logでRESETLOGSメッセージを検索します。次の手順は、次の表に示したとおり、ログ・ファイル内で見つかったメッセージに応じて変化します。
| 戻されたメッセージ | その後の手順 |
|---|---|
RESETLOGS after complete recovery through change nnn |
リカバリは完全です。データベースのすべての変更を適用し、完全リカバリを実行しました。データベースの変更が不必要に削除されるため、分散システムの他のデータベースはいずれもリカバリしないでください。 |
RESETLOGS after incomplete recovery UNTIL CHANGE nnn |
不完全リカバリの実行に成功しました。メッセージの変更番号を記録し、次の手順に進んでください。 |
変更ベースのリカバリを使用して分散データベース・システムの他のすべてのデータベースをリカバリまたはフラッシュバックします。このとき、手順2で記録した変更番号（SCN）を指定します。
|
注意: 分散トランザクションに参加するデータベースに障害が発生した場合、そのデータベースにインダウト分散トランザクションが存在する可能性があります。障害データベースが完全にリカバリされ、データベース間の通信が再開すると、インダウト・トランザクションはOracleリカバラ・プロセス（RECOプロセス）により自動的に解決されます。障害データベースが使用可能になるまで待機できない場合は、インダウト・トランザクションを手動でコミットまたはロールバックすることもできます。 |
|
関連項目:
|
高可用性アーキテクチャのコンポーネントに障害が発生すると、アーキテクチャの完全保護（フォルト・トレランス）は損われ、そのコンポーネントが修復されるまでシングル・ポイント障害の可能性が存在することになります。高可用性アーキテクチャに完全なフォルト・トレランスを回復し、Oracle RAC、Data GuardまたはMAAによる完全保護を再確立するには、障害コンポーネントを修復する必要があります。計画済の停止時間中には、完全なフォルト・トレランスは損われる可能性がありますが、その修復方法はよく理解されています。この停止は計画されたもので、リスクは制御されており、通常はアプリケーションの可用性を継続するのに最も適した時間に実行されるためです。ただし、計画外の停止時間においては、シングル・ポイント障害が発生する可能性を明確に理解する必要があります。
この項には、データベースのフォルト・トレランスを回復するのに必要な手順を記載した次の項目が含まれます。
Oracle RACを使用したOracle Database 11gの場合
Data Guardを使用したOracle Database 11gと、Oracle RACおよびData Guardを使用したOracle Database 11g（MAA）の場合
アプリケーション・サービスをOracle RACクラスタ内（またはプライマリ・サイトとセカンダリ・サイト間）で自動的にすばやくフェイルオーバーすることは、計画済の停止と計画外の停止の両方に備えるうえで重要です。また、エラーまたは問題の修正後に、環境で完全なフォルト・トレランスを回復するためには、Oracle RACクラスタ内または各サイトのデータベースで障害インスタンスや障害ノードをリストアするための手順およびプロセスを理解しておくことも重要です。
特定のコンポーネントに最初に障害を発生させる原因となった主要な問題を修正したら、クラスタに障害ノードを戻すことや、Oracle RACの障害インスタンスを再起動することは簡単です。ただし、次のことを検討する必要があります。
現在稼働中の環境に影響をまったく与えないか、最小限の影響で抑えるためにこれらのタスクを実行するのに最適な時期
フェイルオーバー用に変更したため、再設定する必要のあるネットワーク・コンポーネント（ロード・バランサなど）の再構成
既存の接続のフェイルバックまたは再調整
ノードまたはインスタンスの最初の障害を引き起こした問題を修正したら、ノードまたはインスタンスを再起動していつでもOracle RAC環境に戻すことができます。ノードの再構成を完了するための処理では、追加のシステム・リソースを必要とする場合があります。
表4-9に、ノードの追加時に必要とされる可能性のある追加処理をまとめます。
表4-9 ノードまたはインスタンスの再起動または再結合時の追加処理
| アクション | 追加リソース |
|---|---|
|
ノードの再起動またはクラスタへのノードの再結合 |
Oracleクラスタウェアのみを使用している場合、ノードをクラスタに結合することによる影響はありません。 ベンダーのクラスタウェアを使用している場合、ノードをクラスタに戻すための再構成中にパフォーマンスが低下する可能性があります。現在のアプリケーションに対する影響は、フル・ワークロードのテストで評価しておく必要があります。 |
|
Oracle RACインスタンスの再起動または再結合 |
Oracle RACインスタンスを再起動する場合、ロックの再構成中はパフォーマンスに多少影響する可能性があります。現在のアプリケーションに対する影響は、通常はほとんどありませんが、フル・ワークロードのテストで評価しておく必要があります。 |
|
関連項目:
|
次のリカバリ方法を使用できます。
障害ノードがクラスタに戻され、そのインスタンスが起動されると、Cluster Ready Services（CRS）によってノードで使用される仮想IPアドレスと、インスタンスでサポートされるサービスが自動的に管理されます。リストアされたインスタンスでは、特定のサービスが起動される場合と起動されない場合があります。CRSがリストアされたインスタンスでサービスを起動するかどうかは、サービスがどのように構成されているかと、その時点で適切な数のインスタンスがサービスへのアクセスを提供しているかどうかによって決定されます。最初の障害が発生したときにCRSによって移動された稼働中のインスタンスで、サービスが現在も適切に提供されている場合、そのサービスは優先インスタンスに再配置されません。CRSがリストアされたインスタンスでサービスを再起動するのは、クラスタ全体でサービスへのアクセスを提供しているインスタンスの数が、そのサービスに定義されている優先インスタンスの数より少ない場合です。CRSは、リストアされたインスタンスでサービスを再起動すると、登録アプリケーションにサービスの変更を通知します。
たとえば、優先インスタンスAおよびBと、障害時用の使用可能インスタンスCおよびDで定義されているHRサービスがあるとします。インスタンスBに障害が発生すると、CRSはインスタンスCで自動的にHRサービスを起動します。その後インスタンスBが再起動しても、HRサービスはインスタンスCで稼働を続けます。CRSは、サービスを自動的に優先インスタンスに再配置しません。
次に、別の使用例を検討します。HRサービスが優先インスタンスA、B、CおよびDで定義されており、使用可能インスタンスは存在せず、サービスはクラスタ内のすべてのノードに分散されているとします。インスタンスBに障害が発生すると、HRサービスは残りの3つのノードで稼働を続けます。CRSは、インスタンスBがクラスタに再結合されると、インスタンスBでHRサービスを自動的に起動します。これは、サービスの稼働しているインスタンスの数が、構成されているインスタンスの数より少ないためです。CRSは、アプリケーションに対して、HRサービスがインスタンスBで再び使用可能になったことを通知します。
|
関連項目: 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』 |
Oracle RACインスタンスのリストア後、システムの現在のリソース使用状況とパフォーマンス、アプリケーション構成、および実装されているネットワーク・ロード・バランシング機能によっては、追加の手順を実行する必要があります。
稼働を続けるOracle RACインスタンスに移行された（フェイルオーバーされたか、新規セッションとして開始された）既存の接続は、再起動されたインスタンスに自動的に再分散またはフェイルバックされません。ユーザーのフェイルバックまたは再分散は、必要な場合と必要でない場合があります。この決定は、現在のリソース使用状況と、ワークロードを適切に処理して許容可能なレスポンス時間内に応答できる稼働中のインスタンスの能力に応じて変化します。稼働を続けるOracle RACインスタンスがフル・ワークロードを実行するのに十分なリソースを保持していないか、許容可能なレスポンス時間内に応答できない場合は、再起動されたインスタンスに既存のユーザー接続の一部を移行（切断および再接続）する必要があります。
接続ロード・バランシングが構成されている場合は、使用頻度の最も低いノードで必要に応じて接続が開始されます。したがって、接続は、時間の経過とともに自動的に分散されます。
アプリケーション・サービスでは、次の構成を使用できます。
Oracle RACインスタンスのサブセットで稼働するサービスで管理される構成。
パーティション化しない構成: すべてのサービスがすべてのノードで均等に稼働します。
これは、データセットの結合を維持したままアプリケーションおよびデータベースの形式と機能をモジュール化する際に役立ちます。アプリケーションをパーティション化する場合、またはパーティション化と非パーティション化の組合せを使用する場合、各サービスのレスポンス時間と可用性を考慮する必要があります。特定のサービスの接続を再分散またはフェイルバックする必要がある場合、次のことが可能です。
Oracle Universal Connection Pool（UCP）を使用して、自動的にワークロードを再調整できます。UCPを使用している場合、接続は新しいノードに自動的に再分散されます。
DBMS_SERVICE.DISCONNECT_SESSION PL/SQLプロシージャを使用して手動でワークロードを再調整できます。このプロシージャを使用すると、サービスの実行を続けながらそのサービスに関連付けられたセッションを切断できます。
|
注意: Oracle Universal Connection Pool（UCP）は、高速接続フェイルオーバーとFANイベントを使用して、接続障害を高速かつ自動的に検出し、Javaアプリケーションの終了した接続を削除します。 |
複数のOracle RACインスタンス全体でアプリケーション・サービスの負荷分散を行う場合、Oracle Netの接続時フェイルオーバーと接続ロード・バランシングを使用することをお薦めします。この機能では、フェイルオーバーやリストアに応じた変更作業が必要ありません。ハードウェア・ベース・ロード・バランサを使用することも可能です。ただし、（Oracle Net Servicesでは認識される）個別のアプリケーション・サービスの区別と、インスタンスまたはノードのリストアに対して制限が加えられる可能性があります。たとえば、ノードまたはインスタンスがリストアされて接続の受信が開始される場合、リストアされたノードまたはインスタンスをハードウェア・ベース・ロード・バランサのロジックに含めるための手動による手順が必要になる可能性があります。これに対し、Oracle Net Servicesでは手動による再構成は必要ありません。
表4-10に、インスタンス・リストア後の新規および既存の接続に関する考慮事項をまとめます。これらの考慮事項は、パーティション化、非パーティション化、またはその両方の組合せというアプリケーション・サービスの構成に応じて変化します。既存の接続の再分散が実際に必要であるかどうかは、リソース使用状況とレスポンス時間に応じて決定されます。
表4-10 リストアおよび接続フェイルバック
| アプリケーション・サービス | 既存の接続のフェイルバックまたはリストア | 新規接続のフェイルバックまたはリストア |
|---|---|---|
|
パーティション化 |
既存のセッションは、リストアされたインスタンスに自動的に再配置されません。 |
Oracle Net Services構成の使用により、リストアされたインスタンスに自動的にルーティングされます。 |
|
非パーティション化 |
インスタンスがリストアされた時点でそのインスタンスの負荷は低いため、負荷を再調整する必要がなければ特に何もする必要はありません。負荷を再調整する必要がある場合は、アプリケーション・サービスをパーティション化している場合と同様の問題が発生します。 |
Oracle Net Services構成の使用により、リストアされたインスタンスに自動的にルーティングされます（そのインスタンスの負荷が最も低いため）。 |
図4-6は、2つのノードでパーティション化されたOracle RACデータベースを示しています。各インスタンスでは、異なるアプリケーション機能（HRおよびSales）が提供されます。クライアント・プロセスは、必要とするサービスに基づいて適切なインスタンスに接続します。
図4-7は、1つのOracle RACインスタンスに障害が発生した場合を示しています。
図4-7 パーティション化されたデータベースでのOracle RACインスタンスのフェイルオーバー
1つのOracle RACインスタンスに障害が発生すると、サービスと既存のクライアント接続は、別のOracle RACインスタンスに自動的にフェイルオーバーされます。この例の場合、HRサービスとSalesサービスは、両方とも稼働を続けるOracle RACインスタンスによってサポートされます。また、Salesサービスに対する新規クライアント接続は、Salesサービスのサポートを開始したインスタンスにルーティングされます。
障害インスタンスが修復およびリストアされて図4-6の状態に戻り、Salesサービスがリストアされたインスタンスに再配置されると、フェイルオーバーされたクライアントと、フェイルオーバー先のインスタンスのSalesサービスに接続されていた新規クライアントは、それぞれ識別されてフェイルバックされる可能性があります。インスタンスのリストア後に開始したクライアント接続は、自動的に元のインスタンスに接続されます。したがって、時間の経過とともに古い接続は切断され、新規セッションはSalesサービスに接続されるため、クライアント負荷はリストアされたインスタンスに戻ります。リストアの直後に負荷の再調整が発生するかどうかは、リソース使用状況とアプリケーションのレスポンス時間に応じて決定されます。
図4-8は、パーティション化されていないアプリケーションを示しています。サービスは、アクティブな2つのインスタンス間で均等に分散されます。各インスタンスには、HRとSalesに対するクライアント接続が混在しています。
1つのOracle RACインスタンスに障害が発生すると、障害インスタンスで稼働していたサービスはCRSにより移動されます。また、新規クライアント接続は、同じサービスを提供する使用可能なOracle RACインスタンスにのみルーティングされます。
障害インスタンスが修復およびリストアされて図4-8の状態に戻ると、一部のクライアントはリストアされたインスタンスに戻される可能性があります。パーティション化されていないアプリケーションでは、すべての使用可能なインスタンス間でクライアント負荷を再調整するために適切なサービスを識別する必要はありません。この処理は、単一インスタンス・データベースでリクエストを十分に処理できない場合にのみ必要です。
インスタンスのリストア後に開始したクライアント接続は、自動的にリストアされたインスタンスに接続されます（そのインスタンスの負荷が他と比べて低いためです）。したがって、時間の経過とともに古い接続は切断され、新規セッションはリストアされたインスタンスに接続されるため、クライアント負荷は再び使用可能なすべてのOracle RACインスタンス間で均等に分散されます。リストアの直後に負荷の再調整が発生するかどうかは、リソース使用状況とアプリケーションのレスポンス時間に応じて決定されます。
フェイルオーバーを必要とするプライマリ・データベースの計画外の停止後、スタンバイ・データベースが再確立されるまで完全なフォルト・トレランスは損われます。データベースの完全保護は、可能なかぎり迅速に回復する必要があります。フォルト・トレランスを回復する手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースで多少異なります。
Data Guardファスト・スタート・フェイルオーバーを使用している場合、データベースは自動的に復元されます。ファスト・スタート・フェイルオーバーが完了すると、オブザーバは、自動的に元のプライマリ・データベースをスタンバイ・データベースとして復元するよう試みます。復元により、ブローカ構成に高可用性が回復され、新規プライマリ・データベースに障害が発生した際に再度ファスト・スタート・フェイルオーバーを起動できます。復元されたデータベースは、新規プライマリ・データベース用としてファスト・スタート・フェイルオーバーのターゲットとなるため、再度のファスト・スタート・フェイルオーバーが可能になります。スタンバイ・データベースは、新規プライマリ・データベースから受信されたREDOデータの適用を開始することで、フェイルオーバーの実行可能なターゲットとなります。フェイルオーバーの完了後に診断作業や修復作業を実行するなど、自動復元を行わない場合、FastStartFailoverAutoReinstate構成プロパティをFALSEに設定します。
FastStartFailoverAutoReinstate構成プロパティは、ファスト・スタート・フェイルオーバーが発生した後、オブザーバーが元のプライマリを自動的に回復するかどうかを制御します。これは、ファスト・スタート・フェイルオーバーが開始された理由が、FastStartFailoverThresholdプロパティで指定された秒数より長くプライマリ・データベースが分離されていたことであるためです。状況によっては、詳細な診断またはリカバリ作業が完了するまで自動復元を抑止することが可能です。
元のプライマリ・データベースを復元する場合、データベースを起動してマウントする必要がありますが、オープンすることはできません。ブローカは、元のスタンバイ・データベースと同じタイプ（フィジカルまたはロジカル）のスタンバイ・データベースとしてデータベースを復元します。
元のプライマリ・データベースが自動的に復元されない場合、DGMGRL REINSTATEコマンドまたはEnterprise Managerを使用して手動で復元できます。手動復元の詳細な手順は、『Oracle Data Guard Broker』を参照してください。
Oracleのフラッシュバック・データベース機能を使用する場合、スタンバイ・データベースを再作成する必要はありません。フラッシュバック・データベースには、次のメリットがあります。
数時間に及ぶデータベースのリストア時間を節約できます。
フォルト・トレランスを回復する際の全体的な複雑さを軽減できます。
スタンバイ・データベースが迅速に再作成されるため、システムが脆弱である時間が短縮されます。
|
関連項目: 『Oracle Data Guard概要および管理』の次の項を参照してください。
|
この項には、次の各項目が含まれます。
ファスト・スタート・フェイルオーバーの後、オブザーバは、定期的に以前のプライマリ・データベースに再接続するよう試みます。以前のプライマリ・データベースへのネットワーク・アクセスを再確立すると、オブザーバは、ブローカに対するリクエストを起動して、そのデータベースを新規プライマリ・データベース用のスタンバイ・データベースとして自動的に復元します。これにより、構成における障害保護と高可用性が迅速に回復されます。
ファスト・スタート・フェイルオーバーは、ブローカ構成内のデータベースに接続しながら、Enterprise Managerでオブザーバ・サイトを含む任意のサイトから有効化できます。ブローカでは、図4-9に示されているOracle Enterprise Managerのページでボタンを1回クリックするだけで簡単にスイッチオーバーやフェイルオーバーを起動できます。
Enterprise Managerを使用して、元のプライマリ・データベースを新規スタンバイ・データベースとして復元することも可能です。図4-10は、復元が必要な場合にEnterprise Managerに表示される警告メッセージの例を示しています。
4.2.5.3項「データ領域ディスク・グループ障害」または4.2.5.4項「フラッシュ・リカバリ領域ディスク・グループ障害」の手順に従ってください。
セカンダリ・サイトで計画済のメンテナンスを実行したら、スタンバイ・データベースとログ適用サービスを再起動する必要があります。その後、Data Guard REDO転送サービスによって自動的にスタンバイ・データベースがプライマリ・データベースに同期されます。Enterprise Managerとブローカを使用して、Data Guardの状態を監視できます。
セカンダリ・サイトでの計画済の停止後、またはクラスタ全体の停止後に、次の手順を実行して完全なフォルト・トレランスを回復する必要があります。
|
注意: 次の手順は、（後述の説明のとおり）手動で実行するか、Enterprise Managerを使用して自動で実行することができます。 |
スタンバイ・データベースを起動します。
スタンバイ・データベースは、ローカル・バックアップ、ローカル・テープ・バックアップまたはプライマリ・サイト・バックアップ（セカンダリ・サイトのデータが破損している場合）からリストアする必要があります。『Oracle Data Guard概要および管理』のスタンバイ・データベースを作成する手順に従って、新規プライマリ・データベースからスタンバイ・データベースを再作成します。
スタンバイ・データベースを再確立したら、スタンバイ・データベースを起動します。
REDO Apply（フィジカル・スタンバイ）またはSQL Apply（ロジカル・スタンバイ）を開始します。
プライマリ・データベースでREDO転送サービスを検証します。
状況により、プライマリ・データベースのリモート・アーカイブの宛先を再有効化する必要があります。最初にV$ARCHIVE_DEST_STATUSビューを問い合せて、アーカイブの宛先の現在の状態を確認します。
SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR, SRL
FROM V$ARCHIVE_DEST_STATUS;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
ALTER SYSTEM ARCHIVE LOG CURRENT;
エラーをチェックしてプライマリ・データベースとスタンバイ・データベース間のREDO転送サービスを検証します。V$ARCHIVE_DESTビューとV$ARCHIVE_DEST_STATUSビューを問い合せます。
SELECT STATUS, TARGET, LOG_SEQUENCE, TYPE, PROCESS, REGISTER, ERROR
FROM V$ARCHIVE_DEST;
SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS!='INACTIVE';
リカバリがスタンバイ・データベースで進行中であることを確認します。
フィジカル・スタンバイ・データベースの場合、管理リカバリ・プロセスからのエラーがないことと、アーカイブREDOログ・ファイルからREDOが適用されていることを次のように確認します。
SELECT MAX(SEQUENCE#), THREAD# FROM V$LOG_HISTORY GROUP BY THREAD;
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, CLIENT_PROCESS
FROM V$MANAGED_STANDBY;
ロジカル・スタンバイ・データベースの場合、ロジカル・スタンバイ・プロセスからのエラーがないことと、アーカイブREDOログからREDOが適用されていることを次のように確認します。
SELECT THREAD#, SEQUENCE# SEQ#
FROM DBA_LOGSTDBY_LOG LOG, DBA_LOGSTDBY_PROGRESS PROG
WHERE PROG.APPLIED_SCN BETWEEN LOG.FIRST_CHANGE# AND LOG.NEXT_CHANGE#
ORDER BY NEXT_CHANGE#;
プライマリ・データベースの保護モードを回復します。
スタンバイ・データベースの停止のために、プライマリ・データベースの保護モードを最大保護モードから最大可用性モードまたは最大パフォーマンス・モードに変更する必要があった場合、ビジネス要件に応じて最大保護モードに戻します。
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE [PROTECTION | AVAILABILITY];
|
関連項目: 『Oracle Data Guard概要および管理』 |
データ障害やメディア障害など、データファイルの完全リストアまたは部分リストアを必要とするスタンバイ・データベースでの計画外の停止後、スタンバイ・データベースが稼働を再開するまで完全なフォルト・トレランスは損われます。データベースの完全保護は、可能なかぎり迅速に回復する必要があります。
ロジカル・スタンバイ・データベースのデータ破損およびデータ障害を修復するには、プライマリ・データベースのバックアップではなく、ロジカル・スタンバイ・ファイルのバックアップが必要です。それ以外の方法では、破損によって影響を受けた関連オブジェクトを回復するか、再作成する必要があります。スタンバイ・データベースのデータ破損またはデータ障害を修復する場合、次の修復ソリューションを使用できます。
ロジカル・スタンバイ・データベース専用の手動によるオブジェクトの再作成（4.2.6.5項を参照）
スタンバイ・データベースの停止のために、プライマリ・データベースの保護モードを最大保護モードから最大可用性モードまたは最大パフォーマンス・モードに変更する必要があった場合、ビジネス要件に応じて最大保護モードに戻します。
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE [PROTECTION | AVAILABILITY];
プライマリ・データベースが、論理エラーの修正のためにフラッシュバックされたか、任意の時点にリストアおよびリカバリされてアクティブ化された場合、状況によっては対応するスタンバイ・データベースで追加メンテナンスを実行する必要があります。プライマリ・データベースのリカバリがリセットログ操作なしで完了した場合、追加の作業は必要ありません。
RESETLOGSオプション付きでプライマリ・データベースをオープンした後に、表4-13の問合せを実行します。
表4-13 RESETLOGS SCNと現在のSCN OPEN RESETLOGSを確認するための問合せ
| データベース | 問合せ |
|---|---|
|
プライマリ |
|
|
フィジカル・スタンバイ |
|
|
ロジカル・スタンバイ |
|
表4-14に、スタンバイ・データベースがプライマリ・データベースのリセットログSCNより遅れている場合に、フォルト・トレランスを回復するために実行できるアクションを示します。
表4-14 スタンバイ・データベースのSCNがプライマリ・データベースのRESETLOGS SCNより遅れている場合のアクション
| データベース | アクション |
|---|---|
|
フィジカル・スタンバイ |
|
|
ロジカル・スタンバイ |
スタンバイ・データベースがプライマリ・データベースからアーカイブREDOログ・ファイルを受信していることを確認します。 |
表4-15に、スタンバイ・データベースがプライマリ・データベースのリセットログSCNより進んでいる場合に、フォルト・トレランスを回復するために実行できるアクションを示します。
表4-15 スタンバイ・データベースのSCNがプライマリ・データベースのリセットログSCNより進んでいる場合のアクション
| データベース | アクション |
|---|---|
|
フィジカル・スタンバイ |
|
|
ロジカル・スタンバイ |
|
スタンバイ・データベースとプライマリ・データベースの両方に影響する二重障害が発生した場合、先にプライマリ・データベースを再作成する必要があります。各サイトは同一であるため、最新のバックアップが存在する場所であればどこでもプライマリ・データベースを作成できます。
表4-16に、使用可能なバックアップのタイプに応じたリカバリ計画をまとめます。
表4-16 プライマリ・データベースとスタンバイ・データベースの再作成
| 使用可能なバックアップ | プライマリ・データベースの再作成 |
|---|---|
|
プライマリ・データベースとスタンバイ・データベースのローカル・バックアップ |
プライマリ・データベースのバックアップをリストアします。データベースをリカバリして新規プライマリ・データベースとしてアクティブ化します。 |
|
スタンバイ・データベースにのみ存在するローカル・バックアップ。スタンバイ・データベースのテープ・バックアップ。 |
スタンバイ・データベースのローカル・バックアップをスタンバイ・データベースにリストアします。データベースをリカバリして新規プライマリ・データベースとしてアクティブ化します。 |
|
テープ・バックアップのみ |
テープ・バックアップをローカルでリストアします。データベースをリカバリして新規プライマリ・データベースとしてアクティブ化します。 |
|
関連項目: プライマリ・データベースの再作成後、スタンバイ・データベースを作成する手順の詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
