적용 대상:

Oracle Database - Enterprise Edition - 버전 11.2.0.1 to 11.2.0.4 [릴리즈 11.2]
이 문서의 내용은 모든 플랫폼에 적용됩니다.

목적

이 문서에는 11.2.0.1에서 11.2.0.2 또는 11.2.0.N  이후 버전으로 out-of-place 수동 데이터베이스 업그레이드를 수행하는 방법이 나와 있습니다.

해결책

11.2.0.2 및 이후 패치셋은 전체 릴리스입니다. 11.2 패치셋 설치 프로그램은 기존 11.2 설치를 업데이트하지 않습니다. 
설치 프로세스는 out-of-place 업그레이드를 수행하든 in-place 업그레이드를 수행하든 새 설치를 수행합니다. 
(11.2 Upgrade Guide 3장 "Known Issue When Starting an In-Place Upgrade for Release 11.2.0.2" 참조)

11.2.0.2부터 패치셋을 두 가지 방법으로 적용할 수 있습니다:

• Out-of-place 업그레이드 (권장)
• In-place 업그레이드
•  
  "In-Place" 업그레이드는 옵션이지만 권장되지 않습니다.
  이 업그레이드는 수행할 수 있지만 11.2.0.2 용 설치 프로그램을 실행하는 것만으로 11.2.0.1을 가리킬 수 없습니다. 
  
  "In-Place" 업그레이드 단계는 업그레이드 가이드(아래 참조)에 설명되어 있습니다.
  http://download.oracle.com/docs/cd/E11882_01/server.112/e17222.pdf
  섹션 3-39

자세한 내용은 다음 노트를 참조하십시오:

참조: 이 문서에서 참조가 11.2.0.1을 나타낼 때 현재 설치된 11.2(11.2.0.1-11.2.0.N) 버전을 나타내는 것일 수 있습니다. 참조가 11.2.0.2를 나타낼 때 11.2 패치셋(11.2.0.2-11.2.0.N)의 새 버전일 수 있습니다.


 1 단계
======
11.2.0.2 이상 RDBMS 소프트웨어를 다운로드합니다.
See NOTE:753736.1 - Quick Reference to Patchset Patch Numbers 를 참조하십시오.
여러 파일이 필요할 수 있으므로 패치셋 추가 정보에서 다운로드에 필요한 파일에 대한 전체 지침을 검토합니다. 각 패치셋에 대한 추가 정보에는 특정 지침이 나와 있습니다.

다음도 검토하십시오:

2 단계
======
최신 11.2 RDBMS 소프트웨어를 새로운ORACLE_HOME에 설치합니다..

11.2 설치부터 모든 기본 RDBMS 구성 요소가 설치됩니다. 유일한 옵션은 구성 요소가 링크 설정되거나 링크 해제(활성 상태이며 사용할 수 있는지)되었는지 여부입니다. 사용자 정의 설치는 사용할 수 없습니다.

데이터베이스가 Oracle 텍스트 테마를 사용 중이거나 Oracle Multimedia 데모 및 기타 데모를 설치하려는 경우 이 항목은 기본 설치에 포함되어 있지 않기 때문에 11.2.0.2 예제 CD(이전에는 Companion CD)를 설치해야 합니다.

"opatch lsinventory -detail" 을 이전 및 새로운 ORACLE_HOME 에 대해 실행하여 설치된 제품을 비교할 수 있습니다.

다음 사항도 참조하십시오.
/opt/oracle 을 ORACLE_BASE 로 사용 중인 경우 rootupgrade.sh 가 실패합니다. 자세한 내용은 다음을 참조하십시오:

3 단계
======
최신 11.2 RDBMS 소프트웨어를 설치한 후 실행 중인 이전 인스턴스에 대해 11.2.0.1 인스턴스를 이전 ORACLE_HOME 및 spool/run 11.2.0.2 $ORACLE_HOME/rdbms/admin/utlu112i.sql 스크립트를 사용하여 시작합니다.

사전 업그레이드 정보툴 실행은 DBUA 를 사용하여 업그레이드하거나 수동으로 업그레이드하는 경우 필수 항목입니다. 그렇지 않은 경우 오류가 발생할 수 있습니다:

최신 11.2 릴리스로 업그레이드하기 전에 11.2 사전 업그레이드 스크립트 스풀 파일을 검토하고 문제를 수정해야 합니다.


알려진 문제
++++++++++++++++
11.2.0.2 는 시간대 버전 14 를 사용합니다. 11.2.0.1 은 시간대 버전 11 을 사용합니다. 이후 버전은 시간대 데이터 이후 버전에서도 사용될 수 있습니다.

최신 홈의 DBUA 는 "시간대 버전 및 TIMESTAMP WITH TIME ZONE 데이터 업그레이드" 상자체크박스가 선택된 경우 포함된 버전으로 시간대를 자동으로 업그레이드합니다.

수동으로 업그레이드하는 경우:
BMS_DST 패키지를 사용하여 최신 11.2 버전으로 업그레이드한 후 시간대 버전을 업그레이드하거나 11.2.0.1 시간대를 해당 시간대 버전으로 업그레이드합니다. 업그레이드하기 전에 11.2.0.1 시간대 버전을 다른 버전으로 업그레이드하려는 경우 utlu112i.sql 을 재실행해야 합니다.

다음을 참조하십시오:

4 단계
======
dba_registry 의 모든 구성 요소가 적합하며 부적합한 데이터 딕셔너리 객체가 dba_objects 에 없는지를 확인하려면 아래 My Oracle Support 에서 dbupgdiag.sql 스크립트를 실행합니다.

dbupgdiag.sql 스크립트에서 부적합한 객체를 보고하는 경우 $ORACLE_HOME/rdbms/admin/utlrp.sql 을 여러 번 실행하여 부적합한 객체 수에 변경이 없을 때까지 데이터베이스의 부적합한 객체를 검증합니다.

부적합한 객체를 검증한 후 데이터베이스에서 dbupgdiag.sql 을 다시 한 번 재실행하고 모두 정상인지 확인합니다.

5 단계
======
일괄 처리 및 cron 작업 모두를 사용 안함으로 설정한 다음 데이터베이스 전체 백업을 수행합니다.

예제
----------
데이터베이스의 전체 백업을 수행하려면 다음 단계를 완료합니다:

참조: Oracle Database Backup and Recovery User's Guide

참고: 전체 콜드 백업의 경우 먼저 데이터베이스를 종료하십시오.

6 단계
=======
데이터베이스를 정상적으로 종료합니다.

7 단계 (윈도우즈 플랫폼만 해당)
========================

1) 환경 변수 ORACLE_HOME 이 11.2.0.1 설치를 가리키도록 설정합니다.

2) ORACLE_HOME 셋으로 11.2.0.1 Oracle Database 서비스를 정지하여 11.2.0.1 설치를 가리키도록 합니다.

3) %ORACLE_HOME%\bin\ ORADIM 이진을 사용하여 11.2.0.1 Oracle 서비스를 삭제합니다.

4) 환경 변수 ORACLE_HOME 이 11.2.0.2 설치를 가리키도록 설정합니다.

5) 11.2.0.1%ORACLE_HOME%/database 에서 11.2.0.2 %ORACLE_HOME%/database 로 init.ora/spfile 및 비밀번호 파일(orapw<sid>.ora)을 복사합니다.

6) 11.2.0.1 %ORACLE_HOME%\network\admin(또는 $TNS_ADMIN) 위치에서 11.2.0.2 %ORACLE_HOME%\network\admin(또는 %TNS_ADMIN%) 위치로 구성 파일(listener.ora, sqlnet.ora, tnsnames.ora 등)을 복사합니다.

7) DB 콘솔/DB 콘트롤이 구성되어 있고 사용되는 경우 다음 디렉토리 두 개와 해당 콘텐츠를 11.2.0.1에서 11.2.0.2로 복사합니다. DB 콘솔/DB 콘트롤이 구성되지 않은 경우 이 디렉토리가 존재하지 않을 수 있습니다.
           ORACLE_HOME/<hostname_dbname>
           ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_<hostname_dbname>


8) 11.2.0.2 를 사용하여 명령 프롬프트에서 Oracle 11.2.0.2 서비스를 생성합니다.

예제:

8 단계 (Unix 및 Linux)
=================
대상 11.2.0.2 ORACLE_HOME을 구성합니다.

1) 환경 변수 ORACLE_BASE, ORACLE_HOME, PATH, NLS_10 및 LIBRARY_PATH 가 11.2.0.2 설치를 가리키도록 설정되었는지 확인합니다.

ORACLE_SID 를 업그레이드 할 11.2.0.1 DB 이름으로 설정합니다.

etc/oratab 파일은 Oracle Database 11g 릴리스 2(11.2.0.2) Oracle 홈을 가리킵니다.

2) Database Vault 를 사용 안함으로 설정합니다.

3) 11.2.0.1 $ORACLE_HOME/dbs 에서  11.2.0.2 $ORACLE_HOME/dbs 로 init.ora/spfile 및 비밀번호 파일(orapw<sid>.ora)을 복사합니다.

4) 11.2.0.1 $ORACLE_HOME/network/admin(또는 $TNS_ADMIN) 위치에서 11.2.0.2 $ORACLE_HOME/network/admin(또는 $TNS_ADMIN) 위치로 구성 파일(listener.ora, sqlnet.ora, tnsnames.ora 등)을 복사합니다.

5) DB 콘솔/DB 콘트롤이 구성되어 있고 사용되는 경우 다음 디렉토리 두 개와 해당 콘텐츠를 11.2.0.1 에서 11.2.0.2 로 복사합니다. DB 콘솔/DB 콘트롤이 구성되지 않은 경우 이 디렉토리가 존재하지 않을 수 있습니다.
           ORACLE_HOME/<hostname_dbname>
           ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_<hostname_dbname>

<hostname_dbname>의 실제 이름을 지정합니다.

6) Oracle Database 11g 릴리스 2(11.2)에 대해 COMPATIBLE 초기화 파라미터가 올바르게 설정되어 있는지 확인하십시오. COMPATIBLE 이 올바로 설정되어 있지 않을 경우 사전 업그레이드 정보 툴에서 데이터베이스 섹션에 경고가 표시됩니다.

