<11/06> 사랑은 타이밍

Test and Tuning

성능이란

response time + concureent through-put 확장성(스케빌리티) 고려 해야함

service time(수행시간) + latency(or wait) time(지연시간)<이 훨씬 많은 건수를 가짐

CPU 병목현상 CPU에 경합 발생 업무량에 맞춰서 CPU 개수를 다양하게 선택해야함

SMP 대용량 CPU 서버(36개) multiple process

사진 1

request network time 패킷 움직이는 시간 

transaction time 짧을수록 좋다

response network time

v$sysmetric 조회하면 현재 wait time 과 cpu time의 비율을 알려준다

이 비율 자체가 응답시간을 결정하는 요소다 

성능이 좋다? 사용자가 체감할 수 있는 수치

성능 저하 요인

SQL / App(어플리케이션 로직) / DB design(80%)

 - I/O가 가장 많이 차지하는 요인

DB 설계 정규화가 잘못되면 중복된 데이터를 읽게 되니 가장 큰 문제점이다

SQL의 처리순서에 입각해서 쿼리를 짜야 좋은 성능의 SQL을 짤 수 있다

옵티마이저의 튜닝을 통해 실행계획을 바꿀 수 있다.

SCOTT@orcl>ed

Wrote file afiedt.buf

  1  select ename, e.deptno, d.deptno, d.dname

  2  from emp e, dept d

  3  where e.deptno = d.deptno

  4* and ename like 'A%'

SCOTT@orcl>/

Execution Plan

----------------------------------------------------------

Plan hash value: 3625962092

----------------------------------------------------------------------------------------

| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |

----------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT             |         |     1 |    22 |     4   (0)| 00:00:01 |

|   1 |  NESTED LOOPS                |         |       |       |            |         |

|   2 |   NESTED LOOPS               |         |     1 |    22 |     4   (0)| 00:00:01 |

|*  3 |    TABLE ACCESS FULL         | EMP     |     1 |     9 |     3   (0)| 00:00:01 |

|*  4 |    INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)| 00:00:01 |

|   5 |   TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    13 |     1   (0)| 00:00:01 |

----------------------------------------------------------------------------------------

프리패칭 기능과도 연관있는 2중 nested loop 11g new features

Predicate Information (identified by operation id):

---------------------------------------------------

   3 - filter("ENAME" LIKE 'A%')

   4 - access("E"."DEPTNO"="D"."DEPTNO")

optimizer의 버번적 차이가 실행계획의 차이를 부른다

SCOTT@orcl>alter session set optimizer_features_enable = '10.2.0.1';

특정 어플리케이션이 10g기반에서 훨씬 빠를 경우 이해해야하는 파라메터

Session altered.

create table cpsal3 as select * from sales;

ddl은? dml은? dcl은?

모두 파싱할까?

AWR report 분석 이력서 

v$는 어디에서 조회해서 가져올까 shared pool session 정보가 따로 보관됨