'Oracle/Tuning'에 해당되는 글 16건

  1. 2011.05.09 cursor_sharing
  2. 2011.04.15 내 tracefile 찾는 방법
  3. 2010.01.25 LOCK 관련 실습 1
  4. 2010.01.19 LRU 알고리즘
  5. 2010.01.18 Tuning the Buffer Cache
  6. 2010.01.16 Tuning the Shared Pool 1
  7. 2010.01.16 Reactive Tuning (EM의 performance page)
  8. 2010.01.15 AWR & ADDM & ASH
  9. 2010.01.15 Statspack
  10. 2010.01.14 Metrics, Alerts and Metric Baselines
Oracle/Tuning2011. 5. 9. 08:48






과도한 하드 파싱으로 인한 오라클의 성능 문제를 해결하는 방안으로 cursor_sharing 파라미터의 수정을 고려해 볼 수 있다.

cursor_sharing 파라미터는 비슷한 literal SQL을 바인드 변수로 치환해서 하드 파싱을 줄이도록 하는 기능이다.

이 파라미터는 기본 값은 EXACT로 SQL이 똑같을 때(띄어쓰기, 대소문자, 만 같은 SQL이라고 판단하는 것이다.

그 외 설정값은 SIMILAR, FORCE가 있다.

그러나 이 파라미터를 변경하기 전에는 철저한 검증이 필요하다.

아래의 포스터는 그에 관련된 내용이다.

참조 : similar cursor sharing의 문제점
         Similar cursor sharing and adative cursor sharing

'Oracle > Tuning' 카테고리의 다른 글

내 tracefile 찾는 방법  (0) 2011.04.15
LOCK 관련 실습  (1) 2010.01.25
LRU 알고리즘  (0) 2010.01.19
Tuning the Buffer Cache  (0) 2010.01.18
Tuning the Shared Pool  (1) 2010.01.16
Posted by 자수성가한 부자
Oracle/Tuning2011. 4. 15. 09:58







sql을 분석하기 위해 trace file을 생성하여 그 결과를 보고 분석할 수가 있다.
이 tracefile은 user_dump_dest에 지정된 디렉토리에 생성되게 되어있다.

그런데 만약 여러 유저가 trace file을 생성한다면 내것이 무엇인지 찾지 못할 것이다.

내것이 무엇인지 확인하려면 어떻게 해야할까?


일단 현재 user_dump_dest에 있는 파일을 보자.

# ls -lrt
total 66
-rw-r--r--   1 dba02    dba          140 Apr 13 09:42 afiedt.buf
-rw-r--r--   1 dba02    dba          238 Apr 15 09:30 t.sql
-rw-r-----   1 oracle   dba        21427 Apr 15 09:50 dba02_ora_21033.trc
-rw-r-----   1 oracle   dba         2975 Apr 15 09:51 dba02_ora_21646.trc
-rw-r--r--   1 dba02    dba         6623 Apr 15 09:51 tuning.txt

dba02_ora_21646.trc

맨뒤에 있는 숫자가 process의 id이다.

그러면 process id는 어떻게 찾을까?

SQL> select p.spid
  2    from v$process p, v$session s
  3   where p.addr = s.paddr
  4     and s.audsid = userenv('SESSIONID');

SPID
------------
21646

참 쉽죠?

'Oracle > Tuning' 카테고리의 다른 글

cursor_sharing  (0) 2011.05.09
LOCK 관련 실습  (1) 2010.01.25
LRU 알고리즘  (0) 2010.01.19
Tuning the Buffer Cache  (0) 2010.01.18
Tuning the Shared Pool  (1) 2010.01.16
Posted by 자수성가한 부자
Oracle/Tuning2010. 1. 25. 17:32

1. isqlplus로 v$resource와 v$lock을 질의하여, TM lock과 TM lock이 존재하지 않는 것을 확인한다.

SQL> select * from v$resource;
SQL> select * from v$lock order by ID1;



2. sysdba권한으로 sql plus에 접속해 scott유저의 emp테이블을 update한다.

OS] sqlplus / as sysdba
SQL> update scott.emp set sal = 140;


3. isqlplus로 v$resource와 v$lock을 질의한다. TX lock과 TM lock을 확인한다.

SQL> select * from v$resource;
SQL> select * from v$lock order by ID1;

