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

1. WareValley
http://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 Architecture
Wait Event & Shared Pool
오렌지팀 윤석준 선임연구원

2. Database security and management, WareValley.
http://www.WareValley.com
Wait Event
1. Wait Event
2. When Occurred
3. When disappeard
4. Latch

3. Database security and management, WareValley.
http://www.WareValley.com
Wait Event
공유자원에 접근할 일이 있는데…
이미 다른 Process가 사용 중이라서...
사용 가능할때까지 Sleep 상태로 들어가는 것
(상태정보는 File 이나 SGA 메모리에 저장)

4. Database security and management, WareValley.
http://www.WareValley.com
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이라 부름

5. Database security and management, WareValley.
http://www.WareValley.com
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 등…

6. Database security and management, WareValley.
http://www.WareValley.com
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가 사용 가능하게 되거나
- 기다리전 선행작업이 완료되거나
- 할 일이 생기거나

7. Database security and management, WareValley.
http://www.WareValley.com
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 (큐잉 매커니즘)이 없어 반복적 시도만 할뿐, 우선권 부여는 불가능

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

9. Database security and management, WareValley.
http://www.WareValley.com
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

10. Database security and management, WareValley.
http://www.WareValley.com
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가 하나씩 할당