- h2. Undo
- h5. 트랜잭션이 발생시킨 테이블과 인덱스에 대한 변경사항들이 Undo 레코드 단위로 Undo 세그먼트(블록)에 기록
- h5. (트랜잭션 : Undo 세그먼트) = (N : 1)
- 9i 부터는 AUM 에 의해 1 : 1 을 목표로 자동 관리
- h2. Undo 의 목적
목적 | 설명 |
---|
Transaction Rollback | |
Transaction Recovery | Instance Recovery 시 Rollback 단계 |
Read Consistency | 다른 DBMS 는 Lock 을 통해 구현 |
- h2. Undo 세그먼트
- h5. Undo 세그먼트는 일반 테이블 세그먼트와 다르지 않다.
- Extent 단위로 확장
- Undo 세그먼트의 블록도 버퍼캐시에 캐싱
- h2. 버전별 Undo 기능
버전 | 새기능 | 관리 | 공간관리 | 비고 |
---|
8i | - | Rollback Segment (CREATE, ONLINE, OFFLINE) 수동 | 현재 세그먼트가 꽉차면 에러 발생 | |
9i | AUM(Automatic Undo Management), Dynamic Extent Transfer, Undo Retention | Rollback Segment (CREATE, ONLINE, OFFLINE) 자동 | 현재 세그먼트가 꽉차면 다른 세그먼트 로부터 공간을 빌려옴 | Undo 테이블스페이스가 꽉차면 에러 발생 |
10g | Retention 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 로 설정
- h2. Undo 세그먼트
- h5. Undo 헤더 (Initial Extent)
컬럼 | 내용 | 비고 |
---|
Transaction ID | USN# + Slot# + Wrap# | USN : Undo Segment Number |
Transaction Status | 상태정보 | COMMITTED, ACTIVE |
Commit SCN | | 트랜잭션이 커밋된 경우 |
Last UBA | Undo 레코드 체인을 유지하는 일종의 포인터 | UBA: Undo Block Address |
기타 | | |
상태 | Transaction Table 슬롯 | 비고 |
---|
시작 | 슬롯을 할당 받고, Status 를 ACTIVE 로 변경 | 슬롯을 얻지 못한경우 undo segment tx slot (대기이벤트) 발생 |
종료 | Status 를 COMMITTED 로 변경, Commit SCN 저장 | |
DML | 내용 |
---|
INSERT | 추가된 레코드의 ROWID |
UPDATE | 변경된 컬럼에 대한 Before image |
DELETE | 삭제된 ROW의 모든 컬럼에 대한 Before image |
- h2. v$transaction
컬럼 | 내용 | 비고 |
---|
used_ublk | Undo 블록수 | |
used_urec | Undo 레코드수 | 인덱스는 UPDATE 시 2씩 증가 (내부적으로 DELETE & INSERT) |
- h2. 블록 헤더 ITL 슬롯 (24 Byte)
컬럼 | 내용 | 비고 |
---|
ITL 슬롯 번호 | | |
Transaction ID | | |
UBA | Undo Block Address | CR 블록을 생성할때 사용 |
Locking 정보 | | |
커밋 SCN | | |
- h5. 레코드를 갱신 하기 위해서는, 해당 블록 헤더 ITL 슬롯 확보
- ITL 슬롯 확보 될때까지 enq: TX - allocate ITL entry (대기이벤트) 와 함께 트랜잭션이 블로킹됨
- ITL 슬롯 부족을 극복하기 위해, INITTRANS, MAXTRANS, PCTFREE 파라미터 활용
- 10g 부터 INITTRANS 는 최소2, MAXTRANS 는 255 고정
- 블록에 여유공간이 없는경우 추가 슬롯 생성이 불가능 (PCTFREE)
- h2. Lock Byte
- h5. 레코드가 저장되는 ROW마다, 헤더에 Lock Byte를 할당해, 트랜잭션의 ITL 슬롯 번호를 기록해 둔다. (Row-level Lock)
- h5. 레코드 갱신 시도시
순서 | 대상 | 값 | 동작 | 비고 |
---|
#1 | 레코드의 헤더 | Lock Byte | TRUE 인 경우 다음 단계 진행 | FALSE 인 경우 레코드 갱신 |
#2 | ITL 슬롯 | Transaction ID | 값을 얻어 다음 단계 진행 | |
#3 | Transaction Table 슬롯 | Status | COMMITTED 인 경우 레코드 갱신 | ACTIVE 인 경우 대기 |
DBMS | 레코드 정보 관리 방법 | Lock 에스컬레이션 | 비고 |
---|
오라클 | 레코드 속성 | 없음 | 별도 리소스 사용 없음 |
다른 DBMS | Lock 매니저 | 있음 | |
참조문서
블로그(오라클 성능 문제에 대한 통찰) : http://ukja.tistory.com/252
위키(오라클클럽) : http://wiki.gurubee.net/pages/viewpage.action?pageId=3900637
서적(오라클 성능 고도화 원리와해법 I) : http://book.daum.net/detail/book.do?bookid=KOR9788996246015