ADDR TYPE ID1 ID2
304345E4 XR 4 0
3043484C CF 0 0
304349AC RT 1 0
30434A04 RS 25 1
30434B0C MR 3 0
30434B64 MR 4 0
30434BBC MR 5 0
30434C14 MR 6 0
30434C7C MR 7 0
30434CD4 MR 8 0
30434D2C MR 9 0
30434D84 MR 10 0
30434DDC MR 11 0
30434E34 MR 12 0
30434F94 MR 1 0
30434FEC MR 2 0
304354BC MR 201 0
30435D64 PW 1 0
304367C4 TA 6 1
3043748C TX 589842 597
30437594 TS 3 1
30438B04 TM 51148 0


ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
30FB9A9C 30FB9AB0 165 CF 0 0 2 0 873284 0
30FB9C68 30FB9C7C 167 PW 1 0 3 0 873274 0
30FB9D7C 30FB9D90 167 MR 1 0 4 0 873277 0
30FB9C0C 30FB9C20 166 RT 1 0 6 0 873280 0
30FB9DD8 30FB9DEC 167 MR 2 0 4 0 873277 0
30FB9E34 30FB9E48 167 MR 3 0 4 0 873277 0
30FB9CC4 30FB9CD8 164 TS 3 1 3 0 873275 0
30FB9E90 30FB9EA4 167 MR 4 0 4 0 873277 0
30FB9A40 30FB9A54 165 XR 4 0 1 0 873284 0
30FB9EEC 30FB9F00 167 MR 5 0 4 0 873277 0
30FB9F48 30FB9F5C 167 MR 6 0 4 0 873277 0
30FB9FA4 30FB9FB8 167 MR 7 0 4 0 873277 0
30FBA000 30FBA014 167 MR 8 0 4 0 873277 0
30FBA05C 30FBA070 167 MR 9 0 4 0 873277 0
30FBA0B8 30FBA0CC 167 MR 10 0 4 0 873277 0
30FBA114 30FBA128 167 MR 11 0 4 0 873277 0
30FBA170 30FBA184 167 MR 12 0 4 0 873277 0
30FB9B54 30FB9B68 165 RS 25 1 2 0 873280 0
30FBA1CC 30FBA1E0 167 MR 201 0 4 0 873277 0
2F9C3F90 2F9C3FA8 126 TM 51148 0 3 0 3 0
2FA1FBE8 2FA1FD04 126 TX 589842 597 6 0 3 0


4. scott 유저로 sqlplus로 접속 후, emp테이블을 update를 한다.

SQL> update emp set sal = sal + 140;



5. isqlplus로 v$resource와 v$lock을 질의한다. TX lock과 TM lock을 확인한다.
   v$resource는 변함이 없지만, v$lock은 TX lock과 TM lock이 하나씩 추가가 되었다. TM lock은 shared mode이므로 같은 리소스를 공유하고, lock도 같은 lock을 쓴다. 그리고 TX lock은 첫 세션에서 exclusive 모드로 lock을 잡고 있고, 두번째 세션에서는 exclusive 모드로 lock을 요청하고 있다.

ADDR TYPE ID1 ID2
304345E4 XR 4 0
3043484C CF 0 0
304349AC RT 1 0
30434A04 RS 25 1
30434B0C MR 3 0
30434B64 MR 4 0
30434BBC MR 5 0
30434C14 MR 6 0
30434C7C MR 7 0
30434CD4 MR 8 0
30434D2C MR 9 0
30434D84 MR 10 0
30434DDC MR 11 0
30434E34 MR 12 0
30434F94 MR 1 0
30434FEC MR 2 0
304354BC MR 201 0
30435D64 PW 1 0
304367C4 TA 6 1
3043748C TX 589842 597
30437594 TS 3 1
30438B04 TM 51148 0


ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
30FB9A9C 30FB9AB0 165 CF 0 0 2 0 873584 0
30FB9C0C 30FB9C20 166 RT 1 0 6 0 873580 0
30FB9D7C 30FB9D90 167 MR 1 0 4 0 873577 0
30FB9C68 30FB9C7C 167 PW 1 0 3 0 873574 0
30FB9DD8 30FB9DEC 167 MR 2 0 4 0 873577 0
30FB9CC4 30FB9CD8 164 TS 3 1 3 0 873575 0
30FB9E34 30FB9E48 167 MR 3 0 4 0 873577 0
30FB9E90 30FB9EA4 167 MR 4 0 4 0 873577 0
30FB9A40 30FB9A54 165 XR 4 0 1 0 873584 0
30FB9EEC 30FB9F00 167 MR 5 0 4 0 873577 0
30FB9F48 30FB9F5C 167 MR 6 0 4 0 873577 0
30FB9FA4 30FB9FB8 167 MR 7 0 4 0 873577 0
30FBA000 30FBA014 167 MR 8 0 4 0 873577 0
30FBA05C 30FBA070 167 MR 9 0 4 0 873577 0
30FBA0B8 30FBA0CC 167 MR 10 0 4 0 873577 0
30FBA114 30FBA128 167 MR 11 0 4 0 873577 0
30FBA170 30FBA184 167 MR 12 0 4 0 873577 0
30FB9B54 30FB9B68 165 RS 25 1 2 0 873580 0
30FBA1CC 30FBA1E0 167 MR 201 0 4 0 873577 0
2F9C3F90 2F9C3FA8 126 TM 51148 0 3 0 303 0
2F9C403C 2F9C4054 145 TM 51148 0 3 0 86 0
30FB9BB0 30FB9BC4 145 TX 589842 597 0 6 86 0
2FA1FBE8 2FA1FD04 126 TX 589842 597 6 0 303 1


