1. 언두 체인
트랜잭션이 생성한 언두 데이터들이 생성 순서대로 묶여있는 상태

1.1 방법

• 언두 데이터 블록의 블록 헤더는 블록 내에서 가장 마지막 생성된 언두 데이터의 행 주소 값을 가지고 있다.
• 언두 데이터 블록 내에서 가장 처음 생성된 언두 데이터는 이전 언두 데이터 블록의 주소 값을 가지고 있다.
• 트랜잭션 슬롯에는 가장 마지막 사용된 언두 블록의 주소 값이 저장됨.
  --> 트랜잭션 슬롯을 통해 언두 데이터에 접근하면 데이터 변경 순서의 역순으로 언두 데이터를 읽는다.
  --> 언두 데이터를 역순으로 읽다가 언두 데이터 블록의 주소 값이 ITL에 저장된 가장 먼저 사용한 언두 블록의 주소 값과 일치하면 해당 블록 내의 가장 먼저 생성된 언두 데이터까지 읽은 후 언두 데이터 읽기가 종료 된다.
  --> 언두 체인이 역순으로 읽기 때문에 롤백이 가능한 것이다.

1.2 예제

1) 데이터가 저장된 블록에 접근하여 ITL정보를 확인한다. 트랜잭션 ID는 1.1.3이다.(1번 언두 세그먼트의 1번 트랜잭션 슬롯을 사용, 트랜잭션 슬롯의 재사용 번호는 3번, 트랜잭션이 가장 처음으로 사용한 언두 블록의 주소값은 10번)
참고
ITL에는 트랜잭션 ID가 저장되며 트랜잭션 ID는 [언두세그먼트번호].[트랜잭션 슬롯 번호].[트랜잭션 슬롯 재사용 번호]로 구성된다.

2) ITL에서 확인한 트랜잭션 ID를 이용하여 1번 언두 세그먼트에 접근한 뒤 트랜잭션 테이블의 1번 트랜잭션 슬롯의 정보를 확인한다. 이때 슬롯 재사용 번호가 트랜잭션 ID와 일치하는지 확인한다.

3) 트랜잭션 슬롯에서 확인한 정보로 트랜잭션이 가장 마지막에 사용한 21번 주소 값의 언두 데이터 블록에 접근한다.

4) 21번 언두 데이터 블록에 저장된 언두 데이터를 다 읽은 뒤, 10번 언두 데이터 블록에 저장된 언두 데이터를 읽는다. 10번 언두 블록에 저장된 언두 데이터 1까지 읽으면, ITL에 저장된 언두 데이터 블록 주소값과 일치하므로 읽기를 중단한다.

2. 읽기 일관성

2.1 데이터 유형

• 변경이 발생하지 않은 데이터
• 자기 자신이 변경 후 트랜잭션을 완료한 데이터
• 자기 자신이 변경 후 트랜잭션을 완료하지 않은 데이터
• 다른 사용자가 변경 후 트랜잭션을 완료한 데이터
• 다른 사용자가 변경 후 트랜잭션을 완료하지 않은 데이터

2.2 읽기 일관성이란

• 위의 열거된 데이터 유형 중 다른 사용자가 변경한 데이터에 대해 변경 시점에 따라 이전 이미지를 보여주는 것.
• 조회 시작 시점에 다른 사용자가 변경 후 트랜잭션을 완료하지 않은 데이터는 조회시 변경 전 이미지를 보여주는 것.
• 조회 중 다른 사용자가 변경한 데이터는 트랜잭션 완료 여부에 상관없이 변경 전 이미지를 보여주는 것.
  --> 조회시, 조회 시작 시점에 변경이 발생하지 않거나 변경이 완료되어 있는 데이터가 보여지는 것.

다른 사용자가 데이터 변경 후 트랜잭션을 완료하지 않은 데이터에 대해 읽기 일관성이 보장되는 경우

