• Transaction Rollback

• Transaction Recovery

• Read Consistency
  

UNDO 기본배경

전강좌의 4.Redo부분에 언급했듯이, Redo로그의 메카니즘은 빠른커밋을 실현하기 위한 방법이다. 

단, 시스템장애시에도 지속성을 해치지 않아야 한다는 전제조건을 지키도록 설계되어 있다.

(구체적인 내용은 4.Redo를 참조)

Redo로그의 아키텍쳐만으로는 문제점이 하나 발생한다.

Redo로그화일에 기록은 커밋완료된 데이타만이 올라가는것이 아니다.

대용량트랜잭션에서도 빠른커밋이 가능하도록, 주기적으로 올라간다.

즉, Redo로그화일에는 커밋완료데이터 이외에도 커밋미완료데이타가 혼재하게 된다. 

결국, Redo로그화일을 전부 복구해버리면 未커밋데이터를 커밋완료 데이터인양 복구하게 된다.

무엇이 필요한가 생각해보자.

과거 정보가 필요하다. 즉, 갱신전에 데이터가 어떤 상태였는지가 필요하다.

그로인해, 시스템장애복구시에 未커밋데이터를 갱신전의 데이터로 되돌릴수 있게 된다. (Rollback)

다음 그림은 시스템 장애 발생시 복구과정을 표현한것이다. (Redo, Undo)

이러한, 일련의 메카니즘은 트랜젹션의 정합성을 유지하기 위해서 반듯이 필요한 장치라 볼 수 있다.

이 과거 데이터를 유지하고자 함이 UNDO 메커니즘의 탄생배경이다.

UNDO 아키텍쳐의 이해

위 그림에서와 같이 UNDO는 갱신전 데이터를 보존해두어 Rollback작업이 필요할 때 내용을 제공한다.

8i까지는 데이터보존을 위해 필요한 UNDO영역을 관리자가 파라미터에 의해 수동으로 관리했지만,

9i부터는 자동UNDO관리기능(AUM)이 도입되어서 오라클이 자동으로 관리한다.

그럼, UNDO 메커니즘을 구체적으로 살펴보자.

• UNDO 세그멘트 트랜잭션 테이블 슬롯
  

위 그림은 UNDO 세그먼트를 표현한 그림으로, AUM의 경우는 기본적으로 한 트랜잭션이 한 UNDO세그먼트를 갖는다.

UNDO세그먼트를 제어하기 위한 정보(트랜잭션 테이블 슬롯)가 UNDO헤더에 위치한다.

각 슬롯에 기록되는 사항은 다음과 같다.

1. 트랜잭션ID : USN# + Slot# + Wrap#
   
2. 트랜잭션 상태정보 : 슬롯을 할당받았고 있는가를 표시 (슬롯을 할당받으면 Active)
   
3. 커밋 SCN : 트랜잭션이 커밋될때 갱신되는 일련번호
   
4. Last UBA : Append방식의 기록추가를 위해, 가장마지막 블록의 주소를 저장하고 있다. (리스트형태로 체인형성)
   
5. 기타
   

트랜잭션을 시작하기 위해서는 슬롯을 할당받아야 한다.

슬롯을 할당받으면 UNDO세그먼트에 정보를 기록해가기 시작한다.

정보는 다음과 같다.

1. Insert : 추가된 레코드의 RowId
2. Update : 변경된 컬럼의 변경전 정보（Before Image)
   
3. Delete : 삭제한 데이터의 삭제전 정보（Before Image)

현재 사용중인 UNDO블록에 대해선 다음과 같이 알아볼수 있다.

커밋을 하면 트랜잭션 상태정보는 'Active'에서 'committed'으로 변경되고 그 시점의 커밋 SCN을 트랜잭션 슬롯에 저장한다.
그리고, 해당 트랜잭션 슬롯과 UNDO블록의 다른 트랜잭션에 의해 재사용 될수 있는 상태가 된다.
즉, 그 블록에 기록된 내용은 더 이상 필요없는 기록이 되는것으로, 위 SQL을 실행해 보면, UNDO블록정보가 검색되지 않음을 확인할 수 있다.

물리적으로는 undo redord가 순차적으로(오래된것부터) 재사용(덮어쓰기)되기 때문에 내용자체는 상당기간 남아있게 된다.

※Undo Retention

   9i에서 자동UNDO관리기능이 도입되면서 새롭게 생긴 파라미터로써, 커밋된 UNDO데이터를 "가급적" 일정기간 저장하게(재사용금지)하는 설정을 할 수 있다.  강제성이 없기에 할당공간이 없으면 재사용된다. (우선순위를 미루는 효과정도)

※Retention guarantee

  10g에서 새롭게 추가된 기능으로 Undo Retention과 비슷하나,  "강제적"으로 설정한 기간동안은 재사용을 하지 않게 한다. 기간내에 혹, 할당 공간이 없게 되도 재사용하지 않고 에러를 발생시킨다.

• 블록 헤더 ITL 슬롯

?

트랜잭션을 시작하기 위해서는 UNDO세그먼트의 트랜잭션 테이블로부터 슬롯을 할당받아야 함을 앞에서 살펴 보았다.

그럼, 트랜잭션이 시작되고 실제 데이타를 갱신하기 위해서는 어떻게 될까.

역시, 비슷한 원리로, 특정블록에 있는 레코드를 갱신할때는 그 블록헤더로부터 슬롯(ITL슬롯)을 확보해야 한다.

해당 트랜잭션이 종결(커밋or롤백)된 후 비로소, 해당 블록으로 부터 ITL슬롯을 할당 받아 자신의 트랜잭션을 계속 진행할수 있게 된다.

오라클은 ITL슬롯 부족으로 인한 트랜잭션 블로킹을 최소화하고자 다음과 같은 옵션을 제공한다.

1. initrans : 최초 포맷시에 각 블록에 할당할 ITL슬롯 개수
   
2. maxtrans : 확장시 할당할수 있는 최대 ITL슬롯 개수
   
3. pctfree : ITL슬롯 할당용 예약 공간 (이 공간이 다 사용되면 락경합이 발생한다.)

1. ITL슬롯 번호
   
2. 트랜잭션ID
   
3. UBA(Undo Block Address)
4. 커밋플래그
5. Locking 정보
6. 커밋SCN

• Lock Byte

?블록내에 존재하는 Lock Byte에 대해 알아보기로 하자.

오라클은 저장되는 로우단위로 그 헤더에 Lock Byte를 할당하여 갱신중인 ITL슬롯 번호를 기록한다.

이것으로 해당 로우가 갱신중이라는 사실을 알릴수 있다.

이것이, 로우단위Lock이다.

이와 같이 오라클은 로우단위의 Lock을 속성으로 갖고 있어 Lock에스컬레이션 메커니즘이 전혀 불필요.

다른 DBMS의 Lock메카니즘.

1. 다른 DBMS는 Lock매니져를 두고 관리.
2. Lock매니져 또한 리소스를 소비하게 된다.
3. 대용량의 갱신이 발생하면 블록단위 혹은 테이블 단위로 Lock에스컬레이션이 발생.
4. 그 순간은 동시성이 현저히 저하.

<<1장. 05절 끝>>