'Oracle > Tuning' 카테고리의 다른 글

cursor_sharing  (0) 2011.05.09
내 tracefile 찾는 방법  (0) 2011.04.15
LRU 알고리즘  (0) 2010.01.19
Tuning the Buffer Cache  (0) 2010.01.18
Tuning the Shared Pool  (1) 2010.01.16
Posted by 자수성가한 부자
Oracle/Tuning2010. 1. 19. 18:16

LRU 알고리즘 이란?

LRU 알고리즘은 Least Recently Used의 약자로 기억장치 바깥으로 내보내야할 페이지를 선정할 때 가장 오랜 기간 사용되지 않았던 페이지부터 교체하는 페이지 교체 알고리즘 입니다. 이는 일반적으로 가장 오랫동안 액세스 되지 않았던 페이지는 앞으로도 액세스 되지 않을 확률이 제일 크다는 것에 기반한 것이다.

이 규칙은, 일반적으로 가장 오랫동안 액세스되지 않았던 페이지는, 조만 간에도 액세스되지 않을 확률이 가장 크다는 시간적 집약성에 기반을 두고 있다. LRU는 Belady의 변이를 나타내지 않는다.


오라클에서는 두가지 모드의 LRU 알고리즘이 있다.


MRU (Most Recently Used)
LRU (Least Recently Used)


1. standard mode
   가장 최근에 사용된 buffer의 헤더가  MRU end로 들어감.
  
2. modified mode
    Index로 읽어진 buffer의 헤더는 MRU end로 들어가고, full table 스캔에 의해서 사용된 buffer의 헤더는 LRU end로 들어간다.

단점 : 서버프로세스가 full table scan을 하면 그 때 사용된 buffer는 LRU list의 LRU end로 들어감 프리버퍼 찾을 때 금방 재이용된다.
        full table 스캔이라도 MRU end로 넣는다. -> 쓸데없는 io를 줄인다.


참고 : http://www.juliandyke.com/Presentations/Presentations.html#LogicalIO

'Oracle > Tuning' 카테고리의 다른 글

내 tracefile 찾는 방법  (0) 2011.04.15
LOCK 관련 실습  (1) 2010.01.25
Tuning the Buffer Cache  (0) 2010.01.18
Tuning the Shared Pool  (1) 2010.01.16
Reactive Tuning (EM의 performance page)  (0) 2010.01.16
Posted by 자수성가한 부자
Oracle/Tuning2010. 1. 18. 18:53
Database Buffer Cache 구조



그림 설명.
DBA + Block class에 해시 함수를 적용하면 특정 bucket으로 할당됨.
여러 bucket을 하나의 cbc latch로 보호하기 때문에 경합이 원인이 된다.
Buffer Header는 doulble linked list로 연결되어 있다.
currnet block과 cr블럭은 같이 연결되어 있다.
latch를 획득시에 두가지 모드 shared 모드와 exclusive모드가 있다.
Bucket하나에 Header하나가 좋음.
Working Set은 버퍼의 부분집합이다. LRU list와 CKPT cue 두가지가 있다.
Working set의 갯수는 cpu의 갯수와 DBWR의 갯수에 따라 달라짐.


튜닝의 목표
1. hit ratio를 높일 것
   ※ hit ratio?  원하는 data block을 메모리에서 찾을 확률
       계산법 : 1 - physical reads/logical reads


SQL> select name, value
         from v$sysstat
        where name in ('db block gets from cache',
                               'consistent gets from cache',
                               'physical reads cache');


     - db block gets from cache : caching 되어 있는 data block을 읽은 횟수
     - consistent gets from cache : cr블럭을 읽은 횟수
     - physical reads cache : 디스크에서 data block을 읽은 횟수


    hit ratio만으로는 튜닝의 대상인지 판단하기 어렵다.
    예)
    A SQL               99%                  99만블럭 / 100만블럭
    B SQL               60%                  60블럭 / 100블럭


2. wait를 줄일 것 : 더 비중을 둔다.
   ① latch : cache buffer chains (cbc latch)
      관련 view : v$latch, v$system_event
      여러 유저가 같은 block을 access할 경우 cbc latch에 경합이 생긴다.
      비효율적인 SQL, hot segments일 경우 이 지표가 올라간다.

      hot segment를 찾는 방법
      ⓐ 아래의 SQL을 실행

SQL> select *
         from (select owner, object_name, object_type, statistic_name, sum(value)
                  from v$segment_statistics
                  group by owner, object_name, object_type, statistics_name
                  order by sum(value) desc)
         where rownum < 10


      ⓑ statspack을 남길 경우 level을 7이상으로 한다. -> segment 통계가 남는다.

   ② latch : cache buffer lru chains (cblc latch)
      관련 view : v$latch, v$system_event

   ③ buffer busy waits
      관련 view : v$system_event
      : 하나의 버퍼에 여러 개의 프로세스가 동시에 사용하려고 할 때 발생하는 wait지표 
        buffer lock을 header에 기록
      buffer busy waits를 확인하는 SQL