7) 초기화 파라미터의 값을 사전 업그레이드 정보툴에서 가리키는 최소값 이상으로 조정합니다. JVM 을 설치한 고객의 경우 업그레이드하기 전에 java_pool_size 및 shared_pool_size 를 250MB 이상으로 설정해야 합니다. 그렇지 않으면 다음 오류와 함께 JVM 업그레이드가 실패할 수 있습니다:

9 단계
======
데이터베이스를 수동으로 업그레이드합니다.

1) sqlplus 를 시작하고 새롭게 설치된 (타겟) $ORACLE_HOME/rdbms/admin 의 catupgrd.sql 스크립트를 실행합니다.

2) catupgrd.sql 스풀 파일에 오류가 있는지 확인합니다.

3) 일반 모드에서 데이터베이스를 재시작합니다.

4) SQL> @$ORACLE_HOME/rdbms/admin/catuppst.sql;

5) SQL> @$ORACLE_HOME/rdbms/admin/utlrp.sql;

6) dbupgdiag.sql 스크립트를 실행(Note: 556610.1 참조)하고 dba_registry 의 모든 구성 요소가 적합하며 dba_objects 에 부적합한 객체가 없는지 확인합니다.



사후 업그레이드 단계
===================

1) 오라클 클러스터웨어 구성을 업그레이드 합니다.

당신이 오라클 클러스터웨어를 사용한다면, 데이터베이스에 대한 오라클 클러스터웨어 요소들을 업그레이드 해야만 합니다.

오라클 데이터베이스 11g 릴리즈 2 (11.2.0.2) 가 출시되면서, 업그레이드 명령은 실행되고 있는 소프트웨어의 버전을 업그레이드하여 구성합니다.

업그레이드 할 릴리즈에 대해서 srvctl 을 수행하십시오. 예를 들면,

srvctl upgrade database
srvctl upgrade 데이터베이스 명령어는 데이터베이스의 구성과 명령어가 수행된 데이터베이스 홈 버전에 대한 모든 서비스들을 업그레이드 합니다.


구문과 옵션
다음과 같이 srvctl upgrade database command 를 사용하십시오:

srvctl upgrade database -d db_unique_name -o Oracle_home
Table A-161 srvctl upgrade database Options

옵션에 대한 설명
-d db_unique_name
 데이터베이스에 대한 유일한 이름
 
-o Oracle_home
ORACLE_HOME 의 위치

2) DBMS_DST를 사용하여 시간대를 최신 버전으로 업그레이드 합니다.

3) 복구 카탈로그를 업그레이드합니다.
복구 카탈로그 업그레이드 및 UPGRADE
CATALOG 명령에 대한 전체 정보는 Oracle Database Backup and Recovery User's Guide 에서 
프로시저를 설명하는 항목을 참조하십시오.

4) DBMS_STATS 패키지에서 생성한 통계 자료 테이블 업그레이드

프로시저를 사용하여 통계 자료 테이블을 생성한 경우 다음 프로시저를 실행하여 이 테이블을 업그레이드합니다:

예제에서 SCOTT 은 통계 자료 테이블의 소유자이며 STAT_TABLE 은 
통계 자료 테이블 이름입니다. 각 통계 자료 테이블에 대해 이 프로시저를 수행합니다.

5) Oracle Database Vault 를 사용으로 설정하고 DV_PATCH_ADMIN 롤을 취소합니다.
Oracle Database Vault 를 사용하는 경우 데이터베이스를 업그레이드하기 전에 
사용 안함으로 설정하도록 지침이 제공됩니다. 이제:

Database Vault 를 사용으로 설정합니다.

SYS 계정에 대한 Database Vault DV_PATCH_ADMIN 롤을 취소합니다.

참조
===========
Oracle Database
Upgrade Guide
11g Release 2 (11.2)
E17222-06                             <October 2010                         <
Chapter 3
       Upgrading to the New Release

http://download.oracle.com/docs/cd/E11882_01/server.112/e17222.pdf

5. Oracle Warehouse Builder (OWB) component in database will not be upgraded as part of database upgrade. There are few post upgrade steps to be carried to upgrade the component.

Details in Oracle® Warehouse Builder Release Notes 11g Release 2 (11.2)

적용 대상:

Oracle Database - Enterprise Edition - 버전 10.2.0.1 to 11.2.0.3 [릴리즈 10.2 to 11.2]
이 문서의 내용은 모든 플랫폼에 적용됩니다.

목적

Many RAC instability issues are attributed to a rather short list of commonly missed Best Practices and/or Configuration issues.  The goal of this document it to provide a easy to find listing of these commonly missed Best Practices and/or Configuration issues with the hope to prevent instability caused by these issues.

범위

이 문서의 내용은 RAC이 구현된 모든 환경에 적용된다.

상세 내역

1. 최신 Patchset Update (PSU) 를 적용하라

적용 가능한 플랫폼:  모든 플랫폼

이유?: PSU는 CPU 패치 계획을 좀더 향상시키기 위해 10.2.0.4 이상 버전에서 도입되었다. PSU는 분기마다 출시되며 최근의 CPU를 포함하고 있고 거기에 추가적으로, 운영 환경의 안정화에 중요하다고 여겨지는 개별패치(fix)들을 포함하고 있다. 만약 신규 설치건이라면, 반드시 해당 버전의 가장 최신 PSU를 적용해야 한다. 기존 시스템의 경우, 지속적이고 정기적으로 최신의 PSU를 적용하는 방식으로 운영 환경을 유지보수 하도록 계획해야 한다. 오라클 Support에 문의되고 버그로 판명되는 이슈들중에는 최신의 PSU에서 이미 해결된 알려진 버그인 경우가 많다. 그리고, 윈도우즈 환경에서는 누적 번들 패치가 PSU보다는 좀더 자주 출시가 되는데, 이 경우의 최신의 PSU는, PSU 출시 분기 동안에 나왔던 윈도우즈 번들 패치에 포함된다. .

추가 정보: PSU에 관한 더 많은 정보는 아래 문서들을 참조하라:
Document 854428.1 Intro to Patch Set Updates (PSU)
Document 1082394.1 11.2.0.X Grid Infrastructure PSU Known Issues
Document 756671.1 Oracle Recommended Patches -- Oracle Database
Document 161549.1 Oracle Database, Networking and Grid Agent Patches for Microsoft Platforms

2.  UDP 버퍼 크기가 적당한 지 확인하라

적용 가능한 플랫폼: Windows를 제외한 모든 플랫폼

이유?: 인터커넥트(interconnect)는 RAC 데이터베이스에서 생명선과 같다. 그러나 UDP send/receive 버퍼에 할당된 버퍼 공간이 적당치 않다면 인터커넥트 성능에 상당히 영향을 끼치며, 이것은 곧 클러스터 안정성에 문제가 될 수 있다. 

추가 정보: 적절한 UDP 버퍼 크기 산정을 위한 더 많은 정보는 아래 문서들을 참조하라:
Document 181489.1 Tuning Inter-Instance Performance in RAC and OPS
Document 563566.1 gc lost blocks diagnostics

3.  모든 10.2 와 11.1 클러스터에는 DIAGWAIT 값을 13으로 설정하라

적용 가능한 플랫폼:  Windows를 제외한 모든 플랫폼

이유?:  10gR2 (10.2.x)와 11gR1 (11.1.x)에서 OPROCD 데몬을 위한 기본 마진값은 겨우 500 밀리세컨드 (0.5초)이다. 이 마진은 매우 바쁜 시스템의 경우 너무 작은 값이며 그로 인해 과부하시 가짜 리부팅 (false reboot)이 발생할 수 있다. diagwait 설정을 13으로 변경하는 것은 OPROCD의 마진을 10,000 밀리세컨드 (10초)로 변경해주며 이는 곧 바쁜 시스템에 대해 가짜 리부팅 상황을 피하게끔 충분한 마진을 부여하는 것이다. 게다가, diagwait 설정은, 만약 reboot이 발생하는 경우에 추가 디버깅해볼 수 있는 정보를 trace 화일에 쓰는 시간을 좀더 부여하게끔 해준다. 이 변경은 patchset에는 포함될 수 없다. 그 이유는 클러스터 전체의 중단이 필요하기 때문입니다. 모든 10gR2 와 11gR1 클러스터에서는 이 값을 13으로 설정할 것을 강력히 권고하는 바이다. 새로 설치하는 경우라면 인스톨 직후에 이 diagwait 값을 변경해야 한다. 기존에 설치된 시스템의 경우는 다운타임을 계획해서 필히 적용해야 한다. 현재 설정은 아래 명령어로 확인할 수 있다:

추가 정보: DIAGWAIT에 관한 더 많은 정보는 아래 문서들을 참조하라:
Document 559365.1  Using Diagwait as a diagnostic to get more information for diagnosing Oracle Clusterware Node evictions
Document 567730.1  Changes in Oracle Clusterware on Linux with the 10.2.0.4 Patchset

4.  리눅스 환경에서는 HugePages를 구현하라

적용 가능한 플랫폼:  모든 LINUX 64-Bit 플래폼

이유?:  HugePages를 구현하면 리눅스 환경에서 커널의 성능이 크게 향상된다. 이는, 더 많은 메모리를 가지고 있는 시스템의 경우 특히 그렇다. 일반적으로 12GB RAM 이상을 가진 시스템의 경우, HugePages를 적용하기에 적합한 대상이다. 더 많은 RAM을 가진 시스템일수록 HugePages 활성화를 통해서 얻는 이득이 많다. 왜냐하면 시스템이 가진 메모리가 많을 수록 커널이 그만한 양의 메모리에 대해 page table을 맵핑하고 유지해야 하는 작업량이 증가하기 때문이다. HugePages를 활성화하는 것은 커널이 관리해야 할 page수를 줄여주기 때문에 시스템이 훨씬 효율적으로 동작할 수 있게 해준다. 만약 HugePages가 활성화돼 있지 않다면, 경험적으로 봤을 때 커널이 오라클 클러스터웨어나 Real Application Clusters 데몬보다 선점하면서 인스턴스 또는 노드 eviction을 일으키는 사례가 종종 나타난다.

