[오라클]1-1단계 공유풀 영역

1-1 단계 : 공유풀 영역

	공유 풀 영역을 보다 크게 할당한다
	공유 풀 영역을 보다 크게 할당한다.
	INIT<SID>.ORA 파일의 SHARED_POOL_SIZE 파라메터에 의해 공유 풀 영역의 크기는 결정됩니다. 하지만 너무 많은 사용자들이 너무 많은 SQL문을 실행하면 구문 분석된 정보가 모두 라이브러리 캐시영역에 저장됩니다. 새로운 사용자가 데이터베이스에 접속하고 새로운 SQL문을 실행했다면 그 문장은 서버 프로세스에 의해 구문 분석되어 라이브러리 캐시영역에 저장될 것입니다. 그런데, 불행하게도 라이브러리 캐시영역은 이미 빈 공간이 모두 사용되어 풀(FULL)된 상태입니다. 이런 경우가 발생하면 오라클 서버 프로세스는 로더를 하지 않고 잠시 대기(WAITING)한 후 로더되어 있는 SQL문 중에 가장 오래된 SQL문을 찾아내어 그 정보를 라이브러리 캐시영역으로부터 제거하게 됩니다. 이런 과정을 통해 확보된 빈 공간에 사용자의 새로운 SQL문 정보를 저장하게 됩니다. 이러한 방법을 AGING 메커니즘이라고 합니다. 하지만, 이러한 공간관리로 인해 생기는 문제점은 라이브러리 캐시영역에서 빈 공간을 확보하기 위해 가장 오래된 SQL문을 제거한 후 동일한 문장이 다른 사용자에 의해 재 실행될 때 구문분석을 다시 한다는 점입니다. 즉, 다시 재 실행될 SQL문의 구문분석 정보가 불필요하게 메모리로부터 제거되기 때문에 재 파싱이 발생하여 SQL문의 성능저하 현상이 초래될 수 있다는 점입니다. 이러한 문제점은 결국 라이브러리 캐시영역의 크기가 너무 작아서 발생한 문제이므로 공유 풀 영역의 크기를 더 크게 할당해 주어야 만 성능을 향상시킬 수 있습니다.       라이브러리 캐시영역의 튜닝분석 지금까지, 라이브러리 캐시영역에 대한 튜닝개념에 대해서 알아보았습니다. 그렇다면, 데이터베이스의 라이브러리 캐시 영역의 크기가 너무 작아 성능이 저하되고 있는지 또는 너무 크게 설정되어 있어 메모리가 낭비되고 있는지를 데이터베이스 관리자가 분석할 수 있어야 만 튜닝 계획을 수립할 수 있을 것입니다. 다음은 자료사전을 통해 라이브러리 캐시영역을 분석하는 방법입니다.                   먼저, V$LIBRARYCACHE 자료사전을 통해 히트율(GETHITRATIO)을 분석할 수 있습니다. 히트율이란 V$LIBRARYCACHE 테이블의 GET 컬럼과 GETHITS 컬럼을 백분율로 계산한 값으로 GET은 사용자가 실행한 SQL문이 구문 분석되어 라이브러리 캐시영역에 로더되려고 했던 수이며 GETHITS는 그 중에 로더 되었던 수를 의미합니다. 즉, 라이브러리 캐시영역이 충분한 공간을 할당하고 있어서 사용자의 모든 구문분석 정보를 로더하기에 충분한가를 백분율로 계산해 본 것입니다. 히트율이 90% 이상일 때 좋은 성능을 기대할 수 있습니다. 다음은 히트율을 확인하는 방법입니다.             SQL> SELECT namespace, gets, gethits, gethitratio   FROM v$libraycache       WHERE namespace = 'SQL AREA';     NAMESPACE GETS GETHITS GETHITRATIO SQL AREA 8950 8411 .936779536         GETHITRATIO 컬럼의 값이 90% 이상이면 라이브러리 캐시영역이 개발자들의 SQL 파싱정보를 저장하기에 충분한 메모리 공간을 확보하고 있음을 의미하며, 만약 90% 이하라면 성능이 저하될 수 도 있다는 것을 의미합니다. 물론, 90% 이하라도 사용자들이 성능에 만족한다면 튜닝대상이 안될 수도 있으며 반드시 튜닝을 해야 할 필요가 없다는 것 입니다.             <잠깐>         이러한 히트율의 분석은 기업에서 가장 바쁘게 일을 진행하고 있는 시간대에 분석결과를 기준으로 설명되는 것입니다. 아무도 일을 하고 있지 않는 야간에 결과를 분석한다면 아무런 의미가 없겠죠 ??           조치사항           히트율이 90% 이하이면 다음과 같이 SHARED_POOL_SIZE 파라메터의 값을 높게 설정해야 합니다.                 $ cd $HOME/dbs $ vi init<SID>.ora ….. SHARED_POOL_SIZE = 32000000 ß 이전 값보다 더 큰 값으로 변경 :wq!             두 번째로는, V$LIBRARY 자료사전을 통해 RELOAD 비율을 분석할 수 있습니다. RELOADS 비율이란 PINS 컬럼에 대한 RLOADS 컬럼의 백분율을 RELOADS 비율이라고 합니다. 이것은 라이브러리 캐시영역의 크기가 너무 작을 때 사용자의 SQL 구문분석 정보가 로더되지 못하고 가장 오래된 SQL문 정보를 라이브러리 캐시영역에서 삭제한 후 그 문장이 다시 실행될 때 RELOADS 컬럼 값이 증가하게 됩니다. 또는 구문 분석된 SQL문에서 사용된 객체가 다른 사용자에 의해 삭제된 상태에서 다시 SQL문이 재실행되면 발생합니다. PINS는 구문 분석되어 라이브러리 캐시영역에 저장될 수 있었던 SQL 정보를 의미합니다. PINS 컬럼에 대한 RELOADS 컬럼의 백분율이 1% 미만일 때 좋은 성능을 기대할 수 있습니다. 다음은 PINS에 대한 RELOADS의 비율을 확인하는 방법입니다.               SQL> SELECT sum(pins), sum(reloads), sum(reloads) / sum(pins)   FROM v$libraycache     WHERE namespace = 'SQL AREA';           SUM(PINS) SUM(RELOADS) SUM(RELOADS)/SUM(PINS) 36299 45 0.001239704   PINS에 대한 RELOADS의 비율이 1% 미만일 때 라이브러리 캐시영역의 크기가 SQL 파싱 정보를 저장하기에 충분하다는 것을 의미합니다. 1% 이상이라면 성능이 저하될 수 도 있다는 것을 의미합니다.         마지막으로, V$LIBRARYCACHE 자료사전을 통해 SQL문에서 사용된 객체가 다른 사용자들에 의해 얼마나 자주 삭제되거나 변경되었는지를 분석하는 방법입니다. 주로, ANALYZE 명령어, ALTER, DROP 명령어에 의해 테이블 구조가 변경되는 경우에 발생합니다               SQL> SELECT namespace, invalidations   FROM v$libraycache   WHERE namespace = 'SQL AREA';     NAMESPACE INVALIDATION SQL AREA 5       INVALIDATION 컬럼의 값이 높게 출력되거나 계속적으로 증가 값을 보인다면 공유 풀 영역이 작아서 성능이 저하되고 있음을 의미합니다. 즉, 불필요한 재파싱, 재로딩 작업이 발생할 가능성이 높아지는 것 입니다. 이러한 결과에 의해 튜닝이 필요하다면 다음과 같은 파라메터 값을 높게 설정하셔야 합니다.                   SHARED_POOL_SIZE = [크기] 문법 SHARED_POOL_RESERVED_SIZE = [크기]   SHARED_POOL_RESERVED_MIN_ALLOC = [크기]           [SHARED_POOL_SIZE] 파라메트는 공유 풀 영역의 전체크기를 결정하는 파라메터입니다. 만약, V$LIBRARY 자료사전을 통해 분석된 결과값이 튜닝 기준값에 적합하지 않다면 라이브러리 캐시영역의 크기를 크게 할당해 주어야 하는데 오라클 데이터베이스에서는 이 영역만 크게 할당해 주는 파라메터는 없으며 공유 풀 영역의 크기를 크게 할당해주면 오라클 서버가 적절한 크기로 라이브러리 영역의 크기를 할당해 줍니다. [SHARED_POOL_RESERVED_SIZE] 파라메트는 PL/SQL 블록으로 실행된 SQL문의 구문분석 정보를 저장할 때 사용되는 공유 풀 영역입니다. 일반적인 SQL문과는 달리 PL/SQL 블록들은 문장의 크기가 매우 크기 때문에 구문 분석된 결과 또한 매우 크기 마련입니다. 이러한 결과를 라이브러리 캐시영역에 저장하다 보면 연속된 메모리 공간이 없는 경우(단편화-FRAGMENTATION 현상) 분석결과가 여러 개의 조각으로 쪼개어져 저장됨으로서 단편화 현상을 더 유발시킬 수 있습니다. 결국, 이러한 단편화 현상은 데이터 검색 시 성능을 저하시키기 때문에 미리 아주 큰 PL/SQL 믈록의 구문분석 정보를 저장할 수 있는 충분한 메모리 공간을 확보한다면 이런 문제를 해결할 수 있을 것입니다. 이때 사용하는 파라메터이며 기본값은 SHARED_POOL_SIZE의 10%니며 최대값은 SHARED_POOL _SIZE 값의 1/2 입니다. 만약, 사용자의 개발환경이 PL/SQL 블록으로 개발된 애플리케이션 프로그램이 많다면 이 파라메터 값을 충분하게 설정해 주는 것이 좋습니다. 이 파라메터는 V$SHARED_POOL_RESERVED 자료사전의 REQUEST_FAILURES 컬럼의 값이 0의값이 아니거나 계속 증가값을 보일 때 높은 값을 설정해 주어야 좋은 성능을 기대할 수 있습니다. 반대로, REQUEST_FAILURES 컬럼의 값이 계속 0이면 메모리의 낭비가 초래될 수 있으므로 파라메터의 값을 낮게 설정해 주어야 합니다. [SHARED_POOL_RECERVED_MIN_ALLOC] 파라메터는 PL/SQL 블록의 크기가 이 파라메터에 지정된 크기 이상되어야 RESERVED 영역에 저장될 수 있습니다.           <잠깐>공유 풀 영역의 단편화(Fragmentation) 현상을 제거하는 방법           시스템을 사용하다 보면 메모리 영역과 디스크 영역에서 많은 읽기/쓰기 작업이 발생합니다. 제한된 공간을 계속적으로 사용하다 보면 공간에 대한 단편화(FRAGMENTATION) 현상이 발생할 수 밖에 없습니다. 문제는 단편화 현상으로 인해 효율적인 공간관리가 되지 않고 성능까지 저하되는 현상이 유발되는 것 입니다. 오라클 데이터베이스의 SGA 영역 또한 단편화 현상으로 인해 메모리 공간이 낭비되거나 SQL문의 성능저하를 유발시킬 수 도 있습니다. 문제를 해결할 수 있는 가장 효과적인 방법은 가끔 데이터베이스를 재 시작하는 방법이지만 실제 기업환경에서는 거의 불가능한 일 입니다. 다음과 같이 ALTER SYSTEM 명령어를 사용하면 데이터베이스의 재 시작없이 공유 풀 영역을 클리어(Clear) 시킬 수 있습니다. SQL> ALTER SYSTEM SET FLUSH SHARED_POOL;             데이터 딕셔너리 캐시 영역의 튜닝 분석           오라클 데이터베이스를 설치하면 기본적으로 생성되는 테이블, 뷰, 패키지, 프로시저, 함수 등을 데이터 딕션어리(DATAT DICTIONARY)라고 합니다. 그리고, 데이터베이스를 시작(STA RTUP)하거나, SQL문을 실행하면 일부 데이터 딕션어리(V$~로 시작되는 뷰) 정보가 오라클 서버에 의해 공유 풀 영역의 데이터 딕션너리 캐시영역에 로드 됩니다. 또한, 개발자 또는 데이터베이스 관리자가 튜닝 및 관리의 목적으로 자료사전을 참조하기도 합니다. 이러한 자료사전이 읽혀질 때마다 공유 풀 영역의 데이터 딕션너리 영역에 관련정보를 로더하게 됩니다. V$~로 시작되는 일부 자료사전은 데이터베이스의 마운트 단계에서 만 질의할 수 있지만 대부분의 자료사전(DBA_, USER_, X$~)들은 데이터베이스를 오픈 단계까지 시작해야 만 질의할 수 있습니다. 그럼, 데이터 딕션너리 영역에 대한 튜닝방법에 대해서 알아보겠습니다. 사용자가 참조하는 자료사전이 질의될 때마다 그 정보를 데이터 딕션너리 영역에서 참조할 수 있다면 자료사전을 보다 빠르게 조회할 수 있을 것이고 그렇지 못하다면 자료사전을 데이터 파일로부터 읽어서 데이터 딕션너리 영역으로 로더해야 할 것입니다. 결론적으로, 디스크로부터 자료사전이 읽혀지는 것보다는 데이터 딕션너리 영역으로부터 읽혀지는 것이 성능에 유리하다는 의미입니다 다음은 자료사전을 통해 라이브러리 영역을 분석하는 방법입니다. V$ROWCACHE 자료사전을 참조하면 이 영역에 대한 튜닝 결과를 확인할 수 있습니다.                       SQL> SELECT sum(gets), sum(getmisses), sum(gets)/sum(getmisses)   FROM v$rowcache;       SUM(GETS) SUM(GETMISSES) SUM(GETS)/SUM(GETMISSES) 2126 902 2.3569   [GETS] 컬럼은 사용자가 자료사전을 질의했을 때 데이터 딕션너리 영역으로 자료를 요청했던 수를 의미합니다. [GETMISSES] 컬럼은 자료요청을 했지만 데이터 딕션너리 영역으로부터 자료를 얻지 못했던 수를 의미합니다.           대부분의 자료사전을 빠르게 검색하기 위해서는 [GETS] 컬럼에 대한 [GETMISSES] 컬럼의 백분율이 2% 미만이어야 하고 아주 큰 자료사전 테이블에 대한 검색을 빠르게 하기 위해서는 15% 미만이어야 이 영역에 대한 성능을 기대할 수 있습니다. 만약, 이러한 조건을 만족하지 못한다면 공유 풀 영역의 크기를 더 크게 설정해야 합니다. 라이브러리 영역과 같이 이 영역 만 크게 할당해 주는 파라메터는 없으며 공유 풀 영역의 크기를 크게 할당해주면 오라클 서버가 적절한 크기로 데이터 딕션너리 영역의 크기를 할당해 줍니다.           <조치사항>           $ cd $HOME/dbs $ vi init<SID>.ora ….. SHARED_POOL_SIZE = 32000000 ß 이전 값보다 더 큰 값으로 변경 :wq!                       2) 동일한 SQL문 작성을 위한 표준화 작업을 한다.           V$LIBRARY 자료사전을 통해 개발자가 실행한 SQL문이 LIBRARY CACHE 공간에서 어떻게 저장되고 관리되는지를 자세히 알아 보았습니다. 그렇다면, 개발자가 실행하는 SQL문의 성능을 극대화 시키고 메모리 공간도 효과적으로 사용할 수 있는 방법은 없을까요 ?? 첫 번째 방법이 공유 풀 영역의 크기를 충분히 할당 해 주는 것이라면 두 번째 방법은 모든 SQL문이 동일하게 작성되어 실행되게 함으로서 불필요한 PARSING과 불필요한 RE-LOADING을 피하게 하는 것입니다. 자~ 그렇다면 동일한 SQL문을 실행할 수 있는 가장 최선의 방법은 무엇일까요 ? 프로젝트를 하다 보면 다양한 개성과 창조적인 감성을 가진 인간이 만들어 내는 SQL문을 동일하게 만든다는 것은 말처럼 그리 쉬운 일은 아닐 것 입니다. 가장 최선의 방법은 모든 개발자들이 정해진 규칙에 의해 SQL문을 작성할 수 있도록 표준화를 하는 것 입니다. 일반적으로 정보 시스템을 개발하기 전에 애플리케이션 프로그래밍에 대한 "코딩 표준화", 사용자와의 인터페이스를 효과적으로 하기 위한 "화면 디자인 표준화" 등이 같은 맥락에서 이해할 수 있는 내용입니다. 우리가 이러한 표준화를 하는 궁극적인 목적은 크게 2가지로 요약할 수 있습니다. 첫 번째 목적은 약속된 프로그래밍 규칙을 통해 향후 유지 보수적인 측면을 고려한 것 입니다. 만약, 아무런 규칙없이 프로그래밍을 한다면 너무나도 다양한 유형의 프로그램들이 생성되어 자신이 개발하지 않은 프로그램 소스는 제대로 이해하지 못하는 문제로 인해 유지보수에 어려움을 겪게될 것 입니다. 두 번째 문제는 성능 문제입니다. 다양한 소스코드를 만들게 되면 프로그래밍이 어려워질 뿐 아니라 불필요한 메모리와 디스크 공간의 낭비를 초래할 수 있기 때문입니다. 다음 예제는 시스템 개발초기에 프로젝트 관리자 또는 데이터베이스 분석/설계자에 의해 동일한 SQL문을 만들어 내기 위한 표준화 작업의 일부입니다. 이러한 표준화작업은 사용자의 개발환경에 맞게 적절하게 변형하셔야 하며 새로운 내용의 추가 및 삭제가 추가적으로 필요합니다. 그럼, 지금부터 저를 따라 오세요.         SQL문의 대문자 또는 소문자로 통일하십시오.           사용자의 애플리케이션 프로그램 속에는 수많은 SQL문이 저장되어 있습니다. 시스템 개발은 여러 명이 한 팀이 되어 진행되는데 프로그래머들은 각각 개성과 사고를 가진 인격체이기 때문에 어떤 약속을 해두지 않는다면 어떤 사람은 대문자로, 어떤 사람은 소문자로 SQL문을 작성할 것이고 결국 동일한 SQL문을 만들어 내지 못합니다.           SQL> SELECT * FROM emp; SQL> UPDATE emp SET sal = sal 8 1.1 WHERE deptno = 10;         변수명은 SQL문, 객체명, 변수명과 구분하기 위해 소문자로 작성하십시오.           변수명은 SQL문, 객체명, 컬럼명과 구분하기 위해 소문자로 작성하십시오. SQL문의 빠른 이해와 컬럼 간의 구분을 쉽게 하기 위해 필요합니다.           SQL> SELECT RESNO, HNAME INTO :ls_ResNo, :ls_HName   FROM EMPTBL   WHERE HNAME LIKE '홍길동';         다른 스키마의 테이블을 호출할 때는 SCHEMA명.테이블명 으로 작성하십시오.           다른 스키마의 테이블을 호출할 때는 "Schema명.테이블명"으로 작성하십시오. 만약, 시노늄을 작성하여 사용할 때에는 시노늄 명을 결정하는 네이밍 룰(NAMING RULE)을 잘 작성하여 이름 만 봐도 이해할 수 있도록 해 주십시오.           SQL> SELECT RESNO, HNAME   FROM SCOTT.EMP   WHERE RESNO = 1234;         SQL문의 각 단어의 여백은 한 칸으로 하십시오.           SQL문의 각 단어와 단어의 여백은 1칸으로 작성하십시오. 콤마(comma)는 앞 문자와는 간격을 두지 말고 뒷 문자와는 간격을 1칸으로 작성하십시오. 또한, 컬럼 리스트는 되도록 모두 한 줄에 기술하십시오. (2줄 이상일 경우는 첫줄, 첫 컬럼에 맞추어 작성하십시오.)           SQL> SELECT RESNO, HNAME INTO :ls_ResNo, :ls_HName   FROM EMPTBL   WHERE HNAME LIKE '홍길동';         SQL문 내의 변수명은 변수 선언 기준 안에 따르며 해당 컬럼명을 접두어와 경합하여 사용하십시오.           SQL문 내의 변수 명은 변수선언 기준 안에 따르며 해당 컬럼명을 접두어와 결합하여 사용하십시오. 또한, WHERE절의 비교 처리에는 변수를 사용하십시오.           string gi_resno // 사원번호(G는 글로벌 변수, L은 로컬변수,   // i는 정수타입, s는 문자타입) sql> SELECT RESNO, HNAME   FROM EMPTBL   WHERE RESNO = :ii_resno;         SQL문의 SELECT, FROM, WHERE절은 각 라인의 선두에 사용하십시오.           SQL> SELECT RESNO, HNAME   FROM EMPTBL   WHERE RESNO = :ii_resno;                   자주 사용하는 SQL문을 캐싱한다.           라이브러리 캐시영역을 통해 성능을 향상시킬 수 있는 세 번째 방법은 자주 실행되는 SQL문의 구문 분석정보를 라이브러리 영역에 캐싱 해 두었다가 문장이 재실행될 때 마다 재사용하게 하는 방법입니다. 불필요한 구문 분석단계를 피할 수 있기 때문에 SQL문의 성능을 향상을 시킬 수 있습니다. 다음 내용은 라이브러리 캐시영역의 성능과 관련된 파라메터들 입니다.         CURSOR_SPACE_FOR_TIME = FALSE           만약, 2명의 사용자에 의해 동일한 SQL문이 실행된다면 공유 풀 영역에 있는 구문 분석된 SQL TEXT 정보를 공유하게 될 것입니다. 그러나, PRIVATE SQL AREA 라는 영역에는 2명의 사용자가 실행한 구문 분석된 정보가 각각 저장되게 됩니다. 이 파라메터 값을 TRUE로 설정하면 PRIVATE SQL AREA에 공유 풀 영역의 구문 분석정보를 참조하는 커서가 하나라도 있으면 AGING 알고리즘에 의해 공유 풀 영역으로부터 제거되지 않고 계속 상주할 수 있도록 해 줍니다. 이 파라메터의 기본값은 FALSE 입니다. 만약, 개발자들이 실행하는 SQL문에서 같은 문장이 반복적으로 실행되는 경우가 많다면 이 파라메터를 TRUE 설정하는 것이 성능향상에 유리합니다.         SESSION_CACHED_CURSORS = 0           오라클사에서 제공하는 FORMS 개발 툴 또는 C, COBOL, FORTRAN과 같은 3GL 언어로 시스템을 개발하는 경우, 하나의 조회화면에서 또 다른 조회화면으로 전환하는 프로그램을 구현하다 보면 메인 화면에서 다음 화면으로 이동할 때 메인 프로그램에서 실행되었던 SQL문의 구문 분석정보가 라이브러리 캐시영역으로부터 완전히 제거될 수가 있습니다. 서버 프로그램을 조회한 후 다시 메인 프로그램으로 돌아갔을 때 이미 실행했던 SQL문을 다시 구문 분석하게 된다면 불필요한 작업으로 인해 SQL문의 성능은 저하될 수 있을 것 입니다. 이 파라메터는 하나의 세션에서 캐싱할 수 있는 커서의 수를 지정할 수 있습니다. 이 파라메터의 기본값은 0 입니다         CLOSE_CACHED_OPEN_CURSORS = FALSE           개발자가 실행한 SQL문의 트랜잭션이 COMMIT문을 만나는 순간 관련된 구문 분석정보도 라이브러리 캐시영역으로부터 함께 제거하는 파라메터입니다. 이 파라메터의 기본값은 FALSE 입니다         OPEN_CURSORS = 300           하나의 세션에서 동시에 오픈할 수 있는 커서의 수를 지정할 때 사용합니다. 커서를 너무 많이 오픈하게 되면 그 만큼 많은 커서 정보가 라이브러리 캐시영역에 로더되어야 하기 때문에 성능에 도움이 되지 않습니다. 이 파라메터의 기본값은 오라클 데이터베이스 버전에 따라 틀리며 9i인 경우 300 입니다. 다음은 INIT<SID>.ORA 파일에 파라메터들을 등록하는 방법입니다.           $ cd $HOME/dbs $ vi init<SID>.ora ….. CURSOR_SPACE_FOR_TIME = TRUE SESSION_CACHED_CURSORS = 10 CLOSE_CACHED_OPEN_CURSORS = TRUE OPEN_CURSORS = 500 :wq!                         자주 사용하는 PL/SQL/ 블록을 캐싱한다.           프로젝트를 수행하다 보면 아주 복잡한 스토어드 프로시저, 함수, 패키지, 트리거 등을 생성하게 됩니다. 하지만, 이런 PL/SQL 블록들은 너무 커서 실행할 때 마다 라이브러리 캐시영역에 로더 되었다가 다시 제거되는 현상이 반복적으로 발생할 수 밖에 없습니다. 이런 문제가 자주 발생하면 라이브러리 캐시영역에는 단편화 현상이 발생하게 되고 데이터베이스를 사용하는 전체 사용자들의 성능이 저하되게 됩니다. 오라클 사에서는 자주 실행되는 PL/SQL 블록, 시퀀스 등을 라이브러리 영역에 캐싱해 둘 수 있도록 DBMS_SHARED_POOL 패키지를 제공합니다. 다음 예제를 따라 해 보십시오. 먼저, 라이브러리 영역에 캐싱되어 있는 PL/SQL 블록의 정보를 참조하는 자료사전은 V$DB_OBJECT_CACHE 입니다. v$db_object_cache 자료사전을 조회한 후, 그 중 하나를 공유 풀 영역에 상주 시켜봅시다.           SQL> > select name, type, kept   from v$db_object_cache   where type in ( 'PACKAGE','PROCEDURE', 'TRIGGER', 'PACKAGEBODY');   NAME TYPE KEPT   ----------------------------- <- 캐싱된 PL/SQL 블록 정보가 없습니다.           일단, 애플리케이션에서 자주 실행되는 스토어드 프로시저를 생성한 후 공유 풀 영역에 로더 시켜 보겠습니다. 라이브러리 캐시영역에 로더시킬 때는 DBMS_SHARED_KEEP 패키지를 사용하고 제거할 때는 DBMS_SHARED_UNKEEP 패키지를 사용합니다.           SQL> CONNECT scott/tiger SQL> CREATE OR REPLACE PROCEDURE check_sawon   (v_emp_on) IN emp.empno%TYPE   IS   BEGIN     DELETE FROM emp WHERE empno = v_emp_no;   END check_sawon;   / SQL> execute DBMS_SHARED_POOL.KEEP('SCOTT.CHECK_SAWON');   <- CHECK_SAWON 프로시저를 공유 풀 영역에 상주합니다.     SQL> select type, name   from v$db_object_cache   where type in ('PACKAGE','PROCEDURE','TRIGGER', 'PACKAGE BODY')     END check_sawon;     NAME TYPE KEPT ----------------------------------------------------- CHECK_SAWON PROCEDURE Y   <-KEPT = Y의 의미는 CHECK_SAWON 프로시저가 캐싱되어 있음을 의미합니다     SQL> exit           STATS.SQL 스크립트를 실행하면 위와 같이 ANALYZE 명령어에 의해 분석된 테이블의 구조를 확인할 수 있습니다. 앞에서도 언급했듯이 튜닝을 잘 하기 위해서는 데이터베이스의 구조를 잘 알아야 합니다.