공유 풀 내용
공유 풀은 2개의 메인 구조와  제3의 구조를 포함하고 있습니다:

• 라이브러리 캐쉬 - 공유 SQL과 PL/SQL 저장
• 데이터 딕셔너리 캐쉬 - 딕셔너리 객체에 관한 정보 유지
• 사용자 글로벌 영역(UGA, User Global Area) - 다중 쓰레드(multithreaded) 연결에 관한 정보 유지

공유 글로벌 영역 튜닝
데이터 딕셔너리 캐쉬 또는 라이브러리 캐쉬 상에서의 캐쉬 실패(cache miss)는 데이터베이스 버퍼 캐쉬 상에서의 실패보다 훨씬 비용이 많이 듭니다. 캐쉬 실패 시, 공유 풀 튜닝이 우선됩니다.
공유 풀을 튜닝할 때, 오라클 알고리즘이 메모리에서 라이브러리 캐쉬 데이터 보다 딕셔너리 데이터를 좀 더 오래 유지하고 있기 때문에, DBA는 주로 라이브러리 캐쉬에 관심이 있을 것입니다. 따라서, 수용할 수 있는 캐쉬 적중율로 라이브러리 캐쉬를 튜닝함으로써, 데이터 딕셔너리 캐쉬 적중률 또한 수용할 수 있게 됩니다.공유 풀이 너무 작을 경우, 서버는 자원을 전용하여 한정된 공간을 관리해야 합니다. 이때, CPU 자원의 소모로 경합이 발생합니다.

공유 풀의 크기
공유 풀의 크기를 init.ora 파라미터 SHARED_POOL_SIZE로 설정합니다. 디폴트는 3,500,000 바이트입니다.

라이브러리 캐쉬
라이브러리 캐쉬는 공유 SQL과 PL/SQL 영역(PL/SQL 블록과 SQL 문의 완전 구문분석된 표시 또는 컴파일된 표시)을 포함합니다:

PL/SQL 블록에는 다음이 포함되어 있습니다:

• 프로시저
• 함수
• 패키지
• 트리거
• 익명의(anonymous) PL/SQL 블록

데이터 딕셔너리 캐쉬
데이터 딕셔너리 캐쉬는 메모리 내에 딕셔너리 객체의 정의를 보관합니다

SQL 과 PL/SQL 저장장소
오라클 서버는 SQL문과 PL/SQL 블록을 저장하기 위해 라이브러리 캐쉬를 사용합니다. 캐쉬를 관리하는 데에는 LRU(Least Recently Used, 최근최저사용빈도) 알고리즘이 사용됩니다.

사용자가 이미 캐쉬에 존재하는 문장을 실행시킬 경우, 오라클 서버는 문장의 구문을 재분석하지 않고 캐쉬에 저장된 버전을 사용할 수 있습니다.

문장이 이미 캐쉬에 저장되어 있는가를 찾기 위하여, 오라클 서버는 다음을 수행합니다:

1. ASCII 텍스트의 수치로 문장을 줄임
2. 이 수치에 해시 함수 사용

첫번째 튜닝 목표
구문분석을 최소로 유지하여 실패를 감소시킵니다:

• 애플리케이션이 SQL 문에 대해 구문분석 호출을 하고 문장의 구문분석된 표시가  라이브러리 캐쉬 내의 공유 SQL 영역에 이미 존재하지 않은 경우, 오라클 서버는 문장의 구문을 분석하여 공유 SQL 영역을 할당합니다.
   
   다음을 사용하여 가능할 때 마다 SQL문이 공유 SQL 영역을 공유할 수 있도록 확인하십시오:
   - 가능한 많은 일반 코드(generic code)
   - 상수보다는 바인드 변수
  
  
• 애플리케이션이 SQL 문에 대해 실행 호출을 하고 문장의 구문분석을 포함하는 공유 SQL 영역이 라이브러리 캐쉬에 반납하여 다른 문장을 위해 여유공간을 만들 경우, 오라클  서버는 문장의 구문을 재분석하고, 새로운 공유 SQL 영역을 할당하며, 문장을  실행시킵니다. 더 많은 메모리를 라이브러리 캐쉬에 할당하여 실행 호출 시 라이브러리 캐쉬 실패를 감소시키십시오.
• 스키마 객체가 SQL 문에서 참조되고 이 객체가 어떠한 방법으로든 나중에 수정될 경우, 공유 SQL 영역은 무효로 됩니다.
  

