Query 실행순서(update)

다음의 Query의 실행순서는 어떻게 될까요?

update emp
set sal = sal + 100
where empno = 7788

parsing

select 문의 parsing과 같다. (참조)


execute

1. data block 및 undo block을 읽어서 database buffer cache에 올려놓는다.(undo의 공간이 부족하면 에러남)

2. database buffer cache에 row level lock을 건다.

3. redo log buffer에 redo entry를 생성한다.(내가 무슨 짓을 한다.를 기록)

4. undo data 생성
   - 변경전 데이터를 undo segment에 기록

5. user data 수정


rollback; 의 경우
undo data로 user data를 덮어씀

commit; 의 경우
Buffer cache 정리(lock 해제, 메모리의 변경 확정)
redo log buffer의 내용을 redo log file로 내려쓴다.


fast commit
database buffer cache의 내용을 정리.
그것과 관련된 redo log buffer의 내용 redo log file로 내려씀
dirty buffer들은 여전함(데이터파일과 버퍼의 내용이 다름)

instance recovery:
문제가 생겼을 경우 startup시에 복구
리두로그파일을 읽어서 복구
인스턴스가 죽기 직전의 상황으로.. 
ORACLE_SID -> spfileSID.ora -> Instance 구성 -> Control file read -> data file, redo log file read
   -> INSTANCE Recovery

기타 참고사항
- undo 영역 관련 쿼리
   select * from dba_rollback_segs;

- undo를 남길 여지가 없을 경우 DML에러가 남.

- undo 전문적으로 예전의 데이터를 보관하는 공간.

- redo는 복구시에만 필요함.

- 블럭 : datafile의 블럭
   버퍼 : database buffer cache의 블럭
            종류
          - free : start up이래로 한번도 바뀐적이 없는 버퍼
          - pinned : 지금 보고있거나 바꾸고 있는 버퍼(일종의 lock). 재이용 불가능
          - dirty : 원본과 내용이 다른 버퍼. pinned에서 수정이 완료된 버퍼. 재이용 불가능.
          - clean : 재이용 가능 버퍼.


- DBWn : 데이터베이스로 모아서 내려쓰는 역할
- LGWR : 데이터베이스로 모아서 내려쓰는 역할

- DBWn, LGWR의 사명
   : 사용 가능 메모리(Database buffer cache, redo log buffer)가 많아지도록 항상 내려씀.
     왜? user process, server process가 원활하게 작업할 수 있도록. 3초마다(파라미터 값에 따라 조정가능 함)


- 시스템 테이블 스페이스
- 유저 테이블 스페이스
- undo 테이블 스페이스
   - undo segment

- DBWn, CKPT
  빈집털이 공범
  DBWn가
  CKPT가 신호를 보내고, 끝나고 검사.(Control file과 Data file에 씀)


SCN(system change number)
  참고 : http://aozjffl.tistory.com/165