SQL> select class, count
         from v$waitstat
         where count>0
         order by count desc;


     block class를 확인하는 SQL

SQL> select rownum, w.* from v$waitstat w;

     block class의 의미

Class Description
1 data block
2 sort block
3 save undo block
4 segment header
5 save undo header
6 free list
7 extent map
8 1st level bmb
9 2nd level bmb
10 3rd level bmb
11 bitmap block
12 bitmap index block
13 file header block
14 unused
15 + 2*r undo header block(r = Undo Segment 번호. 0 = System undo segment)
16 + 2*r undo block(r = Undo Segment 번호. 0 = System undo segment)






















      15 : system이라는 undo segment의 헤더 블럭
      16 : system이라는 undo segment의 일반 undo 블럭
      17 : 사용자가 사용할 수 있는 undo tablespace안에 있는 1번 undo segment의 헤더 블럭
      18 : 사용자가 사용할 수 있는 undo tablespace안에 있는 1번 undo segment의 undo 블럭

      cf) read by other session
          : 한 프로세스가 데이터 블럭을 읽어서 메모리에 올리고 있는 중에 다른 프로세스가 읽으려고 할 때 발생하는 지표
           -> I/O의 문제가 있는 것.

   ④ free buffer waits
      관련 view : v$system_event
      server process가 lru알고리즘을 이용해서 free buffer 를 찾는다. 그때 free buffer가 없어서 기다릴 경우 발생하는 지표
      - 메모리의 크기를 늘여주거나 줄여준다.
         관련 파라미터를 설정한다.(계속해서 모니터링 해야 한다.)
           db_cache_size, db_keep_cache_size, db_recycle_cache_size
          사전 준비사항
           create index cust_idx storage (buffer_pool keep ...)
           create table customer storage (buffer_pool recycle ...)
           create index cust_name storage (buffer_pool keep ....)

          advisor를 사용하는 방법 : db_cache_advice를 on으로 설정하여야 한다.
            관련 view : v$db_cache_advice

   ⑤ reads waits
      - 관련 wait 지표
        db file sequential read : single block io를 할 때 올라감.
        db file parallel read : 병렬 처리로 data block을 읽어 올림.
        db file scattered read


튜닝 방법
1. Database Buffer Cache의 크기를 늘이거나 줄이는 것
   : ASMM, Advisor
2. SQL Tuning
3. Multiple Buffer Pool(default, keep, recycle)
    교도소 : recycle
    io를 줄이는 것이 목적.
4. Caching Table
  사전 지식 : LRU 알고리즘.
   아주 자주쓰는 작은 테이블을 caching tables로 만든다.

SQL> create table t1 .... cache;


-- select시에 hint를 이용
select /*+ cache */
* from t1;


5. DB_nK_CACHE_SIZE : multiple block size
6. DBWR 튜닝(N개 또는 Slave process(서버 프로세스가 DBWR의 역할을 대신하도록 한다.))
    - DBWR의 갯수 변경 : DB_WRITER_PROCESSES파라미터를 변경시켜주면 됨. 최대 20개까지 늘일 수 있음.
    - slave process : DBWR_IO_SLAVES파라미터를 변경시켜주면 됨.
7. Direct Path I/O
8. I/O system(SAME)
9. MBRC

flushing the Buffer Cache

SQL> alter system flush buffer_cache


기타 참고사항

- OWI (Oracle Wait Interface)?
   : 오라클 서버 내에서 일어나는 여러가지 일들을 여러가지 지표를 통하여 확인하고

- Cache Fusion
    : 한 데이터베이스에 두개 이상의 instance가 있는 환경(RAC)에서 disk에서 block을 읽어오는 것이 아니고 다른 instance의 buffer를 읽는 것.

- LRU알고리즘의 종류
  1. standard lru
  2. touch count lru

- SQL에서의 literal은 문자, 숫자, 날짜를 의미한다.

- 기술면접 예상질문 :
    nested loop join에 대해서 말씀해보세요.(비교적 쉬운 질문)
    Query Transformation에 대해서 말씀해보세요.
    logical optimization, physical optimization에 대해서 말씀해보세요.
    histogram에 대해서 아는데로 말씀해보세요.

- dirty buffer : 원본과 내용이 다른 버퍼

- keep의 크기는 들어갈 데이터의 크기에 조금 더 준다. - 왜? cr블럭을 위해서...

참고 : http://blog.naver.com/orapybubu?Redirect=Log&logNo=40047392715
         http://wiki.ex-em.com/index.php/Buffer_busy_waits

'Oracle > Tuning' 카테고리의 다른 글

