OWI
point
※ Latch, Lock
OWI (oracle wait Interface)
: SQL 문을 실행할때의 대기 현상을 관찰 하고 어떠한 문제가 발생했는지 추론하자
응답시간 = 실행시간(cpu) + 대기시간
목표는 대기시간을 줄이자!
① 기다리는 원인을 어떻게 찾을 것인가
② 원인에 대한 해결책
OWI 툴
OWI dynamic 뷰
V$SYSYEM_EVENT :인스턴스 가동후에 모든 세션에서 발생한 대기 이벤티의 누적 정보
V$SESSION_EVENT : 사용자별로 누적 정보
V$SESSION_WAIT : 사용자별 실시간 정보
Extended SQL Trace
Oradebug & dump
Automatic Workload Repositiory
Latch & Lock
Latch & Lock 비교
Latch 란?
Latch 종류
Latch 모드
Willing-to-wait : Latch를 획득 할때 까지 서버프로세스는 대기한다.
① Latch가 있는지 확인 있으면 획득
② 없으면 spin count 만큼 반복적으로 Latch 획득을 위해 확인
③ 획득하지 못하면 Sleep 을 실행
④-1 sleep 상태의 프로세스가 일정시간(Time out) 발생하면 다시 Latch획득을 요청
(일반적인 Latch들 )
④-2 래치대기목록(Latch wait list)에 대기 해 놓고 다른 프로세스가 깨워주기를 기다림
(오래걸리는 Latch들 Shared pool , library cache)
※ Latch의 일반적인 대기는 길지 않음
※ 기본적인 전제는 cpu가 여러개인 상황
※ spin을 하는 이유 : context switching 소모시간> cpu 소모시간
⑤
⑥
No-wait
LOCK
※ lock 의 종류를 분류할 줄 알아야함
① Enqueue Lock
② 일반 Lock
※ 동시에 사용하기 때문에 스케줄 관리를 잘해야함
고객 Table
이름 / 나이 / tel
홍길동 20 111
일지매 22 222
유관순 24 333
TM Lock 고객 A,B (Sub_Exclusive mode: lock를 공유하는...)
TX Lock 칼럼 A : 홍길동 → 강감찬 B: 일지매 → 고길동
※ ITL에 따라서 1개의 테이블의 다른 데이터를 동시에 바꿀 수도 아닐 수 도 있음
Lock 보호하는 리소스: lock 이름이 리소스 이름과 일치
오라클 내부 구조와 OWI
DB Buffer Cahce 와 OWI
사용자가 SQL을 실행했을때 block 검색 방법
※ SQL → ASCII→ Hash Values
※ 많은 양을 검색하는 SQL 을 사용하면 DB Buffer Cache의 내용을 전부 밀어냄
※ Buffer Lock : DB Buffer Cache에 disk에서 데이터를 가져오기전에 미리 Lock를 걸어둠
※
※
DB Buffer Cache
Hit % : 총블럭, 메모리에서 읽은, disk에서 읽은 것 으로 계산하기
★★★
Free buffer inspected : LRU list에서 몇번만에 Free 를 찾을 것인가 → 느림 Db buffer cache관리 잘못
→ 데이터를 바꿀때(DML)는 항상 DBWR이 disk에 dirty(변경완료 저장안됨), pinned(변경중)
먼저 내려쓴(check point 발생) 후에 (write complete waits 파라미터 : 내려쓰기 까지 기다리는 시간)
DML 작업을 해야함
※ 자주 데이터를 내려 쓸것인가, 그냥 둘것인가 를 정해주는 파라미터
FAST_START_MTTR_TARGET : 인스턴스 리커버리의 평균 시간
mean time to recovery
Free buffer inspected : 크다 : 더티 버퍼 많음 , ,instance 리커버리(shutdown abort) 오래걸림
Free buffer inspected : 작다 : 더티 버퍼 적음 , ,instance 리커버리(shutdown abort) 적게걸림
FAST_START_MTTR_TARGET : 많이 주면 checkpoint 적게 일어남
적게주면 checkpoint 많이 일어남
free buffer waits : free 나올때 까지 서버 프로세스가 기다리는거
Buffer busy waits : ITL의 내용을 쓰기 위해 기다리는것
write complete waits : 내려쓰고 있는 데이터를 기다리는것
★★★
ITL : 서버프로세스가 어떤 작업을 하는지 적어두는것
ITL의 내용은 동시에 바꾸지 못함 다른 프로세스는 기다림 :Buffer busy waits
※ 같은 데이터를 동시에는 못바꿈
※ 같은 블럭,테이블의 다른 데이터는 여러 서버프로세스가 바꿀 수 있음
※
Redo Log Buffer
log buffer space : change vector letch 에서 기다리는 시간
Latch
Redo Copy Latch → Redo Allocation Latch → Redo Writing Latch(내려쓸때 사용)→ LGWR
shared pool / Library Cache OWI
목표
shared pool 에서 어떻게 메모리를 어떻게 관리, 사용자 할당 , Latch를 사용하는가 ?
특징
shared pool 메모리는 heap 으로 관리
Shared Pool 에서의 비어있는 메모리: Chunk (청크)
shared pool 메모리를 할당받기 위한 Latch : shared pool Latch (전체 인스턴스에서 1개만 존재)
(대기시 latch:shared pool 이벤트)
Library cache 구조
목표
구조가 어떻게 되어있고 어떻게 할당 받을 것인가 ?
특징
SQL 수행과 관련한 정보가 저장되어 있음
Library Cache Manager 에 의해서 관리됨
Library Cache Latch : 접근하기위한 Latch
Library Cache lock : Library Cache 전체를 lock
Library Cache pin : Library Cache내에 특정 Chunk 를 lock 후에 작업
아무리 많은 Free Chunk가 존재해도 담을 수 있는 최적의 크기 이상의 Free Chunk를 발견하지
못하면 Oracle은 작업을 진행하지 않음
why: 왜냐하면 메모리는 연속적으로 할당을 받아야 하기 때문 ,
hard parse에 의해서 메모리가 많이 쪼개져 있음 → shared pool 단편화 현상
shared pool 단편화 현상
- 메모리에 비어있는공간은 4칸인데 4칸의 데이터를 저장하지 못함(데이터를 연속적으로 저장하지 못해서)
Library Cache Object(LCO)
Free
recr
freeable
트렌젝션 / OWI
fff
트렌젝션의 상황이 너무 많음
너무 tool에 의지 하지 말것(토드, orange)
Clean out : 多 양의 데이터를 update 하는 경우 오래걸림
일반 commit 명령 시에 block 하나하나를
① block header 에 ITL 바꾸는 내용을 적고
② block lock 하고 데이터 변경
※ 부하가 많이 걸림
해결 : undo 에만 commit 정보를 적어 주자
delayed block cleanout : 나중에 undo segment 를 확인하는 사용자가 commit 을 하자
fast commit : 커밋 시점에 모든 blcok 에대해 cleanout 수행하지 않고 db buffer 일부분만 수행하자
세그먼트 / OWI
DMT : 8i
데이터 공간의 할당을 전부 dictionary 에서 관리 → 부하가 심함
LMT : 각 block 에 free , dirty 여부를 적어 놓자
FLM: 9i
찾는 순서
① transaction free list
② process free list
③ master free list
문제는: 명확하게 얼만큼 Free 가 남았는지 알지못함
ASSM: 10g
%의 Free 를 갖고 있는지 표시
HWM(데이터 공간 할당을 위한 워터마크)
_BUMP_HIGHWATER_MARK_COUNT: 한번에 얼만큼 block를 할당할 것인가
少 많은 량의 데이터가 입력시 HW 락이 많이 발생
多 HW 락이 적게 발생, block 낭비가 있을 수 있음
※테이블 생성시에 특정 extent(많이 사용할 것 같은것) 용량을 크게도 설정할 수 있음
I/O OWI
어떻게 I/O를 줄일것인가 ??
단계
①어플리케이션 레이어 : SQL 문을 잘 작성하자
②오라클 메모리 레이어 :
- LRU 알고리즘 : 많이 사용한 것을 메모리에 두자
- Buffer pinning : 같은 block 접속이 많으면 Latch를 생략하자
- db buffer cache 세부 구분
① Default : LRU 알고리즘으로 관리
② keep : table 만들때 설정해서 많이 자주 사용되는것 지정하기
③ recycle : 낮은 빈도의 객체들이 사용
- block 사이즈를 융통성 있게 사용
- direct path I/O : 메모리에 올리지 않고 바로 disk에 저장하기
ex: datapump, SQL Load , PDML: /** APPENT *
③오라클 세그먼트 레이어 : ASSM을 사용하자
④OS/디바이스 레이어 :
- 동기식, 비동기식 commit
비동기식 commit : dml 작업이 진행중에 작업 redo → db buffer cache, 성능은 빠름 ,
redolog buffer 내용을 redo log file 저장되었는지는 미지수
동기식 commit : dml 작업이 끝나야 다음 작업, 안전함
- rewdevice 를 권장
- Direct path I/O
리두 / OWI
redo : undo + redo 데이터가 저장이됨
ex : insert 명령시에
undo : delete
redo : insert
※redo가 필요없는 경우에는 redo를 생략하자 → nologging