AWR Report에는 다양한 항목이 있다

그 중 Report Summary , SQL Statistics , Advisory Statistics 이렇게를 많이 본다 

 

볼 수 있는 항목들을 정리하자면

Report Summary 로도 충분히 어느부분이 문제인지 알 수 있다. 

SQL statistic 에서 SQL 정보 (buffer cache Access , Disk Access 등) 확인

 Advisory Statistics : 10G 이후부터는 DB가 SGA, PGA, Undo Segment 등 사이즈 조정 및 Re-Org 등 조언을 해준다 

보다 자세한 정보가 필요하면 , buffer pool statistic , Dictionary Cache Statistic , Library Cache Statistic , Wait Event 등등 확인 할 수 있다 

 

 

 

 

 

Load Profile + Wait Event 결합 분석이 필요하다 

Load Profile 과 Wait Event가 어떻게 시스템 CPU usage 와 Wait 으로 연계되는지 직감적인 감이 필요하다 

Wait Event 만 봐도 되는가? NO. Load profile 등 종합적으로 봐야한다. (보통 wait event 만 확인한다 그럼 안된담)

 

Q. CPU time 대비 Wait Event 비중이 높으면 문제가 있는 시스템인가?

 

Load Profile 에서 가장 중요한 지표는 Logical Reads(초당 Buffer Cache Access Block 개수 )와 Physical Reads(초당 Disk Access Block 개수 )이다   

But. Access Block 수만 나타내므로 Scan Access 인지 Random Access 인지에 따라 의미가 다르다 

 

ex) Physical Read 가 초당 4500 Block 이상이고 Random Access 라면 CPU부하 및 Wait Event 가 매우 많이 발생할 것이다  But! 4500Block 중에 Scan Access 가 있다면 어느정도 안정적이게 운영될 수 있다 (*SSD가 아닌 가정) 

- Scan이 Random에 비해 몇십배 이상 Throughput이 많이 나오기 때문 

 

Report 상에서  Physical Reads 수치 중에 Scan/Random Access 의 비율을 알 수 있는 방법이 없다.

그러나! Wait Event와 종합해서 보면 유추가능하다 

 

DB file Sequential read 가 많다면 Random Block Scan (index는 sequential 하게 읽지만 table 은 random하게 Access 됨 )

DB file scttered read/ Direct IO write 가 많다면 Full Scan

 

 

Load Profile 보는 법 

DB에 어떤 유형의 부하가 얼마만큼 가해지고 있는지 알 수 있다 

Load Profile 항목 간단  Comment

Per Second: 1초당지표

Per Transaction: Transaction(Commit, Rollback)당평균지표

Block은  8kb

• DB cpu (s): Wait 없이 순수하게 CPU 사용하는 core 수   (자원 : CPU + Wait )

• Redo size(bytes): redo log 의증가크기(bytes) (2) 능에 중요한 부분 

 Logical reads(blocks): Buffer cache read block 수  (1) . 능에 중요한 부분   

• Block changes: (DML로) 변경된block수

• Physical read(blocks): Storage I/O read block 수 (1) . 능에 중요한 부분 

• Physical write(blocks): Storage I/O write block 수

• Read IO Requests: Read I/O 요청횟수

• Write IO Request: Write I/O 요청횟수

• Read IO(MB): Read I/O 크기

• Write IO(MB): Write I/O 크기

• IM scan rows : In memory 영역이다 

• Session Logical Read IM :  In memory 영역이다 

• User Calls: 클라이언트가요청한call 수(Parse, Execute 포함)

• Parses(SQL): Soft Parse + Hard Parse

• SQL Work Aread : PGA 에서 사용되고 있는 양

• User Logons : 얼마나 자주 Login/on 되는가 

• Executes(SQL): SQL 실행횟수

• Rollbacks: Rollback 횟수

• Transactions: Rollback + Commit

 

** Per Exec , Per Call 이전에 없던 컬럼이지만 잘 안본다고 함 

 

 

 

Load Profile 분석해보기

DB cpu :  1core 정도 사용 중 

• Redo size(bytes):   초당 0.645M 증가 중

   1) 큰수치이다  -- 15분에 500M 이다.  ( * Log Switch 최대 5분 준다 )

   2) Transaction 한번 하는데 Redo Size 4K를 썼다 

      평균값이기 때문에 , 특정 tx가 4K 이상의 Redo를 쓰고 있다고 예측 가능 

Logical reads(blocks):  초당 1G 정도 메모리 Access 중 

   transaction 단위로 봤을때 947byte -> 빠르게 처리되고 있다 

• Block changes: 초당 4000Block 이 변경되는 중

  Buffer Cache 내에서 Block들이 free, dirty 등 상태가 변경된다 

• Physical read(blocks):  

  transaction 단위로 봤을때 5 byte (많지 않음) -> tx가 IO를 거의 쓰지 않음 

• Physical write(blocks): 

   Batch 시스템의 경우 많이 보인다 

   transaction 단위로 봤을때 2.4 byte (많지 않음) -> tx가 IO를 거의 쓰지 않음 

• Read IO Requests:  769 x 8k = 약 6M

  Physical Read /Write 와 비슷하게 가나 요청을 1Block , MultiBlock 인지에 따라 다르게 나올 수 있다 

• Write IO Request: 

 Physical Read /Write 와 비슷하게 가나 요청을 1Block , MultiBlock 인지에 따라 다르게 나올 수 있다 

• User Calls: 

  Client 가 호출 한 것으로 Parse 와 Execute 를 포함한다 

  Execute 보다 많은데?? - PL/SQL 이 돌아서 그렇다 (흔한 case 는 아님 )

• Parses(SQL): 

• Executes(SQL):

   User 가 한번 Call 해도 여러개의 Execute 가 나올 수 있는데 대표적으로 PL/SQL 

   Transaction 하나당 평균적으로  27번의 SQL이 돈다 (좀 많음)

• Rollbacks:

  많으면 이상한 시스템.. 

• SQL Work Aread :  3mb 정도 PGA 쓰는 중 

• Transactions:

 

해당 Report 로 예측가능한 내용  

1) . Logical Read 가 많은 걸 봐서는 ==> OLTP성 서비스다  

2) .   Redo Size 보아하니 ==>  DML이 많다 

3) .   Redo sizeExecutes  보아하니 ==> 큼직한 Transaction이  있구나 

4) .   Logical reads ,  Physical read , Physical write 의 Per Transaction을 보니 ==> Tx이 IO 거의 없이 매우 빠르게 처리되고 있다  

 

 

 

 

 

Wait Event 보는 법 

Log File Sync 의 Wait 이 많다는건 DML이 빈번하게 발생하고 있다는 뜻 

DR 서버에 Sync로 보내고 있거나 , Storage 가 RAID 로 묶여있거나 Storage 가 부하가 많을 경우 난다