LOCK 관련 실습  (1) 2010.01.25
LRU 알고리즘  (0) 2010.01.19
Tuning the Shared Pool  (1) 2010.01.16
Reactive Tuning (EM의 performance page)  (0) 2010.01.16
AWR & ADDM & ASH  (0) 2010.01.15
Posted by 자수성가한 부자
Oracle/Tuning2010. 1. 16. 13:37

Shared Pool의 architecture
- library cache(주요 관심사)
- data dictionary cache(row cache)
- UGA(User Global Area)
- flashback buffer
- ash buffer


Shared Pool
  : 새로운 object (LCO:Library Cache Object) 가 메모리 할당 요구 - 가능하면 free chunk가 할당됨.
    큰 LCO 는 여러개의 chunk로 만들어짐.
    chunk는 연속적이다.
    LRU 알고리즘에 의해 관리됨.
    관련 지표 : latch : shared pool

  ※ Q  : 왜 shared pool tuning을 먼저 하는가?
      Re : hard parsing을 하면 상당히 비용이 든다.
             performance 관련 문제가 자주 생기는 영역이기 때문에
             shared pool의 튜닝이 완료되면 그 외의 영역에서 효과를 볼 가능성이 크기 때문에

Library Cache
  : 커서들과 관련된 복잡한 metadata가 저장되어 있음.
    SQL 문과 유저에게 공유될 PL/SQL block이 저장되어 있음
    동일 문장에 대한 반복 parsing을 줄일 수 있음.
    관련 view : v$librarycache
    관련 지표 : latch : library cache

  ● library cache에 튜닝이 필요한 것을 확인하는 방법
     1. statspack/AWR indicators
        - load profile
        - instance efficiencies
           execute to parse : 높을 수록 좋음. parse가 적고 execution이 크면 이 숫자가 큼.
                                      cursor 공유가 잘 안되고 있음. 음수가 되는 경우가 있다. 
                                      계산식 {100 * (1- parse/execute)}
           parse CPU to Parse Elapsed : parse elapsed는 parse하는데 걸린 시간.
       - top wait events : latch : shared pool, latch : library cache
          지표(latch : library cache, latch : shared pool) 들을 보고 적절한 대응을 한다.
       - time model

     2. v$librarycache의 주요 컬럼
        - gets : LCO를 찾아본 횟수, 명령을 던진다.-> 동일 문장을 찾으려고 한 횟수
        - gethits : 동일 문장을 찾은 횟수
        - pins : LCO를 읽거나 실행한 횟수, 
        - pinhits : LCO에 특정 표시를 하는 행위
        - reloads : 메모리 부족으로 내려진 sql이 다시 load된 횟수
                        명령을 던진다 -> 그 명령을 위한 메모리를 할당 -> 메모리에
                        증가되고 있다 -> hard parse가 크다.
        - invalidation : 참조하고 있는 객체가 alter 되었을 경우, invalidate됨.
                             dbms_stats로 통계를 새로 잡는 것도 invalid하게 만듬.
                            증가할 경우 hard parsing이 증가한다.

  ● latch : library cache지표를 줄이기 위한 튜닝 목표
    1. hard parsing을 줄이는 것
       : OLTP에서 주로 발생.
       ① 공유 가능한 문장이 되도록 한다.(코딩 규약 준수, 바인드 변수 사용 촉진 등)
       ② 메모리를 적당히 크게 줄 것.
       ③ reparsing을 유발하는 invalidation을 줄일 것 -> DDL사용 줄이고, 통계 생성 주기를 조금 길게 할 것

    2. soft parsing을 줄이는 것
       ① session_cached_cursor 파라미터를 설정한다.
           이 파라미터의 값이 설정되어 있으면 세션당 설정되어 있는 수만큼의
            LCO handle의 주소가 PGA로 옮겨진다.(3번이상 수행된 SQL에 한해서)
       ② hold_cursor 파라미터를 설정한다.
       ③ cursor_space_for_time 파라미터를 설정한다.

    3. 단편화(fragmentation)를 줄이는 것
       ① 서로 다른 크기가 원인일 경우
          ⓐ 10g R2 버전으로 업그레이드 -> 특정 크기의 배수로 chunk를 할당하기 때문에 단편화가 발생가능성이 줄어든다.
          ⓑ 예약 공간을 설정을 변경한다.
              - 관련 파라미터 : shared_pool_reserved_size, shared_pool_size
              - 관련 view : v$shared_pool_reserved (판단하는데 쓰임)
                                 request_misses : 0이면 예약이 바로 되는 것 -> shared_pool_reserved_size를 줄인다.
                                 request_failueres : 
       ② 들락날락
          ⓐ keep : 자주쓰는 오브젝트를 메모리에 오래도록 남긴다.
          ⓑ 이름이 없는 pl/sql블럭에 이름을 붙인다. -> keep
          ⓒ large pool 설정
       ※ 단편화란?
           : 서로 다른의 chunk가 들락날락 하기 때문에 총량은 많으나 실제로 쓸 수 있는 공간이 부족한 현상.
      
    
