wif LiNoUz/Oracle,Sql

Undo 정리

크라소니 2014. 6. 19. 09:42


http://jhroom.co.kr/index.php?mid=db_oracle&page=2&document_srl=23306




===========================================================================================================================================
-- Ref 워크샵 1교재 9-4에서 9-15 발췌
-- Ref pdf파일 >> D45639 의 p272
===========================================================================================================================================
본문의 내용은 Oracle Database 10g : Administration WorkshopⅠ 공식교재에서 발췌 
===========================================================================================================================================
데이터 조작(Managing Undo Data)
데이터 조작어(DML)는 다음 SQL 문으로 구성됩니다.
 - INSERT
 - UPDATE
 - DELETE
 - MERGE

DML은 항상 트랜잭션의 일부로 실행되며 다음과 같이 될 수 있습니다.
 - ROLLBACK 명령을 사용하여 롤백됨
 - COMMIT 명령을 사용하여 커밋됨

데이터는 DML 클래스에 속하는 SQL 문인 insert, update, delete 및 merge에 의해  
조작되거나 수정됩니다.이러한 명령문은 트랜잭션의 일부로 실행되며 성공한 첫번째 DML
문으로 시작되고 COMMIT 또는 ROLLBACK 명령으로 끝납니다. 트랜잭션은 전체적으로
커밋되거나 전체적으로 롤백됩니다.
롤백은 프로세스 또는 시스템 failure 시에 발생할 수도 있습니다.

===========================================================================================================================================
-- undo data
===========================================================================================================================================

- 언두 데이터는 다음의 특징을 갖습니다.
1. 수정되기 전 원래 데이터의 복사본입니다. 
2. 데이터를 변경하는 모든 트랜잭션에 대해 캡처됩니다. 
3. 적어도 트랜잭션이 종료될 때까지는 보존됩니다. 
4. 지원하는 작업:
 - 롤백작업
 - 일기 일관성 및 Flashback Query
 - 실패한 트랙잭션 recovery

※ 복구

인스턴스 복구

 미디어 복구

시스템 또는 오라클이 비정상 종료한 
후 재기동시 발생하는 복구 방식. 
절차를 수행하여 데이터 정합성을 
보장하게 된다.

백업을 수행한 테이터베이스를 
이용하여 복구를 수행하는 경우를 
의미한다.

프로세스로 인해 데이터베이스의 데이터가 변경되는 경우 오라클 데이터베이스는 원본의 수정되기 이전값(undo data)을 저장합니다.
언두 데이터를 캡쳐하면 커밋되지 않은 데이터를 Rollback할 수 있습니다. 또한 언두는 읽기 일관성 및 Flashback Query를 지원합니다.


읽기 일관성 Query는 query가 시작된 시점의 데이터와 일치하는 결과를 제공합니다. 읽기 일관성 query가 성공하려면 원래 정보가 
계속 언두 정보로 존재해야 합니다. 언두 정보를 보존하고 있는 동안 오라클 데이터베이스는 읽기 일관성 query가 충족되도록 데이터를
재구성할 수 있습니다.

Flashback Query는 어떤 목적을 가지고 과거 특정 시점의 데이터 버전을 요청하는 query입니다. 요청한 과거 특정 시점에 대한 언두 정보가 
있는 경우 Flashback Query를 성공적으로 완료할 수 있습니다.

사용자가 트랜잭션의 커밋 또는 롤백을 결정하기 전에 네트워크 오류/클라이언트 컴퓨터 오류(장애)로 인한 사용자의 세션이 비정상적으로 
종료되는 경우 트랜잭션이 실패하는데 언두데이터를 통한 트랜색션을 recovery할 수 있습니다. instance crash가 발생하는 경우에도 트랜잭션이
실패할 수 있습니다.

실패한 트랜잭션의 경우 가장 안전한 동작이 선택되며 오라클 데이터베이스는 유저가 수행한 모든 변경 사항을 보존하고 원본 데이터를 복원합니다.

언두 데이타 정보 보존
 - 사용자의 트랜잭션 언두(롤백)
 - 사용자의 트랜색션 종료(커밋)
 - 사용자 세션의 비정상적인 종료(롤백)
 - 종료 명령에 의한 사용자 세션의 정상적인 종료(커밋)
보존되는 언두 데이터의 양과 보존 기간은 데이터베이스 작업량과 데이터베이스 구성에 따라 다릅니다.

