현재 많은 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 애플리케이션을 개발하는 사람들이 매우 오래 실행되는 트랜잭션 (즉, 한 번의 트랜잭션에서 파이프 라인을 실행할 위치를 파악하기 위해 며칠 또는 몇 주일이 소요될 수있는 트랜잭션)을 갖도록 설계되었습니다. ). 일괄 처리 프로세스는 논리적으로 새 트랜잭션을 만드는 것과 같은 새 작업 영역을 만들고 원하는 경우 언제든지 커밋하면서 해당 작업 영역에서 원하는대로 변경합니다. 별도의 세션에서는 배치 프로세스의 작업 공간에 들어갈 때까지 커밋 된 변경 사항이 표시되지 않습니다. 배치 프로세스가 완료되면 작업 영역을 트랜잭션을 커밋하는 것과 동일한 실제 작업 영역으로 다시 병합 할 수 있습니다.
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오라클 이 가지고 있지 않은 것은 커밋되지 않은 읽기 모드 입니다. 즉, 다른 트랜잭션에서 커밋되지 않은 데이터를 쿼리 할 수 없습니다.
장기 실행 트랜잭션에서 정보를 가져 오는 방법이 있습니다. 지금까지 언급되지 않은 방법은 자율 트랜잭션입니다 (주의해서 사용해야 함)
직접적인 방법은 없습니다. 다른 답변에서 언급 한대로 로그를 구문 분석하거나 대체 방법을 사용하여 장기 실행 프로세스에서 발생하는 상황을 확인해야합니다.
개인적으로이 기능을 활성화하기 위해 자율 트랜잭션을 사용하는 것이 좋습니다. 트랜잭션 자체가 아니라 진행 상황을 알려주는 로깅 메커니즘입니다. 예를 들어, VARCHAR2를 다른 테이블에 쓰는 PROCEDURE LONG_ACTION 호출 PROCEDURE WRITE_LOG_ENTRY (자율 트랜잭션으로 정의)가있을 수 있습니다. 자율적 트랜잭션은 (논리적 관점에서, 현재의 트랜잭션에 영향을 줄 수 있으므로) 현재 트랜잭션을 방해하지 않으므로 현재 트랜잭션의 COMMIT 또는 ROLLBACK에 관계없이 로깅 항목을 통해 진행중인 작업을 확인할 수 있습니다. 즉, 하나의 대규모 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의 설명을 참조하십시오.
(마지막으로, 나는 그것을 언급하지 않았기 때문에 : 자율적 인 거래를 조심하십시오. 구현하기 전에 완전히 이해하고 "그냥 이유"로 사용하지 마십시오. 그들은 백만 가지 방식으로 잘못 사용될 수 있습니다 (예 : 트리거에서 뮤트 오류를 피하십시오.) 가능하면 항상 대안을 찾는 것이 가장 좋습니다. 그렇지 않으면주의해서 진행하십시오. 성능 문제), 그러나 결과를 모른 채 다른 용도로 적용하기 위해 서두르지 마십시오.)