커밋 수행 전 후의 블록 변경 내용 확인 테스트

• 트랜잭션과 관련된 블록 클래스 : 데이터 블록, 언두 블록 헤더, 언두 블록

테스트 초기화

SQL> create table undo_layer_t5(c1 number, c2 varchar2(10), c3 char(20));
SQL> insert into undo_layer_t5 values(1, 'A', 'a');
SQL> insert into undo_layer_t5 values(2, 'B', 'b');
SQL> commit;

테스트 1단계 - 커밋 수행 전 데이터 블록 덤프

kjwon:ora10g:KJWON >
  l  select sid from v$mystat where rownum = 1;

       SID
----------
       148

kjwon:ora10g:KJWON > 
  l   select rowid, substr(rowid, 1, 15), c1 from undo_layer_t5;

ROWID              SUBSTR(ROWID,1,15)                     C1    
------------------ ------------------------------ ----------    
AAAM1CAAGAAAAANAAA AAAM1CAAGAAAAAN                         1    
AAAM1CAAGAAAAANAAB AAAM1CAAGAAAAAN                         2    

kjwon:ora10g:KJWON >
  l  @rowid2fb
 INPUT ROWID  : AAAM1CAAGAAAAANAAA

    OBJECT    FILE_NO   BLOCK_NO ROW_NUMBER
---------- ---------- ---------- ----------
     52546          6         13          0

kjwon:ora10g:KJWON >
  l  alter system dump datafile 6 block 13;
  
kjwon:ora10g:KJWON >
  l  delete from undo_layer_t5;
  
kjwon:ora10g:KJWON >
  l  alter system dump datafile 6 block 13;

테스트 2단계 - 커밋 수행 전 언두 헤더 블록 덤프

kjwon:ora10g:KJWON >
  l  select xidusn, xidslot, xidsqn
  2  from v$transaction
  3  where addr = (select taddr from v$session where sid = 148);

    XIDUSN    XIDSLOT     XIDSQN
---------- ---------- ----------
         7         39        313

kjwon:ora10g:KJWON >
  l  alter system dump undo header '_SYSSMU7$';         

테스트 3단계 - 커밋 수행 전 언두 블록 덤프

kjwon:ora10g:KJWON >
  l  alter system dump undo block '_SYSSMU7$' xid 7 39 313;        

테스트 4단계 - 커밋 수행 후 언두 헤더 블록 덤프

kjwon:ora10g:KJWON >
  l  commit;
  
kjwon:ora10g:KJWON >
  l  alter system dump datafile 6 block 13;     

테스트 5단계 - 커밋 수행 후 언두 헤더 블록 덤프

kjwon:ora10g:KJWON >
  l  alter system dump undo header '_SYSSMU7$'; 

테스트 6단계 - 커밋 수행 후 언두 헤더 블록 덤프

kjwon:ora10g:KJWON >
  l  alter system dump undo block '_SYSSMU7$' xid 7 39 313;      

커밋 전 데이터 블록 덤프 결과 분석