Data Dictionary Cache
 : 관련 view : v$rowcache
  dc_free_extents : tablespace생성시 extents 크기를 너무 작게 잡을 경우 값이 커진다. -> tablespace 새로 생성해야 한다.

UGA
 : large pool을 잡는다.
   v$sesstat을 사용하여 UGA에 해당하는 크기를 구함.

Large Pool

SQL> select * from v$sgastat where pool = 'large pool';


상황)
프로젝트 내에 직접 개발하는 것과 제품이 같이 있을 경우에서 제품내에서 바인드 변수를 사용하지 않아
제품이 실행되기만 하면 서버에 많은 부하를 줄 때 해법은?

  1. 제품을 새로 산다.
  2. 그냥 쓴다.
  3. cursor_sharing을 exact에서 similar를 바꾼다. 커서 공유가 된다.-> bind변수로 바뀐다.
    (단, 이 파라미터 변경시 많은 부작용이 있으므로 관련 내용을 충분히 습득한 후 적용한다. 8i~)
    OLAP = exact(가끔 SQL이 날아오기 때문에 정확한 실행계획을 선택하도록)로 두고
    OLTP = similar(비슷한 쿼리끼리 같은 실행계획을 쓴다.)


실습 예제) latch : library cache 관련 경합 예제 (선생님 블로그 보고 나중에 넣을 것)



기타 참고사항

- Granule 
   : SGA memory가 할당되는 단위. 메모리에서의 extent
                4M               or 16M
                 ↓                      ↓
                SGA 1G이하       2G

- Chunk
   : 메모리의 작은 조각
     Shared Pool에서 라이브러리 캐쉬 오브젝트를 위해 할당되는 메모리 단위.
     필요에 의해 다양한 크기를 가짐.

- Mutex
  : Mutual Exclusive의 줄임말.
    latch와 비슷하게 자원을 보호하는데 쓰이는 매커니즘
    자원 관리 매커니즘의 일부를 OS로 넘긴다. 
    경합의 우려가 latch보다 적다.
    latch로 자원을 보호할 때 보다 빨라짐.

   관련 view : v$mutex_sleep, v$mutex_sleep_history
   관련 wait 지표 : cursor:mutex x
                          cursor:mutex s
                          cursor:pin x
                          cursor:pin s
                          cursor:pin s wait on X

참고 : http://blog.naver.com/orapybubu?Redirect=Log&logNo=40047213691
         http://www.oracle.com/technology/global/kr/pub/columns/dbtuning02.html

'Oracle > Tuning' 카테고리의 다른 글

LRU 알고리즘  (0) 2010.01.19
Tuning the Buffer Cache  (0) 2010.01.18
Reactive Tuning (EM의 performance page)  (0) 2010.01.16
AWR & ADDM & ASH  (0) 2010.01.15
Statspack  (0) 2010.01.15
Posted by 자수성가한 부자
Oracle/Tuning2010. 1. 16. 12:51
Reactive Tuning
  - App
  - DB Server
      memory : sga,pga
      IO : physical io, data placement
      contention : locks, latches
  - OS : EM
     OS 관련 내용을 볼 수 있는 view : v$osstat;

EM의 performance 화면 설명
  - active sessions 그래프 : ASH를 근거로 화면에 표시됨.

  - historical interval section
    performance화면에서 오른쪽 위의 view data에 historical을 선택하면 나오는 화면
     period sql : 24시간동안의 주요 튜닝 대상인 SQL을 보여줌.
     instance activity : 정보의 출처는 v$sysstat

기타 참고사항

- CTWR (Change Tracking Writer) : change tracking file에서 각각 변경된 블럭의 주소를 기록하는 백그라운드 프로세스
- change tracking file : 변경된 블럭의 주소가 들어 있음.

'Oracle > Tuning' 카테고리의 다른 글

Tuning the Buffer Cache  (0) 2010.01.18
Tuning the Shared Pool  (1) 2010.01.16
AWR & ADDM & ASH  (0) 2010.01.15
Statspack  (0) 2010.01.15
Metrics, Alerts and Metric Baselines  (0) 2010.01.14
Posted by 자수성가한 부자
Oracle/Tuning2010. 1. 15. 19:00

AWR
(Automatic Workload Repository)

  : performance statistics가 MMON에 의해 자동으로 수집되는 저장소.
    수집되는 주기는 60분에 한번씩이며, 7일동안 수집된다.
    200M ~ 300M 정도의 공간을 사용한다.
    sys소유의 sysaux tablespace를 사용하는 table들의 덩어리
    10g~

  - 관련 패키지 / 함수
   : dbms_workload_repository.create_snapshot() : 수동으로 snapshot을 생성
     dbms_workload_repository.create_baseline() : baseline생성.
     dbms_workload_repository.modify_snapshot_setting(retention,internal, topnsql)
             retention : 보관하는 기간을 분으로 나타냄. 0일 경우 snapshot을 삭제하지 않음.
             internal : snapshot을 수집하는 주기. 0일 경우
             topnsql
 
  cf. snapshot이란? 특정 시점에 캡쳐된 performance statistics set
 

