시나리오별 내부진행상황

 1. isqlplus 를 통함 로그인
- connection이 없다면 user process는 서버측의 listner로 요청을 하게 되고 listner는 이 요청이 유효한지 판단하고 Server process로 전달함.(REDIRECT라고도 함)
- Server Process가 리스너로부터 받은 요청을 User process 측으로 응답해줌
- 로그인을 성공하면 Connection이 생성됨.

2. select * from emp; 을 실행할 경우 내부의 진행상황
일단 connection 해야함
- client측에서 user process를 생성
- userprocess는 server로 해당 문장을 요청함(request)
- server process는 instance를 통해 DB에 접속하려 함.
- 문장에 대해 SGA의 Shared pool의 Library cache에서
 ① Parsing 단계
 soft parse-이전에 사용된 문장이 있다면 검사를 진행하지 않음
 hard parse-⑴ syntax check:문장의 구조가 맞는지 확인
                  ⑵ symantics check: 스키마에 있는 오브젝트인지, 권한이 있는지 등 확인. 이때 RC에 이전에 검색했던 data dictionary가 있다면 더 빨리 처리.
                  ⑶ pased code 생성: 파싱이 완료되었다는 코드
                  ⑷ excution plan: optimizer가 실행함
 ② excute 단계
 결과값을 가지러 DB buffer cache를 검색함. 이전에 emp 테이블을 검색한적이 있다면 Server process는 메모리에서 바로 그 결과값을 가져갈 수 있음
 결과값이 있으면 cache hit=logical read, 없다면 cache miss=physical read: disk I/O 발생
 ③ fetch(인출) 단계
 fetch 단계는 select절에만 있음.

3. update emp set sal=5000 where sal=1500; 을 실행할 경우 내부의 진행상황
 ① User process가 명령을 받아 Server Process에게 요청.
 ② Parsing 단계
 ③ excute 단계
 실행이전엔  DB buffer cache에 1500이 기록되어 있음. 실행되면 DB buffer cache는  5000으로 변경되고 1500은 undo segment로 옮겨짐(before image. rollback과 read consistency를 위해)
※ cache: 순서에 따라 처리하는게 목적인 메모리
※ buffer:  순서에 상관없이 저장하는 목적의 메모리
※ buffer cache: 순서에 맞게 저장된 메모리

4. commit; 을 실행할 경우
서버프로세스에서 commit을 받으면 제일 먼저 반응하는 메모리가 Redo log buffer이다.
LGWR process에 의해 online redolog file에 기록을 남김(이게 완료되면 commited를 볼 수 있다).
그래도 db file의 값은 아직 1500이고 db buffer cache의 dirty buffer가 5000의 값으로 되어있으며
select로 조회를 하면 db buffer cache의 정보를 보여준다.
DBWR process에 의해 dirty buffer들이 data file로 옮겨진후 free buffer로 바뀐다.