awr report top 5 event 질문 드립니다. 0 4 2,434

by 망고 [2010.05.18 11:19:39]


Top 5 Timed Events

Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
log file sync 301,502 13,226 44 63.8 Commit
CPU time   4,873   23.5  
log file parallel write 136,154 2,792 21 13.5 System I/O
db file parallel write 30,450 1,494 49 7.2 System I/O
local write wait 17,269 880 51 4.2 User I/O


log file sync event가 63.8% 상당히 높게 나왔는데요 이에 대한 원인이 어떤게 있을까 해서
질문 드립니다.

제 짧은 생각으로는 저희가 사용하는 DB는 redo log 가 이중화가 되어 있고, commit 되는
데이터가 많아 redo log 쪽에 많은 wait time 발생하는가 싶어서요

이외에 현재 table reorg 및 index rebuild를 하고 있지 않아 full scan도 발생하는 것 같은데
reorg 및 rebuind 를 해주면 redo log 쪽 wait time 도 줄어들수가 있는건지요

조언좀 부탁드립니다. 감사합니다.
by 랄랄라젠카 [2010.05.18 16:30:10]
이 Report 만을 보고 현재 상황을 개선하기에 적절한 튜닝요소를 판단하는건 무리 같습니다. 나머지 정보들이랑 기타Wait 이벤트와의 조합을 통해 판단을 해야할 텐데요..

가장 기본적으로 우선 성능 튜닝에서 Log file Sync 가 높다는 것은 Commit이 과도하게 수행된 경우 입니다.

어차피 메모리에서 변경된 Data block 들과 redo block 들은 check point 발생등의 여러 이벤트 들을 통해 disk로 기록이 됩니다.

그리고 delayed block clean out 기법을 통해 update나 Insert 시 1000건단위로 commit을 찍거나 10만건 단위로 찍는것은 그리 큰 차이가 없습니다.

하지만 logfile 아래 log file parallel write 같등의 이벤트가 동시에 발생하는 걸로 봐서는 실제로 Insert하는 양이 매우 많은 것으로 볼수 있겠네요.

by 랄랄라젠카 [2010.05.18 16:33:14]
redo log는 변경된 내용을 저장하는 부분이기 때문에 Table이나 Index Rebuild와는 큰 관련이 없을 것 같습니다.

그리고 Table Full scan으로 인한 전반적인 성능저하라면 Wait Event 에서 db file sequencial read , db file scttered read 가 많이 발생했겠죠.

우선 트랜잭션을 발생시키는 Appl 에서 얼마마다 Commit을 찍는지 먼저 확인해보세요.

by 랄랄라젠카 [2010.05.18 16:33:31]
근데 여기 고수분들 많은데 어설프게 리플달아서 욕먹는거 아닌지 몰겠습니다. ㅎㅎ

by 망고 [2010.05.19 14:33:13]
답변 주셔서 감사합니다.
댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입