[Oracle Architecture][2015 04-29] Wait Event and Shared Pool

WareValleyhttp://www.WareValley.com

Database Audit and Protection [ DB 접근통제 ]

Database Encryption [ DB 암호화 ]

Database Vulnerability Assessment [ DB 취약점 분석 ]

Database SQL Query Approval [ DB 작업결재 ]

Database Performance Monitoring and Management [ DB 성능관리 및 개발 ]

WareValley

Oracle ArchitectureWait Event & Shared Pool

오렌지팀 윤석준 선임연구원

Database security and management, WareValley.http://www.WareValley.com

Wait Event

1. Wait Event

2. When Occurred

3. When disappeard

4. Latch


Wait Event

공유자원에 접근할 일이 있는데…

이미 다른 Process가 사용 중이라서...

사용 가능할때까지 Sleep 상태로 들어가는 것

(상태정보는 File 이나 SGA 메모리에 저장)


Wait Event 역사

• 태초에 Oracle 개발자들이 자원 관리 관련 기능 개발에 애를 먹었으니,

• 하다하다 안되서 Debugging 용 Code를 집어넣게 되었다.

• Wait가 발생할 때마다 관련 Log를 생성하도록 Kernel Code에 추가하였는데,

• 그 공을 인정받아 OWI (Oracle Wait Interface) 라는 작위를 받게 되었으며,

• 대대손손 자식농사를 잘 지어서 7.0 : 100 여개, 10g : 890개, 11g : 960개의

Wait Event를 정의하였다.

참고로 MS-SQL Server에서는 Wait Type이라 부름


When occurred ?

1. 필요한 Resource 가 사용중일 때

- 읽으려는 buffer를 다른 process가 write 작업중인 경우

- buffer busy waits, latch free, enqueue 관련

2. 선행 작업을 기다릴 때

- DBWR이 dirty buffer를 disk에 기록하려 할 땐 <- 먼저 LGWR가 log buffer에 있는 redo entry를 redo log로 기록해야 함

-> DBWR이 LGWR을 깨워 buffer를 비우라는 신호를 보내고 LGWR이 마칠때까지 Sleep

-> Sleep 중이던 LGWR은 DBWR이 시킨 일을 다하고 다시 Sleep 해야 하는데

-> DBWR을 깨우고, DBWR은 Sleep

- write complete waits, checkpoint completed, log file sync, log file switch 등…

3. 할 일이 없을 때 ( idle wait event)

- Server process의 Query 결과 전송시 Array 크기만큼 전송한 뒤 다음 Fetch Call을 Wait -> idle 상태

- Query 결과를 모두 전송 (End of Fetch) 한 뒤 다음 Parse Call 이나 Execute Call을 Wait -> idle 상태

- Parallel Query 수행시 먼저 작업을 마친 slave processor 는 다른 작업들의 완료를 Wait -> idle상태

- SQL*Net message from client, PX Deq:Execution Msg 등…


When disappered ?

1. Timeout

- Sleep 시 설정해 놓은 alarm (timeout 마다 Wake -> 아직 누가 사용 중이면 다시 Sleep)

- DBWR <-> LGWR 상호 작용의 wait event들 : 3초

- log file sync : 1초 (Commit 할때마다 LGWR을 깨워 redo buffer를 비우도록 할 때 발생)

- buffer busy : 1초

- enqueuer 관련 lock : 3초

2. Sleep 중인 process가 언제 다시 활동하나 ?

- 기다리던 Resource가 사용 가능하게 되거나

- 기다리전 선행작업이 완료되거나

- 할 일이 생기거나


Latch

• Get Latch ≠ Race Condition , Get Latch = Access Shared Resource

v$latch에서 gets의 횟수가 증가하는 건 문제가 아니다.

• v$latch

- gets : latch 요청 횟수

- misses : 첫시도에서 latch를 못얻은 횟수

=> misses 되면 spin 과정에서 latch를 획득

or spin 실패시 sleep 모드로 전환

( spin : CPU 점유 상태에서 자원에 액세스 시도를 반복)

- simple_gets : 한번에 latch 획득에 성공한 횟수 ( simple gets = gets – misses )

- spin_gets : spin 과정에서 latch를 획득한 횟수 ( spin_gets = misses – sleeps )

즉, gets는 못했지만, sleep 전에 latch를 획득한 횟수

- sleeps : gets 실패 -> spin_gets 실패 -> 결국 sleep 된 횟수

=> latch free 발생 ( 9i까지는 모든 wait event 명이 latch free 하나면 끝.

10g 부터는 latch:cache buffers chaines, latch: library cache lock 처럼 별도 명칭 부여.

하지만, 여전히 떨거지들은 싸잡아 latch free 라 퉁침.)

=> latch는 lock처럼 queueing (큐잉 매커니즘)이 없어 반복적 시도만 할뿐, 우선권 부여는 불가능


Shared Pool


Shared Pool

Dictionary cache ( = Row cache )

- Oracle dictionary 정보 저장

- Row 단위로 R/W 해서 Row Cache 라 부르기도 함

- obejct ( table, view ) 및 tablespace, datafile, segment, extent, user, constraint, sequence, db-link

등에 관한 정보를 캐싱

Library cache- user request query 및 execution plan을 저장

- SQL을 hard parsing 하고 optimization 하는 것은

아주 무거운 동작이므로,

- 반복 수행을 피하고자 만든 cache


sequence 사용 예제 user가 sequence 생성하면 Oracle dictionar에 생성 후 저장하고, Row cache를 통해 R/W

sequence 사용으로 nextval이 호출될 때마다 Row cache가 update 됨

v$rowcache에서 Hit Ratio를 조사하여 수치가 낮게 나오면 Shared Pool 사이즈를 늘리는 것을 고려

v$rowcache에서 TYPE = ‘PARENT’인 entry와

v$latch_children에서 NAME = ‘row cache objects’인

latch의 개수는 항상 일치

=> Row cache의 entry 각각에 대해 latch가 하나씩 할당

[Oracle Architecture][2015 04-29] Wait Event and Shared Pool

Software

Transcript of [Oracle Architecture][2015 04-29] Wait Event and Shared Pool