oracle 세미나 1차 과제 v1 0
DESCRIPTION
Oracle 세미나 1차 과제 V1 0TRANSCRIPT
Oracle 세미나 1 차 과제 V1.0
날짜 : 2010.03.10작성자 : 오마주 팀원
오마주 멤버 : 박상수, 심규원, 장익수, 이돈규, 신종익, 이민상, 황한태
' 공유 가능한 ' SQL 문에 대해서과제 1 차 책임자 : 이돈규과제 2 차 책임자 : 장익수그외 오마주 멤버 참여
Select 처리 과정In-
stance
Oracle Data-base
Library Cache
• SQL, SQL(recursive SQL)
• Parse Test• Execution Plan
Data Dictionary Cache
• Row Cache• Object Information• Security
Datablock
Datablock
Datablock
Datablock
Datablock
Datablock
DataBlock
DataBlock
DataBlock
Datablock
DataBlock
Datablock
Data Buffer Cache
SGA(System Global Area)
Background Process
RadoLogBuffer
Java Pool
Large Pool
Streams Pool
PMON
SMON
DBWn
CKPTLGW
RARCn etc
Data FilesControl
Files
On-line
Redo Log
Offline Redo Log Feles
Shared Pool
Parameter FILE
Password FILE
PGA(Program Global Area)
Server Process
User Process
Lis-tener
LRU List
MRU LRU End
Age outSelect
Cache hit
Cache miss
Session
Parsring
Exe-cuteFetch
①
①
②
③
④
④-1
⑤-2
⑤-1
⑥⑦
⑧-1
⑧-2
Select 처리 과정
1. User 프로세스 요청• 서버 프로세스를 띄우기 위해서 리스너 ( 일종의 프로세스 ) 가 띄워져야 하는데 이 리스너의
역할은 유저와 서버를 연결해 주고 연결 완료 후 바로 빠지고 다른 연결을 시작한다 . 리스너와 INSTANCE 는 1:1, N:1, N:N 작업이 가능하다 .
• 유저 프로세스로부터 올바른 인스턴스명으로 접속요청이 오면 리스너는 서버 프로세스를 띄우고 유저명과 암호를 넘기고 빠지고 암호가 맞으면 DB 인증이 되고 틀리면 접속 실패 한다 . 실직적으로 유저 프로세스와 서버 프로세스가 연결이 되고 리스너는 또 다른 접속을 기다린다 .(Connection)
2. 서버 프로세스 요청 받음• 서버 프로세스에서는 INSTANCE( 출입구 ) 쪽으로 세션 연결을 함 (PGA 를 통해서 연결 )
Select 처리 과정
1. PGA(Program Global Area)• 데이터베이스에 접속하는 모든 유저에게 할당되는 각각의 서버 프로세스가 독자적으로
사용하는 오라클 메모리 영역 – 이 영역으로 인해서 우리는 commit 되기 전의 데이터를 각각의 유저가 볼 수 있다 .
• PGA 구조I. 정렬 공간 – group by, order by 등의 정렬을 수행 하기 위한 공간II. 세션정보 – 결과 값 처리를 위한 유저 프로세스의 세션 정보III. 커서상태정보 – 파싱 정보가 저장되어 있는 주소를 저장IV. 변수저장공간 – 변수 사용시 변소를 저장하는 공간
2. SGA(System Global Area)
Select 처리 과정
1. Shared Pool1) Library Cache - DB 에 접속한 유저가 실행한 SQL 및 SQL 에 대한 분석 정보 실행 계획이
저장됨2) Dictionary Cache – 테이블 정보 , 인덱스 , 인덱스 함수 및 트리거 등 오라클 오브젝트 정보
및 권한에 대한 저장이 됨 – 하나의 테이블이 생성이 되면 거기에 따른 정보가 Dictionary Cache 에 저장이 됨
3) 따라서 우리가 Select 를 실행시 1) 과 2) 모두 실행한다고 보면 됨4) 두 캐시에서 하나라도 오류가 발생한다면 오류 메시지가 발생함
2. Parse : 이전에 실행한 적 있는지 검사1) Search2) Syntax 검사3) Symantax : 각 절을 분석 (Select, where…)4) Privilage 검사5) Object 검사6) Parsed Tree 에 넣는다 : SQL 문장 -> ASCII 로 변환7) 변환된 키 값의 LRU 리스트에 존재 여부 확인
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; 로 해주고 tar-get_no 를 변경하면서 실행되는 SQL 문장은 모두 같은 것으로 인식 됩니다 .
‘DML' SQL 문에 대해서과제 1 차 책임자 : 장익수과제 2 차 책임자 : 박상수그외 오마주 멤버 참여
DML 처리 과정
• DML (Data Manipulation Language statements)• 처리 과정
• 서버 프로세스가 테이블의 데이터를 읽는다 .• 찾아진 데이터파일을 Data Buffer Cache 에 저장한다 .• 오라클이 Lock 을 걸어 갱신하지 못하도록 한다 .• DML 문장을 실행한다 . 새로운 데이터와 이전의 데이터가 동시에 존재한다 . 서버프로세스는 변경 이전
데이터 블록과 새로운 데이터 블록의 변경 사항에 관한 정보를 Redo Log Buffer 에 저장한다 .• 실제로 서버 프로세스가 이전 데이터를 Data Buffer Cache 에 존재하는 롤백 블록에 기록한다 . 그
데이터 블록에 들어있던 이전 데이터는 새로운 데이터로 갱신된다 .• Data Buffer Cache 에서 바뀐 두개의 블록들은 Dirty Buffer 로 표시되어 이후 체크포인트가 발생할 때
DBWR 에 의해 데이터 파일에 저장된다 .
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 를 이용하여 저장되어 있는 전 단계로 이동되어 작업을 재 수행 할 것이다 .
DML 처리 과정
• Insert into t (x,y) values (1,1);• 처리 과정 1
• 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 작업을 시작하면 되겠다 .
SGA(System Global Area) Rado
LogBufferRECY-
CLEDEFAULT
Data Buffer Cache
언두 인덱스 테이블 T
Step 1
Step 2
KEEP
DML 처리 과정
• Insert into t (x,y) values (1,1);• 처리 과정 2
• DataBufferCache 에 있는 내용이 Database files 에 기록되기 전에 반드시 Redo Log Buffer 에 있는 내용이 리두에 저장되는 것이 선행되어야 한다 .
• 현재 상태에서 문제가 발생 한다면 ? – 리두에 저장은 되었으나 Database files 에 기록되기 전에 문제가 발생했다 . 시스템 정상화 이후 리두에 담겨있는 내용을 토대로 Insert 문을 다시 실행하게 될 것이다 .
• 정상적인 절차를 거치게 되면 다음 DML 문장으로 넘어가게 된다 .
SGA(System Global Area) Rado
LogBufferRECY-
CLEDEFAULT
Data Buffer Cache
언두 인덱스 테이블 T 리두 Step 1
KEEP
DML 처리 과정
• Update t set x=x+1 where x=1;• 처리 과정 1
• Insert 가 문제없이 완료 되었지만 Database files 에 기록은 되지 않은 상태이고 , Redo Log Buffer 의 내용이 리두에 담겨져 있다 .
• 언두에는 Update 가 되기 전의 새로운 내용이 담겨진다 .• 현재 상태에서 문제가 발생 한다면 ? – 저장되어 있는 리두를 읽고 Insert 작업을 리두 하게 된다 . 현재 리두에는 Up-
date 에 대한 내용이 전혀 없다 . Insert 를 언두 하기 위해서는 Insert 이전의 상태 즉 , 처음 상태로 돌아가서 Insert 과정을 다시 수행한다 . 그런데 만약 문제 발생 전에 Data Buffer Cache 의 내용이 이미 Database files 에 저장되었다면 그 결과를 반영하게 되고 , 저장되지 않았다면 다시 수행하게 된다 .
• 언두에 Update 가 되기전의 내용이 담기고 문제없이 다음이 수행되면 Insert 의 2,3,4 번 과정이 수행된다 .
SGA(System Global Area) Rado
LogBufferRECY-
CLEDEFAULT
Data Buffer Cache
언두 인덱스 테이블 T 리두
Step 1
Step 2
KEEP
DML 처리 과정
• Delete from t where x=2;• 처리 과정 1
• Insert 와 Update 가 정상적으로 작업을 맞췄다 . 리두는 Update 까지의 작업 내용으로 갱신되었다 .
• Update 와 마찬가지로 언두에 저장되고 Data Buffer Cache 에 올라가게 된다 .• Data Buffer Cache 의 내용은 LGWR 에 의해 리두 로그 버퍼에 저장되어진다 .• Delete 작업을 수행하고 Check Point 발생시 DBWR 에 의해 Database files 에 저장된다 .
SGA(System Global Area) Rado
LogBufferRECY-
CLEDEFAULT
Data Buffer Cache
언두 인덱스 테이블 T 리두 Step 1
KEEP
‘Commit( 커밋 )‘ 대해서과제 1 차 책임자 : 신종익과제 2 차 책임자 : 심규원그외 오마주 멤버 참여
Commit 개요
• Commit( 커밋 )• 모든 데이터 변경사항을 데이터베이스에 영구히 반영시키는 명령어• commit 변경전의 데이터는 모두 잃게 됨• 모든 사용자들이 트랜잭션 종료 후의 결과를 확인• 트랜잭션이 진행 중이었던 행들에 대한 잠금이 모두 해소되며 , 다른 사용자에 의해서 변경이
가능
Commit 처리 과정 구조도In-
stance
Oracle Data-base
Library Cache
• SQL, SQL(recursive SQL)
• Parse Test• Execution Plan
Data Dictionary Cache
• Row Cache• Object Information• Security
Datablock
Datablock
Datablock
Datablock
Datablock
Datablock
DataBlock
DataBlock
DataBlock
Datablock
DataBlock
Datablock
Data Buffer Cache
SGA(System Global Area)
Background Process
RadoLogBuffer
Java Pool
Large Pool
Streams Pool
PMON
SMON
DBWn
CKPTLGW
RARCn etc
Data FilesControl
Files
On-line
Redo Log
Offline Redo Log Feles
Shared Pool
Parameter FILE
Password FILE
PGA(Program Global Area)
Server Process
User Processcommit;
Lis-tener
MRU
Cache miss
Session
① -1
① -2
②
④-1
④-2
③-1
③-2
⑤
⑤-2
⑤-1
Commit 처리 과정 설명
• Commit( 커밋 ) 순서• DML 문을 실행한 후 변경작업을 종료하려면 Commit 문을 실행하며 변경취소를 하려면 Roll-
back 문을 실행 • 사용자가 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) 는 데이터버퍼 캐시영역에 있는 사용자의 변경정보를
최종적으로 테이블에 저장
Commit 처리 과정 설명
• Commit( 커밋 ) 프로세스의 역할• DBWR : 데이터파일에 작업
• 메모리에서 변경된 데이터 값을 실제 데이터 파일에 옮겨 적는 일을 담당
• LGWR : 리두 로그 파일에 기록 작업• 메모리에 있는 리두 로그 버퍼의 정보를 리두 로그 파일에 기록하는 역할 담당