언두 세그먼트의 생성 시기와 크기 할당
When generating? 
 -  DML 명령문이 수행 시  

 



※ Undo Segment - Transaction Table slot

 


출처: http://bysql.net/?mid=w201002&entry=5.%20Undo

※ 블록 헤더 ITL 슬롯
다음은, 블록에 저장되는 ITL슬롯에 대해 살펴보자.

 

트랙잭션을 시작하기 위해서는 UNDO 세그먼트의 트랜잭션 테이블로부터 슬롯을 할당받아야 함을 앞에서 살펴 보았다.
그럼, 트랜잭션이 시작되고 실제 데이타를 갱신하기 위해서는 어떻게 될까?
역시, 비슷한 원리로, 특정블록에 있는 레코를 갱신할때는 그 블록헤더로부터 슬롯(ITL슬롯)을 확보해야 한다.
만약, 어떤 트랙잭션에 의해 이 블록의 데이터가 갱신중이라면, 그 트랜잭션이 종결(커밋 또는 롤백)될 때까지 기다려야 된다.
(블로킹상태)

해당 트랜잭션이 종결(커밋or롤백)된 후 비로소, 해당 블록으로 부터 ITL슬롯을 할당 받아 자신의 트랜잭션을 계속 진행할수 있게 된다.
오라클은 ITL슬롯 부족으로 인한 트랜잭션 블로킹을 최소화하고자 다음과 같은 옵션을 제공한다.

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

ITL(Interested Transaction List)슬롯에 기록되는 내용은 다음과 같다.
 
 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. 그 순간은 동시성이 현저히 저하.

===========================================================================================================================================
출처 : http://www.gurubee.net/display/DBSTUDY/Undo?
===========================================================================================================================================
1. Undo
 - 트랜색션이 발생시킨 테이블과 인덱스에 대한 변경사랑들이 Undo 레코드 단위로 Undo 세그먼트(블록)에 기록
 - 트랜잭션 : Undo 세그먼트 → N : 1
   9i부터는 AUM에 의해 1:1을 목표로 자동 관리

2. Undo의 목적

목적설명
Transaction Rollback 
Transaction RecoveryInstance Recovery 시 Rollback 단계
Read Consistency다른 DBMS 는 Lock 을 통해 구현

3. Undo 세그먼트
 - Undo 세그먼트는 일반 테이블 세그먼트와 다르지 않다.
 - Undo 세그먼트의 블록도 버퍼캐시에 캐싱

4. 버전별 Undo 기능 

 버전

목적 

관리  

공간관리 

비고 

 8i

 

Rollback Segment (CREATE, ONLINE, OFFLINE) 수동

현재 세그먼트가 꽉차면 어레 발생

Undo 테이블스페이스가 꽉차면 에러 발생 

 9i

AUM(Automatic Undo Management),
Dynamic Extent Transfer, Undo Retention

Rollback Segment
(CREATE, ONLINE, OFFLINE) 자동

현재 세그먼트가 꽉차면 다른 세그먼트로부터 공간을 빌려옴 

 

 10g

Retention Guarantee, 
Automatic Undo Retention Tuning

 

 

 


undo_management (파라미터)

undo_retention (파라미터)
 - 트랜젝션이 완료 되었어도 지정된 시간(초) 동안은 가급적 Undo 세그먼트를 재사용하지 않도록 함 
   (active → unexpired → expired)

dba_tablespaces.retention (테이블스페이스 속성)
 - alter tablespace undotbs1 retention (guarantee, noguarantee);

Automatic Undo Retention Tuning (tuned_undo_retention)
 - 10gR1 - undo_retention 을 0 으로 설정
 - 10gR2 - Undo 테이블스페이스의 retention 속성을 noguarantee 로 설정

5. Undo 세그먼트

 Undo 헤더(Initial Extent)
 - Transaction Table 슬롯

컬럼내용비고
Transaction IDUSN# + Slot# + Wrap#USN : Undo Segment Number
Transaction Status상태정보COMMITTED, ACTIVE
Commit SCN 트랜잭션이 커밋된 경우
Last UBAUndo 레코드 체인을 유지하는 일종의 포인터UBA: Undo Block Address
기타  

 - 트랜잭션의 시작/종료  

상태Transaction Table 슬롯비고
시작슬롯을 할당 받고, Status 를 ACTIVE 로 변경슬롯을 얻지 못한경우 undo segment tx slot (대기이벤트) 발생
종료Status 를 COMMITTED 로 변경, Commit SCN 저장 

