30 トランザクションの管理

トランザクションの管理には、トランザクション優先度の設定やトランザクションの自動ロールバックなどのタスクが含まれます。

30.1 優先トランザクション

Oracle Databaseでは、トランザクションを自動的にロールバックし、この動作を制御するパラメータを導入できるようになりました。

行ロックは、表の単一行のロックです。INSERTUPDATEDELETEMERGEおよびSELECT ... FOR UPDATE文のいずれかで変更される行ごとに、トランザクションは行ロックを取得します。行ロックは、トランザクションがコミットされるかロールバックされるまで保持されます。場合によっては、トランザクションが長期間行ロックを保持します。たとえば、アプリケーションに例外が発生したため、そのアプリケーションによって一部の行が変更されますが、トランザクションのコミットや終了は行われません。従来、あるトランザクションが別のトランザクションによる行ロックで長時間ブロックされると、データベース管理者がALTER SYSTEM KILL SESSIONコマンドを使用し、手動でブロックされているトランザクションを終了する必要がありました。

Oracle Database 23ai以降では、データベースに、行ロックを保持しているトランザクションを自動的にロールバックできるタイミングとその対象を制御するパラメータが用意されています。Oracleデータベースによってトランザクションはロールバックされますが、セッションは存続します。アプリケーションで、ROLLBACK SQL文を発行することでトランザクションの自動ロールバックを承認する必要があります。

アプリケーションでは、トランザクションの優先度を指定できます。優先度の低いトランザクションが行ロックで優先度の高いトランザクションをブロックすると、Oracleデータベースによって優先度の低いトランザクションが自動的にロールバックされ、優先度の高いトランザクションが進行します。

データベース管理者は、優先度の低いトランザクションがロールバックされるまでの時間を構成できます。

トランザクションが行ロックを保持しており、トランザクションをブロックしていない場合、そのトランザクションはロールバックされません。

30.1.1 優先トランザクションの使用

トランザクションを自動的にロールバックするパラメータの設定については、この項で説明します。

30.1.1.1 トランザクション優先度の設定

Oracle Databaseでは、トランザクション優先度を制御するためのセッション設定が提供されます。

トランザクション優先度は、ALTER SESSIONコマンドを使用してセッション・レベルで設定します。トランザクション優先度を設定すると、そのセッションで作成されたすべてのトランザクションの優先度がそれと同じになります。

たとえば、現在のセッションでのすべてのトランザクションの優先度を高に設定するには、次のコマンドを使用します:
ALTER SESSION SET "txn_priority" = "HIGH";

txn_priorityの有効な値は、LOWMEDIUMおよびHIGHです。すべてのトランザクションには、デフォルトの優先度HIGHが設定されます。つまり、デフォルトではトランザクションはロールバックされません。トランザクション開始後にこのパラメータを変更した場合、現在のトランザクションの優先度は動的には変更されません。その次にそのセッションで作成されたトランザクションでは、更新された優先度が使用されます。

行ロックに対して優先度HIGHのトランザクションがブロックされている場合、Oracleデータベースは、行ロックを保持しているトランザクションがLOWまたはMEDIUM優先度である場合にのみ、そのトランザクションをロールバックできます。

行ロックに対して優先度MEDIUMのトランザクションがブロックされている場合、Oracleデータベースは、行ロックを保持しているトランザクションがLOW優先度である場合にのみ、そのトランザクションをロールバックできます。

行ロックに対して優先度LOWのトランザクションがブロックされている場合、Oracleデータベースは、その優先度に関係なく、行ロックを保持しているトランザクションのロールバックは行いません。

Oracleデータベースは、優先度HIGHのトランザクションをロールバックしません。

このパラメータは、トランザクションの重要度の理解に基づいてアプリケーションによって設定する必要があります。

関連トピック

30.1.1.2 システム・レベルの待機ターゲットの設定

Oracle Databaseには、行ロックを保持するトランザクションを自動的にロールバックするまでの時間を制御するシステム・パラメータが用意されています。