ADDM
(Automatic Database Diagnostic Monitor)

  : MMON에 의해 수집된 데이타베이스 성능 통계에 대한 철저한 분석을 통해 성능 병목을 확인하고, SQL 구문에 대한 분석을 통해 성능 향상을
    위한 권고안을 제공한다. 또한 SQL Tuning Advisor와 연동된 기능을 제공하기도 한다.

  - EM page 의 addm finding : 숫자 -> 가장 최근의 수집된 snapshot에서의 문제 갯수
  - statistics_level 파라미터의 값이 typical이상이어야 ADDM이 실행된다.


  - ADDM에게 영향을 줄 수 있는 parameter 검색하는 SQL

SQL> select *
         from dba_advisor_def_parameters
         where advisor_name='ADDM';


  DBIO_EXPECTED : 한 블럭을 읽어 올리는데 걸리는 시간을 micro second로 나타낸 parameter

 - 관련 패키지 / 함수
   dbms_advisor.GET_TAKE_REPORT : 그동안의 ADDM의 결과보고서를 파일로 저장할 수 있다.


ASH
(Active Session History)

: 현재 접속해서 활동 중인 Active 세션 정보를 1초에 한번씩 샘플링해서 ASH 버퍼에 저장한다. 
  shared pool안에 있는 메모리.cpu당 2m, 
   v$active_session_history(실제로 일을 하고 있는 session의 정보)의 데이터를 1초에 한번씩 옮겨진다.
  10g new feature
  

  MMON은 자동적으로 60분에 한번씩 Workload repository로 ASH buffer에 있는 내용을 내려씀
  MMNL(Manageability monitor light): 66%가 차면 ASH buffer의 내용을 Workload Repository 로 내려씀

  ※ 활용하는 법
     1. dump to trace file
 
       - setmypid 명령을 이용하면 현재 세션으로 Attach한다.

SQL> oradebug setmypid


      - level 10으로 ash buffer의 전체 내용을 내려받는다.

SQL> oradebug dump ashdump 10


     2. v$active_session_history
     3. dba_hist_active_session_history
     4. ashrpt.sql script를 실행하여 report를 생성한다. 


기타참고사항

- report를 생성할 수 있는 script
   AWR     : awrrpt.sql, awrddrpt.sql      -- 분석(사람)
   ADDM   : addmrpt.sql                      -- 진단한 결과로부터 권고안까지 report내용에 들어감.
   ASH      : ashrpt.sql                         -- 분석(사람)


참고 : oradebug
         http://wiki.oracleclub.com/display/CORE/ASH%28Active%2BSession%2BHistory%29
         http://www.goodus.co.kr/web2008/kl_center/tn.asp

'Oracle > Tuning' 카테고리의 다른 글

Tuning the Shared Pool  (1) 2010.01.16
Reactive Tuning (EM의 performance page)  (0) 2010.01.16
Statspack  (0) 2010.01.15
Metrics, Alerts and Metric Baselines  (0) 2010.01.14
[펌]SQL*TRACE와 TKPROF  (0) 2010.01.13
Posted by 자수성가한 부자
Oracle/Tuning2010. 1. 15. 14:36

statspack이란?
데이터베이스의 performance 관련 데이터를 수집하는데 필요한 *.sql file과 package를 말한다.

statspack의 snapshot level
level 0 : General performance
5 : level0 + sql 에대한 정보 (default)
6 : level5 + sql 상세 실행계획
7 : level6 + segment-level statistics
10: level7 + parent and child latches

v$segment_statistics : 문제의 주범(?)을 쉽게 찾을 수 있게해주는 view
statistics의 level을 7이상 해 놓으면 v$segment_statistics의 내용을 남김.

statspack사용시 고려해야 할 사항.
- statistics_level = typical
- timed_statistics + true
- 수집 기간을 적당하게 줄 것.


Load Profile Section
- 특정 application의 특징들을 볼 수 있다.
- 잠재적 문제를 확인할 수 있다.
- baseline이 있을 경우 효용성이 큼.


statspack 생성 실습(snapshot 수집, report 생성 포함)

OS] export ORACLE_SID=orcl
OS] sqlplus / as sysdba
SQL> shutdown abort
SQL> startup
SQL> define _editor=vi
SQL> !ls $ORACLE_HOME/rdbms/admin/sp*               -- statspack과 관련된 script들을 볼 수 있다.
SQL> ed /u01/app/oracle/product/10.2.0/db_1/rdbms/admin/spcreate.sql
SQL> @?/rdbms/admin/spcreate.sql
Enter value for perfstat_password: pertstat
Enter value for default_tablespace: enter                     -- default는 system tablespace임
Enter value for temporary_tablespace: enter
SQL> show user                                                     -- perfstat user가 생성되고, 그 유저로 접속된 것을 확인할 수 있다.

