CASE 1) 

 

내 분석 

- Redo Log Size 24kb  per  Sec /  3kb per Tx

 -> 1sec당  tx 한 6-7개 있는건가보다

- Logical Read 가 많고 Physical은 적다 

 -> tunning 잘되어있나보네

 -> 1G 정도 읽음 

- Block change 별로 없고 

문제 없어보이는데?

 

강사의견

- Logical Read 는 좀 많은 편이나/ Physical Read는 거의 없다 

- 문제가 없어 보인다.

 

CASE 2) 

 

 

내 분석 

- Redo Log Size 23kb  per  Sec /  1kb per Tx

 -> 초당 18개정도의 tx

-> transactions는 16이다

-> log 가 초당 

- Logical Read (4G)  /  Physical (125M) 

 -> 거의 40배인데 이정도 비율이면 괜찮은거 아닐까?

- Transaction은 16인데 / Execute 는 473

-> 평균적으로 한tx에 30개의 Execute 가 있다..? 되게 큰 tx들이다.. 

 

강사의견

** Sort항목은 12c부터 사라지고 SQL Work Area로 변경됨 

- User call이 초당 600정도 들어옴

-> OLTP성 프로그램이다 

- Physical 이 많다 

-> batch성 업무 같음

- Logical 도 많다 

-> Buffer Cache에도 많은 양이 들어오고 있다 

-> Physical 이 많은 이유는 몇몇 SQL로 인한 것일 거다

 

 

 

 

CASE 3)

내 분석 

- Redo Log Size 500kb  per  Sec /  110kb per Tx

 -> 초당 5개정도의 tx

->  1분에 30M / 10분에 300M => 나쁘지 않은걸 ? 

- Logical Read (1G)  /  Physical (23Mb) 

 -> 거의 120배인데 잘쓰고 있는듯~

- 힌 tx당 180개의 Execute..?

-> tx이 이렇게 많이 하면 lock 문제 있지 않을까/..?

 

강사의견

- User calls는 1600인데 Execute는 800이다  

- 오전에 Report를 뽑는 시스템으로 배치가 돈다 

- Core/ IO가 필요하다 

추가 자료를 보면 위에 3개가 Batch 프로그램으로 돌면서 Phsical Read 를 많이 먹는걸 알 수 있다.