PRIORITY_TXNS_HIGH_WAIT_TARGETおよびPRIORITY_TXNS_MEDIUM_WAIT_TARGETにより、優先度HIGHおよびMEDIUMのトランザクションの、行ロックを保持している低優先度のトランザクションをデータベースでロールバックするまでの最大待ち時間(秒)を設定します。妨げとなるトランザクションがロールバックされますが、その対応するセッションは強制終了されず、存続し続けます。アプリケーションで、ORA-63300を捕捉しROLLBACK SQL文を発行することで、この自動ロールバックを承認する必要があります。ROLLBACKが発行されない場合は、セッション内のすべてのSQL文がORA-63302を受信し続けることになります。待機中トランザクションの優先度がLOWの場合は妨げとなるトランザクションがOracleデータベースによってロールバックされないため、低優先度の待機ターゲットのパラメータは提供されません。

優先トランザクション機能が有効になるのは、トランザクション優先度と待機ターゲットのパラメータが両方設定されている場合のみです。待機ターゲット時間なしでトランザクション優先度を設定しても、この機能は有効になりません。

ALTER SYSTEMコマンドを使用してパラメータを設定するには、待機時間の値とともにパラメータを指定します。この例では、優先度が中または低のトランザクションによって保持されている行ロックで、優先度HIGHのトランザクションが少なくとも15秒ブロックされている場合、データベースはブロックしている優先度の低いトランザクションを自動的にロールバックしようとします。
ALTER SYSTEM SET priority_txns_high_wait_target = 15;
優先度の高いトランザクションが優先度の低いトランザクションによってブロックされると、少なくとも指定した待機時間が経過してからブロックしているトランザクションがロールバックされます。ブロックされている複数のトランザクションが同じ行ロックを取得しようしている場合、待機時間は指定のターゲット時間より長くなる可能性があります。たとえば、デフォルトの優先度の高い待機ターゲットが20秒に設定されているとします。次のアクションが実行されます。
  1. 時間t1のトランザクション1(優先度の低いトランザクション)では、特定の行がロックされます。
  2. 10秒後の時間t2に、優先度が低いトランザクション2が、同じ行をロックして待機しようとします。
  3. 5秒後の時間t3に、優先度が高いトランザクション3が同じ行を更新しようとします。

コミットを実行するトランザクションがないと仮定すると、高優先度のトランザクションは、最初のトランザクションがロールバックされた後に少なくとも(時間t3から)20秒待機します。この後、トランザクション2はトランザクション3の前に行ロックをリクエストしたため、行ロックを取得します。したがって、トランザクション3は、トランザクション2が行ロックを取得してからさらに20秒間待機し、その後、トランザクション2がロールバックされます。そのため、待機ターゲットのパラメータ値は、高優先度の待機中トランザクションが行ロックを取得するまで待機する最大時間を意味するわけではありません。

30.1.1.3 自動ロールバックの承認

トランザクションの自動ロールバックは、そのセッションで後続のSQLの実行を続行できるようにするには、承認する必要があります。この承認は、トランザクションのロールバックを発行することで提供できます。

トランザクションが自動的にロールバックされると、アクティブ・セッションでの現在実行中のSQL、またはアイドル・セッションでの次のSQL文でORA-63300が発生します。後続のSQL文では、ロールバックが発行されるまでORA-63302がスローされます。したがって、アプリケーション・ロジックを、それら2つのエラー(ORA-63300ORA-63302)を両方捕捉してからロールバックを発行するように構造化する必要があります。

次の表に、ロールバックを承認するための使用可能な方法を示します:

表30-1 優先トランザクションに対する使用可能なロールバック方法

トランザクション・タイプ/クライアント SQL*PlusとSQLcl OCI JDBC
ローカルおよび分散トランザクション ROLLBACK SQL文を使用します OCITransRollback()ファンクション、またはROLLBACK SQL文のOCIStmtPrepareOCIStmtExecuteを使用します connection.rollback()を使用するか、connection.createStatement().execute("rollback")を使用してJDBCでロールバック文を実行します
XAトランザクション

DBMS_XA.XA_END()の後にDBMS_XA.XA_ROLLBACK()を実行します

XAトランザクションが一時停止されている場合は、DBMS_XA.XA_ROLLBACK()のみを実行します。

xaoend()の後にxaorollback()を実行します。

XAトランザクションが一時停止されている場合は、xaorollback()のみを実行します。

