| Oracle® Data Guard概要および管理 11gリリース2 (11.2) B56302-06 |
|
 前 |
 次 |
この章では、フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースの管理方法について説明します。次の項目で構成されています。
Data Guard Brokerによるフィジカルおよびスナップショット・スタンバイ・データベース管理の簡素化方法については、『Oracle Data Guard Broker』を参照してください。
この項では、フィジカル・スタンバイ・データベースを起動および停止する方法について説明します。
フィジカル・スタンバイ・データベースを起動するには、SQL*Plus STARTUPコマンドを使用します。SQL*Plus STARTUPコマンドは、引数を指定せずに起動すると、フィジカル・スタンバイ・データベースを読取り専用モードで起動、マウントおよびオープンします。
フィジカル・スタンバイ・データベースは、マウントまたはオープンされると、プライマリ・データベースからREDOデータを受信できます。
REDO Applyの詳細は7.3項を、フィジカル・スタンバイ・データベースを読取り専用モードでオープンする方法の詳細は9.2項を参照してください。
|
注意: プライマリ・データベースからのREDOデータをまだ受信していないフィジカル・スタンバイ・データベースでREDO Applyを開始すると、ORA-01112メッセージが戻されることがあります。このメッセージは、REDO Applyがメディア・リカバリ用の開始順序番号を判別できないことを示します。このエラーが発生した場合は、スタンバイ・データベースでアーカイブREDOログ・ファイルをプライマリ・データベースから手動で取得して登録するか、またはREDO転送が開始されるまで待機した後、REDO Applyを開始します。 |
フィジカル・スタンバイ・データベースは、読取り専用アクセス用にオープンし、問合せをプライマリ・データベースからオフロードするために使用できます。
|
注意: 読取り専用モードで開かれたフィジカル・スタンバイ・データベースは、読取り専用モードで開かれたその他のOracleデータベースと同じ制約を受けます。詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Active Data Guardオプションのライセンスを購入している場合は、フィジカル・スタンバイ・データベースを開いている間はRedo Applyをアクティブにすることができます。それにより、問合せによって、プライマリ・データベースからのものと同じ結果が得られます。この機能は、リアルタイム問合せ機能と呼ばれます。詳細は9.2.1項を参照してください。
Oracle Active Data Guardオプションのライセンスを未購入の場合、REDO Applyがアクティブである間は、フィジカル・スタンバイ・データベースをオープンできません。そのため、フィジカル・スタンバイ・データベース・インスタンスのオープン時またはREDO Applyの開始時には、次のルールに従う必要があります。
REDO Applyは、フィジカル・スタンバイ・データベース・インスタンスをオープンする前に停止する必要がある。
1つ以上のフィジカル・スタンバイ・インスタンスがオープンしている場合、REDO Applyを開始する前にこれらのインスタンスを停止する、またはMOUNT状態を再開する必要がある。
|
関連項目:
|
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 USING CURRENT LOGFILE - > DISCONNECT;
|
注意: REDO Applyがオープン・インスタンスでアクティブになっている場合は、REDO Applyを停止せずにその他のインスタンスをオープンすることができます。 |
REDO Applyは、そのデータベースのいずれかのインスタンスがオープンされている場合、マウント済フィジカル・スタンバイ・インスタンスでは開始できません。REDO Applyを開始する予定のインスタンスは、開始前にオープンしておく必要があります。
例: スタンバイのオープン・モードを調べるためのV$DATABASEの問合せ
この例は、フィジカル・スタンバイがリアルタイム問合せモードで開かれているときのV$DATABASE.OPEN_MODE列の値の変化を示します。
フィジカル・スタンバイ・インスタンスを起動してオープンし、次のSQL問合せを実行して、データベースが読取り専用モードでオープンしていることを確認します。
SQL> SELECT open_mode FROM V$DATABASE; OPEN_MODE -------------------- READ ONLY
次のSQL文を発行してREDO Applyを開始します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE - > DISCONNECT; Database altered.
スタンバイがリアルタイム問合せモード(スタンバイが読取り専用モードでオープンし、REDO Applyがアクティブになっている)であるため、V$DATABASE.OPEN_MODE列は次のように変化します。
SQL> SELECT open_mode FROM V$DATABASE; OPEN_MODE -------------------- READ ONLY WITH APPLY
リアルタイム問合せを使用して、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せをオフロードしている場合、適用ラグを監視して許容範囲内かどうかを確認することが必要になる場合があります。
現行の適用ラグとは、最後に適用された変更がスタンバイで表示可能になってから、同じ変更がプライマリで最初に表示可能になるまでに経過した時間です。このメトリックは秒単位で計算されます。
適用ラグを取得するには、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である必要があります。また、プライマリ・データベースは、最大保護モードまたは最大可用性モードのいずれかで実行されている必要があります。
リアルタイム適用を有効化しておく必要があります。
Active Data Guardは、キャッシュ・フュージョンの使用を通じてOracle RAC環境でパフォーマンスの高いリアルタイム問合せを実現しています。これにより、Data Guardの適用インスタンスおよび問合せは、キャッシュで動作することが可能となり、ディスクI/O制限によって低速化することがなくなります。この結果として、適用インスタンスの予期しない障害が発生すると、Oracle RACのすべてのオープン・インスタンス全体でバッファが一貫性のない状態となります。データの一貫性と整合性を確保するため、Data GuardはOracle RAC構成の他のすべてのオープン・インスタンスをクローズし、それらをマウント状態に移行します。手動でインスタンスを再オープンする必要があり、その時点でデータは自動的に一貫性を回復し、その後いずれかのインスタンスでREDO Applyが再開されます。Data Guard Broker構成では、インスタンスは自動的に再オープンされ、REDO Applyは自動的にいずれかのインスタンスで再開されることに注意してください。
|
関連項目:
|
プライマリ・データベースのアクセス時に破損データ・ブロックが検出されると、フィジカル・スタンバイ・データベースの対応するブロックの破損していないコピーで自動的に置き換えられます。これには次の条件があります。
フィジカル・スタンバイ・データベースがリアルタイム問合せモードで動作している必要があります(Active Data Guardライセンスが必要)。
フィジカル・スタンバイ・データベースがリアルタイム適用を実行している必要があります。
次の点も考慮してください。
自動修復は、Data Guardのどの保護モードでもサポートされます。ただし、スタンバイの破損していないバージョンのブロックを使用してプライマリの破損ブロックを修復する場合の効果は、プライマリによって生成されるREDOとスタンバイ適用がどの程度密接に同期化されているかによって変化します。
自動ブロック修復が実行されると、データベースのアラート・ログにメッセージが書き込まれます。
自動ブロック修復が可能でない場合は、ORA-1578エラーが返されます。
フィジカル・スタンバイ・データベースに破損データ・ブロックが発見された場合、次のデータベース初期化パラメータがスタンバイ・データベースで構成されていれば、サーバーはプライマリ・データベースからこのブロックのコピーを取得することにより、破損を自動修復しようと試みます。
LOG_ARCHIVE_CONFIGパラメータはDG_CONFIGリストを使用して構成され、LOG_ARCHIVE_DEST_nパラメータはプライマリ・データベース用に構成されている。
または
FAL_SERVERパラメータが構成され、その値にプライマリ・データベース用のOracle Netサービス名が含まれている。
破損データ・ブロックを手動で修復するには、RMAN RECOVER BLOCKコマンドを使用します。このコマンドは、データ・ブロックの破損していないコピーをいくつかの場所で探します。デフォルトの場所の1つは、リアルタイム問合せモードで実行しているいずれかのフィジカル・スタンバイ・データベースです。RMAN RECOVER BLOCKコマンドのEXCLUDE STANDBYオプションを使用すると、置換ブロックのコピー元からフィジカル・スタンバイ・データベースを除外することもできます。
|
関連項目: Recovery ManagerのRECOVER BLOCKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
Active Data Guard 11gベスト・プラクティス・ホワイト・ペーパーの付録Dでは、フィジカル・データベースで最適パフォーマンスを実現するための問合せのチューニング方法について説明しています。このホワイト・ペーパーは、次のURLからOracle Maximum Availability Architecture(MAA)のホームページにアクセスして入手することができます。
スタンバイを使用してプライマリ・データベースから問合せをオフロードし、ワークロードの性質上、スタンバイの初回作成時に自動的に作成される一時表領域よりも多くの領域が必要になる場合、追加領域を手動で追加する必要があります。
一時ファイルをフィジカル・スタンバイ・データベースに追加するには、次のタスクを実行します。
一時ファイルが格納される表領域を特定します。スタンバイ・データベースで次のコマンドを入力すると、特定できます。
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES 2> WHERE CONTENTS = 'TEMPORARY'; TABLESPACE_NAME -------------------------------- TEMP1 TEMP2
前述の問合せで特定された表領域ごとに、新しい一時ファイルをスタンバイ・データベースに追加します。次の例では、TEMP1という新しい一時ファイルを追加します。このファイルは、プライマリ・データベースの一時ファイルと一致するサイズおよび再利用特性を持っています。
SQL> ALTER TABLESPACE TEMP1 ADD TEMPFILE 2> '/arch1/boston/temp01.dbf' 3> SIZE 40M REUSE;
プライマリ・データベースに対して行われる構造の変更のほとんどは、REDOデータによってフィジカル・スタンバイ・データベースに自動的に伝播します。表9-1に、フィジカル・スタンバイ・データベースで手動操作が必要なプライマリ・データベースの構造および構成の変更を示します。
表9-1 フィジカル・スタンバイでの手動操作が必要なプライマリ・データベースの変更
| 参照先 | プライマリ・データベースの変更 | フィジカル・スタンバイ・データベースで必要なアクション |
|---|---|---|
|
|
データファイルの追加または表領域の作成 |
|
|
|
表領域またはデータファイルの削除 |
|
|
|
トランスポータブル表領域の使用 |
プライマリ・データベースとフィジカル・スタンバイ・データベースの間で表領域を移動する。 |
|
|
データファイルの改名 |
フィジカル・スタンバイ・データベースでデータファイル名を変更する。 |
|
|
REDOログ・ファイル・グループの追加または削除 |
フィジカル・スタンバイ・データベースでREDOログおよびスタンバイREDOログの構成を評価し、必要に応じて調整する。 |
|
|
|
ログに記録されていない変更を含むデータファイルをフィジカル・スタンバイ・データベースにコピーする。 |
|
|
管理権限の付与または取消し、あるいは管理権限を持つユーザーのパスワードの変更 |
|
|
|
TDEマスター暗号化キーのリセット |
フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットをプライマリ・データベースのデータベース暗号化ウォレットの最新コピーで置き換える。 |
|
|
初期化パラメータの変更 |
フィジカル・スタンバイ・データベースで対応する変更を初期化パラメータに加える必要があるかどうかを評価する。 |
STANDBY_FILE_MANAGEMENTデータベース初期化パラメータは、プライマリ・データベースへのデータファイルの追加を、フィジカル・スタンバイ・データベースに伝播するのかどうかを制御します。
フィジカル・スタンバイ・データベースのSTANDBY_FILE_MANAGEMENTパラメータがAUTOに設定されている場合、プライマリ・データベースに作成された新しいデータファイルはフィジカル・スタンバイ・データベースに自動的に作成されます。
フィジカル・スタンバイ・データベースのSTANDBY_FILE_MANAGEMENTデータベース・パラメータがMANUALに設定されている場合、新しいデータファイルがプライマリ・データベースに追加されると、そのファイルは、プライマリ・データベースからフィジカル・スタンバイ・データベースに手動でコピーする必要があります。
別のデータベースの既存のデータファイルがプライマリ・データベースにコピーされた場合、同様にそのファイルをスタンバイ・データベースにコピーする必要があり、STANDBY_FILE_MANAGEMENTパラメータの設定に関係なくスタンバイ制御ファイルを再作成する必要があります。
|
注意: 次の手順は、Oracle Managed Filesを使用するデータベースには使用しないでください。また、RAWデバイスのパス名がプライマリ・サーバー上とスタンバイ・サーバー上で異なる場合は、DB_FILE_NAME_CONVERTデータベース初期化パラメータを使用してパス名を変換してください。 |
STANDBY_FILE_MANAGEMENTパラメータをAUTOに設定し、データファイルをプライマリ・データベースに追加、またはプライマリ・データベースから削除するたびに、手動操作なしで該当する変更内容がスタンバイ・データベースにも反映されるようにします。スタンバイ・データベースがファイル・システムを使用している限り、これは適切な処理です。スタンバイ・データベースがデータファイルにRAWデバイスを使用している場合は、STANDBY_FILE_MANAGEMENTパラメータは作業を続行しますが、手動操作が必要になります。このような手動操作では、Redo Applyによって新しいデータファイルを作成するREDOデータを適用する前に、RAWデバイスの存在を確認する作業が必要です。プライマリ・データベース上で、データファイルがRAWデバイス内に存在する、新しい表領域を作成します。同時に、スタンバイ・データベース上でも同じRAWデバイスを作成します。次に例を示します。
SQL> CREATE TABLESPACE MTS2 DATAFILE '/dev/raw/raw100' size 1m; Tablespace created. SQL> ALTER SYSTEM SWITCH LOGFILE; System altered.
スタンバイ・データベースでは、RAWデバイスが存在するため自動的にデータファイルが追加されます。スタンバイ・アラート・ログには次のように示されます。
Fri Apr 8 09:49:31 2005 Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1_mf_1_7_15ffgt0z_.arc Recovery created file /dev/raw/raw100 Successfully added datafile 6 to media recovery Datafile #6: '/dev/raw/raw100' Media Recovery Waiting for thread 1 sequence 8 (in transit)
ただし、プライマリ・システム上でRAWデバイスが作成されてもスタンバイ上で作成されなければ、REDO Applyはファイル作成エラーにより停止します。たとえば、プライマリ・データベースで次の文を発行します。
SQL> CREATE TABLESPACE MTS3 DATAFILE '/dev/raw/raw101' size 1m; Tablespace created. SQL> ALTER SYSTEM SWITCH LOGFILE; System altered.
スタンバイ・システムには、RAWデバイス/dev/raw/raw101が作成されていません。アーカイブをリカバリすると、スタンバイ・アラート・ログに次のメッセージが示されます。
Fri Apr 8 10:00:22 2005 Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1_mf_1_8_15ffjrov_.arc File #7 added to control file as 'UNNAMED00007'. Originally created as: '/dev/raw/raw101' Recovery was unable to create the file as: '/dev/raw/raw101' MRP0: Background Media Recovery terminated with error 1274 Fri Apr 8 10:00:22 2005 Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc: ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created ORA-01119: error in creating database file '/dev/raw/raw101' ORA-27041: unable to open file Linux Error: 13: Permission denied Additional information: 1 Some recovered datafiles maybe left media fuzzy Media recovery may continue but open resetlogs may fail Fri Apr 8 10:00:22 2005 Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc: ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created ORA-01119: error in creating database file '/dev/raw/raw101' ORA-27041: unable to open file Linux Error: 13: Permission denied Additional information: 1 Fri Apr 8 10:00:22 2005 MTS; MRP0: Background Media Recovery process shutdown ARCH: Connecting to console port...
9.3.1.1項で説明した問題を修正する手順は、次のとおりです。
スタンバイ・データベースにRAWデバイスを作成し、Oracleユーザーに権限を割り当てます。
V$DATAFILEビューを問い合せます。次に例を示します。
SQL> SELECT NAME FROM V$DATAFILE; NAME ------------------------------------------------------------------------------- /u01/MILLER/MTS/system01.dbf /u01/MILLER/MTS/undotbs01.dbf /u01/MILLER/MTS/sysaux01.dbf /u01/MILLER/MTS/users01.dbf /u01/MILLER/MTS/mts.dbf /dev/raw/raw100 /u01/app/oracle/product/10.1.0/dbs/UNNAMED00007 SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL; SQL> ALTER DATABASE CREATE DATAFILE - > '/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007' - > AS - > '/dev/raw/raw101';
スタンバイ・アラート・ログに、次のような情報が表示されます。
Fri Apr 8 10:09:30 2005 alter database create datafile '/dev/raw/raw101' as '/dev/raw/raw101' Fri Apr 8 10:09:30 2005 Completed: alter database create datafile '/dev/raw/raw101' a
スタンバイ・データベースで、STANDBY_FILE_MANAGEMENTをAUTOに設定してREDO Applyを再開します。
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
この時点で、REDO Applyは新規のRAWデバイスのデータファイルを使用し、リカバリが続行されます。
プライマリ・データベースから表領域またはデータファイルを削除した場合、対応するデータファイルをフィジカル・スタンバイ・データベースから削除する必要があります。次の例に、表領域を削除する方法を示します。
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 INCLUDING CONTENTS AND DATAFILES tbs_4; 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に設定しても変更処理は自動的に実行されないため、スタンバイ・データベースにある同じデータファイルを改名する場合は、スタンバイ・データベースで同じ変更を手動で行う必要があります。
次の手順では、プライマリ・データベースでデータファイルを改名し、その変更をスタンバイ・データベースに手動で伝播する方法について説明します。
プライマリ・データベースでデータファイルを改名するには、表領域をオフラインにします。
SQL> ALTER TABLESPACE tbs_4 OFFLINE;
SQLプロンプトを終了し、UNIXのmvコマンドなどのオペレーティング・システム・コマンドを発行して、プライマリ・システム上のデータファイルを改名します。
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
プライマリ・データベース内のデータファイルを改名し、表領域をオンラインに戻します。
SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE - > '/disk1/oracle/oradata/payroll/tbs_4.dbf' - > TO '/disk1/oracle/oradata/payroll/tbs_x.dbf'; SQL> ALTER TABLESPACE tbs_4 ONLINE;
スタンバイ・データベースに接続し、REDO Applyを停止します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
スタンバイ・データベースを停止します。
SQL> SHUTDOWN;
UNIXのmvコマンドなどのオペレーティング・システム・コマンドを使用して、スタンバイ・サイトでデータファイルを改名します。
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
スタンバイ・データベースを起動し、マウントします。
SQL> STARTUP MOUNT;
スタンバイ制御ファイルのデータファイルを改名します。データファイル名を変更するには、STANDBY_FILE_MANAGEMENTデータベース初期化パラメータをMANUALに設定する必要があります。このパラメータは、データファイル名の変更後、前の値にリセットできます。
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf' - > TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
スタンバイ・データベースで、REDO Applyを再開します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE - > DISCONNECT FROM SESSION;
スタンバイ・システムで対応するデータファイルを改名しないでスタンバイ・データベース制御ファイルをリフレッシュしようとすると、スタンバイ・データベースは改名されたデータファイルの使用を試みますが、改名されたデータファイルは見つかりません。したがって、アラート・ログに次のようなエラー・メッセージが表示されます。
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'
プライマリ・データベースでログ・ファイル・グループを追加または削除した後に、フィジカル・スタンバイ・データベースのREDOログおよびスタンバイREDOログの構成を再評価し、必要に応じて調整する必要があります。
次の手順を実行して、フィジカル・スタンバイ・データベースでログ・ファイル・グループまたはスタンバイ・ログ・ファイル・グループを追加または削除します。
REDO Applyを停止します。
STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定している場合は、値をMANUALに変更します。
REDOログ・ファイル・グループを追加または削除します。
|
注意: オンライン・ログ・ファイル・グループは、フィジカル・スタンバイ・データベースから削除するには、常に手動で消去する必要があります。次に例を示します。ALTER DATABASE CLEAR LOGFILE GROUP 3; ステータスが |
STANDBY_FILE_MANAGEMENT初期化パラメータおよびREDO Applyオプションを元の状態にリストアします。
REDO Applyを再開します。
NOLOGGINGまたはUNRECOVERABLE句を使用してDMLまたはDDL操作を実行するとスタンバイ・データベースは無効になるため、修正のために多大なDBA管理アクティビティが必要になる場合があります。SQL ALTER DATABASEまたはSQL ALTER TABLESPACE文でFORCE LOGGING句を指定すると、NOLOGGING 設定を上書きできます。ただし、この文はすでに無効になっているデータベースを修正しません。
NOLOGGING句を使用した後のリカバリの詳細は、13.4項を参照してください。
REMOTE_LOGIN_PASSWORDFILEデータベース初期化パラメータがSHAREDまたはEXCLUSIVEに設定されている場合、管理権限を付与または取り消すか、あるいは管理権限を持つユーザーのパスワードを変更した後に、フィジカル・スタンバイ・データベースのパスワード・ファイルをプライマリ・データベースの最新コピーで置き換える必要があります。
フィジカル・スタンバイ・データベースのパスワード・ファイルをリフレッシュできないと、REDO転送セッションの認証やSYSDBAまたはSYSOPERとしてのフィジカル・スタンバイ・データベースへの接続が失敗する可能性があります。
フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットは、プライマリ・データベースでTDEマスター暗号化キーがリセットされるたびに、プライマリ・データベースのデータベース暗号化ウォレットの最新コピーで置き換える必要があります。
フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットをリフレッシュできないと、プライマリ・データベースでマスター暗号化キーがリセットされた後に変更された、フィジカル・スタンバイ・データベース上の暗号化された列にアクセスできません。
Data Guardでは、RESETLOGSオプションを使用してプライマリ・データベースがオープンされた後も、フィジカル・スタンバイ・データベースでリカバリを続行できます。プライマリ・データベースでALTER DATABASE OPEN RESETLOGS文を発行すると、データベースのインカネーションが変更され、REDOデータの新規ブランチが作成されます。
フィジカル・スタンバイ・データベースがREDOデータの新規ブランチを受信すると、REDO Applyではそれが自動的に使用されます。フィジカル・スタンバイ・データベースの場合、スタンバイ・データベースにより新規リセットログのSCNより後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されていなければ、手動による介入は必要ありません。次の表に、スタンバイ・データベースとプライマリ・データベースのブランチを再同期化する方法を示します。
| スタンバイ・データベースの状態 . . | 操作 . . | 実行する手順 . . |
|---|---|---|
新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用されておらず、OPEN RESETLOGSの新規REDOブランチがスタンバイに登録されている場合 |
REDO Applyは自動的にREDOの新規ブランチを使用します。 | 手動による介入は必要ありません。MRPは、自動的にスタンバイ・データベースをREDOデータの新規ブランチと再同期化します。
注意: 新規REDOブランチがスタンバイに登録されたかどうかを調べるには、プライマリおよびスタンバイで次の問合せを実行して、結果が一致することを確認します。 SELECT resetlogs_id, resetlogs_change# FROM V$DATABASE_INCARNATION WHERE status='CURRENT' |
| 新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっている場合。 | スタンバイ・データベースは、REDOデータの将来の新規ブランチでリカバリされます。 |
MRPは、自動的にスタンバイ・データベースを新規ブランチと再同期化します。 |
| 新規リセットログのSCNの後(REDOデータの新規ブランチの開始より後)のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっていない場合。 | 指定のプライマリ・データベース・ブランチで、プライマリ・データベースとスタンバイの内容にずれが生じます。 | 第3章の手順に従ってフィジカル・スタンバイ・データベースを再作成します。 |
| REDOデータの新規ブランチから介入するアーカイブREDOログ・ファイルが欠落している場合。 | MRPは欠落しているログ・ファイルが取得されるまで続行できません。 | 各ブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。 |
| REDOデータの前のブランチの終わりからアーカイブREDOログ・ファイルが欠落している場合。 | MRPは欠落しているログ・ファイルが取得されるまで続行できません。 | 前のブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。 |
データベース・インカネーション、OPEN RESETLOGSによるリカバリ、フラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この項では、プライマリ・データベースおよびスタンバイ・データベースを監視するために役立つ情報の検索方法について説明します。
表9-2に、一般的なプライマリ・データベースの管理アクションと、そのアクションに関する情報の参照先を示します。
表9-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ログ・ファイルに関する情報を表示します。
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ログ・ファイルを示しています。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, - > NEXT_CHANGE# FROM V$LOG_HISTORY;
次の問合せは、アラート・ログまたはサーバー・プロセス・トレース・ファイルにメッセージが書き込まれる原因となったData Guardイベントによって生成されたメッセージを表示します。
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
次の問合せは、各REDO転送先のステータスと、スタンバイ・データベースであるREDO転送先については、そのスタンバイ・データベースで適用された最後のプライマリ・データベースREDOのSCNを表示します。
SQL> SELECT DEST_ID, APPLIED_SCN FROM V$ARCHIVE_DEST WHERE TARGET='STANDBY'; DEST_ID STATUS APPLIED_SCN ---------- --------- ----------- 2 VALID 439054 3 VALID 439054
REDO Applyおよびメディア・リカバリのパフォーマンスを最適化する方法は、『Oracle Data Guard Redo Apply and Media Recovery Best Practices』ホワイト・ペーパーを参照してください。このホワイト・ペーパーは、次のURLから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データを適用できるので、プライマリ・データベース内のデータは完全に保護されています。
スナップショット・スタンバイ・データベースには、フィジカル・スタンバイ・データベースと同様の、障害時リカバリおよびデータ保護のメリットがあります。スナップショット・スタンバイ・データベースは、プライマリ・データベースの一時的かつ更新可能なスナップショットを保持することにメリットがあれば、プライマリ・データベースの障害からリカバリする時間が増えてもかまわない場合に最もよく使用されます。
次の手順を実行して、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換します。
REDO Applyがアクティブな場合は、停止します。
データベースがマウントされ、オープンしていないことを確認します。
高速リカバリ領域が構成されていることを確認します。フラッシュバック・データベースを有効化する必要はありません。
次のSQL文を発行して変換を実行します。
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
|
注意: Data Guard Brokerで管理されるフィジカル・スタンバイ・データベースは、DGMGRLまたはOracle Enterprise Managerのいずれかを使用してスナップショット・スタンバイ・データベースに変換できます。詳細は、『Oracle Data Guard Broker』を参照してください。 |
スナップショット・スタンバイ・データベースは読取り/書込みモードでオープンされ、全体を更新できます。
スナップショット・スタンバイ・データベースには、次の特性があります。
スナップショット・スタンバイ・データベースは、スイッチオーバーまたはフェイルオーバーのターゲットにはできません。スナップショット・スタンバイ・データベースは、ロールの推移を実行する前にフィジカル・スタンバイ・データベースに変換して戻す必要があります。
スナップショット・スタンバイ・データベースは、最大保護のData Guard構成では唯一のスタンバイ・データベースになりません。
|
注意: フラッシュバック・データベースを使用して、スナップショット・スタンバイ・データベースを変換してフィジカル・スタンバイ・データベースに戻すことができます。フラッシュバック・データベース・テクノロジを使用して元に戻すことができない操作は、スナップショット・スタンバイを変換してフィジカル・スタンバイに戻すことを妨げます。フラッシュバック・データベースの詳細と制約は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
次の手順を実行して、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに変換します。
Oracle Real Application Clusters(Oracle RAC)データベースで、1つのインスタンス以外はすべて停止します。
データベースがマウントされ、オープンしていないことを確認します。
次のSQL文を発行して変換を実行します。
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
データベースは変換後にディスマウントされ、再起動する必要があります。
データベースがスナップショット・スタンバイ・データベースの間に受信したREDOデータは、REDO Applyが開始されると自動的に適用されます。
|
注意: スナップショット・スタンバイ・データベースは、少なくとも1回は読取り/書込みモードでオープンしてから、フィジカル・スタンバイ・データベースに変換する必要があります。 |
