SQL Statisitcs 항목
•SQL ordered by Elapsed Time (수행시간) : 자주 봄
•SQL ordered by CPU Time (CPU 시간) : CPU를 얼마나 썼는가
•SQL ordered by User I/O Wait Time
•SQL ordered by Gets (User I/O Wait 시간) (Buffer Cache access block 수) : Logical IO 자주 봄
•SQL ordered by Reads (Physical(Storage) access block 수) : Physical IO 자주 봄
•SQL ordered by Physical Reads ( UnOptimized) : Optimize가 안된것
•SQL ordered by Executions : 아무리 빨리 끝나고 0.001초여도 호출이 많으면 Library Cache에 영향을 줄 수 밖에 없다
•SQL ordered by Parse Calls (호출/수행횟수) (Parsing 횟수)
•SQL ordered by Sharable Memory
•SQL ordered by Version Count
•Complete List of SQL Text
** 시간보단 Access Block을 줄이는게 중요하
AWR Report 에서 Main Report를 누르거나 Or 밑으로 내리면 항목이 있다
AWR Report 에서 Main Report를 누르거나 Or 밑으로 내리면 항목이 있다
수행시간이 긴 순서대로 list up이 되어있고
SQL id 항목을 누르면 상세한 내용을 볼 수 있다
** 위의 표에서 1, 2 번째는 PL/SQL을 호출하는 거라고 한다
SQL 전문을 확인 할 수 있다.
DB CPU 퍼센트가 높다고 좋은건 아니다
그 만큼 Buffer Cache를 사용하고 있는 것이고 flush 이슈도 있으며 언젠가는 부하가 올거다
CASE 1)
** 1시간 동안의 수치를 표로 만든것이다
1번 SQL
- 1억3천 Buffer Cache Block에 접근하였다
- 1번 수행할 때 9000개의 Block에 접근했다 (한번 Execute 에 9000*8K =70Mb 정도 접근)
- 1시간에 14000번 수행이되었다 (약 1초에 2번 호출됨)
- 전체 Logical IO의 14% 차지를 한다
- CPU Time 과 Elapsed Time 이 보통 비슷하지만 , 차이가 클 경우 Buffer Cache 보다 IO가 많다는걸 알 수 있다
2번 SQL
- 1번 SQL과 유사
3번 SQL
- 수행 횟수는 적다
- 한 번 수행 할 때 Buffer Cache 에 10G를 접근한다
==> 이럴 경우 어떤 현상이 발생할까?
Buffer Cache에
[72M] [72M] [72M]... [72M]
[20M] [20M] [20M].... [20M]
이렇게 잘 있다가
3번 SQL이 실행 되면
1. [ 10 G ] <- 대왕이 들어와야하기에 , 기존 [72M] [20M] 들은 밑으로 내려가야한다
2. [ 10 G ] 대왕이 잡고 있기 때문에 신규 [72M] [20M] 가 생성될 수가 없다
즉, 3번 SQL은 자주 실행되지도 않으면서 Buffer Cache를 점유하기 때문에 튜닝이 필요하다
자주 Execute 되는 SQL들이 Buffer Cache를 점유하게 해줘야한다
'DBMS > Oracle' 카테고리의 다른 글
[Oracle] dba_hist_osstat view 보는 법 (0) | 2024.07.10 |
---|---|
[Oracle] AWR Report 보는법 - Advisory Statistics 이 뭔지 알아본다 (0) | 2024.06.09 |
[Oracle] AWR Report 보는 법- Load Profile 만 보고 어떤 시스템인지 맞춰보기 (0) | 2024.06.07 |
[Oracle] AWR Report 보는 법 - Load Profile 항목은 어떻게 보는가 (0) | 2024.06.06 |
[Oracle] AWR- report HTML 형식으로 보는 법 (0) | 2024.05.17 |