추가 정보: 
Document 361323.1  HugePages on Linux: What It Is... and What It Is Not...
Document 401749.1  Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration

5.  OS Watcher 및 Cluster Health Monitor를 구현하라

적용 가능한 플랫폼s:  모든 플랫폼

이유?: 안정성 측면과 직접 관련은 없지만, OS Watcher와 Cluster Health Monitor는 OS 상태 및 노드 및 인스턴스 eviction을 유발하는 잠재적 근본 원인을 규명하는 데 있어 매우 유용한 툴이다. 어떤 문제가 처음 발생한 이후 그 문제를 진단할 수 있는 적절한 데이터가 있다면 그 자료를 확보하는 것은 문제 원인을 규명하는 시간을 단축하게끔 해주며, 그렇게 함으로써 향후 장애를 예방할 수 있을 것이다. 이런 종류의 대부분의 3rd party 데이터 수집툴은 수집 주기가 너무 길며 (예를 들어, 5분 또는 그 이상), 그 툴들의 자료를 해석하기가 어렵거나 적절한 데이터를 수집하지 않는 경우도 있다. OS Watcher는 30초 (기본값) 간격으로 기본적인 OS 정보를 수집하는 매우 간단하고 가벼운 툴이다. Cluster Health Monitor는, 모든 플랫폼에 쓸 수 있는 것은 아니지만, 좀더 세부 수준까지 실시간으로 데이터를 수집함으로써 OS Watcher를 보완한다. 어떤 이슈에 대해 보다 빠른 진단과 디버깅을 수월하게 하는데 있어, 이 유틸리티들을 하나 또는 둘다 항상 모든 클러스터 노드에서 수행해 두는 것은 매우 중요한다.

추가 정보:
Document 301137.1 OS Watcher User Guide
Document 1328466.1 Cluster Health Monitor (CHM) FAQ
Document 580513.1 How To Start OSWatcher Black Box Every System Boot (Linux specific)

6.  OS설정에 대해서는 Best Practice를 따르라

(시스템 안정화를 위한 메모리 튜닝에 관한 백서로서, 오라클과 IBM이 공동 작업함)

적용 가능한 플랫폼:  모든 AIX 버전

이유?: 백서 Oracle Real Application Clusters on IBM AIX Best practices in memory tuning and configuring for system stability는 양 벤더의 상호 경험치에 기반한 최적 사례를 함께 테스트하고 엮은 매우 좋은 문서이다. 경험적으로 RAC/AIX 클러스터에서 안정성 문제의 대부분은 이 문서에서 권고한대로 설정하여 해결할 수 있었다. AIX 버전 6.1은 이런 많은 권고안들을 기본값으로 포함하고 있으나, 이 설정들은 OS버전 또는 오라클 버전에 상관없이 모든 RAC 클러스터 상에서 확인돼야 한다.

추가 정보:
백서 다운로드: http://www.oracle.com/technetwork/database/clusterware/overview/rac-aix-system-stability-131022.pdf
Document 811293.1  RAC Assurance Support Team: RAC Starter Kit and Best Practices (AIX)

7.  AIX 플랫폼에서 과도한 페이징/스와핑 이슈를 방지하기 위해, 적절한 APAR가 제대로 설정돼 있는 지 확인하라

적용 가능한 플랫폼: 모든 AIX 버전

이유?: 경험적으로 이 사안은 AIX환경에 영향을 미치는 매우 흔한 이슈이다. 이 이슈의 본질상, 이 문제에 민감한 사람이라면 완전히 시스템 hang이 되는 상황을 경험했을 것이다. RAC이 아닌 환경에서는 이것은 인위적 개입 없이는 계속 시스템 hang 상황에 빠져 있게 된다. 그러나 RAC 환경에서는 해당 노드의 응답 없음으로 인해 노드 eviction 상황으로 전개된다. 

추가 정보: 이 문제에 대한 추가 정보는, 오라클 문서 Document 1088076.1 Paging Space Growth May Occur Unexpectedly on AIX Systems With 64K (medium) Pages Enabled 를 확인하라

8.  NUMA 패치를 적용하라

적용 가능한 플랫폼:  모든 플랫폼

이유?:  10.2.0.4 과11.1.0.7 RDBMS 패치셋에는, NUMA (OS와 하드웨어 종속적)를 지원하는 플랫폼 상에서는 NUMA 최적화가 활성화돼 있었다. (NUMA를 지원하는 시스템 상의) RDBMS 코드내에 이 NUMA가 활성화 돼 있어서 데이터베이스의 성능 저하와 불안정을 야기하는 버그가 되어 왔었다. 10.2.0.4 과11.1.0.7에 NUMA 최적화와 관련있는 증상/이슈에 대한 전체 목록이 Document 759565.1에 나와 있다. 만약 10.2.0.4 또는 11.1.0.7 을 운영하고 있다면, NUMA관련 이슈를 적극적으로 해결하기 위해 Patch 8199533 를 적용할 것을 강력히 권고하는 바이다.

9.  윈도우즈의 비상호적 데스크탑 힙 메모리 (noninteractive Desktop Heap)를 늘려라

적용 가능한 플랫폼:  Windows 플랫폼 

이유?: 윈도우즈 클러스터에서 비상호적 데스크탑 힙 메모리의 기본 크기가 충분치 않음이 확인되었다. 이는 애플리케이션 연결성 이슈 및 클러스터의 일반적인 불안정(hang 및 crash)을 초래한다. 이 이슈에 대해 적극적으로 대처하기 위해, 비상호적 데스크탑 힙 메모리를 1MB까지 늘려줄 것을 권고한다. 권고치 1MB 보다 크게 늘려주는 것은, 마이크로소프트 측의 관여 없이는 수행하지 말아야 한다. 

추가 정보: 비상호적 데스크탑 힙 메모리를 어떻게 조정할 수 있는 지에 대한 설명은 Document 744125.1에서 볼 수 있다.

10.  RACcheck 유틸리티를 수행해라

적용 가능한 플랫폼:  Linux (x86 and x86_64), Solaris SPARC 그리고 AIX (bash shell 환경)

이유?: RACcheck은 Real Application Clusters (RAC), 오라클 클러스터웨어 (CRS), Automatic Storage Management (ASM), 그리고 Grid Infrastructure (GI) 에서 다양하고 중요한 설정 정보들을 살펴볼 수 있도록 개발된 RAC 설정 감사툴이다. 이 유틸리티는, RAC Assurance 개발/지원팀에서 유지 관리되고 있는 일련의 RAC/오라클 클러스터웨어 Best Practice와 Starter Kit 문서 (Document 810394.1 참조)에서 정의된 Best Practice 와 성공 요소들을 점검하는데 이용할 수 있다. RACcheck가 지원되는 플랫폼에서 RAC을 운영하고 있는 고객이라면 클러스터 안정성에 영향을 줄 수 있는 잠재적인 설정 이슈를 식별하기 위해서 이 툴을 활용할 것을 독려하는 바이다.

추가 정보: RACcheck에 대한 더 많은 정보 및 이 유틸리티를 내려받기 위한 링크는 Document 1268927.1에서 확인할 수 있다.

11. NTP를 slewing 옵션으로 설정하라.

적용 가능한 플랫폼:  모든 Linux 및 Unix 플랫폼.

이유?: slew 옵션이 없는 경우는 시간 불일치가 특정 임계치(플랫폼마다 다름)를 넘어설 때 NTP가 시스템 글럭을 앞으로 또는 뒤로 건너뛸 수 있다. 뒤로 시간을 많이 건너 뛰게 되면 클러스터웨어는 checkin이 없다고 보고 노드 eviction을 하게 될 수도 있다. 이러한 이유로, eviction 상황을 방지하기 위해 클럭이 시간을 동기시킬 수 있도록 NTP를 slew time (speed up 또는 speed down)으로 설정할 것을 강력히 권고하는 바이다. 각 플랫폼에서 NTP time slewing을 어떻게 구현하는 지, 아래 각 플랫폼별 RAC and Oracle Clusterware Best Practices and Starter Kit 문서를 참조하라 (아래).

WORKSHOP : SHARED POOL

04 커서공유

(1) 커서란?

공유 커서 (shared cursor) : 라이브러리 캐시에 공유돼 있는 Shared SQL Area
세션 커서 (session cursor) : Private SQL AREA에 저장된 커서
애플리케이션 커서 (application cursor) : 세션 커서를 가리키는 핸들

그림 7

라이브러리 캐시에 공유돼 있는 커서를 실행할 때는 우선 PGA 영역에 메모리를 할당
Private SQL area 라고 하는데 ， Persistent Area 와 Runtime Area로 나뉜다.
Shared SQL Area를 읽어 커서를 실행하는 데 필요한 정보들을 Private SQL Area에 담고，
공유 커서를 가리키는 포인터를 유지한다.그리고 커서의 상태정보도 관리한다.
커서 를 실행하기 위한 이런 준비과정을 "커서를 오픈한다" 고 표현하고，
PGA에 저장된 커서 정보(즉,파싱된 SQL문과 문장을 수행하능데 필요한 기타 정보)를 또
한 '커서' 라고부른다.

PGA에 있는 커서를 핸들링하려면 JAVA, VB, Pro*C, PL!SQL 같은 클라이언트 애플리케이션에도
리소스를 할당

(2) 커서 공유

######################
커서 공유 테스트
######################

-- sys유저 접속
SQL> grant select_catalog_role to scott;
Statement Processed.

SQL> alter system flush shared_pool;
Statement Processed.

-- SCOTT유저 접속
SQL> select /* cursor test */ empno, ename, job, sal, deptno 
from emp 
where empno = 7788;

EMPNO ENAME      JOB       SAL       DEPTNO 
----- ---------- --------- --------- ------ 
 7788 SCOTT      ANALYST        1000     20

1 rows selected.

SQL> select sql_id, parse_calls, loads, executions, invalidations 
      , decode(sign(invalidations), 1, (loads-invalidations),0) reloads 
from v$sql 
where sql_text like '%cursor test%' 
and sql_text not like '%v$sql%';