• Xid 분석(0x0007.027.00000139)
  • 트랜잭션을 시작하기 위해서는 언두 바인딩 절차가 필요
  • 언두 바인딩을 완료된 후 XID(transaction identifier)를 할당 받는다
  • XID는 크게 3개의 필드(Usn#, Slot#, Wrap#)로 구성
  • 위 덤프중 ltl 0x02번의 Xid를 보면 Usn#=7, Slot#=0x27, Wrap#=0x139 인 것을 확인 할 수 있다.
  • 7번 언두(_SYSSMU7$)에 롤백을 위한 정보 저장,
  • 39번째(0x27) 트랜잭션 슬롯에 트랜잭션과 관련된 정보를 저장.
  • 해당 트랜잭션 슬롯은 313번(0x139) 재사용되었다.(Wrap#는 재사용 될 때마다 1씩 증가)

• Uba 분석(0x008000bd.0107.2f)
  • 언두 블럭 내에 변경된 주소
  • 3개의 필드(udba(언두블록의 DBA), seq(시퀀스 번호), slot(언두블록 내의 레코드 번호))로 구성
  • 데이터 블록 내의 Itl 에서 나타내고 있는 Ubs는 트랜잭션에 의해 처음으로 사용된 언두 블록의 주소를 나타낸다.

• Flag 분석(

  ---

  )
  • 트랜잭션이 완료되지 않았으므로, Flag에는 아무런 정보도 가지고 있지 않다.

• Lck 분석(2)
  • 트랜잭션과 관련된 레코드의 수
  • 해당 트랜잭션은 2개의 레코드에 대해서 로우 레벨 락을 설정한 상태

• Scn/Fsc 분석(fsc 0x0036.00000000)
  • Scn은 System Change Number를 나타내며, Fsc는 Free Space Credit를 나타낸다.
  • Fsc는 해당 트랜잭션으로 인해, 데이터 블록 내에 발생되는 프리 공간을 의미
  • 현재 트랜잭션이 진행 중으로 Scn이 할당되지 않았으며, 해당 트랜잭션으로 인해 54bytes(0x0036)의 Free 공간이 발생한 것을 알 수 있다.

커밋 후 데이터 블록 덤프 결과 분석

• Scn 분석(0x0000.0009e8a9)
  • 커밋을 수행하여 트랜잭션을 완료하였으므로, Scn이 할당되었고 해당 Scn이 데이터 블록 내에 저장
  • Scn은 2개의 필드(Scn Wrap#: 2bytes, Scn Base#: 4bytes)로 구성
  • 트랜잭션이 완료하여 Scn을 할당 받을 때 마다, Scn Base#가 증가하며, Scn Base에 해당하는 4Bytes를 다 사용하면, Scn Wrap#가 1 증가.
  • 현재 할당된 Scn은 Wrap#=0x0000, Base#=0x0009e8a9

• Xid 분석(0x0007.027.00000139)
  • 커밋 전과 동일, 향후 언두 정보를 이용한 읽기 일관성 및 블록 클린아웃 시에 사용

• Uba 분석(0x008000bd.0107.2f)
  • 커밋 전과 동일

• Flag 분석(--U-)
  • 트랜잭션이 완료되어 Flag가 U로 변경
  • U Flag가 의미하는 것은 Upper bound Commit이라는 의미
  • Upper bound Commit은 오라클에서 커밋 시에 사용하는 Fast Commit 방식과 관련.(3.6절에서 설명)
  • Fast Commit : 트랜잭션이 종료하면, 언두 헤더 블록내의 트랜잭션 슬롯의 state를 변경하고 트랜잭션과 관련된
    데이터 블록중에 버퍼 캐시에 상주에 있는 블록에 대해서만 Itl의 Flag 필드를 U로 변경하고 Scn/Fsc 필드 중에서
    Scn Base# 부분만을 설정한 후에 커밋을 완료하는 방식.
  • Fast Commit 방식에 의해 데이터 블록의 내용이 변경되는(Cleanout) 것을 fast block cleanout.
    (커밋 수행을 최대한 빨리 끝내기 위해)
  • U Flag는 해당 블록에 대한 delayed block cleanout 이 발생하면 'C'로 변경

• Lck 분석(2)
  • 트랜잭션과 관련되 레코드의 수
  • fast block cleanout시에는 해당 내용을 변경하지 않는다.
  • delayed block cleanout이 발생하는 시점에 0으로 초기화.

• Scn/Fsc 분석(0x0036.0009e8a9)
  • fast block cleanout 시에는 Scn Base#만을 Scn/Fsc 필드에 변경.
  • Scn Wrap#는 delayed block cleanout이 발생하는 시점에 Itl의 Xid 정보를 이용하여
    해당 트랜잭션과 관련되었던 언두 해더 블록의 트랜잭션 슬롯의 정보를 이용하여 변경.

커밋 전 언두 헤더 블록 덤프 결과 분석

• index(0x27) 및 state(10) 분석
  • TSN TBL(Transaction Table)에서 관리되는 트랜잭션 슬롯 정보중에서 index 컬럼은 슬롯번호, state 컬럼은 트랜잭션의 상태를 나타낸다.
  • Active 한 태랜잭션에 대한 정보를 가지고 있는 슬롯의 state는 10, 트랜잭션이 종료한 경우 9.
  • 현재 0x27 슬롯을 사용하고 있으며, 데이터 블록의 itl에서 관리되는 Xid(0x0007.027.00000139)의 두번째 필드와 동일.

• wrap# 분석(0x0139)
  • 트랜잭션 슬롯이 재사용될 때 마다 증가.
  • 데이터 블록의 itl에서 관리되는 Xid(0x0007.027.00000139)의 세번째 필드와 동일.

• dba 분석(0x008000bd)
  • 해당 되는 트랜잭션의 이전 이미지를 저장한 마지막 언두 블럭의 주소
  • 데이터 블록의 itl에서 관리하는 Uba(0x008000bd.0107.2f)의 첫번째 필드 값과 동일한 값을 나타내므로
    해당 트랜잭션을 위해 한 개의 언두 블록이 사용되었음을 알 수 있다.
    {note}

커밋 후 언두 헤더 블록 덤프 결과 분석

• state 분석(9)
  • 커밋이 수행되면 9로 변경.

• scn 분석(0x0000.0009e8a9)
  • 커밋이 수행되면 scn이 할당되고 그 값이 해당 트랜잭션 슬롯의 scn 컬럼에서 관리된다.
  • 커밋 시점에 해당 데이터 블록의 scn과 트랜잭션 슬롯의 scn은 동일한 값을 가지게 된다.

커밋 전 언두 블록 덤프 결과 분석

• Xid 분석(0x0007.027.00000139)
  • 데이터 블록의 Itl에서 관리되는 Xid와 언두 헤더 블록의 트랜잭션 슬롯에서 관리되는 Xid와 동일한 값.
  • 3개의 블록 클래스간의 연결고리는 Xid.

• cnt 분석(0x2f)
  • 해당 언두 블록에 존재하는 언두 레코드의 개수
  • 현재 47개(0x2f)의 언두 레코드를 저장하고 있다.

• irb 분석(0x2f)
  • 해당 언두 블록에서 마지막으로 저장된 언두 레코드의 번호
  • 47번째 언두 레코드가 마지막으로 저장된 언두 레코드

• objd 분석(52546)
  • 언두 레코드와 관련된 오브젝트 번호. (DBA_OBJECTS.OBJECT_ID)

• rci (0x2e, 0x00) 분석
  • 이전 언두 레코드의 번호.
  • ROLLBACK을 수행하기 위해서는 마지막 언두 레코드부터 시작해서 최초의 언두 레코드까지 적용해야만 완료되므로,
    항상 현재의 언두 레코드는 이전 언두 레코드 번호를 가진다.

• rdba(0x00000000) 분석
  • ROLLBACK시 다음에 적용해야 하는 언두 블록의 dba.
  • rci 0x00 값을 가지는 언두 레코드의 rdba 값이 설정이 되어있다면, 해당 트랜잭션은 2개 이상의 언두 블록을 사용.
  • rdba 값이 0x00000000인 경우에는 해당 트랜잭션은 1개의 언두 블록을 사용한 것.

커밋 후 언두 블록 덤프 결과 분석

• 커밋 수행 후에 언두 블록에 대한 변경사항은 없다.

문서에 대하여

• 최초작성자 : 김종원
• 최초작성일 : 2011년 06월 17일
• 이 문서는 오라클클럽 코어 오라클 데이터베이스 스터디 모임에서 작성하였습니다.
• {*}이 문서의 내용은 (주)엑셈에서 출간한 Transaction Internals in Oracle 10gR2'를 참고하였습니다.*