두 번째 튜닝 목표
다음을 통해 단편화를 피하십시오:

• 공유 풀 영역에 예약된 공간을 할당하여 대용량 메모리 요구에 대해 충분한 연속 공간 보장
• 메모리 내의 SQL 과 PL/SQL 영역과 같이 자주 요구되는 큰 객체는 오래되었다고 일반적인 LRU 메커니즘으로 삭제하지 말고 고정
• 큰 익명의 블록을 사용하지 말고 패키지된 작은 PL/SQL 함수 사용
• 다중 쓰레드 연결에서 공유 서버 프로세스에 의한 세션 메모리 사용 측정

3개의 키워드
V$LIBRARYCACHE 내의 각 행은 라이브러리 캐쉬에서 유지되는 한 유형의 항목에 대한 통계를 포함합니다. 각 행에 의해 설명된 항목은 NAMESPACE 열의 값에 의해 구별됩니다. 다음의 NAMESPACE 값을 가진 테이블의 행은 SQL 문과 PL/SQL 블록에 대한 라이브러리 캐쉬 활동을 반영합니다:

SQL AREA, TABLE/PROCEDURE, BODY, TRIGGER

기타의 NAMESPACE 값을 가진 행은 오라클이 종속성 유지를 위해 사용하는 객체 정의에 대한 라이브러리 캐쉬 활동을 반영합니다:

INDEX, CLUSTER, OBJECT, PIPE

NAMESPACE와 관련된 3개의 키워드는 다음과 같습니다.

• GETS: 연관된 항목(item)에 대한 정보를 요청한 총 횟수
• PINS: 이들 영역 각각에 대해, SQL 문이나 프로시저의 실행된 수가 계산됩니다.
• RELOADS: SQL 문에 대한 실행 호출이 수행되고, 문장의 구문분석된 표시를 포함하는 공유 SQL 영역이 다른 문장에 대해 여유공간을 만들기 위해, 또는 문장이 참조하는 객체가 무효가 되었기 때문에 라이브러리 캐쉬로부터 할당이 해제될 경우, 오라클 서버는 문장을 재로드하여 구문을 재분석합니다.  재로드 횟수는 이들 각 네임스페이스에 대해 계산됩니다.

뷰의 설명

• V$SGASTAT: 모든SGA 구조의  크기
    SQL> select * from v$sgastat;
    POOL        NAME                        BYTES
    ----------- --------------------------- --------
    shared pool free memory                  6447072
    shared pool dictionary cache              160932
    shared pool library cache                 463100
    shared pool sql area                     1220580
    shared pool sessions                      242880
          ...
  ( 공유 풀이 캐쉬로서 작용하기 때문에, 모든 여유 메모리가 사용될 때까지 그 어느 것도 삭제되지 않을 것입니다. 여유 메모리는 일반적으로 “낭비된 공간”으로서 간주됩니다. 여유 메모리의 값이 높다면, 이것은 단편화가 일어날 확률이 높다는  것을 나타냅니다.)
  
• V$LIBRARYCACHE: 라이브러리 캐쉬 관리에 관한 통계
• V$SQLAREA: 모든 공유 커서에 대한 전체 통계와 SQL문의 처음 1000개의 문자
• V$SQLTEXT: 자르지 않은 전체 SQL 텍스트, 복수 행으로 표시
• V$DB_OBJECT_CACHE: 패키지 등 캐쉬에 저장된 데이터베이스 객체; 또한 SQL 문에서 참조는 테이블 또는 동의어와 같은 객체

커서가 공유되고 있는가?

• V$LIBRARYCACHE 뷰: gethitratio는 공유되는 커서를 찾는 구문분석 호출의 퍼센트를  의미합니다 (GETHITS/GETS). 이 비율은 90 대 후반의 값이어야 합니다. 그렇지 않을 경우, 애플리케이션 코드의 효율성을 향상시켜야 할 것입니다.
  
      SQL> select namespace, gethitratio
       2       from v$librarycache;
      NAMESPACE       GETHITRATIO
      --------------- -----------
      SQL AREA          .86928702
      TABLE/PROCEDURE   .80073801
      BODY              .6

주의: OEM 진단 팩 애플리케이션:
Performance Manager -> Memory -> 라이브러리 캐쉬 상세 내역(Library Cache Details)

주의: OEM 진단 팩 애플리케이션:
Performance Manager -> Memory -> SQL 영역(SQL AREA)

재로드 대 핀 비율 계산 방법

