11gリリース1（11.1）
E05755-03
 目次 |
 索引 |
| Oracle Data Guard 概要および管理 11gリリース1（11.1） E05755-03 |
|
この付録は、スタンバイ・データベースのトラブルシューティングのヘルプとしてご利用いただけます。この項は、次の項目で構成されています。
スタンバイ・データベースの使用時に発生する問題の原因には、次のようなものがあります。
STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定すると、スタンバイ・サイトのデータファイルを改名できません。STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定した場合、次のSQL文は使用できなくなります。
ALTER DATABASE RENAME
ALTER DATABASE ADD/DROP LOGFILE
ALTER DATABASE ADD/DROP STANDBY LOGFILE MEMBER
ALTER DATABASE CREATE DATAFILE AS
スタンバイ・データベースでこれらの文のいずれかを使用しようとすると、エラーが表示されます。次に例を示します。
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/t_db2.log' to 'dummy';
alter database rename file '/disk1/oracle/oradata/payroll/t_db2.log' to 'dummy'
*
ERROR at line 1:
ORA-01511: error in renaming log/datafiles
ORA-01270: RENAME operation is not allowed if STANDBY_FILE_MANAGEMENT is auto
フィジカル・スタンバイ・データベースにデータファイルを追加する方法は、9.3.1項を参照してください。
スタンバイ・サイトがREDOデータを受信していない場合は、V$ARCHIVE_DESTビューを問い合せて、エラー・メッセージをチェックします。たとえば、次のような問合せを入力します。
SQL> SELECT DEST_ID "ID",
2> STATUS "DB_status",
3> DESTINATION "Archive_dest",
4> ERROR "Error"
5> FROM V$ARCHIVE_DEST WHERE DEST_ID <=5;
ID DB_status Archive_dest Error
-- --------- ------------------------------ ------------------------------------
1 VALID /vobs/oracle/work/arc_dest/arc
2 ERROR standby1 ORA-16012: Archivelog standby database identifier mismatch
3 INACTIVE
4 INACTIVE
5 INACTIVE
5 rows selected.
問合せの出力によって解決しない場合は、次の問題リストを確認します。次のいずれかの条件に該当する場合、REDO転送サービスはスタンバイ・データベースにREDOデータを転送できません。
tnsnames.oraファイル内でスタンバイ・インスタンスのサービス名が正しく構成されていない場合。
LOG_ARCHIVE_DEST_nパラメータで指定されたOracle Netサービス名が不適切な場合。
LOG_ARCHIVE_DEST_STATE_nパラメータが値ENABLEに設定されていない場合。
listener.oraファイルがスタンバイ・データベース用に正しく構成されていない場合。
スタンバイ制御ファイルが、ALTER DATABASE CREATE [LOGICAL] STANDBY CONTROLFILE ...文またはRecovery Managerコマンドを使用して作成されていない場合、スタンバイ・データベースをマウントすることはできません。次のタイプの制御ファイル・バックアップは使用できません。
MANDATORY宛先にREOPENを指定した場合、REDO転送サービスは、REDOデータを正常に転送できなかったとき、プライマリ・データベースを停止します。
MAX_FAILURE属性を使用する場合は、REOPEN属性は必須です。例A-1に、再試行時間を5秒に設定し、再試行回数を3回に制限する方法を示します。
LOG_ARCHIVE_DEST_1='LOCATION=/arc_dest REOPEN=5 MAX_FAILURE=3'
LOG_ARCHIVE_DEST_nパラメータのALTERNATE属性を使用して代替アーカイブ先を指定します。スタンバイ・データベースへのREDOデータの転送に失敗した場合は、代替アーカイブ先を使用できます。転送に失敗したときに、REOPEN属性が指定されていなかった場合、またはMAX_FAILURE属性のしきい値を超えた場合、REDO転送サービスは、次のアーカイブ操作時に代替先へのREDOデータの転送を試みます。
元のアーカイブ先で障害が発生したときに、元のアーカイブ先が自動的に代替アーカイブ先に変更されることを防ぐには、NOALTERNATE属性を使用します。
例A-2は、エラー発生時に、単一、必須のローカル宛先が異なる宛先へ自動的にフェイルオーバーするように初期化パラメータを設定する方法を示します。
LOG_ARCHIVE_DEST_1='LOCATION=/disk1 MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2='LOCATION=/disk2 MANDATORY' LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
LOG_ARCHIVE_DEST_1の宛先で障害が発生した場合、アーカイブ・プロセスは、プライマリ・データベースでの次のログ・ファイル・スイッチでLOG_ARCHIVE_DEST_2の宛先に自動的に切り替えます。
ロジカル・スタンバイ・データベース障害を処理するための重要なツールは、DBMS_LOGSTDBY.SKIP_ERRORプロシージャです。表の重要度に基づいて、次のいずれかを実行できます。
これらの処理のいずれかを実行すると、SQL Applyの停止を回避できます。存在している問題は、後でDBA_LOGSTDBY_EVENTSビューを問い合せて検索し、訂正できます。DBMS_LOGSTDBYパッケージをPL/SQLコールアウト・プロシージャとともに使用する方法の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
通常、第8章で説明した手順に従うと、スイッチオーバーは正常に行われます。ただし、スイッチオーバーが失敗した場合でも、次の項を読むと、問題の解決に役立ちます。
スイッチオーバーが正常に完了しない場合は、V$ARCHIVED_LOGビューのSEQUENCE#列を問い合せて、元のプライマリ・データベースから転送された最後のREDOデータが、スタンバイ・データベースに適用されているかどうかを確認します。最後のREDOデータがスタンバイ・データベースに転送されていない場合は、そのREDOデータが含まれるアーカイブREDOログ・ファイルを元のプライマリ・データベースから古いスタンバイ・データベースに手動でコピーし、SQL ALTER DATABASE REGISTER LOGFILE file_specification文を使用して登録します。次に、適用サービスを開始すると、アーカイブREDOログ・ファイルが自動的に適用されます。V$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。SWITCHOVER_STATUS列の値TO PRIMARYは、プライマリ・ロールへのスイッチオーバーが可能になったことを示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO PRIMARY 1 row selected
V$DATABASEビューのSWITCHOVER_STATUS列に対するその他の有効な値の詳細は、第17章を参照してください。
スイッチオーバーを続行するには、8.2.1項（フィジカル・スタンバイ・データベースの場合）または8.3.1項（ロジカル・スタンバイ・データベースの場合）の説明に従って、ターゲットのスタンバイ・データベースをプライマリ・ロールに切り替える操作を再度実行します。
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY文にWITH SESSION SHUTDOWN句を組み込んでいない場合、アクティブなSQLセッションがあると、スイッチオーバーを継続できません。アクティブなSQLセッションには、他のOracle Databaseプロセスが含まれていることがあります。
セッションがアクティブのときは、スイッチオーバーの試行が次のエラー・メッセージを伴って失敗します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY; ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY * ORA-01093: ALTER DATABASE CLOSE only permitted with no sessions connected
処置: V$SESSIONビューを問い合せ、エラーの原因となっているプロセスを判断します。次に例を示します。
SQL> SELECT SID, PROCESS, PROGRAM FROM V$SESSION 2> WHERE TYPE = 'USER' 3> AND SID <> (SELECT DISTINCT SID FROM V$MYSTAT); SID PROCESS PROGRAM --------- -------- ------------------------------------------------ 7 3537 oracle@nhclone2 (CJQ0) 10 14 16 19 21 6 rows selected.
この例では、JOB_QUEUE_PROCESSESパラメータがCJQ0プロセス・エントリに対応しています。ジョブ・キュー・プロセスはユーザー・プロセスなので、スイッチオーバーの発生を妨げるのはSQLセッションであると考えられます。プロセスまたはプログラム情報のないエントリは、ジョブ・キュー・コントローラによって開始されるスレッドです。
次のSQL文を使用して、JOB_QUEUE_PROCESSESパラメータが設定されていることを確認してください。
SQL> SHOW PARAMETER JOB_QUEUE_PROCESSES; NAME TYPE VALUE ------------------------------ ------- -------------------- job_queue_processes integer 5
さらに、パラメータを0（ゼロ）に設定してください。次に例を示します。
SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0; Statement processed.
JOB_QUEUE_PROCESSESは動的パラメータであるため、値を変更した際にインスタンスを再起動しなくても、変更を即時に有効にできます。これで、スイッチオーバー手順を再試行できます。
初期化パラメータ・ファイル内のパラメータは変更しないでください。インスタンスを停止し、スイッチオーバーが完了した後で再起動すると、パラメータが元の値にリセットされます。これは、プライマリ・データベースとフィジカル・スタンバイ・データベースの両方に適用されます。
表A-1に、スイッチオーバーを妨げる共通のプロセスと、実行する必要のある対処措置をまとめます。
スイッチオーバーに失敗し、エラー「ORA-01093: ALTER DATABASE CLOSEは接続中のセッションがない場合にのみ実行できます」が戻された場合、通常これは、ALTER DATABASE COMMIT TO SWITCHOVER文が暗黙的にデータベースのクローズを実行したときに、その他のユーザー・セッションがデータベースに接続されていてクローズできなかったことが原因と考えられます。
このエラーが発生した場合は、データベースに接続されているユーザー・セッションをすべて切断します。まだアクティブなセッションを確認するには、次のようにV$SESSIONビューを問い合せます。
SQL> SELECT SID, PROCESS, PROGRAM FROM V$SESSION;
スタンバイ・データベースとプライマリ・データベースが同じサイトに存在するとします。ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY文およびALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY文の両方が正常に実行された後、フィジカル・スタンバイ・データベースとプライマリ・データベースを停止し、再起動します。
ただし、2つ目のデータベースの起動はエラー・メッセージ「ORA-01102 データベースを排他モードでマウントすることができません。」を伴って失敗します。
スタンバイ・データベース（つまり元のプライマリ・データベース）で使用される初期化パラメータ・ファイルにDB_UNIQUE_NAMEパラメータを設定していないと、スイッチオーバー中にこの現象が発生することがあります。スタンバイ・データベースのDB_UNIQUE_NAMEパラメータが設定されていない場合、スタンバイ・データベースとプライマリ・データベースの両方が同じマウント・ロックを使用するため、2つ目のデータベースの起動時にORA-01102エラーが発生します。
処置: DB_UNIQUE_NAME=unique_database_nameをスタンバイ・データベースが使用する初期化パラメータ・ファイルに追加して、スタンバイ・データベースとプライマリ・データベースを停止し、再起動します。
スイッチオーバー後にアーカイブREDOログ・ファイルが新しいスタンバイ・データベースに適用されません。
これは、スイッチオーバー後、環境パラメータまたは初期化パラメータが適切に設定されていなかったことが原因と考えられます。
処置:
tnsnames.oraファイルおよび新しいスタンバイ・サイトのlistener.oraファイルを調べます。スタンバイ・サイトにはリスナーのエントリ、プライマリ・サイトにはそれに対応するサービス名が必要です。
LOG_ARCHIVE_DEST_n初期化パラメータが設定されているかどうかを調べます。たとえば、プライマリ・サイトでV$ARCHIVE_DEST固定ビューを次のように問い合せます。
SQL> SELECT DEST_ID, STATUS, DESTINATION FROM V$ARCHIVE_DEST;
スタンバイ・サイトに対応するエントリが見つからない場合、LOG_ARCHIVE_DEST_n初期化パラメータおよびLOG_ARCHIVE_DEST_STATE_n初期化パラメータを設定する必要があります。
STANDBY_ARCHIVE_DEST初期化パラメータおよびLOG_ARCHIVE_FORMAT初期化パラメータを正しく設定し、アーカイブREDOログ・ファイルが適切な場所に適用されるようにします。（STANDBY_ARCHIVE_DESTパラメータは廃止されており、下位互換性のためにのみサポートされています。）
DB_FILE_NAME_CONVERT初期化パラメータおよびLOG_FILE_NAME_CONVERT初期化パラメータを設定します。プライマリ・サイトで作成された新しいデータファイルがスタンバイ・サイトに自動的に追加されるようにするには、STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定します。
フィジカル・スタンバイ・データベースでエラーが発生し、スイッチオーバーを続行できない場合は、次の手順に従って、新しいフィジカル・スタンバイ・データベースをプライマリ・ロールに戻すことができます。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
この文が正常に実行された場合は、必要に応じてデータベースを停止し、再起動します。再起動すると、データベースはプライマリ・データベース・ロールで実行されるため、それ以降の手順を実行する必要はありません。
この文が正常に実行されなかった場合は、手順3に進んでください。
この手順が正常終了し、アーカイブ・ギャップ管理が使用可能になると、FALプロセスが起動し、欠落したアーカイブREDOログ・ファイルをフィジカル・スタンバイ・データベースに再アーカイブします。プライマリ・データベース上でログ・スイッチを強制実行し、プライマリ・データベースとフィジカル・スタンバイ・データベースの両方のアラート・ログを調べて、アーカイブREDOログ・ファイルの順序番号が正しいことを確認します。
この時点で、Data Guard構成は初期状態にロールバックされています。最初に失敗したスイッチオーバーの問題をすべて解決した後、スイッチオーバー操作を再度実行できます。
ロジカル・スタンバイ・データベースに関連するスイッチオーバー操作には、通常、準備とコミットの2つのフェーズがあります。これに対する例外は、ロジカル・スタンバイ・データベースを使用したOracleソフトウェアのローリング・アップグレードの場合、またはData Guard Brokerを使用している場合です。ロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行中、またはData Guard Brokerで開始されたスイッチオーバー操作の際に障害が発生した場合は、A.5.2項に直接進んでください。
スイッチオーバー操作の準備フェーズ中に障害が発生した場合、スイッチオーバーを取り消して、スイッチオーバー操作を再度初めから行います。
ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY文の実行中に障害が発生した場合、プライマリ・データベースで次のSQL文を発行してスイッチオーバーの準備フェーズを取り消します。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY CANCEL;
これで、スイッチオーバー操作を再度初めから行うことができます。
ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY文の実行中に障害が発生した場合、プライマリ・データベースおよびターゲット・スタンバイ・データベースで準備操作を取り消す必要があります。次の手順に従ってください。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY CANCEL;
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY CANCEL;
これで、スイッチオーバー操作を再度初めから行うことができます。
スイッチオーバーのコミットでは単一のSQL文のみを使用しますが、内部的には多数の操作が実行されます。実行する必要がある修正処理は、エラー発生時のスイッチオーバー操作のコミットの状態によって異なります。
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY文の実行中に障害が発生した場合、次の手順を実行します。
V$DATABASE固定ビューのDATABASE_ROLE列をチェックします。
SQL> SELECT DATABASE_ROLE FROM V$DATABASE;
SQL> SELECT COUNT(*) FROM SYSTEM.LOGSTDBY$PARAMETERS 2> WHERE NAME = 'END_PRIMARY';
スイッチオーバー操作のコミット中に発生したエラーの基となる原因を修正してSQL文（ALTER DTABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY）を再発行します。次の手順を実行することもできます。
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBYの後に表示されます。
LOGSTDBY: Preparing the COMMIT TO SWITCHOVER TO LOGICAL STANDBY DDL at scn [flashback_scn].
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO BEFORE SCN <flashback_scn>;
SQL> STARTUP;
SQL> ALTER DATABASE GUARD NONE;
この時点で、プライマリの状態はスイッチオーバーのコミット・コマンドが発行される前と同一です。修正処理を実行する必要はありません。スイッチオーバー操作のコミットに進むか、A.5.1.1項で説明するようにスイッチオーバー操作を取り消します。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY文の実行中に障害が発生した場合、次の手順を実行します。
V$DATABASE固定ビューのDATABASE_ROLE列をチェックします。
SQL> SELECT DATABASE_ROLE FROM V$DATABASE;
ALTER DATABASE GUARD NONEコマンドを発行して、データベースに対する書込み制限を削除します。
SQL> SELECT COUNT(*) FROM SYSTEM.LOGSTDBY$PARAMETERS 2> WHERE NAME = 'BEGIN_PRIMARY';
スイッチオーバー操作のコミット中に発生したエラーの基となる原因を修正してSQL文（ALTER DTABASE COMMIT TO SWITCHOVER TO PRIMARY）を再発行します。次の手順を実行して、スイッチオーバーのコミットを試行する直前の一貫性の時点までロジカル・スタンバイ・データベースをフラッシュバックすることもできます。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARYの後に表示されます。
LOGSTDBY: Preparing the COMMIT TO SWITCHOVER TO PRIMARY DDL at scn
[flashback_scn].
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO BEFORE SCN <flashback_scn>;
SQL> STARTUP OPEN;
この時点で、ターゲット・スタンバイの状態はスイッチオーバーのコミット・コマンドが発行される前と同一です。対処措置を実行する必要はありません。スイッチオーバー操作のコミットに進みます。
適用サービスでは、サポートされないDML文、DDL文およびオラクル社が提供するパッケージを、SQL Applyが実行されているロジカル・スタンバイ・データベースに適用できません。
サポートされない文やパッケージが検出されると、SQL Applyは停止します。表A-2で説明する処理を実行して問題を解決した後、ロジカル・スタンバイ・データベースでSQL Applyを再開してください。
障害の原因を特定するためにDBA_LOGSTDBY_EVENTSビューを問い合せる方法は、第17章を参照してください。
最適なパフォーマンスを得るには、REDO転送サービスで使用される各Oracle Net接続記述子で、Oracle Net SDUパラメータを32KBに設定します。
次の例は、データベース初期化パラメータ・ファイル内のリモート宛先netservを定義する部分を示します。
LOG_ARCHIVE_DEST_3='SERVICE=netserv'
次の例は、tnsnames.oraファイル内のサービス名の定義を示します。
netserv=(DESCRIPTION=(SDU=32768)(ADDRESS=(PROTOCOL=tcp)(HOST=host) (PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=srvc)))
次の例は、listener.oraファイル内の定義を示します。
LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp) (HOST=host)(PORT=1521)))) SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SDU=32768)(SID_NAME=sid) (GLOBALDBNAME=srvc)(ORACLE_HOME=/oracle)))
待機時間が長いかまたは帯域幅が大きいネットワーク・リンクを使用してリモート・サイトへのアーカイブを行う場合は、Oracle Netプロファイル・パラメータのSQLNET.SEND_BUF_SIZEおよびSQLNET.RECV_BUF_SIZEを使用して、ネットワークの送受信I/Oバッファのサイズを大きくすることでパフォーマンスを改善できます。
『Oracle Database Net Services管理者ガイド』を参照してください。
ファイル・システム上の非同期I/Oがパフォーマンス上の問題を示している場合は、ダイレクトI/Oオプションを使用してファイル・システムをマウントするか、またはFILESYSTEMIO_OPTIONS=SETALL初期化パラメータを設定します。最大I/Oのサイズ設定は、1MBです。
構成内の1つ以上のスタンバイ・データベースでスタンバイREDOログを構成した場合は、各スタンバイ・データベースのスタンバイREDOログ・ファイルのサイズが、プライマリ・データベースのオンラインREDOログ・ファイルのサイズと正確に一致していることを確認してください。
ログ・スイッチが発生したときに、プライマリ・データベースに新しい現行のオンラインREDOログ・ファイルのサイズと一致する使用可能なスタンバイREDOログ・ファイルがない場合、次のようになります。
または
No standby log files of size <#> blocks available.
たとえば、プライマリ・データベースで、ログ・ファイルが100KのオンラインREDOログ・グループを2つ使用する場合、スタンバイ・データベースは、ログ・ファイル・サイズが100KのスタンバイREDOログ・グループを3つ持ちます。
また、REDOログ・グループをプライマリ・データベースに追加した場合は、対応するスタンバイREDOログ・グループをスタンバイ・データベースに追加する必要があります。これにより、プライマリ・データベースが悪影響を受ける可能性が低くなります。これは、ログ・スイッチが発生したときに、必要なサイズのスタンバイREDOログ・ファイルが使用できないためです。
この項は、次の項目で構成されています。
ロジカル・スタンバイ・データベースでは、ユーザー表、順序およびジョブがメンテナンスされます。他のオブジェクトをメンテナンスするには、REDOデータ・ストリームにあるDDL文を再発行する必要があリます。
SQL Applyに障害が発生した場合、エラーはDBA_LOGSTDBY_EVENTS表に記録されます。次の各項では、このようなエラーのリカバリ方法を説明します。
DDL文は、プライマリ・データベースとロジカル・スタンバイ・データベースでは同じ方法で実行されます。基礎となるファイル構造が両方のデータベースで同じ場合、DDLはスタンバイ・データベース上で予想どおりに実行されます。
エラーの原因が、ロジカル・スタンバイ・データベース環境に適合しないファイル仕様を含んだDDLトランザクションにある場合は、次の手順を実行して問題を解決してください。
ALTER SESSION DISABLE GUARD文を使用してデータベース・ガードをバイパスし、ロジカル・スタンバイ・データベースへの変更を可能にします。
SQL> ALTER SESSION DISABLE GUARD;
SQL> ALTER TABLESPACE t_table ADD DATAFILE '/dbs/t_db.f' SIZE 100M REUSE; SQL> ALTER SESSION ENABLE GUARD;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE 2> SKIP FAILED TRANSACTION;
トランザクション障害の原因となった問題を修正し、トランザクションをスキップせずにSQL Applyを再開できる場合があります。たとえば、使用可能領域がすべて使用された場合などです。（DDLトランザクションをスキップするときに、プライマリおよびロジカル・スタンバイ・データベースの内容にずれを生じさせないようにしてください。可能な場合は、スキップされたトランザクションのかわりに補足用トランザクションを手動で実行する必要があります。）
次の例に、SQL Applyの停止、エラーの修正およびSQL Applyの再開を示します。
SQL> SET LONG 1000 SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS'; Session altered. SQL> SELECT EVENT_TIME, COMMIT_SCN, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS; EVENT_TIME COMMIT_SCN ------------------ --------------- EVENT ------------------------------------------------------------------------------- STATUS ------------------------------------------------------------------------------- 22-OCT-03 15:47:58 ORA-16111: log mining and apply setting up 22-OCT-03 15:48:04 209627 insert into "SCOTT"."EMP" values "EMPNO" = 7900, "ENAME" = 'ADAMS', "JOB" = 'CLERK', "MGR" IS NULL, "HIREDATE" = TO_DATE('22-OCT-03', 'DD-MON-RR'), "SAL" = 950, "COMM" IS NULL, "DEPTNO" IS NULL ORA-01653: unable to extend table SCOTT.EMP by %200 bytes in tablespace T_TABLE
この例で、ORA-01653メッセージは、表領域がいっぱいで表を拡張できないことを示しています。問題を修正するには、新しいデータファイルを表領域に追加します。次に例を示します。
SQL> ALTER TABLESPACE t_table ADD DATAFILE '/dbs/t_db.f' SIZE 60M; Tablespace altered.
次に、SQL Applyを再開します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered.
SQL Applyを再開すると、障害が発生したトランザクションが再実行され、ロジカル・スタンバイ・データベースに適用されます。
DML障害のフィルタ処理には、SKIP_TRANSACTIONプロシージャを使用しないでください。また、スキップされたイベント表にあるDMLのみでなく、トランザクションに関連しているすべてのDMLについても注意が必要です。これが複数の表の原因となります。
DML障害は通常、特定の表に関する問題を示しています。たとえば、障害が即時に解決できない記憶域の不足に関するエラーであるとします。次の手順は、この問題に応答する1つの方法を示しています。
SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','SCOTT','EMP'); SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
この時点から、SCOTT.EMP表に関するDMLアクティビティは適用されません。表は、記憶域の問題を解決した後で修正できます。ただし、表を修正するには、DBMS_LOGSTDBYパッケージ内のプロシージャを実行するための管理者権限がある、プライマリ・データベースへのデータベース・リンクを設定していることが必要です。
SCOTT.EMP表を削除し、表を再作成して、データをスタンバイ・データベースに転送します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE('SCOTT','EMP','PRIMARYDB'); SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Oracle SQL*Loaderには、様々なソースからOracle Databaseにデータをロードする方法が用意されています。この項では、SQL*Loaderユーティリティの一部のSQL Apply関連機能について説明します。
選択したデータ・ロード方法に関係なく、SQL*Loader制御ファイルには、APPENDおよびREPLACEキーワードを介して、新規データのロード先となるOracle表の現在の内容に対して実行する作業を示す指示が含まれています。次の例に、これらのキーワードをLOAD_STOKという表に使用する方法を示します。
APPENDキーワードを使用すると、新規にロードされるデータはLOAD_STOK表の内容に追加されます。
LOAD DATA INTO TABLE LOAD_STOK APPEND
REPLACEキーワードを使用すると、LOAD_STOK表の内容が削除されてから新規のデータがロードされます。SQL*Loaderでは、DELETE文を使用して表の内容が1つのトランザクションでパージされます。
LOAD DATA INTO TABLE LOAD_STOK REPLACE
SQL*LoaderスクリプトでREPLACEキーワードを使用するかわりに、データをロードする前にプライマリ・データベースの表に対してSQL*PlusのTRUNCATE TABLEコマンドを発行することをお薦めします。これは、プライマリ・データベースとスタンバイ・データベースの両方から高速かつ効率的な方法で表のコピーをパージするのと同じ効果があります。これは、TRUNCATE TABLEコマンドはオンラインREDOログ・ファイルに記録され、ロジカル・スタンバイ・データベースでSQL Applyにより発行されるためです。
SQL*Loaderスクリプトに引き続きREPLACEキーワードを挿入することはできますが、プライマリ・データベースではオブジェクトからの0（ゼロ）行のDELETEが試行されます。プライマリ・データベースから行が削除されていないため、REDOログ・ファイルにREDOは記録されません。したがって、ロジカル・スタンバイ・データベースに対してDELETE文は発行されません。
SQL文TRUNCATE TABLEを使用せずにREPLACEキーワードを発行すると、トランザクションをロジカル・スタンバイ・データベースに適用する必要がある場合に、SQL Applyに次のような問題が発生する可能性があります。
DELETE文を発行する必要があります。たとえば、プライマリ・データベースの表に最初は10,000行含まれていた場合、Oracle SQL*Loaderは1つのDELETE文を発行して10,000行をパージします。スタンバイ・データベースでは、SQL Applyはすべての行がパージされることを認識しないかわりに、10,000のDELETE文を個別に発行し、それぞれの文で1行ずつパージする必要があります。
DELETE文では情報をパージするために全表スキャンが発行されます。前述の例では、SQL Applyは10,000のDELETE文を個別に発行しているため、スタンバイ・データベースに対して10,000の全表スキャンが発行される可能性があります。
SQL Apply環境における長時間実行トランザクションの主な原因の1つは、全表スキャンです。また、索引の作成時や再作成時のように、SQL文がスタンバイ・データベースに複製されるために、長時間実行トランザクションが発生することもあります。
SQL Applyで1つのSQL文が長時間実行されている場合は、SQL Applyインスタンスのアラート・ログに次のような警告メッセージがレポートされます。
Mon Feb 17 14:40:15 2003 WARNING: the following transaction makes no progress WARNING: in the last 30 seconds for the given message! WARNING: xid = 0x0016.007.000017b6 cscn = 1550349, message# = 28, slavid = 1 knacrb: no offending session found (not ITL pressure)
この警告メッセージの注意事項は次のとおりです。
knacrbで始まります。この最終行は、次のことを示しています。
長時間実行文で実行されているSQL文を判別できない場合がありますが、次のSQL文を発行すると、SQL Applyが作業中のデータベース・オブジェクトを識別できます。
SQL> SELECT SAS.SERVER_ID 2 , SS.OWNER 3 , SS.OBJECT_NAME 4 , SS.STATISTIC_NAME 5 , SS.VALUE 6 FROM V$SEGMENT_STATISTICS SS 7 , V$LOCK L 8 , V$STREAMS_APPLY_SERVER SAS 9 WHERE SAS.SERVER_ID = &SLAVE_ID 10 AND L.SID = SAS.SID 11 AND L.TYPE = 'TM' 12 AND SS.OBJ# = L.ID1;
また、次のSQL文を発行すると、実行ごとに多数のディスク読取りを発生させたSQL文を識別できます。
SQL> SELECT SUBSTR(SQL_TEXT,1,40) 2 , DISK_READS 3 , EXECUTIONS 4 , DISK_READS/EXECUTIONS 5 , HASH_VALUE 6 , ADDRESS 7 FROM V$SQLAREA 8 WHERE DISK_READS/GREATEST(EXECUTIONS,1) > 1 9 AND ROWNUM < 10 10 ORDER BY DISK_READS/GREATEST(EXECUTIONS,1) DESC
すべての表に主キー制約を定義することをお薦めします。これにより自動的に列がNOT NULLとして定義されます。主キー制約を定義できない表の場合は、NOT NULLとして定義されている適切な列に索引を定義する必要があります。表に適切な列が存在しない場合はその表を見直し、可能な場合はSQL Applyでスキップしてください。
SCOTTスキーマのFTS表に対して発行されたDML文をすべてスキップする手順は、次のとおりです。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered
SCOTT.FTS表について、すべてのDMLトランザクションのスキップ・プロシージャを構成します。
SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML' , - schema_name => 'SCOTT' , - object_name => 'FTS'); PL/SQL procedure successfully completed
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered
Interested Transaction List（ITL）が不十分な状態は、SQL Applyインスタンスのアラート・ログでレポートされます。例A-3に、警告メッセージの例を示します。
Tue Apr 22 15:50:42 2003 WARNING: the following transaction makes no progress WARNING: in the last 30 seconds for the given message! WARNING: xid = 0x0006.005.000029fa cscn = 2152982, message# = 2, slavid = 17
例A-3のメッセージは、SQL Applyプロセス（slavid）#17が過去30秒にわたって進捗がなかったことを示しています。適用プロセスにより発行されているSQL文を判別するには、次の問合せを発行します。
SQL> SELECT SA.SQL_TEXT 2 FROM V$SQLAREA SA 3 , V$SESSION S 4 , V$STREAMS_APPLY_SERVER SAS 5 WHERE SAS.SERVER_ID = &SLAVEID 6 AND S.SID = SAS.SID 7 AND SA.ADDRESS = S.SQL_ADDRESS SQL_TEXT ------------------------------------------------------------ insert into "APP"."LOAD_TAB_1" p("PK","TEXT")values(:1,:2)
ITLが不十分な状態を識別するには、次の例に示すようにV$LOCKビューを問い合せる方法もあります。TXロックのリクエスト値が4のセッションは、ITLが使用可能になるまで待機中です。
SQL> SELECT SID,TYPE,ID1,ID2,LMODE,REQUEST 2 FROM V$LOCK 3 WHERE TYPE = 'TX' SID TY ID1 ID2 LMODE REQUEST ---------- -- ---------- ---------- ---------- ---------- 8 TX 327688 48 6 0 10 TX 327688 48 0 4
この例では、SID 10はSID 8が保持しているTXロックを待機中です。
セグメントのITLが不十分な状態が長時間続くことはまずありません。また、この状態の継続時間が30秒未満の場合、スタンバイ・データベースのアラート・ログではレポートされません。したがって、ITLが不十分な状態になっているオブジェクトを判別するには、次の文を発行します。
SQL> SELECT SEGMENT_OWNER, SEGMENT_NAME, SEGMENT_TYPE 2 FROM V$SEGMENT_STATISTICS 3 WHERE STATISTIC_NAME = 'ITL WAITS' 4 AND VALUE > 0 5 ORDER BY VALUE
この文では、インスタンスが前回起動された後にITLが不十分な状態になったことのあるデータベース・セグメントがすべてレポートされます。
特定のデータベース・オブジェクトのINITRANSの整数を増やすには、最初にSQL Applyを停止する必要があります。
次の例に、appスキーマ内の表load_tab_1のINITRANSを増やすための手順を示します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered.
SQL> ALTER SESSION DISABLE GUARD; Session altered.
INITRANSを増やします。次に例を示します。
SQL> ALTER TABLE APP.LOAD_TAB_1 INITRANS 30; Table altered
SQL> ALTER SESSION ENABLE GUARD; Session altered
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered.
また、スイッチオーバー時に新しいスタンバイ・データベースでエラーが発生しないように、プライマリ・データベースでデータベース・オブジェクトを変更することを考慮してください。
SQL Applyが「ORA-1403: データが見つかりません。」エラーを戻す場合は、フラッシュバック・トランザクションを使用して欠落しているデータを再構成できる場合があります。これは、スタンバイ・データベース・インスタンスで指定されているUNDO_RETENTION初期化パラメータに依存します。
通常、ロジカル・スタンバイ・データベース環境でORA-1403エラーは表示されません。このエラーが発生するのは、SQL Applyの管理対象である表のデータがスタンバイ・データベースで直接変更された後、同じデータがプライマリ・データベースで変更された場合です。
変更されたデータがプライマリ・データベースで更新されてからロジカル・スタンバイ・データベースで受信されると、SQL Applyはデータのオリジナル・バージョンがスタンバイ・データベースに存在することを確認してから、レコードを更新します。この確認に失敗すると、「ORA-1403: データが見つかりません。」エラーが戻されます。
SQL Applyが検証に失敗すると、ロジカル・スタンバイ・データベースのアラート・ログでエラー・メッセージがレポートされ、DBA_LOGSTDBY_EVENTSビューにレコードが挿入されます。
アラート・ログ内の情報は切り捨てられますが、エラー全体がデータベース・ビューでレポートされます。次に例を示します。
LOGSTDBY stmt: UPDATE "SCOTT"."MASTER" SET "NAME" = 'john' WHERE "PK" = 1 and "NAME" = 'andrew' and ROWID = 'AAAAAAAAEAAAAAPAAA' LOGSTDBY status: ORA-01403: no data found LOGSTDBY PID 1006, oracle@staco03 (P004) LOGSTDBY XID 0x0006.00e.00000417, Thread 1, RBA 0x02dd.00002221.10
最初のステップは、エラーの原因となった表の履歴データを分析することです。そのためには、SELECT文のVERSIONS句を使用します。たとえば、プライマリ・データベースで次の問合せを発行できます。
SELECT VERSIONS_XID , VERSIONS_STARTSCN , VERSIONS_ENDSCN , VERSIONS_OPERATION , PK , NAME FROM SCOTT.MASTER VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE WHERE PK = 1 ORDER BY NVL(VERSIONS_STARTSCN,0); VERSIONS_XID VERSIONS_STARTSCN VERSIONS_ENDSCN V PK NAME ---------------- ----------------- --------------- - --- ------- 03001900EE070000 3492279 3492290 I 1 andrew 02000D00E4070000 3492290 D 1 andrew
データベースが保持するように構成されているUNDO保存の量（UNDO_RETENTION）と表に対するアクティビティによっては、戻される情報が広範囲にわたり、その量を制限するために構文間でバージョンの変更が必要になる場合があります。
戻された情報から、レコードが最初にSCN 3492279で挿入され、SCN 3492290でトランザクションID 02000D00E4070000の一部として削除されたことがわかります。
このトランザクションIDを使用してデータベースを問い合せ、トランザクションの有効範囲を確認する必要があります。そのためにはFLASHBACK_TRANSACTION_QUERYビューを問い合せます。
SELECT OPERATION , UNDO_SQL FROM FLASHBACK_TRANSACTION_QUERY WHERE XID = HEXTORAW('02000D00E4070000'); OPERATION UNDO_SQL ---------- ------------------------------------------------ DELETE insert into "SCOTT"."MASTER"("PK","NAME") values ('1','andrew'); BEGIN
トランザクションの開始を表す1行が必ず戻されることに注意してください。このトランザクションでは、マスター表から削除されたのは1行のみです。実行時のUNDO_SQL列では、元のデータが表にリストアされます。
SQL> INSERT INTO "SCOTT"."MASTER"("PK","NAME") VALUES ('1','ANDREW'); SQL> COMMIT;
SQL Applyを再開すると、トランザクションがスタンバイ・データベースに適用されます。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
|
 Copyright © 1999, 2008 Oracle Corporation. All Rights Reserved. |
|