언두 데이터 관리

I. 언두 데이터

II. 트랜잭션 및 언두 데이터

III. 언두 정보 저장

IV. 언두 데이터와 리두 데이터 비교

V. 언두 관리

VI. 언두 Retention

      1. 구성

       2. 보장

---

I. 언두 데이터

    • 프로세스로 인해  데이터베이스의 데이터가 변경되는 경우 오라클 데이터베이스는 이전값을 지정합니다. 이때 데이터는

       수정되기 전 상태로 저장됩니다.

    • 언두는 읽기 일관성 및 Flashback Query를 지원합니다

    • 언두를 사용하여 트랜잭션 및 테이블을 Flashback 할 수도 있습니다.

    • 읽기 일관성 query 는 qury가 시작된 시점의 데이터와 일차한느 결과를 제공합니다

    • 읽기 일관성 query가 성공하려면 원래 정보가 계속 언두에 존재해야 합니다.

    • 변경 전 테이터를 더 이상 사용할 수 없으면 "snap shot too old" 오류 (ORA-01555)가 발생합니다

    • 언두 정보를 보존하고 있는 동안 오라클 데이터베이스는 읽기 일관성 query가 충족되도록 데이터를 재구성할 수 있습니다.

    • Flashback Query는 어떤 목적을 가지고 과거 특정 시점의 데이터 버전을 요청하고, 요청한 과거 특정 시점에 대한 언두

      정보가 있는 경우 Flashback Query를 성공적으로 완료할 수 있습니다

    •  Oracle Flashback Transaction은 트랜잭션 및 해당 종속 트랜잭션을 백아웃하기 위해 언두를 사용하여 보완 트랜잭션을

        생성하고, Oracle Flashback Table을 사용하면 테이블을 특정 시점으로 Recovery 할 수 있습니다

    • 언두 데이터를 사용하여 실패한 트랜잭션을 Recovery할 수 있습니다

    • 유저가 트랜잭션의 커밋 또는 롤백을 결정하기 전에 네트워크 오류 또는 클라이언트 컴퓨터 Failure로 인해 유저 세션이

       비정상적으로 종료되는 경우 트랜잭션이 실패합니다.

    • Instance가 충돌하거나 Shutdown abort명령을 실행하는 경우에도 실패한 트랜잭션이 발생할 수 있습니다.

    • 실패한 트랜잭션이 발생하는 경우 가장 안전한 동작이 선택되며 오라클 데이터베이스는 유저가 수행한 모든 변경 사항을

       되돌려서 원본 데이터를 복원합니다.

    • 다음 중 하나에 의해 트랜잭션이 종료될 때까지 모든 트랜잭션에 대한 언두 정보를 보존합니다.

      ৹ 유저의 트랜잭션 언두 ( 트랜잭션 롤백 )

      ৹ 유저의 트랜잭션 종료 ( 트랜잭션 커밋 )

      ৹ 유저의 DDL문 실행

         - 현재 트랜잭션에 DML문이 포함되어 있는 경우 데이터베이스는 우선 트랜잭션을 커밋한 다음 DDL을 새로운 트랜잭션으로

             실행 및 커밋합니다

      ৹ 유저 세션의 비정상적인 종료 ( 트랜잭션 롤백 ) 

      ৹ 종료 명령에 의한 유저 세션의 정상적인 종료 ( 트랜잭션 커밋 )

    • 보존되는 언두 데이터의 양과 보존 기간은 데이터베이스 작업량과 데이터베이스 구성에 따라 다릅니다.

