pat98's always & forever

1. REDO
 - 모든 변경사항을 REDO로그에 기록한다.
 - REDO로그는 Online REDO와 Archuved REDO로그로 구성된다.
    Online REDO 로그는 2개 이상의 파일로 구성되어 있어,
    현재 사용중인 로그 파일이 꽉 차면 다음 로그 파일로 스위칭
    이때 꽉 차여진 로그 파일을 다른 위치로 백업래 준 파일을 Archived REDO로그 이다.
 - 목적 3가지
  - 데이타 복구 : Archived REDO이용
  - 버퍼캐시복구 : 인스턴스가 비정상적종료시 그떄까지 작업내용이 잃어버리게 됨.
                          재기동 되면 Online REDO로그에 저장된 기록사항을 읽어와 마지막
                          채크포인트와 사고발생직전까지 수행한 트랜젹션을 재현
  - Fast Commit(IO속도 차 극복) : 데이타 버퍼 블록을 디스크에 기록하는 작업은 Random엑세스 방식,
                                              Append방식 Append방식이 상대적으로 빠르게 때문에 우선 변경사항을
                                              Append방식으로 기록하고 동기화는 후에 배치방식으로 일괄수행.
 - REDO로그 버퍼를 REDO로그에 기록하는 시점
  - 3초마다 DBWR프로세스부터 신호흫 받을때
  - 로그 버퍼의 1/3이 차거나 기록된 REDO레코드량이 1MB를 넘을떄
  - 사용자 커킷 또는 롤백 명령이 날릴때
  
2. UNDO
 - 각 트랜지션별로 UNDO세그먼트를 할당해주고 그 트랜지션이 발생시킨 테이블과 인댁스에
    대한 변경사항을 UNDO레코드 단위로 UNDO세그먼트 블록에 기록.
 - 목적 3가지
  - 트랜지션 롤백
  - 트랜지션 리커버리(인스턴스 리커버리시 롤백단계)
  - READ Consistency(읽기 일관성)
  타 DBMS는 Lock를 통해 일기 일관성을 구현하지만,
  오라클에서는 UNDO데이타를 이용해서 읽기 일관성을 구현한다.  
             읽기 일관성이란 Transaction이 진행되는 동안 Database의 다른 사용자는 이 Consistent Read에 의해
             Commit되지 않은 변경 사항을 볼 수 없는 기능 입니다.  
 - UNDO레코드에 기록되는 내용
  - Insert : 추가된 레코드의 rowid
  - Update : 변경되는 컬럼에 대한 before image
  - Delete : 지워지는 로우의 모든 컬럼의 대한 before image
------------------------------------------------------------------------------------
REDO 와 UNDO를 차이점에서 바라본 관점.
------------------------------------------------------------------------------------
REDO 는 UNDO를 포함 합니다.
REDO 는 시스템 장애시 복구를 위해 사용 합니다.
복구시에 UNDO 데이터도 같이 복구하구요. Commit 되지 않은 데이터를 Rollback 하게 됩니다.
UNDO 는 Rollback 시에도 사용 되지만 Read Consistency(읽기 일관성) 을 위해서 도 사용 됩니다.
REDO 는 모든 변경사항(UNDO 포함)을 기록 합니다.
복구는 UNDO 를 통해서 복구를 하게 됩니다. 즉, ROLLBACK을 한다는 말이죠.
시스템 장애가 발생하게 되면 UNDO 데이터도 모두 날아가게 되겠죠.
결국 시스템 장애시 REDO 데이터를 이용해서 마지막 CHECK POINT 부터 장애까지의 DB BUFFER CACHE 를 복구하게 됩니다.
이게 완료가 되면 UNDO DATA 를 이용하여 COMMIT 되지 않은 데이터를 모두 ROLLBACK 함으로써 복구를 완료하게 됩니다.
결국 REDO 가 UNDO 를 복구하고 최종적으로 UNDO가 복구를 하게 됩니다.
UNDO(안한것 처럼)는 되돌리는 것 이라고 보시면 될거에요.
어떤 세션에서 DML을 발생시키면 commit이나 rollback을 날리기 전까지 이전 정보를 저장하기 위해서
UNDO 블럭에 해당 정보를 기록하죠.. 해당 세션이 트렌젝션 중에 비정상적으로 종료가 되었다면,
안한것 처럼(UNDO) 다시 원복해야 되니까요.
REDO(다시 함)는 위에 설명에도 있듯이 인스턴스 실패시(DB가 내려감) 데이터 파일에 쓰여지지 않은 커밋된 데이터를 복구한다고 되어 있습니다.
좀 더 설명을 해드리자면 커밋을 날릴 경우 LGWR가 로그 파일에 변경된 정보를 기록하게 되고
그 다음에 DBWR이 버퍼캐쉬에 있는 변경 사항에 대해서 데이터 파일에 내려 쓰게 됩니다.
이는 복구 정보가 더 중요해서 그런 것이라고 이해하시면 됩니다(복구 정보가 있으면 재적용이나 되돌릴 수 있으므로).
DB가 비정상적으로 내려가면, 데이터 파일에 쓰여지지 않은 정보들이 리두로그에 기록되어 있으므로
리두로그에서 정보를 가져와 다시 적용(REDO)하는 것입니다.