xa_resource.end()の後にxa_resource.rollback()を実行します。ここでのxa_resourceはタイプXAResourceです。

XAトランザクションが一時停止されている場合は、xa_resource.rollback()のみを実行します。

30.1.1.4 優先トランザクション・モードの設定

優先トランザクションでは、この機能を有効化の前に試せるように、2つのモードがサポートされています。

優先トランザクションのデフォルト・モードはROLLBACKです。このモードでは、PRIORITY_TXNS_HIGH_WAIT_TARGETPRIORITY_TXNS_MEDIUM_WAIT_TARGETが適切に構成されている場合は、行ロックを保持していることでより優先度の高いトランザクションの妨げになっているトランザクションが、自動的にロールバックされ、より優先度の高い、待機中のトランザクションが続行可能になります。

TRACKモードは、データベース管理者が優先トランザクション機能を試せるようにするために用意されています。TRACKモードでは、データベースによって、実際にトランザクションがロールバックされるのではなく、この機能でロールバックされたトランザクションの数が反映されるように、V$SYSSTAT (システムレベルの待機ターゲットの設定を参照)の統計が増分されます。アプリケーションでは、このモードを使用して正しい待機ターゲット値を調整してから、ROLLBACKモードに切り替えることができます。

優先トランザクション・モードをTRACKに設定するには、次のコマンドを使用します:
ALTER SYSTEM SET "priority_txns_mode"="TRACK";
優先トランザクション・モードをROLLBACKに設定するには、次のコマンドを使用します:
ALTER SYSTEM SET "priority_txns_mode"="ROLLBACK";

関連トピック

30.1.1.5 優先トランザクション・モードの使用によるシステムレベルの待機ターゲットの決定

優先トランザクション・モードを使用すると、システムレベルの待機ターゲットを決定するのに役立ちます。

PRIORITY_TXNS_HIGH_WAIT_TARGETおよびPRIORITY_TXNS_MEDIUM_WAIT_TARGETに適切な値を設定するのに役立つように、PRIORITY_TXNS_MODETRACKに設定し行ロック競合の待機イベント時間を監視できます。

通常のワークロードをTRACKモードで数時間(または必要に応じて)実行し、特定の優先度のトランザクションでの通常の行ロック待ち時間を監視します。たとえば、監視によりHIGH優先度のトランザクションでの通常の行ロック待ち時間が最長10秒であることがわかった場合は、PRIORITY_TXNS_HIGH_WAIT_TARGETを90秒より長い値に設定することをお薦めします。それにより、Oracle Databaseで、重要な操作がデータベース上で実行されている間に、行ロックを保持している正当なトランザクションがロールバックされることがなくなります。これらのパラメータについて適切な値を決定した後は、TRACKモードをオフにしROLLBACKモードに切り替え、これらの値を使用してシステムレベルの待機ターゲット・パラメータを構成し、優先トランザクションの使用を開始できます。

行ロックに競合がある場合、行ロック待機中のトランザクションは、共通の待機イベントenq: TX - row lock contentionで待機します。トランザクションのtxn_priorityパラメータとシステムのwait_targetパラメータの両方を設定することで優先トランザクションを有効にすると、待機中トランザクションが、その待機中トランザクションの優先度に基づいて待機イベントで待機するようになります。

表30-2 待機イベント

待機中トランザクションの優先度 待機イベント
HIGH enq:TX - row lock contention (HIGH pri)
MEDIUM enq: TX - row lock contention (MEDIUM pri)
LOW enq: TX - row lock contention (LOW pri)

次の例では、セッション(sid 204)に、行ロックを保持しているHIGH優先度のトランザクションがあります。同じ行ロックを待機中で異なる待機イベントで待機しているその他のトランザクションを、その優先度に基づいて確認できます。

SQL> SELECT TO_CHAR(xidusn) || '.' || TO_CHAR(xidslot) || '.' || TO_CHAR(xidsqn) AS transaction_id, sid, event, seconds_in_wait, blocking_session
     FROM   v$session, v$transaction
     WHERE  event LIKE '%enq%' AND v$session.saddr = v$transaction.ses_addr;