• V$LIBRARYCACHE 뷰: 이 뷰는 이미 구문분석이 된 문장들이 캐쉬에서 오래되어 삭제되었는지의 여부를 표시합니다. RELOADS 수는 PINS 수의 1%를 넘어서는 안됩니다.
• REPORT.TXT 출력 결과: 이 섹션은 utlbstat와 utlestat 가 실행된 기간에 대한 동일한 비율을 표시합니다.
       
     LIBRARY           PINS PINHITRATI   RELOADS
     ------------- -------- ---------- ---------
     BODY               105          1         0  
     SQL AREA         12822       .982        95
     TABLE/PROCED      3714       .969        81
     TRIGGER            917       .997         3

주의: OEM 진단 팩 애플리케이션:
Performance Manager -> Memory -> Library Cache Hit %

무효가 발생할 때
스키마 객체가 SQL 문에서 참조되고 그 객체가 나중에 어떠한 방법으로든 수정될 경우, 공유 SQL 영역은 무효로 되고(무효로 표시됨) 문장은 다음에 실행될 때 구문이 재분석되어, 재로드됩니다.

예: 테이블, 시퀀스, 동의어, 또는 뷰는 재생성되거나 변경되거나 삭제되어, 아니면, 프로시저 또는 패키지 사양이 재컴파일되면, 모든 종속 공유 SQL 영역이 무효로 됩니다.

주의: OEM 진단 팩 애플리케이션:
Performance Manager -> Memory -> Library Cache Details

애플리케이션 테스트
기존 애플리케이션에 대해, 테스트를 설정하고 동적인 뷰를 사용하여, 사용되는 메모리 양을 찾아야 합니다. SHARED_POOL_SIZE를 매우 큰 값으로 설정(필요하면 다른 구조를 희생해서라도)한 다음, 애플리케이션을 실행시키십시오.

사용된 공유가능한 메모리 계산

• 패키지 및 뷰와 같은 내장 객체에 대해, 다음의 질의를 사용하십시오.
    SQL> SELECT SUM(sharable_mem)
      2  FROM v$db_object_cache
      3  WHERE type = ‘PACKAGE’ or type = ‘PACKAGE BODY’ or
      4        type = ‘FUNCTION’ or type = ‘PROCEDURE’;
• SQL 문에 대해, 애플리케이션이 잠깐동안 실행된 후  V$SQLAREA를 질의할 필요가 있습니다. 자주 실행되는 문장에 대해, 동적인 SQL을 포함하지는 않지만, 다음의 질의를 사용하여 사용되는 메모리 양을 계산할 수 있습니다:
    SQL> SELECT SUM(sharable_mem)
      2  FROM v$sqlarea
      3  WHERE executions > 5;
• 또한, 오픈 커서 마다 사용자당 공유 풀에 약 250 바이트를 허용해야 합니다. 이것은  다음 질의를 사용하여 최대 절정 시간에 테스트할 수 있습니다:
    SQL> SELECT SUM(250 * users_opening)
      2  FROM v$sqlarea;
  테스트 환경에서, 테스트 사용자에 대해 오픈 커서의 수를 선택하여 메모리를 측정할 수 있습니다. 결과 값을 총사용자수와 곱합니다:
    SQL> SELECT 250 * value bytes_per_user
      2  FROM v$sesstat s, v$statname n
      3  WHERE s.statistic# = n.statistic#
      4  AND n.name = ‘opened cursors current’
      5  AND s.sid = 15;

애플리케이션은 위의 수를 총합한 것 만큼의 라이브러리 캐쉬 이외에, 동적인 SQL을 위한 약간의 여유가 있는 것이 이상적입니다.

V$SHARED_POOL_RESERVED 뷰를 통한 진단
V$SHARED_POOL_RESERVED 뷰의 통계는 파라미터 튜닝에 도움이 될 수 있습니다. SGA를 증가시키는 데에 충분한 여유 메모리가 있는 시스템에서, 목표는 REQUEST_MISSES = 0 입니다.

ABORTED_REQUEST_THRESHOLD 프로시저를 통한 진단
DBMS_SHARED_POOL 패키지 내의 ABORTED_REQUEST_THRESHOLD 프로시저는 ORA-4031 오류를 보고하기 이전에 비워야 할 공유 풀의 양을 제한하는 것을 허용합니다. 따라서, 큰 객체로 인해 발생할 수 있는 extent(한번에 비워지는)를 제한할 수 있습니다.

파라미터 설정을 위한 Guidelines
시스템이 OS 메모리에 대해 한정되어 있더면, 목표는 다음과 같습니다:

