| Oracle® Data Guard概要および管理 12c リリース1 (12.1) B71304-07 |
|
 前 |
 次 |
フィジカルおよびスナップショット・スタンバイ・データベースの管理方法の詳細は、次の各項を参照してください。
Oracle Data Guard Brokerによるフィジカルおよびスナップショット・スタンバイ・データベース管理の簡素化方法については、『Oracle Data Guard Broker』を参照してください。
この項では、フィジカル・スタンバイ・データベースを起動および停止する方法について説明します。
フィジカル・スタンバイ・データベースを起動するには、SQL*Plus STARTUPコマンドを使用します。SQL*Plus STARTUPコマンドは、引数を指定せずに起動すると、フィジカル・スタンバイ・データベースを読取り専用モードで起動、マウントおよびオープンします。
フィジカル・スタンバイ・データベースは、マウントまたはオープンされると、プライマリ・データベースからREDOデータを受信できます。
REDO Applyについては「REDOデータのフィジカル・スタンバイ・データベースへの適用」および読取り専用モードでのフィジカル・スタンバイ・データベースのオープンについては、「フィジカル・スタンバイ・データベースのオープン」を参照してください。
注意:
プライマリ・データベースからのREDOデータをまだ受信していないフィジカル・スタンバイ・データベースでREDO Applyを開始すると、ORA-01112メッセージが戻されることがあります。このメッセージは、REDO Applyがメディア・リカバリ用の開始順序番号を判別できないことを示します。このエラーが発生した場合は、スタンバイ・データベースでアーカイブREDOログ・ファイルをプライマリ・データベースから手動で取得して登録するか、またはREDO転送が開始されるまで待機した後、REDO Applyを開始します。
フィジカル・スタンバイ・データベースは、読取り専用アクセス用にオープンし、問合せをプライマリ・データベースからオフロードするために使用できます。
注意:
読取り専用モードで開かれたフィジカル・スタンバイ・データベースは、読取り専用モードで開かれたその他のOracleデータベースと同じ制約を受けます。詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle Active Data Guardオプションのライセンスを購入している場合は、フィジカル・スタンバイ・データベースを開いている間はRedo Applyをアクティブにすることができます。それにより、問合せによって、プライマリ・データベースからのものと同じ結果が得られます。この機能は、リアルタイム問合せ機能と呼ばれます。詳細は、「リアルタイム問合せ」を参照してください。
Oracle Active Data Guardオプションのライセンスを未購入の場合、REDO Applyがアクティブである間は、フィジカル・スタンバイ・データベースをオープンできません。そのため、フィジカル・スタンバイ・データベース・インスタンスのオープン時またはREDO Applyの開始時には、次のルールに従う必要があります。
REDO Applyは、フィジカル・スタンバイ・データベース・インスタンスをオープンする前に停止する必要がある。
1つ以上のフィジカル・スタンバイ・インスタンスがオープンしている場合、REDO Applyを開始する前にこれらのインスタンスを停止する、またはMOUNT状態を再開する必要がある。
関連項目:
Oracle Active Data Guardの詳細は、『Oracle Databaseライセンス情報』を参照してください。
Oracle Active Data Guardオプションのリアルタイム問合せ機能を使用するためには、COMPATIBLEデータベース初期化パラメータを11.0以上に設定する必要があります。
フィジカル・スタンバイ・データベース・インスタンスは、そのデータベースのマウント済インスタンスでREDO Applyがアクティブである場合、オープンできません。次のSQL文を使用してREDO Applyを停止し、スタンバイ・インスタンスを読取り専用でオープンしてREDO Applyを再開します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> ALTER DATABASE OPEN; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
注意:
REDO Applyがオープン・インスタンスでアクティブになっている場合は、REDO Applyを停止せずにその他のインスタンスをオープンすることができます。
REDO Applyは、そのデータベースのいずれかのインスタンスがオープンされている場合、マウント済フィジカル・スタンバイ・インスタンスでは開始できません。REDO Applyを開始する予定のインスタンスは、開始前にオープンしておく必要があります。
例: スタンバイのオープン・モードを調べるためのV$DATABASEの問合せ
この例は、フィジカル・スタンバイがリアルタイム問合せモードで開かれているときのV$DATABASE.OPEN_MODE列の値の変化を示します。
リアルタイム問合せを使用して、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せをオフロードしている場合、適用ラグを監視して許容範囲内かどうかを確認することが必要になる場合があります。
現行の適用ラグとは、最後に適用された変更がスタンバイで表示可能になってから、同じ変更がプライマリで最初に表示可能になるまでに経過した時間です。このメトリックは秒単位で計算されます。
適用ラグを取得するには、V$DATAGUARD_STATSビューを問い合せます。次に例を示します。
SQL> SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS -
> WHERE name like 'apply lag';
NAME VALUE DATUM_TIME TIME_COMPUTED
--------- ------------- ------------------- -------------------
apply lag +00 00:00:00 05/27/2009 08:54:16 05/27/2009 08:54:17
apply lagメトリックの計算には、プライマリ・データベースから定期的に受信されるデータが使用されます。DATUM_TIME列には、このデータがスタンバイ・データベースにより最後に受信されたときのタイムスタンプが格納されます。TIME_COMPUTED列には、apply lagメトリックが計算されたときに取得されたタイムスタンプが格納されます。これらの列の値の差は30秒未満である必要があります。差が30秒以上である場合、apply lagメトリックが正確ではない可能性があります。
スタンバイ・インスタンスが最後に起動されてからの適用ラグ値の履歴を示すヒストグラムを取得するには、V$STANDBY_EVENT_HISTOGRAMビューを問い合せます。次に例を示します。
SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM WHERE NAME = 'apply lag' - > AND COUNT > 0; NAME TIME UNIT COUNT LAST_TIME_UPDATED --------- --------- -------- ----------- ------------------------ apply lag 0 seconds 79681 06/18/2009 10:05:00 apply lag 1 seconds 1006 06/18/2009 10:03:56 apply lag 2 seconds 96 06/18/2009 09:51:06 apply lag 3 seconds 4 06/18/2009 04:12:32 apply lag 4 seconds 1 06/17/2009 11:43:51 apply lag 5 seconds 1 06/17/2009 11:43:52 6 rows selected
ある期間にわたってapply lagを評価するには、その期間の開始時のV$STANDBY_EVENT_HISTOGRAMのスナップショットを取得し、その期間の終了時に取得したスナップショットと比較します。
リアルタイム問合せモードのフィジカル・スタンバイ・データベースへの非管理ユーザーからの問合せで、新しいSTANDBY_MAX_DATA_DELAYセッション・パラメータを使用して特定のセッションの適用ラグの許容値を指定できます。この機能によって、スタンバイ・データベースが許容できないほど失効したかどうかを検出できるため、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せを安全に移動できます。
STANDBY_MAX_DATA_DELAYがデフォルト値NONEに設定されている場合、フィジカル・スタンバイ・データベースに発行された問合せは、そのデータベースの適用ラグに関係なく実行されます。
STANDBY_MAX_DATA_DELAYを0 (ゼロ)以外の値に設定すると、フィジカル・スタンバイ・データベースに発行された問合せは、適用ラグがSTANDBY_MAX_DATA_DELAY以下の場合のみ実行されます。それ以外の場合は、ORA-3172エラーが返され、適用ラグが大きすぎることがクライアントに警告されます。
STANDBY_MAX_DATA_DELAYを0に設定すると、フィジカル・スタンバイ・データベースに発行される問合せは、スタンバイ・データベースがプライマリ・データベースから遅れていないかぎり、その問合せがプライマリ・データベースに発行された場合とまったく同じ結果を返すことが保証されます。遅れている場合、ORA-3172エラーが返されます。
ALTER SESSION SQL文を使用してSTANDBY_MAX_DATA_DELAYを設定します。次に例を示します。
SQL> ALTER SESSION SET STANDBY_MAX_DATA_DELAY=2
フィジカル・スタンバイ・データベースで次のSQL文を発行すると、プライマリ・データベースから受け取ったすべてのREDOデータを確実にフィジカル・スタンバイ・データベースに適用できます。
SQL> ALTER SESSION SYNC WITH PRIMARY;
このコマンドが発行された時点でスタンバイ・データベースが受け取ったすべてのREDOデータが、フィジカル・スタンバイ・データベースに適用されるまで、この文によってその他の処理がブロックされます。スタンバイ・データベースのREDO転送ステータスがSYNCHRONIZEDでない場合、またはREDO Applyがアクティブでない場合は、ORA-3173エラーがすぐに返され、同期は行われません。
特定のケースでREDO Apply同期を確実に行うためには、SYS_CONTEXT('USERENV','DATABASE_ROLE')ファンクションを使用して、スタンバイ専用トリガー(プライマリで有効化されるが、スタンバイで実行される場合のみ特定の処理を実行するトリガー)を作成します。たとえば、特定のユーザー接続に対してログオン時にALTER SESSION SYNC WITH PRIMARY文を実行する次のトリガーを作成することができます。
CREATE TRIGGER adg_logon_sync_trigger
AFTER LOGON ON user.schema
begin
if (SYS_CONTEXT('USERENV', 'DATABASE_ROLE') IN ('PHYSICAL STANDBY')) then
execute immediate 'alter session sync with primary';
end if;
end;
これまでに説明した、適用ラグの制御およびREDO Apply同期のメカニズムでは、クライアントが接続していることと、リアルタイム問合せモードのフィジカル・スタンバイ・データベースに問合せを発行することが必要です。
STANDBY_MAX_DATA_DELAYが0に設定されている場合、またはALTER SESSION SYNC WITH PRIMARY SQL文が使用される場合には、この他に次の制限も適用されます。
スタンバイ・データベースがSYNC転送でREDOデータを受け取ります。
スタンバイ・データベースのREDO転送ステータスはSYNCHRONIZEDである必要があります。また、プライマリ・データベースは、最大保護モードまたは最大可用性モードのいずれかで実行されている必要があります。
リアルタイム適用を有効化しておく必要があります。
Oracle Active Data Guardは、キャッシュ・フュージョンの使用を通じてOracle RAC環境でパフォーマンスの高いリアルタイム問合せを実現しています。これにより、Oracle Data Guardの適用インスタンスおよび問合せは、キャッシュで動作することが可能となり、ディスクI/O制限によって低速化することがなくなります。この結果として、適用インスタンスの予期しない障害が発生すると、Oracle RACのすべてのオープン・インスタンス全体でバッファが一貫性のない状態となります。データの一貫性と整合性を確保するため、Oracle Data GuardはOracle RAC構成の他のすべてのオープン・インスタンスをクローズし、それらをマウント状態に移行します。手動でインスタンスを再オープンする必要があり、その時点でデータは自動的に一貫性を回復し、その後いずれかのインスタンスでREDO Applyが再開されます。Oracle Data Guard Broker構成では、インスタンスは自動的に再オープンされ、REDO Applyは自動的にいずれかのインスタンスで再開されます。
関連項目:
ブローカによる適用インスタンス障害の処理方法の詳細は、『Oracle Data Guard Broker』を参照してください。
Oracle Active Data GuardのOracle RACスタンバイにおける適用インスタンス障害の詳細は、http://support.oracle.comにあるMy Oracle Supportノート1357597.1を参照してください。
データベースのアクセス時に破損データ・ブロックが検出されると、それらのブロックの破損していないコピーで自動的に置き換えることができます。これには次の条件があります。
フィジカル・スタンバイ・データベースがリアルタイム問合せモードで動作している必要があります(Oracle Active Data Guardライセンスが必要)。
フィジカル・スタンバイ・データベースがリアルタイム適用を実行している必要があります。
自動ブロック・メディア・リカバリは、破損ブロックが検出されたのがプライマリかスタンバイかにより、2つの方向で動作します。
プライマリでの破損ブロック
破損データ・ブロックがプライマリ・データベースで検出されると、プライマリはそれらのブロックの破損していないコピーをスタンバイで自動的に検索し、見つかれば、プライマリに送信します。
プライマリには、スタンバイのみ(フィジカル・スタンバイ、カスケード・フィジカル・スタンバイ、または遠隔同期インスタンス)へのLOG_ARCHIVE_DEST_nが必要です。プライマリには、ターミナル宛先へのLOG_ARCHIVE_DEST_nは必要ありません。それらのサービス名は自動的に確認できます。
スタンバイでの破損ブロック
破損データ・ブロックがスタンバイで検出されると、スタンバイは自動的にプライマリとの通信を起動し、それらのブロックの破損していないコピーをリクエストします。破損していないブロックをスタンバイに送信できるプライマリでは、次のデータベース初期化パラメータがスタンバイに構成されている必要があります。これは、プライマリが直接スタンバイにサービスを提供していない場合(カスケード構成など)でも適用されます。
LOG_ARCHIVE_CONFIGパラメータはDG_CONFIGリストを使用して構成され、LOG_ARCHIVE_DEST_nパラメータはプライマリ・データベース用に構成されている。
または
FAL_SERVERパラメータが構成され、その値にプライマリ・データベース用のOracle Netサービス名が含まれている。
自動ブロック・メディア修復の追加の考慮事項
自動修復は、Oracle Data Guardのどの保護モードでもサポートされます。ただし、スタンバイの破損していないバージョンのブロックを使用してプライマリの破損ブロックを修復する場合の効果は、プライマリによって生成されるREDOとスタンバイ適用がどの程度密接に同期化されているかによって変化します。
自動ブロック修復が実行されると、データベースのアラート・ログにメッセージが書き込まれます。
自動ブロック修復が可能でない場合は、ORA-1578エラーが返されます。
破損データ・ブロックを手動で修復するには、RMAN RECOVER BLOCKコマンドを使用します。このコマンドは、データ・ブロックの破損していないコピーをいくつかの場所で探します。デフォルトの場所の1つは、リアルタイム問合せモードで実行しているいずれかのフィジカル・スタンバイ・データベースです。RMAN RECOVER BLOCKコマンドのEXCLUDE STANDBYオプションを使用すると、置換ブロックのコピー元からフィジカル・スタンバイ・データベースを除外することもできます。
関連項目:
RMANのRECOVER BLOCKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
Active Data Guardのベスト・プラクティス・ホワイト・ペーパーでは、フィジカル・スタンバイ・データベースで最適パフォーマンスを実現するための問合せのチューニング方法について説明しています。このホワイト・ペーパーは、次の場所からOracle Maximum Availability Architecture(MAA)のホームページにアクセスして入手することができます。
http://www.oracle.com/goto/maa
全データベース・キャッシュ・モードの強制
全データベース・キャッシュ・モードの強制の使用により、問合せがより高速に実行されるため、パフォーマンスが向上する可能性があります。
全データベース・キャッシュ・モードの強制の有効化および無効化はREDOに記録されないので、インメモリー・キャッシュのステータスはData Guard構成のすべてのメンバーで同じである必要はありません。全データベース・インメモリー・キャッシュの強制機能は、Oracle Database 12cリリース1 (12.1.0.2)以上で使用できます。
全データベース・インメモリー・キャッシュの強制機能の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
読取り専用データベースでのREDO生成は許可されません。データ操作言語(DML)操作がグローバル一時表を変更する場合、一時表のみなので、変更そのものではREDOは生成されません。しかし、変更に対して生成されたUNDOは次にREDOを生成します。Oracle Database 12cリリース1 (12.1)より前では、このことは、読取り専用であるOracle Active Data Guardスタンバイではグローバル一時表を使用できないことを意味しました。
しかし、Oracle Database 12cリリース1 (12.1)では、一時UNDO機能により、グローバル一時表への変更に対するUNDOを、UNDO表領域ではなく一時表領域に格納できます。一時表領域に格納されたUNDOはREDOを生成しないので、グローバル一時表へのREDOなしの変更が可能になります。これにより、Oracle Active Data Guardスタンバイのグローバル一時表でのDML操作が可能になります。この機能は次のようにOracle Data Guardに利点をもたらします。
一時データの格納にグローバル一時表を使用するread-mostlyレポート・アプリケーションは、Oracle Active Data Guardインスタンスに負荷を軽減させることができます。
一時UNDOがプライマリ・データベースで有効化されていると、グローバル一時表への変更のUNDOはREDOに記録されないので、プライマリ・データベースが生成するREDOはより少なくなります。そのため、Oracle Data Guardがスタンバイに送信する必要のあるREDOの量も減少するので、ネットワーク帯域幅と記憶域の使用量が減少します。
プライマリ・データベースで一時UNDOを有効化するには、TEMP_UNDO_ENABLED初期化パラメータを使用します。Oracle Active Data Guardスタンバイでは、一時UNDOはデフォルトで常に有効化されているので、TEMP_UNDO_ENABLEDパラメータは何も影響しません。
注意:
グローバル一時表でのデータ定義言語(DDL)操作(CREATEやDROPなど)は引き続きプライマリ・データベースから発行される必要があります。DDL変更はプライマリ・データベースでキャッチアップするとスタンバイで表示可能です。
制限事項
一時UNDO機能では、データベース初期化パラメータCOMPATIBLEを12.0.0以降に設定する必要があります。
Oracle Active Data Guardインスタンスでの一時UNDO機能は一時BLOBまたは一時CLOBをサポートしません。
ローカル・オブジェクトに対する変更を伴っている場合、Oracle Active Data Guardインスタンス上の分散トランザクションは許可されません。たとえば、Oracle Active Data Guardインスタンスでグローバル一時表を変更し、かつデータベース・リンクを使用して他のデータベース上でリモート表を更新するようなトランザクションは、コミットできません。Active Data Guardインスタンス上のグローバル一時表に対する未処理のDML操作をコミットまたはロールバックしてから、リモートDML操作を発行する、あるいはその逆順を行う必要があります。EXPLAIN PLAN文などの操作によるグローバル一時表への暗黙的な書込みも、これに該当します。
関連項目:
一時表UNDOの詳細は、『Oracle Database管理者ガイド』を参照してください。
TEMP_UNDO_ENABLED初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
Oracle Active Data Guard環境では、デフォルトのCACHEオプションおよびNOORDERオプションでプライマリ・データベースによって作成された順序には、スタンバイ・データベースからもアクセスできます。スタンバイ・データベースはそのような順序に最初にアクセスするとき、プライマリ・データベースに順序番号の範囲を割り当てることを要求します。範囲はキャッシュ・サイズと、順序が作成されたときに指定したその他の順序プロパティに基づきます。次に、データ・ディクショナリ内の対応する順序エントリを調整することで、プライマリ・データベースがそれらの順序番号を要求しているスタンバイ・データベースに割り当てます。スタンバイが範囲内のすべての番号を使用したら、別の番号の範囲を要求します。
プライマリ・データベースは、スタンバイ・データベースからの範囲の要求ごとに、プライマリ・データベースとスタンバイ・データベースの両方に以前に割り当てられたものと重複しないような順序番号の範囲が確実に取得されるようにします。これでOracle Data Guard構成全体にわたって一意の順序番号のストリームが生成されます。
順序の範囲に対するスタンバイの要求にはプライマリへのラウンドトリップが含まれるため、Oracle Active Data Guardスタンバイで使用される順序を作成するときは、CACHEキーワードに十分大きい値を指定するようにしてください。そうしないと、パフォーマンスが影響を受ける可能性があります。
また、ターミナル・スタンバイには、プライマリを指すように定義されたLOG_ARCHIVE_DEST_nパラメータが含まれることを確認してください。
例: 複数スタンバイ構成での順序値の範囲の割当て
この例は、最初、または以前に割り当てられた順序値のすべてを使い果してしまった後で順序のNEXTVALを参照する場合に、データベースに割り当てることのできる順序値の範囲を示します。この例では、2つのスタンバイ・データベースがあります。
セッション順序はセッションの可視性があるグローバル一時表で使用されるように特別に設計された特別なタイプの順序です。既存の通常の順序(比較のために「グローバル」順序とも呼ばれます)とは異なり、セッション順序は、セッション間ではなくセッション内のみで、一意の順序番号の範囲を戻します。別の違いは、セッション順序は永続的ではないということです。セッションが終了すると、セッション中にアクセスされたセッション順序の状態も終了します。
セッション順序は、順序が定義されるときに指定する順序プロパティのほとんどをサポートします。しかし、CACHE/NOCACHEおよびORDER/NOORDERオプションはセッション順序には関係なく、無視されます。
セッション順序は読取り/書込みデータベースにより作成される必要がありますが、読取り/書込みまたは読取り専用データベース(通常のデータベースを読取り専用で一時的にオープンするか、またはスタンバイ・データベース)でアクセスできます。
セッション順序の作成および変更
セッション順序を作成するには、次のSQL文を発行します。
SQL> CREATE SEQUENCE … SESSION;
既存のセッション順序を通常の(グローバル)順序に変更するには、次のSQL文を発行します。
SQL> ALTER SEQUENCE … GLOBAL;
通常の順序をセッション順序に変更するには、次のSQL文を発行します。
SQL> ALTER SEQUENCE … SESSION;
例: セッション順序の使用
この例では、セッション順序値がデータベース・セッションごとにどのように一意になるかを示しています。
プライマリ・データベースに対して行われる構造の変更のほとんどは、REDOデータによってフィジカル・スタンバイ・データベースに自動的に伝播します。表10-1に、フィジカル・スタンバイ・データベースで手動操作が必要なプライマリ・データベースの構造および構成の変更を示します。
表10-1 フィジカル・スタンバイでの手動操作が必要なプライマリ・データベースの変更
| プライマリ・データベースの変更 | フィジカル・スタンバイ・データベースで必要なアクション |
|---|---|
|
|
|
|
プライマリ・データベースとフィジカル・スタンバイ・データベースの間で表領域を移動する。 |
|
フィジカル・スタンバイ・データベースでデータファイル名を変更します。 |
|
フィジカル・スタンバイ・データベースでREDOログおよびスタンバイREDOログの構成を評価し、必要に応じて調整する。 |
|
ログに記録されていない変更を含むデータファイルをフィジカル・スタンバイ・データベースにコピーします。 |
|
|
|
フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットをプライマリ・データベースのデータベース暗号化ウォレットの最新コピーで置き換える。 |
|
フィジカル・スタンバイ・データベースで対応する変更を初期化パラメータに加える必要があるかどうかを評価する。 |
STANDBY_FILE_MANAGEMENTデータベース初期化パラメータは、プライマリ・データベースへのデータファイルの追加を、フィジカル・スタンバイ・データベースに伝播するのかどうかを制御します。
フィジカル・スタンバイ・データベースのSTANDBY_FILE_MANAGEMENTデータベース・パラメータがAUTOに設定されている場合、プライマリ・データベースに作成された新しいデータファイルはフィジカル・スタンバイ・データベースに自動的に作成されます。
フィジカル・スタンバイ・データベースのSTANDBY_FILE_MANAGEMENTデータベース・パラメータがMANUALに設定されている場合、新しいデータファイルがプライマリ・データベースに追加されると、そのファイルは、プライマリ・データベースからフィジカル・スタンバイ・データベースに手動でコピーする必要があります。
注意:
Oracle Active Data Guardオプションが有効になっているフィジカル・スタンバイでは、手動でのコピーの方法は使用できません。かわりに、スタンバイで次のSQL文を実行して、空のデータファイルを作成する必要があります。
SQL> ALTER DATABASE CREATE DATAFILE [filename | filenumber] -
AS [NEW | new_filename];
名前を変更するもの(filenameまたはfilenumber)を指定する必要があります。
また、新しいファイル名またはNEWのいずれかを指定します。NEWキーワードにより、Oracle Managed Files (OMF)が有効な場合、自動的に名前が選択されます。
別のデータベースの既存のデータ・ファイルがプライマリ・データベースにコピーされた場合、同様にそのファイルをスタンバイ・データベースにコピーする必要があり、STANDBY_FILE_MANAGEMENTパラメータの設定に関係なくスタンバイ制御ファイルを再作成する必要があります。
プライマリ・データベースから表領域またはデータファイルが削除されると、対応するデータファイルがフィジカル・スタンバイ・データベースから削除される必要があります。次の例に、表領域を削除する方法を示します。
SQL> DROP TABLESPACE tbs_4; SQL> ALTER SYSTEM SWITCH LOGFILE;
削除されたデータファイルがデータベースに属していないことを確認するには、V$DATAFILEビューを問い合せます。
過去の変更を含むREDOデータがスタンバイ・データベースに適用された後、スタンバイ・システムで対応するデータファイルを削除します。次に例を示します。
% rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf
削除した表領域のREDO情報がスタンバイ・データベースで適用されたことを確認した後、プライマリ・データベースで表領域のデータファイルを削除できます。次に例を示します。
% rm /disk1/oracle/oradata/payroll/tbs_4.dbf
プライマリ・データベースでSQL DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES文を発行すると、プライマリ・データベースとスタンバイ・データベースの両方からデータファイルを削除できます。この文を使用するには、STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定する必要があります。たとえば、プライマリ・サイトで表領域を削除するには、次のように入力します。
SQL> DROP TABLESPACE tbs_4 INCLUDING CONTENTS AND DATAFILES; SQL> ALTER SYSTEM SWITCH LOGFILE;
Oracleトランスポータブル表領域機能を使用すると、Oracleデータベースのサブセットを移動して、別のOracleデータベースにプラグインできます。これにより、実際には表領域がデータベース間で移動します。
フィジカル・スタンバイの使用中に表領域セットをプライマリ・データベースに移動またはコピーする手順は、次のとおりです。
トランスポートする表領域セットのデータファイルとその表領域セットの構造情報を含むエクスポート・ファイルで構成される、トランスポータブル表領域セットを生成します。
次の手順で表領域セットをトランスポートします。
データファイルをコピーし、プライマリ・データベースにエクスポートします。
データファイルをスタンバイ・データベースにコピーします。
DB_FILE_NAME_CONVERTデータベース初期化パラメータが構成されていないかぎり、データファイルのパス名はプライマリ・データベースとスタンバイ・データベースで同じものが使用される必要があります。DB_FILE_NAME_CONVERTが構成されてなく、プライマリ・データベースとスタンバイ・データベースでデータファイルのパス名が同じではない場合、ALTER DATABASE RENAME FILE文を発行して、データファイルの名前を変更します。この操作は、REDO Applyが、表領域をプライマリ・データベースにプラグすることで生成されたREDOの適用に失敗した後で行います。データ・ファイル名を変更する前に、STANDBY_FILE_MANAGEMENT初期化パラメータをMANUALに設定し、データ・ファイル名を変更した後で、前の値にリセットする必要があります。
表領域をプラグインします。
データ・ポンプ・ユーティリティを起動して、表領域セットをプライマリ・データベースにプラグインします。スタンバイ・サイトでREDOデータが生成されて適用され、表領域がスタンバイ・データベースにプラグインされます。
トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。
プライマリ・データベースで1つ以上のデータファイルを改名した場合、その変更はスタンバイ・データベースに伝播されません。したがって、STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定しても変更処理は自動的に実行されないため、スタンバイ・データベースにある同じデータ・ファイルを改名する場合は、スタンバイ・データベースで同じ変更を手動で行う必要があります。
次の手順では、プライマリ・データベースでデータファイルを改名し、その変更をスタンバイ・データベースに手動で伝播する方法について説明します。
スタンバイ・システムで対応するデータ・ファイルを改名せず、スタンバイ・データベースの制御ファイルのリフレッシュを試みた場合、スタンバイ・データベースは改名したデータ・ファイルを使用しようとしますが、見つかりません。次のようなメッセージがアラート・ログに書き込まれます。
ORA-00283: recovery session canceled due to errors ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'
注意:
手順4-9のかわりに、ALTER DATABASE MOVE DATAFILEコマンドを使用してスタンバイでデータファイルを改名する方法があります。詳細は、「オンライン・データ・ファイルの場所の移行」を参照してください。
プライマリ・データベースでログ・ファイル・グループを追加または削除した後に、フィジカル・スタンバイ・データベースのREDOログおよびスタンバイREDOログの構成を再評価し、必要に応じて調整する必要があります。
次の手順を実行して、フィジカル・スタンバイ・データベースでログ・ファイル・グループまたはスタンバイ・ログ・ファイル・グループを追加または削除します。
Oracle RAC環境では、次の点に注意してください。
プライマリ・データベースにオンラインREDOログ・グループが追加されるとき、スタンバイ・データベースにはオンラインREDOログ・グループを手動で追加する必要があります。自動的には実行されません。
プライマリ・データベースに新しいREDOスレッドが追加されるとき、スタンバイには新しいREDOスレッドが自動的に追加されます。デフォルトでは、新しいスレッドは100 MBずつの2つのログ・グループで構成されます。これは変更もオーバーライドもできません。
既存のREDOスレッドに新しいログ・グループが追加されるとき、既存のスレッドに新しいログ・グループは自動的に追加されません。
NOLOGGINGまたはUNRECOVERABLE句を使用してDMLまたはDDL操作を実行するとスタンバイ・データベースは無効になるため、修正のために多大なDBA管理アクティビティが必要になる場合があります。SQL ALTER DATABASEまたはSQL ALTER TABLESPACE文でFORCE LOGGING句を指定すると、NOLOGGING設定を上書きできます。ただし、この文はすでに無効になっているデータベースを修正しません。
NOLOGGING句を使用した後のリカバリの詳細は、「NOLOGGING句を指定した後のリカバリ」を参照してください。
REMOTE_LOGIN_PASSWORDFILEデータベース初期化パラメータがSHAREDまたはEXCLUSIVEに設定されている場合、管理権限を付与または取り消すか、あるいは管理権限を持つユーザーのパスワードを変更した後に、フィジカル・スタンバイ・データベースのパスワード・ファイルをプライマリ・データベースの最新コピーで置き換える必要があります。
フィジカル・スタンバイ・データベースのパスワード・ファイルをリフレッシュできないと、REDO転送セッションの認証や、SYSDG、SYSDBAまたはSYSOPERとしてのフィジカル・スタンバイ・データベースへの接続が失敗する可能性があります。
スタンバイ・データベースのOracle ASMディスク・グループにパスワード・ファイルを格納した場合、更新したパスワード・ファイルをプライマリ・データベースからスタンバイ・データベースのOracle ASMの場所にコピーする必要があります。Oracle ASMまたはデータベース・インスタンス・パスワード・ファイルを指定した場所にコピーするために使用するASMCMD pwcopyコマンドの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。srvctlユーティリティを使用してデータベース構成を変更する方法の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
Oracle Data Guardでは、RESETLOGSオプションを使用してプライマリ・データベースがオープンされた後も、フィジカル・スタンバイ・データベースでリカバリを続行できます。プライマリ・データベースでALTER DATABASE OPEN RESETLOGS文を発行すると、データベースのインカネーションが変更され、REDOデータの新規ブランチが作成されます。
フィジカル・スタンバイ・データベースがREDOデータの新規ブランチを受信すると、REDO Applyではそれが自動的に使用されます。フィジカル・スタンバイ・データベースの場合、スタンバイ・データベースにより新規リセットログのSCNより後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されていなければ、手動による介入は必要ありません。次の表に、スタンバイ・データベースとプライマリ・データベースのブランチを再同期化する方法を示します。
| スタンバイ・データベースの状態 . . | 操作 . . | 実行する手順 . . |
|---|---|---|
新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されておらず、 |
REDO Applyは自動的にREDOの新規ブランチを使用します。 |
手動による介入は必要ありません。管理されたREDOプロセス(MRP)は、自動的にスタンバイ・データベースをREDOデータの新規ブランチと再同期化します。 注意: 新規REDOブランチがスタンバイに登録されたかどうかを調べるには、プライマリおよびスタンバイで次の問合せを実行して、結果が一致することを確認します。 SELECT resetlogs_id, resetlogs_change# FROM V$DATABASE_INCARNATION WHERE status='CURRENT' |
新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっている場合。 |
スタンバイ・データベースは、REDOデータの将来の新規ブランチでリカバリされます。 |
管理されたREDOプロセス(MRP)は、自動的にスタンバイ・データベースを新規ブランチと再同期化します。 |
新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっていない場合。 |
指定のプライマリ・データベース・ブランチで、プライマリ・データベースとスタンバイの内容にずれが生じます。 |
「フィジカル・スタンバイ・データベースの作成」の手順に従ってフィジカル・スタンバイ・データベースを再作成します。 |
REDOデータの新規ブランチから介入するアーカイブREDOログ・ファイルが欠落している場合。 |
MRPは欠落しているログ・ファイルが取得されるまで続行できません。 |
各ブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。 |
REDOデータの前のブランチの終わりからアーカイブREDOログ・ファイルが欠落している場合。 |
MRPは欠落しているログ・ファイルが取得されるまで続行できません。 |
前のブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。 |
データベース・インカネーション、OPEN RESETLOGSによるリカバリ、フラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この項では、プライマリ・データベースおよびスタンバイ・データベースを監視するために役立つ情報の検索方法について説明します。
表10-2に、一般的なプライマリ・データベースの管理アクションと、そのアクションに関する情報の参照先を示します。
表10-2 一般的なプライマリ・データベースの管理アクションに関する情報ソース
この項では、動的パフォーマンス・ビューを使用してプライマリ・データベース、フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースを監視する方法について説明します。
次の動的パフォーマンス・ビューについて説明します。
関連項目:
ビューの詳細な参照情報は、『Oracle Databaseリファレンス』を参照してください。
次の問合せは、プライマリ・データベース、フィジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースのデータ保護モード、データ保護レベル、データベース・ロールおよびスイッチオーバー・ステータスを表示します。
SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL, – > DATABASE_ROLE ROLE, SWITCHOVER_STATUS – > FROM V$DATABASE;
次の問合せは、ファスト・スタート・フェイルオーバーのステータスを表示します。
SQL> SELECT FS_FAILOVER_STATUS "FSFO STATUS", - > FS_FAILOVER_CURRENT_TARGET TARGET, - > FS_FAILOVER_THRESHOLD THRESHOLD, - > FS_FAILOVER_OBSERVER_PRESENT "OBSERVER PRESENT" – > FROM V$DATABASE;
次の問合せは、フィジカル・スタンバイ・データベースでのREDO ApplyおよびREDO転送ステータスを表示します。
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#,- > BLOCK#, BLOCKS FROM V$MANAGED_STANDBY; PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS ------- ------------ ---------- ---------- ---------- ---------- RFS ATTACHED 1 947 72 72 MRP0 APPLYING_LOG 1 946 10 72
このサンプル出力は、リモート・ファイル・サーバー(RFS)プロセスがREDOログ・ファイル順序番号947のアーカイブを完了し、REDO ApplyがアクティブにアーカイブREDOログ・ファイル順序番号946を適用していることを示しています。また、REDO ApplyがアーカイブREDOログ・ファイル順序番号946を適用していることも示しています。
次の問合せは、フィジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースでプライマリ・データベースから受信したアーカイブREDOログ・ファイルに関する情報を表示します。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, - > NEXT_CHANGE# FROM V$ARCHIVED_LOG; THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# ---------- ---------- ------------- ------------ 1 945 74651 74739 1 946 74739 74772 1 947 74772 74795
このサンプル出力は、プライマリ・データベースから受信した3つのアーカイブREDOログ・ファイルを示しています。
REDO Applyおよびメディア・リカバリのパフォーマンスを最適化する方法は、『Oracle Data Guard Redo Apply and Media Recovery Best Practices』ホワイト・ペーパーを参照してください。このホワイト・ペーパーは、次の場所からOracle Maximum Availability Architecture(MAA)のホームページにアクセスして入手することができます。
http://www.oracle.com/goto/maa
関連項目:
Standby Statspackのインストールと使用の詳細は、http://support.oracle.comのMy Oracle Supportノート454848.1を参照してください。Standby Statspackはフィジカル・スタンバイ・データベースからRedo Applyパフォーマンス・データを収集するために使用することもできます。
スナップショット・スタンバイ・データベースは、全面的に更新可能なスタンバイ・データベースです。スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信およびアーカイブしますが、適用はしません。プライマリ・データベースから受信したREDOデータは、スナップショット・スタンバイ・データベースへのローカル更新がすべて破棄された後、スナップショット・スタンバイ・データベースが変換されてフィジカル・スタンバイ・データベースに戻ると適用されます。
プライマリ・データベースのREDOデータは受信と同時には適用されないので、スナップショット・スタンバイ・データベースは通常、時間の経過とともにプライマリ・データベースとの差異が生じます。スナップショット・スタンバイ・データベースのローカルな更新によって差異が増えます。ただし、スナップショット・スタンバイはいつでもフィジカル・スタンバイ・データベースに戻すことができ、その後プライマリから受信したREDOデータを適用できるため、プライマリ・データベース内のデータは完全に保護されています。
スナップショット・スタンバイ・データベースには、フィジカル・スタンバイ・データベースと同様の、障害時リカバリおよびデータ保護のメリットがあります。スナップショット・スタンバイ・データベースは、プライマリ・データベースの一時的かつ更新可能なスナップショットを保持することにメリットがあれば、プライマリ・データベースの障害からリカバリする時間が増えてもかまわない場合に最もよく使用されます。
次の手順を実行して、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換します。
注意:
Oracle Data Guard Brokerで管理されるフィジカル・スタンバイ・データベースは、DGMGRLまたはOracle Enterprise Manager Cloud Controlのいずれかを使用してスナップショット・スタンバイ・データベースに変換できます。詳細は、『Oracle Data Guard Broker』を参照してください。
スナップショット・スタンバイ・データベースは読取り/書込みモードでオープンされ、全体を更新できます。
スナップショット・スタンバイ・データベースには、次の特性があります。
スナップショット・スタンバイ・データベースは、スイッチオーバーまたはフェイルオーバーのターゲットにはできません。スナップショット・スタンバイ・データベースは、ロールの推移を実行する前にフィジカル・スタンバイ・データベースに変換して戻す必要があります。
スナップショット・スタンバイ・データベースは、最大保護のOracle Data Guard構成では唯一のスタンバイ・データベースになりません。
注意:
フラッシュバック・データベースを使用して、スナップショット・スタンバイ・データベースを変換してフィジカル・スタンバイ・データベースに戻すことができます。フラッシュバック・データベース・テクノロジを使用して元に戻せない操作では、スナップショット・スタンバイを変換してフィジカル・スタンバイに戻せません。
フラッシュバック・データベースの詳細と制約は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
