| Oracle® Database高可用性ベスト・プラクティス 12cリリース1 (12.1) E57730-02 |
|
 前 |
 次 |
この章では、計画外の各停止タイプを許容するか管理することで停止時間を最小化できるOracle運用ベスト・プラクティスについて説明します。
この章には、次の項目が含まれます。
この項では、プライマリまたはセカンダリ・サイト・コンポーネントに影響する計画外の停止について説明し、推奨される修復方法または各停止に関連する停止時間を最小化するために推奨される方法について説明します。
計画外の停止は、アプリケーションをサポートするテクノロジ・インフラストラクチャのいずれかの部分に予期しない障害が発生することを示します。これには、次のコンポーネントが含まれます。
ハードウェア
ソフトウェア
ネットワーク・インフラストラクチャ
ストレージ・インフラストラクチャ
ネーミング・サービス・インフラストラクチャ
データベース
データ・センター
監視および高可用性インフラストラクチャでは、迅速な検出作業を行って停止時間からの回復を図る必要があります。
計画外の停止を解決することが、システムの最大可用性にとって不可欠です。表12-1に、4つのMAA参照アーキテクチャの比較と、プライマリ・サイトでの計画外の停止に対応するためのリカバリ手順の概要を示します。MAA参照アーキテクチャは、『Oracle Database高可用性概要』を参照してください。複数のリカバリ手順を必要とする停止については、この表に、12.2項「計画外の停止からのリカバリ」の詳細な説明へのリンクが含まれます。
表12-1 プライマリ・サイトでの計画外の停止のリカバリ時間および手順
| 停止範囲 | Bronze: 単一インスタンスHAとバックアップ | Silver: Oracle RAC | Gold: Oracle RACとOracle Active Data Guard脚注1 | Platinum: Oracle 12c MAAとPlatinum対応のアプリケーション |
|---|---|---|---|---|
|
|
数時間から数日
|
数時間から数日
|
数秒から数分脚注2 |
アプリケーションの停止なし |
|
|
適用なし |
数時間から数日
|
数秒から数分 |
アプリケーションの停止なし |
|
リカバリ可能なサーバー障害(ノード) |
数分から1時間
|
数秒脚注3 |
数秒脚注3 |
アプリケーションの停止なし |
|
データベース・インスタンス障害 |
数分
|
数秒脚注3 |
数秒脚注3 |
アプリケーションの停止なし
|
|
|
停止時間なし脚注4 |
停止時間なし脚注4 |
停止時間なし脚注4 |
停止時間なし脚注4 |
|
|
数分から数時間 |
数分から数時間 |
Oracle Active Data Guardでは停止時間ゼロが可能: 12.2.7.2項「Active Data Guardの使用」 数秒から数分 |
Active Data Guardでは停止時間ゼロが可能: 12.2.7.2項「Active Data Guardの使用」 アプリケーション停止ゼロまたはデータ損失フェイルオーバーが必要な場合は数秒 |
|
|
30分未満脚注5 |
30分未満脚注5 |
30分未満脚注5 |
30分未満脚注5 |
|
|
カスタマイズ済で構成可能脚注6 |
カスタマイズ済で構成可能脚注6 |
カスタマイズ済で構成可能脚注7 |
12.2.5項「アプリケーション・コンティニュイティおよびトランザクション・ガードによるアプリケーション・フェイルオーバー」 |
脚注1 Data Guardの物理レプリケーションはOracleデータベースで最も一般的に使用されるデータ保護および可用性ソリューションですが、アプリケーションの制御によって実装が可能になる場合には特に、アクティブ/アクティブ論理レプリケーションが望ましい場合があります。これらの要件に対して、Oracle GoldenGateをData Guardのかわりに使用できます。物理レプリケーションと論理レプリケーションのトレードオフの詳細は、http://www.oracle.com/technetwork/database/features/availability/dataguardgoldengate-096557.htmlで「Oracle Active Data Guard and Oracle GoldenGate」のトピックを参照してください。
脚注2 このリカバリ時間は、データベースおよび既存の接続フェイルオーバーに適用されます。ネットワーク接続の変更やサイト固有の他のフェイルオーバー・アクティビティによっては、リカバリ時間全体が増加する可能性があります。
脚注3 データベースは引き続き使用可能ですが、障害が発生したシステムに接続しているアプリケーションの一部が一時的に影響を受け、Oracle RACまたはOracle RAC Oneのどちらを使用しているかによって数秒から数分ブラウンアウトすることがあります。
脚注4ストレージ障害は、ミラー化および自動リバランス機能のあるOracle ASMを使用して防止されます。
脚注5 人為的エラーからのリカバリ時間は、主に検出時間に依存します。不適切なDMLまたはDLLトランザクションの検出に数秒を要する場合、一般的に適切なトランザクションをフラッシュバックするのに必要な時間は、数秒間のみです(適切にリハーサルされている場合)。参照整合性制約を考慮する必要があります。
脚注6 アプリケーションまたはレスポンス時間の減速を検出し、これらのSLA違反に対応するようにOracle Enterprise Managerまたはカスタマイズしたアプリケーションのハートビートを構成できます。たとえば、Enterprise Managerのビーコンを構成して、アプリケーションのレスポンス時間を監視および検出できます。さらに、特定のしきい値を超過した後で、Enterprise Managerはアラートを生成し、場合によってはデータベースを再起動できます。
脚注7 アプリケーションまたはレスポンス時間の減速を検出し、これらのSLA違反に対応するようにOracle Enterprise Managerまたはカスタマイズしたアプリケーションのハートビートを構成できます。たとえば、Enterprise Managerのビーコンを構成して、アプリケーションのレスポンス時間を監視および検出できます。一定のしきい値に到達すると、Enterprise ManagerによってOracle Data Guardの DBMS_DG.INITIATE_FS_FAILOVER PL/SQLプロシージャがコールされ、フェイルオーバーが開始されます。
|
関連項目:
|
Data Guardの「最大可用性」(net_timeoutでの同期通信)または「最大パフォーマンス」(非同期通信)を使用している場合、スタンバイ・サイトの停止はプライマリ・データベースの可用性に影響しません。
|
注意: スタンバイ・データベースでActive Data Guardオプションを使用するシステムの停止は、読取りアクティビティにスタンバイ・データベースを使用しているアプリケーションに影響することがありますが、このような停止はプライマリ・データベースの可用性には影響しません(可用性は指定したモードに基づきます)。 |
ただし、プライマリ・データベースがSYNCトランスポート・モードで稼働しているスタンバイ・データベースから確認応答を受信しない場合、Data Guardの「最大保護」は可用性に影響します(net_timeoutは「最大保護」に適用されません)。このため、「最大保護」を使用している場合は、2つのSYNCスタンバイ・データベースと、必要に応じて複数の遠隔同期インスタンスをデプロイするというMAAベスト・プラクティスに従う必要があります。2つのスタンバイ・データベースがある場合、単一のスタンバイの停止はプライマリの可用性またはデータ損失ゼロの保護に影響しません。
システム・リソースが制限されているため2つのスタンバイ・データベースをデプロイすることが実際的でない場合は、単純にデータ保護モードを「最大可用性」にダウングレードし、プライマリ・データベースを再起動することで、プライマリ・データベースの可用性をリストアできます。
表12-2に、セカンダリ・サイトでのスタンバイ・データベースの計画外の停止に対応するためのリカバリ手順をまとめます。複数のリカバリ手順を必要とする停止については、この表に、12.2項「計画外の停止からのリカバリ」の詳細な説明へのリンクが含まれます。
表12-2 セカンダリ・サイトまたは遠隔同期インスタンス・サイトでの計画外の停止のリカバリ手順
| 停止タイプ | 単一インスタンスのスタンバイ・データベースまたはOracle RACスタンバイ・データベースのリカバリ手順 |
|---|---|
|
コンピュータ障害(インスタンスまたはノード) |
ブローカにより、ログ適用サービスが自動的に再起動されます。 注意1: スタンバイ・データベースが1つのみあり、「最大保護」が構成されている場合は、プライマリ・データベースを停止して、スタンバイ・データベースとのデータの相違(保護されていないデータ)がないようにします。 注意2: Oracle RACスタンバイ・データベースの場合、使用可能なスタンバイ・インスタンスへの接続時フェイルオーバーを実行するようプライマリ・データベースのOracle Net記述子が構成されている場合、プライマリ・データベースの可用性に対する影響はありません。ブローカを使用している場合、自動的に接続時フェイルオーバーが構成されます。 |
|
データ破損 |
12.3.5項「スタンバイ・データベースのデータ障害後のフォルト・トレランスのリストア」 |
|
|
12.3.6項「RESETLOGSによるプライマリ・データベースのオープン後のフォルト・トレランスのリストア」 |
|
遠隔同期インスタンスまたはノードの障害 |
遠隔同期構成ベスト・プラクティスに従っている場合、データベースによって各ステップが自動的に実行され、手動で介入する必要はありません。 |
|
関連項目:
|
この項では、様々なタイプの計画外の停止からリカバリするためのベスト・プラクティスについて説明します。
完全サイト・フェイルオーバーでは、本番環境の負荷に対応するよう準備されたセカンダリ・サイトにデータベース、中間層アプリケーション・サーバーおよびすべてのユーザー接続をフェイルオーバーします。
スタンバイ・サイトが前提条件を満たしている場合、次の状況では完全サイト・フェイルオーバーをお薦めします。
プライマリ・サイトの障害(自然災害や悪意のある攻撃など)
プライマリ・ネットワークの接続障害
プライマリ・サイトの電源障害
サイト・フェイルオーバーを数分以内に迅速に完了するには、次のことを行います。
8.3項「一般的なData Guard構成のベスト・プラクティス」で説明した、Data Guard構成ベスト・プラクティスを使用します。
リカバリ時間目標(RTO)が30秒未満の環境では、Data Guardファスト・スタート・フェイルオーバーを使用してスタンバイ・データベースに自動的にフェイルオーバーします(8.5.2.3項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」参照)。
セカンダリ・サイトで稼働している中間層アプリケーション・サーバーを維持して起動時間を不要にするか、高速接続フェイルオーバーのベスト・プラクティスを使用して既存のアプリケーションを新しいプライマリ・データベースにリダイレクトします。その説明は次を参照してください。
次のWebサイトにあるOracle DatabaseのMAAベスト・プラクティスのエリアのMAAホワイト・ペーパー: 『高可用性Oracle Databaseでのクライアント・フェイルオーバーのベスト・プラクティス - Oracle Database 12c』
自動ドメイン・ネーム・サーバー(DNS)フェイルオーバー手順を構成します。プライマリ・サイトがアクセス不能になった後で自動DNSフェイルオーバーが行われ、セカンダリ・サイトのワイドエリア・トラフィック・マネージャがセカンダリ・サイトのロード・バランサの仮想IPアドレスを返し、後続の再接続でクライアントが自動的に方向付けされます。
データ損失の可能性は、使用しているData Guard保護モード(「最大保護」、「最大可用性」または「最大パフォーマンス」)によって決まります。GoldおよびPlatinum参照アーキテクチャの場合、Oracle 12c遠隔同期インスタンスを使用してWAN経由でデータ損失ゼロを実現できます。図12-1に、遠隔同期を使用した構成例を示します。
アプリケーション・コンティニュイティを使用すると、アプリケーション停止ゼロが可能になりますが、アプリケーション層がサイト全体で共有されている場合にかぎります。
プライマリ・サイトとセカンダリ・サイトのWANトラフィック・マネージャにより、サイト・フェイルオーバー機能が提供されます。WANトラフィック・マネージャは、プライマリ・サイト(またはプライマリ・サイトの特定のアプリケーション)がアクセス不可能になった場合に、自動的にトラフィックをリダイレクトします。スイッチオーバーの際には、この操作を手動で起動してセカンダリ・サイトに切り替えることも可能です。トラフィックは、停止またはスイッチオーバーによりプライマリ・サイトでサービスを提供できなくなった場合にのみ、セカンダリ・サイトに転送されます。プライマリ・サイトが停止すると、ユーザー・トラフィックはセカンダリ・サイトに自動的に転送されます。
図12-2は、サイト・フェイルオーバー前の可能なネットワーク・ルートを示しています。
クライアント・リクエストは、プライマリ・サイトのクライアント層に入り、WANトラフィック・マネージャによって転送されます。
クライアント・リクエストは、ファイアウォールを介して非武装地帯(DMZ)からアプリケーション・サーバー層に送信されます。
リクエストは、アクティブなロード・バランサを介してアプリケーション・サーバーに転送されます。
リクエストは、別のファイアウォールを介してデータベース・サーバー層に送信されます。
アプリケーション・リクエストは、必要に応じてOracle RACインスタンスにルーティングされます。
レスポンスは、同様の経路でアプリケーションとクライアントに戻されます。
図12-3は、サイト・フェイルオーバー後のネットワーク・ルートを示しています。クライアントまたはアプリケーション・リクエストは、セカンダリ・サイトのクライアント層に入り、プライマリ・サイトと同じ経路をたどります。
次の手順では、フェイルオーバーまたはスイッチオーバーのネットワーク・トラフィックに対する影響について説明します。
管理者は、プライマリ・データベースをセカンダリ・サイトにフェイルオーバーまたはスイッチオーバーします。この操作は、Data Guardファスト・スタート・フェイルオーバーを使用している場合は自動的に処理されます。
管理者は、セカンダリ・サイトの中間層アプリケーション・サーバーを起動します(実行されていない場合)。障害が発生したサイトに同じ中間層アプリケーション・サーバーが存在する場合、それらを利用できることがあります。
セカンダリ・サイトのワイドエリア・トラフィック・マネージャの選択は、サイト全体の障害に対して自動的に行うことができます。セカンダリ・サイトのワイドエリア・トラフィック・マネージャがセカンダリ・サイトのロード・バランサの仮想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
セカンダリ・サイトのロード・バランサで、セカンダリ・サイトの中間層アプリケーション・サーバーにトラフィックを転送します。
セカンダリ・サイトでクライアント・リクエストを処理する準備が整いました。
フェイルオーバーは、クライアントのWebブラウザにも依存します。ほとんどのブラウザ・アプリケーションでは、一定期間DNSエントリがキャッシュされます。したがって、停止の発生時に進行中だったセッションは、キャッシュ・タイムアウトの期限切れまでフェイルオーバーされない可能性があります。このようなクライアントでサービスを再開するには、ブラウザを一度終了して再起動します。
フェイルオーバーは、1つのスタンバイ・データベースをプライマリ・データベースのロールに移行する操作です。フェイルオーバー操作は、プライマリ・データベースに計画外の障害が発生し、一定の時間内にそのデータベースをリカバリできない場合に起動します。
Oracle Data Guardでは、ブローカと、ファスト・スタート・フェイルオーバーを使用して、フェイルオーバー・プロセスを自動化することができます。手動でフェイルオーバーを実行することもできます。
ファスト・スタート・フェイルオーバーでは、手動操作を必要とするプロセスの不確実性がなく、システム停止が検出されてから数秒以内に、データ損失がゼロまたは最小限のフェイルオーバーが自動実行されます(FastStartFailoverLagLimitプロパティを使用して構成)。構成ベスト・プラクティスは、8.5.2.3項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」を参照してください。
手動フェイルオーバーでは、次のいずれかの方法を使用して、ユーザーの決定に基づくフェイルオーバー・プロセスが可能になります。
Oracle Enterprise Manager
ブローカ・コマンドライン・インタフェース(DGMGRL)
SQL*Plus文
12.2.2.3項「手動フェイルオーバー実行のベスト・プラクティス」を参照してください。
データベース・フェイルオーバーは、アプリケーション・フェイルオーバーにより実行されますが、先にサイト・フェイルオーバーが実行される場合もあります。Platinum対応のアプリケーションおよびデータ損失ゼロのフェイルオーバーの場合、アプリケーション・コンティニュイティおよびトランザクション・ガードによるアプリケーション・フェイルオーバーを使用してアプリケーション停止ゼロを実現できます。Data Guardフェイルオーバー後は、セカンダリ・サイトがプライマリ・データベースをホストします。元のプライマリ・データベースを新しいスタンバイ・データベースとして回復し、構成のフォルト・トレランスを復元する必要があります。12.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。
通常、フェイルオーバー操作は、データをほとんど失わないか、まったく失うことなく数秒から数分で完了します。Oracle 12c遠隔同期機能を使用すると、プライマリ・データベースとスタンバイ・データベース間の物理的な距離に関係なくスタンバイ・データベースに対するデータ損失ゼロの保護が可能です。
|
関連項目:
|
プライマリ・データベースの障害を、ローカル・バックアップやフラッシュバック・テクノロジを使用してリカバリ時間目標(RTO)内に修復できない場合、Oracle Data Guardを使用してフェイルオーバーを実行する必要があります。
手動フェイルオーバーは、次のような計画外の停止が発生した場合に実行します。
プライマリ・データベースが使用不可能となるサイト障害
一定の時間内に修復できないユーザー・エラーによる障害
Oracle Active Data Guardによって自動的に解決されないデータ破損、データまたはメディア破損、データベースまたはクラスタの障害
フェイルオーバーでは、以前のプライマリ・データベースをスタンバイ・データベースとして復元し、現在の環境にフォルト・トレランスを回復する必要があります。元のプライマリ・データベースが損傷していない場合、フラッシュバック・データベースを使用して、スタンバイ・データベースを短時間で回復することができます。12.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。
ファスト・スタート・フェイルオーバーは、完全自動のため、ユーザーの操作を必要としません。
ファスト・スタート・フェイルオーバーの実行時に考慮する必要のある操作上のベスト・プラクティスはありません。ただし、8.5.2.3項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」に記載されているすべての構成上のベスト・プラクティスを検討することは重要です。
|
関連項目:
|
手動フェイルオーバーを実行する場合は、次のようにします。
8.5.2.4項「手動フェイルオーバーのベスト・プラクティス」で説明されている構成ベスト・プラクティスに従います。
次の方法から選択します。
Oracle Enterprise Manager
Oracle Enterprise Managerを使用して手動フェイルオーバーを実行する方法の詳細は、『Oracle Data Guard Broker』を参照してください。手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方で同じです。
Oracle Data Guardブローカ・コマンドライン・インタフェース(DGMGRL)
Oracle Enterprise Managerを使用して手動フェイルオーバーを実行する方法の詳細は、『Oracle Data Guard Broker』を参照してください。手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方で同じです。
SQL*Plus文
ノードまたはインスタンスの障害が発生すると、Oracle RACリカバリが自動的に実行されます。通常の複数インスタンスOracle RAC環境では、正常なインスタンスが障害インスタンスを自動的にリカバリし、自動クライアント・フェイルオーバーで支援する可能性があります。リカバリ時間は、データベースとOracle RAC構成のベスト・プラクティスを採用することで制限でき、通常は、データ損失なしで、非常に大規模なビジー・システムのインスタンス・リカバリ時間を数秒から数分にすることができます。Oracle RAC One Node構成では、リカバリ時間はOracle RAC全体よりも長くなると予想されます。Oracle RAC One Nodeでは、インスタンス・リカバリを実行する前に置換インスタンスを起動する必要があります。
Oracle RACおよびOracle RAC One Nodeでのインスタンスまたはノードの障害の場合は、次のリカバリ方法を使用します。
ソフトウェアまたはハードウェアの問題によりインスタンスが停止または中止されると、インスタンス障害が発生します。インスタンス障害の発生後、Oracleでは、オンラインREDOログ・ファイルを使用して自動的にデータベース・リカバリを実行します。
Oracle RAC環境のインスタンス・リカバリでは、障害インスタンスの再起動や、障害インスタンスで稼働していたアプリケーションのリカバリは行われません。アプリケーションはサービス再配置と高速アプリケーション通知を使用して継続して実行できます(12.2.3.2項「自動サービス再配置」を参照してください)。
いずれかのインスタンスが別のインスタンスに対してリカバリを実行する場合、リカバリする側のインスタンス(およびトランザクション・リカバリの場合はアクティブなフォアグラウンド・プロセス)は次の操作を実行します。
障害インスタンスによって生成されたREDOログ・エントリを読み取り、その情報を使用してコミット済トランザクションがデータベースに記録されていることを確認します。したがって、コミット済トランザクションのデータは失われません。
障害発生時にアクティブであったコミットされていないトランザクションをロールバックし、それらのトランザクションに使用されていたリソースを解放します。
複数のインスタンスに障害が発生した場合、障害を受けなかったインスタンスが1つでもあれば、Oracle RACは、障害が発生したすべてのインスタンスに対してインスタンス・リカバリを実行します。Oracle RACデータベースのすべてのインスタンスに障害が発生した場合、いずれかのインスタンスを再起動した時点でクラッシュ・リカバリが開始され、コミット済トランザクションはすべてリカバリされます。Data Guardは、クラスタのすべてのインスタンスに障害が発生した場合に停止を防ぐための推奨ソリューションです。
サービスの信頼性を確保するには、正常なインスタンスを構成してその中でフェイルオーバーを実行します。必要なサービスを複数のデータベース・インスタンスで提供することにより、サービスが使用可能になります。ハードウェア障害が発生し、障害Oracle RACデータベース・インスタンスに悪影響を及ぼす場合、構成に応じて、Oracle Clusterwareは次のいずれかを行います。
Oracle Clusterwareは、DBCAまたはEnterprise Managerでの構成どおりに、障害のあるデータベース・インスタンス上のサービスを別の使用可能なインスタンスに自動的に移動します。Oracle Clusterwareは、障害がサービスに影響を与えるタイミングを認識して、サービスをサポートする稼働中のインスタンス全体にサービスを自動的にフェイルオーバーします。
|
注意: Oracle RAC One Nodeでは、別のノードの別のインスタンスが起動し、適切なサービスに対して使用可能になると、再配置が行われます。このため、Oracle RAC One Nodeはインスタンスの障害時に新しいインスタンスを起動しますが、新しいインスタンスは「稼働を続けているインスタンス」ではありません。 |
デフォルトでは、サービスを複数のインスタンスで使用可能にできます。この場合、複数のインスタンスのいずれかが失われると、クライアントは稼働を続けているインスタンス全体で使用可能なサービスの使用を継続しますが、作業に使用できるリソースは減ります。
同時に、Oracle Clusterwareは障害インスタンスを再起動して依存リソースをシステムに再統合するように試み、Cluster Ready Services (CRS)はデータベース・インスタンスの再起動を3回試みます。クライアントは、ノード障害イベントを"サブスクライブ"して、インスタンスの問題の通知を迅速に受け、新しい接続を設定できます(Oracle Clusterwareは新しい接続を設定せず、クライアントが新しい接続を設定します)。高速アプリケーション通知(FAN)イベントを使用した障害の通知は、Oracleサーバー・アーキテクチャ内の様々なレベルで起動できます。Oracleクライアント・フェイルオーバー・ベスト・プラクティス(第10章)に従いながらアプリケーション・コンティニュイティを使用しているとき、ほとんどの場合、アプリケーションはエラーを表示せずに停止をシームレスに処理できます。
Oracle Cluster Registry(OCR)ファイルが失われると、Oracle RACおよびOracleクラスタウェアの可用性が影響を受けます。OCRファイルは、自動で作成されるバックアップからリストアするか、ocrconfigツールを使用して手動で作成されるエクスポート・ファイルからリストアすることが可能です(ocrconfigはバックアップのリストアにも使用します)。また、OracleはオプションでOCRをミラーリングして、単一のOCRデバイスの障害に対応します。OCRミラーは、必ず物理的に別々のデバイス、できれば別々のコントローラ上に置きます。詳細は、5.2.7項「Oracle Cluster Registry (OCR)のミラーリングとOracle ASMでの複数の投票ディスクの構成」を参照してください。
すべての投票ディスクが破損している場合は、それらをリストアする必要があります。これを行うには、crsctlコマンドを使用します。使用する手順は、投票ファイルを格納する場所によって決まります。投票ディスクがOracle ASMに格納されている場合は、crsctl replace votediskコマンドを実行して、指定するOracle ASMディスク・グループに投票ディスクを移行します。投票ディスクをOracle ASMに格納しなかった場合は、crsctl delete css votediskコマンドを実行して投票ディスクを削除し、crsctl add css votediskコマンドを実行して追加します。
|
関連項目:
|
最小限の構成で、アプリケーションは、サービスを提供しているインスタンスが使用不可能になったときに通知を迅速かつ効率的に受信できます。通知が発生すると、稼働を続ける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のフェイルオーバーを引き起こすあらゆる障害または計画メンテナンスが発生した場合に、自動の高速リダイレクションが可能になります。
|
関連項目:
|
Platinum対応のアプリケーションでは、次の前提条件を満たしているときは必ず、計画外停止アクティビティおよび計画メンテナンス・アクティビティの際にアプリケーション停止ゼロを実現できます。
アプリケーション・コンティニュイティおよびトランザクション・ガードでアプリケーションが構成されている、かつ
データ損失ゼロのOracle RACフェイルオーバーが発生している、または
データ損失ゼロのData Guardフェイルオーバーが発生している
計画済および計画外の停止に続いてアプリケーション・コンティニュイティは、データベース・セッションを再構築し、データベース・セッションを使用不可にしているリカバリ可能エラーに続く保留中作業を再送信することで、停止をマスキングしようとします。アプリケーション・コンティニュイティは、リカバリ不能なエラーが原因のコール障害後は作業を再送信しません。無効なデータ値の送信は、リプレイに使用できないリカバリ不能エラーの例です。
アプリケーション・コンティニュイティが構成されていると、エンドユーザー要求は最大1回実行され、サービスに指定されたリプレイ・タイムアウト属性を超えていない場合はリプレイが開始されます。リプレイ時は、アプリケーション・コンティニュイティは実行が少し遅れているようにユーザーに見えます。リプレイが成功するとこの機能は、一時的な停止(セッション障害、インスタンスまたはノードの停止、ネットワーク障害など)や計画済停止(修復、構成変更、アプリケーションのパッチ適用など)からアプリケーションをマスキングします。
表12-3に、様々なOracle ASM障害タイプの影響と推奨される修復方法をまとめます。
表12-3 Oracle ASM障害タイプと推奨される修復方法
| 障害 | 説明 | 影響 | 推奨される修復方法 |
|---|---|---|---|
|
Oracle ASMインスタンス障害 |
Oracle ASMインスタンスの障害 |
同じノードからOracle ASM記憶域にアクセスするすべてのデータベース・インスタンスが停止します。 Flex ASM構成では、別のASMインスタンスが使用可能である場合、データベース・インスタンスはすべて使用可能なままです。 |
自動(12.2.3項「計画外の停止からのOracle RACリカバリ(ノードまたはインスタンス障害の場合)」) Oracle RACを使用していない場合、Data Guardフェイルオーバーを使用します(12.2.2.2項「ファスト・スタート・フェイルオーバーを実装するためのベスト・プラクティス」を参照)。 Oracle RACとData Guardを使用していない場合、基礎となる問題を修正してからOracle ASMとデータベース・インスタンスを再起動します。 |
|
Oracle ASMディスク障害 |
1つ以上のOracle ASMディスクに障害が発生しますが、すべてのディスク・グループはオンラインのままです。 |
引き続きすべてのデータにアクセスできます。この状況は、標準冗長性または高冗長性のディスク・グループでのみ発生します。 |
Oracle ASMは、残りのディスク・ドライブに自動的にリバランスし、冗長性を再確立します。冗長性をリストアするには残りのディスク・ドライブに十分な空きディスク領域が必要です。そうでないと、リバランスが |
|
データ領域ディスク・グループ障害 |
1つ以上のOracle ASMディスクに障害が発生し、データ領域ディスク・グループがオフラインになります。 |
データ領域ディスク・グループにアクセスするデータベースが停止します。 |
Data Guardフェイルオーバーまたはローカル・リカバリを実行します(12.2.6.3項「データ領域ディスク・グループ障害」を参照)。 |
|
高速リカバリ領域ディスク・グループ障害 |
1つ以上のOracle ASMディスクに障害が発生し、高速リカバリ領域ディスク・グループがオフラインになります。 |
高速リカバリ領域ディスク・グループにアクセスするデータベースが停止します。 |
ローカル・リカバリまたはData Guardフェイルオーバーを実行します(12.2.6.4項「高速リカバリ領域ディスク・グループ障害」を参照)。 |
Oracle ASMインスタンスに障害が発生した場合、同じノードからOracle ASM記憶域にアクセスするデータベース・インスタンスが停止します。フェイルオーバー処理の説明を次のリストに示します。
プライマリ・データベースがOracle RACデータベースの場合、アプリケーション・フェイルオーバーは自動的に発生し、データベース・インスタンスに接続しているクライアントは残っているインスタンスに再接続します。このため、サービスはクラスタ内の他のインスタンスによって提供され、処理は継続します。通常、リカバリ時間は数秒以内です。
プライマリ・データベースがOracle RACデータベースでない場合、Oracle ASMインスタンス障害が発生するとデータベース全体が停止します。
構成でOracle Data Guardを使用しており、ファスト・スタート・フェイルオーバーを有効にしている場合、データベース・フェイルオーバーが自動的に起動され、クライアントはフェイルオーバーの完了後に新規プライマリ・データベースに自動的に再接続されます。リカバリ時間は、自動Data Guardファスト・スタート・フェイルオーバー操作が完了するまでの時間と同じです。ファスト・スタート・フェイルオーバーを構成していない場合、手動でOracle ASMインスタンスとデータベース・インスタンスを再起動するか、手動Data Guardフェイルオーバーを実行することによって、この停止状態からリカバリする必要があります。
構成にOracle RACもData Guardも含まれない場合、Oracle ASMインスタンスとデータベース・インスタンスを手動で再起動する必要があります。リカバリ時間は、これらの作業の所要時間により異なります。
Oracle ASMディスクに障害が発生した場合、フェイルオーバー処理は次のようになります。
Oracle ASMディスク・グループが外部冗長性タイプとして構成されている場合、単一のディスク障害は、ストレージ・アレイにより処理されるためOracle ASMインスタンスからは認識されないのが普通です。ディスク・グループを使用するOracle ASMとデータベースのすべての操作は、通常どおり機能し続けます。
ただし、外部冗長性ディスク・グループの障害がOracle ASMインスタンスによって検出された場合、Oracle ASMインスタンスはディスク・グループを即時にオフラインにするため、ディスク・グループにアクセスしているOracleインスタンスはクラッシュします。ディスク障害が一時的な場合は、Oracle ASMとデータベース・インスタンスを再起動でき、ディスク・グループがオンラインに戻った後でクラッシュ・リカバリが行われます。
Oracle ASMディスク・グループが標準または高冗長性タイプとして構成されている場合、ディスク障害はOracle ASMにより透過的に処理され、ディスク・グループにアクセスしているデータベースは影響を受けません。
Oracle ASMインスタンスは、自動的にOracle ASMリバランス操作を開始し、1つ以上の障害ディスクのデータをOracle ASMディスク・グループの他の正常なディスクに分散します。リバランス操作の進行中に、まだ再ミラー化されていないデータを含むディスクに別のディスク障害が発生すると、ディスク・グループの可用性に影響を与える可能性があります。リバランス操作が正常に完了すると、後続の障害が発生してもOracle ASMディスク・グループは影響を受けません。複数のディスク障害も、それらの障害が正常な冗長性のOracle ASMディスク・グループのただ1つの障害グループに影響を与えるかぎり、同じように処理されます。
複数の障害グループの複数のディスクで、プライマリ・エクステントとそのすべてのミラーが失われる障害が発生した場合、ディスク・グループはオフラインになります。
Oracle ASMディスクに障害が発生した場合は、次のリカバリ方法を使用します。
図12-4は、ディスク障害をレポートするEnterprise Managerを示しています。14個のアラートのうち5つを示しています。示されている5つのアラートは、Disk RECO2のオフライン・メッセージです。
図12-5は、データ領域ディスク・グループDATA、Data Guardディスク・グループDBFS_DGおよびリカバリ領域ディスク・グループRECOのステータスをレポートするEnterprise Managerを示しています。
図12-5 Enterprise ManagerによるOracle ASMディスク・グループ・ステータスのレポート
図12-6は、DATAディスク・グループに対する保留中のREBAL操作をレポートするEnterprise Managerを示しています。この操作は、「%完了」に示されているとおりほぼ完了しており、「残り時間」は0分と推定されています。
1つの特定の障害グループの1つ以上の障害ディスクが削除された後、新しいディスクで置換する必要がある場合に、これらの手順を実行します。
次のSQLコマンドを使用して、障害ディスク・グループに1つ以上の置換ディスクを追加します。
ALTER DISKGROUP disk_group ADD FAILGROUP failure_group DISK 'disk1','disk2',...;
次のコマンドで操作の進行状況をチェックします。
SELECT * FROM V$ASM_OPERATION;
データ領域ディスク・グループ障害は、複数の障害が存在する場合にのみ発生するのが普通です。たとえば、データ領域ディスク・グループが外部冗長性として定義されている場合、単一のディスク障害はOracle ASMから隔離されている必要があります。ただし、ストレージ・アレイの複数のディスク障害は、Oracle ASMで認識される可能性があり、その場合ディスク・グループはオフラインになります。同様に、標準または高冗長性ディスク・グループの異なる障害グループに複数のディスク障害が発生した場合も、ディスク・グループはオフラインになる可能性があります。
標準または高冗長性ディスク・グループで1つ以上のディスク障害が発生し、Oracle ASMディスク・グループにアクセス可能な場合、データは失われず、即座にアクセスできなくなることもありません。Oracle ASMインスタンスは、自動的にOracle ASMリバランス操作を開始し、1つ以上の障害ディスクのデータをOracle ASMディスク・グループの他の正常なディスクに分散します。リバランス操作が正常に完了すると、2番目の障害が発生してもOracle ASMディスク・グループは影響を受けません。リバランス操作を正常に完了するには、ディスク・グループ内の残りのディスクに十分な空きディスク領域が存在する必要があります。
表12-4に、データ領域のディスク・グループ障害からリカバリするために可能な解決方法をまとめます。
表12-4 データ領域ディスク・グループ障害のリカバリ・オプション
| リカバリ・オプション | リカバリ時間目標(RTO) | リカバリ・ポイント目標(RPO) |
|---|---|---|
|
Data Guardフェイルオーバー(12.2.6.4項「高速リカバリ領域ディスク・グループ障害」を参照)。 |
数秒から数分 Platinumの場合: アプリケーション停止ゼロ |
選択されているデータ保護レベルに応じて変動 Active Data Guard遠隔同期機能を使用すると、さらにデータ損失ゼロ構成が可能になります。 |
|
ローカル・リカバリ(「ローカル・リカバリの手順」を参照) |
データベースのリストア時間とリカバリ時間 |
0(ゼロ) |
Data Guardを使用しており、ファスト・スタート・フェイルオーバーを構成している場合、データ領域ディスク・グループがオフラインとなってデータベースが停止した時点で自動フェイルオーバーが起動されます。ファスト・スタート・フェイルオーバーを構成していない場合は、手動フェイルオーバーを実行します。
Data Guardフェイルオーバーを実行する場合、リカバリ時間目標(RTO)は、Data Guardオブザーバ・プロセスとファスト・スタート・フェイルオーバーの稼働状況に応じて数分から数秒となります。ただし、手動フェイルオーバーを実行する場合は、スタンバイ・サイトにすべてのデータが用意されていないとデータ損失が発生する可能性があります。
Data Guardフェイルオーバーが完了し、アプリケーションが使用可能になったら、データ領域ディスク・グループ障害を解決する必要があります。引き続き、後続の「ローカル・リカバリの手順」を参照してOracle ASMディスク・グループ障害を解決します。
ローカル・リカバリのみのRTOは、次の操作時間に基づきます。
障害ストレージ・コンポーネントを修復および置換する時間
データベースをリストアおよびリカバリする時間
損失の影響はデータ領域ディスク・グループに限定されるため、データ損失は発生しません。トランザクションはすべて高速リカバリ領域に存在するOracle REDOログに記録されるため、完全なメディア・リカバリが可能です。
Data Guardを使用していない場合、次のローカル・リカバリの手順を実行します。ローカル・リカバリの実行に要する時間は、データベースをリストアおよびリカバリする時間に応じて変化します。ローカル・リカバリの実行によるデータ損失はありません。
1つ以上の障害ディスクを置換し、ストレージへのアクセスが回復したら、次の手順を実行します。
|
注意: 新規プライマリ・データベースに対してOracle Data Guardフェイルオーバーを実行した場合、次の手順を使用してリストアし、Data Guard設定と同期できます。12.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」も参照してください。 |
Oracle ASMインスタンスで次のSQL*Plus文を発行することで、新しい記憶域の場所を使用してOracle ASMディスク・グループを再構築します。
SQL> CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK 'path1','path2',...force;
データベースの起動に使用するspfileは+DATAディスクグループ内に存在し、使用できないため、データベース・インスタンスの起動に使用するDB_NAME、DB_UNIQUE_NAMEおよびCOMPATIBLEの各パラメータを指定したダミーpfileを作成します。
次のRMANコマンドを発行して、データベース・インスタンスNOMOUNTを起動します。
RMAN> STARTUP FORCE NOMOUNT;
spfile自動バックアップからspfileをリストアし、リカバリ領域に残っているコピーから制御ファイルをリストアします。
RMAN> RESTORE CONTROLFILE FROM 'recovery_area_controlfile';
制御ファイルのリストア場所の絶対パスを、次のようにrestore controlfileコマンドに指定する必要があります。
RMAN> RESTORE CONTROLFILE TO '+RECO/dbm/control01.ora' from autobackup db_recovery_file_dest='+RECO' db_name='db_name';
前のステップの場所にspfileがリストアされたら、最初のステップで作成したダミーのinit.oraファイルを変更して、リストアされたspfileを指すようにする必要があります。
たとえば、pfileは次のようになります。
$ cat initdbm1.ora SPFILE='+RECO/dbm/spfiledbm.ora' ==> spfile restored in the previous step.
リストアされたspfileを使用してデータベース・インスタンスを再起動します。
spfileのcontrol_filesパラメータを変更して、リストアされた制御ファイルを指すようにします。
ALTER SYSTEM SET control_files='<full path and filename of the location of the restored control files>';
データベース・インスタンス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;
障害Oracle ASMディスク・グループにログ・ファイル・メンバーを再作成します。
SQL> ALTER DATABASE DROP LOGFILE MEMBER 'filename'; SQL> ALTER DATABASE ADD LOGFILE MEMBER 'disk_group' TO GROUP group_no;
リストアされたデータベースのクリーンアップの一環として、temp表領域を再作成します。
SQL> DROP TABLESPACE TEMP; SQL> CREATE TEMPORARY TABLESPACE TEMP TEMPFILE 'disk_group';
次のRMANコマンドを使用して、増分レベル0のバックアップを実行します。
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;
通常、制御ファイル・メンバーは高速リカバリ領域に存在し、Oracleではすべての制御ファイル・メンバーにアクセスできる必要があるため、高速リカバリ領域ディスク・グループに障害が発生すると、データベースはクラッシュします。高速リカバリ領域には、フラッシュバック・ログ、REDOログ・メンバーおよびすべてのバックアップ・ファイルが含まれることがあります。
この障害は高速リカバリ領域ディスク・グループのみに影響を与えるため、データの損失はありません。データファイルとオンラインREDOログ・ファイルは引き続き存在し、データ領域で使用できるため、データベースのメディア・リカバリは必要ありません。
高速リカバリ領域ディスク・グループ障害は、複数の障害が存在する場合にのみ発生するのが普通です。たとえば、高速リカバリ領域ディスク・グループが外部冗長性として定義されている場合、単一のディスク障害はOracle ASMから隔離されている必要があります。ただし、ストレージ・アレイの複数のディスク障害は、Oracle ASMに影響し、ディスク・グループがオフラインになる原因となることがあります。同様に、標準または高冗長性ディスク・グループの異なる障害グループに複数のディスク障害が発生した場合も、ディスク・グループはオフラインになる可能性があります。
表12-5に、高速リカバリ領域ディスク・グループ障害が発生した場合に使用可能な解決方法をまとめます。
表12-5 高速リカバリ領域ディスク・グループ障害のリカバリ・オプション
| リカバリ・オプション | リカバリ時間目標(RTO) | リカバリ・ポイント目標(RPO) |
|---|---|---|
|
ローカル・リカバリ(12.2.6.4.1項「高速リカバリ領域ディスク・グループ障害のローカル・リカバリ」を参照)。 |
5分以下 |
0(ゼロ) |
|
Data Guardフェイルオーバーまたはスイッチオーバー(12.2.6.4.2項「高速リカバリ領域ディスク・グループ障害のData Guardロールの移行」を参照)。 |
数秒から数分 |
0(ゼロ) |
ローカル・リカバリを実行することを決定した場合は、高速リカバリ領域に存在する制御ファイル・メンバーをinit.oraから削除した後で高速ローカル再起動を実行してプライマリ・データベースを起動し、アーカイブ用に高速リカバリ領域として別のディスク・グループを割り当てる必要があります。
高速リカバリ領域が失われた場合、データベースのLOG_ARCHIVE_DEST_nの場所とデータベースのDB_RECOVERY_FILE_DESTを変更して、動作可能なディスク・グループを指すようにする必要があります。そうしないと、アーカイブ・ログの場所が使用できない場合、データベースがハングします。また、保証付きリストア・ポイントが所定の場所にある場合、DB_RECOVERY_FILE_DESTが使用できなくなると、データベースはクラッシュします。
高速ローカル再起動を行うには、プライマリ・データベースで次の手順を実行します。
データ領域のメンバーのみを指定するよう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:
失われたディスク・グループにあったREDOログ・メンバーを削除します。たとえば、次のコマンドを発行します。
ALTER DATABASE DROP LOGFILE MEMBER '+RECO/dbm/onlinelog/group_2.258.750768395';
フラッシュバック・ログの破損や損失が発生した場合、状況によってはフラッシュバック・データベースを一度無効化してから再有効化する必要があります。
ALTER DATABASE FLASHBACK OFF; ALTER DATABASE FLASHBACK ON; ALTER DATABASE OPEN;
ただし、この方法は、高速リカバリ領域を作成して障害ストレージ・コンポーネントを置換するまでの一時的な修復手段です。ローカル・リカバリの手順を使用することをお薦めします。
障害が発生した高速リカバリ領域ディスク・グループが回復し、再作成されたら、LOG_ARCHIVE_DEST_1およびDB_RECOVERY_FILE_DESTの場所を元の高速リカバリ領域ディスク・グループに戻し、アーカイブ・ログおよびフラッシュバック・ログをその高速リカバリ領域ディスク・グループに転送します。
|
関連項目:
|
Data Guardロールの移行を実行する場合、リカバリ時間目標(RTO)は、Data Guardオブザーバ・プロセスとファスト・スタート・フェイルオーバーの稼働状況に応じて数秒から数分となります。
保護レベルが最大パフォーマンスの場合、またはスタンバイ・データベースがプライマリ・データベースと同期されていない場合は、次の手順を実行します。
制御ファイル・メンバーを削除し、SPFILEの一時高速リカバリ領域(ファイル・システム)を参照することによって、一時的にプライマリ・データベースを起動します。
Data Guardスイッチオーバーを実行してデータ損失を防ぎます。
スイッチオーバーが完了し、アプリケーションが使用可能になったら、高速リカバリ領域ディスク・グループ障害を解決します。
関連するデータベースを停止し、ローカル・リカバリの手順を使用してOracle ASMディスク・グループ障害を解決します。詳細は、「高速リカバリ領域ディスク・グループ障害のData Guardロールの移行のローカル・リカバリ手順」を参照してください。
|
注意: 新規プライマリ・データベースに対してOracle Data Guardフェイルオーバーを実行した場合、この手順を使用して元のプライマリ・データベースをスタンバイ・データベースとして再導入することはできません。その理由は、データベースの再導入作業に必要なフラッシュバック・データベースのログ・ファイルが失われているためです。スタンバイ・データベースについては、完全な復元を実行する必要があります。 |
高速リカバリ領域として使用するストレージを置換するか、ストレージへのアクセスを確立します。
次のSQL*Plus文を発行することによって、記憶域の場所を使用してOracle ASMディスク・グループを再構築します。
SQL> CREATE DISKGROUP RECO NORMAL REDUNDANCY DISK 'path1','path2',...force;
次の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;
障害Oracle 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;
データ・ブロックは、認識されているOracleデータベース形式ではないか、または内容に内部的な一貫性がないと破損します。データ・ブロック破損は、内部のOracle制御情報やアプリケーションおよびユーザー・データにダメージを与えて、これがクリティカル・データおよびサービスの重大な損失につながる場合があります。Oracleデータベースの破損の防止、検出および修復機能は、保護対象のデータおよびトランザクションの内部知識と、包括的な高可用性ソリューションのインテリジェント統合を基に構築されています。詳細は、4.1.6項「データの破損からの保護」を参照してください。
リカバリ・プロセスは、ブロックの破損が疑われるか検出された場合(例: ORA-1578、ORA-752、ORA-600 [3020]およびORA-753)に開始します。破損したブロックが見つかると、ほとんどのブロック破損からリカバリするための様々な手法が提供されます。
データ・ブロックのリカバリには次のような様々な手法があります。
データ・リカバリ・アドバイザは、ほとんどの問題を診断および修復するための最も簡単な方法です。詳細は、12.2.7.1項「データ・リカバリ・アドバイザの使用」を参照してください。
Active Data Guardは、プライマリまたはスタンバイ・データベースの破損データ・ブロックを自動的に修復できます。詳細は、12.2.7.2項「Active Data Guardの使用」を参照してください。
RMANブロック・メディア・リカバリは、正常なバックアップからブロックを取得することで個々の破損ブロックを修復できます。詳細は、12.2.7.3項「RMANとブロック・メディア・リカバリの使用」を参照してください。
スタンバイ・データベースへのData Guardスイッチオーバーまたはフェイルオーバー。詳細は、12.2.7.2.2項「フィジカル・スタンバイ・データベースからのデータの抽出」を参照してください。
RMANでのデータファイル・メディア・リカバリ。詳細は、12.2.7.3項「RMANとブロック・メディア・リカバリの使用」を参照してください。
ORA-752またはORA-600 [3020]を引き起こす書込みの欠落を検出した場合は、次の場所にあるMy Oracle Supportのノート1265884.1の『Resolving ORA-752 or ORA-600 [3020] During Standby Recovery』のガイドラインに従います。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1265884.1
さらに、Data Guardブローカには新しいPrimaryLostWriteActionプロパティがあり、プライマリ・データベースで書込みの欠落が発生していることがスタンバイ・データベースによって検出されるたびに実行される特定のアクションを簡単に自動化できます。たとえば、ファスト・スタート・フェイルオーバーが有効(最大パフォーマンス・モードまたは最大可用性モードのいずれか)で、Data GuardブローカのPrimaryLostWriteActionがFORCEFAILOVERに設定されている場合、オブザーバはフェイルオーバーを開始します。このオプションにより、データ損失フェイルオーバーになりますが、停止時間を大幅に短縮できます。FORCEFAILOVERオプションは、Oracle Database 12cリリース1 (12.1.0.2)以降でのみ使用可能です。
破損ブロックのリカバリに使用するメソッドにかかわらず、最初に破損のタイプと程度を分析してリカバリを実行する必要があります。データの破損を防止および準備するのに最適な手法を実装すると、その後発生する可能性のあるデータ損失と停止時間に対処するときの時間、労力およびストレスを軽減できます。
MAAベスト・プラクティスは、次のようなほとんどの破損や、逸脱または欠落した書込みを解決するための手順を追ったプロセスを提供します。
|
関連項目:
|
データ・リカバリ・アドバイザでは、次のようなリストア操作やリカバリ手順を実行したり、フラッシュバック・データベースを使用したりできます。
破損ブロックを含むデータファイルのブロック・メディア・リカバリの実行
データベースまたは選択した表領域のPoint-in-Timeリカバリの実行
フラッシュバック・データベースを使用したデータベース全体の巻戻し
バックアップからのデータベースの完全なリストアおよびリカバリ
データ・リカバリ・アドバイザには、コマンドラインおよびGUIの両方のインタフェースがあります。GUIインタフェースは、Oracle Enterprise Manager Database Control(サポート・ワークベンチ)で「リカバリの実行」をクリックすると使用できます。これにより、データ・リカバリ・アドバイザを使用できます。
RMANコマンドライン・インタフェースを使用したデータ・リカバリ・アドバイザのコマンドには、LIST FAILURE、ADVISE FAILURE、REPAIR FAILURE、CHANGE FAILUREなどがあります。
データ・リカバリ・アドバイザで問題が修正された場合、それ以上リカバリ方法を続行する必要はありません。ただし、アラート・ログでプライマリ・データベースとスタンバイ・データベースのORA-エラーと破損警告を定期的にチェックしてください。データベースの動作中に破損が検出されると、破損エラーがORA-600またはORA-01578としてアラート・ログに記録されます。
|
注意: 現在のリリースのデータ・リカバリ・アドバイザでは、単一インスタンス・データベースのみがサポートされています。Oracle RACデータベースはサポートされていません。データ・リカバリ・アドバイザでサポートされているデータベース構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
|
関連項目:
|
スタンバイ・データベースを使用してプライマリ・データベースのブロック破損を修復するには、2つのオプションがあります。
または、破損が広範囲の場合は、プライマリ・データベースを修復する一方でスタンバイ・データベースへのフェイルオーバーまたはスイッチオーバーを選択できます。詳細は、12.2.7.4項「Data Guardロール移行の実行」を参照してください。
Oracle Database 11gリリース2(11.2)から、破損ブロックの修復は、フィジカル・スタンバイ・データベースから同じブロックの状態のよいバージョンを取得することで、プライマリ・データベースによりリアルタイムで自動的に行われます。この機能を自動ブロック修復と呼びます。自動ブロック修復では、破損したデータ・ブロックを破損検出と同時に自動修復できます。自動ブロック修復では、ディスクやテープのバックアップまたはフラッシュバック・ログからブロックを取得するのとは対照的に、最新の良好なブロックをリアルタイムで使用するため、ブロック破損によりデータにアクセスできない時間とブロックのリカバリの時間が短縮されます。
このため、自動ブロック修復では、Oracle Active Data Guardスタンバイ・データベースを使用して、プライマリ・データベースにより検出されたデータ破損の自動修復が行われます。また、Active Data Guardのフィジカル・スタンバイ・データベースで破損が検出された場合、破損はプライマリの良好なブロックで自動的に修復されます。どちらの操作もアプリケーションに対して透過的です。
|
注意: 自動ブロック修復では、Oracle Active Data Guardオプションを使用する必要があります。 |
|
関連項目: Oracle Active Data Guardオプションおよび自動ブロック修復機能の詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
Data Guardフィジカル・スタンバイ・データベースを使用して、破損データファイルをスタンバイ・データベースの良好なコピーで置換することにより、プライマリ・データベース上のデータファイル全体のブロック破損を修復できます。ファイルがプライマリ・データベースにリストアされた後、データファイルまたは表領域リカバリによって、データファイルとデータベースの残りの部分との整合性がとられます。
|
関連項目: スタンバイ・データベースのファイルを使用した、プライマリ・データベース上のデータファイルの損失からのリカバリの詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
大規模なブロック破損(物理的または論理的)や書込みの欠落は、プライマリ・サイトでの重大なハードウェア問題を示していると考えられます。この場合、スタンバイ・データベースへのフェイルオーバーが、可用性を維持してデータ損失の可能性を最小限に抑えるために、最も賢明な処理方針となることがあります。
Data GuardブローカのプロパティPrimaryLostWriteActionを使用して、スタンバイ・データベースによってファスト・スタート・フェイルオーバー構成で書込みの欠落が検出された場合に実行されるアクションを事前に定義します。
ブロック・メディア・リカバリでは、RMAN RECOVER BLOCKコマンドを使用して、データファイルでメディア破損としてマークされた1つのブロックまたはデータ・ブロックのセットをリカバリします。メディア破損としてマークされた、メディア・リカバリを必要とするデータ・ブロックの数が少ない場合、データファイル全体ではなく、破損したブロックを選択的にリストアおよびリカバリできます。ブロック・メディア・リカバリにより、REDO適用時間が最小化され、リカバリ時のI/Oオーバーヘッドが回避されます。ブロック・メディア・リカバリでは、破損ブロックのリカバリ中も、関連するデータファイルをオンラインのまま使用できます。ただし、破損ブロックは、完全にリカバリされるまで使用できない状態が続きます。
ブロック・メディア・リカバリを使用するのは、次の場合です。
メディア・リカバリを必要とするブロックの数が少なく、リカバリの必要なブロックが判明している場合。
ブロックが破損としてマークされている場合(RMAN VALIDATE CHECK LOGICALコマンドで検証可能)。
破損したデータファイルのバックアップ・ファイルがローカルで使用可能であるか、そのバックアップ・ファイルをリモートの場所から取得できる場合。
|
注意: データ・ブロックに問題のない論理的な破損の原因となるユーザー・エラーまたはソフトウェア・バグからのリカバリには、ブロック・メディア・リカバリを使用しないでください。 |
データファイルの重要な部分が破損しているか、破損量が不明の場合は、RMANを使用してバックアップからのファイルのリストアまたはディスク・イメージ・コピーへの切替えを行うか、Data Guardスタンバイ・データベースにスイッチオーバーしてください。
破損が検出された場合は、Oracle Enterprise Managerのリストアまたはリカバリウィザードを使用してブロックをリカバリするか、RMANで直接リカバリします。たとえば、RMANブロック・メディア・リカバリを使用して特定の破損ブロックをリカバリするには、次のようにします。
RMAN> RECOVER BLOCK DATAFILE 7 BLOCK 3;
破損ブロックを修復すると、この破損ブロックを示す行がV$DATABASE_BLOCK_CORRUPTIONビューから削除されます。
|
関連項目: RMANのブロック・メディア・リカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
不良なコントローラまたはその他のハードウェアやソフトウェアの問題によりプライマリ・データベースの破損が広範囲の場合は、プライマリ・データベース・サーバーを修復する一方でスタンバイ・データベースにフェイルオーバーまたはスイッチオーバーできます。次の場合には、データの破損またはデータ障害にData Guardスイッチオーバーまたはフェイルオーバーを使用します。
データベースが停止しているか、データベースが稼働していてもデータの破損や障害によりアプリケーションが使用不能であり、ローカルでのリストアとリカバリにかかる時間が長いか不明な場合。
ローカルでのリカバリ時間が、ビジネス品質保証契約またはRTOより長くなる場合。(FSFOおよび書込みの欠落に対するブローカの属性を使用して、これとORA-1578発生時のトリガーを自動化できます。)
|
関連項目: Data Guardのフェイルオーバーとスイッチオーバーの詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
破損、および逸脱または欠落した書込みの解決に次のいずれの方法も使用できない場合は、RMANの従来のメディア・リカバリを使用します。
|
注意: Data Guardフィジカル・スタンバイがない場合は、従来のメディア・リカバリを使用する必要があります。従来のメディア・リカバリを使用すると、1つ以上のファイルのバックアップ・コピーがリストアされ、データファイル、表領域またはデータベースのリカバリによってデータベースが整合性のとれた状態に戻ります。 |
データファイル・メディア・リカバリでは、RMAN RECOVERコマンドを使用して、データベースのデータファイル全体またはデータファイルのセットをリカバリします。メディア破損としてマークされた、メディア・リカバリを必要とするデータ・ブロックの数が多いか不明の場合、またはファイル全体が失われた場合、関連するデータファイルをリストアおよびリカバリする必要があります。
|
関連項目: 高度なユーザー管理リカバリ・シナリオの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Oracleフラッシュバック・テクノロジは、データ・リカバリの概念を大きく変えるものです。フラッシュバック・テクノロジ以前は、データベースを破損するのは数秒でも、リカバリには数時間から数日を要していました。フラッシュバック・テクノロジを使用すると、エラーを修正する時間が、エラーを起こしたときの時間と同じ程度にまで短縮されます。人為的エラーが発生し、データベース、表、トランザクションまたは行レベルの変更を過去の任意の時点に戻す必要がある場合でも、データベースやオブジェクトをリストアすることなくそれらのエラーを簡単に修復できます。フラッシュバック・テクノロジでは、間違った行削除などの局所的な障害を詳細に分析して修復できます。また、フラッシュバック・テクノロジでは、不適切なアプリケーション・バッチ・ジョブを誤って実行した場合など、広範囲に影響が及ぶ障害を修復することも可能です。さらに、フラッシュバック・テクノロジは、データベース・リストアと比較して非常に高速です。
フラッシュバック・テクノロジは、次のような人為的エラーを修復する場合にのみ使用できます。
間違いによる(または悪意のある)更新、削除または挿入トランザクション
間違いによる(または悪意のある)DROP TABLE文
間違いによる(または悪意のある)バッチ・ジョブまたは広範囲に影響が及ぶアプリケーション・エラー
フラッシュバック・テクノロジは、ブロック破損、ディスク障害、ファイル削除などのメディア破損やデータ破損には使用できません。これらの停止を修復するには、12.2.2項「セカンダリ・データベースでのデータベース・フェイルオーバー」を参照してください。
表12-6に、行の破壊(不適切な更新を使用した場合など)からデータベース全体の破壊(オペレーティング・システム・レベルで基礎となるファイルをすべて削除した場合など)まで、停止範囲に応じた各種のフラッシュバック・ソリューションをまとめます。
表12-6 様々な障害のフラッシュバック・ソリューション
| 停止範囲 | 人為的エラーの例 | フラッシュバック・ソリューション | 関連項目 |
|---|---|---|---|
|
行またはトランザクション |
意図しない行の削除 間違ったトランザクション |
|
|
|
表 |
表の削除 1つの表または表のセットに影響を与える間違ったトランザクション |
|
関連項目: 12.2.8.1項「表の非一貫性の解決」 |
|
表領域またはデータベース |
多くの表または不明な表のセットに影響を与える間違ったバッチ・ジョブ データベース全体を対象とする悪意のある一連のトランザクション |
フラッシュバック・データベースの有効化またはFLASHBACK TABLEコマンドの複数回使用 |
|
|
単一の表領域、または複数の表領域のサブセット |
少数の表領域に影響を与える間違ったトランザクション |
RMAN表領域のPoint-in-Timeリカバリ(TSPITR) |
表12-7に、各フラッシュバック機能をまとめます。
表12-7 フラッシュバック機能のまとめ
フラッシュバック・データベースでは、Oracleデータベースのフラッシュバック・ログを使用し、他のすべてのフラッシュバック・テクノロジ機能では、Oracleデータベース独自のUNDO機能とマルチバージョン読取り一貫性機能を使用します。詳細は、4.1項「データベース構成の高可用性および高速リカバリのベスト・プラクティス」に記載されているデータベース構成上のベスト・プラクティスを参照して、障害時にこれらのソリューションでリソースを使用できるようフラッシュバック・テクノロジを構成してください。
|
関連項目:
|
一般的に、フラッシュバック・テクノロジを使用した場合のリカバリ時間は、人為的エラーの発生に要した時間と人為的エラーの検出に要した時間の合計に等しくなります。
フラッシュバック・テクノロジでは、人為的エラーが発生した時点までリカバリすることが可能です。
次のリカバリ方法を使用できます。
誤ってデータベース・オブジェクトを削除することは、よくあります。ユーザーはすぐこの間違いに気付きますが、その時点ではすでに遅く、削除した表とその索引、制約、トリガーを簡単に元に戻す方法はなくなっています。以前は、一度削除したオブジェクトは永久的に失われていました。非常に重要な表やその他のオブジェクト(索引、パーティションまたはクラスタ)が失われた場合、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-11 14.00.00','dd-Mon-yy hh24:mi:ss');
この文により、タイムスタンプで指定した過去の時点から現在までの間に発生したORDERS表とORDER_ITEMS表に対するすべての更新が元に戻されます。フラッシュバック表では、この操作がオンラインでインプレース実行されると同時に、表間の参照整合性制約も維持されます。
フラッシュバック・ドロップ
フラッシュバック・ドロップは、オブジェクトを削除するときの安全策を提供します。ユーザーが表を削除すると、その表はごみ箱に配置されます。ごみ箱のオブジェクトは、ユーザーがそれらを永久的に削除することを決定するまで、またはその表を含む表領域の領域制限に到達するまでそのまま格納されます。ごみ箱は、すべての削除済オブジェクトが存在する仮想的なコンテナです。ユーザーは、ごみ箱を参照して、削除済の表とその依存オブジェクトを元に戻すことができます。たとえば、employees表とそのすべての依存オブジェクトを元に戻すには、次の文を使用します。
FLASHBACK TABLE employees TO BEFORE DROP;
フラッシュバック・トランザクション
Oracleフラッシュバック・トランザクションでは、データベースをオンラインにしたままで、特定のトランザクションまたはトランザクションのセットを簡単かつ迅速に取り消すことができ、ロジカル・リカバリ時の可用性が向上します。
トランザクションとその依存トランザクションをロールバックするには、DBMS_FLASHBACK.TRANSACTION_BACKOUT() PL/SQLプロシージャを使用します。このプロシージャは、UNDOデータを使用して、影響を受けたデータをトランザクション前の状態に戻す補正トランザクションを作成、実行します。
|
関連項目:
|
行およびトランザクションの非一貫性を解決するには、フラッシュバック問合せ、フラッシュバック・バージョン問合せ、フラッシュバック・トランザクション問合せ、および問題を修正するためのUNDO文で構成された補正SQL文を組み合せて使用する必要があります。この項では、人事管理の例を使用して、間違いによる(または悪意のある)ユーザー・エラーによって引き起こされた行およびトランザクションの非一貫性を解決するための一般的な方法について説明します。
フラッシュバック問合せ
フラッシュバック問合せでは、管理者やユーザーが以前のある時点でのデータを問合せできます。この機能は、間違って削除または変更されたデータを参照および再構築する際に使用します。
開発者は、フラッシュバック問合せを使用して、アプリケーションにセルフサービスのエラー修正機能を組み込み、エンド・ユーザーにエラーをすぐに元に戻して修正する機能を提供し、それらの作業からデータベース管理者を解放します。過去に設定された時間に合せてデータを再構築するのに必要な情報は、データベースで自動的に維持されるため、フラッシュバック問合せの管理は簡単です。
次の部分的な文により、2011年6月28日午後2時以降のEMPLOYEES表から行が選択されて表示されます。
SELECT * FROM EMPLOYEES
AS OF TIMESTAMP
TO_DATE('28-Jun-11 14:00','DD-Mon-YY HH24:MI')
WHERE ...
フラッシュバック・バージョン問合せ
フラッシュバック・バージョン問合せでは、データベースの変更を行レベルで参照できます。フラッシュバック・バージョン問合せは、SQLの拡張機能であり、指定した時間間隔で異なるバージョンの行をすべて取得できます。たとえば、次のようになります。
SELECT * FROM EMPLOYEES
VERSIONS BETWEEN TIMESTAMP
TO_DATE('28-Jun-11 14:00','dd-Mon-YY hh24:mi') AND
TO_DATE('28-Jun-11 15:00','dd-Mon-YY hh24:mi')
WHERE ...
この文により、2011年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-11 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-11 08.48.43 AM 28-JUN-11 08.54.49 AM 0006000800000086
7521 WARD 1875 28-JUN-11 08.54.49 AM 28-JUN-11 09.10.09 AM 0009000500000089
7521 WARD 1250 28-JUN-11 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データベースを過去の時点に戻すための従来のメソッドは、Point-in-Timeリカバリです。ただし、Point-in-Timeリカバリは、データベース全体をバックアップからリストアし、データベースでエラーが発生する前の時点にリカバリする必要があるため、数時間または数日かかる場合があります。データベースのサイズは絶えず拡大しているため、データベース全体をリストアするだけでも数時間から数日かかります。
フラッシュバック・データベースは、ポイント・イン・タイム・リカバリを実行するための手段です。フラッシュバック・データベースを使用すると、論理的データ破損またはユーザー・エラーを原因とする問題を修正するために、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を使用して、目的の時点にリカバリするか(スタンバイ・データベースがプライマリ・データベースより遅れている場合)、目的の時点にフラッシュバックします(スタンバイ・データベースに十分なフラッシュバック・ログが存在する場合)。
バックアップからリストアします。
データベースのフラッシュバック後は、スタンバイ・データベースなどの依存データベースもすべてフラッシュバックする必要があります。12.3項「フォルト・トレランスのリストア」を参照してください。
フラッシュバック・データベースでは、削除した表領域は自動的に修復されませんが、フラッシュバック・データベースを使用して停止時間を大幅に短縮できます。表領域が削除される前の時点にプライマリ・データベースをフラッシュバックして、SET NEWNAMEを使用して関連する表領域から対応するデータファイルのバックアップをリストアし、表領域が削除される前の時点にリカバリできます。
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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
一部のアプリケーションは、複数のデータベースを更新でき、分散トランザクションに関与できます。関与するデータベース間のグローバルな一貫性は、アプリケーションに不可欠です。
分散データベース環境の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 Site Guardは、Oracle Fusion Middleware、Oracle Fusion ApplicationsおよびOracleデータベースの調整されたフェイルオーバーを編成して自動化します。また、拡張して、別のデータ・センターのソフトウェア・コンポーネントを組み込むことも可能です。Oracle Site Guardは、プライマリ環境とスタンバイ環境を同期し、ミッション・クリティカルなデータを保護する基礎となるレプリケーション・メカニズムと統合できます。Oracleデータベース用のOracle Data GuardやOracle Sun ZFSのサポートが組み込まれています。また、Oracle Site Guardは、他のストレージ・レプリケーション・テクノロジをサポートすることも可能です。
|
関連項目:
|
高可用性アーキテクチャのコンポーネントに障害が発生するたびに、アーキテクチャの完全保護またはフォルト・トレランスが損われ、コンポーネントが修復されるまで単一点障害が存在する可能性があります。高可用性アーキテクチャを完全なフォルト・トレランスにリストアして完全なOracle RAC、Data GuardまたはMAA保護を再確立するには、障害のあるコンポーネントの修復が必要です。計画停止時間中は完全なフォルト・トレランスが犠牲になることがありますが、計画済であるため修復の方法はよく理解されており、リスクは管理され、継続的なアプリケーション可用性に最適な時点で実行されます。一方、計画外の停止時間については、単一点障害のリスクを明確に理解する必要があります。
この項には、データベースのフォルト・トレランスを回復するのに必要な手順を記載した次の項目が含まれます。
Oracle RACまたはOracle RAC One Nodeを使用したOracle Database 11gの場合
Data Guardを使用したOracle Database 11gと、Oracle RACおよびData Guardを使用したOracle Database 11g(MAA)の場合
アプリケーション・サービスをOracle RACクラスタ内(またはプライマリ・サイトとセカンダリ・サイト間)で自動的にすばやくフェイルオーバーすることは、計画済の停止と計画外の停止の両方に備えるうえで重要です。同様に、Oracle RAC One Nodeを使用して、Oracle RAC One Nodeインスタンスに障害が発生した場合に起動する新しいインスタンスにアプリケーションがフェイルオーバーすることを確認する必要があります。また、エラーまたは問題の修正後に、環境で完全なフォルト・トレランスを回復するためには、Oracle RACクラスタ内または各サイトのデータベースで障害インスタンスや障害ノードをリストアするための手順およびプロセスを理解しておくことも重要です。
特定のコンポーネントに最初に障害を発生させる原因となった主要な問題を修正したら、クラスタに障害ノードを戻すことや、Oracle RACまたはOracle RAC One Nodeの障害インスタンスを再起動することは簡単です。ただし、次のことを検討する必要があります。
現在稼働中の環境に影響をまったく与えないか、最小限の影響で抑えるためにこれらのタスクを実行するのに最適な時期
既存の接続のフェイルバックまたは再調整
ノードまたはインスタンスの最初の障害を引き起こした問題を修正したら、ノードまたはインスタンスを再起動していつでもOracle RAC環境に戻すことができます。Oracle RAC One Nodeでは、障害インスタンスを再起動し、元のノードでインスタンスを実行することもできます。ノードの再構成を完了するための処理では、追加のシステム・リソースを必要とする場合があります。
表12-8に、ノードの追加時に必要とされる可能性のある追加処理をまとめます。
表12-8 ノードまたはインスタンスの再起動または再結合時の追加処理
| アクション | 追加リソース |
|---|---|
|
ノードの再起動またはクラスタへのノードの再結合 |
Oracleクラスタウェアのみを使用している場合、ノードをクラスタに結合することによる影響はありません。 ベンダーのクラスタウェアを使用している場合、ノードをクラスタに戻すための再構成中にパフォーマンスが低下する可能性があります。現在のアプリケーションに対する影響は、フル・ワークロードのテストで評価しておく必要があります。 |
|
Oracle RACインスタンスの再起動または再結合 |
Oracle RACインスタンスを再起動する場合、ロックの再構成中はパフォーマンスに多少影響する可能性があります。現在のアプリケーションに対する影響は、通常はほとんどありませんが、フル・ワークロードのテストで評価しておく必要があります。 |
次のリカバリ方法を使用できます。
|
関連項目:
|
|
注意: サービス可用性のリカバリに関するこれらの説明はOracle RACに関するものであり、Oracle RAC One Nodeシステムには適用されません。 |
障害ノードがクラスタに戻され、そのインスタンスが起動されると、Cluster Ready Services(CRS)によってノードで使用される仮想IPアドレスと、インスタンスでサポートされるサービスが自動的に管理されます。リストアされたインスタンスでは、特定のサービスが起動される場合と起動されない場合があります。CRSがリストアされたインスタンスでサービスを起動するかどうかは、サービスがどのように構成されているかと、その時点で適切な数のインスタンスがサービスへのアクセスを提供しているかどうかによって決定されます。最初の障害が発生したときにCRSによって移動された稼働中のインスタンスで、サービスが現在も適切に提供されている場合、そのサービスは優先インスタンスに再配置されません。
CRSがリストアされたインスタンスでサービスを再起動するのは、クラスタ全体でサービスへのアクセスを提供しているインスタンスの数が、そのサービスに定義されている優先インスタンスの数より少ない場合です。CRSは、リストアされたインスタンスでサービスを再起動すると、登録アプリケーションにサービスの変更を通知します。
たとえば、HRサービスがインスタンスAおよびBでは優先として定義され、インスタンスCおよびDでは障害発生時に使用可能として定義されているとします。インスタンスBに障害が発生すると、CRSはCでHRサービスを自動的に開始し、インスタンスBが再起動された後もHRサービスはインスタンスCに残ります。CRSは、サービスを優先インスタンスに自動的には再配置しません。
HRサービスがインスタンスA、B、C、Dで優先として定義され、使用可能として定義されているインスタンスはなく、サービスがクラスタ内のすべてのノードに分散している別のシナリオについて考えます。インスタンスBに障害が発生した場合、HRサービスは他の3つのノードで使用可能なままになります。HRサービスは構成されているインスタンス数よりも少ないインスタンスで実行されているため、CRSは、インスタンスBがクラスタに再結合されたときにインスタンスBでHRサービスを自動的に開始します。CRSは、HRサービスがインスタンスBで再び使用可能になったことをアプリケーションに通知します。
|
関連項目: 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』 |
Oracle RAC One Nodeデータベースの管理は、Oracle RACデータベースまたは単一インスタンス・データベースとは若干異なります。管理者管理Oracle RAC One Nodeデータベースの場合は、候補ノード・リストを監視し、可能であればサーバーがいつでもフェイルオーバーに使用できるようにしておく必要があります。候補サーバーは汎用サーバー・プールに存在し、データベースとそのサービスは、いずれかの候補サーバーにフェイルオーバーします。
ポリシー管理Oracle RAC One Nodeデータベースの場合は、その現在のノードが使用できなくなった場合に備えて、サーバーがデータベースのフェイルオーバーに使用できるようにサーバー・プールが確実に構成されている必要があります。また、ポリシー管理Oracle RAC One Nodeデータベースでは、オンライン・データベース再配置用の宛先ノードを、データベースのサーバー・プールに配置する必要があります。
|
関連項目: Oracle RAC One Nodeの管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
Oracle RACインスタンスのリストア後、システムの現在のリソース使用状況とパフォーマンス、アプリケーション構成、および実装されているネットワーク・ロード・バランシング機能によっては、追加の手順を実行する必要があります。
稼働を続けているOracleインスタンス上でフェイルオーバーまたは新規セッションとして開始された可能性のある既存の接続は、再起動されたインスタンスに自動的には再配布またはフェイルバックされません。現在のリソース使用率と、稼働を続けているインスタンスがワークロードを十分に処理でき、許容されるレスポンス時間を提供するかどうかに応じて、ユーザーのフェイルバックまたは再配布が必要な場合と不要な場合とがあります。稼働を続けているOracle RACインスタンスに、ワークロード全体を実行するのに十分なリソースがないか、許容されるレスポンス時間を提供しない場合は、一部の既存のユーザー接続を再起動されたインスタンスに移動(切断して再接続)することが必要な場合があります。
|
注意: Oracle RAC One Nodeでは、データベースに対してインスタンスが1つのみあります(移行していない場合)。したがってOracle RAC One Node構成では、接続が1つしかないため、接続の"リバランス"の戦略を再考する必要はありません。Oracle RAC One Nodeを使用しているクライアントは、サービスのステータスに関する通知を受けるために、FANやその他のクライアントおよびサービス機能を操作できる必要があります。 |
接続ロード・バランシングが構成されている場合は、使用頻度の最も低いノードで必要に応じて接続が開始されます。したがって、接続は、時間の経過とともに自動的に分散されます。
アプリケーション・サービスでは、次の構成を使用できます。
Oracle RACインスタンスのサブセットで稼働するサービスで管理される構成。
パーティション化しない構成: すべてのサービスがすべてのノードで均等に稼働します。
これは、データセットの結合を維持したままアプリケーションおよびデータベースの形式と機能をモジュール化する際に役立ちます。アプリケーションをパーティション化する場合、またはパーティション化と非パーティション化の組合せを使用する場合、各サービスのレスポンス時間と可用性を考慮する必要があります。
特定のサービスの接続を再分散またはフェイルバックする必要がある場合、Oracle Universal Connection Pool (UCP)を使用してワークロードを自動的にリバランスできます。UCPを使用している場合、接続は新しいノードに自動的に再分散されます。
|
注意: Oracle Universal Connection Pool(UCP)は、高速接続フェイルオーバーとFANイベントを使用して、接続障害を高速かつ自動的に検出し、Javaアプリケーションの終了した接続を削除します。 |
複数のOracle RACインスタンス間のロード・バランシング・アプリケーション・サービスには、Oracle Net接続時フェイルオーバーと接続ロード・バランシングをお薦めします。この機能には、フェイルオーバーまたはリストアの変更や修正は不要です。ハードウェア・ベースのロード・バランサも使用できます。ただし、個々のアプリケーション・サービスの区別(Oracle Net Servicesでは認識されます)とインスタンスまたはノードのリストアには制限がある場合があります。たとえば、ノードまたはインスタンスがリストアされ、接続の受信を開始できるようになった場合、リストアされたノードまたはインスタンスをハードウェア・ベースのロード・バランサ・ロジックに含めるには手動の手順が必要な場合がありますが、Oracle Net Servicesでは手動再構成は不要です。
表12-9に、インスタンス・リストア後の新規および既存の接続に関する考慮事項をまとめます。これらの考慮事項は、パーティション化、非パーティション化、またはその両方の組合せというアプリケーション・サービスの構成に応じて変化します。既存の接続の再分散が実際に必要であるかどうかは、リソース使用状況とレスポンス時間に応じて決定されます。
表12-9 リストアおよび接続フェイルバック
| アプリケーション・サービス | 既存の接続のフェイルバックまたはリストア | 新規接続のフェイルバックまたはリストア |
|---|---|---|
|
パーティション化 |
既存のセッションは、リストアされたインスタンスに自動的に再配置されません。 |
Oracle Net Services構成の使用により、リストアされたインスタンスに自動的にルーティングされます。 |
|
非パーティション化 |
インスタンスがリストアされた時点でそのインスタンスの負荷は低いため、負荷を再調整する必要がなければ特に何もする必要はありません。負荷を再調整する必要がある場合は、アプリケーション・サービスをパーティション化している場合と同様の問題が発生します。 |
Oracle Net Services構成の使用により、リストアされたインスタンスに自動的にルーティングされます(そのインスタンスの負荷が最も低いため)。 |
図12-7は、2つのノードでパーティション化されたOracle RACデータベースを示しています。各インスタンスでは、異なるアプリケーション機能(HRおよびSales)が提供されます。クライアント・プロセスは、必要とするサービスに基づいて適切なインスタンスに接続します。
図12-8は、1つのOracle RACインスタンスに障害が発生した場合を示しています。
図12-8 パーティション化されたデータベースでのOracle RACインスタンスのフェイルオーバー
1つのOracle RACインスタンスに障害が発生すると、サービスと既存のクライアント接続は、別のOracle RACインスタンスに自動的にフェイルオーバーされます。この例の場合、HRサービスとSalesサービスは、両方とも稼働を続けるOracle RACインスタンスによってサポートされます。また、Salesサービスに対する新規クライアント接続は、Salesサービスのサポートを開始したインスタンスにルーティングされます。
障害インスタンスが修復およびリストアされて図12-7の状態に戻り、Salesサービスがリストアされたインスタンスに再配置されると、フェイルオーバーされたクライアントと、フェイルオーバー先のインスタンスのSalesサービスに接続されていた新規クライアントは、それぞれ識別されてフェイルバックされる可能性があります。インスタンスのリストア後に開始したクライアント接続は、自動的に元のインスタンスに接続されます。したがって、時間の経過とともに古い接続は切断され、新規セッションはSalesサービスに接続されるため、クライアント負荷はリストアされたインスタンスに戻ります。リストアの直後に負荷の再調整が発生するかどうかは、リソース使用状況とアプリケーションのレスポンス時間に応じて決定されます。
図12-9は、パーティション化されていないアプリケーションを示しています。サービスは、アクティブな2つのインスタンス間で均等に分散されます。各インスタンスには、HRとSalesに対するクライアント接続が混在しています。
1つのOracle RACインストールに障害が発生した場合、Oracle Clusterwareは障害インスタンスで実行されていたサービスを移動します。1つのOracle RACインスタンスに障害が発生した場合、新しいクライアント接続はそのサービスを提供する残りのインスタンスでのみ受け入れられます。
障害インスタンスが修復およびリストアされて図12-9の状態に戻ると、一部のクライアントはリストアされたインスタンスに戻される可能性があります。パーティション化されていないアプリケーションでは、すべての使用可能なインスタンス間でクライアント負荷を再調整するために適切なサービスを識別する必要はありません。この処理は、単一インスタンス・データベースでリクエストを十分に処理できない場合にのみ必要です。
インスタンスのリストア後に開始したクライアント接続は、自動的にリストアされたインスタンスに接続されます(そのインスタンスの負荷が他と比べて低いためです)。したがって、時間の経過とともに古い接続は切断され、新規セッションはリストアされたインスタンスに接続されるため、クライアント負荷は再び使用可能なすべてのOracle RACインスタンス間で均等に分散されます。リストアの直後に負荷の再調整が発生するかどうかは、リソース使用状況とアプリケーションのレスポンス時間に応じて決定されます。
フェイルオーバーを必要とするプライマリ・データベースの計画外の停止後、スタンバイ・データベースが再確立されるまで完全なフォルト・トレランスは損われます。データベースの完全保護は、可能なかぎり迅速に回復する必要があります。フォルト・トレランスを回復する手順は、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースで多少異なります。
Data Guardファスト・スタート・フェイルオーバーを使用している場合、データベースは自動的に復元されます。ファスト・スタート・フェイルオーバーの完了後、オブザーバは元のプライマリ・データベースをスタンバイ・データベースとして自動的に回復しようとします。復元により、ブローカ構成に高可用性が回復され、新規プライマリ・データベースに障害が発生した場合に再度ファスト・スタート・フェイルオーバーを起動できます。復元されたデータベースは、新規プライマリ・データベース用としてファスト・スタート・フェイルオーバーのターゲットとなるため、再度のファスト・スタート・フェイルオーバーが可能になります。スタンバイ・データベースは、新規プライマリ・データベースから受信されたREDOデータの適用を開始することで、フェイルオーバーの実行可能なターゲットとなります。フェイルオーバーの完了後に診断作業や修復作業を実行するなど、自動復元を行わない場合、FastStartFailoverAutoReinstate構成プロパティをFALSEに設定します。
FastStartFailoverAutoReinstate構成プロパティは、プライマリ・データベースがFastStartFailoverThresholdプロパティで指定された秒数を超えて孤立したことによりファスト・スタート・フェイルオーバーが開始したためにファスト・スタート・フェイルオーバーが発生した後で、オブザーバが元のプライマリ・データベースを自動的に回復する必要があるかどうかを制御します。場合によっては、診断またはリカバリ作業が終了するまで自動復元は不要です。
元のプライマリ・データベースを復元する場合、データベースを起動してマウントする必要がありますが、オープンすることはできません。ブローカは、元のスタンバイ・データベースと同じタイプ(フィジカルまたはロジカル)のスタンバイ・データベースとしてデータベースを復元します。
元のプライマリ・データベースが自動的に復元されない場合、DGMGRL REINSTATEコマンドまたはEnterprise Managerを使用して手動で復元できます。手動復元の詳細な手順は、『Oracle Data Guard Broker』を参照してください。
Oracleのフラッシュバック・データベース機能を使用する場合、スタンバイ・データベースを再作成する必要はありません。フラッシュバック・データベースには、次のメリットがあります。
数時間に及ぶデータベースのリストア時間を節約できます。
フォルト・トレランスを回復する際の全体的な複雑さを軽減できます。
スタンバイ・データベースが迅速に再作成されるため、システムが脆弱である時間が短縮されます。
|
関連項目:
|
この項には、次の項目が含まれます。
ファスト・スタート・フェイルオーバーの後、オブザーバは、定期的に以前のプライマリ・データベースに再接続するよう試みます。以前のプライマリ・データベースへのネットワーク・アクセスを再確立すると、オブザーバは、ブローカに対するリクエストを起動して、そのデータベースを新規プライマリ・データベース用のスタンバイ・データベースとして自動的に復元します。これにより、構成における障害保護と高可用性が迅速に回復されます。
ファスト・スタート・フェイルオーバーは、ブローカ構成内のデータベースに接続しながら、Enterprise Managerでオブザーバ・サイトを含む任意のサイトから有効化できます。ブローカでは、Oracle Enterprise Managerのページでボタンを1回クリックするだけで簡単にスイッチオーバーやフェイルオーバーを起動できます。
Enterprise Managerを使用して、元のプライマリ・データベースを新規スタンバイ・データベースとして復元することも可能です。図12-10は、復元が必要な場合にEnterprise Managerに表示される警告メッセージの例を示しています。
12.2.6.3項「データ領域ディスク・グループ障害」または12.2.6.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概要および管理』 |
データ障害やメディア障害など、データファイルの完全リストアまたは部分リストアを必要とするスタンバイ・データベースでの計画外の停止後、スタンバイ・データベースが稼働を再開するまで完全なフォルト・トレランスは損われます。データベースの完全保護は、可能なかぎり迅速に回復する必要があります。
ロジカル・スタンバイ・データベース上のデータの破損とデータ障害を修復するには、プライマリ・データベースからのバックアップではなくロジカル・スタンバイ・ファイルのバックアップが必要です。または、破損の影響を受ける関連オブジェクトを回復または再作成する必要があります。スタンバイ・データベースのデータ破損またはデータ障害を修復するには、次の修復ソリューションを使用できます。
RMANとブロック・メディア・リカバリの使用(12.2.7.3項「RMANとブロック・メディア・リカバリの使用」で説明しました)。
RMANとデータファイル・メディア・リカバリの使用 (12.2.7.5項「RMANとデータファイル・メディア・リカバリの使用」で説明しました)。
ロジカル・スタンバイ・データベースのみのオブジェクトの手動再作成(14.2.6.7項「手動によるオブジェクトの再作成」で説明します)。
スタンバイ・データベースの停止のために、プライマリ・データベースの保護モードを最大保護モードから最大可用性モードまたは最大パフォーマンス・モードに変更する必要があった場合、ビジネス要件に応じて最大保護モードに戻します。
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE [PROTECTION | AVAILABILITY];
プライマリ・データベースが、論理エラーの修正のためにフラッシュバックされたか、任意の時点にリストアおよびリカバリされてアクティブ化された場合、状況によっては対応するスタンバイ・データベースで追加メンテナンスを実行する必要があります。プライマリ・データベースのリカバリがリセットログ操作なしで完了した場合、追加の作業は必要ありません。
RESETLOGSオプション付きでプライマリ・データベースをオープンした後に、表12-12の問合せを実行します。
表12-12 RESETLOGS SCNと現在のSCN OPEN RESETLOGSを確認するための問合せ
| データベース | 問合せ |
|---|---|
|
プライマリ |
|
|
フィジカル・スタンバイ |
|
|
ロジカル・スタンバイ |
|
表12-13に、スタンバイ・データベースがプライマリ・データベースのリセットログSCNより遅れている場合に、フォルト・トレランスを回復するために実行できるアクションを示します。
表12-13 スタンバイ・データベースのSCNがプライマリ・データベースのRESETLOGS SCNより遅れている場合のアクション
| データベース | アクション |
|---|---|
|
フィジカル・スタンバイ |
|
|
ロジカル・スタンバイ |
スタンバイ・データベースがプライマリ・データベースからアーカイブREDOログ・ファイルを受信していることを確認します。 |
表12-14に、スタンバイ・データベースがプライマリ・データベースのリセットログSCNより進んでいる場合に、フォルト・トレランスを回復するために実行できるアクションを示します。
表12-14 スタンバイ・データベースのSCNがプライマリ・データベースのリセットログSCNより進んでいる場合のアクション
| データベース | アクション |
|---|---|
|
フィジカル・スタンバイ |
|
|
ロジカル・スタンバイ |
|
スタンバイ・データベースとプライマリ・データベースの両方に影響する二重障害が発生した場合、先にプライマリ・データベースを再作成する必要があります。各サイトは同一であるため、最新のバックアップが存在する場所であればどこでもプライマリ・データベースを作成できます。
表12-15に、使用可能なバックアップのタイプに応じたリカバリ計画をまとめます。
表12-15 プライマリ・データベースとスタンバイ・データベースの再作成
| 使用可能なバックアップ | プライマリ・データベースの再作成 |
|---|---|
|
ZDBRAによって管理されるバックアップ(REDOを含む) |
データベース全体および関連のREDOをリストアし、データ損失ゼロをほぼ実現します。 |
|
プライマリ・データベースとスタンバイ・データベースのローカル・バックアップ |
プライマリ・データベースのバックアップをリストアします。データベースをリカバリして新規プライマリ・データベースとしてアクティブ化します。 |
|
スタンバイ・データベースにのみ存在するローカル・バックアップ。スタンバイ・データベースのテープ・バックアップ。 |
スタンバイ・データベースのローカル・バックアップをスタンバイ・データベースにリストアします。データベースをリカバリして新規プライマリ・データベースとしてアクティブ化します。 |
|
テープ・バックアップのみ |
テープ・バックアップをローカルでリストアします。データベースをリカバリして新規プライマリ・データベースとしてアクティブ化します。 |
|
関連項目: プライマリ・データベースを再作成した後のスタンバイ・データベースの作成手順は、『Oracle Data Guard概要および管理』を参照してください。 |
