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를 점유하게 해줘야한다