문서의 선택한 두 판 사이의 차이를 보여줍니다.
양쪽 이전 판 이전 판 다음 판 | 이전 판 | ||
study:oracle:adv_owi_10g:oracle_internal_owi [2009/07/30 00:09] deathguy |
study:oracle:adv_owi_10g:oracle_internal_owi [2009/08/12 19:16] deathguy 삭제 |
||
---|---|---|---|
줄 2: | 줄 2: | ||
- 오라클은 물리적인 I/O를 최소화 하기 위해 최근에 사용된 블럭에 대한 정보를 메모리의 일정 부분에 보관하려 한다 => 이 영역을 Buffer Cache 라고함. | - 오라클은 물리적인 I/O를 최소화 하기 위해 최근에 사용된 블럭에 대한 정보를 메모리의 일정 부분에 보관하려 한다 => 이 영역을 Buffer Cache 라고함. | ||
- | |||
===== Buffer Cache 구조 ===== | ===== Buffer Cache 구조 ===== | ||
{{: | {{: | ||
줄 12: | 줄 11: | ||
- 특정 블럭에 대한 Scan을 할려고 하면 Cache buffer chains latch를 획득 해야만 한다. \\ **※ 9i부터 읽기 작업에 한하여 buffer cache chains latch를 shared 모드로 획득 한다** | - 특정 블럭에 대한 Scan을 할려고 하면 Cache buffer chains latch를 획득 해야만 한다. \\ **※ 9i부터 읽기 작업에 한하여 buffer cache chains latch를 shared 모드로 획득 한다** | ||
- 다음과 같은 쿼리를 이용하여 cache buffer chains latch의 갯수를 확인가능 하다 \\ <code sql> | - 다음과 같은 쿼리를 이용하여 cache buffer chains latch의 갯수를 확인가능 하다 \\ <code sql> | ||
- | select count(*) from v$latch_children where name = 'cache buffers chains' | + | SQL> |
+ | |||
+ | COUNT(*) | ||
+ | ---------- | ||
+ | 65536 | ||
</ | </ | ||
+ | * **cache buffer chains latch** => hash 함수로 얻은 값으로 해당 데이터가 어떠한 bucket에 있는가를 확인할때 발생되는 latch | ||
+ | {{: | ||
==== Working Set ==== | ==== Working Set ==== | ||
줄 31: | 줄 36: | ||
* Working Set 개수는 Cache buffer lru latch 개수에 의해 결정( 하나의 working set을 하나의 lru latch가 관리함 )되며 X$KCBWDS( Kerner Cache Buffer Working sets Descriptors )를 조회 하면 확인 가능 하다 | * Working Set 개수는 Cache buffer lru latch 개수에 의해 결정( 하나의 working set을 하나의 lru latch가 관리함 )되며 X$KCBWDS( Kerner Cache Buffer Working sets Descriptors )를 조회 하면 확인 가능 하다 | ||
* LRU , LRUW List를 탐색 하고자 하는 프로세스는 반드시 cache buffer lru chain latch를 획득 해야 함. | * LRU , LRUW List를 탐색 하고자 하는 프로세스는 반드시 cache buffer lru chain latch를 획득 해야 함. | ||
+ | * **cache buffer chains lru latch** | ||
줄 40: | 줄 46: | ||
- 만약 Single블럭 I/O에 의해 읽혀진 블럭은 Mid-Point에 삽입되며 Touch Count는 1 이다. | - 만약 Single블럭 I/O에 의해 읽혀진 블럭은 Mid-Point에 삽입되며 Touch Count는 1 이다. | ||
- Full table scan 이나 인덱스 Full Scan으로 읽혀진 데이터 들은 Mid-Point에 삽입되었다 바로 Cold 영역의 꼬리로 옮겨져서 버퍼 캐쉬에 머무를 확률이 작아 진다. | - Full table scan 이나 인덱스 Full Scan으로 읽혀진 데이터 들은 Mid-Point에 삽입되었다 바로 Cold 영역의 꼬리로 옮겨져서 버퍼 캐쉬에 머무를 확률이 작아 진다. | ||
+ | |||
+ | |||
+ | ==== Buffer lock ==== | ||
+ | * buffer 자체 보호 . 즉 , 버퍼의 내용을 변경하거나 읽으려고 하는 프로세스는 변경 작업이나 읽기 작업을 완료할때 까지 해당 버퍼 (정확하게 말하면 Buffer header)에 대해서 buffer lock을 exclusive 또는 shared 하게획득 해야 한다. | ||
줄 56: | 줄 66: | ||
- 기록된 블럭은 LRU 보조 리스트로 옮겨짐 | - 기록된 블럭은 LRU 보조 리스트로 옮겨짐 | ||
- free block를 찾으면 buffer lock을 exclusive하게 획득 후 데이터 파일로 부터 block를 load | - free block를 찾으면 buffer lock을 exclusive하게 획득 후 데이터 파일로 부터 block를 load | ||
+ | |||
+ | ===== Buffer Cache Dump ===== | ||
+ | - 버퍼의 구조를 가장 명확하게 알 수 있는 방법은 버퍼 캐시 덤프를 이용하는것 \\ <code sql> | ||
+ | SQL> alter session set evnets ' | ||
+ | OR | ||
+ | SQL> oradebug dump buffers 1 | ||
+ | </ | ||
+ | * 참고로 oradebug 를 추천한다 \\ | ||
+ | - X$BH 뷰에서 확인가능하다 | ||
+ | * 눈여겨 봐야될 컬럼은 다음과 같다 | ||
+ | |||
+ | ^ 컬럼 ^ 내용 ^ | ||
+ | ^ HLADDR | 해당 버퍼를 관장하는 래치의 주소 V$LATCH_CHILDREN.ADDR 과 조인해서 원하는 래치정보를 얻을수 있다 | | ||
+ | ^ TS# | 블록이 속한 테이블스페이스 번호 V$TABLESPACE.TS# | ||
+ | ^ DBARFIL | DBA 중 파일번호 | | ||
+ | ^ DBABLK | DBA 중 블록번호 | | ||
+ | ^ CLASS | 블록 클래스 | | ||
+ | ^ STATE | 버퍼의 상태 | | ||
+ | ^ 0 | FREE no valid block image | | ||
+ | ^ 1 | XCUR a current mode block, exclusive to this instance | | ||
+ | ^ 2 | SCUR a current mode block, shared with other instances(RAC환경에서만 쓰임) | | ||
+ | ^ 3 | CR a consistent read (stale) block image | | ||
+ | ^ 4 | READ buffer is reserved for a block being read from disk | | ||
+ | ^ 5 | MREC a block in media recovery mode | | ||
+ | ^ 6 | IREC a block in instance (crash) recovery mode | | ||
+ | ^ 8 | PI past image(RAC환경에서만 쓰임) | | ||
+ | ^ TCH | Touch Count | | ||
+ |