Undo 레코드

DML내용
INSERT추가된 레코드의 ROWID
UPDATE변경된 컬럼에 대한 Before image
DELETE삭제된 ROW의 모든 컬럼에 대한 Before image

Undo 레코드 체인
 - Last UBA 로 구성

6. v$transaction

컬럼내용비고
used_ublkUndo 블록수 
used_urecUndo 레코드수인덱스는 UPDATE 시 2씩 증가 (내부적으로 DELETE & INSERT)


7. 블록 헤더 ITL 슬롯(24 Byte) 

컬럼내용비고
ITL 슬롯 번호  
Transaction ID  
UBAUndo Block AddressCR 블록을 생성할때 사용
Locking 정보  
커밋 SCN  

   레코드를 갱신 하기 위해서는, 해당 블록 헤더 ITL 슬롯 확보
    - ITL 슬롯 확보 될때까지 enq: TX - allocate ITL entry (대기이벤트) 와 함께 트랜잭션이 블로킹됨
    - ITL 슬롯 부족을 극복하기 위해, INITTRANS, MAXTRANS, PCTFREE 파라미터 활용
       → 10g 부터 INITTRANS 는 최소2, MAXTRANS 는 255 고정
       → 블록에 여유공간이 없는경우 추가 슬롯 생성이 불가능 (PCTFREE)

8. Lock Byte
레코드가 저장되는 ROW마다, 헤더에 Lock Byte를 할당해, 트랜잭션의 ITL 슬롯 번호를 기록해 둔다. (Row-level Lock)

레코드 갱신 시도시

순서대상값동작비고
#1레코드의 헤더Lock ByteTRUE 인 경우 다음 단계 진행FALSE 인 경우 레코드 갱신
#2ITL 슬롯Transaction ID값을 얻어 다음 단계 진행 
#3Transaction Table 슬롯StatusCOMMITTED 인 경우 레코드 갱신ACTIVE 인 경우 대기


   
  - DBMS 별 레코드 정보 관리

DBMS레코드 정보 관리 방법Lock 에스컬레이션비고
오라클레코드 속성없음별도 리소스 사용 없음
다른 DBMSLock 매니저있음 

※ 참조문서
블로그(오라클 성능 문제에 대한 통찰) : http://ukja.tistory.com/252
위키(오라클클럽) : http://wiki.oracleclub.com/pages/viewpage.action?pageId=3900637
서적(오라클 성능 고도화 원리와해법 I) : http://book.daum.net/detail/book.do?bookid=KOR9788996246015

===========================================================================================================================================
※ 사용중인 Undo Block 수/Undo record 양
SQL> select s.sid, s.serial#, t.xidusn, t.used_ublck, t.used_urec
     from v$session s, v$transaction t
     where t.addr=s.taddr;

※ DML별 Undo 레코드 기록 내용
 - Insert: 추가된 레코드의 rowid
 - Update: 변경되는 컬럼에 대한 before imgae
 - Delete: 지워지는 모든 로우의 모든 컬럼에 대한 before image

※ Undo 관련 Parameter
 - UNDO_MANAGEMENT(default Auto)
 - UNDO_RETENTION (default 900)

언두 세그먼트의 자동 확장 /축소

 

 - undo tablespace는 instance당 하나만을 가진다.
 - undo tablespace는 (1-10)개로 이루어져 있으며, 이중 하나는 system사용 공간이다.
 - undo segment는 최소 2개의 extend를 할당받는다.

 - session에 따른 segment space의 할당 방식
 - 하나의 undo segment는 여러개의 TX(session A, session B)를 보유할 수 있다.
 - 하나의 TX는 하나의 undo segment만을 이용할 수 있다.

언두 세그먼트의 축소
 - 언두 세그먼트를 절단(Truncate)했을 경우
 - 언두 세그먼트에 Shrink를 수행했을 경우(수동으로 언두 세그먼트 축소시키는 옵션)
 - 언두 세그먼트에 Optimal 크기를 할당했을 경우(12시간 마다 자동으로 비사용 EXTENT 반납)

===========================================================================================================================================
트랜잭션 및 언두 데이터
 - 각 트랜색션은 하나의 언두 세그먼트에만 할당.
 - 하나의 언두 세그먼트는 한 번에 여러개의 트랜잭션을 처리할 수 있습니다.