SQL_ID        PARSE_CALLS LOADS     EXECUTIONS INVALIDATIONS RELOADS   
------------- ----------- --------- ---------- ------------- --------- 
896pksq7c53f2           1         1          1             0         0

1 rows selected.

SQL> select /* cursor test */ empno, ename, job, sal, deptno 
from emp 
where empno = 7788;

EMPNO ENAME      JOB       SAL       DEPTNO 
----- ---------- --------- --------- ------ 
 7788 SCOTT      ANALYST        1000     20

1 rows selected.

SQL> select /* cursor test */ empno, ename, job, sal, deptno 
from emp 
where empno = 7788;

EMPNO ENAME      JOB       SAL       DEPTNO 
----- ---------- --------- --------- ------ 
 7788 SCOTT      ANALYST        1000     20

1 rows selected.

SQL> select sql_id, parse_calls, loads, executions, invalidations 
      , decode(sign(invalidations), 1, (loads-invalidations),0) reloads 
from v$sql 
where sql_text like '%cursor test%' 
and sql_text not like '%v$sql%';

SQL_ID        PARSE_CALLS LOADS     EXECUTIONS INVALIDATIONS RELOADS   
------------- ----------- --------- ---------- ------------- --------- 
896pksq7c53f2           3         1          3             0         0

1 rows selected.

• parse_calls: 라이브러리 캐시에서 SQL 커서를찾으려는요청 횟수
• loads: 하드파싱을 거친 SQL 실행계획을 라이브러리 캐시에 적재한 횟수
• executions : SQL을 수행한 횟수
• invalidations : 커서가 무효화된 횟수. 커서가 참조하고 있는 오브젝트에 중요한 변
  화가일어났음을의미함

#####################################
다른세션 접속후 커서공유 테스트
#####################################

SQL> select /* cursor test */ empno, ename, job, sal, deptno 
from emp 
where empno = 7788;

EMPNO ENAME      JOB       SAL       DEPTNO 
----- ---------- --------- --------- ------ 
 7788 SCOTT      ANALYST        1000     20

1 rows selected.


SQL> select /* cursor test */ empno, ename, job, sal, deptno 
from emp 
where empno = 7788;

EMPNO ENAME      JOB       SAL       DEPTNO 
----- ---------- --------- --------- ------ 
 7788 SCOTT      ANALYST        1000     20

1 rows selected.

SQL> select sql_id, parse_calls, loads, executions, invalidations 
      , decode(sign(invalidations), 1, (loads-invalidations),0) reloads 
from v$sql 
where sql_text like '%cursor test%' 
and sql_text not like '%v$sql%';

SQL_ID        PARSE_CALLS LOADS     EXECUTIONS INVALIDATIONS RELOADS   
------------- ----------- --------- ---------- ------------- --------- 
896pksq7c53f2           5         1          5             0         0

1 rows selected.

다른 세션에서 같은 SQL을 수행할 때도 이전 세션에서 적재한 커서를 재사용했음을
알수있다.

###################################
통계 재생성후 커서공유 테스트
###################################

SQL> execute DBMS_STATS.GATHER_TABLE_STATS  
(ownname => USER, tabname => 'EMP' 
,no_invalidate => FALSE 
);

PL/SQL executed.
SQL Execution Time > 00:00:05.367

SQL> select /* cursor test */ empno, ename, job, sal, deptno 
from emp 
where empno = 7788;

EMPNO ENAME      JOB       SAL       DEPTNO 
----- ---------- --------- --------- ------ 
 7788 SCOTT      ANALYST        1000     20

1 rows selected.

SQL Execution Time > 00:00:00.062
Total Elapsed Time > 00:00:00.062

SQL> select /* cursor test */ empno, ename, job, sal, deptno 
from emp 
where empno = 7788;

EMPNO ENAME      JOB       SAL       DEPTNO 
----- ---------- --------- --------- ------ 
 7788 SCOTT      ANALYST        1000     20

1 rows selected.

SQL Execution Time > 00:00:00.062
Total Elapsed Time > 00:00:00.062

-------------------------[Start Time: 2014/03/04 18:39:12]-------------------------
SQL> select sql_id, parse_calls, loads, executions, invalidations 
      , decode(sign(invalidations), 1, (loads-invalidations),0) reloads 
from v$sql 
where sql_text like '%cursor test%' 
and sql_text not like '%v$sql%';

SQL_ID        PARSE_CALLS LOADS     EXECUTIONS INVALIDATIONS RELOADS   
------------- ----------- --------- ---------- ------------- --------- 
896pksq7c53f2           2         2          2             1         1

1 rows selected.

SQL Execution Time > 00:00:00.031
Total Elapsed Time > 00:00:00.047

쿼리를 다시 수행한 후에 v$sql을 다시 조회해 보면， 적재 횟수가 아래처럼 2로 증가한
것을볼수있다.

라이브러리 캐시에 있는 커서틀이 여러 세션에 의해 공유되면서 반복 재사용되는 것
공유된 커서를 사용할 때는 최적화 및 Row-Source Generation 단계를 생략하고
곧바로 실행 단계로 넘어가므로 보다 효율적이고 빠르게 SQL을 수행한다

커서가 공유되려면 커서를 식별하는 키 값이 같아야 함
-> 라이브러리 캐시에서 커서를 식별하기 위해 시용되는 키 값은 'SQL 문장 그 자체'
-> SQL문을 구성하는 전체 문자열이 이름 역할을 한다는 뜻
-> SQL_ID와 SQL FULLTEXT는 1:1로 대응
SQL문 중간에 작은 공백문자 하나만 추가하더라도 서로 다른 SQL 문장으로 인식해 새로운
SQL_ID를발급받게 된다. 즉 커서가 공유되지 않는다.

(3) Child 커서를 공유하지 못하는 경우

8QL마다 하나의 Parent 커서를 가지며， Child 커서는 여러 개일 수 있다.
실제 수행에 필요한 정보는 Child 커서에 담기므로 적어도 한 개의 Child 커서를 갖는다.
v$sqlarea는 Parent 커서 정보를 보여주고36) ' v$sql은 Child 커서 정보를 보여준다.
아래는 SC0TT과 HR 스키마 각각에 EMP 테이블을 만들고 각 계정으로 로그인 해서
select * from emp 쿼리를 수행한 후에 v$sqlarea와 v$sql을 쿼리했을 때의 결과를 보
이고 있다.

##########################
자식커서의 공유 테스트
##########################

C:\WINDOWS\system32>sqlplus "/as sysdba"


SQL> conn /as sysdba
연결되었습니다.
SQL> create table hr.emp as select * from scott.emp;

테이블이 생성되었습니다.

SQL> alter system flush shared_pool;

시스템이 변경되었습니다.

SQL> conn scott/tiger
연결되었습니다.
SQL> select * from emp where empno=7698;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7698 BLAKE      MANAGER         7839 81/05/01       2850                    30

SQL> conn hr/hr
연결되었습니다.
SQL> select * from emp where empno=7698;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7698 BLAKE      MANAGER         7839 81/05/01       2850                    30


== v$sqlarea는 부모커서를 확인
SQL>  conn /as sysdba
연결되었습니다.
SQL> select sql_id, version_count, optimizer_mode, address, hash_value
  2  from v$sqlarea
  3  where sql_text like 'select * from emp where%'
  4  and sql_text  not like 'v$sql';

SQL_ID        VERSION_COUNT OPTIMIZER_ ADDRESS  HASH_VALUE
------------- ------------- ---------- -------- ----------
5tq0u8y4zd3ta             2 ALL_ROWS   3D9C5BFC 2314637098


== v$sql는 자식커서를 확인
SQL> select sql_id, child_number, optimizer_mode, address, hash_value, parsing_user_id
  2  from v$sql
  3  where sql_text like 'select * from emp where%'
  4   and sql_text  not like 'v$sql';

SQL_ID        CHILD_NUMBER OPTIMIZER_ ADDRESS  HASH_VALUE PARSING_USER_ID
------------- ------------ ---------- -------- ---------- ---------------
5tq0u8y4zd3ta            0 ALL_ROWS   3D9C5BFC 2314637098              84
5tq0u8y4zd3ta            1 ALL_ROWS   3D9C5BFC 2314637098              85


== v$sqlarea 에 동일문장의 버전이 몇개인지 볼수 있다.
select * from v$sqlarea order by version_count desc;

하나의 SQL문장이 여러개 Child 커서를 갖게 되는 대표적인 이유
1. SQL에서 참조하는 오브젝트명이 같지만 SQL을 실행한 사용자에 따라 다른 오브젝트를 가리킬때
2. 참조 오브젝트가 변경돼 커서가 무효화되면 이후 그 커서를 처음 사용하려는 세션에
의해 다시 하드파싱돼야 하는데 특정 세션이 아직 기존 커서를 사용 중(Pin)일 때
3. 옵티마이저 모드를 비롯해 옵티마이저 관련 파라미터가 다를 때
4. 입력된 바인드 값의 길이가 크게 다를 때
5. NLS 파라미터를 다르게 설정했을 때
6. SQL 트레이스를활성화했을때

해당 딕셔너리를 참조해라. ====> V$SQL_SHARED_CURSOR

SQL> conn scott/tiger
연결되었습니다.
SQL> conn /as sysdba
연결되었습니다.
SQL> alter system flush shared_pool;

시스템이 변경되었습니다.

SQL> conn scott/tiger
연결되었습니다.
SQL> alter session set optimizer_mode=first_rows;

세션이 변경되었습니다.

SQL> select * from emp where empno=7698;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7698 BLAKE      MANAGER         7839 81/05/01       2850                    30

SQL> alter session set optimizer_mode=all_rows;

세션이 변경되었습니다.

SQL> select * from emp where empno=7698;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7698 BLAKE      MANAGER         7839 81/05/01       2850                    30


SQL> conn /as sysdba
연결되었습니다.
SQL> select sql_id, version_count, optimizer_mode, address, hash_value
  2  from v$sqlarea
  3  where sql_text like 'select * from emp where%'
  4  and sql_text  not like 'v$sql';

