A Oracle Data Guardのトラブルシューティング
スタンバイ・データベースで発生する可能性がある問題の一部と、それらに対応するためのトラブルシューティング手順を次に示します。
A.1 一般的な問題
スタンバイ・データベースの使用時に発生する可能性がある一般的な問題の一部を次に示します。
A.1.1 ALTER DATABASE文を使用したデータファイルの改名
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
フィジカル・スタンバイ・データベースにデータファイルを追加する方法は、「データファイルの追加または表領域の作成」を参照してください。
A.1.2 スタンバイ・データベースがプライマリ・データベースからREDOデータを受信しない
スタンバイ・サイトがREDOデータを受信していない場合は、V$ARCHIVE_DESTビューの問合せを行い、エラー・メッセージがないか確認します。
たとえば、次のような問合せを入力します。
SQL> SELECT DEST_ID "ID", - > STATUS "DB_status", - > DESTINATION "Archive_dest", - > ERROR "Error" - > 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ファイルがスタンバイ・データベース用に正しく構成されていない場合。 -
スタンバイ・サイトでリスナーが開始されていない場合。
-
スタンバイ・インスタンスが起動されていない場合。
-
スタンバイ・アーカイブ先をプライマリSPFILEまたはテキスト初期化パラメータ・ファイルに追加したが、その変更をまだ使用可能にしていない場合。
-
REDO転送の認証が正しく構成されていない場合。REDO転送の認証の構成要件は、3.1.2項を参照してください。
-
スタンバイ・データベースのベースとして無効なバックアップを使用した場合(たとえば、間違ったデータベースからのバックアップを使用、または正しい方法でスタンバイ制御ファイルを作成しなかったなど)。
A.2 ログ・ファイル宛先の障害
MANDATORY宛先にREOPENを指定した場合、REDO転送サービスは、REDOデータを正常に転送できなかったとき、プライマリ・データベースを停止します。
MAX_FAILURE属性を使用する場合は、REOPEN属性は必須です。例A-1に、再試行時間を5秒に設定し、再試行回数を3回に制限する方法を示します。
例A-1 再試行時間と制限の設定
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は、エラー発生時に、単一、必須のローカル宛先が異なる宛先へ自動的にフェイルオーバーするように初期化パラメータを設定する方法を示します。
例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の宛先に自動的に切り替えます。
A.3 ロジカル・スタンバイ・データベース障害の処理
ロジカル・スタンバイ・データベース障害を処理するための重要なツールは、DBMS_LOGSTDBY.SKIP_ERRORプロシージャです。
表の重要度に基づいて、次のいずれかを実行できます。
-
表や特定のDDLに関する障害を無視する。
-
ストアド・プロシージャをフィルタに関連付ける。これによって、文のスキップ、文の実行または代用文の実行について実行時に決定できます。
これらの処理のいずれかを実行すると、SQL Applyの停止を回避できます。存在している問題は、後でDBA_LOGSTDBY_EVENTSビューを問い合せて検索し、訂正できます。PL/SQLコールアウト・プロシージャでのDBMS_LOGSTDBYパッケージ使用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
A.4 フィジカル・スタンバイ・データベースへのスイッチオーバーの問題
スイッチオーバーの失敗の原因となる可能性のある問題の一部と、考えられる解決策を次に示します。
A.4.1 REDOデータが転送されていないためスイッチオーバーできない
スイッチオーバーが正常に完了しない場合は、V$ARCHIVED_LOGビューのSEQUENCE#列の問合せを行い、元のプライマリ・データベースから転送された最新のREDOデータが、スタンバイ・データベースに適用されていることを確認してください。
最後のREDOデータがスタンバイ・データベースに転送されていない場合は、そのREDOデータが含まれるアーカイブREDOログ・ファイルを元のプライマリ・データベースから古いスタンバイ・データベースに手動でコピーし、SQL ALTER DATABASE REGISTER LOGFILE file_specification文を使用して登録します。次に適用サービスを開始すると、アーカイブREDOログ・ファイルが自動的に適用されます。V$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。SWITCHOVER_STATUS列からTO PRIMARYまたはSESSIONS ACTIVEが戻されると、プライマリ・ロールへのスイッチオーバーが可能になります。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO PRIMARY 1 row selected
スイッチオーバーを続行するには、「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」(フィジカル・スタンバイ・データベースの場合)または「ロジカル・スタンバイ・データベースへのスイッチオーバーの実行」(ロジカル・スタンバイ・データベースの場合)の説明に従って、ターゲットのスタンバイ・データベースをプライマリ・ロールに切り替える操作を再度実行します。
A.4.2 ORA-01102エラーによりスイッチオーバーできない
スイッチオーバー中にORA-01102エラーが表示された理由と、実行する必要があるアクションが説明されます。
スタンバイ・データベースとプライマリ・データベースが同じサイトに存在するとします。ALTER DATABASE SWITCHOVER TO target_db_name文が正常に実行された後、フィジカル・スタンバイ・データベースとプライマリ・データベースを停止し、再起動します。
注意:
フィジカル・スタンバイ・データベースが起動後に読取り専用モードでオープンされていない場合、停止して再起動する必要はありません。
ただし、2番目のデータベースの起動は、ORA-01102エラー「データベースを排他モードでマウントすることができません。」で失敗します。
スタンバイ・データベース(元のプライマリ・データベース)で使用される初期化パラメータ・ファイルにDB_UNIQUE_NAMEパラメータを設定していないと、スイッチオーバー中にこの現象が発生することがあります。スタンバイ・データベースのDB_UNIQUE_NAMEパラメータが設定されていない場合、スタンバイ・データベースとプライマリ・データベースの両方が同じマウント・ロックを使用するため、2つ目のデータベースの起動時にORA-01102エラーが発生します。
処置: DB_UNIQUE_NAME=unique_database_nameをスタンバイ・データベースが使用する初期化パラメータ・ファイルに追加して、スタンバイ・データベースとプライマリ・データベースを停止し、再起動します。
A.4.3 スイッチオーバー後にREDOデータが適用されない
スイッチオーバー後にアーカイブREDOログ・ファイルが新しいスタンバイ・データベースに適用されない場合は、スイッチオーバー後に一部の環境パラメータまたは初期化パラメータが正しく設定されていなかったことが原因と考えられます。
処置:
-
新しいプライマリ・サイトの
tnsnames.oraファイルおよび新しいスタンバイ・サイトのlistener.oraファイルを調べます。スタンバイ・サイトにはリスナーのエントリ、プライマリ・サイトにはそれに対応するサービス名が必要です。 -
リスナーがまだ起動されていない場合は、スタンバイ・サイトで起動します。
-
プライマリ・サイトからスタンバイ・サイトにREDOデータを正しく転送するための、
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に設定します。
A.5 ロジカル・スタンバイ・データベースへのスイッチオーバーの問題
ロジカル・スタンバイ・データベースに関連するスイッチオーバー操作には、通常、準備とコミットの2つのフェーズがあります。これに対する例外は、ロジカル・スタンバイ・データベースを使用したOracleソフトウェアのローリング・アップグレードの場合、またはOracle Data Guard Brokerを使用している場合です。
ロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行中、またはOracle Data Guard Brokerで開始されたスイッチオーバー操作の際に障害が発生した場合は、スイッチオーバー操作のコミット・フェーズ中の障害に直接進んでください。
注意:
Oracle Data Guard構成のすべてのデータベースで、フラッシュバック・データベースを有効にすることをお薦めします。この項の手順では、使用するOracle Data Guard構成内のすべてのデータベースで、フラッシュバック・データベースが有効にされていると想定しています。
A.5.1 スイッチオーバー操作の準備フェーズ中の障害
スイッチオーバー操作の準備フェーズ中に障害が発生した場合、スイッチオーバーを取り消して、スイッチオーバー操作を再度初めから実行します。
A.5.1.1 プライマリ・データベースの準備中の障害
ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY文の実行中に障害が発生した場合は、スイッチオーバーの準備フェーズを取り消しできます。
そのためには、次のSQL文をプライマリ・データベースで発行します。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY CANCEL;
これで、スイッチオーバー操作を再度初めから行うことができます。
A.5.2 スイッチオーバー操作のコミット・フェーズ中の障害
スイッチオーバーのコミットでは単一のSQL文のみを使用しますが、内部的には多数の操作が実行されます。
実行する必要がある修正処理は、エラー発生時のスイッチオーバー操作のコミットの状態によって異なります。
A.5.2.1 元のプライマリ・データベースの変換での障害
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY文の実行中に障害が発生した場合に実行できる手順があります。
-
元のプライマリ・データベースの
V$DATABASE固定ビューのDATABASE_ROLE列をチェックします。SQL> SELECT DATABASE_ROLE FROM V$DATABASE;
-
列に
LOGICAL STANDBYの値が含まれる場合、スイッチオーバー操作は完了していますが、スイッチオーバー後のタスクで障害が発生しています。この場合、データベースを停止して再オープンすることをお薦めします。 -
列に
PRIMARYの値が含まれる場合、手順2に進みます。
-
-
元のプライマリで次の問合せを実行します。
SQL> SELECT COUNT(*) FROM SYSTEM.LOGSTDBY$PARAMETERS - > WHERE NAME = 'END_PRIMARY';
-
問合せで0が戻される場合、プライマリの状態は、スイッチオーバーのコミット・コマンドが発行される前と同一です。修正処理を実行する必要はありません。スイッチオーバー操作のコミットに進むか、「ロジカル・スタンバイ・データベースの準備中の障害」で説明するようにスイッチオーバー操作を取り消します。
-
問合せで1が戻される場合、プライマリは一貫性がない状態のため、手順3に進む必要があります。
-
-
インスタンス化された既存のまたは新しいロジカル・スタンバイ・データベースにより保護されるための機能が維持されるよう、元のプライマリ・データベースで対処措置を実行します。
スイッチオーバー操作のコミット中に発生したエラーの基となる原因を修正してSQL文(
ALTER DTABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY)を再発行します。次の手順を実行することもできます。-
スイッチオーバー・コマンドのコミットを開始したインスタンスのアラート・ログから、元のプライマリへのフラッシュバックに必要なSCNを判別します。この情報は、SQL文
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;
-
データベースをアラート・ログから取得したSCNまでフラッシュバックします。
SQL> FLASHBACK DATABASE TO BEFORE SCN <flashback_scn>;
-
プライマリ・データベースをオープンします。
SQL> STARTUP;
-
元のプライマリ・データベースのデータベース・ガードを低くします。
SQL> ALTER DATABASE GUARD NONE;
この時点で、プライマリの状態はスイッチオーバーのコミット・コマンドが発行される前と同一です。修正処理は必要ありません。スイッチオーバー操作のコミットに進むか、「プライマリ・データベースの準備中の障害」で説明するようにスイッチオーバー操作を取り消します。
-
A.5.2.2 ターゲット・ロジカル・スタンバイ・データベースの変換での障害
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY文の実行中に障害が発生した場合に実行できる手順があります。
-
ターゲット・スタンバイ・データベースの
V$DATABASE固定ビューのDATABASE_ROLE列をチェックします。SQL> SELECT DATABASE_ROLE FROM V$DATABASE;
-
列に
PRIMARYの値が含まれる場合、スイッチオーバー操作は完了していますが、スイッチオーバー後のタスクで障害が発生しています。この場合、次の手順を実行します。-
データベースを停止して、再オープンします。
-
ALTER DATABASE GUARD NONEコマンドを発行して、データベースに対する書込み制限を削除します。
-
-
列に
LOGICAL STANDBYの値が含まれる場合、手順2に進みます。
-
-
ターゲット・ロジカル・スタンバイで次の問合せを実行します。
SQL> SELECT COUNT(*) FROM SYSTEM.LOGSTDBY$PARAMETERS - > WHERE NAME = 'BEGIN_PRIMARY';
-
問合せで0が戻される場合、ロジカル・スタンバイの状態はスイッチオーバーのコミット・コマンドが発行される前と同一です。修正処理を実行する必要はありません。スイッチオーバー操作のコミットに進むか、「ロジカル・スタンバイ・データベースの準備中の障害」で説明するようにスイッチオーバー操作を取り消します。
-
問合せで1が返される場合、ロジカル・スタンバイは一貫性がない状態です。手順3に進んでください。
-
-
新しいプライマリまたは別の新しいプライマリに対するバイスタンダになるための機能が維持されるよう、ロジカル・スタンバイで対処措置を実行します。
スイッチオーバー操作のコミット中に発生したエラーの基となる原因を修正してSQL文(
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY)を再発行します。次の手順を実行して、スイッチオーバーのコミットを試行する直前の一貫性の時点までロジカル・スタンバイ・データベースをフラッシュバックすることもできます。-
スイッチオーバーのコミット・コマンドを開始したインスタンスのアラート・ログから、ロジカル・スタンバイへのフラッシュバックに必要なSCNを判別します。この情報は、SQL文
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;
-
必要なSCNまでターゲット・ロジカル・スタンバイをフラッシュバックします。
SQL> FLASHBACK DATABASE TO BEFORE SCN <flashback_scn>;
-
データベースをオープンします(Oracle RACの場合、すべてのインスタンスをオープンします)。
SQL> STARTUP OPEN;
-
この時点で、ターゲット・スタンバイの状態はスイッチオーバーのコミット・コマンドが発行される前と同一です。対処措置を実行する必要はありません。スイッチオーバー操作のコミットに進みます。
A.6 SQL Applyが停止した場合の処置
サポートされない文やパッケージが検出されると、SQL Applyは停止します。
適用サービスでは、サポートされないDML文、DDL文およびオラクル社が提供するパッケージを、SQL Applyが実行されているロジカル・スタンバイ・データベースに適用できません。
SQL Applyが、サポートされない文やパッケージのために停止した場合は、問題を修正し、表A1で説明されているアクションを実行して、ロジカル・スタンバイ・データベースでSQL Applyを再開できます。
表A-1 一般的なSQL Applyエラーの解決方法
障害の原因を特定するためにDBA_LOGSTDBY_EVENTSビューを問い合せる方法は、「Oracle Data Guardに関連するビュー」を参照してください。
A.7 REDOデータ転送のネットワーク調整
最適なパフォーマンスを得るには、REDO転送サービスで使用される各Oracle Net接続記述子で、Oracle Net SDUパラメータを最大値の65535バイトに設定します。
次の例は、データベース初期化パラメータ・ファイル内のリモート宛先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 NET SDUパラメータのその他の変更方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
A.8 スタンバイ・データベースのディスクのパフォーマンスが遅い
ファイル・システム上の非同期I/Oがパフォーマンス上の問題を示している場合は、ダイレクトI/Oオプションを使用してファイル・システムをマウントするか、またはFILESYSTEMIO_OPTIONS=SETALL初期化パラメータを設定します。
最大I/Oのサイズ設定は、1MBです。
A.9 プライマリ・データベースの停止を回避するにはログ・ファイルを一致させる必要がある
構成内の1つ以上のスタンバイ・データベースでスタンバイREDOログを構成した場合は、各スタンバイ・データベースのスタンバイREDOログ・ファイルのサイズが、プライマリ・データベースのオンラインREDOログ・ファイルのサイズと正確に一致していることを確認してください。
ログ・スイッチが発生したときに、プライマリ・データベースに新しい現行のオンラインREDOログ・ファイルのサイズと一致する使用可能なスタンバイREDOログ・ファイルがない場合、次のようになります。
-
プライマリ・データベースが最大保護モードで作動しているときは停止します。
または
-
スタンバイ・データベース上のRFSプロセスにより、スタンバイ・データベースにアーカイブREDOログ・ファイルが作成され、次のメッセージがアラート・ログに書き込まれます。
No standby log files of size <#> blocks available.
たとえば、プライマリ・データベースで、ログ・ファイルが100KのオンラインREDOログ・グループを2つ使用する場合、スタンバイ・データベースは、ログ・ファイル・サイズが100KのスタンバイREDOログ・グループを3つ持ちます。
また、REDOログ・グループをプライマリ・データベースに追加するたびに、対応するスタンバイREDOログ・グループをスタンバイ・データベースに追加する必要があります。これによって必要なサイズのスタンバイREDOログ・ファイルがログ・スイッチ時に使用できないことにより、プライマリ・データベースに悪影響が発生する可能性を軽減できます。
A.10 ロジカル・スタンバイ・データベースのトラブルシューティング
エラーのリカバリに役立つトラブルシューティングのヒントを次に示します。
A.10.1 エラーのリカバリ
ロジカル・スタンバイ・データベースでは、ユーザー表、順序およびジョブがメンテナンスされます。他のオブジェクトをメンテナンスするには、REDOデータ・ストリームにあるDDL文を再発行する必要があリます。
SQL Applyに障害が発生した場合、エラーはDBA_LOGSTDBY_EVENTS表に記録されます。次の各項では、このようなエラーのリカバリ方法を説明します。
A.10.1.1 ファイル仕様が含まれているDDLトランザクション
DDL文は、プライマリ・データベースとロジカル・スタンバイ・データベースでは同じ方法で実行されます。
基礎となるファイル構造が両方のデータベースで同じ場合、DDLはスタンバイ・データベース上で予想どおりに実行されます。
エラーの原因が、ロジカル・スタンバイ・データベース環境に適合しないファイル仕様を含んだDDLトランザクションにある場合は、次の手順を実行して問題を解決してください。
トランザクション障害の原因となった問題を修正し、トランザクションをスキップせずに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を再開すると、障害が発生したトランザクションが再実行され、ロジカル・スタンバイ・データベースに適用されます。
A.10.2 SQL*Loaderセッションのトラブルシューティング
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に次のような問題が発生する可能性があります。
-
現在、表に多数の行が含まれている場合は、その行をスタンバイ・データベースから削除する必要があります。SQL Applyでは文の元の構文を判別できないため、プライマリ・データベースからパージする行ごとに
DELETE文を発行する必要があります。たとえば、プライマリ・データベースの表に最初は10,000行含まれていた場合、Oracle SQL*Loaderは1つの
DELETE文を発行して10,000行をパージします。スタンバイ・データベースでは、SQL Applyはすべての行がパージされることを認識しないかわりに、10,000のDELETE文を個別に発行し、それぞれの文で1行ずつパージする必要があります。 -
スタンバイ・データベースの表にSQL Applyで使用可能な索引が含まれていない場合、
DELETE文では情報をパージするために全表スキャンが発行されます。前述の例では、SQL Applyは10,000の
DELETE文を個別に発行しているため、スタンバイ・データベースに対して10,000の全表スキャンが発行される可能性があります。
A.10.3 長時間実行トランザクションのトラブルシューティング
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)
この警告メッセージの注意事項は次のとおりです。
-
この警告は、Interested Transaction List(ITL)が不十分な場合に戻される警告メッセージに似ていますが、最終行が
knacrbで始まります。この最終行は、次のことを示しています。-
全表スキャンが発生している可能性がある
-
この発行では、Interested Transaction List(ITL)が不十分な状態に対して何も実行されない
-
-
この警告メッセージがレポートされるのは、1つの文の実行時間が30秒を超える場合のみです。
長時間実行文で実行されているSQL文を判別できない場合がありますが、次のSQL文を発行すると、SQL Applyが作業中のデータベース・オブジェクトを識別できます。
SQL> SELECT SAS.SERVER_ID - > , SS.OWNER - > , SS.OBJECT_NAME - > , SS.STATISTIC_NAME - > , SS.VALUE - > FROM V$SEGMENT_STATISTICS SS - > , V$LOCK L - > , V$STREAMS_APPLY_SERVER SAS - > WHERE SAS.SERVER_ID = &SLAVE_ID - > AND L.SID = SAS.SID - > AND L.TYPE = 'TM' - > AND SS.OBJ# = L.ID1;
また、次のSQL文を発行すると、実行ごとに多数のディスク読取りを発生させたSQL文を識別できます。
SQL> SELECT SUBSTR(SQL_TEXT,1,40) - > , DISK_READS - > , EXECUTIONS - > , DISK_READS/EXECUTIONS - > , HASH_VALUE - > , ADDRESS - > FROM V$SQLAREA - > WHERE DISK_READS/GREATEST(EXECUTIONS,1) > 1 - > AND ROWNUM < 10 - > ORDER BY DISK_READS/GREATEST(EXECUTIONS,1) DESC;
すべての表にプライマリ・キーの制約を定義すると、列が自動的にNOT NULLとして定義されるので、この方法をお薦めしています。プライマリ・キーの制約を定義できない表については、該当する列で索引をNOT NULLと定義します。該当する列が表に存在しない場合は表を確認し、可能であればSQL Applyをスキップします。次の手順では、SCOTTスキーマのFTS表に対して発行されたすべてのDML文をスキップする方法を説明します。
-
SQL Applyを停止します。
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 Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered
ITLが不十分な状態のトラブルシューティング
Interested Transaction List(ITL)が不十分な状態は、SQL Applyインスタンスのアラート・ログでレポートされます。次に警告メッセージの例を示します。
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
リアルタイム適用の分析
上述の出力のメッセージは、SQL Applyプロセス(slavid)#17が過去30秒にわたって進捗がなかったことを示しています。適用プロセスにより発行されているSQL文を判別するには、次の問合せを発行します。
SQL> SELECT SA.SQL_TEXT -
> FROM V$SQLAREA SA -
> , V$SESSION S -
> , V$STREAMS_APPLY_SERVER SAS -
> WHERE SAS.SERVER_ID = &SLAVEID -
> AND S.SID = SAS.SID -
> 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 -
> FROM V$LOCK -
> 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は、スタンバイ・データベースのアラート・ログではレポートされません。したがって、ITLが不十分な状態になっているオブジェクトを判別するには、次の文を発行します。
SQL> SELECT OWNER, OBJECT_NAME, OBJECT_TYPE - > FROM V$SEGMENT_STATISTICS - > WHERE STATISTIC_NAME = 'ITL waits' - > AND VALUE > 0 - > ORDER BY VALUE;
この文では、インスタンスが前回起動された後にITLが不十分な状態になったことのあるデータベース・セグメントがすべてレポートされます。
注意:
このSQL文は、Oracle Data Guard環境のロジカル・スタンバイ・データベースに限定されません。任意のOracleデータベースに適用されます。
ITLが不十分な状態の解消
特定のデータベース・オブジェクトのINITRANSの整数を増やすには、最初にSQL Applyを停止する必要があります。
関連項目:
データベース・オブジェクトに割り当てられた各データ・ブロック内に割り当てられた同時トランザクション・エントリの初期数である、INITRANS整数指定の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
次の例に、appスキーマ内の表load_tab_1のINITRANSを増やすための手順を示します。
-
SQL Applyを停止します。
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 Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered.
また、スイッチオーバー時に新しいスタンバイ・データベースでエラーが発生しないように、プライマリ・データベースでデータベース・オブジェクトを変更することを検討してください。
A.10.4 フラッシュバック・トランザクションでのORA-1403エラーのトラブルシューティング
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)および表に対するアクティビティによっては、返される情報が広範囲で、返される情報を制限するVERSIONS BETWEEN構文の変更が必要な場合があります。返された情報から、レコードが最初に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;