Oracle 세미나 1차 과제 V1 0

1. Oracle 세미나 1차 과제 V1.0
날짜 : 2010.03.10
작성자 : 오마주 팀원
오마주 멤버 : 박상수, 심규원, 장익수, 이돈규, 신종익, 이민상, 황한태

2. '공유 가능한' SQL문에 대해서
과제 1차 책임자 : 이돈규
과제 2차 책임자 : 장익수
그외 오마주 멤버 참여

3.  Select 처리 과정
⑦Session Instance
Server Process ② ⑥
PGA
SGA
(Program Global Area) (System Global Area) Large Pool
Shared Pool Data Buffer Cache
Library Cache ⑤-1 Data
block
Data
block
Data
block
Rado
Java Pool
• SQL, SQL(recursive SQL) Log
① ③• Parse Test
• Execution Plan
Data
block
Data
block
Data
block
Buffer
⑧-1 Parsring Data Dictionary Cache
Data
Block
⑤-2
Data
Block
Data
Block
Execute • Row Cache Data
block
Data
Block
Data
block Streams Pool
• Object Information
Fetch • Security
Listener
Background Process
Cache
PMON SMON DBWn CKPT LGWR ARCn etc
LRU List hit
Select Age out
MRU
④ End
LRU
① Cache Oracle Database
⑧-2 miss
④-1 Online Offline Redo Log Feles
Parameter Control
FILE Data Files Redo
Files
Log
User Process Password FILE

4.  Select 처리 과정
1. User 프로세스 요청
• 서버 프로세스를 띄우기 위해서 리스너(일종의 프로세스)가 띄워져야 하는데 이 리스너의 역할
은 유저와 서버를 연결해 주고 연결 완료 후 바로 빠지고 다른 연결을 시작한다. 리스너와
INSTANCE는 1:1, N:1, N:N 작업이 가능하다.
• 유저 프로세스로부터 올바른 인스턴스명으로 접속요청이 오면 리스너는 서버 프로세스를 띄우
고 유저명과 암호를 넘기고 빠지고 암호가 맞으면 DB인증이 되고 틀리면 접속 실패 한다. 실직
적으로 유저 프로세스와 서버 프로세스가 연결이 되고 리스너는 또 다른 접속을 기다린
다.(Connection)
2. 서버 프로세스 요청 받음
• 서버 프로세스에서는 INSTANCE(출입구)쪽으로 세션 연결을 함(PGA를 통해서 연결)

5.  Select 처리 과정
1. PGA(Program Global Area)
• 데이터베이스에 접속하는 모든 유저에게 할당되는 각각의 서버 프로세스가 독자적으로 사용하
는 오라클 메모리 영역 – 이 영역으로 인해서 우리는 commit되기 전의 데이터를 각각의 유저가
볼 수 있다.
• PGA 구조
I. 정렬 공간 – group by, order by 등의 정렬을 수행 하기 위한 공간
II. 세션정보 – 결과 값 처리를 위한 유저 프로세스의 세션 정보
III. 커서상태정보 – 파싱 정보가 저장되어 있는 주소를 저장
IV. 변수저장공간 – 변수 사용시 변소를 저장하는 공간
2. SGA(System Global Area)

6.  Select 처리 과정
1. Shared Pool
1) Library Cache - DB에 접속한 유저가 실행한 SQL 및 SQL에 대한 분석 정보 실행 계획이 저장됨
2) Dictionary Cache – 테이블 정보, 인덱스, 인덱스 함수 및 트리거 등 오라클 오브젝트 정보 및 권
한에 대한 저장이 됨 – 하나의 테이블이 생성이 되면 거기에 따른 정보가 Dictionary Cache에 저
장이 됨
3) 따라서 우리가 Select를 실행시 1)과 2) 모두 실행한다고 보면 됨
4) 두 캐시에서 하나라도 오류가 발생한다면 오류 메시지가 발생함
2. Parse : 이전에 실행한 적 있는지 검사
1) Search
2) Syntax 검사
3) Symantax : 각 절을 분석 (Select, where…)
4) Privilage 검사
5) Object 검사
6) Parsed Tree에 넣는다 : SQL문장 -> ASCII로 변환
7) 변환된 키 값의 LRU 리스트에 존재 여부 확인

