1. 터치 카운트 소개
오라클은 볼륨의 증가, 성능상의 요구 및 최근 시스템들의 복잡성 등의 이유로 Touch- Count 에 근간한 Data Buffer Management Algorithm을 제시하였다. 데이터 블록 버퍼들은 Modified LRU 알고리즘을 사용하여 더 이상 관리되지 않는다. Touch-Count 알고리즘은 오라클 8i부터 소개되었는데 Latch Contention을 줄이고 버퍼 성능의 최적화를 위한 기회를 증가시키기 위해서이다.
2. 터치 카운트 나온 이유
오라클 데이터 블록 버퍼 캐시의 크기가 급격하게 증가하였다. 데이터 블록 캐시 크기가 1 Giga 바이트 이상되는 사이트들도 많이 보았다. 이 정도의 캐시 크기는 권고하지 않지만 이는 사람들의 전체 데이터베이스상에서의 캐시에 대한 요구가 어떻게 변화하였는지를 보여주고 있다. 그러나 문제점들이 존재하고 있다. 오라클의 데이터 블록 버퍼 알고리즘은 중요한 Physical I/O에 대한 예측을 기반으로 설계되고 만들어 졌다. 데이터 블록 버퍼 크기를 매우 크게 하여 테스트를 해본 DBA라면 이러한 경우에 성능이 저하되는 것을 경험하였을 것이다.
성능이 저하되는 것은 당연한 것이다. 그러면 왜 그런 것일 까?
오라클은 I/O를 위하여 디자인되었기 때문에 Buffer Cache Nature Shift가 발생할 경우 다른 알고리즘이 반드시 사용되어야 한다. 단순하게 매우 큰 버퍼 캐시를 관리할 수 있는 것만으로는 충분하지가 않다. 사실상 버퍼 캐시 크기가 큰 경우 성능을 유지하는 것이란 쉽지 않다. 따라서 경쟁력을 유지하기 위해서 오라클 시스템은 대규모의 캐시를 지원할 뿐 아니라 주요한 성능상의 잇점을 제공해야 한다. 다시 말해서 새로운 알고리즘이 요구되는 것이다. 보다 큰 캐시와 증가된 성능상의 요구에 더하여 오라클은 이의 마케팅과 테크니컬 포지션을 분산 데이터베이스에서 강력한 중앙 집중형 데이터베이스로 전환하고 있다. 이러한 변화 들은 제어에 대한 요구를 증가시켰으며 오라클은 단일 데이터베이스 시스템을 보다 작은 서브 데이터베이스로 분할하는 방법을 DBA들에게 제공하고 있다. 오라클의 Touch-Count 구현은 상당히 최적화되었으며 따라서 다이나믹하고 매우 큰 캐시내에서 버퍼 캐시를 관리하기 위해 필요한 제어를 제공할 것이다.대규모의 캐시,성능상 요구의 증가와 제어를 함께 놓고 보았을 때 오라클이 새로운 데이터 블록 버퍼 캐시 알고리즘을 선택한 것이 탁월하다고 만은 할 수 없다.
오라클이 수년간에 걸쳐 데이터 블록 버퍼 알고리즘을 변경하여 왔다는 것이다.
3. 버퍼 캐쉬 관리의 역사
오라클은 데이터 블록 버퍼 알고리즘을 수정해왔다. 이의 중심에는 LRU(Least Recently Used List)가 있다. LRU는 단순히 캐싱된 데이터 블록에 대한 포인터들의 리스트이다. 일반적으로 이들 리스트의 앞쪽은 자주 쓰이는 블록들이 다른 편의 끝쪽에는 자주 쓰이지 않는 블록들이 존재한다. LRU 체인의 자주 쓰이는 끝쪽을 MRU(Most Recently Used) 리스트의끝이라고 부른다. LRU 체인의 자주 쓰이지 않는 끝쪽을 LRU의 끝이라고 부른다. 종종 LRU 체인의 LRU 끝에 대하여 혼동하는 경우가 있으나 이러한 Naming Convention에 상관없이 일반적인 아이디어는 Physcial I/O를 최적화하기 위하여 자주 사용되는 블록을 캐싱하여 버퍼 캐시내에 유지하는 것이다. 초기에 오라클은 표준 LRU 알고리즘이라고 불리는 것을 만들었다. 버퍼가 캐시로 옮겨지 거나 캐시내에서 다시 액세스될 때 마다 버퍼의 포인터는 LRU 체인의 MRU end로 이동된다
(기억할 것은 블록은 절대로 물리적으로 이동되지 않으며 단지 물리적인 메모리 블록에 대한 포인터만 이동하는 것임).
여기서 생각해 보아야 할 것은 자주 쓰이지 않는 블록은 자연적으로 LRU 리스트의 LRU end로 이동되며 아마도 이들의 내용은 더 자주 쓰이는 블록 들로 채워져 있을 것이다.Full Table 스캔은 Cache Killer와 같은데 모든 테이블 블록이 버퍼에 놓여지게 된다. 만약 버퍼 캐시가 500 Block이고 테이블이 600 Block을 포함하고 있다면 모든 자주 쓰이는 블록들은 이 Full-Table 스캔된 테이블의 블록들로 교체될 것이다. 이는 과도한 컴퓨터 시스템의 사용과 기본적으로 잘 구성되어진 캐시를 파괴하는 현상을 초래하기 때문에 데이터베이스 성능 저하의 주요한 요인으로 작용한다. 이러한 요소들을 제거하기 위해서 그 유명한 Modified Least Recently Used(LRU) 알고리즘이 구현되었다.
오라클이 수년동안 이 알고리즘을 변경하는 동안에도 기본적은 오퍼레이션들은 동일하게 유지되었다. Modified LRU 알고리즘은 Full-Table 스캔된 블록들을 읽어서 LRU 체인의LRU end에 올려 놓으며 이들 블록중에서 제한된 수의 블록만이 동시에 캐시내에 존재하도록 허용한다. 이것은 Full-table 스캔이 전체 버퍼 캐시를 플러싱(Flush)하는 것을 방지하기 위해서이다. 이것이 마치 모든 버퍼 캐시 문제를 해결한 것처럼 보일지 모르지만 다시 생각해 보아야 할 것들이 있다.
Large Index Range 스캔은 어떻게 할 것인가? 수백개의 인덱스 리프 블록들이 버퍼 캐시내로 유입되는 상황을 상상해 보자.
수정된 LRU 알고리즘은 오직 Full-Table 스캔 이슈만을 고려하였으며 Index Block에 대한 것은 아니다. 일시적인 솔루션과 경쟁력을 유지하기 위하여 오라클은 Multiple Buffer Pool을 고안하였다. 대부분의 DBA들은 Multiple Buffer Pool을 사용하지 않으며 Touch-Count 알고리즘은 이를 매력적이지 않게 하였으며 이들은 상당히 정교하게 사용될 때에만 매우 효과적일 수 있다. Keep Pool은 작은 오브젝트들을 위해 고안되었는데 어플리케이션의 응답 시간 이슈를 고려할 때 항상 캐시해 놓아야 한다. Recycle Pool은 일반적이며 정상적인 버퍼 캐시 오퍼레이션에 영향을 주는 큰 오브젝트들을 위해 고안되었다.
마지막으로 Default Pool은 그 외 모든 경우를 위해 고안되었다. 일반적이며 효과적인 버퍼 캐시 오퍼레이션을 유지하기 위하여 매우 빠른 알고리즘이 반드시 필요하며 이는 핵심적으로 모든 버퍼가 버퍼 캐시내에 이들의 자리를 확보하고 또한 버퍼 캐시내에 머무를 수 있도록 하는 것이다.
Touch-count 알고리즘은 각각의 그리고 모든 블록들이 버퍼 캐시에 공간을 할당 받게 할 뿐 아니라 버퍼 캐시내에 머무를 수 있도록 한다.
비록 인스턴스 파라메터와 관련된 Default Touch-count는 블록이 단순하게 버퍼 캐시 내에 유지되는 것을 어렵게 한다. 버퍼 캐시내에 유지되기 위해서는 상당히 많은 장애들이 존재한다.
4. 터치 카운트 버퍼 관리 방법
Touch-Count Based 알고리즘(Count Frequency Scheme라고도 불림)은 Simple LRU 알고리즘보다 복잡하다. 따라서 여기에는 Touch-Count 알고리즘 사용시 비용상에서 그리고 이전 LRU 알고리즘과 비교할 때, 보다 향상된 성능을 제공하는 등과 같은 잇점들에 앞서 무엇인가 Motivating Factor들이 존재해야 할것이다. 이미 이러한 Motivating Factor들에 대해서는 언급하였는데 즉, Bigger Cache, 성능상의 요구 사항들, 증가된 제어, Full-table Scan 억세스, Index 억세스이다. 이러한 요소들은 캐시 환경을 매우 격렬하고 긴장 되게 만든다. Touch-count Based 알고리즘의 핵심은 각 버퍼가 캐시내에 유지되게 하는 것 뿐만이 아니라 LRU 리스트의 MRU end에 계속 놓여지도록 하는 것이다. 일반적인 Touch-count 알고리즘은 이를 위하여 각 버퍼에 Counter를 할당한다. 블록이 Touch될 때 마다 이의 Counter가 증가된다. 이 Touch Counter의 값은 각 버퍼링된 블록에 Value 혹은 Polularity를 부여하기 위해 사용된다. 이 Touch Count는 버퍼 캐시 활동 중에 Reference되며 Manipulate될 것이다. Reference와 Manipulation 특성들은 Touch-Count 알고리즘 구현의 특성이다.
4.1. Oracle’s Touch-Count Implementation
오라클은 버퍼가 캐시내에 유지되는 것을 매우 어렵게 만드는 일부 성가신 작업들을 수행한다. 오직 선택된 소수만이 LRU 체인의 MRU end에 남아 있을 수 있다.
4.1.1. MIDPOINT INSERTION
LRU는 두개의 기본적인 영역, Hot Region과 Cold Region으로 나뉘어 진다. Hot Region내에 있는 모든 버퍼들은 Hot Buffer라고 불리며 Cold Region내 모든 버퍼들은 Cold Buffer라고 불린다. Hot Region과 Cold Region사이에는 Midpoint Marker가 있으며 이 Midpoint 포인터는 적당한 수의 버퍼가 Hot Region과 Cold Region에 존재하도록 이동한다. 즉, Midpoint 포인터는 특정 블록과 관계된 것이 아니다.
디폴트로 오라클은 LRU를 균등하게 분할한다. 즉, Hot Region과 Cold Region은 버퍼내에서 각각 50%를 차지한다. 이것은 _db_percent_hot_default 파라메터에 의해서 제어된다.이 파라메터를 증가시키면 Hot Region내 버퍼의 백분율이 증가될 것이며 즉 midpoint를 넘어서게 된다.
서버 프로세스가 디스크에서 블록을 읽어서 버퍼 캐시에 올려 놓을 때 LRU 체인의 중간,즉 Hot과 Cold Region의 사이에 올려 놓는다.
이것은 Midpoint Insertion이라고 알려져 있으며 오라클 Touch-Count 알고리즘 구현의 기본적인 개념이다. 실제적으로 버퍼는 Hot Region내로 위치된다.
4.1.2. TOUCH COUNT INCREMENTATION
개념적으로 버퍼가 Touch될 때 마다 어떤 이유에서든 Touch Count는 증가된다. 버퍼의 Life상에는 서버 프로세스의 강력한 관심속에 있다가 매우 빠르게 이의 관심으로부터 멀어지는 시기가 있다. 이러한 문제점을 감소시키기 위하여 오라클은 오직 버퍼의 Touch Count가 디폴트로 기껏해야 3초마다 한번씩만 증가되도록 허용한다. 이것은 버퍼의 TouchCount가 3초내에서 한번만 증가될 수 있다는 것을 의미하는 것은 아니다. 만약 Time Sequence를 그래프로 나타낸다면 Touch Count가 3초내에서 두번 증가되는 것을 볼 수 있을 것이다. 이 “three second period”는 _db_aging_touch_time 파라메터로서 조정 가능하다. Touch Count 증가의 또 다른 주요한 측면은 버퍼가 이동하지 않는 다는 것이다. 즉, 이의 포인터가 이동하지 않는 것이다. Touch Count 증가와 버퍼 포인터의 이동은 서로 독립적이다. 버퍼 포인터 이동은 아래에서 설명할 것이다. Latch는 특정 액션을 수행하기 위하여 반드시 소유해야 할 Token과 같은 것이다. 그러나 오라클은 Latch가 없이 Buffer의 Touch Count를 업데이트 한다. 즉, 버퍼는 Touch Count가 증가되는 동안에 관리될 것이다. 이러한 경우에 발생 가능한 최악의 경우는 Touch Count가 실제로 증가되지 않으며 Cache Corruption도 발생하지 않는 것이다.
4.1.3. BUFFER MOVEMENT
버퍼가 버퍼 캐시로 올려지면 Midpoint 앞에 놓여지면 Hot Region에 올려지는 것이다. LRU 알고리즘과 다르게 오라클의 Touch-Count 알고리즘은 버퍼를 이동시키지 않는데 이는 버퍼가 Touch되기 때문이다. 즉, 이 Touch Count는 아마도 증가는 되지만 버퍼는 이동되지 않을 것이다. 서버 프로세스가 물리적인 오라클 블록을 버퍼 캐시로올려놓기 위해서 Free Buffer를 찾을 때 이는 가장 먼저 Free 버퍼를 찾을 것이다. Free 버퍼는 단순히 버퍼이며 이의 컨텐츠는 디스크상의 카피본과 일치한다. 즉, 여기에는 차이(Difference)가 없다. 만약 상이하다면 해당 블록은 Dirty로 태그된다. 서버 프로세스가 Free 버퍼를 찾거나 DBWR가 Dirty 블록을 찾을 때, 그리고 만약 블록의Touch Count가 2이상될 경우 블록은 LRU 체인의 MRU end로 이동된다. Block Movement Threshold(디폴트 2) 값은 _db_aging_hot_criteria 파라메터로 제어 가능하다. 버퍼가 LRU 체인의 MRU end로 이동되면 이의 Touch count는 0로 셋팅된다(여러 테스트에 의하면 버퍼가 LRU 체인의 MRU end로 이동될 될 때 이의
Touch Count는 _db_aging_stay_count(default 0) > = _db_aging_hot_criteria(default 2)가 아니라면 0로 리셋된다.
_db_aging_stay_count > = _db_aging_hot_criteria 라면 현재 Touch Count를 2로 나눈 것으로 셋팅된다).
이 새롭게 Touch Count가 0으로 셋팅된 Popular 버퍼는 나중에 Touch Count가 증가되거나 디스크 로 Page Out될 것이다.
4.1.4. HOT TO COLD MOVEMENT
버퍼가 Cold Region에서 Hot Region으로(LRU 체인의 MRU end로) 이동되면 Midpoint Marker는 1 position 이동할 것이다. 이것이 발생할 때 또한 별다른 Fault가 없을 경우 버퍼는 Hot Region에서 Cold Region으로의 Threshold를 Cross over하도록 할 것이다. 버퍼의 Touch Count가 250일지라도 만약 Threshold를 Cross하면 Touch Count는 1로 셋팅될 것이다. Threshold Crossing Touch Count Reset값은 _db_aging_cool_count 파라 메터로 제어된다.
5. 터치 카운트 성능 튜닝
Performance Tuning은 몇 개의 기본적인 단계들로 구성된다. 먼저 시스템을 모니터링 해야 하며 다음으로 Contention이나 문제가 존재한다면 이를 판별해 내야 할 것이다. 다음으로 분석이 이루어져야 하며 마지막으로 해결 방안이 마련되어야 한다. 오라클의 버퍼 캐시 모니터링 방법과 Touch-count 알고리즘 기반에서 적절한 파라메터를 통하여 제어를 최적화하는 방법들이다.
5.1. Touch-count Performance Monitoring
오라클 버퍼 캐시의 성능을 모니터링하는 것은 알고리즘에 독립적이다. 그러나 버퍼 캐시와 관련된 문제가 확인되었다면 해결할 방법은 알고리즘에 따라 다르게 될 것이다. 버퍼 캐시
의 문제점이나 이로 인한 오라클 서버 기반 성능 문제점을 정확하게 판별해 낼 수 있는 가장 좋은 방법은 Response Time과 이의 컴포넌트들을 모니터링하는 것이다.Response Time 분석은 Service Time과 Queue Time을 모두 고려해야 한다. Service Time은 데이터베이스 오파레이션(예: Buffer Cache Management)동안 CPU가 사용한 시간이며 Queue Time은 CPU가 프로세싱을 계속하기 위하여 무엇인가(예:latcing)를 기다린시간이다. Ratio Based Analysis는 Service Time이나 Queue Time을 고려하지 않으며 오라클 시스템의 활동성에 포커스를 맞춘다. Session Wait Analysis는 Queue Time과 이의 컴포넌트를 판별해내나 Service Time은 고려되지 않는다. 이것은 때때로 문제를 해결함에 있어 그릇된 방향으로 이끌게 할 수 있다. Response Time Analysis는 Service Time과 Queue Time을 모두 고려하기 때문에 실제적인 문제가 어디에 있는 지를 정확하게 분석해 낼 수 있다. Queue Time의 컴포넌트들이 판별되고 카테고리화되면 성능상의 Bottleneck이 정확하게 판별된다. 만약 버퍼 캐시가 주요한 문제 요인이라면 Queue Time이 Service Time보다 높을 것이 고 다음의 오라클 Wait Event중 하나가 Queue Time의 대부분을 소모할 것이다.
버퍼 캐시와 관련된 Wait Event들로는 LRU chain latch, free buffer wait, cache buffer chains latch, buffer busy wait, db file sequential read(index based physical reads), db file scattered read(full-table scan based physical reads)가 있다. 버퍼 캐시 Contention이 발견되고 Touch-count 알고리즘이 사용되었다면 성능을 향상시키기 위한 가능한 일 들로 Touch-count와 관련된 파라메터를 조절하는 것이다.
5.2. Classic Buffer Cache Performance Tuning
Touch-count 관련된 파라메터의 조절은 버퍼 캐시 성능 이슈를 해결 하는데에 효과적이며 모니터링을 통해 판별된 Wait Event들은 아마도 최고의 솔루션을 제공할 것이다. 아래에 버퍼 캐시와 관련된 주요한 Wait Event에 대한 간략한 리스트가 있다. 이 리스트는 이들 wait event가 무엇인가 보다 어떻게 해결해야 하는 가에 대한 내용이다.
LRU chain latch wait Touch된 cache block의 수와 LRU chain lath를 요청하는 프로세스 수를 감소시키고 LRU latch 수를 증가시킨다. 또한 Latch Hold Duration을 줄이고
CPU를 증설하고 보다 빠른 CPU를 사용하도록 한다.
Free buffer wait I/O Subsystem Throughput capacity를 증가시키고 어플리케이션이보다 작은 량의 dirty block을 발생시키도록 수정한다. DBWR에게 보다 많은 파워를 부여 하고
데이터 블록 버퍼 수를 증가하도록 한다.
Buffer busy wait 동일한 버퍼가 busy하거나 busy한 버퍼가 많은지를 판별하도록 한다. 만약 동일한 버퍼가 busy하다면 어플리케이션을 수정하고 블록의 Popularity를
줄이도록 한다. 만약 많은 버퍼들이 busy하다면 I/O subsystem throughput capacity를 증가시키거나 busy buffer 수를 줄이도록 한다.
Cache buffer chains latch wait 버퍼 캐시내에 동일 블록에 대한 많은 카피본이 존재하는 지를 판별한다. 만일 많은 카피본이 존재한다면 어플리케이션을 수정하거나
블록의 popularity를 감소시킨다. 그렇지 않다면 블록 버퍼와 hash bucket 수를 증가시키고 보다 빠른 CPU를 사용하도록 한다.
Db file sequential or scattered read waits 어플리케이션내 Physical I/O를 줄이도록 수정하고 I/O subsystem throughput capacity를 증가시킨다.
5.3. 터치 카운트 변수 튜닝 방법
믿을 만한 경험치가 없을 경우에는 적절하고 신빙성 있는 테스트를 수행되어야 한다. 이 장에서는 먼저 관련된 Touch count 파라메터들에 대해서 나열하여 간략하게 설명하겠다.
5.3.1. Touch-Count Instance Parameters
5개의 Touch-count 관련된 파라메터들이 있으며 이들을 사용하여 잇점을 얻을 수 있다.
_db_percent_hot_default Hot Region내 Block Buffer의 Percentage (디폴트 50 %)
_db_aging_touch_time 버퍼의 Touch Count 증가 Time Window(디폴트 3초)
_db_aging_hot_creiteria 버퍼가 LRU 체인의 MRU end로 이동될 Threshold (디폴트 2 touch count)
_db_aging_stay_count 버퍼가 LRU 체인의 MRU end로 이동될 때의 Touch Count 리셋값(디폴트 0 touch count)
_db_aging_cool_count 블록이 Hot Region에서 Cold Region으로 이동될 때의 다시 부여될 Touch Count 값(디폴트 1 touch count)
5.3.2. Research Setup
대부분의 인스턴스 파라메터로 인한 일반적인 영향성들은 대부분의 경우에 예측 가능하지만 Touch Count 파라메터의 변경은 그리 쉬운 일이 아니다. 일부 잘못된 생각과 개인적인 견해들을 제거하기 위하여 일련의 정밀한 테스트를 수행하였으며 여기에서 그것에 대하여 간략하게 설명하겠다.테스트는 데이터베이스 시스템에 4 가지 타입의 스트레스를 부여하기 위하여 셋팅하였다.4가지 타입의 스트레스는 cache buffer chain latch contention, LRU latch contention,free buffer wait contention, full table scan and index physical read wait contention이었다. 각 유형별 스트레스를 부여하기 위하여 특정 스크립트를 수행하였으며 다양한 파라메터를 의도적으로 셋팅할 수 있었다. 그러나 LRU 알고리즘이 현재 잘 작동되고 있는지를 알아낼 수 있는 LRU latch contention은 의도해낼 수가 없었다.Latch wait를 위해서 “latch impact”라고 불리는 것을 기록하였다. Latch Impact는 v$latch에 근간한 간단한 계산으로서 sleep*(sleeps/decode(gets,0,1,gets))와 같은 것이다. Touch-count 파메터가 latch의 활동에 영향을 주는 지의 여부를 판별하기 위하여 latch impact를 기록하였다. Non-latching waits-free buffer waits, physical read watis from a full table or index scan-을 위하여 실제 wait time을 기록하였다. 각각의 스트레스와 인스턴스 파라메터 수정에 앞서 데이터베이스 시스템을 Recycle하였다. 그리고 나서 시스템에 스트레스를 주기 시작하였으며 이는 60초의 warm-up period로 진행되었다. 1분 간격으로 13번 수행하고 나서 오라클과 시스템 통계 정보를 수집하였다. 수집된 통계정보를 바탕으로 하여 touch-count 파라메터가 시스템에 주는 영향성에 대하여 검증할 수 있었다.
5.3.3. Research and Thought Analysis
첫째로 그리고 무엇보다 중요한 것은 만약 Response Time 분석 내용중 queue time 문제에서 buffer cache contention이 주요하지 않다면 touch count 파라메터에 대한 고려는큰 의미가 없다. 그렇지 않은 경우 touch count 파라메터는 주요한 값을 가질 수 있게 된다. 수행했던 각 테스트의 통계 정보를 제시할 것이다. 다음 아래에서 5개의 주요한 touch-count 인스턴스 파라메터의 수정에 관한 견해를 나열하였다. 내가 희망하는 바는 이것이 여러분들의 특수한 시스템 분석 환경상에서 어떠한 방향과 촉매제로서의 역할을 하고자 하는 것이다. 다시 한번 우리의 목적을 상기하자면 버퍼의 이동을 최소화하고 Most Popular Block이 캐싱을 유지하는 것이다.
_db_percent_hot_default 테스트 데이터에 의하면 latch activity(cache buffer chains latch and LRU latch)와 free buffer wait time은 해당 파라메터를 수정함으로써 크게 영향을 받는 것으로 나타났다. 테스트 데이터에 근간하면 최적의 셋팅값은 Contention에 따라 다른 것으로 나타나고 있다. 데이터는 버퍼 캐시의 75% 혹은 그 이상을 Hot Region으로 잡았을 경우 성능에 해로운 것으로 나타나고 있다. 해당 파라메터의 변경이 scattered read waits(physical FTS read waits)에 통계적으로 주요한 영향을 주지않는 것은 흥미로운 일이다. 만약 보다 많은 블록을 Hot 영역으로 잡을 것을 고려하고 있다면 해당 파라메터를 증가시키도록 하며 반대로 Cold 영역으로 보다 많은 블록을 옮기고 싶다면 해당 파라메터를 감소시키도록 한다.
_db_aging_touch_time 블록의 이동이나 Popular 블록의 활발한 활동이 급격하다면 해당 파라메터를 증가시킴으로써 Movement Threshold에 도달하는 것을 감소시킬 수 있으며 따라서 버퍼의 이동을 감소시킬 수 있다. 심각한 cache buffer lru chains latch나 LRU latch contention은 블록의 이동이 과다함을 나타내는 것으로 해당 파라메터를 증가시킴으로써 갑작스런 성능 저하와 버퍼의 이동을 감소시킬 수 있다. 그러나 반드시 주의를 요해야 한다. 해당 파라메터 값을 너무 크게 잡으면 Popular Block의 Devaluing 현상이 나타난다.
_db_aging_hot_creiteria 블록의 이동 현상을 늦추고 싶다면 해당 파라메터의 값을 증가시키도록 한다. 블록의 이동 현상을 늦추어야 필요성이 있다는 것은 cache buffer chains latch나 LRU latch contention이 심각하게 발견되고 있다는 것이다. 버퍼가 이동되는 것(to the MRU end of the list)을 어렵게 만들고 싶다면 해당 파라메터 값을 증가시키도록 한다. 값을 증가시킬 경우 진정한 Popular Block들만이 캐시내에 유지될 수 있도록 할 수 있을 것이다.
_db_aging_stay_count Popular Block이 매우 빈번하게 캐시에서 밀려날 경우 (buffer cache hit ratio가 낮을 것임) 해당 파라메터를 증가시킴으로써 Polular Block이 캐시 내에 보다오래 머무를 수 있도록 할 것이다. 그러나 해당 파라메터 값을 지나치게 증가 시킬 경우 nearly-Popular Block들이 초기에 실제로는 많이 억세스가 되지 않았음에도 높은 Touch-count를 얻게되는 현상이 발생할 수도 있다. 즉, 본질적으로 High Touch-count 의 의미와 값을 감소시키게 하는 것이다.
_db_aging_cool_count 해당 파라메터 값을 증가시킴으로써 블록들이 캐시내에 머무르는 것을 보다 쉽게 할 수 있으며 Cooling Affect가 보다 천천히 그리고 급격하지 않게 나타나지 않도록 하여 준다. 만약 Popular Block이 캐시에서 빨리 밀려난다면(buffer cache hit ratio가 낮을 것임) 해당 파라메터 값을 증가시킴으로써 이 블록들이 캐시내에 보다 오래 머무를 수 있도록 하여 줄 것이다. 그러나 너무 높게 잡으며 Unpopular Block들도 캐시에 머무르게 하여 cache buffer chains latch나 LRU latch contention이 과하게 발생될 것이다.
위 도표는 테스트 결과이다. 데이터들은 보다 정확한 통계 정보를 얻기 위하여 매초당 13 번 수행하였다. 결과에 따르면 _db_percent_hot_default 파라메터값의 변경은 latch와 free buffer wait의 활동에 상당한 영향을 주는 것으로 나타나고 있다(90% confidence level). 그러나 scattered read wait 활동에는 큰 영향을 주지 못하는 것으로 나타나고 있다. “latch impact” 값은 Latch contention 활동에 대한 단순한 계산이다.
6. Concluding Thoughts
위 테스트 결과에 근간하여 세가지 주요한 포인트들을 도출해 보았다.
1. 오라클은 변화에 순응하기 위하여 이들의 내부 알고리즘을 지속적으로 변경하였다.
2. Touch-count 인스턴스 파라메터의 조절은 Buffer Cache의 활동가 성능 등에 주요한 영향을 줄 수 있다.
3. 보다 정밀하고 포괄적인 연구가 수행될 필요성이 있다.
Oracle의 Buffer Cache Management 알고리즘 관련 자료.
8i 이전까지 Oracle의 Buffer Cache Management 알고리즘은 LRU에 근간하였으나 시스템의 트랜잭션과 데이터량이 현격하게 증가하는 현상 속에서 데이터베이스의 Buffer Cache의 크기도1G 이상되는 것이 일반 화되어 가고 있다. 이러한 환경속에서 대량의 데이터를 보다 효율적으로 관리하기 위한 Buffer Cache의 알고리즘상의 변화가 필요로 하게 되었다. 8i부터 구현된 Touch-count 알고리즘은 Buffer Cache 사이즈가 증가하면서 발생하는 성능상의 문제등을 해결하기 위하여 새롭게 제시된 것 이다. 본 문서는 이 Touch-Count 알고리즘의 히스토리, 설명 및 구현 방법, 튜닝 포인트등에 대하여 설명하고 있다.
출처:Touch_Count_Algorithm