TRANSACTION_ID  SID     EVENT                              SECONDS_IN_WAIT BLOCKING_SESSION
--------------- ------ ----------------------------------- --------------- ----------------
2.17.1619          187 enq: TX - row lock (HIGH priority)              361              204
5.32.1557           51 enq: TX - row lock (LOW priority)               359              204

関連トピック

30.1.2 優先トランザクションの監視

固定ビューには、トランザクション優先度および待機ターゲットの監視に役立つ情報が表示されます。

V$TRANSACTIONには、トランザクションの監視に役立つ2つの列があります。TXN_PRIORITYはトランザクションの優先度を示し、PRIORITY_TXNS_WAIT_TARGETは秒単位で指定されたトランザクションの待機ターゲットを示します。

アラートは、トランザクションが終了するたびにアラート・ログに表示されます。例:

Transaction (sid: 203, serial: 39661, xid: 7.23.1161, txn_priority: "LOW") terminated by transaction (sid: 204, serial: 9266, xid: 13.15.3, txn_priority: "HIGH") because of the parameter "priority_txns_high_wait_target = 10"

スケジューラ・ジョブに対してはTXN_PRIORITYを設定できません。それがスケジューラ・ジョブに対して設定されている場合は、エラーORA-63303がスローされ、アラート・ログにおいてレポートされます。

関連トピック

30.1.2.1 ROLLBACKモードでの増分される統計

ROLLBACKモードの場合は、優先トランザクションについて特定の統計が増分されます。

次の統計は、ROLLBACKモードにおいてのみ増分されます。トランザクションがより優先度の高い待機中トランザクションのためにロールバックされるたびに、これらの統計が増分されます。
SQL> select name
     from   V$SYSSTAT
     where  name like '%txns rollback%';

NAME
---------------------------------------------------------------
txns rollback priority_txns_high_wait_target
txns rollback priority_txns_medium_wait_target
たとえば、HIGH優先度のトランザクションのためにMEDIUMまたはLOW優先度のトランザクションがロールバックされた場合は、txns rollback priority_txns_high_wait_targetが増分されます。
30.1.2.2 TRACKモードでの増分される統計

TRACKモードの場合は、優先トランザクションについて特定の統計が増分されます。

次の統計は、TRACKモードにおいてのみ増分されます。トランザクションがより優先度の高い待機中トランザクションのためにロールバックされるたびに、これらの統計が増分されます。
SQL> select name
     from   V$SYSSTAT
     where  name like '%txns track mode%';

NAME
----------------------------------------------------------------
txns track mode priority_txns_high_wait_target
txns track mode priority_txns_medium_wait_target
たとえば、HIGH優先度のトランザクションのためにMEDIUMまたはLOW優先度のトランザクションがロールバックされた場合は、txns track mode priority_txns_high_wait_targetが増分されます。

関連トピック

30.1.3 優先トランザクションの動作

分散トランザクションとXAトランザクションについて優先トランザクションの動作を理解する必要があります。

30.1.3.1 分散トランザクションの場合の優先トランザクションの動作

この項では、分散トランザクションの場合の優先トランザクションの動作を説明します。

参加者の優先度

分散トランザクションの場合、コーディネータ・ブランチの優先度は、すべての参加者(リモート・ブランチ)によって継承されます。つまり、分散トランザクションtxn1db1で始まり、db2に参加者txn2がある場合、txn2txn1TXN_PRIORITYパラメータ値を継承します。

承認の動作

分散トランザクションの自動ロールバックは、ローカル・トランザクションと同じ方法で承認されます。ただし、分散トランザクションの場合の自動ロールバック承認動作は、次の点でローカル・トランザクションと異なります:
  • 分散トランザクションのリモート・ブランチが自動的にロールバックされた場合、コーディネータ・セッションは、自動的にロールバックされたリモート・ブランチに対してコーディネータからSQL文が発行されるまで、正常に続行されます。その時点では、コーディネータにより、ロールバック承認を受信するまでORA-63300およびORA-63302がスローされます。
  • 分散トランザクションのコーディネータ(つまりローカル)ブランチが自動的にロールバックされた場合、そのコーディネータ・セッションでの新しいSQL文ではただちにORA-63300およびORA-63302がスローされます。この動作は、ローカル・トランザクションと同じです。
