1. h2. Undo
    • h5. 트랜잭션이 발생시킨 테이블과 인덱스에 대한 변경사항들이 Undo 레코드 단위로 Undo 세그먼트(블록)에 기록
    • h5. (트랜잭션 : Undo 세그먼트) = (N : 1)
      • 9i 부터는 AUM 에 의해 1 : 1 을 목표로 자동 관리
  2. h2. Undo 의 목적
목적설명
Transaction Rollback
Transaction RecoveryInstance Recovery 시 Rollback 단계
Read Consistency다른 DBMS 는 Lock 을 통해 구현
  1. h2. Undo 세그먼트
    • h5. Undo 세그먼트는 일반 테이블 세그먼트와 다르지 않다.
      • Extent 단위로 확장
      • Undo 세그먼트의 블록도 버퍼캐시에 캐싱
  2. h2. 버전별 Undo 기능
버전새기능관리공간관리비고
8i-Rollback Segment (CREATE, ONLINE, OFFLINE) 수동현재 세그먼트가 꽉차면 에러 발생
9iAUM(Automatic Undo Management), Dynamic Extent Transfer, Undo RetentionRollback Segment (CREATE, ONLINE, OFFLINE) 자동현재 세그먼트가 꽉차면 다른 세그먼트 로부터 공간을 빌려옴Undo 테이블스페이스가 꽉차면 에러 발생
10gRetention Guarantee, Automatic Undo Retention Tuning
    • h5. undo_management (파라미터)
    • h5. undo_retention (파라미터)
      • 트랜젝션이 완료 되었어도 지정된 시간(초) 동안은 가급적 Undo 세그먼트를 재사용하지 않도록 함 (active → unexpired → expired)
    • h5. dba_tablespaces.retention (테이블스페이스 속성)
      • alter tablespace undotbs1 retention (guarantee, noguarantee);
    • h5. Automatic Undo Retention Tuning (tuned_undo_retention)
      • 10gR1 - undo_retention 을 0 으로 설정
      • 10gR2 - Undo 테이블스페이스의 retention 속성을 noguarantee 로 설정
  1. h2. Undo 세그먼트
    • h5. Undo 헤더 (Initial Extent)
      • Transaction Table 슬롯
컬럼내용비고
Transaction IDUSN# + Slot# + Wrap#USN : Undo Segment Number
Transaction Status상태정보COMMITTED, ACTIVE
Commit SCN트랜잭션이 커밋된 경우
Last UBAUndo 레코드 체인을 유지하는 일종의 포인터UBA: Undo Block Address
기타
        • 트랜잭션의 시작/종료
상태Transaction Table 슬롯비고
시작슬롯을 할당 받고, Status 를 ACTIVE 로 변경슬롯을 얻지 못한경우 undo segment tx slot (대기이벤트) 발생
종료Status 를 COMMITTED 로 변경, Commit SCN 저장
    • h5. Undo 레코드
DML내용
INSERT추가된 레코드의 ROWID
UPDATE변경된 컬럼에 대한 Before image
DELETE삭제된 ROW의 모든 컬럼에 대한 Before image
    • h5. Undo 레코드 체인
      • Last UBA 로 구성
  1. h2. v$transaction
컬럼내용비고
used_ublkUndo 블록수
used_urecUndo 레코드수인덱스는 UPDATE 시 2씩 증가 (내부적으로 DELETE & INSERT)
  1. h2. 블록 헤더 ITL 슬롯 (24 Byte)
컬럼내용비고
ITL 슬롯 번호
Transaction ID
UBAUndo Block AddressCR 블록을 생성할때 사용
Locking 정보
커밋 SCN
    • h5. 레코드를 갱신 하기 위해서는, 해당 블록 헤더 ITL 슬롯 확보
      • ITL 슬롯 확보 될때까지 enq: TX - allocate ITL entry (대기이벤트) 와 함께 트랜잭션이 블로킹됨
      • ITL 슬롯 부족을 극복하기 위해, INITTRANS, MAXTRANS, PCTFREE 파라미터 활용
        • 10g 부터 INITTRANS 는 최소2, MAXTRANS 는 255 고정
        • 블록에 여유공간이 없는경우 추가 슬롯 생성이 불가능 (PCTFREE)
  1. h2. Lock Byte
    • h5. 레코드가 저장되는 ROW마다, 헤더에 Lock Byte를 할당해, 트랜잭션의 ITL 슬롯 번호를 기록해 둔다. (Row-level Lock)
    • h5. 레코드 갱신 시도시
순서대상동작비고
#1레코드의 헤더Lock ByteTRUE 인 경우 다음 단계 진행FALSE 인 경우 레코드 갱신
#2ITL 슬롯Transaction ID값을 얻어 다음 단계 진행
#3Transaction Table 슬롯StatusCOMMITTED 인 경우 레코드 갱신ACTIVE 인 경우 대기
      • DBMS 별 레코드 정보 관리
DBMS레코드 정보 관리 방법Lock 에스컬레이션비고
오라클레코드 속성없음별도 리소스 사용 없음
다른 DBMSLock 매니저있음

참조문서

블로그(오라클 성능 문제에 대한 통찰) : http://ukja.tistory.com/252
위키(오라클클럽) : http://wiki.gurubee.net/pages/viewpage.action?pageId=3900637
서적(오라클 성능 고도화 원리와해법 I) : http://book.daum.net/detail/book.do?bookid=KOR9788996246015