트랜색션이 시작되면 해당 트랜잭션은 언두 세그먼트에 할당되며, 트랜잭션이 진행되는 동안 데이터가 변경되면 변경되기 전 원래의 값이 
언두 세그먼트에 복사됩니다.

Dynamic Performance View → v$transaction을 확인하여 어느 트랜잭션이 어느 언두 세그먼트에 할당되었는지 알 수 있습니다.
언두 세그먼트는 데이터 블록으로 구성된 Extent로 구성, 필요한 경우 자동으로 확장/축소(shrink)되며 활당된 트랜잭션에 대해 
순환 저장 버퍼처럼사용 됩니다. 모든 Extent가 사용된 후에 트랜잭션은 첫번째 Extent로 다시래핑(wraps around back)하거나 
언두 세그먼트에 새 Extent를 할당할 것을 요청합니다.

Note: Parallel DML 작업으로 인해 실제로 트랜잭션이 두 개 이상의 세그먼트를 사용할 수 있습니다.
Parallel DML 실행에 대한 자세한 내용은 Oracle Database Administrator’s Guide 10g를 참조하십시오

===========================================================================================================================================언두 정보 저장
언두 정보는 언두 세그먼트에 저장되며 언두 세그먼트는 하나의 언두 테이블스페이스에 저장됩니다. 
언두 테이블스페이스의 특징은 다음과 같습니다. 
 - 언두 세그먼트에만 사용됩니다.
   언두 세그먼트는 항상 SYS가 소유하며, 세그먼트는 순환 버퍼처럼 사용되므로 각 세그먼트는 최소 두 개의 Extent를 갖는다.
   최대 Extent 수의 기본값은 데이터베이스 블록 크기에 따라 다르지만 매우 큽니다.(블록 크기가 8KB인 경우 32,765개)
 
 - recovery 시 특별한 고려 사항이 있습니다.
   instance crash 등으로 인해 실패한 트랜색션을 recovery하는 경우에는 언두 데이터가 필요하므로 언두 테이블스페이스는 instance가 MOUNT 상태
   일 때만 recovery할 수 있습니다.

 - 단일 instance와만 연관됩니다.

 - 여러 언두 테이블스페이스 중 하나만 주어진 시간에 주어진 instance에 대해 현재 쓰기가 가능해야 합니다.
   데이터베이스에는 여러 언두 테이블스페이스가 있을 수 있지만 특정 시점에서 그 중 하나만 언두 데이터가 기록되는
   현재 언두 테이블스페이스로 지정될 수 있습니다.

언두 테이블스페이스는 자동 Extent 할당을 사용하는 영구적인 로컬관리방식의 테이블스페이스로, recovery 방법을 제외하고 다른 테이블스페이스와 
같은 방법으로 관리됩니다.

===========================================================================================================================================언두 데이터와 리두 데이터 비교

 

 

언두

리두 

기록내용 

변경 사항을 언두하는 방법 

변경 사항을 재생성하는 방법 

사용목적 

롤백, 읽기 일관성 

데이터베이스 변경 사항 롤포워드 

 저장위치  

언두 세그먼트 

리두 로그 파일 

보호대상 

다중 유저 시스템에서 일관성 없는 읽기가 발생하지 않도록 보호 

데이터 손실이 발생하지 않도록 보호 

언두 데이터는 변경사항을 언두해야 하는 경우에 필요하며 읽기 일관성 및 롤백에 대해 발생합니다.
리두 데이터는 데이터를 분실하여 변경 사항을 다시 수행해야 하는 경우에 필요합니다.

커밋 프로세스는 트랜잭션의 변경 사항을 디스크에 영구 저장되는 리두 로그 파일에 기록되는지 검증합니다.
변경 사항(테이블의 블록)이 실제로 저장되는 데이터 파일(*.dbf)에 기록되지 않아도 변경 사항이 리두 로그 파일에 기록됩니다.
(참고: Before DBWn writes → LWRn는 redo log buffer에 변경 트랜잭션 정보인 redo entry를 리두 로그 파일에 기록합니다.)

커밋된 변경 사항이 데이터 파일에 반영되기 직전에 정전이 발생해도 트랜잭션이 커밋된 상태(리두로그파일 기록)이기 때문에 instance를 
다시 시작하면 SMON(Background Process) 프로세스는 리두 로그 파일로 Roll forward를 하며, 언두 데이타로 Roll back을 하고, 
Control file의 SCN과 Data file의 SCN을 맞춰 동기화를 시킨다.(instance recovery)