30.1.3.2 XAトランザクションの場合の動作

この項では、XAトランザクションの場合の優先トランザクションの動作を説明します。

XAトランザクションが自動的にロールバックされると、XAクライアントは、ロールバック承認を受信するまで、後続のXA文に対してXAER_RMFAILエラーを受け取ります。クライアントは、想定では、XAER_RMFAILを処理してからXA_END文およびXA_ROLLBACK文を実行することになっています。

TMSUSPENDフラグが設定されたXA_ENDが原因でXAトランザクションがすでに一時停止状態であった場合、承認にはXA_ROLLBACK文の実行のみが必要です。

30.1.4 優先トランザクションの制限事項

優先トランザクションの使用には制限事項があります。

スケジューラ・ジョブに対してはTXN_PRIORITYを設定できません。設定すると、エラーORA-63303がスローされます。エラーがアラート・ログに記録されます。

30.2 自動トランザクション隔離

Oracle Databaseは、システム・クラッシュを引き起こす可能性のあるトランザクションのリカバリを隔離(分離)します。これらのトランザクションは、行ロックが解放されるようにDBAが手動で解決する必要があります。

REDOアプリケーションについて

SGAのバッファ・キャッシュ内のデータベース・バッファは、最低使用頻度(LRU)アルゴリズムを使用して、必要な場合にのみディスクに書き込まれます。データベース・ライター・プロセスがこのアルゴリズムを使用してデータベース・バッファをデータファイルに書き込む方法により、データファイルには、コミットされていないトランザクションによって変更されたデータ・ブロックと、コミットされたトランザクションからの変更が欠落してるデータ・ブロックが含まれる場合があります。

クラッシュ・リカバリおよびインスタンス・リカバリ

クラッシュ・リカバリは、シングル・インスタンス・データベースのクラッシュ時またはOracle Real Application Clustersデータベースの全インスタンスのクラッシュ時に、障害からリカバリするために使用されます。インスタンス・リカバリとは、Oracle Real Application Clustersデータベース内の障害インスタンスを正常なインスタンスでリカバリすることです。

クラッシュス・リカバリとインスタンス・リカバリの目的は、デッド・インスタンスのキャッシュにあるデータ・ブロックの変更をリストアし、開いたままだったREDOスレッドを閉じることです。インスタンス・リカバリおよびクラッシュ・リカバリでは、オンラインREDOログ・ファイルおよび現在のオンライン・データファイルのみが使用されます。

インスタンス障害が発生すると、2つの潜在的な問題が発生する可能性があります:
  • トランザクションによって変更されたデータ・ブロックは、コミット時にデータファイルに書き込まれず、REDOログにのみ表示される場合があります。そのため、REDOログには、リカバリ中にデータベースに再適用する必要がある変更が含まれています。

  • ロールフォワード・フェーズの後、データファイルには、障害発生時にコミットされなかった変更が含まれている場合があります。これらのコミットされていない変更は、トランザクションの一貫性を保証するためにロールバックする必要があります。これらの変更は、障害発生前にデータファイルに保存されたか、ロールフォワード・フェーズ中に取り込まれたものです。

このジレンマを解決するために、Oracleでは通常、システム障害を正常にリカバリするために2つの異なるステップ、つまり、REDOログを使用したロールフォワード(キャッシュ・リカバリ)と、ロールバック・セグメントまたはUNDOセグメントを使用したロールバック(トランザクション・リカバリ)が使用されます。

キャッシュ・リカバリ

オンラインREDOログは、データ、索引、ロールバック・セグメントなど、データベース・バッファに対して行われたすべての変更(変更がコミットされたかコミットされていないかに関係なく)を記録するオペレーティング・システム・ファイルのセットです。Oracleブロックに対するすべての変更は、オンライン・ログに記録されます。

インスタンス障害またはディスク障害からのリカバリの最初のステップは、キャッシュ・リカバリまたはロールフォワードと呼ばれ、REDOログに記録されているすべての変更をデータファイルに再適用します。REDOログにはロールバック・データも記録されているため、ロールフォワードでは対応するUNDOセグメントも再生成されます。

