Tip
2010.04.28 16:08

버퍼캐시와 OWI

조회 수 19873 추천 수 0 댓글 1

버퍼 캐시와 OWI
================

버퍼 캐시 구조 : 효과적인 관리를 위해 해시 체인(Hash chain) 구조를 사용한다.
                 hash chain은 shared pool 내에 존재하며 오라클ㄹ의 전형적인
                 메모리 구조 관리기법인
                 => 버킷 -> 체인 -> 헤더 의 구조를 사용한다.
                
                 CBC = cache buffers chains (버퍼블록을 찾을때 필요한 래치)
                 CBLC = cache buffers lru chain (버퍼에서 더티버퍼와 프리버퍼를 찾을때 필요한 래치)
                
                 해시 체인 구조는 Shared pool 영역에 존재하며, 실제 버퍼에 대한 정보들은 버퍼 캐시에 존재한다.
                
                 해시 체인 구조는 하나의 cach buffers chains 래치를 이용해 보호 된다.
                 특정 블록 스캔시 프로세스당 하나의 cache buffers chains 를 획득한다.
                 동시에 많은 수의 프로세스가 캐시를 탐색할 경우 경합이 생긴다.
                 9i부터는 읽기 전용작업에 한하여 shared 모드로 획득하나.
                 buffer lock 을 획득하거나 해제할 때 cache buffers chains 래치를 exclusive하게 획득하기 때문에
                 읽기 작업만 수행하는 경우에도 여전히 경합 발생한다.....
                
dbworksTM^^> -- 다음 명령어로 cache buffers chains 래치 개수 구하기
dbworksTM^^> select count(*) from v$latch_children where
              name ='cache buffers chains';

  COUNT(*)
----------
      1024
     
BUFFER LOCK 은 cache buffers chains latch 와 cache buffers lru chains latch 가 해시 체인 구조와
============   Working Set(LRU + LRUW) 구조를 보호하는 역할을 한다면 buffer lock은 버퍼 자체를 보호한다.
               엄밀히 말하면 버퍼 헤더에 대해 동시에 두 프로세스가 내용 변경을 못하게 막는 역할....
           
(buffer busy waits)  - cache buffers chains latch 로 버퍼에 데이타가 올라와 있는 것을 확인하면
                       해당 버퍼에 대해 buffer lock을 획득하는 과정을 가지는데 이과정에서
                       경합이 생기면 buffer busy waits 이벤트를 대기하게 된다.
             
(write complete waits) - dbwr에의해 기록중인 버퍼에 대해 buffer lock을 획득하는 중에 경합이
                         생기면 write complete waits 가 대기하게 된다.
             
              buffer lock 획득후 읽는 작업을 "Logical Reads 작업이라고 한다.
              - 이작업이 일관된 모드이 읽기 작업이면 : consistent gets 값이 증가
              - 이작업이 현재 모드의 읽기 작업이면 : db block gets 통계값이 증가 한다.
             
              따라서 session logical reads 값 = consistent gets + db block gets 이다.
             
              "LOGICAL READS 가 높으면 BUFFER LOCK 때문에 성능이 떨어진다."
             
(read by other session) - 퍼버 캐시에 값이 없으면 Working set 을 관리하는 cache buffers lru chain latch를 획득한다.
                          latch가 프리블록을 찾으면 buffer lock이 lock을 걸고 데이타 파일을 디스크에서
                          해당 버퍼로 읽어 올린다. 이때 buffer lock을 획득하는 과정에서 경합이
                          생기면  read by other session 이벤트를 대기한다.  
                          버퍼 캐시를 경유한 정확한 Physical Reads를 구할려면
                          physical reads 통계값에서 physical reads direct,physical reads direct(lob)통계 값을 빼면 된다.        
                         
(Buffer Pinning) -   Logical Reads는 매번 latch를 획득해야한다. latch경합을 없애기 위해서 Buffer Pinning 이라는 기법을
                   사용하는데 2번이상 스캔된 버퍼는 Pinned 상태로 변환된다. 래치 획득없이 곧바로 찾아 갈 수 있다.
                     Buffer Pinning 기법을 사용시 session logical reads 대시 buffer is pinned count 값이 증가한다.
                     pinned 상태라도 메모리의 I/O자체는 발생하며 래치획득과 해시 체인 탐색과 같은 부가적인 작업이 줄어든다.....                         
                         
             