USER is "PERFSTAT"
SQL> col object_name format a40
SQL> select object_name, object_type
         from user_objects order by 2;
SQL> desc statspack
SQL> col name format a30
SQL> select * from stats$sga;
SQL> exec statspack.snap                     -- snapshot 수집
SQL> select * from stats$sga;
SQL> variable no number
SQL> exec :no := statspack.snap          
SQL> print no

        NO
----------
        12
SQL> @?/rdbms/admin/spreport.sql          -- 만들어진 snapshot을 토대로 report를 생성
시작 snapshot과 끝 snapshot을 설정후 report 이름을 차례로 입력해 준다.
Instance     DB Name        Snap Id   Snap Started    Level Comment
------------ ------------ --------- ----------------- ----- --------------------
orcl         ORCL                 1 15 Jan 2010 14:15     5
                                  2 15 Jan 2010 14:16     5
                                  3 15 Jan 2010 14:17     5
                                 11 15 Jan 2010 14:18     5
                                 12 15 Jan 2010 14:19     5
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 1
Enter value for end_snap: 3

Enter value for report_name: first_report.lst
SQL> exit
OS] vi first_report.lst


statspack 삭제실습(spdrop.sql script를 실행)

SQL> @?/rdbms/admin/spdrop.sql


그 외의 script 및 기타 사항들

- sppurge.sql : 의미없는 데이터는 사라진다.
- sptruncate.sql : snapshot을 지움.
- exp perfstat/perfstat parfile=spuexp.par  : spuexp.par 파일은 export 시의 파일에 부여할 수 있는 여러 옵션들이 저장되어 있음.



참조 : http://download.oracle.com/docs/cd/B10501_01/server.920/a96533/statspac.htm#29200
         http://www.oracleclub.com/lecture/1915
         http://www.yes24.com/24/goods/291430
         http://blog.daum.net/_blog/BlogView.do?blogid=08n3a&articleno=14734688&_bloghome_menu=recenttext#ajax_history_home
         http://extremedb.blogspot.com/2008/02/statspack.html

'Oracle > Tuning' 카테고리의 다른 글

Reactive Tuning (EM의 performance page)  (0) 2010.01.16
AWR & ADDM & ASH  (0) 2010.01.15
Metrics, Alerts and Metric Baselines  (0) 2010.01.14
[펌]SQL*TRACE와 TKPROF  (0) 2010.01.13
Statistics, Waits  (0) 2010.01.13
Posted by 자수성가한 부자
Oracle/Tuning2010. 1. 14. 18:21
Metrics
: 누적 통계에서 변화의 비율
  base statistics로 부터 파생된 2차통계
※ Base statistics : 정상적으로 시스템이 돌아갈 때 수집한 데이터
내부 컴포넌트를 위해 사용됨.
Base Statistics의 한계를 극복하기 위해 나온 개념
관련 view : v$sysmetric, v$sessmetric, v$servicemetric, v$filemetric

Statistic Histograms
: 막대 그래프, metric은 잠재적인 문제를 알 수 있지만 histogram을 이용하면 명확하게 문제를 알 수 있다.

SQL> select * from v$sql_workarea_histogram;
SQL> select * from v$file_histogram;
SQL> select * from v$event_histogram;


Alerts
: 주시하고 있는 Metric을 기준으로 임계점을 넘어갈 때 발생되는 이벤트
  tool generated alert : EM과 같은 tool이 발생시키는 alert -> 적시성이 조금 떨어질 수 있음.
  server generated alert : server에서 특정 상황이 발생되지마자 발생된다.
   - metric based alert : metric을 기준으로 임계점을 넘었을 때 발생되는 이벤트
   - event based alert : 에러 발생시 나타나는 에러(snap too old) 등
  push mode : 서버가 em에 던진다.
  pull mode : tool이 특정 주기마다 가져감.


Metric Baselines
 : 15개 정도의 metric의 값이 자동 변경되는 기능
   adaptive alert threshold : 시점에 따라 비교의 기준을 다르게 함.
   baseline normalized view : 여러가지 척도를 한눈에 볼 수 있게 함.
    예년 : 최근 30년 평균
   EM의 기능.
  

참고 : http://blog.naver.com/orapybubu?Redirect=Log&logNo=40046954315


기타 참고사항

- v$fixed_table : This view displays all dynamic performance tables, views, and derived tables in the database

- drill down : 주어진 데이터들을 가능하면 상세한 범위까지 사용자가 볼 수 있게 끔 하는 특별한 분석 기술

'Oracle > Tuning' 카테고리의 다른 글

AWR & ADDM & ASH  (0) 2010.01.15
Statspack  (0) 2010.01.15
[펌]SQL*TRACE와 TKPROF  (0) 2010.01.13
Statistics, Waits  (0) 2010.01.13
Tuning Overview  (0) 2010.01.12
Posted by 자수성가한 부자