ロールフォワードでは、必要に応じて多数のREDOログ・ファイルをたどり、データベースを後の時点まで進行させます。ロールフォワードには通常、オンラインREDOログ・ファイル(インスタンス・リカバリまたはメディア・リカバリ)が含まれ、アーカイブREDOログ・ファイル(メディア・リカバリのみ)が含まれる場合もあります。

ロールフォワード後のデータ・ブロックには、コミットされたすべての変更が含まれます。また、障害発生前にデータファイルに保存されていたか、REDOログに記録されてキャッシュ・リカバリ時に取り込まれた、コミットされていない変更も含まれることがあります。

トランザクション・リカバリ

UNDO表領域(自動UNDO管理モード)には、データベースに対する変更の前のイメージを記録するUNDOセグメントが含まれます。データベース・リカバリでは、UNDOセグメント内のUNDOブロックは、以前にロール・フォワード・フェーズによって適用されたコミットされていないトランザクションの影響をロールバックします。

ロールフォワード後は、コミットされなかった変更を取り消す必要があります。UNDOブロックの適用により、クラッシュ前に書き込まれたか、キャッシュ・リカバリ中にREDOアプリケーションによって取り込まれたデータ・ブロック内の、コミットされていない変更がロールバックされます。データベース内のコミットされていないトランザクションをロールバックするこのプロセスは、トランザクション・リカバリと呼ばれます。

次の図は、任意のタイプのシステム障害からのリカバリに必要な2つのステップである、ロールフォワードとロールバックを示しています。

図30-1 ロールフォワードとロールバック

図30-1の説明が続きます
「図30-1 ロールフォワードとロールバック」の説明

トランザクション・リカバリ中の障害

次の理由により、トランザクション・リカバリが失敗する可能性があります。
  • データベース・ブロックの物理データ破損(ORA-01578、ORA-28304)
  • 論理データ破損(ORA-00600)
  • メモリー破損(ORA-00602、ORA-07445)
  • 状態の破損(ORA-00600)

トランザクション・リカバリ中の障害は、データベース・インスタンス全体に対してリカバリ不能となり、プラガブル・データベースを含むコンテナ・データベース(CDB)全体を停止させる可能性があります。システム内のすべてのトランザクションをリカバリできないと、リカバリされていないトランザクションによって行ロックが長期間保持されることになります。これは重要なビジネス操作に大きく影響します。

Oracle Database 23ai以降では、リカバリに失敗したトランザクションは隔離され、DBAがその問題を解決するまでリカバリされません。これによりデータベースの可用性が向上します。データベース開発者は隔離されたトランザクションについて通知を受け、隔離されたトランザクションによって保持されている行ロックを解放できるように、ただちにアクションを実行する必要があります。

トランザクション隔離は、データベース内の永続データ・ディクショナリ表に保持されます。したがって、データベース内の任意のRACインスタンスから隔離を管理できます。

DML操作が隔離されたトランザクションによってロックされた行にアクセスしようとすると、行がロックされている間はDML操作を実行できないため、エラーORA-60451が発生します。

隔離されたトランザクションとレプリケーション

Oracle Data Guardは論理レプリケーションを使用するため、Oracle Data Guardの使用時に隔離メタデータはスタンバイ・サーバーにレプリケートされません。したがって、スタンバイ・サーバーのトランザクション隔離ビュー(DBA_QUARANTINED_TRANSACTIONSなど)の内容は、プライマリ・サーバーのエントリとは異なる場合があります。

Active Data Guard (ADG)で実行している場合、レプリケーションは物理です。つまり、トランザクション検疫機能では、停止したトランザクションと検疫のカタログ表現の両方がスタンバイ・データベースにレプリケートされます。

30.2.1 隔離されたトランザクションの監視

アラートおよびデータ・ディクショナリ・ビューは、隔離されたトランザクションのデータベース開発者に警告します。