II. 트랜잭션 및 언두 데이터

    • 트랜잭션이 시작되면 해당 트랜잭션은 언두 세그먼트에 할당되고, 트랜잭션이 진행되는 동안 데이터가 변경되면 변경되기

       전의 값이 언두 세그멈트에 복사됩니다.

    • Dynamic Performance뷰 V$TRANSACTION을 확인하여 어느 트랜잭션이 어느 언두 세그먼트에 할당되었는지 알 수

      있습니다.

    • 언두 세그먼트는 트랜잭션을 지원하는 데 필요한 경우 Instance에서 자동으로 생성되는 특수 세그먼트입니다.

    • 언두 세그먼트는 데이 블록으로 구성된 Extend로 구성되어 있습니다.

    •  언두 세그먼트는 필요한 경우 자동으로 확장되거나 축소되며 할당된 트랜잭션에 대해 순환 저장 버퍼처럼 사용됩니다.

    • 트랜잭션이 완료되거나 모든 공간이 사용될 때까지 트랜잭션은 언두 세그먼트에 Extand를 채우고, Extend가 가득 차서 더

       많은 공간이 필요한 경우 트랜잭션은 세그먼트에 있는 다음 Extend에서 필요한 공간을 얻습니다.

    • 모든 Extend가 사용된 후에 트랜잭션은 첫번째 Extend로 다시 래핑 하거나 언두 세그먼트에 새 Extend를 할당할 것을

      요청합니다.

III. 언두 정보 저장

    • 언두 세그먼트는 언두 테이블스페이스라는 특수한 형식의 테이블스페이스에만 존재할 수 있습니다

    • 언두 테이블스페이스에 테이블 등의 다른 세그먼트 유형을 만들수는 없습니다.

    • DBCA는 Small File 테이블 스페이스를 자동으로 생성하고, Big File 언두 테이블 스페이스를 생성할 수도 있습니다.

    •  짧은 동시 트랜잭션이 많은 대규모 온라인 트랜잭션 프로세싱 환경에서는 파일 헤더에 경합이 발생할 수 있습니다.

    •  데이터베이스에는 여러 언두 테이블 스페이스가 있을 수 있지만 특정 시점에서 그중 하나만 데이터베이스의 Instance에

       대한 현재 언두 테이블스페이스로 지정될 수 있습니다.

    • 언두 세그먼트는 자동으로 생성되며 항상 SYS가 소유합니다.

    • 언두 세그먼트는 순환 버퍼처럼 사용되므로 각 세그먼트는 최소 두개의 Extend를 갖습니다.

    • 최대 Extend 수의 기본값은 데이터베이스 블록 크기에 따라 다르지만 매우 큽니다.

    • 언두 테이블 스페이스는 자동 Extend 할당을 사용하는 영구적인 로컬관리방식의 테이블스페이스로, 데이터베이스에 의해

      자동으로 관리됩니다.

    • Instance Crash 등으로 인해 실패한 트랜잭션을 Recovery하는 경우에는 언두 데이터가 필요하므로 언두 테이블스페이스는

      Instance가 MOUNT 상태일 때만 Recovery할 수 있습니다.

  

IV. 언두 데이터와 리두 데이터 비교

    • 언두 데이터는 변경사항을 언두해야 하는 경우에 필요하며 읽기 일관성 및 롤백에 대해 발생합니다.

    • 리두 데이터는 어떤 이유로 인해 데이터를 분실하여 변경 사항을 다시 수행해야 하는 경우에 필요합니다.

    • 언두 블록 변경 사항은 리두 로그에도 기록됩니다.

    • 커밋 프로세스는 트랜잭션의 변경 사항이 메모리가 아니라 디스크에 영구 저장되는 리두 로그 파일에 기록되었는지

      검증합니다

    • 리두 로그 파일은 대개 다중화되므로 디스크에 리두 데이터의 복사본이 여러 개 있습니다.

    • 테이블의 블록이 실제로 저장되는 테이터 파일에 변경 사항이 아직 기록되지 않은 경우에는 지속 리두 로그에 쓰는

      것만으로도 데이터베이스의 일관성이 보장됩니다.

    • 커밋된 변경 사항이 데이터 파일에 반영되기 전에 정전이 발생하더라도 트랜잭션이 커밋되었기 때문에 문제가 발생하지

      않습니다.

    • 시스템을 다시 시작하면 정전 시 아직 데이터 파일에 반영되지 않은 리두 레코드를 롤포워드할 수 있습니다.

 