1. 세션 1이 scn10시점에 작업을 update하고 트랜잭션을 완료하지 않았다.
2. 세션2는 scn이 15인 시점에 작업을 update 하고 트랜잭션을 완료하였다.
   ==> 세션 3이 scn21인 시점에 사원 테이블을 조회하면 조회 시점에 트랜잭션이 완료되지 않은 작업은 변경 전 이미지로 데이터를 보여주게 된다.

• 조회 중 다른 사용자가 변경한 데이터에 대해 트랜잭션 완료 여부와 상관 없이 읽기 일관성이 제공되는 경우*
  

1. 세션 3이 scn 12 시점에서 테이블을 조회를 시작하여 20인 시점에 완료
2. 조회 도중 세션 1과 2에서 변경작업을 진행
3. 세션 1은 작업을 완료하지 않았기 때문에 변경 전 데이터가 조회
4. 세션 2는 조회 작업 이후 변경을 완료하였기 때문에 전 데이터가 조회

2.3 Current Buffer Cache 와 Consistency Read Buffer Cache.
2.3.1 Current Buffer Cache.

• DML 수행 시 발생
• 현재 시점의 데이터 블록을 의미함.
• DML 수행 시에는 가장 최근의 데이터 블록 이미지에 대해서 변경이 적용

2.3.2 Consistency Read Buffer Cache

• SELECT 수행시 발생하거나 DML수행 시 WHERE 조건 절을 만족하는 데이터를 검색할 때 발생함.
• 발생하는 경우 먼저 필요한 블록의 현재 버퍼 캐시를 버퍼 캐시 내 다른 공간에 복사한 뒤, 복사된 블록에 언두 정보를 반영하여 롤백 후 이를 사용한다.

읽기 일관성 버퍼 캐시 생성 과정

1) SCN 15 시점에 세션 1이 update 를 진행
2) 버퍼 캐시로 복사된 언두 데이터 블록에 변경 전 이미지가 복사된 후, 버퍼 캐시에 변경 후 이미지가 적용된다.
3) SCN20 시점에 세션 2가 검색을 진행
4) 세션 1이 트랜잭션을 완료하지 않았으므로, Consistency Read Buffer Cache를 생성하기 위해 세션 1에 의해 변경된 블록을 다른 버퍼 캐쉬 영역으로 복사한다.
5) 언두 데이터 블록을 버퍼 캐쉬에 복사한다.
6) 복사된 버퍼 캐시에 롤백을 적용하여 변경 전 이미지를 생성한다.
7) 블럭의 이전값을 출력한다.

3. ORA-1555 snapshot too old 에러
읽기 일관성 제공에 실패하는 경우 발생하는 에러인데 다음의 자원이 재사용되었을때 발생한다.

• 트랜잭션 슬롯
• 언두 데이터 블록
  --> 오라클의 fast commit 작업으로 트랜잭션 완료 후 위의 리소스를 사용할 수 없게 된다.

3.1 fast commit
커밋 시 변경된 버퍼 캐시를 데이터 파일로 내려 쓰지 않고, 리두 로그 버퍼의 데이터만 리두 로그 파일로 내려 쓰는 방식
--> 대신 데이터 블록을 변경시킨 트랜잭션이 완료 되었음을 트랜잭션 슬롯 및 ITL에 표시 한다. ==> ( Cleat out 작업)
3.1.1 clean out
두가지 방법을 사용

• Delayed Block Cleanout
  • 트랜잭션이 갱신한 블록 개수가 총 버퍼 캐시 블록 개수의 1/10을 초과한 경우 커밋 이후 해당 블록을 접근하는 첫번째 쿼리에 의해 실행
  • 하는 작업
    • ITL 슬롯에 커밋 정보 저장
    • 레코드에 기록된 Lock Byte 해제
    • Online Redo 에 Logging
• Fast Block Cleanout( Delayed logging block clean out)
  • 트랜잭션이 갱신한 블록 갯수가 버퍼 캐시 블록 갯수의 1/10을 초과하지 않은 경우 커밋시점에서 바로 하는 불완전 블록 클린 아웃
  • 하는 작업
    • ITL 슬롯에 커밋 정보만 저장
      ==> 해당 블록을 갱신하려고 Current 모드로 읽는 시점에 나머지 작업을 진행 한다.