Oracle Databaseは、隔離されたトランザクションのDBAに、次のようないくつかの方法で警告します。
  • ALERT_QUE - トランザクションの隔離アラートが永続アラート・キューSYS.ALERT_QUEに送信されます。このアラートは、データ・ディクショナリ・ビューDBA_OUTSTANDING_ALERTSおよびDBA_ALERT_HISTORYの他、Enterprise Manager Cloud ControlおよびAWRレポートに自動的に表示されます。
  • 注意ログ - Oracle 21cで導入された注意ログには、重要で可視性の高いデータベース・イベントに関する情報が含まれています。Oracle Database 23ai以降では、トランザクション隔離情報も含まれています。
  • アラート・ログ - 内部エラーのインシデントが生成され、アラート・ログにトレースされます。DBAは、隔離インシデントをV$DIAG_ALERT_EXTで監視できます。

DBA_QUARANTINED_TRANSACTIONSおよびCDB_QUARANTINED_TRANSACTIONSという名前のビューは、アクティブな隔離されたトランザクションをすべてモニターします。これらのビューには、隔離の解決に必要な情報がすべて表示されます。

表30-3 DBA_QUARANTINED_TRANSACTIONSビューの列

データ型 Nullかどうか 説明
USN NUMBER Not Null 隔離されたトランザクションのUNDOセグメント番号。
SLT NUMBER Not Null 隔離されたトランザクションのスロット番号。
SQN NUMBER Not Null 隔離されたトランザクションの順序番号。
UNDO_TSN NUMBER   隔離されたトランザクションのUNDO表領域番号。
TXN_START_SCN NUMBER   隔離されたトランザクションの開始SCN。
INCIDENT_TIME VARCHAR2(64)   インシデントが発生したタイムスタンプを識別します。
REASON VARCHAR2(256)   このトランザクションのリカバリに失敗した理由。
TRACE_FILE_NAME VARCHAR2(4096)   このトランザクションのリカバリ失敗の理由および診断情報を含むトレース・ファイル名。
UBA_RDBA NUMBER   ロールバックに適用されている現在のUNDOブロックのブロック番号。
UBA_SQN NUMBER   UNDOブロック順序番号。
UBA_RECORD_NUMBER NUMBER   UNDOレコード番号。
UNDO_RECORD_OBJN NUMBER   オブジェクトのディクショナリ・オブジェクト番号(OBJN)。
UNDO_RECORD_OBJD NUMBER   オブジェクトを含むセグメントのディクショナリ・オブジェクト番号(OBJD)。
PREV_UNDO_BLOCK_DBA NUMBER   ロールバックに使用された以前のUNDOブロック・アドレス。
DATA_BLOCK_TSN NUMBER   オブジェクトの表領域ID。

ビューDBA_QUARANTINED_TRANSACTIONSGV$TRANSACTIONおよびGV$FAST_START_TRANSACTIONSと結合して、トランザクションの詳細およびそのリカバリの進行状況を取得できます。固定ビューは永続的ではないため、GV$TRANSACTIONはデータベース・インスタンスの再起動時にその情報を失うことに注意してください。データベース・インスタンスの再起動後にトランザクション・リカバリが開始されるため、GV$TRANSACTIONは、データベースの再起動後もアクティブなトランザクション・リカバリの進行状況を示します。

30.2.2 隔離されたトランザクションの解決

データベース開発者は、トランザクション隔離が生成されたときにアラートを受け取ります。隔離は、行ロックが長時間保持されないように、迅速に監視して解決する必要があります。

隔離は、DBA_QUARANTINED_TRANSACTIONSを使用して監視できます。ビューのREASON列には、トランザクションが隔離された理由が表示されます。例:
SQL> select usn, slt, sqn, reason, undo_record_objn
     from   dba_quarantined_transactions;

   USN    SLT    SQN                 REASON    UNDO_RECORD_OBJN
------ ------ ------ ---------------------- -------------------
     6     18     10    ORA-00600[ktubko_1]               73646
     7     20     13              ORA-28304               73650

トランザクション隔離の理由を特定した後は(前述の例ではORA-00600[ktubko_1]ORA-28304)、トランザクション隔離の様々な原因を解決する方法について詳細な手順が記載されている「Primary MOS note for Automatic Transaction Quarantine (Doc ID 3005962.1)」を参照してください。

30.2.3 隔離されたトランザクションの削除

隔離に関連する問題が修正されたら、隔離を削除する必要があります。