1. REQUEST_FAILURES = 0 또는 증가되지 않음
2. LAST_FAILURE_SIZE > SHARED_POOL_RESERVED_MIN_ALLOC
3. AVG_FREE_SIZE > SHARED_POOL_RESERVED_MIN_ALLOC

두 번째 목표나 세 번째 목표가 달성되지 않으면, SHARED_POOL_RESERVED_SIZE와 SHARED_POOL_SIZE를 같은 양으로 증가시키십시오.

SHARED_POOL_RESERVED_SIZE가 너무 작을 때의 Guidelines
REQUEST_FAILURES > 0 이고 적어도 다음 중 하나가 사실이면, 예약 풀이 너무 작은 것입니다:

• LAST_FAILURE_SIZE > SHARED_POOL_RESERVED_MIN_ALLOC
• MAX_FREE_SIZE < SHARED_POOL_RESERVED_MIN_ALLOC
• FREE_SPACE < SHARED_POOL_RESERVED_MIN_ALLOC

이러한 경우에:

• SHARED_POOL_RESERVED_SIZE와 SHARED_POOL_SIZE를 적절하게 증가시키십시오. 또는
• SHARED_POOL_RESERVED_MIN_ALLOC를 증가시키십시오 (그러나 SHARED_POOL_SIZE를 증가시킬 필요가 있을 수도 있습니다.)

SHARED_POOL_RESERVED_SIZE가 너무 클 때의 Guidelines
다음과 같은 경우, 너무 많은 메모리가 예약 목록에 할당되었을 수 있습니다:

• REQUEST_MISS = 0 또는 증가되지 않음
• FREE_SPACE => 최소 SHARED_POOL_RESERVED_SIZE 의 50%

이러한 경우에:

• SHARED_POOL_RESERVED_SIZE를 감소시키십시오. 또는
• SHARED_POOL_RESERVED_MIN_ALLOC을 감소시키십시오 (디폴트 값이 아닌 경우)

SHARED_POOL_SIZE가 너무 작을 때의 Guidelines
이것은 다음과 같은 경우일 것입니다:

• REQUEST_FAILURES > 0 이고 증가되지 않음
• LAST_FAILURE_SIZE < SHARED_POOL_RESERVED_MIN_ALLOC

이러한 경우에:

• SHARED_POOL_RESERVED_SIZE를 감소시키십시오. 또는
• SHARED_POOL_RESERVED_MIN_ALLOC을 감소시키십시오 (디폴트 값보다 크게 설정된 경우)

객체 보관 이유 및 시기
큰 객체를 로드하는 것이 단편화를 유발시키는 주요 원인입니다. 크기는 작지만 수가 많은 객체들이 오래되었을 때 여유 공간을 만들기 위하여 공유 풀에서 삭제되기 때문에, 사용자의 응답시간이 영향을 받게 됩니다. 이러한 상황을 막기 위하여, 이들 큰 객체나 자주 요구되는 객체는 공유 풀에 보관하여 오래되어도 공유 풀에서 결코 삭제되지 않도록 하십시오.

• 보관해야 할 객체
  -  STANDARD, DIUTIL 패키지, 공유가능한 메모리가 정의된 한계값을 초과하는 객체와 같이 자주 요구되는 큰 프로시저 객체
  -  자주 사용되는 테이블에서 종종 실행되는 컴파일된 트리거
  -  시퀀스 (시퀀스가 공유 풀에서 오래되어 삭제될 때, 시퀀스 번호가 사라지기 때문)
• 객체 보관 시기: 시작 시간이 가장 좋음 (추가 단편화를 예방하기 때문)
• ALTER SYSTEM FLUSH SHARED_POOL 명령을 사용하여 공유 풀을 비우더라도 보관된 객체를 비우지는 못합니다.

객체 보관 방법
제공된 DBMS_SHARED_POOL 패키지와 KEEP 프로시저를 사용하십시오.
패키지를 생성하기 위해서는 dbmspool.sql 스크립트를 실행시키십시오. prvtpool.plb 스크립트는 앞의 스크립트가 종료될 때 자동으로 실행됩니다. 이들 스크립트는 catproc.sql로 실행되지 않습니다.
UNKEEP 프로시저를 사용하여, 공유 풀에서 고정된 객체를 삭제하십시오.

큰 익명의 PL/SQL 블록을 제거하기 위한 2가지 해결방안