SQL_ID        VERSION_COUNT OPTIMIZER_ ADDRESS  HASH_VALUE
------------- ------------- ---------- -------- ----------
5tq0u8y4zd3ta             2 ALL_ROWS   3D9C5BFC 2314637098



SQL> select child_number, child_address, optimizer_mode_mismatch, optimizer_mismatch
  2  from V$SQL_SHARED_CURSOR
  3  where SQL_ID = '5tq0u8y4zd3ta'
  4  and ADDRESS  = '3D9C5BFC';

CHILD_NUMBER CHILD_AD O O
------------ -------- - -
           0 37DF4684 N N
           1 37FF5A94 Y N


SQL> select *
  2  from V$SQL_SHARED_CURSOR
  3  where SQL_ID = '5tq0u8y4zd3ta'
  4  and ADDRESS  = '3D9C5BFC';

SQL_ID        ADDRESS  CHILD_AD CHILD_NUMBER U S O O S L F E B P I S T A B D L T B I I R L I O E M U
 T N F A I T D L D B P C S C P T M B M R O P M F L P L A F L R L H P B
------------- -------- -------- ------------ - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
5tq0u8y4zd3ta 3D9C5BFC 37DF4684            0 N N N N N N N N N N N N N N N N N N N N N N N N N N N N
 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N
5tq0u8y4zd3ta 3D9C5BFC 37FF5A94            1 N N N N N N N N N N N N N N N N N N N N N N N N N N N N
 N N N N N N N N N N N N N N N N N N N N Y N N N N N N N N N N N N N N

Version Count 수치가 높은 SQL 일수록 커서를 탐색하는 데 더 많은 시간을 소비하므
로 library cache 래치에 대한 경합 발생 가능성을 증가시킨다.

v$sql_shared_cursor 다이나믹 뷰는 새로운 Child 커서가 왜 기존 Child 커서와 공유
못하는지 확인

(4) Parent 커서를 공유하지 못하는 경우

1. 공백 문자 또는 줄바꿈
SELECT * FROM CUSTOMER;
SELECT *   FROM CUSTOMER;
2 . 대소문자구분
SELECT * FROM CUSTOMER;
SELECT * FROM Customer;
3. 태이블 Owner 명시
SELECT * FROM CUSTOMER;
SELECT * FROM HR.CUSTOMER;
4. 주석 (Comment)
SELECT * FROM CUSTOMER;
SELECT /* 주석문 */ * FROM CUSTOMER;
5. 용티마이져 힌트 사용
SELECT * FROM CUSTOMER;
SELECT /*+ all_rows */ * FROM CUSTOMER;
6. 조건 절 비교값
SELECT * FROM CUSTOMER WHERE CUST_ID = '0000001';
SELECT * FROM CUSTOMER WHERE CUST_ID = '0000002';
이 외에도 더 다양한 케이스가 있을 것이다. 1. 2. 4번은 그 실행계획이 100% 같다.

그럼에도 문자열을 조금 다르게 기술했다는 이유 때문에 서로 다른 SQL로서 각각
하드파싱을 일으카고 서로 다른 공간을 차지하면서 Shared Pool을 낭비하게 된다. 이런
비효율을 줄이고 공유 가능한 형태로 SQL을 작성하려면 개발 초기에 SQL 작성 표준을
정해 이를 준수하도록 해야 한다.

5번은 의도적으로 실행계획을 달리 가져가려는 것이므로 논외로 하고 라이브러리 캐시
효율과 직접 관련이 큰 것은 6번 같은 패턴이다. 즉 조건절에 바인드 변수를 사용하지 않
고 서로 다른 Literal 값으로 문자열을 대체하는 경우다.
만약 OLTP성 업무를 처리하는 애플리케이션에서 6번과 같은 패턴으로 SQL을 개발한
다변 결코 좋은 성능을 보장받을 수 없다. 개별 쿼리 성능으로 보면 잘 느끼지 못하지만
동시 트랜잭션이 몰리는 peak 시간대에 시스템을 장애 상황으로 몰고 가는 주범이다.

==================================================================================================================
공유풀은 힙(heap)으로 불리는 OS메모리 공간으로 구성됨.
힙(heap)은 헤더와 하나이상의 메모리익스텐트로으로 구성됨.
메모리익스텐트는 지속적으로 할당과 반납이 반복되며 여러개 작은조각으로 나누어짐.
메모리 영역이 작은단위로 나누어 지는 것을 공유풀단편화(FRAGMENTATION)이라 함.
단편화로 인해 쪼개진 영역은 청크라고 불리며 프리리스트에 의해 관리됨.
한번 사용된 청크는 다시 프리리스트에 등록되기 전까지 공유풀 LRU리스트에서 관리됨
LRU알고리즘을 이용하여 청크의 재사용률을 높이기 위해서임.

공유풀에 메모리 할당과정
1. 새로운 SQL에 대해 파스 수행하려면 힙영역 새로운 빈공간 할당받아야함.
2. 프리리스트에서 필요한 크기의 프리청크 서칭
3. 프리리스트 서칭후 있으면 힙영역 할당. 없으면 LRU리스트 사용가능 청크를 서칭
4. LRU리스트에도 없으면 4031에러 발생후 SQL파스 실패

예> SQL파스를 위해 256바이트가 필요할�
1. 쉐어드풀 래치획득후 프리리스트로 부터 256바이트의 청크를 검색.

• 이과정에서 래치를 획득하지 못하면 latch:shared pool 대기 이벤트를 발생시키며 획득가능할때까지 대기.
  2. 256바이트의 프리청크를 찾았다면 해당 청크를 익스텐트에 할당.
• 이과정에서 256바이트의 프리청크가 없어서 찾지 못했다면 더큰크기의 프리청크를 검색
  3. 400바이트의 프리청크를 찾았다면 필요한 크기의 256바이트와 144바이트의 크기로 쪼갬.
  256바이트 청크를 익스텐트에 할당. 144바이트의 청크는 프리리스트에 등록
• 이과정에서 256바이트 보다 더 큰 프리청크를 찾지 못했다면 공유풀 LRU리스트로 부터 핀이 해제된 청크중 256바이트 보다 큰 청크를 검색 후 프리리스트 등록
  4. 공유풀LRU리스트 검색시 필요한 크기의 청크를 확인 못할시 4031에러와 SQL파스 실패

프리리스트에서 프리청크를 검색후 할당받기까지 모든단계에서 shared pool 래치를 할당 받아야 한다.
청크의 할당 해제가 빈번히 발생 한다면 청크는 더욱 작게 쪼개져 관리되어야 할 청크의 수가 증가 한다.
프리리스트를 검색하는 시간을 증가시키고 쉐어드풀 레치에 대한 경합을 증가시켜 성능저하를 유발 하며
4031에러를 발생시킨다.
==================================================================================================================

05 바인드 변수의 중요성

바인드 변수 사용에 따른 효과는 아주 분명
커서를 많이 생성하지 않고 하나를 반복 재사용하므로 메모리 사용량과 파싱 소요 시간을 불인다
궁극적으로 시스템전반의 메모리와 CPU사용률을 낮춰 데이터베이스 성능과 확장성을 높이는데 기여
특히 동시 사용자 접속이 많을 때는 그 영향력이 절대적이다

#################################
바인드 변수 사용의 필요성 테스트
#################################

SQL> create table t as select * from dba_objects;

테이블이 생성되었습니다.

SQL> update t set object_id = rownum;

72471 행이 갱신되었습니다.

SQL> commit;

커밋이 완료되었습니다.

SQL> create unique index t_idx on t (object_id);

인덱스가 생성되었습니다.

SQL> analyze table t compute statistics;

테이블이 분석되었습니다.



set timing on 
declare 
  type rc is ref cursor; 
  l_rc rc;
  l_object_name t.object_name%type;
begin 
  for i in 1..20000
  loop
   open l_rc for
    'select /* TEST1 */ object_name
     from t
     where object_id = :x' using i;
   fetch l_rc into l_object_name;
   close l_rc;
  end loop;
end;
/
SQL> set timing on
SQL> declare
  2    type rc is ref cursor;
  3    l_rc rc;
  4    l_object_name t.object_name%type;
  5  begin
  6    for i in 1..20000
  7    loop
  8     open l_rc for
  9      'select /* TEST1 */ object_name
 10       from t
 11       where object_id = :x' using i;
 12     fetch l_rc into l_object_name;
 13     close l_rc;
 14    end loop;
 15  end;
 16  /

PL/SQL 처리가 정상적으로 완료되었습니다.

경   과: 00:00:00.79
SQL>

SQL> col sql_text format a50
SQL> select sql_text,loads,parse_calls,executions,fetches
  2  from v$sql
  3  where sql_text like '%TEST1%'
  4  and sql_text not like '%v$sql%'
  5  and sql_text not like 'declare%';

SQL_TEXT                                                LOADS PARSE_CALLS EXECUTIONS    FETCHES
-------------------------------------------------- ---------- ----------- ---------- ----------
select /* TEST1 */ object_name      from t      wh          1       20000      20000      20000
ere object_id = :x


경   과: 00:00:00.03


declare 
  type rc is ref cursor; 
  l_rc rc;
  l_object_name t.object_name%type;
begin 
  for i in 1..20000
  loop
   open l_rc for
    'select /* TEST2 */ object_name
     from t
     where object_id = '||i ;
   fetch l_rc into l_object_name;
   close l_rc;
  end loop;
end;
/

SQL> declare
  2    type rc is ref cursor;
  3    l_rc rc;
  4    l_object_name t.object_name%type;
  5  begin
  6    for i in 1..20000
  7    loop
  8     open l_rc for
  9      'select /* TEST2 */ object_name
 10       from t
 11       where object_id = '||i ;
 12     fetch l_rc into l_object_name;
 13     close l_rc;
 14    end loop;
 15  end;
 16  /

PL/SQL 처리가 정상적으로 완료되었습니다.

경   과: 00:00:07.54
SQL>


select sql_text,loads,parse_calls,executions,fetches
from v$sql
where sql_text like '%TEST2%'
and sql_text not like '%v$sql%'
and sql_text not like 'declare%';


select /* TEST2 */ object_name      from t      wh          1           1          1          1
ere object_id = 19110

