Programming/Oracle

Performance Tuning 실무

초록깨비 2008. 12. 2. 13:27
728x90

Performance Tuning 실무

 

1.       현실적 저성능 시스템 요인

-          대부분의 주요인은 DB관련 비효율이며 cpu/memory부하가 아닌 비효율적인 I/O

2.       개선

-          RDB에 적합한 최적화와 DB Design, Optimizer가 최고의 효율을 낼수 있는 옵티마이징 전략과 집합개념의 고성능 SQL이 성공의 열쇠

 

1) 100만건                 2) 2만건

 

 

 

 

 

 


    100 byte                 10,000byte

 

1)      이 두배 빠름, 양으로

I/O block단위로 한다(row단위 x) oracle block 8k

 

 

3.       batch프로그램의 성능 개선

1)      절차형 -> 비절차형(SQL)로 바꾸는 것이 효율적이다

2)      절차형 TUNING에는 한계가 있다

cursor

select ~

                         -> 개선(8시간 -> 4시간) : index조정

fetch ~ 

4.       OLPT 성능개선

1)      사용자 SQL

2)      INDEX

3)      NASTED LOOP JOIN잘 되게 유도(OLPT에선 HASH JOIN, SORT MERGE JOIN의미 없음 : 비용이 많이 들기 때문에)

5.       JOIN때문에 속도가 느려지는 것은 아님(OLPT 상에서), 하나의 TABLE에서 SELECT하는것과 속도차 없음

6.       TABLE간에 중복 속성은 두지 않는 것이 좋다

7.       INDEX가 많으면 INSERT, UPDATE시 속도문제 발행(다량의 DATA처리시)

-          ACCESS PATH조사후 분별력 있는 컬럼으로 INDEX를 만들어 준다

(WHERE절에서 사용하는 조건)

8.       DECODE(구분, 2, 번호1,번호2) : 번호2가 필요없을 경우에는 쓰지 않는다. NULL일 경우에는 TABLE 검색 하지 않으므로 더 효율적

9.       배타(Exclusive-OR)관계에 대한 해소 부재

select distinct e.회원번호, e.상담일시, e.상담내용

from 상담내역 e, 회원 m, 준회원 s, 상태_분류코드 code

        where (e.상담분류코드 != 000 and e.상담분류코드 = 001)

            or (m.회원상태코드 = 002   and e.회원번호 = m.회원번호)     outer join

            or (s.준회원상태코드 = 003  and e.회원번호 = m.회원번호)  decode로 풀어야함

   

=> select e.회원번호, e.상담일시, e.상담내용

from 상담내역 e, 회원 m, 준회원 s, 상태_분류코드 code

          where (e.상담분류코드 != 000 and e.상담분류코드 = 001)

     and (m.회원번호(+) = decode(e.구분, 1, e.회원번호) and m.회원상태코드 = 002)

     and (s.회원번호(+) = decode(e.구분, 1, e.준회원번호) and s.회원상태코드 = 003)

상담내역

준회원

정회원

준회원 변경

정회원 변경

  

 

 

 

 

 

 

 

정회원

준회원

구분

회원 변경

 

상담내역

 

 

 

 

 

 

 

 

 

 

 


10.   성능진단 자료 분석

. SQL TRACE FACILITY

-          SQL문 사용에 대한 성능을 분석하기 위해 사용

-          SQL문에서 다음과 같은 정보를 수집(oracle db에서 실행되는 모든 sql의 통계자료를 trace file로 생성)

1)      parse, execute, fetch count별로 구분

2)      사용cpu시간과 elapsed(처리경과)시간

3)      physical read한 블럭수와 logical read한 블록수

4)      처리/추출된 rows

5)      실행계획

-          INSTANCE SESSION단위로 설정

-          TRACE 결과 파일은 TKPROF utility에 의해 사용자가 읽을수 있는 파일로 변환

 

-          파라메터 지정(alter system ~ or parameter에 직접 지정)

1)      TIMED_STATISTICS     TRUE

2)      SQL_TRADE             TRUE

3)      USER_DUMP_DEST      directory

4)      MAX_DUMP_FILE_SIZE  number

        

      instance level trace

1)      init.ora file parameter변경

timed_statistics = true

sql_trade       = true

user_dump_dest =/$oracle_home/rdbms/udump/trc

max_dump_file_size = 102000(os block size를 나타냄)

  . 이 값은 os block수를 나태내브로 os block size 512일 경우,

1024000 500mb 정도의 dump file을 만들 수 있음

2)      user_dump_dest에서 기존 trace file 삭제 : session id별로 생성됨

3)      database shutdown & startup

4)      trace file생성

 

      session level trace

1)

 

 

       

 

 


728x90