===========================================================================================================================================언두 모니터
일반적으로 언두는 관리가 거의 필요 없으며 다음과 같은 영역을 모니터합니다.
 - 언두 테이블스페이스의 사용 가능한 공간
 - "Snapshot too old" 오류

대부분의 경우 언두는 instance에 의해 자동으로 관리되므로 데이터베이스 관리자(DBA)의 개입이
거의 필요하지 않습니다. 다음과 같은 경우 관리자의 개입이 필요할 수 있습니다.
 - undo space가 부족한 경우 → v$undostat(10분마다)

 


TX양 = UNDO의 양 

- 유저가 ORA-01555 snapshot too old 오류 메시지를 수신하는 경우

언두 정보는 항상 트랜잭션이 종료될 때까지 보존됩니다. 그러므로 매우 큰 데이터를 커밋하지 않고 삭제 또는 갱신
(삽인된 데이터는 원래 이미지가 NULL 값이므로 삽입 작업은 undo space를 거의 사용하지 않음)
하는 경우에는 언두 테이블스페이스가 원본 데이터를 포함할 만큼 커야 합니다.

다음 명령으로 50GB의 테이블에 있는 모든 행을 삭제한다고 가정해 보자.
SQL> delete from reallybigtable;

이 명령문을 실행한 사용자는 롤백을 하려면 언두 테이블스페이스의 공간을 원본(변경전 데이타의 크기) 정보에 대한 공간을 확보해야 합니다.
언두 테이블스페이스에 대한 공간 부족시 오라클은 사용자에게 'ORA-01650: unable to extend rollback segment' 오류 메시지를 수신합니다.

사전 모니터(Proactive Monitoring)를 통해 언두 테이블스페이스의 공간 문제가 유저에게 영향을 주기 전에 감지할 수 있습니다.

관리자가 언두 정보와 관련하여 직면할 수 있는 또 다른 문제는 query가 이미 겹쳐쓴 언두 정보에 액세스해야 하는 경우입니다. 
이 문제는 장기 실행되는 query 또는 Flashback Query에서 발생할 수 있습니다. query에 과거 특정 시점의 데이터 "스냅샷"이 필요하고 
이 스냅샷을 재구성하는데 더 이상 존재하지 않는 언두 데이터가 필요한 경우 query는 다음 오류를 반환합니다. 
ORA-01555: snapshot too old

read consistency가 깨지는 경우라고 할 수 있습니다. 따라서 언두 retention은 장기 실행 query를 수용하도록 구성되어야 합니다.

===========================================================================================================================================언두 관리

언두 관리를 통해 다음 오류를 방지해야 합니다.
 - 언두 테이블스페이스의 공간 오류 (ORA-01650: unable to extend rollback segment)
   ① 언두 테이블스페이스 크기를 적절히 조정
   ② 대형 트랜잭션을 주기적으로 커밋

 - "Snapshot too old" 오류 (ORA-01555: snapshot too old)
   ① 적절한 언두 retention 간격 구성
   ② 언두 테이블스페이스의 크기를 적절히 조정
   ③ 언두 retention 보장을 고려

자동 언두 관리 사용
 - UNDO_MANAGEMENT=AUTO (권장)
 - UNDO_TABLESPACE=UNDOTBS1

DBA는 자동 언두 관리를 사용하여 테이블스페이스 레벨에서 언두를 관리하고 instance가 사용하는 테이블스페이스를 언두하는 
UNDO_TABLESPACE 초기화 파라미터를 사용하여제어합니다. 
언두 테이블스페이스를 선택한 경우 관리자는 충분한 공간을 제공하고 언두 retention 간격을 구성하는 데만 신경쓰면 됩니다.
수동 관리를 사용하는 경우 DBA는 다음 사항도 고려해야 합니다.
 ① 최대 Extent 수 및 Extent 크기 조정을 포함한 세그먼트 크기 조정
 ② 차단 중인 트랜잭션 식별 및 제거
 ③ 트랜잭션 처리에 충분한 롤백 세그먼트 생성 (수동 모드에서는 언두 세그먼트를 롤백 세그먼트라고 함)
 ④ 롤백 세그먼트를 포함할 테이블스페이스 선택 (언두 테이블스페이스는 자동 언두 관리와함께 사용할 때만 지원됨)

