[오라클]1-2단계 버퍼캐쉬 영역

1-2 단계 : 버퍼캐쉬 영역

		데이터 버퍼 캐시 영역의 튜닝 분석   "SQL문의 처리과정"을 통해 알아보았듯이 데이터 파일로부터 읽혀진 데이터가 저장되는 메모리 영역을 데이터버퍼 캐시영역이라고 하며 이 영역의 크기는 INIT<DB명>.ORA 파일에 정의되는 DB_CACHE_SIZE 파라메터에 의해 결정됩니다. 예를 들어, 윈도우 시스템에서 어떤 텍스트 파일의 내용을 편집하기 위해 더블-클릭을 하면 잠시 후 편집기 프로그램이 실행되고 파일의 내용이 화면에 출력됩니다. 이와 같이 실행되는 과정을 살펴보면 선택된 파일은 디스크로부터 읽혀지고 시스템의 메모리 버퍼영역에 로더된 다음 편집기를 통해 사용자의 화면에 출력되는 것 입니다. 만약, DB_CACHE_SIZE 파라메터의 값이 10MB일 때 읽혀지는 테이블의 크기는 20MB이라면 어떻게 될까요 ? 읽혀지는 테이블이 메모리 크기보다 크기 때문에 한번에 테이블 데이터 모두를 메모리에 저장하지 못하고 2번에 나누어서 저장해야 할 것입니다. 그렇다면, DB_CACHE_SZIE가 20MB이라면 어떻게 될까요 ? 당연히 읽혀진 테이블 데이터 20MB를 한번에 데이터버터 캐시영역에 저장하게 될 것입니다. 2번 이상, 여러 번 나누어서 데이터를 처리하는 것보다는 한번에 데이터를 처리하는 것이 좋은 성능을 기대할 수 있는 방법이 될 것입니다. 결론적으로, 데이터버퍼 캐시영역의 크기는 처리하려는 테이블 데이터를 충분히 로더할 수 있을 만큼 설정되어 있는 경우와 그렇지 못한 경우에 의해 성능차이가 발생할 수 있다는 것입니다.   데이터 버퍼 캐시 영역의 튜닝 방법           데이터 버퍼 캐시 영역을 보다 크게 할당한다.     그럼, 데이터버퍼 캐시영역에 대한 성능을 향상시킬 수 있는 첫 번째 방법을 알아 보겠습니다. 사용자가 질의한 데이터를 데이터버퍼 캐시영역에 로더하려면 충분한 메모리 공간이 필요합니다. 공간이 부족하면 한번에 데이터를 로더하지 못하고 여러 번 나누어서 로더해야 하기 때문에 성능이 저하될 수 있습니다. 다음은 자료사전을 통해 데이터 버퍼 캐시영역의 튜닝 상태를 분석하는 방법입니다. V$SYSSTAT 자료사전을 참조하면 이 영역에 대한 튜닝 여부를 확인할 수 있습니다.         $ sqlplus scott/tiger SQL> select * from big_dept; SQL> select * from big_emp; SQL> connect system/manager SQL> select 1 - ((phy.value)/(cur.value + con.value)) "CACHE HIT RATIO" from v$sysstat cur, v$sysstat con, v$sysstat phy where cur.name = 'db block gets' and con.name = 'consistent gets' and phy.name = 'physical reads';   CACHE HIT RATIO ----------------- .973257182   "PHYSICAL READS"는 사용자가 SQL문을 실행했을 때 데이터 파일로부터 테이블을 읽은 블록 수를 의미하며 "DB BLOCK GETS"는 DML문의 처리과정에서 처럼 데이터버퍼 캐시영역에 있는 변경 후 데이터를 참조할 때 읽은 블록 수를 의미합니다. "CONSISTENT GETS"은 변경작업 후 ROLLBACK문을 실행했을 때 변경 전 데이터로 복구하기 위해 이전 데이터를 저장해 두는 메모리 영역으로부터 읽은 블록 수입니다. 즉, "PHYSICAL READS"는 물리적 구조에서 읽은 블록 수이며 "DB BLOCK GETS"와 "CONSISTE NT GETS"는 논리적 구조(메모리 영역)에서 읽은 블록 수를 의미합니다. 되도록, 하나의 테이블을 질의할 때 물리적 구조로부터 데이터를 읽는 것보다는 논리적 구조로부터 읽은 블록 수가 더 많아야 성능에 도움이 될 것입니다. 만약, 충분한 데이터 버퍼 공간이 확보되었다면 "DB BLOCK GETS"와 "CONSISTENT GETS"가 더 높은 값이 출력될 것입니다. 그리고, 다음과 같은 공식에 의해 캐시 히트율을 계산할 수 있는데 이것은 사용자가 실행한 SQL문의 테이블이 이미 다른 사용자에 의해 읽혀져서 데이터버퍼 영역에서 발견되었던 블록 수를 백분율로 계산한 것입니다. 히트율 = 1 - (PHYSICAL READS / (DB BLOCK GETS + CONSISTENT GETS)) 캐시 히트율이 90% 이상일 때 충분한 데이터버퍼 캐시영역이 설정되어 있고 좋은 성능을 기대할 수 있습니다. 만약, 캐시 히트율이 좋지 못하다면 다음 파라메터를 통해 데이터버퍼 캐시영역의 크기를 크게 설정해 주어야 합니다.       $ cd $HOME/dbs $ vi init.ora ……………………… DB_CACHE_SIZE = [크기] :wq!       <잠깐>   오라클 9i 이전 버전에서는 DB_CACHE_SIZE 파라메터가 DB_BLOCK_SIZE와 DB_BLOCK_BUFFERS 파라메터로 나누어져 사용되었습니다. 2개 파라메터 값을 곱한 결과가 DB_CACHE_SIZE의 값과 같습니다.         멀티 버퍼 캐시영역을 할당한다.     일반적으로 오라클 데이터베이스의 SGA 영역에는 데이터 버퍼 캐시영역이 하나의 구조로 생성되는데 이 영역을 데이터의 성격과 크기에 따라 여러 개의 영역으로 나누어 생성할 수 있는 기법을 멀티 버퍼캐시 영역이라고 합니다. 위 그림에서 보시는 것처럼 데이터버퍼 캐시영역을 3가지 영역으로 나누어 생성할 수 있습니다. 첫 번째 영역은 KEEP 데이터버퍼 캐시 영역입니다. 이 영역은 운영되는 데이터베이스 환경에서 빈번하게 사용되는 테이블 데이터를 계속 데이터버퍼 캐시영역에 상주시키기 위한 공간입니다. 이 공간에 저장될 수 있는 테이블은 그 크기가 너무 크면 안되고 사용자에 의해 빈번하게 사용되는 테이블이어야 합니다. 예를 들어, 부서 테이블, 사원 테이블, 코드 테이블 등은 모든 애플리케이션 프로그램에서 항상 참조되며 또한 테이블의 크기가 크지 않기 때문에 가장 적합한 테이블입니다. 두 번째 영역은 RECYCLE 데이터 버퍼 캐시영역입니다, 이 영역에는 자주 사용되지 않고 가끔 사용되는 테이블이면서 테이블의 크기가 아주 큰 테이블을 검색할 때 사용됩니다. 사용자에 의해 검색된 테이블은 이 영역에 데이터를 로더한 후 작업이 완료되면 모두 클리어(CLEAR) 됩니다. 마지막으로, DEFAULT 데이터 버퍼 캐시영역은 하나의 데이터버퍼 캐시영역을 가진 환경에서 사용되던 구조와 동일한 의미를 가집니다. 즉 여러 사용자에 의해 공용으로 사용되는 메모리 공간입니다. 다음은 다중 풀 영역을 설정하는 파라메트들 입니다.       DB_CACHE_SIZE = [크기] DB_KEEP_CACHE_SIZE = [크기] DB_KEEP_RECYCLE_SIZE = [크기]     DB_CACHE_SIZE 파라메터는 DEFAULT 데이터버퍼 캐시영역의 크기를 의미합니다. DB_KEEP_CACHE_SIZE 파라메터는 KEEP 데이터버퍼 캐시영역의 크기를 의미합니다. DB_KEEP_RECYCLE_SIZE 파라메터는 RECYCLE 데이터버퍼 캐시영역의 크기를 의미합니다.     다음은 다중 풀 영역에 로더될 테이블을 다음과 생성해야 합니다.       < 문법 > CREATE TABLE [테이블명] ([컬럼-1] [데이터 타입], ……………………………………. [컬럼-N] [데이터 타입]) STORAGE ( BUFFER_POOL [KEEP | RECYCLE] );   ALTER TABLE [테이블명] STORAGE ( BUFFER_POOL [KEEP | RECYCLE] );           KEEP 데이터버퍼 캐시영역       자~ 그렇다면 KEEP 데이터버퍼 캐시 영역를 설정하고 싶은데 그 크기는 얼마나 할당해야 할까요 ? 크기를 설정하는 방법은 다음과 같습니다. 먼저, ANALYZE 명령어를 실행하여 캐싱하려는 테이블이 몇 개의 블록으로 구성되어 있는지를 분석해야 합니다. 테이블의 모든 데이터를 KEEP 데이터버퍼 영역에 저장하기 위해서 테이블의 실제 블록 수를 분석하는 것입니다.           $ sqlplus scott/tiger SQL> analyze table big_emp compute statistics; SQL> analyze table big_dept compute statistics; SQL> select table_name, blocks   from user_tables   where table_name in ( 'BIG_EMP' , 'BIG_DEPT' );   TABLE_NAME BLOCK ----------------------------------------- BIG_DEPT 5 <- 14 행을 저장하고 있슴 BIG_EMP 370 <- 28955 행을 저장하고 있슴 <-sum(blocks + 1) 을 모두 포함할 만큼의 충분한 크기로 keep buffer pool을 설정해야 합니다.           ANALYZE 명령어를 실행하면 분석결과가 DBA_TABLES, USER_TABLES 자료사전에 저장 됩니다. 만약, KEEP 데이터버퍼 캐시영역에 5개의 테이블을 저장하고 싶다면, 이러한 방법으로 각 테이블의 블록 수를 분석한 다음 전체 블록 수를 집계하여 그 값을 DB_KEEP_CACHE_SIZE 파라메터에 할당해 주면 됩니다.           $ cd $ORACLE_HOME/dbs $ vi init<DB명>.ora DB_KEEP_CACHE_SIZE = 4M ß BIG_DEPT, BIG_EMP 가 상주될 메모리 공간 DB_RECYCLE_CACHE_SIZE=4M ß RECYCLE 영역 :wq!   $ sqlplus "/as sysdba" SQL > startup force ß Shutdown 후 다시 Startup SQL > show parameter db_keep_cache_size   NAME TYPE VALUE db_keep_cache_size big integer 8388608                 RECYCLE 데이터버퍼 캐시영역           이번에는 RECYCLE 데이터버퍼 캐시 영역를 설정하고 싶은데 그 크기는 얼마나 할당해야 할까요 ? 크기를 설정하는 방법은 다음과 같습니다. 먼저, V$CACHE 자료사전을 참조하기 위해서 $HOME/rdbms/admin 경로에 있는 CATPARR.SQL 스크립트를 실행하십시오.           SQL> CONNECT SYS/CHANGE_ON_INSTALL AS SYSDBA SQL> show parameter db_recycle_cache_size         NAME TYPE VALUE ---------------------------------------------------------- db_recycle_cache_size big integer 8388608     SQL> START $HOME/rdbms/admin /catparr.sql SQL> SELECT owner#, name, count(*) blocks   FROM v$cache   WHERE name = 'EMP'   GROUP BY owner#, name;     OWNER NAME   BLOCK 5 EMP   200           실행된 결과가 V$CACHE 자료사전에 저장됩니다. 이 결과에서 해당 테이블이 데이터버퍼 캐시영역에서 필요로 하는 블록 수가 어느 정도인지 알 수 있습니다. 이 블록 수의 1/4 값을 DB_RECYCLE_CACHE_SIZE 파라메터에 설정하십시오. RECYCLE 영역에는 가끔 질의되는 테이블 데이터가 저장될 메모리 공간이기 때문에 결과의 전체 블록 수를 설정할 필요가 없습니다. 현재 데이터베이스에 설정된 다중 풀 영역에 대한 정보를 참조할 때는 V$BUFFER_POOL_STA TISTICS와 V$BUFFER_POOL 자료사전을 참조하십시오.               SQL > select name, buffers from v$buffer_pool; NAME BUFFERS   -------------- -----------   KEEP 1934 <- KEEP 영역의 크기 RECYCLE 1934 <- RECYCLE 영역의 크기 DEFAULT 967 <- DEFAULT 영역 크기           다중 버퍼 캐시영역이 활성화 되었으면 개발자가 실행할 테이블 중에 KEEP 영역과 RECYCL 영역에 로더될 테이블을 결정합니다.               $ sqlplus scott/tiger SQL> alter table big_emp storage ( buffer_pool keep); SQL> alter table big_dept storage ( buffer_pool keep); SQL> alter table account storage ( buffer_pool recycle);               각 테이블이 어떤 버퍼 캐시영역에 로더 되는지를 확인하는 방법입니다.               SQL> select table_name, buffer_pool   from user_tables   where table_name in ( 'BIG_EMP' , 'BIG_DEPT' );       TABLE_NAME BUFFER_ ---------------- ------- BIG_EMP KEEP <-KEEP 될 테이블 정보를 의미합니다.       SQL> SELECT * FROM big_dept; SQL> SELECT * FROM big_emp;   SELECT * FROM account;               다음 문장은 다중 버퍼 캐시영역의 현재 튜닝상태를 제공해 줍니다,               SQL> select name,   1-(physical_reads/(db_block_gets+consistent_gets)) "Multiple RATIO"   from v$buffer_pool_statistics   where db_block_gets + consistent_gets > 0 ;       NAMA Multiple RATIO ----------- --------------- KEEP .839300938 <-100 %에 가까울수록 최적 RECYCLE .819349315 <-50 %가 최적 DEFAULT .752205989 <-90 % 이상이 가장 최적                   KEEP 영역은 모든 테이블을 캐싱하기 위한 공간이므로 100% 히트율을 유지하는 것이 좋은 성능을 제공하고, RECYCLE 영역은 잠깐 사용되는 공간이므로 50% 히트율로도 충분하며, DEFAULT 영역은 일반적으로 사용되는 공간이므로 90% 히트율을 유지하는 것이 좋습니다.               <잠깐>오라클 8i 버전에서 멀티 버퍼 캐시 영역의 활성화 방법     오라클 9i 이전 버전과 이후 버전에서 멀티 버퍼캐시 영역을 활성화하는 방법의 차이는 문법적인 측면입니다. 즉, 9i 버전에서는 SGA 영역을 동적으로 관리하는 기능이 추가되었기 때문에 이와 관련된 문법이 변경되었습니다               $ vi init<SID>.ora   DB_BLOCK_BUFFERS = 3147 DB_BLOCK_LRU_LATCHES = 6 BUFFER_POOL_KEEP = (BUFFERS:1400, LRU_LATCHES:1) BUFFER_POOL_RECYCLE = (BUFFERS:200, LRU_LATCHES:3)               <잠깐>오라클 8i 버전에서 멀티 버퍼 캐시 영역의 활성화 방법           ID NAME LO_SETID HI_SETID SET_COUNT BUFFERS LO_BNUM JI_BNUM ------------------------------------------------------------------------------------- 0 0 0 0 0 0 0 1 KEEP 3 3 1 1400 0 0 2 RECYCLE 4 6 3 200 0 0 3 DEFAULT 1 2 2 1547 1600 0               DB_BLOCK_BUFFERS와 DB_BLOCK_SIZE 파라메터가 오라클 9i에서 DB_CACHE_SIZE 파라메터로 바뀌었고, DB_BLOCK_LRU_LATCHES와 같은 래치 파라메터는 오라클 서버가 자동 관리해 주는 방법으로 변경되어 9i에서는 정의하지 않습니다.                     자주 사용되는 테이블을 캐싱한다.           다중 멀티 풀 영역을 이용한 성능향상 기법이 오라클 8 버전부터 추가된 기능이라면 캐싱 테이블 기법은 오라클 이전 버전부터 사용되던 기법입니다. 사용자가 실행한 SQL문에 의해 테이블 전체 스캔 방법으로 테이블이 검색된 후 계속해서 데이터 버퍼 캐시영역에 상주하게 됩니다. 정상적인 데이터버퍼 캐시 메커니즘이라면 다른 서버 프로세스에 의해 데이터버퍼 캐시영역은 재 사용되겠지만 캐싱 테이블로 만들어진 블록들은 다른 서버 프로세스에 의해 재 사용되지 않고 계속해서 상주할 수 있게 되는 기능입니다. 다중 멀티 풀 영역에서 KEEP 데이터버퍼 캐시영역과 유사한 기능을 가지고 있습니다. 이 기법을 통해 빈번하게 사용되는 테이블을 데이터버퍼 캐시영역에 상주시키면 검색 시 성능을 향상시킬 수 있습니다. 다음 문법은 캐시 테이블을 생성하는 방법입니다.           문법 CREATE TABLE [테이블명] ([컬럼] [데이터타입]) [CACHE / NOCACHE]; ALTER TABLE [테이블명] [CACHE] /NOCACHE];             테이블을 생성할 때 [CACHE] 키워드를 사용하십시오. 또는, 이미 생성되어 있는 테이블을 [CACHE] 키워드로 변경할 수도 있습니다. 또한, [CACHE]된 테이블을 [NOCACHE]로 변경할 수도 있습니다. 만약, CACHE된 테이블 데이터가 [NOCACHE]로 바뀌면 데이터베이스가 종료되고 다시 시작될 때 적용됩니다. 다음 예제를 따라 해 보세요. DBA_TABLES, USER_TABLES 자료사전을 검색해 보면 어떤 테이블이 캐시 테이블로 생성되어 있는지를 알 수 있습니다.                       SQL> alter table big_dept cache; SQL> select table_name, cache   from user_tables   where table_name in ('BIG_EMP' , 'BIG_DEPT');       TABLE_NAME CACHE   BIG_DEPT Y   BIG_EMP Y <-데이터 버퍼캐시 영역에 상주되는 테이블을     SQL> SELECT * FROM big_dept; SQL> SELECT * FROM big_emp;               다음은 캐시 테이블로 생성하지는 않았지만 힌트절을 통해 테이블을 캐싱하는 방법입니다.               SQL> SELECT /*+CACHE*/ deptno, dname, loc FROM big_dept; SQL> EXIT                     Multiple Block 구조           오라클 데이터베이스에서 테이블에 대해 읽기/쓰기 작업을 수행할 때 한번에 읽고 쓸 수 있는 데이터의 크기를 블록(Block)이라고 합니다. 하나의 블록크기는 오라클 데이터베이스가 설치될 때 init<SID>.ora 파일에 정의되는 DB_ BLOCK_SIZE 파라메터에 의해 결정됩니다. 그리고, 이 값은 더 이상 변경할 수 없습니다. 만약, 대용량의 데이터를 저장하고 있는 테이블에 대해 읽기작업을 실행했을 때 DB_BLOCK_SIZE가 4K(4096 Byte)인 경우보다 8K(8192 Byte)인 경우가 한번에 읽을 수 있는 데이터가 크기 때문에 약 2배 이상 빠르게 검색할 수 있을 것 입니다. 오라클 8i 버전까지는 설치할 때 결정된 한 개 블록의 크기를 더 이상 변경하지 못하여 대용량 데이터를 처리해야 하는 경우 근본적인 구조변경을 하지 못하였습니다. 오라클 9i 버전에서는 이러한 문제점을 해결하여 테이블스페이스를 생성할 때 특별한 블록크기를 지정하지 않으면 설치할 때 정의된 DB_BLOCK_SIZE 파라메터 값으로 결정하고, 대용량의 데이터를 저장하고 검색하는 테이블이 존재하는 테이블스페이스를 생성할 때는 별도로 블록크기를 보다 크게 설정할 수 있습니다. 이러한 기능을 다중 블록(Multiple Block)구조라고 합니다. 다음 내용은 블록의 크기가 작은 경우와 큰 경우에 대한 비교 분석된 내용입니다.                     먼저, 다중 블록크기를 설정하기 위해서는 데이터 버퍼 캐시영역에 각 블록크기에 대한 전용 데이터 버퍼 캐시영역을 활성화해야 하고 테이블스페이스 생성시 적절한 블록크기를 정의하게 되면 사용가능 합니다.             init<SID>.ora 파일에 관련 파라메터 들을 설정하십시오.               $ vi init<SID>.ora DB_BLOCK_SIZE = 2048 기본 블록크기 DB_4K_CACHE-SIZE = 8M 4K 블록크기를 설정한 테이블스페이스를 위한 메모리 공간 DB_8K_CACHE-SIZE = 16M 8K 블록크기를 설정한 테이블스페이스를 위한 메모리 공간 DB_16K_CACHE-SIZE = 32M 16K 블록크기를 설정한 테이블스페이스를 위한 메모리 공간 DB_32K_CACHE-SIZE = 64M 32K 블록크기를 설정한 테이블스페이스를 위한 메모리 공간       <- 이 파라메터들에 의해 SGA 영역에는 2K, 4K, 8K, 16K, 32K 블록크기를 가진 데이터가 읽혀질 때 저장될 전용 메모리 공간이 각각 활성화됩니다.             대용량 데이터를 저장해야 할 데이터가 저장될 테이블스페이스를 생성하십시오.               SQL> CREATE TABLESPACE INSA   DATAFILE '$HOME/dbs/insa01.dbf' size 10m blocksize 4k; SQL> create table emp_test   (A number) SQL> select * from user_tables   where table_name = 'EMP_TEXT';                     DB 캐시 영역의 시뮬레이션           이 기능은 오라클 데이터베이스의 SGA 영역에 활성화 되어 있는 데이터 버퍼 캐시영역에 대한 시물레이션 기능에 대해서 소개하고자 합니다. 오라클 9i 버전에서는 DB_CACHE_SIZE 파라메터에 의해 데이터 버퍼캐시 영역의 크기가 결정되는데 이 공간의 크기가 너무 작게 설정되어 있으면 데이터를 검색할 때 성능이 저하되고 또한 너무 크게 설정되어 있으면 메모리의 낭비가 초래될 수 있는 단점을 가지고 있습니다. 그렇다면 모든 사용자가 실행하는 SQL문을 보다 빠르게 처리할 수 있을 만큼 적절한 메모리 공간이 확보되어 있는지를 확인할 수 있어야 할 것 입니다. DB_CACHE_ADVICE 파라메터를 ON으로 활성화하게 되면 현재 데이터 버퍼 캐시영역의 각 블록구조의 활용상태를 시뮬레이션 할 수 있습니다. [OFF]로 설정되면 데이터 버퍼 캐시영역에 대한 시뮬레이션을 하지 않습니다. [READY]는 향후 시뮬레이션을 위한 통계정보 만 수집하고 실제적인 시뮬레이션은 하지 않습니다. 이 값에 의해 수집된 통계정보는 공유 풀 영역에 약 700 바이트 만큼의 공간을 사용합니다. [ON]은 지금 즉시 통계정보 수집 후 데이터 버퍼 캐시영역에 대한 시뮬레이션을 시작합니다. 위 그림에서 V$DB_CACHE_ADVICE 자료사전을 분석하여 데이터 버퍼 캐시영역을 분석하고 있습니다. SIZE_FOR_ESTIMATE 컬럼은 데이터 버퍼캐시 영역을 3M 단위로 시뮬레이션하는 것을 나타내는 것이며 BUFFERS_FOR_ESTIMATE 컬럼은 3M 단위의 버퍼크기에 대한 블록 수를 나타내며 ESTD_PHYSICAL_READ_FACTOR와 ESTD_PHYSICAL_READS 컬럼은 각 버퍼크기에 대한 사용된 회수를 보여주고 있습니다. 만약, 특정 메모리 영역에서 주로 작업이 발생하고 어떤 메모리 영역에서는 작업이 거의 일어나지 않는다면 불필요한 메모리 공간이 낭비되고 있음을 의미하는 것이며, 만약, 모든 메모리 영역에서 빈번한 읽기 작업이 발생한다면 오히려 데이터 버퍼 캐시영역의 크기가 너무 작아 성능저하가 발생하고 있음을 나타냅니다     <잠깐> 다음은 오라클 이전 버전까지 제공되던 데이터 버퍼 캐시 영역의 시뮬레이션 방법입니다.                       이 기능을 사용하기 위해서는 DB_BLOCK_LRU_EXTENDED_STATISTICS 파라메터를 설정해야 합니다. 위 그림에서 데이터 버퍼캐시 영역의 블록 개수를 200개로 설정했을 때 각 블록구조의 사용된 회수를 V$CURRENT_BUCKET 자료사전을 통해 분석할 수 있습니다. 이 결과를 통해 현재 데이터 버퍼 캐시영역의 크기가 적절한지를 알 수 있습니다.           DB 캐시 영역의 시뮬레이션           사용자가 실행하는 SQL문에 의해 테이블이 디스크로부터 읽혀져서 메모리에 로더된 다음 서버 프로세스에 의해 다시 읽혀져 사용자에게 리턴되는 과정에서 데이터 버퍼 캐시영역의 히트율이 얼마나 되는지를 분석해 봅시다. 사용자의 요청에 의해 읽혀지는 테이블들이 디스크보다는 메모리로부터 읽혀진다면 히트율은 보다 높아질 것이며, 그렇지 않다면 히트율은 낮아질 것 입니다. 결론적으로 히트율이 높아진다면 보다 성능은 향상될 수 있을 것 입니다.               SQL> SELECT 1 - (phy.value - lob.value - dir.value) / ses.value "Hit Ratio"   FROM v$sysstat ses, v$sysstat lob,     v$sysstat dir, v$sysstat phy   WHERE ses.name = 'session logical reads'     AND dir.name = 'physical reads direct'     AND lob.name = 'physical reads direct (lob)'     AND phy.name = 'physical reads';       Hit Ratio   ---------   .849176501   <- 히트율이 90% 이상일 때 좋은 성능이 기대될 수 있습니다.               [physical reads]는 디스크로부터 읽은 블록 수이며 [physical reads direct]는 메모리로부터 읽은 블록 수이고, [physical reads direct (lob)]는 Large Object Binary를 읽은 블록 수이고, [session logical reads]는 해당 세션에서 논리적으로 읽은 블록 수입니다.