select /* TEST2 */ object_name      from t      wh          1           1          1          1
ere object_id = 18922

select /* TEST2 */ object_name      from t      wh          1           1          1          1
ere object_id = 18476

select /* TEST2 */ object_name      from t      wh          1           1          1          1
ere object_id = 19948

select /* TEST2 */ object_name      from t      wh          1           1          1          1
ere object_id = 19051


2091 개의 행이 선택되었습니다.

경   과: 00:00:01.25

바인드 변수 사용원칙을 잘 지커지 않으면 라이브러리캐시 경합때문에 시스템 정상가동이
어려운 상황에 직면할 수 있다. cursor_sharing 파라미터를 변경 긴급처방

06 바인드 변수의 부작용과 해법

바인드 변수를 사용하면 최초 수행할 때 최적화를 거친 실행계획을 캐시에 적재하고，
실행시점에는 그것을 그대로 가져와 값을 다르게 바인딩하면서 반복 재사용하게 된다.
여기서， 변수를 바인딩하는 시점이 (최적화 시점보다 나중인) 실행시점이라는 사실을 아
는 것이 중요하다. 즉， SQL을 최적화하는 시점에 조건절 컬럼의 데이터 분포도를 활용하
지 못하는 문제점을 갖는다.

(1) 바인드 변수 Peeking

오라클은 9i부터 바인드 변수 Peeking 기능을 도입
SQL이 첫 번째 수행되면서 하드파싱될 때 함께 딸려 온 바인드 변수 값을 살짝 훔쳐 보고
그 값에 대한 컬럼 분포를 이용해 실행계획을 결정
문제점
잘못 수립된 실행계획 때문에 느린 애플리케이션도 문제지만 시스템 운영자 입장에서는
자주 실행계획이 바뀌어 어제와 오늘의 수행속도가 급격히 달라지는 현상

(2) 적응적 커서 공유(Adaptive Cursor Sharing)

오라클 11g도입된 이 기능이 작동하려면 기본적으로 조건절 컬럼에 히스토그램이 생성돼 있어야 한다.
그 상태에서，옵티마이저가 바인드 변수 값에 따라 실행계획을 달리 가져갈 필요가 있다고 판단면
SQL커서에 대해서 이 기능이 활성화
문제점
새로운 실행계획을 만들지 않는다
기존 커서의 실행계획을 그대로 사용해보고 성능이 나쁘다고 판단되면 모드를 전환

(3) 입력 값에 따라 SQL 분리

인텍스 액세스 경로(access Path)로서 중요하고 조건절 컬럼의 데이터 분포가 균일하지 않
은 상황에서 바인드 변수 시용에 따른 부작용을 피하려면 바인딩 되는 값에 따라 실행계
획을 아래와 같이 분리하는 방안을 고려해야 한다.

select /*+ full(a) */ *
from 아파트매물 a
where :city in ('서울','경기')
and 도시 = :city
union all
select /*+ index(a) */ *
from 아파트매물 a
where :city not in ('서울','경기')
and 도시 = :city;

문제점
union all을 이용해 SQL을 길게 작성하면 Parse 단계의 CPU 사용률을 높임.
-라이브러리 캐시는 문장을 저장함
-Syntax를 체크함
-파싱트리를 만들어 Semantic 체크도함
union all을 이용해 SQL을 길게 작성하면 Execute단계에서도 CPU 사용률을 높임.
-I/O를 일으키지 않을 뿐 실제실행은 일어나기 때문

(4) 예외적으로，Literal 상수값 사용

게다가 배치 프로그램이나 정보계 시스템에서 수행되는 SQL은 대부분 Long
Running 쿼리이므로 파싱 소요시간이 쿼리 총 소요시간에서 차지하는 비중에 매우 낮
고, 사용빈도도낮아하드파싱에 의한라이브러리 캐시 부하를크게 염려할펼요가없다.

07 세션 커서 캐싱

세션 커서 (session cursor)란
Shared Pool에 위치한 공유 커서 (shared cursor)를 실행하려고 PGA로 인스턴스화한 것

쿼리를 수행한 후에 커서를 닫으면,
세션 커서를 위해 할당된 메모리는 물론 공유 커서를 가리키는 포인터까지바로 해제,
그 다음에 같은 SQL을 수행하면 커서를 오픈하기 위한 라이브러리 캐시 탐색작업을 다시 해야 함.

세션 커서 캐싱(Session Cursor Cache)란
오라클은 자주 수행하는 SQL에 대한 세션 커서를 세션 커서 캐시 (Session cursor Cache)에 저장

커서를 닫는 순간 해당 커서의 Parse Call 횟수를 확인해 보고 그 값이 3보다 크거나 같으면,
세션 커서를 세션 커서 캐시로 옮긴다. 세션 커서 캐시에는 SQL 텍스트와 함께 공유 커서를
가리키는 포인터를 저장
커서는 닫힌 상태지만 공유 커서에 대한 참조를 유지하기 때문에 다음 수행 시 더 빨리
커서를 오픈(자주 수행되는 SQL문에 의해 발생하는 라이브러리 캐시 부히를 경감)

즉，
SQL문을 파싱해서 구문을 분석하고,
라이브러리 캐시에서 커서를 찾는 과정에서 소모되는 CPU 사용량을 줄일 수 있음은 물론，
소프트 파싱 과정에 발생하는 래치 요청 횟수를 감소시키는 효과

세션 커서 캐시 내에서도 LRU 알고리즘을 시용함으로써 새로운 엔트리를 위한 공간이 필요할 때마다
기존 세션 커서 중 사용 빈도가 낮은것부터 밀어낸다.

session_cached_cursors는 얼마나 많은 세션 커서를 캐싱할지를 지정하는 파라미터
로서 ， 이 값을 O보다 크게 설정하면 Parse Call이 발생할 때마다 라이브러리 캐시를 탐색
하기 전에 세션 커서 캐시를 먼저 살펴본다.

• users_opening: 공유 커서를 참조하고 있는 세션 커서의 수를 보여준다. 수행을 마
  쳐 커서 를 닫았더라도 참조를 버리지 않은 채 세션 커서 캐시로 옮겨진다면 여기에
  집계된다 .
• users_executing : 해당 SQL을 현재 실행 중인， 즉 커서가 열려있는 세션 커서의
  수를 보여준다. DML일 때는 수행을 마칠 때 커서가 자동으로 닫히지만 select문은
  EOF(End of Fetch)에 도달했을 때 커서가 닫힌다

SQL> alter session set session_cached_cursors = 10;

세션이 변경되었습니다.

SQL> alter system flush shared_pool;

시스템이 변경되었습니다.

SQL> select * from scott.emp where empno=7788 ;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM
---------- ---------- --------- ---------- -------- ---------- ----------
    DEPTNO
----------
      7788 SCOTT      ANALYST         7566 87/04/19       3000
        20


SQL> select parse_calls, users_opening, users_executing from v$sql
  2  where sql_text = 'select * from scott.emp where empno=7788 ';

PARSE_CALLS USERS_OPENING USERS_EXECUTING
----------- ------------- ---------------
          1             0               0

SQL> select * from scott.emp where empno=7788 ;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM
---------- ---------- --------- ---------- -------- ---------- ----------
    DEPTNO
----------
      7788 SCOTT      ANALYST         7566 87/04/19       3000
        20


SQL> select parse_calls, users_opening, users_executing from v$sql
  2  where sql_text = 'select * from scott.emp where empno=7788 ';

PARSE_CALLS USERS_OPENING USERS_EXECUTING
----------- ------------- ---------------
          2             0               0

SQL> select * from scott.emp where empno=7788 ;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM
---------- ---------- --------- ---------- -------- ---------- ----------
    DEPTNO
----------
      7788 SCOTT      ANALYST         7566 87/04/19       3000
        20


SQL> select parse_calls, users_opening, users_executing from v$sql
  2  where sql_text = 'select * from scott.emp where empno=7788 ';

PARSE_CALLS USERS_OPENING USERS_EXECUTING
----------- ------------- ---------------
          3             1               0

세번 일어나는 순간 users_opening값이 0에서 1로 바뀐 것 확인
세번째 수행되기 전까지는 users_opening값이 0인것
커서를 닫자마자 공유커서에 대한 참조까지 곧바로 해제

users_opening에서 'open' 의 의미가 실제 커서가 열려 있음을 의미하는 것이 아님을
기억할 필요가 있다. 커서는 닫힌 상태지만 공유 커서에 대한 참조를 유지하기 때문에 다
음수행 시 더 빨리 커서를오픈할수있는것이다.

create table t(x number);

select a.name, b.value  
from   v$statname a, v$mystat b 
where  a.name in ('session cursor cache hits','parse count (total)')
and    b.statistic# = a.statistic#; 


alter session set session_cached_cursors=0;

declare 
   i number; 
 begin 
   for i in 1..10000 
    loop 
    execute immediate 'insert into t values('||mod(i,100)||')'; 
    end loop; 
 
 commit; 
end; 
/  


select a.name, b.value  
from   v$statname a, v$mystat b 
where  a.name in ('session cursor cache hits','parse count (total)')
and    b.statistic# = a.statistic#; 

alter session set session_cached_cursors=100;

declare 
   i number; 
 begin 
   for i in 1..10000 
    loop 
    execute immediate 'insert into t values('||mod(i,100)||')'; 
    end loop; 
 
 commit; 
end; 
/  


select a.name, b.value  
from   v$statname a, v$mystat b 
where  a.name in ('session cursor cache hits','parse count (total)')
and    b.statistic# = a.statistic#; 

출처: http://wiki.gurubee.net/pages/viewpage.action?pageId=28115145

SHARED POOL에 대한 점검 사항들

제품 : ORACLE SERVER




SHARED POOL에 대한 점검 사항들
======================


PURPOSE
-------
다음은 shared pool에 관련된 performance 에 대한 점검 사항들이다.


Explanation
-----------

1. literal SQL Statements

SELECT      substr(sql_text,1,40) "SQL", count(*) ,
sum(executions) "TotExecs"
FROM      v$sqlarea
WHERE      executions < 5
     GROUP BY substr(sql_text,1,40)
     HAVING count(*) > 30