• 이들 블록을 찾아내어 패키지된 함수를 호출하는 익명의 작은 PL/SQL 블록으로 바꾸십시오.
• 익명의 PL/SQL 블록이 패키지로 바뀔 수 없는 경우에, 이 블록은 V$SQLAREA에서 식별되어 KEPT로 표시될 수 있습니다.
  그런 다음 적절한 공급된 프로시저를 사용하여 이들 블록을 메모리에 보관할 수 있습니다 .
  
  SQL> declare x number;
    2  begin x : = 5;
    3  end;
  은 다음과 같이 될 것입니다:
  
  SQL> declare /* KEEP_ME */ x number;
    2  begin x : = 5;
    3  end;
  
  SQL> select address, hash_value
    2  from v$sqlarea
    3  where command_type = 47 and sql_text like ‘% KEEP_ME %’;
  
  위 문장에서 알아낸 address와 hash_value로 익명의 PL/SQL 블록을 식별하여 KEEP 프로시저를 실행하십시오.
  
  SQL> execute dbms_shared_pool.keep(‘address,hash_value’);

초기화 파라미터
다음의 파라미터는 라이브러리 캐쉬에 영향을 미칩니다.

• OPEN_CURSORS: 사용자 프로세스에 할당된 프라이비트 SQL 영역을 참조하는 커서의 수 정의 ( 프라이비트 SQL 영역은 커서가 종료될 때까지 계속 존재하여 문장이 컴파일 된 후에도 여전히 존재합니다).
  
  공유 SQL 영역에 대해 사용할 수 있는 추가 메모리를 이용하기 위하여, 세션에 대해  허용되는 커서의 수를 증가시킬 필요가 있습니다. 애플리케이션 개발자는 시스템 메모리를 보존하기 위하여 불필요하게 오픈된 커서를 종료시켜야 합니다. 디폴트 값은 50입니다.
   
• CURSOR_SPACE_FOR_TIME: 디폴트가 FALSE인 부울(boolean) 파라미터 (이 파라미터를   TRUE로 설정할 경우, 시간을 얻기 위한 공간 사용을 선택하십시오. 공유 SQL 영역은 이  영역을 참조하는 커서가 종료될 때까지는 오래되어도 삭제되지 않습니다. 따라서, 자유 메모리가 있는지, 캐쉬 실패는 없는지 확인하십시오. V$LIBRARYCACHE 내의 RELOADS   값이 일관되게 0 이 아니면 이 파라미터를 변경하지 마십시오. 애플리케이션이 Forms나 다른 동적인 SQL을 사용할 경우, 설정값을 FALSE로 유지하십시오.)
   
• SESSION_CACHED_CURSORS: 이 파라미터는 사용자가 동일한 문장의 구문을 반복하여    분석하는 상황에 도움이 됩니다. 이것은 사용자가 종종 Forms 간에 교차할 때 Forms  애플리케이션에서 발생하는데, 한 폼에 대해 오픈된 모든 SQL 문이 다른 폼으로 교환할 때  종료되기 때문입니다. 이 파라미터로 종료된 커서는 세션 내에 캐쉬됩니다. 따라서, 문장의   구문을 분석하기 위한 어떠한 연속 호출이라도 구문분석 단계를 무시할 것입니다. (이것은    프리컴파일러에서 HOLD_CURSORS와 비슷합니다.)
  
  설정한 값이 효과가 있는지 검사하기 위하여, 일반적인 사용자 세션에 대해 V$SESSTAT에서 세션 통계 “session cursor cache hits(세션 커서 캐쉬 적중)”와 “parse count(구문분석 카운트)”를 비교하십시오. 구문분석이 캐쉬 적중을 거의 초래하지 않는다면, 설정값을 증가시켜야 할 것입니다. 그러나, 이것으로 인하여 전반적인 메모리 요구가 증가할   것이라는 사실을 명심하십시오.
  
  디폴트는 0인데, 이것은 캐쉬되지 않았다는 것을 의미합니다. 

2개의 키워드

• GETS: 해당 항목에 대한 정보의 총 요청 수 (예를 들어, 파일 설명에 대한 통계를 포함하는 행에서, 이 열은 파일 설명 데이터에 대한 총 요청 수를 포함합니다.)
• GETMISSES: 캐쉬 실패의 결과를 초래한 데이터 요청 수

