Undo 테이블스페이스, Redo Log 파일

 

Undo (Rollback)

- 트랜잭션을 이전 상태로 되돌리는 것
- 작업을 시작하기 전의 상태를 의미

 

Redo

- 이전 상태로 되돌아간 후, 실패가 발생하기 전까지의 과정을 그대로 따라가는 것
- 시스템 복구를 위해 시스템에 로그를 기록
- redo 정보는 항상 실제 작업보다 먼저 보관되어져야 함

 

 

Update, Insert, Delete DML작업 발생시

Undo : 데이터베이스 버퍼 캐시의 데이터(이전 이미지) → 언두 세그먼트

Redo : 리두 로그 버퍼(변경 작업에 대한 리두로그 정보)  → 리두 로그 파일에 저장

 

 

---

## Undo 테이블스페이스

• Transaction rollback
  • 커밋을 수행하지 않은 작업에 대해 롤백을 수행하면 수행전의 데이터로 복구

 

• Read consistency 유지
  • 커밋 또는 롤백되기 이전 변경 작업을 수행하는 사용자 이외에 다른 모든 사용자는 이전 값을 참조

 

• Transaction recovery
  • 완료되지 않은 상태의 트랜잭션이 비정상 종료되는 경우 데이터베이스가 재 기동되는 시점에 커밋되지 않았던 데이터를 원래값으로 복원

 

 

※ Undo segment

- 언두 테이블 스페이스 내부에 생성되는 세그먼트, 임의의 트랜잭션을 실행하는 경우 변경 이전의 값을 저장

 

 

## Undo 테이블스페이스 관리

• 자동 언두 관리  (Autometic undo management)
  
  • 커밋을 수행하지 않은 작업에 대해 롤백을 수행하면 수행전의 데이터로 복구

 

• 인위적 언두 관리 (Manual undo management)
  
  • 커밋 또는 롤백되기 이전 변경 작업을 수행하는 사용자 이외에 다른 모든 사용자는 이전 값을 참조

 

## Undo 데이터의 보관/유지기간

 

▶ undo_retention 파라미터

- Undo 데이터의 보유 기간을 결정

- UNDO_RETENTION을 설정한 후에도 UNDO 테이블스페이스의 크기가 너무 작으면 지정한 시간 동안 Undo 데이터를 유지할 수 없음

- 대용량 이관작업이 있을때 undo tablespace의 상승으로 성능적 이슈가 발생

  보통 이럴때는 여분의 datafile을 추가하는 방법을 쓰지만 datafile이 부족하여 추가가 불가할 경우

   undo tablespace를 비워주면 임시로 undo tablespace가 100%에 도달하여 성능적 이슈가 발생하는것을 방지가능

- UNDO_RETENTION 기간보다 오래된 UNDO 정보는 Expired상태로 되며 해당 공간은 새로운 트랜잭션으로 채우기 가능

 

 

현재 자동 언두 관리 모드로 설정되어 있으며 데이터를 보존 최소 기간은 900으로 설정

 

 

 

 

▶  GUARANTEE VS NOGUARANTEE

select RETENTION from DBA_TABLESPACES where tablespace_name ='UNDOTBS1';

 

guarantee  : 언두 유지 시간 엄격히 적용

noguarantee : 언두 유지 시간을 엄격하게 적용하지 않고 테이블 스페이스 크기와 연관하여 관리

 

 

 

 

▶ 현재 Undo 사용량 조회

 

select STATUS, sum(bytes)/1024/1024 MB from dba_undo_extents group by status;

 

※ undo 익스텐트 상태

ACTIVE : 현재 UNDO 데이터를 기록하고 있는 상태
UNEXPIRED : undo_retention 시간을 초과하지 않은 Extent. 사용 중인 트랜잭션이 없으나, 언두 유지 시간이 완료되지 않아서 트랜잭션에 할당되지 않고 보존되어 있는 상태
EXPIRED :  UNDO_RETENTION값이 지난 값으로 UNDO 부족시 rewrite 될 수 있는 영역

FREE : 트랜잭션에 한 번도 할당되지 않았거나, SMON에 의한 주기적 정리가 완료되어 있는 상태

 

 

---

## Redo Log 파일 

 

 

## 저장되는 정보

• DML, DDL문에 의해 발생된 모든 변경 사항
• DML 문장은 저장 X
• DDL 문장은 저장 됌
• Recursive SQL 문장에 의해 발생된 모든 변경사항

 

Recursive SQL : 사용자가 실행하는 SQL 문장이 아닌 오라클 내부적으로 수행되는 내부 SQL

 

## 리두 로그 덤프 정보 확인

 

CREATE TABLE TEST_EXAMPLE_TB (
  2      seq_no NUMBER NOT NULL,
  3      data1 VARCHAR2(100),
  4      data2 VARCHAR2(100)
  5  );

Table created.

SQL> alter system switch logfile;

System altered.

SQL> col first_change# format 9999999999999
SQL> col member format a60
SQL> set linesize 140
SQL> select a.first_change#, a.status, b.member
  2  from v$log a, v$logfile b
  3  where a.group#=b.group#
  4  /

 FIRST_CHANGE# STATUS           MEMBER
-------------- ---------------- ------------------------------------------------------------
       2799959 INACTIVE         /app/oracle/oradata/ORA19C/redo02.log
       2852461 CURRENT          /app/oracle/oradata/ORA19C/redo01.log
       2807849 ACTIVE           /app/oracle/oradata/ORA19C/redo03.log

SQL>


alter system dump logfile '경로' scn min (firstchange번호);

 

 

로그 파일이에 기록되어 있는 정보 확인 가능

 

 

 

## 리두 로그 버퍼로부터 리두로그 파일에 내려 적히는 조건

• 마지막으로 LGWR가 내려 적힌 후 3초 이후
• 로그 버퍼 전체 크기가 3/1이 채워지는 경우
• 사용자가 commit 명령을 수행했을 때
• DBWR이 LGWR에게 쓰기를 요청할 때
  •  DBWR가 더티버퍼를 데이터 파일로 내려적힐 때 더티버퍼와 연관된 리두 로그 정보가 리두 로그 파일에 저장되지 않았을 경우 내려적으라는 신호를 주게 됌
• 리두 로그 스위치가 발생할 때