행위

"오라클 트랜잭션,블럭,언두,리두 덤프 테스트"의 두 판 사이의 차이

DB CAFE

(qm)
 
(→‎현재 트랜잭션 조회)
 
(같은 사용자의 중간 판 하나는 보이지 않습니다)
9번째 줄: 9번째 줄:
  
 
=== 테이블 생성 및 데이터 입력 ===   
 
=== 테이블 생성 및 데이터 입력 ===   
 +
<source lang=sql>
 +
 
SYS>create table test(id number);
 
SYS>create table test(id number);
 
Table created.
 
Table created.
25번째 줄: 27번째 줄:
  
 
=== 현재 트랜잭션 조회 ===
 
=== 현재 트랜잭션 조회 ===
 +
<source lang=sql>
 +
 
SYS>select xidusn, xidslot, xidsqn from v$transaction
 
SYS>select xidusn, xidslot, xidsqn from v$transaction
 
where addr =(select taddr from v$session where sid=149);
 
where addr =(select taddr from v$session where sid=149);

2024년 6월 26일 (수) 19:23 기준 최신판

thumb_up 추천메뉴 바로가기

1 트랜잭션,블럭,언두,리두 덤프 테스트[편집]

1.1 sid 확인[편집]

select * from v$mystat where rownum=1;
    XIDUSN    XIDSLOT     XIDSQN
---------- ---------- ----------
         9          3                353

1.2 테이블 생성 및 데이터 입력[편집]

SYS>create table test(id number);
Table created.

-- 데이터 입력 (100건 )
SYS> begin

for i in 1..100 loop 
insert into test values(i); 
end loop; 
end; 
/

PL/SQL procedure successfully completed.

1.3 현재 트랜잭션 조회[편집]

SYS>select xidusn, xidslot, xidsqn from v$transaction
where addr =(select taddr from v$session where sid=149);

  XIDUSN    XIDSLOT     XIDSQN
---------- ---------- ----------
         9          3               353

1.4 업데이트 진행[편집]

SYS>update test set id=10000 where rownum<50; 49 rows updated.

1.5 언두 세그먼트 조회[편집]

SYS>select file_id, block_id, segment_id from dba_rollback_segs where segment_id=9;

   FILE_ID   BLOCK_ID SEGMENT_ID
---------- ---------- ----------
         2           137               9

1.6 언두 블럭 덤프[편집]

-- trace 파일을 찾기 쉽게 하기위해 파일명 식별자 적용 
SYS>alter session set tracefile_identifier="UNDODUMP";

-- 언두 블럭 덤프 
SYS>alter system dump datafile 2 block 137; 

SYS>select b.object_name as TABLE_NAME, a.FILE#, a.DBABLK, a.obj, a.CR_SCN_BAS, a.BA, a.CR_UBA_FIL, a.CR_UBA_BLK
         , decode (state,0,'FREE',1,'SCUR',3,'CR',4,'READ',5,'MREC',6,'IREC')AS STATE
      from x$bh a, dba_objects b
     where b.object_name = upper('test')
       and a.obj=b.object_id;

TABLE_NAME  FILE#   DBABLK  OBJ     CR_SCN_BAS   BA         CR_UBA_FIL   CR_UBA_BLK  STATE
------------- ----- ------- ----  -------------  -------- ------------- ------------- ----------
TEST          1      60914  52754   0            289C8000          0    0             SCUR
TEST          1      60914  52754   746827       28C48000          0    0             CR
TEST          1      60913  52754   0            28C44000          0    0             SCUR

1.7 데이터 블럭 덤프[편집]

SYS>alter session set tracefile_identifier="BLOCKDUMP";
SYS>alter system dump datafile 1 block 60914; 
System altered.

SYS>exit

1.8 데이터 블럭 덤프 파일 보기[편집]

*** 2010-03-21 17:43:09.122
Start dump data blocks tsn: 0 file#: 1 minblk 60914 maxblk 60914
buffer tsn: 0 rdba: 0x0040edf2 (1/60914)
scn: 0x0000.000b654c seq: 0x03 flg: 0x04 tail: 0x654c0603
frmt: 0x02 chkval: 0x50f3 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x0CC29E00 to 0x0CC2BE00
CC29E00 0000A206 0040EDF2 000B654C 04030000  [......@.Le......]
....
CC2BDF0 0201012C 012C02C3 02C30201 654C0603  [,.....,.......Le]
Block header dump:  0x0040edf2
 Object id on Block? Y
 seg/obj: 0xce12  csc: 0x00.b6508  itc: 2  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0009.003.00000161  0x008001e3.0125.31  ----  100  fsc 0x0000.00000000
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
 
data_block_dump,data header at 0xcc29e5c
===============
tsiz: 0x1fa0
hsiz: 0xda
pbl: 0x0cc29e5c
bdba: 0x0040edf2
     76543210
