Oracle-特定のテーブルに対するコミットされていない変更を表示する方法はありますか？

現在、多くのDMLステートメントを実行するバッチプロセスを介してデバッグしていますが、すぐにはコミットしません。トランザクションがコミットされていないときに、別のセッションからの「保留中」の変更を表示できると便利です。これは可能ですか？

例：

Insert into table myTable (col1, col2) values ("col1", "col2");

--Somehow view the pending transaction maybe by system view?....

...other DML statements....

commit;

バッチ処理の詳細と、コミットされていない変更を表示しようとする理由に応じて、いくつかの異なるアプローチがあります。

1）Oracle Workspace Managerは、Spatialアプリケーションの開発者が非常に長時間実行されるトランザクション（つまり、1つのトランザクションでパイプラインを実行する場所を数日または数週間必要とするトランザクション）に相当するように設計されたツールです）。バッチプロセスは、新しいワークスペースを作成し（論理的には新しいトランザクションを作成するようなものです）、必要に応じてコミットしながらそのワークスペースで必要な変更を加えることができます。別のセッションでは、バッチプロセスのワークスペースに入るまで、コミットされた変更は表示されません。バッチプロセスが完了すると、そのワークスペースをマージして、トランザクションをコミットするのと同等のライブワークスペースに戻すことができます。

2）DBMS_XAパッケージを使用して、あるセッションから別のセッションにトランザクションを「ハンドオフ」し、あるセッションが別のセッションによって開始されたトランザクションに接続できるようにすることができます。これは使用するのにかなりわかりにくいパッケージですが、最近PL / SQL Challengeで使用する良い例がありました（アクセスするには無料のアカウントが必要な場合があります）。

3）実際のデータを表示するのではなく、単にバッチプロセスのステータスを表示しようとしている場合、バッチプロセスは自律トランザクションを使用してログ情報を書き込むことができます。または、DBMS_APPLICATION_INFOパッケージを使用して、アプリケーションでV $ SESSIONまたはV $ SESSION_LONGOPSのさまざまな属性を更新し、別のセッションからの負荷の状態を監視できるようにすることもできます。

編集：これは質問が明確になる前に書かれた

フラッシュバッククエリを使用して、独自のコミットされていないデータなしでテーブルを表示できます。

考慮してください：

SQL> CREATE TABLE my_table
  2  AS SELECT ROWNUM ID FROM dual CONNECT BY LEVEL <= 5;

Table created

SQL> INSERT INTO my_table VALUES (6);

1 row inserted

私のトランザクションを持つテーブルと他の人が見たテーブルの違いを見るために、私は発行することができます：

SQL> SELECT * FROM my_table
  2  MINUS
  3  SELECT * FROM my_table AS OF TIMESTAMP (systimestamp);

        ID
----------
         6

はい-LogMinerはこれを実行できます。実際、コミットされたトランザクションのみが必要な場合は、出力を特にフィルタリングする必要があります！そして、そこにあるTABLE_NAMEでV$LOGMINER_CONTENTSそれはあなたが単一のテーブルにどのように見えるかです。

Oracleにないのは、読み取り非コミット分離モードです。つまり、別のトランザクションでコミットされていないデータをクエリすることはできません。

長時間実行されているトランザクションから情報を取得する方法があります-今のところ言及されていないのは自律的なトランザクションです（注意して使用する必要があります）

直接的な方法はありません。（別の回答で述べたように）ログを解析するか、代替方法を使用して、長時間実行プロセスで何が起こっているかを確認する必要があります。

個人的には、自律型トランザクションを使用してこの機能を有効にすることをお勧めします。トランザクション自体ではなく、何が起こっているかを知らせるロギングメカニズムとして。たとえば、PROCEDURE LONG_ACTIONでPROCEDURE WRITE_LOG_ENTRY（自律型トランザクションとして定義）を呼び出して、VARCHAR2を別のテーブルに書き込むことができます。自律型トランザクションは現在のトランザクションを妨害しません（論理的な観点から、パフォーマンスへの潜在的な影響に注意してください）。したがって、現在のトランザクションのCOMMITまたはROLLBACKに関係なく、ロギングエントリを介して何が起こっているかを確認できます。つまり、1つの大規模なDMLステートメントでそれを行うことができます。ループを使用する必要があります。

考慮してください：

TABLE LOG_ENTRIES defined as
    activity_date  date,
    log_entry varchar2(2000)

TABLE BIG_JOB (definition doesn't really matter)

PROCEDURE WRITE_LOG_ENTRY
                        ( str VARCHAR2 )
IS
    PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
    INSERT INTO LOG_ENTRIES VALUES ( SYSDATE, str );
    COMMIT;
END;

PROCEDURE LONG_ACTION IS
    c NUMBER;
BEGIN
    FOR r IN ( SELECT * FROM BIG_JOB )
    LOOP
       c := c + 1;
       UPDATE BIG_JOB z
          SET fld = hairy_calculation
        WHERE z.rowid = r.rowid;
       IF MOD(c,500) = 0 THEN
           WRITE_LOG_ENTRY ( c || ' rows processed.' );
       END IF;
    END LOOP;
    COMMIT;
END;

上記を考慮すると、長いアクションの成功に関係なく、処理された500行ごとにログエントリが取得されます。動作中にデータの正確な複製が必要な場合は、複製テーブルを作成し、データを複製するプロシージャを呼び出すことをお勧めします（プロシージャは自律型トランザクションです）。その後、データを事後的に破棄します。（複製の必要はありません。）

さらに、これがデバッグを目的とする場合は、テストを行ったときにそのようなロギングの必要性を削除するか、大幅に減らすことをお勧めします。そして、いつものように、自分のシステムでテスト、テスト、テストを行い、物事がどのように機能するかを検証します。（ロギングがパフォーマンスに大きく影響する良い例については、Niallのコメントを参照してください。）

（最後に、前に言及しなかったため：自律型トランザクションに注意してください。実装する前にそれらを完全に理解し、「理由だけで」使用しないでください。トリガーでのmutateエラーを回避するため、可能な場合は常に代替手段を見つけることが最善です。もしできない場合は、注意して続行してください。パフォーマンスの問題）、しかし、結果を知らずに急いで他の用途に適用しないでください。）

10gでは使用できませんが、DBMS_XAはトランザクションが複数のセッションを通過できるようにすることができます。これを使用すると、2番目のセッションでトランザクションで何が起こっているかを確認できます。

ここでの他の情報に加えて、コミットされていないトランザクションに関する情報を送信する追加の方法は、電子メールを送信するか、テキストファイルに書き込むことです。