===========================================================================================================================================언두 세그먼트의 종류 및 관리 방식
언두 세그먼트의 종류
 - 시스템 언두 세그먼트
   시스템 테이블스페이스에 존재하는 오브젝트가 변경될 경우 사용되는 
   언두 세그먼트 데이터베이스 생성시 시스템테이블스페이스에 자동으로 생성된다.

 - 비 시스템 언두 세그먼트
   일반 유저의 DML 작업시 언두 데이터를 저장하기 위해 사용

 - 지연 언두 세그먼트
   오프라인, 임시 For Recovery상태 진행중인 작업에 대해 복구를 수행하기 위해
   해당 테이블스페이스에 대한 언두 세그먼트를 생성

언두 세그먼트 관리 방식 

종류

자동 언두 관리  

수동 언두 관리 

관리주체 

오라클 커널  

데이터베이스 관리자 

언두 세그먼트 

자동 관리 

수동 관리 

Snapshot관리 

언두 테이블스페이스 증가
UNDO_RETENTION 파라메터 조정으로 에러 감소

언두 테이블스페이스 증가 및 언두 세그먼트 크기와 개수 조절 필요 

===========================================================================================================================================언두 테이블스페이스 관리
언두 테이블스페이스 변경
 - 데이터베이스 생성 시 언두 테이블스페이스 생성
 - 데이터베이스 생성 후 언두 테이블스페이스 생성

언두 테이블스페이스 제거 
 - 데이터 파일 추가
 - 데이터 파일 이름 변경
 - 데이터 파일 상태 변경(온라인에서 오프라인으로 변경 시)

언두 테이블스페이스 교체
언두 테이블스페이스 생성(데이터베이스 생성 시)
SQL> create database test
     ...[생략]
     undo tablespace undoo_tbs
     datafile '/경로/xxx.dbf' size 100m;

언두 테이블스페이스 생성(테이터베이스 생성과 별도로 생성 시)
SQL> create undo tablespace undo_tbs
     datafile '/경로/xxx.dbf' size 100m;

언두 테이블스페이스 변경
SQL> alter tablespace undo_tbs
     add datafile '/경로/xxx.dbf' size 100m;

언두 테이블스페이스 삭제
SQL> drop tablespace undo_tbs;

언두 테이블스페이스 교체
SQL> alter system set UNDO_TABLESPACE=undo_tbs; 

 

===========================================================================================================================================언두 세그먼트 확인
언두 관련 내용을 확인 할수 있는 데이터 딕셔너리 뷰 및 동적 성능 뷰
 - DBA_ROLLBACK_SEGS 
   현재 데이터베이스에 존재하는 모든 언두 세그먼트에 대한 내용 조회
 
 - V$ROLLSTAT
   현재 데이터베이스에 존재하는 언두 세그먼트 중 온라인 상태인 언두 세그먼트에
   대한 내용 조회가 가능
  
 - V$ROLLNAME
   모든 언두 세그먼트의이름을 확인

 - V$UNDOSTAT
   언두 테이블스페이스에 대한 모니터링 및 튜닝을 위한 정보를 조회

===========================================================================================================================================언두 Retention 구성

UNDO_RETENTION은 이미 커밋된 언두 정보의 보관 기간을 초 단위로 지정합니다. 
UNDO_RETENTION 파라미터는 다음과 같은 경우에만 설정합니다.
 - 언두 테이블스페이스에서 AUTOEXTEND 옵션이 활성화된 경우
 - LOB에 대해 언두 retetion을 설정할 경우
 - retetion을 보장하려는 경우

AUTOEXTEND 언두 테이블스페이스의 경우 시스템은 최소한 이 파라미터에 지정된 시간 언두를 보관하고 
query의 언두 요구 사항을 충족하도록 언두 retention 기간을 자동으로 튜닝합니다.

고정 길이 언두 테이블스페이스의 경우 시스템은 언두 테이블스페이스 크기 및 과거 사용 기록에 따라 
가능한 최대 언두 retention 기간을 자동으로 튜닝하고 retenton 보장이 활성화되 않을 경우