목표
일부 경우에 데이터 딕셔너리 캐쉬에서의 실패가 예상됩니다. 인스턴스가 시작하자마자, 데이터 딕셔너리 캐쉬에는 어떠한 데이터도 포함되어 있지 않습니다. 따라서 실행된 어떠한 SQL 문이라도 캐쉬 실패를 초래할 수 있습니다. 더 많은 데이터가 캐쉬로 읽혀질수록, 캐쉬 실패의 가능성은 감소합니다. 결국, 데이터베이스는 가장 자주 사용되는 딕셔너리 데이터가 캐쉬에 저장되는 “안정된 상태”에 도달해야 합니다. 이러한 점에서, 캐쉬 실패는 거의 발생해서는 안됩니다. 캐쉬를 튜닝하기 위해, 애플리케이션이 실행된 후에만 활동을 검사하십시오.

딕셔너리 캐쉬 감시
V$ROWCACHE 뷰를 사용하십시오. 가장 관심있는 열은 다음 다음과 같습니다.

열	설명
PARAMETERS	데이터 딕셔너리 항목의 범주
GETS	범주에 관한 정보 요청
GETMISSES	캐쉬 실패를 초래하는 요청

크기 조정
SHARED_POOL_SIZE 파라미터를 사용하여 간접적으로만 딕셔너리 캐쉬의 크기를 조정할 수 있습니다. 공유 풀 공간을 할당하기 위한 알고리즘은 딕셔너리 캐쉬를 선호합니다.

적절한 비율을 위한 목표
정상적인 실행동안 모든 GETMISSES의 총합과 GETS의 총합의 비율은 15%이하이어야 합니다. 이보다 높은 경우, SHARED_POOL_SIZE를 증가시킬 것을 고려하십시오.
시작한 후 서버가 객체 정의를 처음 필요로 할 때, 객체 정의가 캐쉬로 로드되어야 하기 때문에 GETMISSES값이 0이 되기를 기대할 수 없습니다. 

Report.txt 출력 결과의 비율
Report.txt 출력 결과가 항목 수에 대해  높은 GET_MISS/GET_REQ 비율을 나타내면, 이것은 SHARED_POOL_SIZE를 증가시켜야 한다는 것을 의미합니다.

주의: OEM 진단 팩 애플리케이션:
Performance Manager -> Memory -> Data Dictionary Cache Hit %

사용자 글로벌 영역
다중 쓰레드 서버를 사용할 경우, 사용자 세션과 커서 상태 정보는 개별(private) 사용자 메모리에 저장되는 것이 아니라 공유 풀에 저장됩니다. 정렬 영역과 개별(private) SQL 영역은 세션 정보에 포함됩니다. 이것은 공유 서버가 문장 당 작업을 하기 때문에 어떠한 서버도 모든 사용자의 정보에 액세스할 필요가 있기 때문입니다. 공유 풀의 이 부분은 사용자 글로벌 영역(User Global Area, UGA)이라고 합니다.

다중 쓰레드 서버에 대한 총 메모리 요구량은 전용 서버를 쓰는 경우 정도입니다. SHARED_POOL_SIZE를 증가시킬 필요가 있겠지만, 개별(private) 사용자 메모리는 더 적게 필요합니다.

필요한 공간 측정
모든 다중 쓰레드 연결에 대해, 공유 풀에 세션 메모리를 놓기 위하여 모든 공유 서버 사용자를 위한 필요 공간의 양을 계산할 필요가 있습니다.

주의: OEM 진단 팩 애플리케이션:
Performance Manager -> Memory -> Memory Allocated

대용량 풀의 존재

Oracle8은 SGA에 공유 풀과 유사한 새로운 영역을 도입했습니다. 대용량 풀은 할당되지 않으므로 필요할 경우 명시적으로 구성해야 합니다. 대용량 풀의 메모리는 공유 풀에서 할당되는 것이 아니라 SGA에서 직접 할당되므로 Oracle 서버 시작 시 인스턴스에 필요한 공유 메모리의 양에 대용량 풀의 메모리를 추가합니다.

장점

대용량 풀은 다음 작업에 사용할 세션 메모리에 대용량 메모리를 할당할 때 사용됩니다.

• I/O 서버 프로세스
• Oracle 백업 및 복원 작업
  Oracle 서버 백업과 복원 작업 및 I/O 서버 프로세스에 필요한 메모리는 수백 KB 크기의 버퍼에 할당됩니다. 대용량 풀은 공유 풀보다 이러한 요청을 더 잘 만족시켜 줄 수 있습니다.