7.  Select 처리 과정
1.
1) 이 존재하면 문장이 100%로 동일 한다는 것이므로 Cache hit(소프트 파싱)이 발생하고 그 발생
된 문장은 최근 즉 LRU로 가장 앞부분의 버퍼에 쌓이게 됨. 그 후에 Data Buffer Cache에 해당
부분의 블록을 찾아서 결과 값을 Fetch(Select 만)함.
2) 가 존재하지 않으면 Cache miss(하드 파싱)가 발생된다. Execution plan(실행계획)을 세우고 해
당 쿼리를 execute한 후에 Database files에서 해당하는 값을 가져와서 Data Buffer Cache에 비
어 있는 블록에 저장이 되고 유저에게 그 결과값을 Fetch(Select 만)함.
3) 데이터 버퍼 캐시 사용시 4가지 상태가 있음
가. Pinned : 블록이 사용 중
나. Free : 블록이 비어있음
다. Clean : 곧 age out 될 것.
라. Dirty : 블록이 변경은 되었으나 Data base files에는 저장 되지 않은 상태
2. 조건 값이 다를 때 100%같은 문장으로 인식하는 방법
• Select * from emp where empno=1234;
• Select * from emp where empno=2345;
는 다르게 파싱 됩니다. 다른 문장으로 인식되기 때문입니다. 그러나 만약 비교할 값을 bind
variable에 넣고 select * from emp where empno=;target_no; 로 해주고 target_no 를 변경하면
서 실행되는 SQL 문장은 모두 같은 것으로 인식 됩니다.

8. ‘DML' SQL문에 대해서
과제 1차 책임자 : 장익수
과제 2차 책임자 : 박상수
그외 오마주 멤버 참여

9.  DML 처리 과정
• DML (Data Manipulation Language statements)
• 처리 과정
• 서버 프로세스가 테이블의 데이터를 읽는다.
• 찾아진 데이터파일을 Data Buffer Cache에 저장한다.
• 오라클이 Lock을 걸어 갱신하지 못하도록 한다.
• DML문장을 실행한다. 새로운 데이터와 이전의 데이터가 동시에 존재한다. 서버프로세스는 변경 이전 데이
터 블록과 새로운 데이터 블록의 변경 사항에 관한 정보를 Redo Log Buffer에 저장한다.
• 실제로 서버 프로세스가 이전 데이터를 Data Buffer Cache에 존재하는 롤백 블록에 기록한다. 그 데이터 블
록에 들어있던 이전 데이터는 새로운 데이터로 갱신된다.
• Data Buffer Cache에서 바뀐 두개의 블록들은 Dirty Buffer로 표시되어 이후 체크포인트가 발생할 때 DBWR
에 의해 데이터 파일에 저장된다.

10.  DML 처리 과정
• 예제 트랜잭션
• Insert into t (x,y) values (1,1);
• Update t set x=x+1 where x=1;
• Delete from t where x=2;
• 위 과정들이 트랜잭션으로 되어 있기 때문에 모든 과정이 문제없이 수행되어야만 트랜잭션이 올
바르게 종료 되었다고 할 수 있다. 중간에 하나의 문제점이 발생하게 되면 Undo/Redo를 이용하
여 저장되어 있는 전 단계로 이동되어 작업을 재 수행 할 것이다.