V. 언두 관리

    • 오라클 데이터베이스는 자동 언두 관리를 통해 모든 세션에 대한 전용 언두 테이블스페이스에서 언두 정보 및 Undo Space를

      완전 자동화된 방식으로 관리합니다.

    • 시스템은 자동으로 자체 튜닝되어 언두 정보에 대한 Retention을 최적화합니다.

    • 자동 확장 테이블스페이스를 위한 언두 Retention 기간이 장기 실행 활성 query보다 약간 길어지도록 튜닝됩니다.

    • 고정 크기 언두 테이블스페이스의 경우 데이터베이스는 Retention을 최적화하도록 동적으로 튜닝합니다.

    • 수동 언두 관리 모드에서 Undo space는 언두 테이블 스페이스가 아닌 롤백 세그먼트를 통해 관리됩니다.

    

VI. 언두 Retention

1. 구성

    • UNDO_RETENTION 초기화 파라미터는 언두 Retention의 낮은 임계값을 초 단위로 지정합니다.

    • 자동 확장 언두 테이블스페이스를 위한 최소 언두 Retention 기간은 예상되는 가장 긴 Flashback 작업으로 가능한 길게

      설정합니다

    • 자동 확장 언두 테이블스페이스의 경우 시스템은 최소한 이 파라미터에 지정된 시간 동안 언두를 보관하고 query의 언두 요구

       사항을 충족하도록 언두 Retention 기간을 자동으로 튜닝합니다.

    •  자동 튜닝된 Retention 기간은 Flashback 작업을 수행하는데 충분하지 않을 수도 있습니다.

    • 고정 크기 언두 테이블스페이스의 경우 시스템은 언두 테이블스페이스의 크기 및 사용 기록에 따라 최적의 언두 Retention

       기간을 자동으로 튜닝하고 Retention 보장이 활성화되지 않은 경우 UNDO_RETENTION을 무시합니다.

    • 언두 정보는 다음의 세가지 범주로 나뉩니다.

      ৹  커밋되지 않은 언두 정보( 활성 )   

          - 현재 실행 중인 트랜잭션을 지원하며 유저가 롤백하려는 경우나 트랜잭션이 실패한 경우에 필요합니다.

          - 커밋도지 않은 언두 정보는 겹쳐쓰이지 않습니다.

      ৹  커밋된 언두 정보( 만료되지 않음 )

          - 실행 중인 트랜잭션을 지원하는 데는 더 이상 필요하지 않지만 언두 Retention 간격을 만족시키는 데에는 여전히

             필요합니다.

          - 커밋된 언두 정보는 활성 트랜잭션이 공간 부족으로 인해 실패하는 일이 없도록 하는 한도 내에서 보존됩니다.

      ৹ 만료된 언두 정보 ( 만료됨 )

          - 실행 중인 트랜잭션을 지원하는데 더 이상 필요하지 않습니다.

          - 만료된 언두 트랜잭션은 활성 트랜잭션에서 공간이 필요하면 겹쳐쓰입니다.

    

 

 

 

2. 보장

    • 기본적으로 언두 작업은 undo space 부족으로 인해 활성 트랜잭션이 실패하도록 허용하기보다는 아직 만료되지 않은

       커밋된 트랜잭션의 언두 정보를 겹쳐 씁니다.

    • Retention을 보장하면 언두 Retention 설정으로 인해 트랜잭션이 실패하더라도 언두 Retention 설정을 시행합니다.

    • RETENTION GUARANTEE는 초기화 파라미터라기보다는 테이블스페이스 속성입니다.

    • RETENTION GUARANTEE 속성은 SQL 명령문을 통해서만 변경할 수 있습니다.