• 다중 스레드 서버: Oracle 서버는 다중 스레드 서버를 위한 대용량 풀에서 세션 메모리를 할당함으로써 주로 공유 SQL을 캐시하는 용도로 공유 풀을 사용할 수 있게 되므로 공유 SQL 캐시 감소에서 오는 성능 오버헤드를 피할 수 있습니다.
• 병렬 실행: PARALLEL_AUTOMATIC_TUNING 매개변수가 TRUE로 설정되어 있으면 Oracle 서버는 대용량 풀에서 병렬 실행 버퍼를 할당합니다. 이 매개변수가 FALSE로 설정되어 있으면 공유 풀에서 병렬 실행 버퍼를 할당합니다. PARALLEL_AUTOMATIC_TUNING 매개변수 값이 TRUE로 설정되어 있으면 Oracle 서버는 LARGE_POOL_SIZE 매개변수 값을 자동으로 계산합니다. LARGE_POOL_SIZE 값을 수동으로 설정하려면 V$SGASTAT 뷰를 질의하여 필요에 맞게 LARGE_POOL_SIZE 값을 늘리거나 줄입니다.

작업 방식

LARGE_POOL_SIZE 초기화 매개변수가 설정되어 있지 않으면 Oracle 서버는 SGA의 공유 풀에서 공유 메모리 버퍼 할당을 시도합니다. LARGE_POOL_SIZE가 설정되어 있으나 그 값이 충분히 크지 않은 경우에는 할당에 실패하며 버퍼를 요청한 Oracle 서버 구성 요소는 다음을 수행합니다.

• 로그 아카이브가 실패하고 오류를 반환합니다.
• RMAN 명령이 메시지를 경고 파일에 쓰며 해당 작업에 I/O 슬래이브를 사용하지 않습니다.
• MTS 세션이 시작되면 고정 UGA를 위한 작은 양의 메모리는 공유 풀에서 할당되고 나머지 UGA는 대용량 풀에서 할당됩니다. 대용량 풀에 남아 있는 공간이 충분하지 않으면 다음과 같은 ORA-4031 오류가 반환됩니다.
    ORA-4031: unable to allocate 636 bytes of shared memory
       ("large pool","EMP","session heap","define var info")

대용량 풀에는 LRU 목록이 없습니다. 대용량 풀은 공유 풀에서 할당된 다른 메모리와 동일한 LRU 목록을 사용하는 공유 풀의 예약 공간과는 다릅니다.

대용량 풀 구성 방법

LARGE_POOL_SIZE 매개변수가 설정되어 있지 않은 경우에는 대용량 풀이 없습니다. 지정한 크기의 메모리는 SGA에서 할당됩니다.

• 설명: 대용량 풀 크기의 기본 단위는 바이트임(값을 KB 또는 MB로도 지정 가능)
• 최소값: 600KB
• 최대값: 2GB 이상(최대값은 운영 체제마다 다름)
• 대용량 풀이 사용되고 있는 현황을 확인하기 위해서 V$SGASTAT 뷰를 질의합니다.
  SQL>    SELECT *
    2     FROM v$sgastat
    3     WHERE pool = 'large pool';
  POOL         NAME                        BYTES
  -----------  --------------------------  ----------
  large pool   free memory                 4194304

PARALLEL_AUTOMATIC_TUNING이 TRUE로 설정되어 있으면 LARGE_POOL_SIZE가 자동으로 계산됩니다. LARGE_POOL_SIZE 값을 수동으로 설정하려면 V$SGASTAT 뷰를 질의하여 필요에 맞게 LARGE_POOL_SIZE 값을 늘리거나 줄입니다.

예를 들어, 시작 시 다음 오류가 발생할 수 있습니다.

   ORA-27102: out of memory

   SVR4 Error: 12: Not enough space

이 경우 데이터베이스가 시작될 수 있도록 LARGE_POOL_SIZE 값을 충분히 낮출 것을 고려해 봅니다. LARGE_POOL_SIZE 값을 낮춘 후에도 다음 오류가 표시될 수 있습니다.

   ORA-04031: unable to allocate 16084 bytes of shared memory ("large pool","unknown object","large pool hea","PX msg pool")

이런 경우 다음 질의를 실행하여 16,084바이트를 할당할 수 없었던 이유를 확인합니다.

   SQL> SELECT NAME, SUM(BYTES) FROM V$SGASTAT

     2  WHERE POOL='LARGE POOL' GROUP BY ROLLUP (NAME);

