1. h2. 읽기 일관성 구현 (Dirty Read 방지)

• • h5. 다른 DBMS 의 문제 데모

• • • 데모 #0

 
TX1> select sum(잔고) from 계좌;

• • • 데모 #1 - 레코드가 추가된 위치에 따라서 총합계가 달라진다.

 
TX2> insert into 계좌 (계좌번호, 잔고) values ( 11, 1000 );
TX2> commit; 

• • • 데모 #2 - 레코드의 순서와 TX1, TX2 의 실행 순서에 따라서 총합계가 달라진다.

 
TX2> update 계좌 set 잔고 = 잔고 + 100 where 계좌번호 = 7;
TX2> update 계좌 set 잔고 = 잔고 - 100 where 계좌번호 = 3;
TX2> commit; 

• • h5. 다른 DBMS 의 문제 대안

1. h2. Consistent 모드 블록 읽기 (Multi-Version Read Consistency Model)
   • h5. 쿼리가 시작된 시점 ¹ 을 기준으로 데이터를 읽음
     • 변경이 발생한 블록은(쿼리 SCN ⁴ 보다 블록 SCN ³ 이 큰 블록은) Current 블록 ² 으로부터 CR 블록을 생성해서 읽는다.
       • ( Current 블록 ² : CR 블록 ) = ( 1 : N )
         • RAC 환경에서 Current 블록이 노드 숫자만큼 생길 수(캐싱될 수) 있으나, Exclusive 모드의 Current 블록은 한개다. (Shared(S), Exclusive(X), Null(N) 모드)
     • 시점 ¹ 은 SCN ⁴ (System Commit Number) 로 식별 (v$database.current_scn) : 일관성, 동시성, Redo Log 정보 순서 식별, 데이터 복구
     • 블록 SCN ³ (System Change Number) : 블록이 마지막으로 변경된 시점 정보
2. h2. Consistent 모드 블록 읽기의 세부 원리
   • h5. SCN ⁵ 확인 후 읽기 작업을 한다.
     • SCN ⁵ : 쿼리 SCN or 스냅샷 SCN
     • Current 블록 SCN <= 쿼리 SCN 인 블록만 읽기 가능
   • h5. Current 블록 상태에 따른 Consistent 모드 블록 읽기

• • • Current 블록 상태가 ACTIVE 인 경우, 오라클은 Delayed 블록 클린아웃 하기 때문에 트랜잭션 테이블 까지 확인을 해야 함.
    • CR 블록 생성에 필요한 Undo 정보가 없는 경우 ORA-1555 발생

1. h2. IMU (In-Memory Undo)
   • h5. 장점
     • Undo 세그먼트 헤더 블록, Undo 세그먼트 블록 버퍼에 대한 래치 경합 및 Pinning 감소
     • In-memory undo latch (래치)
   • h5. 파라미터 (10g)
     • _in_memory_undo : IMU 사용 여부 (TRUE / FALSE)
     • _imu_pools : IMU Pool 수
   • h5. 동작
     1. Undo 데이터가 Undo 세그먼트가 아닌 Shared Pool 내의 IMU Pool <KTI-UNDO> 에 생성...
     2. IMU Pool 이 가득차면, 저장된 Undo 데이터를 Undo 세그먼트로 일괄 기록 (IMU Flush)
     3. 이후 Undo 데이터는 예전처럼 Undo 세그먼트에 저장
2. h2. DBA당 CR 개수 제한
   • _db_block_max_cr_dba (파라미터)
   • 블록당 6개 까지만 CR Copy를 허용 (가득 차면 오래된 CR Copy 부터 밀려남)
   • LRU 리스트에서 항상 LRU END 쪽에 위치 (메모리 부족시 가장 먼저 밀려남)

참조문서

블로그(오라클 성능 문제에 대한 통찰) : http://ukja.tistory.com/11
서적(오라클 성능 고도화 원리와해법 I) : http://book.daum.net/detail/book.do?bookid=KOR9788996246015