flag=--------
ntab=1
nrow=100
frre=-1
fsbo=0xda
fseo=0x1d48
avsp=0x1b42
tosp=0x1b42
0xe:pti[0] nrow=100 offs=0
0x12:pri[0] offs=0x1f9a
0x14:pri[1] offs=0x1f94
....
0xd6:pri[98] offs=0x1d4e
0xd8:pri[99] offs=0x1d48
block_row_dump:
tab 0, row 0, @0x1f9a
tl: 6 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 2]  c3 02
.....
tab 0, row 99, @0x1d48
tl: 6 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 2]  c2 02
end_of_block_dump
End dump data blocks tsn: 0 file#: 1 minblk 60914 maxblk 60914

1.8.1 용어 해설[편집]

  • ITL
  1. Interested Transaction List의 Entry Number.
  2. ITL Entry의 개수는 Table 생성시 INITRANS와 MAXTRANS Option을 통해 설정 가능.
  3. INITRANS는 최초 설정되는 ITL Entry의 개수이며 MAXTRANS는 동적으로 최대한 증가시킬 수 있는 ITL Entry의 개수 이다. (MAXTRANS의 값을 설정하더라도 무시 됨.)
  4. 처음 Block Header에는 두 개의 ITL Entry를 갖게 된다. 그래서 동시에 3개 이상의 Transaction이 해당 Block에 발생하지만 않는다면 두 개의 Entry가지고 재사용하며 Transaction 정보를 관리하게 된다. 때문에 가장 최근 해당 Block에 발생했던 2개의 Transaction에 대한 정보를 관리하게 된다.
  5. ITL List에 동시 3개 이상의 여러 Transaction이 동일 Block에 존재하는 Row들을 대상으로 Update를 수행한다면 Transaction의 개수만큼 동적으로 증가할 수 있으며 이렇게 증가한 ITL List는 줄어들지 않는다.
  • XID
  1. Xid는 Transaction 발생 시 첫 번째 DML문장이 수행되는 동안에 Transaction에 할당되는 ID.
  2. Usn#, Slot#, Wrap# 의 3개의 필드로 구성
  3. V$TRANSACTION View를 이용해서 조회 가능
  4. 0x0005.02f.0000028b 을 10진수로 변환하면 USN=5, SLOT=47 SQN=651
  • Flag
  1. Flag는 U와 C 두 종류가 있으며 U Flag는 Upper Bound Commit이라는 의미.
  2. Fast Commit은 Commit을 빠르게 수행하기 위한 기법이다.
    1. Commit을 빠르게 수행하기 위해 Commit시 수행 되어야 할 Cleanout작업(ITL정리작업, Row Record 정리작업, Block SCN 변경작업)에 대해 나중에 일부 또는 전부를 수행하는 것이다.
    2. Cleanout은 Buffer Cache에 상주하는 Block인지, Disk에 상주하는 Block 인지에 따라 처리하는 방식이 다르다.
    3. 하지만 Buffer Cache에 상주해 있을 때에 Cleanout이 수행된다는 것만은 동일하다.
    4. 이러한 방식을 채택한 것은 최상의 Commit속도를 내기 위함에 있다.
  • Lck
  1. Lck은 Transaction 에 의해 변경된 row수를 의미.
  2. Commit이 이루어 졌는데도 불구하고 아직 락을 풀지 않았다는 이유는 바로 오라클은 "delayed block cleanout" 의 메커니즘으로 commit을 처리 하기 때문이다.
    1. 예를 들어 데이터 100,000건을 insert 후 commit을 하면 바로 끝나지만 오라클은 내부적으로 리두를 이용한 "지연된 블럭 클린아웃" 작업을 진행함.
    2. Delayed block cleanout이란 변경된 데이터 블록들 중 Fast commit에 의해 cleanout 되지 않은 블록들을 나중에 cleanout 처리한다는 의미이다.
    3. Delayed block cleanout은 다음 번에 해당 블록을 스캔하는 프로세스에 의해 수행된다.
    4. Delayed block cleanout이 발생하는 경우 순수한 Select 작업인 경우에도 cleanout 작업 자체에 대한 리두 데이터가 생성 될 수 있다.
  • Scn/Fsc
  1. Scn은 System Change Number의 약자
  2. Fsc는 Free Space Credit의 약자.
  3. Fsc 0x0000.000c104e은 ‘.’을 기준으로 앞부분은 Transaction으로 인해 Data Block에 발생되는 Free공간을 의미하며 뒷부분은 마지막으로 Commit된 Transaction의 SCN번호.
    1. 그리고 Fsc를 통해 Transaction이 진행 중인지 완료되었는지 확인이 가능.
    2. 만약 Transaction이 수행 중이라면 위 지표의 000c104e부분이 SCN이 할당되지 않아 00000000으로 나타난다.

1.9 Undo 블럭 덤프[편집]

*** TRACE DUMP CONTINUED FROM FILE /u01/app/oracle/admin/orcl/udump/orcl_ora_12575_UNDODUMP.trc ***