Oracle은 다음과 유사한 출력으로 응답합니다.

   NAME                          SUM(BYTES)
   --------------------------    ----------
   PX msg pool                     1474572
   free memory                      562132
                                   2036704

   3 rows selected.

이 문제를 해결하려면 LARGE_POOL_SIZE 값을 늘립니다. 이 예제의 LARGE_POOL_SIZE 값은 약 2MB입니다. 사용 가능한 메모리의 크기에 따라 LARGE_POOL_SIZE 값을 4MB로 늘려 데이터베이스 시작을 시도할 수 있습니다.

• V$LIBRARYCACHE 의 RELOADS/PINS 의 적절한 RATIO는?
  A. 1% 이하
  B. 5% 이하
  C. 10% 이하
  D. 15% 이하
  답

• V$LIBRARYCACHE의 RELOADS/PINS > 0.01일 때 늘려야 할 parameter?
  A. SHARED_POOL_SIZE
  B. LIBRARY_CACHE
  C. SORT_AREA_SIZE
  D. LOG_BUFFER
  답

• 다음 중 SHARED POOL의 튜닝 포인트가 아닌 것은?
  A. V$ROWCACHE의 GETMISSES/GETS
  B. V$LIBRARYCACHE의 GETHITRATIO
  C. V$LIBRARYCACHE의 RELOADS/PINS
  D. V$SYSSTAT의 SORTS(MEMORY)/SORTS(DISK)
  답

• 다음 중 Shared Pool 의 크기를 결정하기 위해서 참조하는 자료사전들은?
  A. V$DB_OBJECT_CACHE, V$SQLAREA, V$SESSTAT
  B. V$SQLAREA, V$SESSTAT, V$SQLTEXT
  C. V$SQLAREA, V$ROWCACHE, V$SESSTAT
  D. V$SQLAREA, V$LIBRARYCACHE, V$ROWCACHE
  답

• 다음 중 Shared Pool의 튜닝 포인트가 아닌 것은?
  A. V$ROWCACHE의 GETMISSES/GETS
  B. V$LIBRARYCACHE의 GETHITRATIO
  C. V$LIBRARYCACHE의 RELOADS/PINS
  D. V$SYSSTAT의 sorts(memory)/sorts(disk)
  답

• 다음 중 공유 커서를 조회할 수 있는 자료사전은?
  A. V$LIBRARYCACHE
  B. V$CACHE
  C. V$SQL
  D. V$SHARED_POOL_RESERVED
  답

• 다음 중 라이브러리 캐쉬에서의 CACHE HIT를 증가 시키기 위한 방법은(세 가지)?
  A. CODING CONVENTION을 따른다.
  B. PL/SQL 블록에서 상수보다 BIND 변수를 사용한다.
  C. SHARE POOL 의 크기를 증가 시킨다.
  D. 테이블 생성/변경 시 CACHE 옵션을 사용한다.
  답

• 다음과 같은 Query문의 결과인 gethitratio의 값이 어느정도인 것이 적당한가?
  SELECT GETHITRATIO
  FROM V$LIBRARYCACHE
  WHERE NAMESPACE = 'SQL AREA';
  
  A. 0.9보다 큰 값
  B. 0.9보다 작은 값
  C. 0.1보다 큰 값
  D. 0.1 보다 작은값
  답

• 다음은 라이브러리 캐쉬에 영향을 미치는 파라미터이다. 이들 중 라이브러리 캐쉬의 예약된 공간에 큰 오브젝트를 저장하기 위해서 그 크기의 기준치를 정하는 것은?
  A. SHARED_POOL_SIZE
  B. CURSOR_SPACE_FOR_TIME
  C. SHARED_POOL_RESERVED_SIZE
  D. SHARED_POOL_RESERVED_MIN_ALLOC
  답

• 다음의 SQL문은 어떤 정보를 얻기 위한 것인가?
  SELECT (SUM(getmisses)/SUM(gets)) *100
  FROM v$rowcache;
  
  A. Redo Log Buffer Cache 튜닝정보
  B. Rollback Segment의 튜닝 정보
  C. Shared Pool의 튜닝정보
  D. Database Buffer Cache의 튜닝정보
  답

• 라이브러리 캐쉬에 관한 설명 중 옳지 않은 것은?
  A. SQL문과 PL/SQL 블록을 저장하는 데 사용된다.
  B. LRU 알고리즘에 의해 관리된다.
  C. Cache Hit인 경우 Parsing time이 감소된다.
  D. 라이브러리 캐쉬의 크기는 파라미터로 직접 결정할 수 있다.
  답