ORDER BY 2
/

shared SQL문들 중에서 literal SQL문들을 찾아내어 bind variable을
사용할 수 있는 경우 bind variable로 전환하도록 한다.
ORACLE cost based optimizer는 bind variable 보다 literal value를
사용하는 SQL에 대하여 보다 최적화된 execution plan을 결정하게 된다.
하지만 과도한 literal SQL문들을 사용하게 되면 hard parsing 이
빈번하게 되고 library cache와 dictionary cache의 사용율을 높이게 된다.


2. Library cahe hit ratio

SELECT to_char(trunc(sum(reloads)/sum(pins)*100, 5),99.99999)||
'%(less than 1%)' "Library Cache MISS RATIO"
FROM v$librarycache
/

만일 miss ratio가 1%보다 큰 경우 library cache miss를 줄이는 노력이
필요하다. 예를 들어 적절한 크기의 shared pool을 사용하거나 dynamic SQL
(literal SQL) 사용을 줄이도록 한다.


3. Checking hash chain lengths
SELECT hash_value, count(*)
FROM v$sqlarea
GROUP BY hash_value
HAVING count(*) > 5
/

위 query에 대한 결과가 없어야 한다. 만일 동일한 HASH_VALUE를 갖는
sql 수가 많다면 다음의 query를 이용하여 이 hach chain에 의하여 관리되는
sql 들을 확인하여 본다.
대부분 literal sql문들에 의하여 이런 문제가 발생하는 경우가 많다.

SELECT sql_text FROM v$sqlarea WHERE hash_value= <XXX>;


4. Checking for high version counts

     SELECT      address, hash_value,
     version_count ,
users_opening ,
users_executing
sql_text
FROM v$sqlarea
WHERE version_count > 10
     /

SQL의 version은 문장 상으로 완벽히 일치하지만 참조 object가 틀리는
SQL문들을 의미한다. 만일 이해할 수 없을 정도의 version count를 갖는
row가 있다면 한국 오라클 기술지원팀으로 문의하도록 한다.


5. Finding statement/s which use lots of shared pool memory

SELECT      substr(sql_text,1,40) "Stmt", count(*),
sum(sharable_mem) "Mem",
sum(users_opening) "Open",
sum(executions) "Exec"
FROM v$sql
GROUP BY substr(sql_text,1,40)
HAVING sum(sharable_mem) > <MEMSIZE>
/


6. Allocations causing shared pool memory to be 'aged' out

SELECT      *
FROM      sys.x$ksmlru
WHERE      ksmlrnum>0
/

x$ksmlru는 shared pool의 object에 대한 list로 object 할당 시 age out된
object 수에 정보를 담고 있어 age out으로 인한 응답율 저하나 latch
병합들의 원인을 추적하는 데 유용하다.
이 table은 8i부터 sys user로만 조회가 가능하며 한번 조회되면 reset된다.

(x$ksmlru.ksmlrnum : Number of items flushed from the shared pool)


Example
-------


Reference Documents
-------------------

출처 : http://www.commit.co.kr/101

Single_to_RAC(Converting).pdf

Steps to Remove Node from Cluster When the Node Crashes Due to OS/Hardware Failure and cannot boot up (Doc ID 466975.1) To BottomTo Bottom

Modified:16-Nov-2012Type:HOWTO

Rate this document Email link to this document Open document in new window Printable Page

In this Document

Goal

Fix

  Summary

  Example Configuration

  Initial Stage

  Step 1 Remove oifcfg information for the failed node

  Step 2 Remove ONS information

  Step 3 Remove resources

  Step 4 Execute rootdeletenode.sh

  Step 5 Update the Inventory

References

APPLIES TO:

Oracle Server - Enterprise Edition - Version 10.2.0.1 to 11.1.0.6 [Release 10.2 to 11.1]

Oracle Server - Standard Edition - Version 10.2.0.1 to 11.1.0.6 [Release 10.2 to 11.1]

Information in this document applies to any platform.

Oracle Server Enterprise Edition - Version: 10.2.0.1 to 11.1.0.6

Oracle Clusterware

GOAL

This document is intented to provide the steps to be taken to remove a node from the Oracle cluster. The node itself is unavailable due to some OS issue or hardware issue which prevents the node from starting up. This document will provide the steps to remove such a node so that it can be added back after the node is fixed.

The steps to remove a node from a Cluster is already documented in the Oracle documentation at

Version Documentation Link

10gR2 http://download.oracle.com/docs/cd/B19306_01/rac.102/b14197/adddelunix.htm#BEIFDCAF

11gR1 http://download.oracle.com/docs/cd/B28359_01/rac.111/b28255/adddelclusterware.htm#BEIFDCAF

This note is different because the documentation covers the scenario where the node is accessible and the removal is a planned procedure. This note covers the scenario where the Node is unable to boot up and therefore it is not possible to run the clusterware commands from this node.

For 11gR2, refer to note 1262925.1

FIX

Summary

Basically all the steps documented in the Oracle Clusterware Administration and Deployment Guide must be followed. The difference here is that we skip the steps that are to be executed on the node which is not available and we run some extra commands on the other node which is going to remain in the cluster to remove the resources from the node that is to be removed.

Example Configuration

 All steps outlined in this document were executed on a cluster with the following configuration:

Item Value

Node Names lc2n1, lc2n2, lc2n3

Operating System Oracle Enterprise Linux 5 Update 4

Oracle Clusterware Release 10.2.0.5.0

ASM & Database Release 10.2.0.5.0

Clusterware Home /u01/app/oracle/product/10.2.0/crs ($CRS_HOME)

ASM Home /u01/app/oracle/product/10.2.0/asm

Database Home /u01/app/oracle/product/10.2.0/db_1

 Cluster Name lc2

 Assume that node lc2n3 is down due to a hardware failure and cannot even boot up. The plan is to remove it from the clusterware, fix the issue and then add it again to the Clusterware. In this document, we will cover the steps to remove the node from the clusterware

Please note that for better readability instead of 'crs_stat -t' the sample script 'crsstat' from 

  Doc ID 259301.1 CRS and 10g/11.1 Real Application Clusters 

was used to query the state of the CRS resources. This script is not part of a standard CRS installation.

Initial Stage

At this stage, the Oracle Clusterware is up and running on nodes lc2n1 & lc2n2 (good nodes) . Node lc2n3 is down and cannot be accessed. Note that the Virtual IP of lc2n3 is running on Node 1. The rest of the lc2n3 resources are OFFLINE:

[oracle@lc2n1 ~]$ crsstat

Name                                     Target     State      Host      

-------------------------------------------------------------------------------

ora.LC2DB1.LC2DB11.inst                  ONLINE     ONLINE     lc2n1     

ora.LC2DB1.LC2DB12.inst                  ONLINE     ONLINE     lc2n2     

ora.LC2DB1.LC2DB13.inst                  ONLINE     OFFLINE              

ora.LC2DB1.LC2DB1_SRV1.LC2DB11.srv       ONLINE     ONLINE     lc2n1     

ora.LC2DB1.LC2DB1_SRV1.LC2DB12.srv       ONLINE     ONLINE     lc2n2     

ora.LC2DB1.LC2DB1_SRV1.LC2DB13.srv       ONLINE     OFFLINE              

ora.LC2DB1.LC2DB1_SRV1.cs                ONLINE     ONLINE     lc2n1     

ora.LC2DB1.db                            ONLINE     ONLINE     lc2n2     

ora.lc2n1.ASM1.asm                       ONLINE     ONLINE     lc2n1     

ora.lc2n1.LISTENER_LC2N1.lsnr            ONLINE     ONLINE     lc2n1     

ora.lc2n1.gsd                            ONLINE     ONLINE     lc2n1     

ora.lc2n1.ons                            ONLINE     ONLINE     lc2n1     

ora.lc2n1.vip                            ONLINE     ONLINE     lc2n1     

ora.lc2n2.ASM2.asm                       ONLINE     ONLINE     lc2n2     

ora.lc2n2.LISTENER_LC2N2.lsnr            ONLINE     ONLINE     lc2n2     

ora.lc2n2.gsd                            ONLINE     ONLINE     lc2n2     

ora.lc2n2.ons                            ONLINE     ONLINE     lc2n2     

ora.lc2n2.vip                            ONLINE     ONLINE     lc2n2     

ora.lc2n3.ASM3.asm                       ONLINE     OFFLINE              

ora.lc2n3.LISTENER_LC2N3.lsnr            ONLINE     OFFLINE              

ora.lc2n3.gsd                            ONLINE     OFFLINE              

ora.lc2n3.ons                            ONLINE     OFFLINE              

ora.lc2n3.vip                            ONLINE     ONLINE     lc2n1     

[oracle@lc2n1 ~]$

Step 1 Remove oifcfg information for the failed node

Generally most installations use the global flag of the oifcfg command and therefore they can skip this step. They can confirm this using:

[oracle@lc2n1 bin]$ $CRS_HOME/bin/oifcfg getif

eth0  192.168.56.0  global  public

eth1  192.168.57.0  global  cluster_interconnect