*** 2010-03-21 17:41:26.402
Start dump data blocks tsn: 1 file#: 2 minblk 137 maxblk 137
buffer tsn: 1 rdba: 0x00800089 (2/137)
scn: 0x0000.000b650a seq: 0x02 flg: 0x00 tail: 0x650a2602
frmt: 0x02 chkval: 0x0000 type: 0x26=KTU SMU HEADER BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x0CC29E00 to 0x0CC2BE00
CC29E00 0000A226 00800089 000B650A 00020000  [&........e......]
...
CC2BDF0 01000017 02C10280 4A29C203 650A2602  [..........)J.&.e]
  Extent Control Header
  -----------------------------------------------------------------
  Extent Header:: spare1: 0      spare2: 0      #extents: 3      #blocks: 23   
                  last map  0x00000000  #maps: 0      offset: 4080 
      Highwater::  0x008001e3  ext#: 2      blk#: 2      ext size: 8    
  #blocks in seg. hdr's freelists: 0    
  #blocks below: 0    
  mapblk  0x00000000  offset: 2    
                   Unlocked
     Map Header:: next  0x00000000  #extents: 3    obj#: 0      flag: 0x40000000
  Extent Map
  -----------------------------------------------------------------
   0x0080008a  length: 7    
   0x00800031  length: 8    
   0x008001e1  length: 8    
 
 Retention Table
  -----------------------------------------------------------
 Extent Number:0  Commit Time: 1269143889
 Extent Number:1  Commit Time: 1269158414
 Extent Number:2  Commit Time: 1269141402
 
  TRN CTL:: seq: 0x0125 chd: 0x002b ctl: 0x000e inc: 0x00000000 nfb: 0x0000
            mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
            uba: 0x008001e2.0125.2a scn: 0x0000.000b5aa7
Version: 0x01
  FREE BLOCK POOL::
    uba: 0x00000000.0125.29 ext: 0x2  spc: 0xf10  
    uba: 0x00000000.0124.3c ext: 0x1  spc: 0x1fa  
    uba: 0x00000000.0124.2a ext: 0x1  spc: 0xa6e  
    uba: 0x00000000.0000.00 ext: 0x0  spc: 0x0    
    uba: 0x00000000.0000.00 ext: 0x0  spc: 0x0    
  TRN TBL::
 
  index  state cflags  wrap#    uel         scn            dba            parent-xid    nub     stmt_num    cmt
  ------------------------------------------------------------------------------------------------
   0x00    9    0x00  0x0161  0x000e  0x0000.000b6425  0x008001e2  0x0000.000.00000000  0x00000001   0x00000000  1269160093
   0x01    9    0x00  0x0160  0x000d  0x0000.000b5d5a  0x00800038  0x0000.000.00000000  0x00000001   0x00000000  1269156493
   0x02    9    0x00  0x0161  0x0018  0x0000.000b6220  0x008001e1  0x0000.000.00000000  0x00000001   0x00000000  1269158893
   0x03   10    0x80  0x0161  0x0002  0x0000.000b6508  0x008001e3  0x0000.000.00000000  0x00000002   0x00000000  0
   0x04    9    0x00  0x015f  0x0013  0x0000.000b5b6a  0x00800038  0x0000.000.00000000  0x00000001   0x00000000  1269155293
   ...
   0x2f    9    0x00  0x015f  0x001c  0x0000.000b5ad3  0x00800038  0x0000.000.00000000  0x00000001   0x00000000  1269155292
End dump data blocks tsn: 1 file#: 2 minblk 137 maxblk 137
*** TRACE DUMP CONTINUES IN FILE /u01/app/oracle/admin/orcl/udump/orcl_ora_12575_BLOCKDUMP.trc ***

-- index 0x03(16진수)의 값인 XIDSLOT 3(10진수)와 같다. State의 값이 10으로 되어있는건 현재 트랜잭션 Active상태임을 나타낸다. 즉 commit을 하지않은 트랜잭션 이다.

   XIDUSN    XIDSLOT     XIDSQN
---------- ---------- ----------
         9          3               353
select * from v$transaction
where XIDUSN=9 and XIDSLOT=3 and XIDSQN=353;
  • 언두 세그먼트 번호 6번이면 트랜잭션 테이블에서의 슬롯 위치는 4번임을 확인할 수 있다.
FILE_ID   BLOCK_ID SEGMENT_ID
-------- ---------- --------------
      2           137               9
  • 언두 헤더의 덤프를 내용을 확인한 결과 세션 종료전 확인 했던 값과 일치 함을 확인 할수 있다.
Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0009.003.00000161  0x008001e3.0125.31  ----  100  fsc 0x0000.00000000
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
원본 주소 "http://dbcafe.co.kr/wiki/index.php?title=오라클_트랜잭션,블럭,언두,리두_덤프_테스트&oldid=12038"