| Oracle Data Guard Broker 11gリリース1（11.1） E05756-02 |
|
 戻る |
 次へ |
この章では、Oracle Enterprise Manager Grid Control 10.2提供のData Guard Brokerグラフィカル・ユーザー・インタフェース（GUI）について説明します。これは現在、Enterprise Managerで使用可能な最新のブローカ・インタフェースです。このインタフェースを使用して、Oracle Database 11gリリース1（11.1）Data Guard構成を作成、管理および監視できます。
この章の内容は、次のとおりです。
Data GuardのWebページにアクセスするには、Oracle Enterprise ManagerのGrid Controlから次の手順を実行します。
|
注意: Oracle Enterprise Manager Grid Controlにより、Data Guard 10.2の機能一式にアクセスできます。Enterprise Manager Database Controlでは、Data Guardの制限された監視限定機能が使用できます。 |
「ターゲット」タブをクリックして「ターゲット」ページにアクセスします。
「データベース」をクリックして「データベース」ページにアクセスします。
「データベース」ページでは、検出されたデータベースすべてのリストが表示されます。この使用例では、プライマリ・データベースNorth_Salesがすでに検出されています。North_Salesデータベースをクリックし、プライマリ・データベースのホーム・ページにアクセスします。
「管理」をクリックします。
「高可用性」セクションの「Data Guard」で、「設定および管理」をクリックしてログインします。
|
注意: SYSDBA権限を持つユーザーとしてログインすると、すべての監視および管理機能を含め、Data Guardの全機能にアクセスできます。非SYSDBAユーザーとしてログインした場合にアクセスできるのは監視機能のみで、スタンバイの作成、スイッチオーバーおよびフェイルオーバーなどの機能は使用できません。 |
プライマリ・データベースがブローカ構成に含まれていない場合は、手順5で「設定および管理」をクリックして図6-1に示すページにアクセスします。このスクリーンショットは、「すべてのターゲット」タブに表示される情報を示しており、クラスタについて検出されたすべてのターゲットのグラフが含まれます。管理対象ターゲットのリストから、ターゲットの可用性をすばやく評価し、任意のグラフをクリックして詳細にドリルダウンできます。
プライマリ・データベースがすでにブローカ構成に含まれている場合は、手順5で「設定および管理」をクリックして図6-2に示すData Guardの概要ページにアクセスします。
Data Guardの概要ページで、次の操作を実行できます。
保護モードの編集: 「Data Guard」の「概要」セクションで「保護モード」をクリックすると現在の保護モード設定が表示され、必要に応じて保護モードを変更できます。
ファスト・スタート・フェイルオーバーの有効化: 「無効」をクリックするとファスト・スタート・フェイルオーバー・ウィザードが起動し、ファスト・スタート・フェイルオーバーおよびオブザーバの有効化プロセスが順を追って示されます。
スタンバイの進捗サマリーの表示: このグラフは、各スタンバイ・データベースがまだ受信および適用していないデータの量を示します。
プライマリ・データベースに関する情報の取得: 「名前」、「ホスト」、「ステータス」、「現行ログ」または「プロパティ」（「編集」）をクリックすると、プライマリ・データベースの関連情報が表示されます。
「ステータス」または「編集」をクリックすると「プロパティの編集」ページが表示され、プライマリ・データベースの現在の状態やプロパティを表示して変更できます。
スタンバイ・データベースに関する情報の表示または変更:
ブローカ構成へのスタンバイ・データベースの追加: 「スタンバイ・データベースの追加」をクリックすると、フィジカルまたはロジカルのスタンバイ・データベースを追加できます。
状態またはプロパティの変更: 「編集」をクリックすると、「プロパティの編集」ページにアクセスし、スタンバイ・データベースの現在の状態またはプロパティを表示して変更できます。
Data Guard Broker制御の切断: 「削除」をクリックすると、選択したスタンバイ・データベースをData Guard Broker制御から削除できます。
スタンバイからプライマリへのロールの切替え: 「スイッチオーバー」をクリックすると、データベース・ロールをスタンバイからプライマリに切り替えることができます。
スタンバイ・データベースからプライマリ・データベースのロールへの推移: プライマリ・データベースで災害などの障害が発生し、プライマリ・データベースを適時にリカバリできる可能性がない場合は、「フェイルオーバー」をクリックします。ターゲット・スタンバイ・データベースがプライマリ・ロールを引き継ぎ、障害が発生したプライマリ・データベースはブローカにより無効化されます。障害が発生したプライマリ・データベースを、新しいプライマリ・データベースのスタンバイ・データベースとして再有効化する手順については、5.4.3項を参照してください。
構成のパフォーマンス情報と、スタンバイ・データベースごとのオンラインREDOログ・ファイルのステータスの表示:
「パフォーマンス概要」をクリックすると、アーカイブされ適用済のデータ、スタンバイの進捗サマリーおよびログ・サービスのサマリーに関する情報が表示されます。
「ログ・ファイルの詳細」をクリックすると、プライマリ・データベース上で生成されたがスタンバイで受信されていないオンラインREDOログ・ファイルのステータスと、スタンバイ・データベースで受信されたが適用されていないオンラインREDOログ・ファイルのステータスが表示されます。
その他の管理アクティビティの実行:
「検査」をクリックすると、保護モードとプロパティをチェックし、スタンバイREDOログ・ファイルが存在することを確認し、ログ・スイッチを検証できます。
「Data Guard構成の削除」をクリックすると、Data Guard Broker制御からブローカ構成を削除できます。
Enterprise Managerのトピックに関する情報の検索: —「ヘルプ」をクリックすると、「Oracle Data Guardにようこそ」のヘルプ・トピックが表示されます。オンライン・ヘルプ・システムからは、「コンテンツ」ページまたは「検索」ページを使用して必要なヘルプ・トピックを検索できます。
データベースの管理および監視を行うには、最初にブローカ構成を作成する必要があります。Enterprise Managerにはスタンバイ・データベースの追加ウィザードが用意されており、1つのプライマリ・データベースと1つ以上のスタンバイ・データベースを含むブローカ構成を作成できます。この使用例では、後でスタンバイ・データベースの追加ウィザードを使用し、すでにフィジカル・スタンバイ・データベース（DR_Sales）が1つ含まれるブローカ構成にロジカル・スタンバイ・データベースを追加する方法を示しています。スタンバイ・データベースの追加ウィザードを起動するには、Data Guardの概要ページで「スタンバイ・データベースの追加」をクリックします。
「スタンバイ・データベースの追加」をクリックし、次のオプションから1つ選択できます。
新規のフィジカル・スタンバイ・データベースの作成（単一インスタンスのみ）
新規のロジカル・スタンバイ・データベースの作成（単一インスタンスのみ）
Data Guard Brokerを使用した既存のスタンバイ・データベースの管理
プライマリ・データベースのバックアップのみを作成
まだ接続していない場合は、SYSDBAの接続情報を使用してプライマリ・データベースに接続する必要があります。
|
関連項目: Oracle RACスタンバイ・データベースを作成する手順については、『Oracle Data Guard概要および管理』を参照してください。 |
図6-3に、構成の作成プロセスの初期ページを示します。
スタンバイ・データベースの追加ウィザードに表示される指示に従って、次の手順を実行します。
次の手順では、プライマリ・データベースおよびフィジカル・スタンバイ・データベースが1つずつ含まれるブローカ構成がすでに存在することを前提としており、新規ロジカル・スタンバイ・データベースを作成します。ウィザードに表示される指示に従って、データベースのOracleホームを選択し、データファイルをスタンバイ・データベースにコピーする追加の手順を示します。
手順1 バックアップ・タイプの決定
Enterprise Managerでは、Oracle Recovery Manager（RMAN）を使用して、プライマリ・データベースの新規または既存のバックアップから単一インスタンスのスタンバイ・データベースを作成できます。2つのバックアップ操作から一方を選択し、スタンバイ・データベースの作成に使用できます。
プライマリ・データベース稼働中にバックアップを実行
プライマリ・データベースの既存のバックアップを使用
図6-4に、ロジカル・スタンバイ・データベースを追加する場合の、構成プロセスの手順1を示します。
図6-4 スタンバイ・データベースの追加ウィザード: バックアップ・タイプ（ロジカル・スタンバイ・データベース）
「取消」をクリックすると、現在のプロセスを終了してスタンバイ・データベースの追加ウィザードの初期ページからやりなおすことができます。
図6-5に、ロジカル・スタンバイ・データベースを追加する場合に表示される追加画面内容を示します。
図6-5 スタンバイ・データベースの追加ウィザード: バックアップ・タイプ（ロジカル・スタンバイ・データベース）
手順2 バックアップ・オプションの設定
プライマリ・データベースのバックアップ・ファイルを格納するために、作業ディレクトリが必要です。このディレクトリを必要に応じて保持し、将来追加するスタンバイ・データベースの作成に使用できます。作業ディレクトリを作成できるプライマリ・ホスト上の位置を指定します。
この手順にはプライマリ・ホストの接続情報が必要です。プライマリ・データベースのOracleサーバー・インストール所有者の接続情報を入力します。「優先資格証明として保存」ボックスを選択すると、これらの接続情報を保存できます。
「取消」をクリックすると、現在のプロセスを終了してスタンバイ・データベースの追加ウィザードの初期ページからやりなおすことができます。
図6-6に、構成プロセスの手順2を示します。
手順3 スタンバイ・データベースを作成するOracleホームの選択
スタンバイ・データベースは、Oracle Enterprise Managerで検出された任意のOracleホームに作成できます。プライマリ・ホストのオペレーティング・システムと一致するホスト上のOracleホームのみが表示されます。検出されたOracleホームを選択し、スタンバイ・データベースの一意のインスタンス名を入力する必要があります。手順を続行するには、スタンバイ・ホストの接続情報が必要です。
図6-7に、構成プロセスの手順3を示します。
手順4 スタンバイ・データベースのファイル位置の設定
ブローカ構成の作成プロセスの一部として、プライマリ・データベースのデータファイルをスタンバイ・ホストで使用可能にする必要があります。スタンバイ・データベース・ファイルの位置をカスタマイズするためのオプションが用意されています。手順を続行するには、スタンバイ・ホストの接続情報が必要です。オプションを次に示します。
バックアップ・ファイルへのアクセス方法の指定
プライマリ・データベースのバックアップ・ファイルをスタンバイ・ホストからアクセス可能にする方法を選択します。次の2つのオプションから選択できます。
プライマリ・ホストの作業ディレクトリからスタンバイ・ホストの作業ディレクトリにファイルを転送
ネットワーク・パス名を使用してスタンバイ・ホストからプライマリ・ホストの作業ディレクトリの場所に直接アクセス
スタンバイ・データベースのファイル位置の指定
スタンバイ・データベース・ファイルの位置を選択します。次の2つのオプションから選択できます。
Oracle OFA (Optimal Flexible Architecture)に変換してください
ファイル名と場所をプライマリ・データベースと同じ場所に保持
ネットワーク構成ファイルの位置の指定
Data Guardにより、スタンバイ・データベースの構成情報が、スタンバイ・ホスト上の指定したディレクトリにあるネットワーク構成ファイル（listener.oraおよびtnsnames.ora）に追加されます。
「取消」をクリックすると、現在のプロセスを終了してスタンバイ・データベースの追加ウィザードの初期ページからやりなおすことができます。
図6-8に、構成プロセスの手順4を示します。
手順5 スタンバイ・データベースの構成パラメータの設定
スタンバイ・データベースの構成パラメータを設定する必要があります。これらのパラメータには、データベース名、データベースの一意名、ターゲット名およびスタンバイのアーカイブ位置が含まれます。スタンバイのアーカイブ位置には、通常のディレクトリまたはフラッシュ・リカバリ領域を指定できます。デフォルト値は、対応するプライマリ・データベース設定に基づきます。
「取消」をクリックすると、現在のプロセスを終了してスタンバイ・データベースの追加ウィザードの初期ページからやりなおすことができます。
図6-9に、構成プロセスの手順5を示します。
手順6 「終了」をクリックする前の情報の確認
スタンバイ・データベースの追加ウィザードでは、構成とスタンバイ・データベースに関して入力したデータを最後に確認できます。すべての情報が適切であることを確認してから「終了」をクリックします。
「取消」をクリックすると、現在のプロセスを終了してスタンバイ・データベースの追加ウィザードの初期ページからやりなおすことができます。
図6-10に、構成プロセスの手順6を示します。
「スタンバイ・データベース記憶域」をクリックすると、すべてのスタンバイ・データベース・ファイルの位置に関する追加情報を表示できます。
「終了」をクリックすると、データベース作成プロセスがOracle Enterprise Managerジョブとして実行されます。ジョブの発行前であれば、いつでもスタンバイの作成を取り消すことができます。図6-11に、スタンバイ・データベースの作成プロセスを示します。
ジョブの発行後は、Data Guardの概要ページに戻ります。「スタンバイ・データベース」表の「ステータス」列に「作成の進行中」と表示されます。このリンクをクリックすると、スタンバイ・データベース作成の進捗を監視できます。図6-12に、このリンクを含むData Guardの概要ページを示します。
構成の初期作成後にスタンバイ・データベースを追加するには、「スタンバイ・データベースの追加」をクリックしてスタンバイ・データベースの追加ウィザードを再度実行します。
スタンバイ・データベースの追加ウィザードではOracle RACスタンバイ・データベースを作成できませんが、Data Guard構成に既存のRACスタンバイ・データベースを追加できます。「スタンバイ・データベースの追加」をクリックしてスタンバイ・データベースの追加ウィザードを実行し、「既存のスタンバイ・データベースの追加」を選択します。
図6-13に、スタンバイ・データベースの追加ウィザードの初期ページを示します。
スタンバイ・データベースの追加ウィザードに表示される指示に従って、次の手順を実行します。
手順1 既存のスタンバイ・データベースの選択
この手順では、構成に追加するRACスタンバイ・データベースを選択します。環境内で検出されたすべてのデータベース（RACおよび非RACデータベースの両方）が、リストに表示されます。図6-14（手順1）の例では、リストに表示されているデータベースの1つ（RAC10g）がOracle RACスタンバイ・データベースです。
「取消」をクリックすると、現在のプロセスを終了してスタンバイ・データベースの追加ウィザードの初期ページからやりなおすことができます。
続行する場合は「次へ」をクリックします。
手順2 スタンバイ・アーカイブ位置の設定
図6-15（手順2）に示すように、必要に応じて、既存のスタンバイ・クラスタ・データベースの「スタンバイ・アーカイブの場所」の設定を変更できます。
続行する場合は「次へ」をクリックします。
手順3 構成設定の確認
図6-16（手順3）に示す構成とスタンバイ・データベースのデータを確認します。
「取消」をクリックすると、現在のプロセスを終了してスタンバイ・データベースの追加ウィザードの初期ページからやりなおすことができます。
操作を完了する場合は「終了」をクリックします。
ブローカ構成のデータベースに接続されているかぎり、オブザーバ・サイトを含め、任意のサイトからファスト・スタート・フェイルオーバーを有効化できます。ファスト・スタート・フェイルオーバーを有効化しても、フェイルオーバーは起動されません。かわりに、オブザーバが、プライマリ・データベースとスタンバイ・データベースの監視を開始し、フェイルオーバーの条件が満たされた場合に、ファスト・スタート・フェイルオーバーを起動できるようになります。
この項では、ファスト・スタート・フェイルオーバーおよびオブザーバを有効化する手順を説明します。
手順1 ファスト・スタート・フェイルオーバー・ウィザードの起動
「ファスト・スタート・フェイルオーバー」ステータス・フィールドの横にあるData Guardの概要ページで、「無効」をクリックしてファスト・スタート・フェイルオーバー・ウィザードを開きます。
手順2 ターゲット・データベースおよびファスト・スタート・フェイルオーバーのプロパティの構成
「ファスト・スタート・フェイルオーバー: 構成」ページで、次の操作を実行します。
ファスト・スタート・フェイルオーバーのターゲットとするスタンバイ・データベースを選択し、ファスト・スタート・フェイルオーバーのプロパティを設定します。図6-17の例では、フィジカル・スタンバイ・データベースDR_Salesをターゲット・スタンバイ・データベースとして選択しています。
「オブザーバの設定」をクリックし、オブザーバが動作するシステムおよびOracleホームを指定します。
オブザーバが現在定義されていない場合、「オブザーバのホスト」および「オブザーバのOracleホーム」フィールドは空です。「オブザーバのホスト」および「オブザーバのOracleホーム」フィールドを直接編集するか（この場合、指定されたホストがすでにEnterprise Managerにより検出されている必要があります）、またはEnterprise Managerにより示された検出済ホストとそのOracleホームのリストから選択できます。「オブザーバのホスト」および「オブザーバのOracleホーム」フィールドを空のままにした場合、ファスト・スタート・フェイルオーバーを構成できますが、オブザーバを手動で起動して、ファスト・スタート・フェイルオーバー可能な状態にする必要があります。
オブザーバのホストおよびホームがすでにEnterprise Managerで認識されている場合、「オブザーバの設定」ページが表示されたときの「オブザーバのホスト」フィールドには、それらの値が表示されます。オブザーバの場所は変更できます。この場合、現在のオブザーバが停止し、Enterprise Managerでは指定のホストで新規オブザーバを起動するようにリモート操作が実行されます。
図6-18に、「オブザーバの設定」ページを示します。
|
注意: Enterprise ManagerのGrid Controlによってオブザーバを実行している場合、オブザーバからの出力は次のログ・ファイルに書き込まれます。ORACLE_HOME\rdbms\log\dgmgrl<pid>.log この例では、 |
FastStartFailoverThreshold構成プロパティを設定し、（プライマリ・データベースが使用できないことが検出されてから）フェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースを待機させる秒数を指定します。
「続行」をクリックします。
手順3 フラッシュバック・データベースの有効化
ファスト・スタート・フェイルオーバー・ウィザードの次のページでは、プライマリ・データベースおよびスタンバイ・データベースのフラッシュバック・ロギングを有効化します。プライマリ・データベースまたはターゲット・スタンバイ・データベースのいずれかでフラッシュバック・ロギングが有効化されていない場合、図6-19に示すページが表示されます。このページでは、フラッシュバック・ロギングをアクティブにする必要があるデータベースごとに、フラッシュ・リカバリ領域の場所、フラッシュ・リカバリ領域のサイズおよびフラッシュバック保存時間を指定できます。
手順4 ファスト・スタート・フェイルオーバーの有効化の確認
Enterprise Managerでは、図6-20に示した「確認」ページが表示され、ここでファスト・スタート・フェイルオーバーの開始を確認します。
有効化操作を続行するため「はい」をクリックした場合、図6-21に示すEnterprise Managerの処理中ページが表示されます。処理中ページでは、プログレス・バーおよび有効化操作中に実行されている手順のリストが示されます。ファスト・スタート・フェイルオーバー・ウィザードでは、次の手順が実行されます。
プライマリ・データベースおよびスタンバイ・データベースで、スタンバイREDOログ・ファイルが作成されます。
必要に応じて、保護モードが「最大可用性」にアップグレードされます。
必要に応じて、プライマリ・データベースおよびスタンバイ・データベースが再起動されます。
ファスト・スタート・フェイルオーバーが有効化されます。
オブザーバ・プロセスが開始されます。
一部の手順は実行されない場合があります。たとえば、ファスト・スタート・フェイルオーバーではData Guard構成が最大可用性モードまたは最大パフォーマンス・モードのいずれかで動作している必要があるため、この使用例には保護モードの変更手順が含まれており、構成の保護モードが最大パフォーマンスから最大可用性にアップグレードされます。
操作が完了すると、Enterprise ManagerではData Guardの概要ページが表示され、「有効」ステータスが「オブザーバのホスト」とともに示されます。
図6-22に、この使用例でどのようにしてファスト・スタート・フェイルオーバーが「DR_Salesに対して有効」となっているかを示しています。このステータス・フィールドをクリックした場合、ファスト・スタート・フェイルオーバー・ウィザードが再度起動し、ファスト・スタート・フェイルオーバーを無効化する手順が順を追って示されます。
ファスト・スタート・フェイルオーバーおよびオブザーバを有効化した後は、オブザーバが継続的に環境を監視してプライマリ・データベースが使用可能であることを確認します。オブザーバが問題を検出した場合、FastStartFailoverThresholdプロパティで指定された時間内で、プライマリ・データベースへの再接続を試行します。その時間内に問題が改善されず、ターゲット・スタンバイ・データベースがフェイルオーバー可能な状態である場合、オブザーバはただちにファスト・スタート・フェイルオーバーを起動します。ファスト・スタート・フェイルオーバーは自動的かつ高速に実行されるため、回復が必要であるか、またはすでに実行されていることがわかるまで、ファスト・スタート・フェイルオーバーが実行されたことに気付かない場合があります。
図6-23に、回復が必要なときに表示される警告メッセージの例を示しています。
また、「アラート・ログ・エラー」ページのメトリックを参照し、ファスト・スタート・フェイルオーバー環境に関する情報を取得できます。このページでは、エラーが含まれるログ・エントリのリストを参照できます。データベース・アラートを参照するには、データベース・ホーム・ページにナビゲートし、「診断サマリー」セクションで「アラート・ログ」リンクを選択します。エラーは、行ごとに重大度レベルおよびタイム・スタンプが含まれる表にリストされます。「カテゴリ」列には、エラーのカテゴリ・タイプの説明が示されます。「データの表示」を使用してリストをフィルタ処理し、1日、1週間または1か月分のデータを表示できます。
図6-24に、ファスト・スタート・フェイルオーバーが発生した後のNorth_Salesデータベースの「アラート・ログ・エラー」ページの例を示しています。
Enterprise Managerを使用して、構成で実行する必要のある定期的なメンテナンス作業の一部を簡素化できます。以降の項に示す例には、次の方法を示します。
この項では、スタンバイ・データベースを「ログ適用オフ」に設定する方法について説明します。
スタンバイ・データベースの状態を「ログ適用オフ」に変更する手順は、次のとおりです。
Data Guardの概要ページで、「ログ適用オフ」状態に変更するスタンバイ・データベースを選択します。
「編集」をクリックして「プロパティの編集」ページにアクセスします。
「ログ適用オフ」を選択します。
「適用」をクリックします。
プロセスが完了すると、正常終了を示すメッセージが戻されます。
図6-25に、データベースの状態の変更に使用できる「プロパティの編集」ページを示します。
スタンバイ・データベースの状態を「ログ適用オフ」に変更すると、REDO Apply（またはロジカル・スタンバイ・データベースの場合はSQL Apply）はそのスタンバイ・データベースに対するREDOデータの適用を停止します。ただし、プライマリ・データベースのREDO転送サービスは影響されないため、スタンバイ・データベースは引き続きプライマリ・データベースからREDOデータを受け取ります。
メンテナンス作業の完了後は、同じ手順でデータベースをオンラインに戻すことができます。
Enterprise Managerでは、データベース・プロパティはプライマリ、スタンバイおよび共有の3つにわけられます。
プロパティを表示または変更する手順は、次のとおりです。
Data Guardの概要ページで、「プライマリ・データベース」セクションの「編集」をクリックするか、「スタンバイ・データベース」セクションの「編集」をクリックします。
次のどちらかをクリックします。
スタンバイ・ロール・プロパティ
共有プロパティ
適切な変更を行って「適用」をクリックします。
プロセスが完了すると、正常終了を示すメッセージが戻されます。
図6-26に、スタンバイ・データベースに固有のプロパティを示します。
「拡張プロパティの表示」をクリックすると、図6-27に示すように、スタンバイ・データベースに固有の追加のプロパティを表示できます。
図6-28に、プライマリ・データベースとスタンバイ・データベースの両方に共通するプロパティを示します。
Enterprise Managerを使用すると、ブローカ構成全体の保護モードを変更できます。
最初に作成された構成は、デフォルトで最大パフォーマンス・モードに設定されています。この項では、最大保護モードにアップグレードするためのプロセスについて説明します。最大保護モードでは、プライマリ・データベースの障害時にもデータが消失しないことが保証されます。
最大保護モードを設定する手順は、次のとおりです。
Data Guardの概要ページで、「概要」セクションにある「最大パフォーマンス」をクリックします。
「最大保護」を選択して「続行」をクリックします。
図6-29に、「保護モードの編集」ページを示します。
図6-30にリストされたスタンバイ・データベースから、最大保護モードをサポートする必要のあるデータベースを1つ以上選択します。プライマリ・データベースおよび選択したスタンバイ・データベースについては、REDO転送サービス（および構成可能なデータベース・プロパティLogXptMode）が自動的にSYNCに設定されます。
Data Guard Brokerでは、構成内のすべてのデータベースに必要なスタンバイREDOログ・ファイルの正しい数とサイズが自動的に判断され、指定したディレクトリ位置を使用して、これらのログ・ファイルが追加されます。「続行」をクリックして続行します。
図6-30 保護モードの変更: スタンバイ・データベースおよびオンラインREDOログ・ファイル
保護モードを変更することを確認します。続行するには「はい」、取り消すには「いいえ」をクリックします。この使用例では、「はい」をクリックして変更を受け入れることを想定しています。次に、図6-31に示すように、「処理中: 保護モードの変更」ページが表示されます。
保護モードが正常に更新されると、図6-32に示すData Guardの概要ページが表示されます。
プライマリ・データベースとスタンバイ・データベース間でスイッチオーバーが必要となる場合があります。この使用例では、スイッチオーバー操作を使用して、プライマリ・データベースとスタンバイ・データベース間でロールを切り替えるプロセスについて説明します。
スイッチオーバーを実行する手順は、次のとおりです。
プライマリ・データベースとなるスタンバイ・データベースを選択します。
「スイッチオーバー」をクリックします。
スイッチオーバーを続行するには「はい」をクリックします。取り消すには「いいえ」をクリックします。
図6-33は、スイッチオーバー確認ページを示します。
スイッチオーバー操作では、次の手順が実行されます。
プライマリ・データベースとスタンバイ・データベースが現在エラー・ステータスの状態ではないことが確認され、プライマリ・データベースのブローカ管理が有効で実行中であることが検証されます。
スイッチオーバー・ターゲットがフィジカル・スタンバイ・データベースの場合は、「プライマリ・データベース・セッションの参照」リンクを使用して、プライマリに接続中のアクティブなユーザー・セッションを表示できます。これらのセッションは、スイッチオーバー時に自動的にクローズされます。
スイッチオーバーでは、最初にプライマリ・データベースがスタンバイ・ロールに変更され、次にスタンバイ・データベースがプライマリ・ロールに変更されます。スイッチオーバーの進捗を示す進捗インジケータが表示されます。
スイッチオーバー・ターゲットがフィジカル・スタンバイ・データベースの場合は、そのデータベースとプライマリ・データベースの両方が再起動されます。
図6-34は、スイッチオーバー時の処理中ページを示します。
図6-35に、スイッチオーバーが正常に終了した後のData Guardの概要ページを示します。
この使用例では、フェイルオーバー操作を使用してフィジカル・スタンバイ・データベースの1つ（この場合はDR_Sales）をプライマリ・ロールに推移する手順について説明します。フェイルオーバーは、ソフトウェア障害またはシステム障害が発生した結果、プライマリ・データベースが消失した場合にのみ実行してください。障害が発生したプライマリ・データベースはブローカにより無効化されるため、再有効化する必要があります。また、スタンバイ・データベースはプライマリ・データベースのロールを引き継ぎます。障害が発生したプライマリ・データベースを、新しいプライマリ・データベースのスタンバイ・データベースとして再有効化する手順については、5.4.3項を参照してください。
図6-36のData Guardの概要ページには、プライマリ・データベースへのアクセスに関する問題を示すORA-16625エラー・ステータスが表示されています。
DR_Salesをプライマリ・ロールに推移するには、「スタンバイ・データベース」表で、DR_Salesを選択して「フェイルオーバー」をクリックします。
図6-37に、フェイルオーバー確認ページを示します。
プライマリ・データベースの障害を適時にリカバリできないと判断した場合は、フェイルオーバー操作を起動できます。フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの両方が含まれる構成では、フィジカル・スタンバイ・データベースをフェイルオーバー・ターゲットとして使用することをお薦めします。これは、こうすることで、ロジカル・スタンバイ・データベースが新規プライマリ・データベースのロジカル・スタンバイとして引き続き機能できるためです。ロジカル・スタンバイにフェイルオーバーが実行された場合、構成内のフィジカル・スタンバイを新規プライマリ・データベースのバックアップから再作成する必要があります。
フェイルオーバー操作では、次の2種類のフェイルオーバー操作から1つ選択できます。
完全: 使用可能なすべてのREDOがスタンバイ・データベースで適用されるため、データ消失を最小限に抑えられます。
即時: 追加のデータはスタンバイ・データベースに適用されないため、データが失われる可能性があります。これが最も高速なタイプのフェイルオーバーです。
図6-38に、フェイルオーバー操作の進捗を示します。
フェイルオーバー中に、選択したスタンバイ・データベースがプライマリ・ロールに推移します。フェイルオーバー・ターゲットがフィジカル・スタンバイ・データベースの場合は、そのデータベースが再起動されます。完了すると、Data Guardの概要ページには、図6-39に示すように更新後の構成が反映されます。
この図の「Data Guardステータス」列は、元のプライマリ・データベース（North_Sales）が無効化され、フィジカル・スタンバイ・データベースとして再有効化されるまでEnterprise Managerでは管理できなくなったことを示しています。
Enterprise Managerには、プライマリ・データベースとスタンバイ・データベースのオンラインREDOログ・ファイル・アクティビティのみでなく、構成のステータスを監視するいくつかの方法が用意されています。Data Guardの概要ページには、構成に関する情報と、そのデータベースに関する要約情報も最も基本的なレベルで表示されます。
|
注意: SYSDBA以外のユーザーとしてログインしている場合も、Data Guardの監視機能にアクセスできます。ただし、スタンバイの作成、スイッチオーバーおよびフェイルオーバーなど、すべての管理機能には、SYSDBA接続が必要です。 |
たとえば、Data Guardの概要ページの要約情報には、構成内のすべてのデータベースのステータスが示されます。特定のスタンバイ・データベースに対してREDO ApplyまたはSQL Applyがオフになっている理由の詳細を知るには、「スタンバイ・データベース」表でそのデータベースの「ステータス」リンクを選択してプロパティ・ページを表示します。Data Guard固有のデータベース・プロパティが不適切な場合や一貫性がない場合、または他のパラメータと競合していることがわかった場合は、「プロパティの編集」ページで、そのデータベースに対して警告のフラグが付けられます。「ステータス」リンクの横には、ステータスの状態を示す様々なアイコンが表示されます。プライマリ・データベースが正常に動作している場合は緑のチェック・マーク、警告がある場合は感嘆符を囲む黄色の三角形、エラー状態がある場合は赤いXが表示されます。
プライマリ・データベースのステータスをチェックするには、Data Guardの概要ページの「プライマリ・データベース」セクションで「ステータス」を選択します。
「スタンバイ・データベース」表に表示されるスタンバイ・データベースのステータスをチェックするには、「ステータス」列のリンクを選択します。
たとえば、黄色の警告アイコン上に移動すると、「黄色の警告アイコンは、プロパティの不一致が検出されたことを示します。このプロパティの値は、Data Guardとデータベースの間、Data Guardとサーバー・パラメータ・ファイルの間、またはその両方の間で一致していません。」というメッセージが表示されます。
図6-40に、オブザーバがファスト・スタート・フェイルオーバー構成を監視しなくなったため構成がエラーを戻した場合の、Data Guardの概要ページを示します。
次の項では、構成のステータスと健全性を監視する方法について説明します。
ブローカ構成の全体の健全性をすばやくチェックするもう1つの方法は、検証操作を実行することです。検証操作では、構成内の各データベースの健全性チェックなど、ブローカ構成に関する一連の妥当性チェックが実行されます。実行されるチェックは、次のとおりです。
各データベースの現行のREDO転送サービス設定、およびスタンバイREDOログ・ファイルが正しく構成されているかどうかなど、現在のデータ保護モードの設定を示します。いずれかのデータベースにスタンバイREDOログ・ファイルが必要な場合は、検証結果を使用すると自動的に構成できます。
各データベースの現在のステータスを検証します。
プライマリ・データベースでログ・スイッチを実行し、そのログ・ファイルが各スタンバイ・データベースに適用されたことを確認します。
検証操作の結果を、エラー（ある場合）も含めて表示します。エラーがなく、少なくとも1つのスタンバイ・データベースにオンラインREDOログ・ファイルが正しく適用された場合、検証操作は正常に完了します。
検出されないデータベースまたはRACインスタンスを表示します。未検出のデータベースおよびインスタンスがあると、フェイルオーバーまたはスイッチオーバーが正常に完了しない可能性があります。
データベース・プロパティとデータベース自体での対応する値との間の不一致を検出します。これらの不一致を解決するメカニズムも用意されています。
|
注意: 検証操作は、「取消」をクリックしていつでも停止できます。 |
構成を検証するには、Data Guardの概要ページの「追加管理」セクションで「検査」をクリックします。図6-41を参照してください。「検査」コマンドを選択すると進捗インジケータが表示されます。検証操作が正常に完了した場合、そのブローカ構成は健全で、データは保護されており、スイッチオーバーまたはフェイルオーバーの準備ができている状態です。
検証操作が正常に完了した場合、そのブローカ構成は健全で、データは保護されており、スイッチオーバーまたはフェイルオーバー操作の準備ができている状態です。検証の処理中ページは、いつでも取り消すことができます。
図6-42に、検証操作が正常に完了した後の結果を示します。
プライマリ・データベース上で生成されたがスタンバイ・データベースで受信されていないアーカイブREDOログ・ファイル、およびスタンバイ・データベースで受信されたが適用されていないアーカイブREDOログ・ファイルについてのステータスを、構成内のスタンバイ・データベースごとに示す表があります。この「ログ・ファイルの詳細」ページを使用すると、REDO転送サービスまたはログ適用サービスが停止された場合にログ・ファイル情報を判断できます。通常の操作中は、各スタンバイ表は空です。
たとえば、REDO転送サービスが予期せずにオフラインになると、プライマリ・データベースでは引き続きアーカイブREDOログ・ファイルが生成されますが、REDO転送サービスはアーカイブREDOログ・ファイルをスタンバイ・データベースに送信しません。「ログ・ファイルの詳細」ページを表示すると、スタンバイ・データベースごとに受信されていないログ・ファイルを確認できます。
「ログ・ファイルの詳細」ページには、プライマリ・データベース上の現在のログ・ファイルのログ順序番号を示す「プライマリの現行ログ」エントリがあります。
スタンバイ・データベースごとに、REDO転送情報およびログ適用情報が表示され、ログ・ファイルの累積情報を診断できます。表6-1に、スタンバイ表の各列を示します。
表6-1 「ログ・ファイルの詳細」ページ
| 列名 | 説明 |
|---|---|
|
ログ |
ログ順序番号。 |
|
ステータス |
ログ・ファイルのステータス。 |
|
未受信 |
ログ・ファイルは受信されていません。 |
|
未適用 |
ログ・ファイルは適用されていません。 |
|
最初の変更番号(SCN) |
最初のシステム変更番号。 |
|
最終変更番号(SCN) |
最後のシステム変更番号。 |
|
サイズ（KB） |
ログ・ファイルのサイズ（KB単位）。 |
|
生成時間 |
ログ・ファイルが生成された時刻。 |
|
完了時間 |
ログ・ファイルが完了した時刻。 |
Data Guardの概要ページで「ログ・ファイルの詳細」をクリックすると、図6-43に示すページが表示されます。
さらに詳細なパフォーマンスの監視を行うには、構成内のすべてのオンラインREDOログ・ファイル・アクティビティを要約したパフォーマンス・グラフを使用して、ブローカ構成の詳細なパフォーマンス統計を表示できます。このグラフは、指定可能な収集間隔（データがプライマリ・データベースから抽出される頻度）に基づいてリフレッシュされます。デフォルトの収集間隔は30秒です。この値は変更できます。パフォーマンスの抽出頻度の詳細は、オンライン・ヘルプを参照してください。
「パフォーマンス概要」ページでは、構成内のすべてのデータベースからパフォーマンス関連情報が収集されます。グラフはすべてメトリックで表されます。通常、グラフでは2時間分のデータが示されます。任意のグラフをクリックして、履歴データを参照できます（24時間/日、7日/週、31日/月など）。頻度の計算では、（適用または生成された）REDOの量を収集間隔（デフォルトは、パフォーマンス・ページでは1分、メトリックでは5分です）で割った値を求めます。
REDO生成率: このグラフは、プライマリのREDO生成率（KB/秒）を示します。
ラグ・タイム: 「転送ラグ」（スタンバイ・データベースでまだ使用できないREDOのおおよその秒数）および「適用ラグ」（スタンバイ・データベースがプライマリ・データベースより遅れているおおよその秒数）を示します。
適用頻度: スタンバイ適用率（KB/秒）を示します。「現在のREDO生成率」は最新の値を示します。「アクティブの場合の適用率(最後の3ログ、KB/秒)」の値は、最新の3つのログ・ファイルを平均した場合の実際の適用率を示します。
テスト・アプリケーション: テスト・アプリケーションは、プライマリ・データベースでワークロードを生成する組込みアプリケーションです。これは、プライマリ・データベースに負荷がかかっている場合のパフォーマンス・メトリックを表示する簡単な方法です。
概要: プライマリ・データベースの名前とステータスを示します。ステータス・リンクをクリックすると、ステータス・メトリックの履歴の要約が表示されます。注意: パフォーマンス・ページ上のステータスは、5分の収集間隔で実行されるステータス・メトリックから直接表示されます。Data Guardの概要ページ上のステータスは、リフレッシュごとに必ず更新されます。
「パフォーマンス概要」ページには、ページが表示されると同時にグラフ情報が表示されます。オフラインまたは無効なデータベースのデータは収集されません。
Oracle Enterprise Managerでは自動的に、プライマリ・データベースとスタンバイ・データベースのステータスおよびアーカイブREDOログ・ファイル・アクティビティが監視されます。次のリストに、Data Guardのメトリックを示しています。
Data Guardファスト・スタート・フェイルオーバー:
ファスト・スタート・フェイルオーバーの発生
ファスト・スタート・フェイルオーバーSCN
ファスト・スタート・フェイルオーバーの時間
Data Guardパフォーマンス
適用ラグ（秒）
推定フェイルオーバー時間（秒）
REDO適用率(KB/秒)
転送ラグ（秒）
Data Guardステータス
いずれかのメトリックが起動された場合に電子メールで通知するように、電子メール・サービスを設定できます。
|
関連項目: メトリックの登録と電子メール・サービスの使用方法の詳細は、Enterprise Managerのヘルプおよびマニュアルを参照してください。 |
次の項では、Data Guardのメトリックの詳細を説明します。
ファスト・スタート・フェイルオーバーが有効化されている場合、ファスト・スタート・フェイルオーバーが実行されると、これらのメトリックにより新規プライマリ・データベース（元のスタンバイ）に対するクリティカル・アラートが生成されます。
この項の例では、Data Guardのメトリックと、メトリックが起動されたときに電子メールを介して通知を受け取るように設定する方法について説明します。Data Guardのメトリックを管理する手順は、次のとおりです。
手順1: 電子メールでメトリックの通知を受け取るための設定
いずれかのメトリックが起動された場合に電子メールによる通知を受け取るように、通知方法を設定できます。通知方法を設定する手順は、次のとおりです。
「データベース・ホーム」ページの最下部にある「設定」をクリックします。
「設定」ページで「通知メソッド」をクリックします。
必要なメール・サーバー情報を設定します。
|
関連項目: 電子メール・サービスの詳細は、Oracle Enterprise Managerのマニュアルおよびヘルプを参照してください。 |
手順2: 「すべてのメトリック」ページの表示
「データベース・ホーム」ページの最下部にある「すべてのメトリック」をクリックすると、Data Guardを含めてOracle Enterprise Managerのすべてのメトリックを表示できます。
図6-45に、プライマリ・データベースの「すべてのメトリック」ページでData Guardのメトリックが開かれている場合を示します。
手順3: Data Guardのメトリックのしきい値の設定または変更
次のData Guardのメトリックは、「メトリックおよびポリシー設定」ページで変更できます。
Data Guardファスト・スタート・フェイルオーバー
ファスト・スタート・フェイルオーバーが有効化されている場合、ファスト・スタート・フェイルオーバーが実行されると、これらのメトリックにより新規プライマリ・データベース（元のスタンバイ）に対するクリティカル・アラートが生成されます。
ファスト・スタート・フェイルオーバーの発生: ファスト・スタート・フェイルオーバーが発生したことを示します。この値は、ファスト・スタート・フェイルオーバーが発生していない場合は0（ゼロ）、発生している場合は1となります。
ファスト・スタート・フェイルオーバーSCN: ファスト・スタート・フェイルオーバー発生時のSCNを示します。「ファスト・スタート・フェイルオーバーSCN」は、メトリックによりアラートが生成される前の値に初期化される必要があります。
ファスト・スタート・フェイルオーバーの時間: ファスト・スタート・フェイルオーバー発生時の時間を示します。
Data Guardパフォーマンス
「パフォーマンス概要」ページのグラフはすべて、次のメトリックで表されます。
適用ラグ（秒）: スタンバイ・データベースがプライマリ・データベースより遅れているおおよその秒数を示します。
推定フェイルオーバー時間（秒）: このスタンバイ・データベースへのフェイルオーバーに必要なおおよその秒数です。この秒数は、起動時間と、（必要に応じて）スタンバイに対し使用可能なREDOをすべて適用するために必要な残りの時間を合計した時間に相当します。バウンスが必要ない場合、残りの適用時間のみとなります。
REDO適用率(KB/秒): このスタンバイ・データベースのREDO適用率をKB/秒で示します。
転送ラグ（秒）: スタンバイ・データベースでまだ使用できないREDOのおおよその秒数を示します。
Data Guardステータス
Data Guard Statusメトリックに「警告」が含まれている場合は、警告アラートが起動されます。「エラー」が含まれている場合は、クリティカル・アラートが起動されます。
|
関連項目: メトリックの設定の詳細は、Oracle Enterprise Managerのオンライン・ヘルプを参照してください。 |
手順4 起動済メトリックの表示
メトリック条件が起動されるか、しきい値を超えると、アラートが発行されます。「すべてのメトリック」ページで「Data Guardステータス」、「Data Guardパフォーマンス」または「Data Guardファスト・スタート・フェイルオーバー」をクリックすると、起動済メトリックが表示されます。
図6-46に、North_Salesデータベースの「アラート・ログ・エラー」ページを示しています。この図は、構成内でオブザーバの問題が検出された後、「Data Guardファスト・スタート・フェイルオーバー」メトリックが起動した際に表示される内容の例を示しています。表には、構成内の各データベースのステータスが示されています。プライマリ・データベースのステータスは、ORA-16820エラーを示しています。
電子メール・サービスが設定されているため、DBAも電子メール・メッセージによる通知を受け取ります。
メトリック条件が解決されると、メトリックは自動的に消去されます。
スタンバイ・データベースまたはブローカ構成を削除して、Data Guard Brokerの制御対象から外すことができます。
Data Guard Brokerの制御からスタンバイ・データベースを削除しても、データベース自体が永続的に削除されることはありません。この操作では、スタンバイ・データベースのプロファイルがブローカ構成ファイルから永続的に削除されます。
デフォルトでは、スタンバイの宛先もプライマリ・データベースから削除されるため、そのスタンバイ・データベースにはログ・ファイルがアーカイブされなくなります。
|
注意: Oracle9iのData Guard Managerでは、デフォルトでプライマリ・データベース上にスタンバイの宛先が保持されていました。 |
ブローカ構成からスタンバイ・データベースを削除するには、Data Guardの概要ページの「スタンバイ・データベース」セクションで「削除」をクリックします。Enterprise Managerからスタンバイ・データベースを削除してよいかどうかを確認するプロンプトが表示されます。続行するには「はい」、取り消すには「いいえ」をクリックします。
図6-47に、スタンバイ・データベースの削除を示します。
ブローカ構成を削除するには、プライマリ・データベースを介して構成に接続している必要があります。「追加管理」セクションで「Data Guard構成の削除」をクリックします。Enterprise Managerから、構成を削除するかどうかを確認するプロンプトが表示されます。続行するには「はい」、取り消すには「いいえ」をクリックします。
図6-48に、Data Guard Broker構成の削除を示します。
このオプションを選択すると、選択したブローカ構成はEnterprise Managerによって永続的に削除されます。構成を永続的に削除する場合、削除操作による結果は次のとおりです。
すべてのスタンバイ宛先を保持するボックスを選択すると、スタンバイ・データベースまたはログ適用サービスの基礎となる操作には影響を与えません。REDO転送サービスやログ適用サービスなどの操作は引き続き実行されますが、これらのサービスは、Enterprise Managerで管理できなくなります。
デフォルトでは、すべてのスタンバイ・データベースのプロファイルがブローカ構成から削除され、構成内のすべてのスタンバイ・データベースに対するログ転送サービスが停止します。
各データベースで保守されているすべてのブローカ構成プロファイル情報が破棄されます。削除された構成はブローカで認識できず、Enterprise Managerで管理できなくなります。
構成情報は、1度ブローカ構成から永続的に削除するとリカバリできませんが、スタンバイ・データベースの追加ウィザードを使用すると、構成を簡単に再作成できます。