If the output of the command returns global as shown above then you can skip the following step (executing the command below on a global defination will return an error as shown below.

If the output of the oifcfg getif command does not return global then use the following command

[oracle@lc2n1 bin]$ $CRS_HOME/bin/oifcfg delif -node lc2n3 

PROC-4: The cluster registry key to be operated on does not exist.

PRIF-11: cluster registry error

Step 2 Remove ONS information

Execute the following command to find out the remote port number to be used

[oracle@lc2n1 bin]$ cat $CRS_HOME/opmn/conf/ons.config

localport=6113 

remoteport=6200 

loglevel=3

useocr=on

and remove the information pertaining to the node to be deleted using:

[oracle@lc2n1 bin]$ $CRS_HOME/bin/racgons remove_config lc2n3:6200

Step 3 Remove resources

In this step, the resources that were defined on this node have to be removed. These resources include Database Instances, ASm, Listener and Nodeapps resources. A list of these can be acquired by running crsstat (crs_stat -t) command from any node

[oracle@lc2n1 ~]$ crsstat |grep OFFLINE

ora.LC2DB1.LC2DB13.inst                  ONLINE     OFFLINE              

ora.LC2DB1.LC2DB1_SRV1.LC2DB13.srv       ONLINE     OFFLINE              

ora.lc2n3.ASM3.asm                       ONLINE     OFFLINE              

ora.lc2n3.LISTENER_LC2N3.lsnr            ONLINE     OFFLINE              

ora.lc2n3.gsd                            ONLINE     OFFLINE              

ora.lc2n3.ons                            ONLINE     OFFLINE             

 Before removing any resource it is recommended to take a backup of the OCR:

[root@lc2n1 ~]# cd $CRS_HOME/cdata/lc2

[root@lc2n1 lc2]# $CRS_HOME/bin/ocrconfig -export ocr_before_node_removal.exp

[root@lc2n1 lc2]# ls -l ocr_before_node_removal.exp

-rw-r--r-- 1 root root 151946 Nov 15 15:24 ocr_before_node_removal.exp

 Use 'srvctl' from the database home to delete the database instance on node 3:

[oracle@lc2n1 ~]$ . oraenv

ORACLE_SID = [oracle] ? LC2DB1

[oracle@lc2n1 ~]$ $ORACLE_HOME/bin/srvctl remove instance -d LC2DB1 -i LC2DB13

Remove instance LC2DB13 from the database LC2DB1? (y/[n]) y

 Use 'srvctl' from the ASM home to delete the ASM instance on node 3:

[oracle@lc2n1 ~]$ . oraenv

ORACLE_SID = [oracle] ? +ASM1

[oracle@lc2n1 ~]$ $ORACLE_HOME/bin/srvctl remove asm -n lc2n3

Next remove the listener resource.

Please note that there is no 'srvctl remove listener' subcommand prior to 11.1 so this command will not work in 10.2. Using 'netca' to delete the listener from a down node also is not an option as netca needs to remove the listener configuration from the listener.ora.

10.2 only:

The only way to remove the listener resources is to use the command 'crs_unregister', please use this command only in this particular scenario:

[oracle@lc2n1 lc2]$ $CRS_HOME/bin/crs_unregister ora.lc2n3.LISTENER_LC2N3.lsnr

 11.1 only:

 Set the environment to the home from which the listener runs (ASM or database):

[oracle@lc2n1 ~]$ . oraenv

ORACLE_SID = [oracle] ? +ASM1

[oracle@lc2n1 lc2]$ $ORACLE_HOME/bin/srvctl remove listener -n lc2n3 

  As user root stop the nodeapps resources:

[root@lc2n1 oracle]# $CRS_HOME/bin/srvctl stop nodeapps -n lc2n3

[root@lc2n1 oracle]# crsstat |grep OFFLINE

ora.lc2n3.LISTENER_LC2N3.lsnr            OFFLINE    OFFLINE              

ora.lc2n3.gsd                            OFFLINE    OFFLINE              

ora.lc2n3.ons                            OFFLINE    OFFLINE              

ora.lc2n3.vip                            OFFLINE    OFFLINE        

 Now remove them:

[root@lc2n1 oracle]#  $CRS_HOME/bin/srvctl remove nodeapps -n lc2n3

Please confirm that you intend to remove the node-level applications on node lc2n3 (y/[n]) y

 At this point all resources from the bad node should be gone:

[oracle@lc2n1 ~]$ crsstat 

Name                                     Target     State      Host      

-------------------------------------------------------------------------------

ora.LC2DB1.LC2DB11.inst                  ONLINE     ONLINE     lc2n1     

ora.LC2DB1.LC2DB12.inst                  ONLINE     ONLINE     lc2n2     

ora.LC2DB1.LC2DB1_SRV1.LC2DB11.srv       ONLINE     ONLINE     lc2n1     

ora.LC2DB1.LC2DB1_SRV1.LC2DB12.srv       ONLINE     ONLINE     lc2n2     

ora.LC2DB1.LC2DB1_SRV1.cs                ONLINE     ONLINE     lc2n1     

ora.LC2DB1.db                            ONLINE     ONLINE     lc2n2     

ora.lc2n1.ASM1.asm                       ONLINE     ONLINE     lc2n1     

ora.lc2n1.LISTENER_LC2N1.lsnr            ONLINE     ONLINE     lc2n1     

ora.lc2n1.gsd                            ONLINE     ONLINE     lc2n1     

ora.lc2n1.ons                            ONLINE     ONLINE     lc2n1     

ora.lc2n1.vip                            ONLINE     ONLINE     lc2n1     

ora.lc2n2.ASM2.asm                       ONLINE     ONLINE     lc2n2     

ora.lc2n2.LISTENER_LC2N2.lsnr            ONLINE     ONLINE     lc2n2     

ora.lc2n2.gsd                            ONLINE     ONLINE     lc2n2     

ora.lc2n2.ons                            ONLINE     ONLINE     lc2n2     

ora.lc2n2.vip                            ONLINE     ONLINE     lc2n2  

Step 4 Execute rootdeletenode.sh

From the node that you are not deleting execute as root the following command which will help find out the node number of the node that you want to delete

[oracle@lc2n1 ~]$ $CRS_HOME//bin/olsnodes -n

lc2n1   1

lc2n2   2

lc2n3   3

this number can be passed to the rootdeletenode.sh command which is to be executed as root from any node which is going to remain in the cluster.

[root@lc2n1 ~]# cd $CRS_HOME/install

[root@lc2n1 install]# ./rootdeletenode.sh lc2n3,3

CRS-0210: Could not find resource 'ora.lc2n3.ons'.

CRS-0210: Could not find resource 'ora.lc2n3.vip'.

CRS-0210: Could not find resource 'ora.lc2n3.gsd'.

CRS-0210: Could not find resource ora.lc2n3.vip.

CRS nodeapps are deleted successfully

clscfg: EXISTING configuration version 3 detected.

clscfg: version 3 is 10G Release 2.

Successfully deleted 14 values from OCR.

Key SYSTEM.css.interfaces.nodelc2n3 marked for deletion is not there. Ignoring.

Successfully deleted 5 keys from OCR.

Node deletion operation successful.

'lc2n3,3' deleted successfully

[root@lc2n1 install]# $CRS_HOME/bin/olsnodes -n

lc2n1   1

lc2n2   2

Step 5 Update the Inventory

From the node which is going to remain in the cluster run the following command as owner of the CRS_HOME. The argument to be passed to the CLUSTER_NODES is a comma seperated list of node names of the cluster which are going to remain in the cluster. This step needs to be performed from once per home (Clusterware, ASM and RDBMS homes).

[oracle@lc2n1 install]$ $CRS_HOME/oui/bin/runInstaller -updateNodeList ORACLE_HOME=/u01/app/oracle/product/10.2.0/crs "CLUSTER_NODES={lc2n1,lc2n2}" CRS=TRUE  

Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.

The inventory pointer is located at /etc/oraInst.loc

The inventory is located at /u01/app/oracle/oraInventory

'UpdateNodeList' was successful.

[oracle@lc2n1 install]$ $CRS_HOME/oui/bin/runInstaller -updateNodeList ORACLE_HOME=/u01/app/oracle/product/10.2.0/asm "CLUSTER_NODES={lc2n1,lc2n2}"

Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.

The inventory pointer is located at /etc/oraInst.loc

The inventory is located at /u01/app/oracle/oraInventory

'UpdateNodeList' was successful.

[oracle@lc2n1 install]$ $CRS_HOME/oui/bin/runInstaller -updateNodeList ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1 "CLUSTER_NODES={lc2n1,lc2n2}"

Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.

The inventory pointer is located at /etc/oraInst.loc

The inventory is located at /u01/app/oracle/oraInventory

'UpdateNodeList' was successful.

11g NEWFEATURE.(upgrade).pdf

4-oracle-db-11g-best-practice-forum.pdf

11g에 추가된 파티션 유형

Reference 파티셔닝

• 상품 테이블을 상품대분류 기준으로 리스트 파티셔닝하고, 일별상품거래 테이블도 부모 테이블인 상품과 똑 같은 방식과 기준으로 파티셔닝
• 이럴 때 10g 까지는 상품에 있는 상품대분류 컬럼을 일별 상품거래 테이블에 반정규화
• 11g에서 부모 테이블 파티션 키를 이용해 자식 테이블을 파티셔닝하는 기능

Create table 상품 {
상품번호 number NOT NULL PRIMARY KEY
, 상품명 varchar2(50) not null
, 현재가격 number not null
, 상품대분류 varchar2(4) not null
, 등록일시 date not null
)
Partition by list(상품대분류) (
 Partition p1 values ('의류')
,partition p2 values ('식품')
,partition p3 values ('가전')
,partition 4 values ('컴퓨터')
);

create table 일별상품거래 (
  상품번호   number  NOT NULL, 거래일자   varchar2(8)
, 판매가격   number
, 판매수량   number
, 판매금액   number
, constraint 일별상품거래_fk foreign key(상품번호) references 상품
)
partition by reference (일별상품거래_fk);

Interval 파티셔닝

• 11g 부터는 Range 파티션을 생성할 대 아래와 같이 interval, 기준을 정의함으로써 정해진 간격으로 파티션이 자동 추가되도록 할 수 있다.
• 테이블을 일단위로 파티셔닝 했을때 유용하다.

create table 주문일자 (주문번호 number, 주문일시 date, ... )
partition by range(주문일시) INTERVAL(NUMTOYMINTERVAL(1, 'MONTH')) 
(
, partition p200907 values less than(to_date('2009/08/01', 'yyyy/mm/dd'))
, partition p200908 values less than(to_date('2009/09/01', 'yyyy/mm/dd'))
, partition p200909 values less than(to_date('2009/10/01', 'yyyy/mm/dd'))
, partition p200910 values less than(to_date('2009/11/01', 'yyyy/mm/dd'))
);

create table 고객 (고객번호 number, 고객명 varchar2(20), ... )
partition by range(고객번호) INTERVAL (100000)
( partition p_cust1 values less than ( 100001 )
, partition p_cust2 values less than ( 200001 )
, partition p_cust3 values less than ( 300001 )
) ;