- 버퍼 캐시 덤프
  -level 1 = Header only, level 10 = ALL
  SQL> alter session set events 'immediate trace name buffers level 1';
  or
  SQL> oradebug dump buffers 1
 
  내용은 87쪽....              
 
- Buffer Cache에서 대기 이벤트들

############ latch: cache buffers chains
  9i 부터는 Shared mode 에서 cache buffers chains 래치에 대해 select 에 대한 발생되지 않아야 하ㅏ지만
  실제로 버퍼 헤더 정보를 Exclusive 모드로 변경해야 하기 때문에 buffer lock을 해제하는 동안에도
  Exclusibe하게 획득해야 한다.
 
  - 비효율적인 SQL
  - 핫블록
 
# 핫블록인지 비효율적인 SQL인지 아래의 쿼리로 판단 할 수 있다.

  SQL> select * from
              (select child#, gets, sleeps from v$latch_children
               where name = 'cache buffers chains'
            order by sleeps desc
            ) where rownum <= 20;       
           
    CHILD#       GETS     SLEEPS
  ---------- ---------- ----------
      1001       1846          13
       350       1710          14
      1024       1196          23
      1023       1219          14
      1022       1219          15
      1021       1285          12
      1020       1320          14
      1019       1625          13
      1018       1518          11
      1017       1434          12
      1016       1503          11     
     
      만약 특정 자식 래치의 GETS, SLEEPS 값이 다른 자식 래치에 비해서 비정상적으로
      높다면 해당 래치가 관장하는 체인에 핫블록이 있는 것으로 추측할 수 있다.
      위의 테스트를 수행한 수의 결과는 특정 래치에 대한 편중 현상이 보이지 않으므로
      핫블록에 의한 문제는 없다고 판단할 수 있다.    
     
Parallel Query를 적절히 사용하는 것도 cache buffers chains 래치 경합을 줄이는 방법이 될 수 있다.
Parallel Query는 SGA를 거치지 않고 데이터 파일에서 원하는 데이터를 직접 읽어 들이기 때문에
버퍼 캐시에서의 경합 문제 자체가 존재하지 않는다. 하지만 Parallel Query는 대용량 데이터를 처리하기
위해 사용되는 것으로 래치 경합을 위한 일반적인 해결책으로 권고되지는 않는다.

Parallel Query 는 : TC락 경합과 direct path read 이벤트가 발생함

  • 유주환 2010.04.29 13:31
    결국엔 비효율적인 sql이 문제가 되죠~~ sql 튜닝 ㅜ.ㅜ

List of Articles
번호 분류 제목 글쓴이 날짜 조회 수
공지 Q&A Oracle관련 게시물만 Sean 2014.04.09 84902
76 Tip 오라클 null값 정리 유주환 2010.04.18 29867
75 Tip sysaux resize 유주환 2010.04.18 25290
74 Tip Analyze 통계정보 dbkill 2010.04.11 13296
73 Tip Expdp/Impdp시 ORA-31633 에러 해결 방법 2 김준호 2010.04.20 22479
72 Tip DATAFILE SIZE 줄이는 계산 1 고구마 2010.04.19 13475
71 Tip 세마포어에 대하여 고구마 2010.04.19 13230
70 Tip DML_DDL_로그기록_체크 유주환 2010.04.19 13417
69 Tip 통계 백업 및 생성 유주환 2010.04.18 16183
68 Tip shared pool / library cache 고구마 2010.04.28 25066
67 Tip DML 문의 처리과정 고구마 2010.04.28 17306
66 Tip Buffer Cahe 관련 대기 이벤트들 고구마 2010.04.28 25635
65 Tip Buffer busy waits 고구마 2010.04.28 19597
» Tip 버퍼캐시와 OWI 1 고구마 2010.04.28 19873
63 Tip IDLE EVENT 유주환 2010.04.23 21499
62 Tip 권한주기 고구마 2010.04.23 15735
61 Tip 핫백업 디비올리기 유주환 2010.04.09 34980
60 Tip partiton table truncate 및 rebuild 작업 유주환 2010.04.09 10545
59 Tip How to Use DBMS_STATS to Move Statistics to a Different Database 고구마 2010.04.09 17064
58 Tip 10G FGA AUDIT 1 고구마 2010.04.09 23607
57 Tip EM 재구성 고구마 2010.04.09 26261
Board Pagination Prev 1 2 3 4 Next
/ 4