UNDO_RETENTION을 무시합니다. 따라서 자동 언두 관리에서는 나열된 세 가지 경우에 UNDO_RETENTION 설정이 사용됩니다. 
이러한 세 가지 경우가 아니면 이 파라미터는 무시됩니다.
언두 정보는 다음의 세 가지 범주로 나뉩니다.

 - 커밋되지 않은 언두 정보: 현재 실행 중인 트랜잭션을 지원하며 유저가 롤백하려는 경우나
   트랜잭션이 실패한 경우에 필요합니다. 커밋되지 않은 언두 정보는 겹쳐쓰이지 않습니다.

 - 커밋된 언두 정보: 실행 중인 트랜잭션을 지원하는 데는 더 이상 필요하지 않지만 언두
   retention 간격을 만족시키는 데에는 여전히 필요합니다. "만료되지 않은" 언두 정보라고도 합니다. 
   커밋된 언두 정보는 활성 트랜잭션이 공간 부족(ORA-01650)으로 인해 실패하는 일이 없도록 
   하는 한도 내에서 보존됩니다.

 - 만료된 언두 정보: 실행 중인 트랜잭션을 지원하는 데 더 이상 필요하지 않습니다. 
   만료된언두 트랜잭션은 활성 트랜잭션에서 공간이 필요하면 겹쳐쓰입니다.

 

 

기본적으로 언두 작업은 undo space 부족으로 인해 활성 트랜잭션이 실패하지 않도록 아직 만료되지 않은 커밋된 트랜잭션을 겹쳐씁니다.
이 작업은 retention을 보장하여 변경할 수 있습니다. retention을 보장하면 언두 retention 설정으로 인해 트랜잭션이 실패하더라도 
언두 retention 설정을 시행합니다.

RETENTION GUARANTEE는 초기화 파라미터라기보다는 테이블스페이스 속성입니다. 이 속성은 SQL 명령행 문을 통해서만 변경할 수 있습니다. 
retention을 보장하도록 언두 테이블스페이스를 변경하는 구문은 다음과 같습니다.
SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;

보장된 언두 테이블스페이스를 일반 설정으로 되돌리려면 다음 명령을 사용하십시오.
SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;

retention 보장은 언두 테이블스페이스에만 적용됩니다. 비언두 테이블스페이스에 retention 보장을
설정하려고 하면 다음 오류가 발생합니다.
SQL> ALTER TABLESPACE example RETENTION GUARANTEE;
ERROR at line 1:
ORA-30044: 'Retention' can only specified for undo tablespace

※ GUARANTEE 설정 확인 
SQL> select tablespace_name, retention
     from dba_tablespaces
     where tablespace_name='UNDOTBS1';

===========================================================================================================================================

 

언두 테이블스페이스의 크기 조정
언두 테이블스페이스에 모든 트랜잭션의 원래 정보가 포함될 수 있도록 언두 테이블스페이스 크기를 조정해야 합니다.
Enterprise Manager의 Administration 페이지에서 Undo Management 링크를 누르면 현재 설정, 
분당 언두 사용량 및 지정한 기간 동안 발견된 가장 오래 실행 중인 query를 포함하여 시스템 언두의 개요를 확인할 수 있습니다.

언두 테이블스페이스에 속한 데이터 파일에 공간이 부족하면 데이터 파일이 자동으로 확장될 수 있습니다. 
다른 테이블스페이스와 달리 언두 테이블스페이스에서는 연관된 데이터 파일의 자동 확장을 활성화하지 않을 것이 좋습니다.

undo space 데이터 파일 자동 확장 기능을 활성화할 수 있지만 테이블스페이스의 크기를 적절하게 조장한 다음에는 데이터 파일 자동 확장
기능을 비활성화해야 합니다. 비활성화하면 단일 사용자가 트랜잭션을 커밋하지 않아 실수로 디스크 공간을 많이 사용하는 것을 방지할 수 있습니다.

===========================================================================================================================================

 

Undo Advisor 사용
Undo Management 속성 페이지를 통해 Undo Advisor에 액세스할 수 있습니다. 또한 지정된 언두
retention을 만족시키는 데 필요한 언두 테이블스페이스 크기를 예측하여 제공합니다.
원하는 retention 기간을 입력하면 Advisor의 분석 영역에 retention 기간을 지원하는 데 필요한
테이블스페이스 크기가 표시됩니다. 또한 그래프의 한 지점을 눌러 선택한 기간을 지원하는 데
필요한 테이블스페이스 크기를 확인할 수 있습니다.
언두 retention 기간을 선택한 후에는 OK를 눌러 새 retention 기간을 구현합니다.