トランザクション隔離に関する問題が修正されるまで、トランザクション・リカバリを再試行できません。したがって、是正措置により隔離を修正した後、隔離されたトランザクションに対してトランザクション・リカバリを再開するには、隔離を手動で削除する必要があります。次のDDL構文を使用して、隔離を削除できます。
ALTER DATABASE DROP TRANSACTION QUARANTINE
<xid_undo_seg_no> <xid_slot_no> <xid_sequence_no>;
ここで:
  • xid_undo_seg_noは、隔離されたトランザクションのUNDOセグメント番号です(ビューDBA_QUARANTINED_TRANSACTIONSUSN列)
  • xid_slot_noは、隔離されたトランザクションのスロット番号です(ビューDBA_QUARANTINED_TRANSACTIONSSLT列)
  • xid_sequence_noは、隔離されたトランザクションの順序番号です(ビューDBA_QUARANTINED_TRANSACTIONSSQN列)
たとえば、xid 8.20.275の隔離を削除するには、次のコマンドを使用します。
ALTER DATABASE DROP TRANSACTION QUARANTINE 8 20 275;

30.2.4 トランザクション隔離のエスカレーション

PDBのトランザクション隔離制限(デフォルトは3)に達すると、データベース開発者がその問題を解決できるように、すべてのRACインスタンスでそれが自動的に停止されます。CDB内の他のPDBは影響を受けません。

トランザクション隔離は、メモリー、データ、状態の破損などの障害が単一のトランザクションに限定される場合に役立つように設計されています。つまり、リカバリに失敗した非アクティブなトランザクションは隔離され、非アクティブな他のトランザクションはリカバリ可能であり、PDBやCDBを停止する必要はありません。

複数のブロックの物理的破損、PDB SGAの破損、または内部エラーが原因の論理的データ破損など、複数のトランザクションにわたる障害、またはPDB全体にわたる障害が発生した場合、失敗した非アクティブなトランザクションを隔離しても、リカバリが役立たない場合があります。これは、これらの障害の根本原因が同じかどうかで異なります。非アクティブな他のトランザクションのリカバリでそれと同じ問題が発生する可能性があるためです。いくつかのトランザクションを隔離した後でも、システムは一貫性のない状態で動作し続けます。障害が論理データ破損によるものである場合、時間の経過とともに分散するため、危険になる可能性があります。これを回避するために、3のトランザクションの隔離制限があります。その後、隔離がデータベース・レベルにエスカレートされ、PDBに対してアーカイブ・ロギングが有効になっていてPDBを停止できる場合は、shutdown abortを使用してPDBを終了します。PDBのトランザクション・リカバリは自動的に無効化されるため、データベース開発者は次回のPDB起動時に問題を修正できます。

エスカレーションが発生したら、次のステップを実行します:
  1. PDBをオープンします。
  2. ビューDBA_QUARANTINED_TRANSACTIONSを問い合せて、隔離されたトランザクションについて情報を取得します。
  3. データベース内の隔離されたトランザクションごとに、トランザクション隔離の原因を解決(「隔離されたトランザクションの解決」)してから、トランザクション隔離を削除します(「隔離されたトランザクションの削除」を参照)。
  4. PDBに対してトランザクション・リカバリを有効にします。
トランザクション・リカバリを有効にするには、次のコマンドを使用します。
ALTER SYSTEM SET TRANSACTION_RECOVERY=ENABLED sid='*';
SCOPE句は必要ありません。SCOPEのデフォルト値は次のとおりです。
  • PDBの場合、デフォルト値はSCOPE=BOTHです。
  • CDB$ROOTの場合、データベースの起動にサーバー・パラメータ・ファイルが使用されていた場合、デフォルトはSCOPE=BOTHです。データベースの起動にパラメータ・ファイルを使用した場合、デフォルトはSCOPE=MEMORYです。
SCOPEのこれらのデフォルト値は、自動トランザクション検疫のトランザクション・リカバリを再度有効にします。

トランザクション隔離がPDBにエスカレートされたかどうかを判断するために、隔離されたトランザクションの監視で説明されているすべてのアラート・チャネル(SYS.ALERT_QUE、注意ログおよびアラート・ログ)にアラートが公開されます。