8._블록_클린아웃
2012.03.18 20:52
- What is Block Clear Out
- Transaction 에 의한 RowLock 해제
- 블록헤더에 Commit 정보를 기록
※ Oracle 의 로우 단위 Lock는 레코드 속성(Lock byte)로 관리 되며, 이는 로우 헤더로부터 블록 헤더에 있는 ITL 엔트리를 가르키는 포인터이다.
| Delayed 블록 클린아웃 | 커밋 클린아웃 (Delayed Logging Block CleanOut) |
발생 시점 | - Transaction 에 의해 갱신되는 Block가 DB buffer cache의 10%를 초과한 경우 | - Transaction 에 의해 갱신되는 Block가 DB buffer cache의 10% 이하인 경우 |
처리 내역 | - ITL Slot Commit 정보 저장 - Lock Byte 해제 - Clean Out 정보 Redo Logging | - ITL Slot Commit 정보 저장 - Lock Byte 해제 X (Redo에 Logging 하지 않기 위해) |
사용 목적 | - 대량의 변경작업시 commit 성능의 향상을 위해 | - Select 시 빈번한 Block Clean Out 발생을 줄이기 위해 |
- Delayed 블록 클린아웃
- 사용자가 트랜잭션을 커밋 하면 블록 클린 아웃까지 완료해야 완전한 커밋
- 대량의 갱신 작업후 커밋을 위해 블록을 하나 하나 찾아 다니면 수행시간이 길어진다.
- 오라클은 대량의 갱신 작업후 커밋 정보를 트랜잭션 테이블에만 기록하고 빠르게 커밋을 끝내 버린다.
- 블록 클린 아웃의 시점은 커밋후 해당 블록이 처음 액세스 되는 시점이다.
- 커밋 클린 아웃(Fast 블록 클린아웃)
- 모든 클린아웃을 Delayed 블록 클린아웃으로 처리한 경우 Select 시 블록 클린아웃 하는 일이 빈번해짐
- 블록 클린아웃 역시 쓰기 작업이므로 Current 블록에 작업 수행 필요
- RAC 가 아닌 과거 7.X 버전의 OPS 구조에서 ping 현상을 예방하기 위해 커밋 클린아웃 도입
RAC는 Dirty 상태의 버퍼블록의 싱크가 Instance 상에서 가능하지만 과거 OPS 구조에서는 Dirty 블록을 Disk에기록하여 싱크가능
Select 시 Disk I/O 증가
- 커밋 시점에 블완전 형태의 클린아웃이 이루어짐
- 커밋 시점에 이미 완전한 커밋 정보가 ITL에 기록돼어 있기 때문에
CR모드 읽기 시 커밋 SCN 확인을 위한 트랜잭션 테이블 확인 불필요
- 이후 해당 블록 갱신 시점에 Current 모드로 읽을때 Lock Byte 해제 및 Redo 에 Logging 하여 완전 클린아웃 처리
- ITL 블록과 클린아웃
Itl Xid Uba Flag
Lck Scn/Fsc |
0x01 0x0006.016.00000378 0x008009f9.03f0.18
--U- 1 fsc 0x0000.0028b73e
- 커밋 클린아웃(Fast 클린아웃) 상태
- ITL 슬롯에 커밋 SCN 기록(0x0000.0028b73e)
- Fast 클린아웃 상태 표시를 위해 fsc 표시되어 있고 커밋 플래그에 U가 표시됨
- 바로 사용불가 쓰기작업을 위해 읽는 순간 LockByte 해제 및 Redo Log에 기록하여 2번 slot과 같은 상태가 되야함
0x02 0x0005.01d.0000038c 0x0080015a.02ef.05 C--- 0 scn 0x0000.0028b691
- 블록 클린아웃이 된 상태
- 커밋 Flag 가 C로 표시되어 있다
0x03
0x0005.00d.000003c4 0x00801a0b.01d1.1d C-U- 0 scn 0x0000.006770c0
- LockByte가 완전 해제된 완전한 클린아웃 상태
- 커밋 Flag 가 C-U- 인것은 추정된 커밋 SCN을 의미한다.
-- commit 전 데이터 블록 덤프 Itl Xid Uba Flag Lck Scn/Fsc 1. Itl 0x02 의 Xid 분석 . Xid 구성 = Usn# + Slot# + Wrap# . Usn# = Ox5 : 해당 트랜잭션은 5번 Undo(_SYSSMU5$)에 롤백정보 저장 . Slot# = Ox1d : 5번 Undo Header block 내의 29번째(1d) 트랜잭션 슬롯에 트랜잭션 관련 정보 저장
. wrap# = Ox38c: 해당 트랜잭션 슬롯은 908번(Ox38c) 재사용되었음 2. Itl 0x02 Uba분석(0x0080015a.02ef.05) . Undo 블록내에 변경된 주소 (트랜잭션에 의해 처음으로 사용된 언두블럭의 주소) . Udba + seq + slot . Udba : Undo block 의 DBA . slot : Undo Block 내의 레코드 번호 3. Itl 0x02 Flag 분석 . 트랜잭션이 완료되지 않았으므로 Flag 는 아무런 정보도 가지고 있지 않다 4. Itl 0x02 Lck 분석(2) . 트랜잭션과 관련된 레코드의 수 : 해당 트랜잭션은 2개의 레코드에 대해 로우레벨 락을 설정 상태 5. Itl 0x02 Scn/fsc 분석(fsc 0x0036.00000000) . SCN : System Change Number . Fsc : Free Space Credit => 해당 Tr에 의해 Free된 Byte . 0x0036 : 54Bytes 의 free 공간 발생 . 00000000 : 현재 진행 중인 TR인 경우에는 별도의 SCN 번호가 부여 되지 않는다 -- commit 후 데이터 블록 덤프 Itl Xid Uba Flag Lck Scn/Fsc 1. Scn 분석 (0x0000.0028b73e) . Scn Wrap# (2Bytes) + Scn Base# (4Bytes) . Commit이 완료 되었으므로 SCN 할당 . TX 가 완료 되어 SCN이 할당 될때 마다 SCN Base#이 증가됨 . Base# 4 Bytes가 다 사용되면 Wrap#이 증가 2. Flag 분석(--U-) . U : Upper bound Commit 의 약자 . Fast Commit Block Clean Out 를 의미 3. Lck분석(2) . TX 가 완료되면 Lock Byte가 0이된다. . Fast Commt Block CleanOut 된 상태 이므로 변경 사항이 없다.
4. Scn/Fsc 분석 (0x0036.00709636) . fast Commit Block CleanOut 시에는 Scn Base#만 변경한다.
|
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
26 | 3._SQL트레이스 | sapius | 2012.04.03 | 37297 |
25 | 8._Statspack_AWR | 시와처 | 2012.04.01 | 11767 |
24 |
7._Response_Time_Analysis_방법론과_OWI
![]() | 시와처 | 2012.04.01 | 5916 |
23 | 6._V$SYSTEM_EVENT | 시와처 | 2012.04.01 | 3507 |
22 | 4._동시성_구현_사례 [1] | dasini | 2012.03.26 | 11962 |
21 |
5._오라클_Lock
![]() | 시와처 | 2012.03.25 | 12875 |
20 | 3._비관적_vs._낙관적_동시성_제어 | dasini | 2012.03.25 | 6396 |
19 | 2._AutoTrace | 남송휘 | 2012.03.25 | 3138 |
18 | 1._Explain_Plan | 남송휘 | 2012.03.25 | 4543 |
17 | 3장._오라클_성능_관리 | 남송휘 | 2012.03.25 | 3117 |
16 |
2._트랜잭션_수준_읽기_일관성
![]() | AskZZang | 2012.03.20 | 6364 |
15 | 1._트랜잭션_동시성_제어 | AskZZang | 2012.03.19 | 4883 |
14 | 11._Shared_Pool | 박영창 | 2012.03.19 | 3395 |
13 | 10._대기_이벤트 | 박영창 | 2012.03.18 | 10624 |
12 | 9._Snapshot_too_old | 박영창 | 2012.03.18 | 9969 |
» | 8._블록_클린아웃 | 시와처 | 2012.03.18 | 12305 |
10 |
7._Consistent_vs._Current_모드_읽기
![]() | 시와처 | 2012.03.18 | 5708 |
9 | 2장._트랜잭션과_Lock | AskZZang | 2012.03.16 | 5462 |
8 |
6._문장수준_읽기_일관성
![]() | 정찬호 | 2012.03.11 | 57563 |
7 |
4._Redo
![]() | 남송휘 | 2012.03.11 | 5606 |