11.  DML 처리 과정
• Insert into t (x,y) values (1,1);
• 처리 과정 1
Data Buffer Cache
SGA KEEP
(System Global Area) Rado
Log
RECYCL
E
DEFAULT Buffer Step 1
Step 2
언두 인덱스 테이블 T
• Redo, Undo 생성
Undo – 백업 데이터, t 테이블의 이전 데이터, 롤백 세그먼트가 완성되고 블록들을 재 사용하기 전까지 남음 -> Data Buffer
Cache에 올라오기 때문에 SGA의 변경사항을 저장하는 Redo Log Buffer에 내용을 저장한다.
• 인덱스, 테이블 t 의 내용을 Data Buffer Cache에 가져온다. -> Data Buffer Cache에 올라오기 떄문에 SGA
의 변경사항을 저장하는 Redo Log Buffer에 저장된다.
• 현재 상태에서 문제가 발생 한다면? – 사실 아무 문제가 없다. 왜냐하면 현재는 SGA 영역에서 일이 처리되고 있고 있는 상
황인데 문제가 발생(시스템폭주/다운)했다는 것은 실제 Database files에는 아무런 문제가 발생하지 않았기 때문이다. 현재
는 Redo에 아무내용도 저장되어 있지 않기 때문에 시스템 정상화 이후에 다시 실행할 명령도 없다. 그냥 다시 Insert 작업을
시작하면 되겠다.

12.  DML 처리 과정
• Insert into t (x,y) values (1,1);
• 처리 과정 2
Data Buffer Cache
SGA KEEP
(System Global Area) Rado
Log
RECYCL
E
DEFAULT Buffer
언두 인덱스 테이블 T 리두 Step 1
• DataBufferCache에 있는 내용이 Database files에 기록되기 전에 반드시 Redo Log Buffer에 있는 내용이 리
두에 저장되는 것이 선행되어야 한다.
• 현재 상태에서 문제가 발생 한다면? – 리두에 저장은 되었으나 Database files에 기록되기 전에 문제가 발생했다. 시스템 정
상화 이후 리두에 담겨있는 내용을 토대로 Insert문을 다시 실행하게 될 것이다.
• 정상적인 절차를 거치게 되면 다음 DML문장으로 넘어가게 된다.

13.  DML 처리 과정
• Update t set x=x+1 where x=1;
• 처리 과정 1
Data Buffer Cache
SGA KEEP
(System Global Area) Rado
Log
RECYCL
E
DEFAULT Buffer Step 1
Step 2
언두 인덱스 테이블 T 리두
• Insert가 문제없이 완료 되었지만 Database files에 기록은 되지 않은 상태이고, Redo Log Buffer
의 내용이 리두에 담겨져 있다.
• 언두에는 Update가 되기 전의 새로운 내용이 담겨진다.
• 현재 상태에서 문제가 발생 한다면? – 저장되어 있는 리두를 읽고 Insert작업을 리두 하게 된다. 현재 리두에는 Update에 대
한 내용이 전혀 없다. Insert를 언두 하기 위해서는 Insert 이전의 상태 즉, 처음 상태로 돌아가서 Insert 과정을 다시 수행한
다. 그런데 만약 문제 발생 전에 Data Buffer Cache의 내용이 이미 Database files에 저장되었다면 그 결과를 반영하게 되
고, 저장되지 않았다면 다시 수행하게 된다.
• 언두에 Update가 되기전의 내용이 담기고 문제없이 다음이 수행되면 Insert의 2,3,4 번 과정이 수행된다.

14.  DML 처리 과정
• Delete from t where x=2;
• 처리 과정 1
Data Buffer Cache
SGA KEEP
(System Global Area) Rado
Log
RECYCL
E
DEFAULT Buffer
언두 인덱스 테이블 T 리두 Step 1
• Insert와 Update가 정상적으로 작업을 맞췄다. 리두는 Update까지의 작업 내용으로 갱신되었다.
• Update와 마찬가지로 언두에 저장되고 Data Buffer Cache에 올라가게 된다.
• Data Buffer Cache의 내용은 LGWR에 의해 리두 로그 버퍼에 저장되어진다.
• Delete작업을 수행하고 Check Point 발생시 DBWR에 의해 Database files에 저장된다.

15. ‘Commit(커밋)‘ 대해서
과제 1차 책임자 : 신종익
과제 2차 책임자 : 심규원
그외 오마주 멤버 참여

16.  Commit 개요
• Commit(커밋)
• 모든 데이터 변경사항을 데이터베이스에 영구히 반영시키는 명령어
• commit 변경전의 데이터는 모두 잃게 됨
• 모든 사용자들이 트랜잭션 종료 후의 결과를 확인
• 트랜잭션이 진행 중이었던 행들에 대한 잠금이 모두 해소되며, 다른 사용자에 의해서 변경이 가
능

17.  Commit 처리 과정 구조도
Session Instance
Server Process
⑤ SGA ②
PGA
(Program Global Area) (System Global Area) Large Pool
Shared Pool Data Buffer Cache
Library Cache Data Data Data Rado
Java Pool
block block block
• SQL, SQL(recursive SQL) Log
① -2 • Parse Test
• Execution Plan
Data
block
Data
Data
block
Data
Data
block
Data
Buffer
④-1
Block Block Block
Data Dictionary Cache
• Row Cache
Streams Pool
Data Data Data
block Block block
• Object Information
• Security
⑤-1
Listener
Background Process ③-1
PMON SMON DBWn CKPT LGWR ARCn etc
MRU ⑤-2
① -1 Cache Oracle Database ③-2
④-2 miss
Online Offline Redo Log Feles
Parameter Control
FILE Data Files Redo
Files
Log
User Process Password FILE
commit;

18.  Commit 처리 과정 설명
• Commit(커밋) 순서
• DML문을 실행한 후 변경작업을 종료하려면 Commit문을 실행하며 변경취소를 하려면 Rollback
문을 실행
• 사용자가 DML(Insert,Updata,Delete)문을 실행한 후 Commit문을 처리했을 경우 데이터베이스
내부에서 처리되는 과정
• 1. 사용자가 DML문을 실행한 후 COMMIT문을 실행합니다.(DDL, DCL문장은 자동 commit)
• 2. 서버 프로세스는 DML문의 처리결과(변경전의 데이터, 변경후의 데이터)가 저장되어 있는 로그 버퍼 영
역에 시스템 변경번호(SYSTEM CHANGE NUMBER)를 부여
• 3. 로그 기록기(LGWR)는 로그버퍼 영역에 있는 변경 데이터를 영구적으로 보관하기 위해 Redo log files 에
저장
• 4. 서버 프로세스는 네트워크를 통해 사용자 프로세스에게 'Committed' 메시지를 전송하고 사용자 프로세
스는 SQL*PLUS 화면에 메시지를 출력
• 5. 로그버퍼 영역의 데이터를 하나의 리두 로그 파일에 모두 저장하지 못하면 다음 로그파일로 위치를 이동
하고 이것을 로그 스위치(LOG SWITCH)라고 함
• 6. CKPT 프로세스는 컨트롤 파일과 데이터 파일의 헤드영역에 시스템 변경 번호와 관련 상태정보를 저장
되며, 이것을 체크포인트 이벤트라고 함
• 7. 이 작업이 끝나면 데이터베이스 기록기(DBWR)는 데이터버퍼 캐시영역에 있는 사용자의 변경정보를 최
종적으로 테이블에 저장

19.  Commit 처리 과정 설명
• Commit(커밋) 프로세스의 역할
• DBWR : 데이터파일에 작업
• 메모리에서 변경된 데이터 값을 실제 데이터 파일에 옮겨 적는 일을 담당
• LGWR : 리두 로그 파일에 기록 작업
• 메모리에 있는 리두 로그 버퍼의 정보를 리두 로그 파일에 기록하는 역할 담당