행위

오라클 파라미터

DB CAFE

Dbcafe (토론 | 기여)님의 2020년 10월 26일 (월) 16:38 판 (sessions)
thumb_up 추천메뉴 바로가기


목차

1 파라미터 파일의 개념과 종류[편집]

1.1 파라미터 파일의 개념[편집]

오라클에서 말하는 필수 파일 중에서 파라미터 파일은 오라클이 구동 할 수 있게 설계되어 있는 도면과 같습니다. 한가지 예로 데이터베이스를 기동하기 위해서는 파라미터 파일을 참조하여 SGA 및 기타 필요한 환경을 구성 할 수 있습니다.

shutdown(종료상태) -> 파라미터 파일 읽기(spfile/pfile) -> NOMOUNT 단계별로 올라오는데 여기에서 파라미터 파일을 가장 중요한 역활을 하게 됩니다. 만약 파라미터 파일이 없을 경우에는 "could not open parameter file '경로 및 파일이름' " 에러가 발생 됩니다.

1.2 파라미터 파일의 종류[편집]

1.2.1 정적 파라미터(initSID.ora)[편집]

  1. 오라클 모든 버전에서 사용가능(8i ~)
  2. 텍스트 형식으로 OS Edit를 이용하여 변경 가능
  3. 관련 뷰 : V$PARAMETER
  4. 동적 파마메터의 종류는 적음

1.2.2 동적 파라미터(spfileSID.ora)[편집]

  1. 오라클 특정 버전부터 사용가능(9i ~)
  2. 바이너리 형식으로 OS Edit를 이용하여 변경 불가능(vi를 이용해서 나오는 결과는 바이너리가 아닙니다.)
  3. 관련 뷰 : V$SPPARAMETER
  4. 동적 파마메터의 종류는 많음

pfile과 spfile의 가장 큰 차이점은 pfile은 OS에서 vi 편집기를 이용하여 파라미터의 값을 변경 할 수 있고 데이터베이스가 NOMOUNT 단계 이상이라면 다시 pfile을 쓰지 않습니다. 결과적으로 파일을 지워도 아무 이상 없습니다. 시스템 레벨에서 변경은 되지만 메모리에서 잠깐 사용하고 버리게 되는 것입니다.

아래 자세히 설명 하도록 하겠습니다. 반대로 spfile은 OS에서 vi 편집기로 절대 수정을 하면 안되며 NOMOUNT 단계 이상이라면 spfile을 다시 쓰기 때문제 제거 하거나 이동하면 안됩니다.

참고로 시스템 레벨은 아래에서 설명하겠지만 파라미터를 설정 변경은 조건에 따라서 pfile, spfile 모두 가능 합니다.

SPFILE :

ALTER SYSTEM SET [파라미터이름=values] [SCOPE=(MEMORY/SPFILE/BOTH)]

PFILE  :

ALTER SYSTEM SET [파라미터이름=values] [SCOPE=(MEMORY)]

파라미터 초기화

ALTER SYSTEM RESET "_pga_max_size" SID='*' [SCOPE=(MEMORY/SPFILE/BOTH)];

1.3 파라미터 파일의 관리[편집]

1.3.1 파라미터 경로[편집]

파라미터 파일의 경로는 기본적으로 $ORALE_HOME/dbs 에 있습니다.

$ cd $ORALE_HOME/dbs
$ ls -l
1.spfiletestdb.ora
2.spfile.ora
3.inittestdb.ora
4.init.ora

1.3.2 동적 파라미터 사용(SPFILE)[편집]

$ORACLE_HOME/dbs/spfiletestdb.ora 존재. spfileSID.ora 파일이 있다면 pfile(initSID.ora)의 내용은 절대 반영 되지 않음. initSID.ora 파일이 있어도 상관 없음.

$ ls -al spfile*
-rw-r-----  1 oracle dba 2560  1월 26 02:17 spfiletestdb.ora
1.3.2.1 데이터베이스를 오픈하지 않고 NOMOUNT 단계에서 상태 확인[편집]
SQL> startup nomount
1.3.2.2 현재 상태가 pfile인지 spfile인지 확인 하는 방법[편집]

아래와 같이 VALUE에 값이 있을 경우에는 spfile이고 만약 VALUE에 값이 없다면 pfile이 됩니다.

SQL> show parameter pfile
NAME         TYPE      VALUE
---------------------------------------------------------------
spfile         string      /home/oracle/product/10g/dbs/spfiletestdb.ora

1.3.3 현재 파라미터를 몇개나 사용하고 있는지 확인 =[편집]

SQL> select isspecified ,count(value) from v$spparameter group by isspecified;
ISSPECIFIED  COUNT(VALUE)
------------ ------------
FALSE               0
TRUE                22

1.3.4 정적 파라미터 사용(PFILE)[편집]

$ORACLE_HOME/dbs/inittestdb.ora 존재.

SPFILE이 우선 적용 되므로 spfiletestdb.ora, spfile.ora 파일을 제거 해야함.

$ ls -al initt*
-rw-r--r--  1 oracle dba 1089  1월 25 17:47 inittestdb.ora
1.3.4.1 데이터베이스를 오픈하지 않고 NOMOUNT 단계에서 상태 확인[편집]
SYS@testdb> startup nomount
1.3.4.2 현재 상태가 pfile인지 spfile인지 확인[편집]

아래와 같이 VALUE에 값이 있을 경우에는 spfile이고 만약 VALUE에 값이 없다면 pfile이 됩니다.

SQL> show parameter pfile;
NAME         TYPE     VALUE
-----------------------------------------
spfile         string
1.3.4.3 현재 파라미터를 몇개나 사용하고 있는지 확인[편집]
SQL> select isdefault ,count(value) 
       from v$parameter group by isdefault
ISDEFAULT    COUNT(VALUE)
------------------ ------------
FALSE        21
TRUE       168

1.4 파라미터 파일 생성[편집]

정적 파라미터는 데이터베이스 종료 상태에서도 가능 하지만 동적 파라미터의 경우는 데이터베이스가 NOMOUNT 단계 이상에서 생성.

1.4.1 정적 파라미터의 경우 - 방법 1[편집]

  1. show parameter dump 로 확인하여 덤프 파일이 경로를 확인.
  2. 기본적으로 덤프파일과 동일한 디렉토리에 pfile 디렉토리가 있습니다.
  3. init.ora.2322 파일을 기존 pfile($ORACLE_HOME/dbs) 위치로 복사하면 됩니다.
  4. 오라클 공인 문서에서는 $ORACLE_HOME/dbs 디렉토리의 init.ora 파일로 변경 하라고 되어 있습니다.

그말은 데이터베이스 올리지 말라는 것과 같은 이야기 입니다. 상당히 불편하기 때문에 아래와 같은 작업을 하시길 권장합니다.

$ cp init.ora.010201115288 $ORACLE_HOME/dbs

1.4.2 정적 파라미터의 경우 - 방법 2[편집]

NOMOUNT 단계 이상에서 생성 합니다.

SYS@testdb> create pfile from spfile;

1.4.3 동적 파라미터의 경우[편집]

NOMOUNT 단계 이상에서 생성 합니다.

SYS@testdb> create spfile from pfile;


1.5 시스템 레벨(ALTER SYSTEM SET)[편집]

1.5.1 파라미터 파일의 값 변경[편집]

ALTER SYSTEM SET 파라미터 이름=파라미터 값
[COMMENT='text']
[SCOPE=MEMORY/SPFILE/BOTH]
[SID='sid'/'*']
  • 파라미터 설정 주석을 추가하는 COMMENT 옵션

동적 파라미터 파일의 설정 값을 해당 명령어로 변경시 주석을 추가할 수 있게 하는 옵션. 파라미터 설정 값 변경시 이력 관리 및 특이 사항을 메모할 필요가 있을 경우 사용.

  • 파라미터 설정 변경하는 SCOPE 옵션

파라미터의 설정을 변경 하는데 있어서 가장 큰 역활을 하는 옵션. 동적 파라미터(spfile)와 정적 파라미터(pfile) 중 어떤 방식으로 기동 되었는지에 따라서 방법의 차이 있음. 기본적인 개념은 정적 파라미터는 MEMORY 옵션만 사용할 수 있고, 정적 파라미터는 옵션 모두 사용 가능. MEMORY : 파라미터 설정 값 변경을 메모리에서만 적용하는 의미로 종료 후 재기동 할 경우 MEMORY 옵션으로 변경 된 파라미터 값은 바뀌지 않습니다. SPFILE : 파라미터 설정 값을 변경 하되 데이터베이스를 재기동 후 변경 합니다. 실제적으로 현재 메모리 상에서는 기존의 값을 유지 하게 되고 재기동 후에는 변경 된 값을 정상적으로 사용 할 수 있습니다. BOTH : 어려운 옵션입니다. 왜냐하면 MEMORY + SPFILE 두가지의 옵션을 모두 사용합니다. 그렇다면 정적 파라미터에서 해당 옵션을 절대 사용 할 수 없습니다. 이유는 위에서 설명 한 것과 같이 PFILE에 결과 값을 쓰지 않기 때문입니다. PFILE는 DBA(관리자)가 직접 수정하는 설정 파일 입니다. 다시 말해서 동적 파라미터를 위한 옵션이라고 생각 하셔도 됩니다. 파라미터 설정 변경하는 SCOPE 옵션을 이용하여 변경 가능한 파라미터와 변경 불 가능한 파라미터 파악 IMMEDIATE : 즉시 적용이 가능한 파라미터 MEMORY/SPFILE/BOTH 모두 사용 가능 DEFERRED  : 현재 접속 중인 세션은 적용 하지 않고 다음 세션 부터 적용하는 파라미터로써 MEMORY/SPFILE/BOTH 모두 사용 가능 FALSE : 데이터베이스를 재 기동해야 적용 가능 한 것으로 오직 SPFILE만 사용 가능(Static Parameter)

1.5.2 정적 파라미터(pfile) 쿼리를 이용하여 사용 유무를 확인[편집]

SYS@testdb>   
SELECT ISSYS_MODIFIABLE ,COUNT(*)
FROM v$parameter
GROUP BY ISSYS_MODIFIABLE;

ISSYS_MODIFIABLE     COUNT(*)
------------------ ----------
DEFERRED                  7
FALSE                        107
IMMEDIATE                 145

1.5.3 동적파라미터(spfile) 쿼리를 이용하여 사용 유무를 확인[편집]

SYS@testdb>   
SELECT b.ISSYS_MODIFIABLE, COUNT(*)
FROM v$spparameter a, v$parameter b
WHERE a.name = b.name
GROUP BY b.ISSYS_MODIFIABLE;

ISSYS_MODIFIABLE     COUNT(*)
------------------ ----------
DEFERRED      7
FALSE     108
IMMEDIATE    145

파라미터 설정 변경하는 SID 옵션 오라클 RAC(Real Application Cluster)를 사용할 경우 변경된 파라미터 값이 적용될 노드를 선택하는 옵션입니다. 기본 값은'*'을 사용할 경우 모든 노드에 변경된 설정 값을 적용합니다. 특정 노드에만 적용해야 할 경우 해당 인스턴스 번호를 설정 해주면 됩니다.

[설명] testdb.__db_cache_size=180355072 에서 __의미는 spfile에서 pfile로 추출할때 ASM을 사용하고 있다면 현재 SGA의 COMPONENT 값을 의미 합니다. ASM을 사용하게 되면 SGA는 동적으로 크기가 변하는데 spfile에서 pfile을 생성시 값을 의미 합니다. 별 의미는 없습니다.

select component, current_size/1024/1024 "current", min_size/1024/1024 "min", user_specified_size/1024/1024 "user",
  granule_size/1024/1024 "granule"
from v$sga_dynamic_components;

[설명] *.db_block_size=8192 이와 같은 값이 보이는데, *심볼은 rac에서 적용가능하게 또는 구분 가능하도록디자인된 속성값이라 할 수있습니다. (* = all instance)


1.6 복구 시나리오[편집]

1.6.1 데이터베이스 종료 상태에서 DBA(관리자) 실수로 spfile, pfile 모두 삭제 했을 경우 복구 방법[편집]

  • $ORACLE_BASE/admin/testdb/pfile을 $ORACLE_HOME/dbs로 파일을 복사 한 후 DB를 OPEN .
-- 1.$ORACLE_HOME/dbs 로 이동  
$ cd $ORACLE_HOME/dbs

-- 2.$ORACLE_HOME/dbs spfile,pfile 확인 (현재는 삭제되어서 존재하지 않음)
$ ls
backup  hc_testdb.dat  initdw.ora  lkTESTDB  orapwtestdb

-- 3. DB 기동(파라이터 오류 발생됨) 
$ sqlplus / as sysdba
SYS@testdb> startup
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/home/oracle/product/10g/dbs/inittestdb.ora'

-- 4. 파일 복사 
-- 4.1. $ORACLE_BASE/admin/testdb/pfile에서 $ORACLE_HOME/dbs/로 파일 복사 
$ cd $ORACLE_BASE/admin/testdb/pfile
$ cp init.ora.010201115288 $ORACLE_HOME/dbs/inittestdb.ora

-- 5.데이터파일을 OPEN 하기 이전에 Controlfile의 경로가 맞는지 받드시 확인.
$ vi inittestdb.ora

# File Configuration
control_files=( '/home/oracle/oradata/testdb/control01.ctl',    
                '/home/oracle/oradata/testdb/control03.ctl')

-- 6.DB 기동 
SYS@testdb> startup
ORACLE instance started.
Total System Global Area  285212672 bytes
Fixed Size      1267068 bytes
Variable Size     92277380 bytes
Database Buffers   188743680 bytes
Redo Buffers      2924544 bytes
Database mounted.
Database opened.
SYS@testdb> show parameter pfile;
NAME         TYPE      VALUE
----------------------------------------------------
spfile         string

1.6.2 pfile을 spfile로 변경[편집]

  • pfile을 spfile로 만들어 주고 데이터베이스를 재기동.
SQL> create spfile from pfile;
SQL> shutdown immediate;
SQL> startup
ORACLE instance started.
Total System Global Area  285212672 bytes
Fixed Size      1267068 bytes
Variable Size     92277380 bytes
Database Buffers   188743680 bytes
Redo Buffers      2924544 bytes
Database mounted.
Database opened.
SQL> show parameter pfile;
NAME         TYPE      VALUE
------------------------------------------------
spfile         string      /home/oracle/product/10g/dbs/spfiletestdb.ora

1.6.3 spfile을 pfile로 변경[편집]

  • spfile을 pfile로 만들어 주고 데이터베이스를 재기동.
SQL> create pfile from spfile;

2 V$PARAMETER 컬럼 설명[편집]

Column ! Datatype ! Description
NUM NUMBER 파라미터 번호
NAME VARCHAR2(80) 파라미터 이름
TYPE NUMBER 파라미터 타입에 대한 번호 유형

• 1 - Boolean

• 2 - String

• 3 - Integer

• 4 - Parameter file

• 5 - Reserved

• 6 - Big integer

VALUE VARCHAR2(512)

세션에 대한 파라미터 값(세션 내에서 변경하는 경우) 또는 인스턴스 전체.

DISPLAY_VALUE VARCHAR2(512)

사용자에게 친숙한 형식의 매개변수 값.

예를 들어 BIG INTEGER 파라미터의 VALUE 값이 262144로 표시 될 경우, DISPLAY_VALUE에서는 256K로 출력한다.

ISDEFAULT VARCHAR2(9)

• TRUE - 파라미터가 기본값으로 설정.

• FALSE - 파라미터 파일에 파라미터 값이 명시.

ISSES_MODIFIABLE VARCHAR2(5)

• TRUE - 파라미터가 ALTER SESSION 명령으로 변경

• FALSE - 변경 불가능

ISSYS_MODIFIABLE VARCHAR2(9)

ALTER SYSTEM을 통해 변경되는 파라미터가 언제 적용 되는 가의 여부

• IMMEDIATE - 파라미터 타입에 상관 없이 ALTER SYSTEM 명령 즉시 적용됨.

• DEFERRED - 파라미터 타입에 관계 없이 ALTER SYSTEM을 통해 변경.

변경한 파라미터는 이후 세션에 적용됨.

• FALSE - 인스턴스 시작에 SPFILE이 사용되지 않았다면, ALTER SYSTEM으로 변경 할 수 없는 파라미터. 변경 사항은 이후 인스턴스에 적용됨.

ISINSTANCE_MODIFIABLE VARCHAR2(5)

• TRUE - ALTER SYSTEMS으로 변경된 파라미터가 모든 인스턴스간에 파라미터 값이 서로 다를 수 있는 경우.

• FALSE - 모든 RAC 인스턴스에 대해 파라미터는 같은 값을 가지고 있다.

ISSYS_MODIFIABLE 컬럼이 FALSE이면 이 컬럼은 항상 FALSE이다.

ISMODIFIED VARCHAR2(10)

파라미터가 인스턴스 시작 후 수정되었는지 여부.

• MODIFIED - ALTER SESSION으로 수정된 파라미터.

• SYSTEM_MOD - ALTER SYSTEM으로 수정된 파라미터.

(이것은 현재 로그인 된 모든 세션의 수정한 값의 원인이다.

원문첨부: which causes all the currently logged in sessions' values to be modified)

• FALSE – 인스턴스 시작 이후 수정되지 않은 파라미터.

ISADJUSTED VARCHAR2(5) 오라클이 더 적절한 값으로 입력할 것인지 여부.
(예를들어 파라미터 값이 PRIME이어야 하는데 유저가 입력한 값이 NON-PRIME NUMBER다. 그래서 오라클은 NEXT PRIME NUMBER로 값을 조정한다.
오라클에서 PRIME이 무엇인지 설명 요망)
ISDEPRECATED VARCHAR2(5)

파라미터가 중지되었는지(더 이상 사용되지 않는지) 여부.

• TRUE - 중지.

• FALSE - 중지 안됨.

DESCRIPTION VARCHAR2(255)

파라미터의 설명.

UPDATE_COMMIT VARCHAR2(255) 가장 최근의 업데이트와 관련된 코맨트.
HASH NUMBER 파라미터 이름에 대한 해시값

※ 세션에 적용되는 현재 초기화 파라미터에 대한 정보를 표시한다.

※ 새 세션은 V$SYSTEM_PARAMETER로 표시되는 인스턴스 전체 값에서 파라미터 값을 상속한다.


3 추천 파라미터[편집]

3.1 OPTIMIZER_DYNAMIC_SAMPLING[편집]

 - 참조)OLTP 업무의 경우 Hard Parsing이 자주 발생하지 않아 크게 도움이 되지 않을 뿐더러 파싱에 의한 부하가 크기 때문에 권장되지 않음
 - DYNAMIC SAMPLING(동적 샘플링)은 통계정보가 존재하지 않은 Table에 대한 정확한 selectivity와  cardinality의 추정치를 결정하여 성능을 향상시키는 것이 목적
 - 옵션 변경 방법
   optimizer_dynamic_sampling = value
 - value 값
   0 :dynamic sampling 비활성화
   1 :9i Default value 1.수행 Query에 최소 하나 이상의 통계정보가 없는 table에 존재
                       2.통계정보가 존재하지 않은 Table이 Join을 수행하거나 Sub Query로 수행
                       3.인덱스가 존재하지 않음
                       4.통계정보가 존재하지 않는 Table의 block개수가 dynamic sampling을 수행하는
                          블록의 개수(32) 보다 많을 때
   2 : 10g Default value. 통계정보가 없는 모든 Table을 sampling 함. Sampling block의 개수는 1과 동일
   4 : where 절에서 두 개 이상의 컬럼을 참조하는 모든 table을 sampling함
   5 : default sampling block * 2
   9 : default sampling block * 128
  10 : table의 모든 block dynamic sampling
 - 일반적으로 DW 와 같이 양측 like (%:value%) 등을 사용하는 경우 예측치를 적게 잡게 되므로 dynamic_sampling 이 효율적일수 있으나 OLTP 환경에서 통계정보가 존재한다면 불필요한 부하는 주게되는 현상이 발생한다.
 - OLTP 권장값
   optimizer_dynamic_sampling = 0


3.2 _gc_policy_time[편집]

 - 참조) Resource Remastering 수행하지 않음(Remastering이 빈번할 경우 서비스 성능지연 발생)
 - RAC 환경에서 자신의 로컬 캐시에 존재하지 않는 특정 블록을 읽기 위해서 반드시 해당 블록을 관리하는
   마스터 노드와 통신을 해야 함.
   만일 특정 블록을 자주 access 하는 인스턴스가 해당 블록의 마스터 노드가 된다면 인스턴스간 통신이 줄어 들기 때문에 RAC 시스템 전체의 성능을 향상시키게 됨.
   특정 블록을 자주 액세스하는 인스턴스가 해당 블록의 마스터 노드로 변경되는 것을 동적 리소스 리마스터링 이라고 함.
 - _gc_policy_time 권장값
   _gc_policy_time = 0
  

3.3 _gc_undo_affinity[편집]

 - RAC 에서 undo segment 를 활성화 한 노드가 자동으로 마스터 노드가 되는 기능
 - _gc_undo_affinity 권장값
   _gc_undo_affinity = false
  

3.4 _optimizer_use_feedback[편집]

 - 11gR2에서 이 기능은 이제 튜닝 엔진이 아닌 런타임 엔진에까지 적용이 되었습니다.
   간단하게 정리하면 다음과 같습니다.
   .쿼리를 수행한 후 예상 로우 건수와 실제 로우 건수의 차이가 크다고 판단되면 해당 실행 계획은
    공유 불가 상태가 되고 실제 로우 건수를 저장한다. 하지만 예상 로우 건수와 실제 로우 건수의
    차이만이 유일한 팩터인지는 확실하지 않음.
   .다음에 동일한 쿼리가 다시 실행되면 최초의 실행에서 저장한 로우 건수를 OPT_ESTIMATE 힌트를 이용해 쿼리에 삽입한다.
    즉 Cardinality Feedback이 이루어진다.
   .이 과정은 단 한번만 이루어진다. 즉 최초의 쿼리만이 피드백의 대상이 된다.
   ._OPTIMIZER_USE_FEEDBACK 파라미터를 이용해 제어 가능하다. 즉 이 파라미터의 값을 FALSE로 변경하면 Cardinality Feedback은 일어나지 않는다.
 - 실행계획 변경될 수 있음
 - _optimizer_use_feedback 권장값
   _optimizer_use_feedback = false

3.5 _b_tree_bitmap_plans[편집]

 - Query Optimizer 가 SQL 을 해설할 때 Where 절에 여러 조건이 있고, 해당 조건컬럼들에 index 가 각각 생성되어 있을 경우 Btree Index 를 Bitmap 으로 conversion 하여 PLAN을 수립하여 실행함.
   이럴 경우 TYPE이나 CODE 성 컬럼의 경우 Btree Index Range Scan으로 해결되는 경우 보다 성능이 좋을수 있으나 일반적으로 성능이 저하되는 경우가 더 많음.
 - Bitmap Coversion시 성능저하가 일어나는 경우 발생
 - _b_tree_bitmap_plans 권장값
   _b_tree_bitmap_plans = false   


3.6 OPTIMIZER_INDEX_CACHING , OPTIMIZER_INDEX_COST_ADJ[편집]

 - OPTIMIZER_INDEX_CACHING설정하기 (0-100 default:0)
   . Nested Loops 조인이나 IN-List 탐침으로 수행되어 인덱스가 반복해서 랜덤 액세스를 할 때 인덱스 블록들이 버퍼에 캐쉬되어 있을 확률을 나타냄.
   . 이것은 곧 랜덤 액세스에 대한 부하가 감소되는 것을 의미하므로 옵티마이져가 Nested Loops 조인이나 IN-List 탐침으로 실행계획을 수립하는 경향이 증가한다.
     예를 들어 100으로 설정할 경우 SQL 조건에 따라 읽어들여야 하는 인덱스 블록이 100% DB Buffer Cache에서 찾아질 것을 가정하는 것이고  0으로 설정할 경우 Buffer Cache에서 찾아질 가능성이 0이라고 가정하는 것입니다.
     만약 랜덤 액세스가 많이 발생하는 환경에서 반복 액세스가 일어나는 인덱스가 적은 블록을 가지고 있거나 특정한 범위를 주로 액세스하여 재사용률이 매우 높다면 이 값을 증가시켜 주는 것이 좋다.
     그러나 이것은 비용의 조정을 의미하기 때문에 옵티마이저에게 커다란 영향을 미칠 수 있으므로 주의하여야 한다.
   . OPTIMIZER_INDEX_CACHING 파라메터는 in-list iterator 방식으로 인덱스를 탐침할 때 읽게 되는 인덱스 블록과 NL조인시 inner테이블에 속한 인덱스 블록에 대한 비용계산을 조정하고자 할 때 사용한다.
    단일 테이블을 액세스하기 위한 일반적인 index unique scan 이나 range scan 비용을 계산할 때는 영향을 미치지 않는다
 - OPTIMIZER_INDEX_COST_ADJ설정하기 (1-1000 default:100)
   . OPTIMIZER_INDEX_COST_ADJ 파라미터는 디폴트 100으로 설정되어 있으며 가능한 값의 범위는 1부터 10000 까지입니다.
     이 파라미터는 인덱스 탐색비용에 대한 평가를 조정하기 위해 사용하는 것으로서,디폴트 설정값 100은 인덱스에 대한 액세스 비용이 보통의 비용모델에 근거해서 평가될 것이고, 10으로 설정한다면 보통의 인덱스 액세스 비용의 1/10로 평가될 것임을 의미합니다.
     따라서 이 값이 작을수록 인덱스를 경유한 테이블 액세스(a Single-Block I/O) 비용이 더 적게 평가될 것이고, 클수록 인덱스를 경유하지 않는 Full Tabe Scan(a Multiblock I/O)의 액세스 비용이 더 적게 평가될 것입니다.
     바꾸어 말하면, 이 파라미터는 Single-Block I/O와 Multiblock I/O에 대한 상대적인 평가로 해석할 수 있고, 따라서 테이블 데이터 블록이 평균적으로 얼마만큼 캐싱되어 있는지에 대한 의미로 해석할 수도 있습니다.
     앞에서 설명한 OPTIMIZER_INDEX_CACHING이 인덱스가 캐싱되어 있을 확률을 가리키는 것처럼 말입니다.
 - 설정
   . 기본값인 OPTIMIZER_INDEX_CACHING = 0과 OPTIMIZER_INDEX_COST_ADJ = 100 : 이들은 일반적으로 데이터 웨어하우스/보고용 시스템에 적합.
   . OPTIMIZER_INDEX_CACHING = 90과 OPTIMIZER_INDEX_COST_ADJ = 25 : 이들은 일반적으로 트랜잭션/OLTP 시스템에 적합.


3.7 open_links[편집]

 - 초기값 4, 권장값 40
 - 하나의 session 에 동시에 사용할수 있는 DB Link 개수 지정
 - DB Link 사용을 위하여 값을 늘려놓을 필요가 있음


3.8 open_links_per_instance[편집]

 - 초기값 4, 권장값 40
 - 하나의 instance 에 동시에 사용할수 있는 DB Link 개수 지정
 - DB Link 사용을 위하여 값을 늘려놓을 필요가 있음

3.9 db_files[편집]

 - DB 에서 열수 있는 datafile 의 최대 개수
 - 권장값 : 서버 및 업무마다 조금씩 틀리지만 일반적으로 1000 이상으로 세팅


3.10 _optimizer_invalidation_period[편집]

 - 통계정보 변경 후 관련 SQL Cursor 가 invalidation 되는 시점을 지정
 - 권장값 : 통계정보 후 기존 Cursor가 즉시 무효화 되도록 설정
   _optimizer_invalidation_period = 1

3.11 db_cache_advice[편집]

 - DB_CACHE_ADVICE를 통한  Buffer Cache 크기조절시 성능 예측, 즉 Buffer Cache 튜닝진단도구임(Advisory 기능)
 - Buffer Cache Advisory 기능 사용은 다음 두가지의 오버헤드를 발생
   . Advisory 기능은 buffer cache 별로 bookkeeping 을 위한 약간의 cpu 오버헤드가 발생
   . Memory : Advisory 기능은 buffer block 당 shared pool에 약 700 byte 정도의 메모리를 할당
 - DB_CACHE_ADVICE = {ON | READY | OFF}
   . OFF : Advisory 기능이 disable 되고, CPU나 MEMORY 오버헤드가 없음
   . ON  : Advisory 기능이 enable 되고, CPU나 MEMORY 오버헤드가 발생 (simulator lru latch wait event 가 발생할수 있음)
   . READY : Advisory 기능이 disable 되나, shared pool의 메모리는 할당
 - 권장값 shared pool 값이 충분하면 READY 를 설정해도 큰 문제는 없으나 그렇지 않을 경우 OFF 로 설정.

3.12 _library_cache_advice[편집]

 - libaray cache 크기 조절시 성능 예측
 - 권장 값 : _library_cache_advice = false

3.13 _db_mttr_advice[편집]

 - mttr(Mean-Time-To-Recover) 크기 조설시 성능 예측
 - 권장 값 : _db_mttr_advice = false
  

3.14 audit_trail[편집]

 - 의심가는 데이터베이스의 작업을 모니터링 하고, 기록 정보를 수집 하는 기능
 - 감사 로그를 기록해야 하므로 시스템의 속도 저하 발생 및 과도한 로그 생성으로 system tablespace의 증가
 - 11G부터 audit_trail default 위치가 DB로 설정되어 있어 tablespace full발생함
 - 권장 값 : NONE

3.15 optimizer_mode[편집]

 - batch job 등이 존재하지 않고 순수 OLTP 성 업무일 경우 변경
 - 권장 값 : FIRST_ROWS_1

3.16 _enqueue_hash_chain_latches[편집]

 - hash chain latch 는 해쉬 테이블과 해쉬 체인을 보호안다.
   기본 설정값은 cpu_count 와 동일하며 _enqueue_hash_chain_latches 파라메터를 통해 조정 가능하다.
 - 권장 값 : CPU CORE*3

3.17 _cleanup_rollback_entries[편집]

 - 한번에 rollback 하는 count (V$TRANSACTION.USED_UREC) 를 결정
   즉 Rollback의 성능향상을 가져옴.
 - 권장 값 : 500 정도, 개발 DB 나 Migration 등일때는 몇만 까지 잡고 처리해도 가능함.
   너무 큰 값을 사용할 경우 rollback 부하로 인해 다른 업무에 영향을 받을 수 있음.
 - fast_start_parallel_rollback=false 와 같이 고려
  

3.18 _highthreshold_undoretention[편집]

 - Undo tablespace가 계속 증가하는 현상 발생
   Undo 정보 확인해보면 unexpired된 extents가 많이 보임.
   즉 Undo extents 가 unexpired 상태에서 expired 되지 않는 문제로 해당 값 적용 권고
 - 권장 값 : _highthreshold_undoretention = 86400 [10800]
 - 권장 값 변경후에도 이슈가 발생시 _undo_autotune 을 false 로 변경


3.19 _optimizer_extended_cursor_sharing , _optimizer_extended_cursor_sharing_rel[편집]

 - 불필요한 child cursor 발생 방지-10g 존재 parameter
 - 권장 값 : 둘다 NONE
참조 )
alter system set "cursor_sharing"=exact scope=both;
alter system set "_optimizer_extended_cursor_sharing_rel"=none scope=both;
alter system set "_optimizer_extended_cursor_sharing"=none scope= both;
alter system set "_optimizer_adaptive_cursor_sharing"=false scope= both;

3.20 _partition_large_extents=false (default=true)[편집]

   _index_partition_large_extents=false (default=false)
 - 일반적으로 테이블을 생성할 경우 64kb의 extent를 할당 받아 segment가 생성
 - Oracle 11g부터는 파티션 테이블에 대해서는 대용량 데이터라는 판단하여 extent할당하는 크기가 바뀜(table: 64KB -> 8MB, index : 64KB)
 - 이와 같은 경우 lange + hash composite partition 일 경우 테이블 생성초기부터 엄청난 공간을 차지하면서 segment 가 생성되게 됨.
 - 권장 값 : 둘다 false

3.21 _add_col_optim_enabled[편집]

 - column add 시에 dictionary 만 update 하고 , 이후 insert 시 해당 column이 생성
 - Add Column(default 값이 있고, NOT NULL 제약조건 이 있는 경우)후 Query에서Wrong Result가 Return 가능성
 - 권장 값 : false


3.22 _datafile_write_errors_crash_instance[편집]

 - Datafile한개라도 I/O error 날 경우 전체 instance shutdown
 - 권장 값 : false


3.23 _memory_imm_mode_without_autosga[편집]

 - ORA-4031 회피하기 위해 SGA_TARGET, MEMORY_TARGET이 설정되어 있지 않더라도 memory resize 


참조) 1. _gc_defer_time = 0 (default = 3ms)

 - cleanout 작업이 예상되는 current block 의 전송을 지연시키는 역활
 - block cleanout 은 dirty block 의 row level lock 정보를 해제한다는 것
 - gc current block pin time wait event 와 관련됨
   . 다른 instance 의 current 요청에 대하여, current block 에 대한 lock 을 획득하는데 소요된 시간
   . pin 에 시간이 소요되는 경우는 크게 2가지
   . 만일 전송대상인 current block 에 대하여 block cleanout 이 이루어지지 않았다면 _gc_defer_time (default : 3ms) 만큼 대기 후 lock 을 획득
   . 2번째로 block 경합이 발생하는 경우 -> 전송대상인 current block 을 local process 가 사용중이라면 lock 획들할 때 까지 대기

2. _use_adaptive_log_file_sync

 - 11g new feature로 log file sync 수행시 post wait 방식과 polling 방식을 선택할수 있음.
  . false : 기존 방식인 post wait 방식
  . polling-only : polling 방식 
  . true : post-wait 과 polling 방식의 자동 변환
 - 11.2.0.3 에서 false 권고
  post-wait 방식과 polling 방식을 자동 변환 중 성능 지연 발생 가능성이 있음. 

3.24 memory_target[편집]

- 초기값 10G, 권장값 0 이나 주석처리
- 메모리 (SGA + PGA) 크기 자동 튜닝 기능때 총 메모리량 지정

- db_writer_process

- 초기값 50, 권장값 500
- 하나의 session 당 캐싱되는 커서의 갯수

- _diag_daemon

- 기본값 true, 권장값 false
- 분석 데몬의 자동시작유무 결정
- Diagnosability Daemon (DIAG) 는 process 와 instance failure 에 관련한 진단 정보를 포착(capture)하여
  systemstate dump 를 12로 생성하는 역활을 함.

3.25 pga_aggregate_target[편집]

인스턴스에 연결된 모든 서버 프로세스에서 사용할 수 있는 PGA 메모리의 합계 크기에 대한 목표치(Target)를 설정하는 파라미터로 인스턴스 레벨에서 동적으로 수정 가능하다 (eg. 100,000KB, 2,500MB, 50GB)


pga_aggregate_target 값을 0이 아닌 값으로 설정하면 workarea_size_policy 파라미터가

자동으로 auto로 세팅된 것으로 간주되어 "_area_size"와 같은 Workarea Size를 결정하는 파라미터 값들은 무시됨


PGA는 자동 PGA 메모리 관리 기능을 사용한다고 해서 pga_aggregate_target 크기만큼의 메모리를 마리 할당해 두지는 않는다.

이 파라미터는 workarea_size_policy를 auto로 설정한 모든 프로세스들이 할당받을 수 있는 Work Area의 총량을 제한하는 용도로 사용된다.

  • Default Value

- 10MB 또는 SGA 크기의 20% 중에서 더 큰 숫자 = Greatest(10MB, SGA Size 20%)

  • 관련 파라미터

- _smm_max_size : 하나의 서버 프로세스가 사용 가능한 최대 Wokrarea 크기 - _smm_px_max_size : 하나의 병렬 실행에 속한 병렬 슬레이브들이 사용 가능한 최대 Workarea 크기 - _pga_max_size : 하나의 서버 프로세스가 사용 가능한 최대 PGA 크기

workarea_size_policy = auto 모드에서 단일 프로세스가 사용할 수 있는 최대 Work Area 크기는 인스턴스 기동 시

오라클에 의해 내부적으로 결정되며, "_smm_max_slze" 파라미터(단위는 KB)를 통해 확인 가능하다.

select a.ksppinm name, b.ksppstvl value
  from sys.x$ksppi a, sys.x$ksppcv b
 where a.indx = b.indx and a.ksppinm = '_smm_max_size';


  1. 일반적인 권고 값
    • OLTP 시스템 : (Total Physical Memory * 80%) * 20%
    • OLAP 시스템 : (Total Physical Memory * 80%) * 50%
  2. 애플리케이션 특성 및 모니터링 결과를 바탕으로 세밀한 조정 필요
    • 일반적인 목표 : Optimal 소트 방식으로 수행, 나머지(10%미만)만 Onepass 소트 방식으로 수행
    • 시스템에 Multipass 소트가 종종 발생하는 것으로 측정되면 크기를 늘리거나 튜닝이 필요한 상태임
  1. 매우 큰 Sort Area가 필요할 경우
 이 경우 큰 크기의 Worarea가 필요하지만 PGA_AGGREGATE_TARGET을 사용하는 경우 각 서버 프로세스가 사용
 가능한 최대 Workarea의 크기가 오라클에 의해 일정한 크기로 제한함
  1. 오라클에 의해 지정된 크기 이상의 Sort Area가 필요한 경우는 해당 세션에 대해서 WORKAREA_SIZE_POLICY
 값을 아래와 같이 Manual로 전환 후 SORT_AREA_SIZE 조정
SQL> alter session set workarea_size_policy = manual;
SQL> alter session set sort_area_size = 52428800;
SQL> alter session set sort_area_retained_size = 52428800;




PGA 메모리 관리방식을 지정하는 파라미터로 설정 값에 따라 작업 영역(Workarea)의 모드를 제어함 pga_aggregate_target과 연관되어 PGA 메모리를 관리함

Default - AUTO (AUTO, MANUAL)

  1. AUTO
    • PGA_AGGREGATE_TARGET에 근거를 둔 PGA 메모리를 사용 방식
    • 운영에 필요한 메모리를 많이 사용하는 작업 영역의 크기를 자동화함
  2. MANUAL
    • PGA 작업 영역의 크기 조정을 수동으로 조정하는 사용하는 방식
    • *_area_size 파라미터에 해당하는 값을 기준으로 PGA 메모리 사용을 관리함

예시)

alter session set workarea_size_policy = {auto | manual}
alter system set workarea_size_policy = {auto | manual}
  • 관련 파라미터

- sort_area_size

- hash_area_size

- bitmap_merge_area_size

- create_bitmap_area_size


  • 수동 PGA 메모리 관리 방식으로 변경 시 주의사항
    • MANUAL 모드로 설정한 프로세스는 pga_aggregate_target 파라미터 제약 받지 않음
    • sort area와 hash area를 아주 큰 값으로 설정하고 실제 매우 큰 작업을 동시에 수행한다면 가용한 물리적 메모리가
 고갈돼 페이징(Paging)이 발생하면서 시스템 전체 성능 저하 가능 (심할 경우, 시스템 마비까지 가능)
 ※ 참고) *_area_size 설정 가능 범위 : 0 ~ 2147483647 (2GB - 1Byte)
    • MANUAL 모드에서 병렬 쿼리를 사용하면 각 병렬 슬레이블 별로 sort_area_size크기 만큼의 Sort Area 사용 가능
따라서, MANUAL 모드에서 병렬도를 크게 설정할 때는 sort_area_size와 hash_area_size 반드시 확인이 필요함



3.26 sort_area_size[편집]

Oracle은 요청되는 SQL Task에 대한 처리 과정에서 여러 Sort작업을 수행하게 된다.

  1. 가능한 Real Memory내에서 Sort가 수행될 수 있도록 해야 한다.
  2. 정의된 sort_area_size가 초과되는 작업 수행 시에는 Temporary 영역을 이용한 Disk Sort를 수행하게 된다.
  3. Index Creation, Order by, Group by 등 Operation이 주로 사용되는 Sort관련 Task 이다.
  4. 최초 Sort관련 Operation 작동 시 정의된 sort_area_retained_size 만큼이 PGA영역에 할당된다.
  5. sort_area_retained_size가 초과되는 Sort Task 경우 정의된 sort_area_size가 PGA에 할당된다.
  6. sort_area_size가 초과되는 Sort Task는 Temporary Tablespace를 이용한 DISK Sort를 수행한다.
  7. 상기 Sort 영역은 PGA에 할당되므로 무리하게 큰 Size를 사용 시 다른 사용 Application에 영향을 미칠 수 있다.
    • 이는 OLTP기준으로 설정한다.(Memory의 한계성)
  8. Sort가 종료 시, 즉 마지막 Row를 Fetch하게 되면 sort_area_retained_size가 PGA Memory에 남게 된다.
   Full Db Import나 Index 생성 작업 시 sort_area_size를 증가시키면 속도가 향상될수 있다.

  • Default Value

- OS별로 다름



3.27 Parallel Processing Parameters[편집]

Parallel Processing이 적용될 수 있는 범위는 매우 다양하며, 그 중에서도

- 단순 Select 작업 (Parallel Query)

- Table 및 Index의 생성, Index Rebuild 등의 DDL 작업

- 통계정보 생성 작업 (DBMS_STATS Package)

- Parallel DML (PDML) 작업

- Datapump(expdp/impdp)를 통한 Parallel 작업

- Parallel Recovery

등은 매우 빈번하게 사용된다.

Parameter Description 비고
parallel_adaptive_multi_user enable adaptive setting of degree for multiple user streams 설정하지 않음
parallel_automatic_tuning enable intelligent defaults for parallel execution parameters 설정하지 않음
Def. = FALSE
Deprecated Parameter in 11g
parallel_degree_limit limit placed on degree of parallelism
CPU
IO
integer||설정하지 않음 (자동 설정)
Def. = CPU 
parallel_degree_policy policy used to compute the degree of parallelism (MANUAL/LIMITED/AUTO)
MANUAL
LIMITED
AUTO	
설정하지 않음
Def. = MANUAL
parallel_execution_message_size - message buffer size for parallel execution if PARALLEL_AUTOMATIC_TUNING is

set to false, then 2148bytes

 if PARALLEL_AUTOMATIC_TUNING is

set to true, then 4096 bytes

16384 유지
Def. = 16384 (OSVersion Dependent)
parallel_force_local force single instance execution TRUE 설정
Def. = FALSE 
parallel_io_cap_enabled enable capping DOP by IO bandwidth 설정하지 않음
Def. = FALSE
 PARALLEL_DEGREE_LIMIT로 대체
parallel_max_servers maximum parallel query servers per instanc- CPU_COUNT를 감안하여 설정
parallel_min_percent minimum percent of threads required for parallel query 설정하지 않음
 Def. = 0 (%)
parallel_min_time_threshold threshold above which a plan is a candidate for parallelization (in seconds)
AUTO
integer||설정하지 않음
Def. = AUTO (30 seconds)
 PARALLEL_DEGREE_POLICY가 AUTO 또는 LIMITED인 경우에 한함

parallel_min_servers minimum parallel query servers per instanc- Def. = 0 유지

D 0보다 큰 값을 설정하는 경우 Large Pool에 대해 ORA-4031 발생 빈도수가 증가할 수 있음

parallel_server_instances number of instances to use for sizing OPS SGA structures 설정하지 않음
parallel_servers_target instance target in terms of number of parallel servers 설정하지 않음

Def. = 4 * CPU_COUNT * PARALLEL_THREADS_PER_CPU * ACTIVE_INSTANCE_COUNT

 PARALLEL_DEGREE_POLICY가

AUTO인 경우에 한함 PARALLEL_MAX_SERVERS보다 작게 설정해야 한다.

parallel_threads_per_cpu number of parallel execution threads per CPU 설정하지 않음 (자동 설정)

D Def. = OS Dependent (usually 2)

4 파라미터 상세 목록[편집]

4.1 active_instance_count[편집]

RAC(Clustering)환경에서 2개의 Instance를 가지고 있는 환경일 경우 Active될 수 있는 Instance의 수를 지정한다.

1로 설정된 환경에서 첫번째 Startup된 Instance가 Primary가 되며, 다음으로 Startup된 Instance가 Secondary가 된다.

Client의 Connection은 Primary로 접속되며, Primary가 죽었을 경우 Secondary가 Primary가 된다.

4.2 always_anti_join[편집]

Oracle server가 사용할 Anti Join을 지정한다.

먼저 'NOT IN' Subquery에 대해서 Anti Join이 가능한지를 검증하고, 가능하다면 Subquery를 여기에 지정된 방식을 사용한다.

  1. All columns referenced in the subqueries are not null
  2. Subqueries are not correlated
  3. The Where clause of the outer query block does not have any ORs in it

위의 조건을 만족하지 못한다면 'NOT IN' Subquery는 Not Exists로 처리된다. (With a Filter Operation).

(NESTED_LOOPS/MERGE/HASH)

4.3 always_semi_join[편집]

Oracle Server는 가능한 더 효과적인 Access Path를 찾기위한 Optimizer의 단계로서 Query Rewrite단계를 거치게 되며

그 중 Subquery Merge단계에서 가능한 Subquery를 Join으로 해결하려고 한다.

이때 'IN', Corelated 'IN', 'EXIST' Subquery에서 Oracle server가 사용할 Semi Join을 지정한다.

먼저 Semi Join이 가능한지를 검증하고, 가능하다면 Subquery를 여기에 지정된 방식을 사용한다.

  • Default Value

- STANDART(NESTED_LOOPS/MERGE/HASH)

4.4 aq_tm_processes[편집]

AQ Message를 Monitoring(Delay 또는 Expire 속성 사용의 경우)하기 위한 Time Manager의 Process의 개수를 지정한다

  • Default Value

- 0

4.5 audit_file_dest[편집]

Auditing File이 저장될 Directory 지정(플랫폼에 따라 다름). OS의 권한으로 Login 하는 User기록

Default Value

- 첫 번째 기본값은 다음과 같음

$ORACLE_BASE/admin/ORACLE_SID/adump

- 첫 번째 기본값이 없거나 사용할 수없는 경우에 사용되는 두 번째 기본값은 다음과 같음

$ORACLE_HOME/rdbms/audit

이러한 기본값은 모두 Unix 시스템 용이며, 다른 플랫폼은 다른 기본값을 가질 수 있음

4.6 audit_trail[편집]

Audit Trail(감시) Write 여부 결정. (SQL 실행, Recode 보관) None이나 init.ora 파일에 기술되어 있지 않다면 Audit Record는 기록되지 않는다. O/S Level에서도 System Audit Trail를 Write 할 수도 있다.

DB Option 에서 활성화하면 Audit Record는 SYS.AUD$ TABLE에 기록된다. {None | False | DB | True | OS}

  • Default Value

- None

4.7 background_core_dump[편집]

Oracle Background Process의 Core File을 생성할 경우 SGA의 Dump를 만들 것인지 아닌지를 결정한다.

Full, Partial로 줄 수 있다. shadow_core_dump는 Foreground Process에 대해 적용

  • Default Value

- Partial

4.8 background_dump_dest[편집]

Oracle Background Process(PMON,SMON…..)의 Log File Destination과 Oracle Alert Log File Destination(alert_sid.log)을 지정한다.

11gR1 부터는 데이터베이스 진단 데이터를 위한 파일 기반의 Repository를 제공하는데,

ADR(Automatic Diagnostic Repository)이라는 컨셉으로 관리된다.

ADR은 기존에 bdump와 udump로 나뉘어 관리되던 Diagnostic 정보를 한 곳에 모아 관리하고 손쉽게 Oracle Support에 그 Data를 전달할 수 있도록 도와준다.

기존의 […_DUMP_DEST] 초기화 파라미터는 무시된다.

먼저 ADR_BASE의 위치는 Instance에서 diagnostic_dest 파라미터로 확인할 수 있음

(1) $ORACLE_BASE가 설정되어 있다면, diagnostic_dest의 위치는 $ORACLE_BASE

(2) $ORACLE_BASE가 설정되어 있지 않다면, diagnostic_dest의 위치는 $ORACLE_HOME/log

  • Default Value

- OS, DBMS 버전별로 다름

     ~ 10g : background_dump_dest (초기화 파라미터 설정값)
     11g R1 ~ : $ADR_HOME/trace


4.9 blank_trimming[편집]

Character처리에 있어서 Destination Size보다 큰 String을 할당할 경우 Destination Size보다 큰 부분은 Blank 처리할 것인가를 지정하는 Parameter.

False일 경우는 Destination Size보다 큰 경우는 처리되질 않는다.

  • Default Value

- False

4.10 buffer_pool_keep[편집]

가능한 한 Memory에 오랫동안 유지되어져야 하는 Segment를 위해 사용되는 Buffer Cache의 영역.

자주 사용되어지고 Cache Size의 약 10% 전/후의 크기를 가진 Segment가 이 Pool을 사용하기에 적당하다.

그러나 여기에서도 Oracle7.3 의 Cache Option과 마찬가지로 새로이 Access 되는 Segment에 의해

LRU End 쪽으로 이동하는 것이 가능하므로 항상 Cache 된다고 보장할 수는 없다.

적당한 크기로 지정하는 것이 중요한데 당연히, 동시에 Memory에 올려지기를 바라는 오브젝트들의 크기의 합보다는 커야 한다.

  • Default Value

- None

4.11 buffer_pool_recycle[편집]

자주 사용되어지지 않거나, Buffer Pool의 두 배 보다 큰 정도의 큰 Segment가 Index Search를 하는 작업 등에 사용되어지도록 한다.

buffer_pool_recycle = (buffers:<value>, lru_latches:<value>)

혹은

buffer_pool_recycle = <value>

  • Default Value

- None

4.12 commit_point_strength[편집]

여러 개의 DB가 하나의 트랜잭션에 참여하는 분산 DB 환경에서 트랜잭션이 부분적으로 Commit되고 Error가 발생하였을 경우

Recovery 과정에서 해당 트랜잭션을 Commit 또는 Rollback을 수행해야 되는데 이 파라미터 값이 가장 높은 값을 가진 DB가 기준이 된다.

따라서 기준 DB가 해당 트랜잭션을 Commit 하였으면 다른 DB도 Commit이 되고, 아직 Commit이 되지 않았으면 Rollback 되어져야 한다.

4.13 compatible[편집]

현재 Oracle Version보다 낮은 Version의 Release를 사용할 수 있도록 한다.

Oracle7 이상 Server 에서는 반드시 설정해야하며, 제약적인 사항도 있다.

StandBy DB를 이용할 경우 Primary와 StandBy는 반드시 동일하여야 하며,

값은 7.3.0.0.0 이거나 그 이상의 Version를 설정하여야 한다.

또한 UROWID(Universial ROWID : IOT 및 Foreign Table의 Row의 논리적인 Address의 표현)를 사용하는 경우는 반드시 8.1 이상을 설정하여야 한다.

4.14 control_file_record_keep_time[편집]

Control File은 각종 DB의 정보를 관리하는 Record들을 관리한다.

이들 중 순환방식(Archive Log Record들과 Backup관련 Record들)으로 관리되는 Reusable Record들을 어느 기간동안(일자) 반드시 보관되어야 할지를 지정하는 Parameter이다.

Control File에서 관리되는 Record들의 정보는 V$CONTROLFILE_RECORD_SECTION를 조회하여 확인 가능하다.

RAC일 경우는 Backup 받는 주기가 반드시 여기에 설정된 날짜 이내에 이루어 져야 한다.

  • Default Value

- 7(days)

4.15 control_files[편집]

Control File의 위치와 File명(Device명) 기술.

최대 8개 까지 지정. Control File은 Disk장애로 부터 보호하기 위하여 Multiplexing하여 서로 다른 Disk및 Controller에서 관리되어야 한다.

4.16 core_dump_dest[편집]

Core 발생시 Dump될 Directory를 지정한다. 기본 설정 값은 UNIX 매개 변수이며 플랫폼에 따라 지원되지 않을 수 있음.

11g 부터는 ADR로 관리 되어 짐.

4.17 cursor_sharing[편집]

SQL 조건절에 있는 상수 값들을 변수로 전환시켜 파싱함으로써 커서(Cursor)를 공유할 수 있도록 하는 파라미터


  • Default Value

- EXACT {EXACT | SIMILAR | FORCE}


- EXACT

└ 리터럴(Literal) 값을 모두 다른 값으로 HARD PARING 처리

└ 대소문자, 공백, 비교 상수값이 조금만 달라도 공유할 수 없음


- SIMILAR

└ 리터럴(Literal)을 바인드로 변환하면서 모든 리터럴 값에 대한 실행 계획을 확인하므로 동일한 SQL문이라

  하더라도 여러 개의 실행계획이 수립될 수 있음

└ SIMILAR로 적용되면 동일한 SQL 문에 대한 확인뿐만 아니라 바인드 값에 대한 확인까지 수행함

└ SHARED POOL에서 확인할 수 있는 SQL 문의 실제 실행 계획의 수를 줄이거나 그렇지 못할 수도 있음

└ SIMILAR로 설정하면 히스토그램이 없을 때 FORCE와 똑같이 작동한다. 그러므로 값 분포가 균등한 컬럼은

  히스토그램 없이 통계를 만들어 커서를 공유할 수 있게 하고, 값 분포가 균등하지 않은 컬럼에 대해서는
  히스토그램을 만들어 옵티마이저가 좋은 실행계획을 만들도록 돕는다면 유용할 것이지만 후자는 라이브러리
  캐시 효율에는 도움이 되지않는다.


- FORCE

└ 리터럴(Literal)을 바인드로 변환하면서 SIMILAR와는 달리 바인드 값에 대한 확인하지 않고 동일한 SQL문에

  대해서 단일 계획(One-Size-Fits-All-Plan)만을 수립

4.18 cursor_space_for_time[편집]

True이면 커서를 보관하기 위하여 Database가 많은 Space를 필요로 한다.

또한 Shared Sql Area와 Client's Private SQL Area에 영향을 준다.

Shared Sql Area가 Shared PooL에 고정되고 Open된 Cursor가 Shared Sql Area에서 참조 되어지는 동안 Shared Sql Area는 Age Out 되지 않으므로 Active Cursor의 Sql Area는 메모리에 존재하여 속도가 빠르고 사용되어지는 동안에는 Memory에 계속적으로 상주되어진다.

Shared Pool는 당연히 동시에 모든 Cursor를 보관할 수 있도록 충분한 Size를 확보하여야 한다.

또한 각 Cursor를 위해 할당되어진 Private Sql Area도 Cursor가 실행된 후에도 상주하게 된다.

1회성 비공유 SQL문장 및 SQL의 종류가 집중적으로 많이 실행되는 곳은 사용하지 않도록 한다.

4.19 db_block_buffers[편집]

SGA에 상주하는 DB BLOCK의 개수(One Block Equals One Buffer) SGA Size와 Database Performance에 큰 영향을 준다.

값이 크면 Data Block이 Memory 많이 상주하여 Disk I/O를 감소시켜 Logical Read가 많아 Performance가 향상되며

단점은 많은 양의 메모리 사용에 있다.

  • Default

- 32768

4.20 db_block_checking[편집]

Oracle이 일반 Data Block에 대한 Block Corruption여부를 Checking할 것인지를 지정한다.

시스템 및 Block에 대한 Operation(Insert/Update/Select/Delect)등에 따라 1% ~ 10%성능의 Degration의 수준이 다르다.

그러나 System Tablespace는 항상 Block Checking을 하게되어 있다.

이 Parameter는 성능의 감소를 감수할 경우만 설정하도록 한다.

  • Default Value

- False

4.21 db_block_checksum[편집]

True이면 DBWn이나 Direct Load시, Data가 Disk에 Write전에 모든 Data Block의 Checksum를 계산하여 Data Block의 정상유무를 검증한다.

Temporary Data Block Write시에도 동일하게 동작한다. System Tablespace에 대해서는 반드시 Block Checksum을 적용한다.

db_block_checksum은 Oracle DB Performance의 1~2% 정도의 영향을 주므로 이를 고려하여 설정하여야 한다.

  • Default

- False

4.22 db_block_max_dirty_target[편집]

Block Buffer에서 Dirty 상태의 Block의 Max 수를 지정하여 이 값이 이상일 경우는 DBWR가 Dirty Buffer를 Disk로 Write Out하도록 하는데 사용하는 임계치를 지정한다.

간접적으로 Crash Recovery또는 Instance Recovery시 읽어야 하는 Block의 수를 조절하여 Instance Recovery의 Time을 조절하는 역할을 한다.

1000 ~ Buffer 수 범위내에서 설정할 수 있다. Default는 Buffer수 만큼이 할당되며, 0으로 설정할 경우 이 Limit기능은 무시된다.

4.23 db_file_direct_io_count[편집]

Backup, Restore 또는 Direct Path Read/Write 기능을 사용한 I/O 를 위해 사용되어지는 Buffer 수가 되며,

I/O Buffer Size는 db_block_size x db_file_direct_io_count가 된다.

  • Default Value

- 64

4.24 db_file_multiblock_read_count[편집]

Sequential Scan(=Full Table Scan)동안 한 번의 I/O에 의하여 읽을 수 있는 최대 Block의 개수.

일반적으로 Default Value는 db_block_buffers와 process의 함수적 관계에 있다.

이 값이 OS의 최대 I/O Size를 초과시 OS의 최대 I/O Size를 사용한다.

  • Default Value

- 8

4.25 db_file_name_convert[편집]

Primary Database에 새로운 Data File의 Filename를 StandBy Database상의 Filename으로 Convert할 수 있도록 지정하는 Parameter

  • Default Value

- None

4.26 db_files[편집]

DB 운영시 Open 되어지는 최대 Datafile File의 개수. 값을 변경하기 위해서는 DB를 Restart 하여야 한다.

db_files 파라미터는 Create Database시 maxdatafiles와 유사하다.

db_files가 maxdatafiles와 동일하거나 커야만 DB가 Open 되어진다.

db_files >= 50 이거나 또는 db_block_buffers >= 10000일 경우 CKPT Process가 기동되며, 아닐 경우는 LGWR에 의해 CheckPoint Processing이 처리된다.

4.27 db_writer_processes[편집]

Multiple Database Writer는 init.ora file내의 db_writer_processes라는 Parameter에 의해 구현되며, 이것은 Oracle 8.0.4부터 제공되었다.

이것은 기존의 master-slave관계가 아닌 진정한 의미의 복수 개의 Database Writer를 사용하는 것이며, Database Writer Process들은 PMON이 Start된 후에 Start되어진다.

db_block_lru_latchs는 DBWn에게 Latch를 고루 할당 하도록 설정하여야 한다.

DBWR_IO_SLAVES가 설정된다면 1개의 DBWR이 이용되며 이 Parameter는 무시된다.
  • Default Value

- 1

4.28 dbwr_io_slaves[편집]

Oracle7에서의 mulitple DBWR Process들은 단순히 Slave Process로써, Async I/O call을 수행할 수는 없었다.

Oracle 8.0.3부터, Slave Database Writer Code가 Kernal에 포함되었고, Slave Process의 async I/O가 가능하게 되었다.

이것은 dbwr_io_slaves라는 Parameter를 통해 가능하며, I/O Slave가 asynchronous I/O가 가능하여 I/O call 이후에 Slave가 block되지 않아 더 나은 성능을 제공한다는 것을 제외하고는 Oracle7과 매우 유사하다.

Slave Process는 Instance 생성 시기가 아닌 Database Open시에 Start되기 때문에 Oracle process id가 9번부터 할당되며, OS에서 확인되는 process이름도 ora_i10n_SID와 같은 형태가 된다.

Slave Process가 초기화되고 난 후에는, Slave Process는 DBWR Timer Event를 기다리면서 Master DBWR이 Data를 전달해주기를 기다리고, Master DBWR은 Salve Process들이 I/O가 끝난다는 것을 알려주는 DBWR I/O to Slave Event를 기다리게 된다.

DBWR Slave Processing은 Main DBWR process가 각 Slave Process들에게 I/O Write를 나누어 주도록 하는 것이다.

Master DBWR이 Batch Write가 필요하게 되면, 각 Slave Process들에게 Round-Robin 방식으로 Write할 Block들을 나누어 준다.

이때 Master DBWR은 실제 I/O에는 참여하지 않으며, 단지 감독만 하면 된다.

그리고 모든 Slave Process들이 모두 I/O Request에 참여하는 것은 아니며, Write할 크기와 Salve Process의 현재 활동에 따라 달라지게 된다.

4.29 disk_asynch_io[편집]

Datafiles, Controlfiles, Logfiles들에 대한 I/O를 Asynchronous하게 제어할 것인가를 지정한다.

4.30 distributed_transactions[편집]

동시에 허용할 수 있는 분산 처리 Transaction의 개수. Transactions Parameter를 초과할 수 없다.

Snapshot or Replication등 분산 Transaction이 동시에 처리되는 수가 많다면 값을 증가시켜야 한다.

이 값이 설정되면 RECO Background Process가 기동된다.

값이 0이면 분산처리를 허용하지 않으며, DB Open시 RECO Processor가 기동되지 않는다.

4.31 dml_locks[편집]

DML(Data Manepulation Language : Insert,Update,Delete) Lock의 최대 개수. Default는 Transaction * 4가 된다.

Transaction에 의해서 각각의 테이블에 할당되어진다. (TM, TX) 값이 0이면 Enqueues가 Disable 되어지고 속도는 증가(TM를 잡지않음)하나 DROP TABLE, CRATE INDEX, ALTER TABLE, LOCK TABLE IN EXCUSIVE 등의 명령문은 사용할 수 없다.

3명의 User가 하나의 테이블을 갱신하면 3개의 Entries가 필요하고 3명의 User가 두개의 테이블을 갱신하면 6개의 Entries가 필요하다.

특히 RAC인 경우 많이 변경되는 테이블에 대해서 Performance 향상을 위해 이 기능을 Disable하여 사용할 수 있다.

  • Default Value

- Derived (4 * Transactions)

4.32 enqueue_resources[편집]

Enqueue : Oracle에서 사용되는 다른 종류의 Lock 기법.

Enqueue는 동시에 여러 Process가 기존의 리소스에 대해서 다른 Degree로 공유할 수 있는 방법을 제공한다.

가장 대표적인 예가 테이블에 대한 Lock이라 할 수 있겠다.

즉 하나의 테이블에 대해서 두개의 Process가 Share Mode나 Shared Update Mode로 Lock를 잡을 수 있다.

Enqueue는 OS의 Lock 기법을 이용하여 User가 Request한 Lock Mode에 관한 정보를 갖고 있고 OS Lock Manager는 LOCK에 걸린 리소스를 계속해서 추적한다.

만약 어떤 Process가 요구한 Lock Mode가 현재에 허용될 수 없다면 OS는 Requesting Process를 Wait Queue에 넣게 된다.

Latch : SGA안에 있는 Shared Data Structure를 보호하기 위한 저수준의 기법

Latch는 일종의 Lock 으로 굉장히 빨리 Acquire 되거나 Free 되며 일반적으로 하나의 Process가 어느 한 순간에 실행하는 Piece Of Code를 다른 Process로 부터 보호한다.

Enqueue와 차이점은 Ordered Queue를 사용하지 않는다는 것이다.

Latch를 기다리는 Process들은 Timer를 이용하여 일정 기간 후 Wakeup하여 다시 Latch를 잡으려고 하고 이를 Spin이라 한다.

모든 Waiting Process들이 동시에 Retry 하게 되므로 누가 먼저 대기하느냐에 관계없이 Latch를 잡을 수 있다.

Enqueue는 Lock Manager에 의해 Lock 되어지는 리소스 개수.

Enqueue_Resource는 Sessions에서 파생되며 10 Session이상일 경우

((SESSIONS - 10) * 2) + 55이며 DML_LOCKS + 20이상 지정되면 이 값이 사용된다.

4.33 event[편집]

Instance Level의 Debug 등의 목적으로 Event를 걸 때 사용.

4.34 fast_start_io_target[편집]

1,000 ~ Buffer 수까지 지정가능하며 Default는 Buffer수 이다.

이 값은 db_block_max_dirty_target보다 더 정확하게 Crash Recovery 또는 Instance Recovery 동안에 읽어 들여야 할 I/O 수의 한계값을 지정하는데 사용한다.

DBWn이 Dirty Buffer를 Disk로 기록할 경우 이 값보다 Recovery시 읽어들여야 할 I/O의 한계이 작도록 고려되어 Write Out 한다.

작은 값일 수록 Crash Recovery 또는 Instance Recovery이 시간이 짧아질 수있으며, 0일 경우 이 기능은 Disable된다.

관련 Parameter : log_checkpoint_timeout, log_checkpoint_interval

V$INSTANCE_RECOVERY에서 각 경우별 Recovery발생시 처리해야할 Redo Block을 확인할 수 있다.

4.35 fast_start_parallel_rollback[편집]

Parallel Rollback을 사용하여 Process의 수를 구분하기 위해 설정한다.

False | LOW | HIGH 값이 올 수 있으며,

False는 사용하지 않으며, LOW는 2 * CPU_COUNT 내로, HIGH는 4 * CPU_COUNT 내로 제한한다.

그러나 Single Process에 의해 처리되는 경우보다 오히려 늦게 처리되는 경우도 있다.

  • Default Value

- Low

4.36 gc_defer_time[편집]

RAC 관련 파라미터로 다른 Instance로 부터의 Hot Backup을 위해 다른 Instance에게 Disk로 Write Out을 하기 전에 Buffer의 Clean Out 등의 시간을 주기 위하여 사용되며, 해당 시간 이후에는 강제로 Write Out 하도록 한다.


4.37 gc_files_to_locks[편집]

RAC 관련 파라미터로 각 Datafile에 할당되어지는 PCM Locks수

1 = 300 : 2 = 100 : 1번 Datafile에 300개, 2번 Datafile에 100개 할당.

1-2 = 4 : 1, 2번 Datafile에 걸쳐서 총 4개의 PCM Locks 할당

1-2 = 4!8 : 8개의 Contiguous Block으로 총 4개의 PCM Lock 할당.

Sequencial I/O가 일어나는 경우.

1-2 = 4!4EACH : 1, 2번 각기 4 Contiguous Block으로 각각 4개의 PCM Lock 할당. 총 8개 할당

4.38 gc_releasable_locks[편집]

RAC 관련 파라미터로 Find Grained Locking에 할당되어진 Lock 최대 개수.

Default로서 db_block_buffers로 설정된다.

4.39 gc_rollback_locks[편집]

RAC 관련 파라미터로 동시에 변경되는 Rollback Segment에 부여하는 Distributed Lock 수 정의.

다른 Instance가 Block의 Read Consistent를 요구할 때 Rollback Segment Block를 Disk에 Write 할 때 사용된다.

4.40 global_names[편집]

Database Link를 사용할 경우 연결되어지는 쪽의 DB 이름이 DB Link 이름과 동일한지 아닌지를 검증할 것인가를 결정한다. True이면 같아야 하고 False이면 검증하지 않음

4.41 hash_area_size[편집]

Hash Join 하기 위해 사용되어지는 Memory 최대 Size. 설정하지 않는다면 sort_area_size x 2 이고 DB restart 없이 "ALTER SESSION" 명령을 이용하여 설정 값을 변경할 수 있다.

4.42 hash_join_enabled[편집]

Optimizer가 Hash Join의 Plan을 사용할 것을 지정한다. Alter Session을 이용하여 설정값 변경 가능

  • Default Value

- True

4.43 hash_multiblock_io_count[편집]

Hash Join를 사용할 경우 한번에 읽거나 쓰여지는 Block의 개수. 설정하지 않으면 Query에 종속적이며, OS의 Max I/O Size보다 작아야 한다. Alter Session, Alter System을 이용하여 설정값 변경 가능하다. 그러나 이 값은 가능한 설정하지 않도록 한다.

내부적으로 Query에 따라 적절한 값으로 Query마다 설정값이 다르다.

4.44 hi_shared_memory_address[편집]

Instance Startup시 SGA의 Starting Address를 지정한다.

4.45 hs_autoregister[편집]

Heterogeneous Services(HS) Agent들의 Automatic Self-Registration을 Enable/Disable 한다.

4.46 instance_groups[편집]

RAC Option으로 포함 시키려는 Group명을 지정하며, Parallel Query의 Slave의 할당을 위해 같은 Instance Group이 사용됨.

4.47 instance_name[편집]

Single Instance에서는 주로 SID와 같다. RAC 에서는 Client에서 Connection시 Load Balance등에 사용되는 Unique한 이름을 설정한다.

4.48 instance_number[편집]

RAC Parameter이며 Free Space Lists Group을 할당하기 위해서 사용되어 지는 Unique한 Instance Number를 지정한다.

  • Default Value

- 가능한 가장 낮은 수 (인스턴스 시작 순서 및 다른 인스턴스에 할당 된 instance_number 값에 따라 다름)

4.49 java_max_sessionspace_size[편집]

Java Program을 Server상에서 실행시킬 경우 Max Session Size를 지정

4.50 java_pool_size[편집]

Java Method나 Class 설정 등을 위한 Java Pool을 위한 Memory를 할당한다.

4.51 job_queue_interval[편집]

SNP Background Process의 Wake_Up Interval Time. 범위는 1~3600까지 설정할 수 있다.

  • Default Value

- 60초

4.52 job_queue_processes[편집]

각 Instance의 SNP Backgroud Process의 개수.

SNP x Process는 Automatic Propagation 또는 Automatic Snapshot Refresh 등을 수행한다.

0 ~ 36개 까지 설정할 수있으며 DBMS_JOB Package에 의해 설정된 Job의 실행에 관여한다.


4.53 large_pool_size[편집]

MTS의 Session Memory 및 parallel_automatic_tuning = True로 되어 있을 경우

Parallel Execution Message Buffer로, Backup Process이 Disk I/O Buffer를 위해 사용되는 Memory를 설정한다

4.54 license_max_sessions[편집]

동시에 허용되어지는 User Session의 개수 설정.

설정 값에 도달하게 되면 Restricted Session 권한을 가진 User만 연결되며 일반 Session들이 접속하게 되면 Warning Message를 받게 된다.

0 이면 제한를 받지 않지만 특정 값을 설정하게 되면 license_sessions_warning을 설정하여 Warning Message를 받게 한다.

Licensing과 User Licensing를 동시에 설정할수 없으므로 반드시 license_max_sessions이나 license_max_user 중의 하나는 0 이어야 한다.

4.55 license_max_users[편집]

Database에 생성되어 지는 User 개수 설정.

제한 값에 도달하게 되면 User는 더 이상 생성될 수 없고 제한 값을 증가 하여야 한다.

Licensing과 User Licensing를 동시에 설정할 수 없으므로 반드시 license_max_sessions이나 license_max_user 중의 하나는 0 이어야 한다.

4.56 license_sessions_warning[편집]

User Session의 접속 시 일정한 수(=license_sessions_warning)에 도달하면 경고 Message를 받도록 Session 제한폭을 설정함.

제한폭에 도달하면 User Session는 연결은 되지만 Alert File에 Message Write. 0 이면 경고 메시지 없음.

Restricted Session 권한을 가진 User가 Login하게 되면 경고 Message를 알리게 된다.

4.57 lm_locks[편집]

RAC 관련 Parameter이며 PCM과 Non PCM Lock의 전체 개수를 지정한다. (= PCM + NonPCM lock 개수)

L = R + (R*(N - 1))/N - L = the total number of locks - R = the number of resources (as determined by the LM_RESS parameter). - N = the total number of nodes

  • Default Value

- 12000

4.58 lm_ress[편집]

각각의 Lock Manager Instance에서 lock할 수 있는 리소스의 개수를 지정한다. (PCM + NonPCM resource 개수를 지정)

- PCM Resources = gc_files_to_locks(Fixed locks only) + (gc_releasable_locks * instances) + gc_rollback_locks(Fixed locks only)

- Non PCM Resources = ((processes + dml_locks + transactions + enqueue_resources + enqueue_locks + pq_overhead + overhead) * instances) + db_files

4.59 local_listener[편집]

local Net8 listeners를 기술한다. ""(ADDRESS_LIST = (Address = (Protocol = TCP)(Host=localhost) (Port=1521)) (Address=(Protocol = IPC)(Key= DBname)))""

4.60 lock_name_space[편집]

Distributed Lock Manager(DLM)이 Lock Name을 생성할 떄 사용되는 이름을 지정한다.

Cluster 환경하에서 StandBy DB또는 Clone DB가 Primary DB와 같은 Cluster상에 같은 DB명을 사용할 경우 이 값의 셜정을 고려한다.

4.61 lock_sga[편집]

전체 SGA를 페이징 또는 스와핑이 일어나지 않도록 Physical Memory에 둘 것인가를 지정한다. 플랫폼마다 지원여부가 다르며 지원되지 않을 경우 무시된다.

4.62 log_archive_dest[편집]

Archive Log File의 Destination의 Directory를 지정한다. log_archive_dest_n과 같이 사용될 수 없으며, Raw Partition은 사용될 수 없다.

4.63 log_archive_dest_1[편집]

Archived Log File의 Destination을 여러곳에 두고자 할 경우 설정한다.

Location = xxx일 경우는 Local File System에 해당되고 Service = xxx일 경우는 Remote(또는 StandBy DB)에 해당된다.

Mandatory는 Online Redo Log File이 재사용되기 전에 반드시 설정된 Destination으로 Archiving이 되어야 한다.

V$ARCHIVE_DEST View로 현재의 설정여부를 확인할 수 있다.

((SERVICE=tnsnames_service | LOCATION=local_pathname) [MANDATORY | OPTIONAL] [REOPEN[=integer]] )

4.64 log_archive_dest_state_1[편집]

지정된 Archive Destination에 대해 다음에 오는 Archive Operation(Automatic 또는 Manual)대해 반영여부.

4.65 log_archive_duplex_dest[편집]

Duplex Archive Destination을 지정하기 위해 사용된다.

반드시 Archiving이 성공되어야 하는 개수는 log_archive_min_succeed_dest 파라미터로 지정한다.

1일 경우는 log_archive_dest에서 설정한 Directory는 Archiving이 반드시 성공 되어야 하며, 2일 경우는 log_archive_dest, log_archive_duplex_dest에서 지정된 Directory에 Archiving이 모두 성공해야 한다.

4.66 log_archive_format[편집]

Archive File의 File Name Type 지정 (%S : Log Sequence Number, %T : Thread Number)

4.67 log_archive_max_processes[편집]

Archiver Background Processes(ARC0 ~ ARC9)의 log_archive_start = True일 경우 Instance의 Startup시 초기의 Archived Process의 설정치를 지정하며, log_archive_start = False일 경우 SQL에 의한 Archive Operation시 기동된다.

실제 Actual한 ARCx의 수는 Archiving의 작업량에 따라 좌우된다.

4.68 log_archive_min_succeed_dest[편집]

반드시 Archiving이 성공되어야 하는 개수는 log_archive_min_succeed_dest 파라미터로 지정한다.

1일 경우는 log_archive_dest에서 설정한 Directory는 Archiving이 반드시 성공 되어야 하며, 2일 경우는 log_archive_dest, log_archive_duplex_dest에서 지정된 Directory에 Archiving이 모두 성공해야 한다.

4.69 log_archive_start[편집]

Archiving을 Automatic로 할건지 Manual 할건지를 결정하는 파라미터(True : Automatic, False : Dba Manual). 'Archive Log Start Or Stop' 명령이 우선된다.

4.70 log_archive_trace[편집]

Archived Log Process(ARC0 ~ ARC9)에 의해 생성되는 Trace Output정보(Trace Level)의 내용을 조절한다. - 0 : Disable archivelog tracing (this is the default) - 1 : Track archival of REDO log file - 2 : Track archival status of each archivelog destination - 4 : Track archival operational phase - 8 : Track archivelog destination activity - 16: Track detailed archivelog destination activity - 32: Track archivelog destination parameter modifications - 64: Track ARCn process state activity

4.71 log_buffer[편집]

SGA 안에 존재하는 Redo Log Buffer에 할당된 Byte 수. Transaction이 길거나 양이 많을 경우 File I/O를 감소시키기 위해서 크게 설정. 작업량이 빈번할 경우에는 log_buffer의 Size 크기는 무의미하다.

참고로 Log Space Request Ratio(= redo log space request / redo entries) 이 비율이 0.0001 보다 크다면 순환 사용하는 Redo Log Buffer가 너무 작으므로 log_buffer를 증가 시켜야 한다.

  • Default Value

- 500K 또는 128K*CPU개수

4.72 log_checkpoint_interval[편집]

Redo Log File Block에 어느 정도 채워져야 CheckPoint를 발생시키는가를 결정. 이 값이 없으면 항상 Log Switch 발생시 CheckPoint 발생. 설정 값이 실제 Redo Log Size보다 크면 Switching Log시 마다 CheckPoint 발생. (Redo Log File Block의 수(=OS Block Size)=> v$Archived_log에서 Block Size로 OS Block Size를 확인할 수 있다.)

(참고) CheckPoint발생 시점 1. Alter system switch logfile 2. Alter system CheckPoint (local or global) 3. Alter tablespace begin backup 4. Alter tablespace offline (normal, temporary) 5. Instance shutdown (normal,Immediate) 6. Log file switch normal 7. Log file switch stuck (log file switch stuck는 CheckPoint는 일어났지만 완전히 끝나지 않은 상태이며, Log Switch는

   Unsuccessful임을 의미한다. Log switch가 필요할 경우 대상 Log File이 아직도 그 전 CheckPoint와 관련되어 있는
   경우 Oracle은 그 전 CheckPoint 작업을 Speed Up 하도록한다)

8. log_checkpoint_timeout (init.ora) 9. log_checkpoint_interval (init.ora)

4.73 log_checkpoint_timeout[편집]

CheckPoint 발생 후 다음 번 CheckPoint 발생 시점까지의 대기시간. 설정 값이 0 이면 Time_Based CheckPoint를 실행하지 않는다.

4.74 log_checkpoints_to_alert[편집]

CheckPoint가 일어난 시기를 alert.log 파일에 기록할지를 지정하는 것으로 얼마나 자주 CheckPoint가 발생하는지 확인 할 수가 있다.


4.75 log_file_name_convert[편집]

Primary Database에 새로운 Log File의 Filename를 StandBy Database상의 Filename으로 Convert 할 수 있도록 지정하는 파라미터

4.76 max_commit_propagation_delay[편집]

RAC 환경에서 SCN Generation Scheme의 사용을 지정하는 파라미터.

max_commit_propagation_delay < 700 으로 세팅하면 DLM Lock SCN Generate Scheme을 사용하며,

700 이상으로 세팅되어 있으면 Lamport SCN Generation을 사용

4.77 max_dump_file_size[편집]

Alert File을 제외한 Trace 파일의 O/S System 최대 Block 개수. Unlimited일 경우 제한이 없지만 너무 크게 설정할 경우 Trace File에 의한 File System의 Full이 발생하지 않도록 한다.

  • Default Value

- 10000 blocks

4.78 max_enabled_roles[편집]

Sub-Roles 까지 포함하여 User에게 부여할 수 있는 최대 Roles의 개수. User에게는 max_enabled_roles + 2(Public, User 자신의 Role)의 Role이 최대로 지정될 수 있다.

  • Default

- 20

4.79 max_rollback_segments[편집]

SGA내의 Rollback Segment Cache의 최대 Size. 하나의 Instance에 의해서 동시에 Online 되어 질 수 있는 최대 RBS 개수

  • Default

- max(30, transactions / transactions_per_rollback_segment)

4.80 mts_circuits[편집]

MTS 사용시 Inbound와 Outbound의 전체 Virtual Circuits(Dispatcher와 Server Process와의 가상 연결관계)의 수를 지정

  • Default

- MTS 환경이면 Session 파리미터, 그렇지 않으면 0

4.81 mts_dispatchers[편집]

Oracle Instance Start Up시 기동되는 Dispatchers 수 및 환경 설정 파라미터(여러 개 가능 (TCP/IP, DECNET))

  • Default

- NULL

4.82 mts_listener_address[편집]

필요한 SQL*NET LISTENER ADDRESS지정. MTS_LISTENER_ADDRESS = (ADDRESS = (PROTOCOL=TCP)(HOST=xxx.xx.xx.xx)(PORT=1521))

  • Default

- 8.1.3부터 더 이상 사용하지 않음

4.83 mts_max_dispatchers[편집]

동시에 기동시킬 수 있는 Dispatchers 최대수 지정

  • Default

- Dispatchers 환경이 구성되어 있다면 Greatest(5, Dispatchers 구성 수)

4.84 mts_max_servers[편집]

MTS 사용시 기동시킬 수 있는 Shared Server 최대수 지정

  • Default

- 20

4.85 mts_multiple_listeners[편집]

MTS_LISTENER_ADDRESS를 여러 개 지정할 경우 사용

  • Default

- 8.1.3부터 더 이상 사용하지 않음

4.86 mts_servers[편집]

Oracle Instance Startup 시에 기동 되는 Server Process 개수

  • Default

- 1

4.87 mts_service[편집]

Dispatcher에 할당되어지는 Service명(Instance명를 입력하면 됨). 설정을 하지 않으면 db_name과 동일하게 설정된다.

  • Default

- 8.1.3부터 더 이상 사용하지 않음

4.88 mts_sessions[편집]

MTS에서 허용 가능한 전체 Session수를 지정

  • Default

- LEAST(MTS_CIRCUITS, SESSIONS - 5)

4.89 nls_calendar[편집]

Oracle의 Calendar 시스템을 지정하기 위해 사용. 이 값에 따라 Date FormaT이 바뀔 수 있다.

  • Default

- Gregorian

4.90 nls_comp[편집]

주로 Where 절에서 NLSSORT Function을 지정하지 않을 경우 Binary로 비교된다 {BINARY | ANSI}. 그러나 ANSI일 경우 NLS_SORT에서 지정한 Linguistic 비교를 하게된다.

  • Default

- BINARY

4.91 nls_currency[편집]

Local Currency의 통화 단위의 문자열을 나타내기 위하여 사용된다.

  • Default

- Derived

4.92 nls_date_format[편집]

TO_DATE, TO_CHAR 등의 함수를 사용할 때 기본 날짜 형식을 지정하기 위해 사용된다. 지정하지 않을 경우 NLS_TERRITORY에 의해 좌우된다.

  • Default

- Derived

4.93 nls_date_language[편집]

날짜의 스펠링을 위해서 사용된다. 지정하지 않을 경우 NLS_TERRITORY에 의해 좌우된다.

  • Default

- OS별로 다름

4.94 nls_dual_currency[편집]

해당 Territory의 Dual Currency를 지정한다.

  • Default

- Dual currency symbol

4.95 nls_iso_currency[편집]

통화 숫자형식을 위한 International Currency를 위해서 사용될 문자열 지정한다. 지정하지 않을 경우 NLS_TERRITORY에 의해 좌우된다.

  • Default

- Derived

4.96 nls_language[편집]

Database의 Default Language를 지정한다.

  • Default

- OS별로 다름

4.97 nls_numeric_characters[편집]

숫자의 구분자로 사용된다.

  • Default

- Derived

4.98 nls_sort[편집]

Binary로 지정할 경우 Character의 Numeric Value를 기준으로 소팅한다. Default 값은 NLS_LANGUAGE값에 따라 좌우된다.

  • Default

- Derived

4.99 nls_territory[편집]

Territory를 지정한다. Day, Week Numbering에 영향을 준다.

  • Default

- OS별로 다름

4.100 nls_time_format[편집]

Time Data Type에 대한 Format 지정

  • Default

- None

4.101 nls_time_tz_format[편집]

Time With Time Zone Data Type에 대한 Format 지정

  • Default

- None

4.102 nls_timestamp_format[편집]

Timestamp Data Type에 대한 Format 지정

  • Default

- None

4.103 nls_timestamp_tz_format[편집]

Timestamp With Time Zone Data Type에 대한 Format 지정

  • Default

- None

4.104 O7_DICTIONARY_ACCESSIBILITY[편집]

Oracle7에서 Oracle8i로의 Migration시 사용되는 Parameter

  • Default

- False

4.105 object_cache_max_size_percent[편집]

Session Object Cache의 Max size를 지정하는 것으로 Max Size는 (object_cache_optimal_size + (object_cache_max_size_percent * object_cache_optimal_size))이며 이 값 이상이 될 경우 Shrink를 수행하며, object_cache_optimal_size까지 줄어든다. 이 Object Cache는 Session에서 사용되는 Object정보를 가져오기 위한 Server와의 Roundtrip을 줄이기 위한 Memory Block이다.

  • Default

- 10%

4.106 object_cache_optimal_size[편집]

Session Object Cache가 Max Size를 초과했을 경우 줄어들 Optimal Size를 지정.

  • Default

- 100 Kbytes

4.107 open_cursors[편집]

Single User Process에 의해서 동시에 Open 되어지는 최대 Cursor 개수

  • Default

- 64

4.108 open_links[편집]

User Process당 동시에 Open 되어지는 Remote Database 최대 개수 설정. 설정치는 하나의 SQL 문장이 실행될 때 참조하는 모든 Database의 수와 동일하거나 크게 설정할 수 있다. 많은 다른 DB를 참조할 때 시간 초과가 발생하면 설정 값을 증가한다. 만약 Query가 A, B, C DB를 Access하는데 open_link가 2로 설정되어 있다면 Query는 하나의 Connection이 끊어지거나 다른 Connection이 만들어 질 때까지 Waiting 하게 된다.

  • Default

- 4

4.109 open_links_per_instance[편집]

Migratable Open Connections의 수를 지정한다. XA Transactions은 Migratable Open Connections을 사용하며, Transaction이 Commit된 후에도 Connection이 Cache화 되어 남아 있게 된다. 같은 User의 Transaction이 들어오게 되면 이전의 Cache화 되어 있던 Connection을 사용하게 된다.

  • Default

- 4

4.110 optimizer_features_enable[편집]

Oracle Release Number를 바탕으로 Optimizer를 제어할 수 있는 파라미터 값을 사용할 수 있도록 저장하는 파라미터. 예를 들어 8.0.5에서 8.1.5로 Upgrade 했을 경우 8.0.5의 Optimizer 상태를 유지하고 싶을 경우 8.0.5로 설정 할 수 있다.

  • Default

- 8.0.0

4.111 optimizer_index_caching[편집]

Cost-Base Optimizer가 Nested Loop Join을 선호하도록 조절하는 파라미터. Nested Loop Join시 Buffer Cache내에 Inner Table의 Index를 Cache화 하는 비율(%)를 지정하므로 Nested Loop Join시 성능의 향상을 가져오며, Optimizer는 Cost계산시 이 비율을 반영하여 Nested Loop Join을 선호하도록 Plan이 선택된다.(0~100)

  • Default

- 0

4.112 optimizer_index_cost_adj[편집]

Optimizer가 Index를 사용하는 위주의 Plan으로 풀릴 것인지 또는 가능한 사용하지 않을 쪽으로 풀릴 것인지의 비중을 지정한다. Cost-Base Optimizer는 Rule Base처럼 Index를 사용하도록 Plan이 주로 만들어 지게 되나, 반드시 index가 있다고 Rule Base처럼 Index를 이용한 Plan으로 처리되는 것은 아니다. Index를 이용한 Plan위주로 하고자 한다면 100(%) 이상을, 가능한 Index를 사용하지 않고자 한다면 100 이하를 지정한다. (1 ~ 10000)

  • Default

- 100

4.113 optimizer_max_permutations[편집]

From 절에 해당 테이블들에 대한 경우의 수(n!)만큼 Nested Loop Join, Hash Join, Sort Merge Join의 경우에 대해서 Cost를 계산하게 되며, Table이 많을 경우 Parsing Time에 대한 Overhead가 커지게 된다. 이 경우 Plan을 계산할 경우의 수를 제한 하고자 할 경우 쓰이게 된다. Default는 80,000이며 이 값이 작을수록 Parsing Time은 줄어든다. 그러나 개발자들은 From절의 Table의 순서에 대해 신경을 써야 한다.

  • Default

- 80000

4.114 optimizer_mode[편집]

Optimizer 지정(CHOOSE, FIRT_ROWS, ALL_ROWS, RULE)

  • Default

- CHOOSE

4.115 optimizer_percent_parallel[편집]

Optimizer가 Parallel Plan으로 가고자 하는 비중을 지정한다. 0일 경우 Serial Plan을 선택하며, Optimizer가 Index를 이용한 Serial로 갈 것인지 Object의 Parallelism을 Cost 계산에 사용하여 Full Table Scan을 이용한 Parallel을 선호할 것인지의 비중을 지정한다. (0 ~ 100)

  • Default

- 100

4.116 oracle_trace_collection_name[편집]

Oracle Trace Collection Name

  • Default

- NULL

4.117 oracle_trace_collection_path[편집]

Oracle Trace File Destination, Log 위치

  • Default

- OS별로 다름

4.118 oracle_trace_collection_size[편집]

Oracle Trace File 최대 Size

  • Default

- 5242880

4.119 oracle_trace_enable[편집]

Oracle Trace Facility 설정

  • Default

- False

4.120 oracle_trace_facility_name[편집]

Oracle Trace Facility Name

  • Default

- oracled

4.121 oracle_trace_facility_path[편집]

Oracle Trace Facility File 위치

  • Default

- OS별로 다름

4.122 os_authent_prefix[편집]

OS Level의 Userid/Pwd로 Login한 User를 DB의 Login을 허용하며, OS User에 이 파마리터에서 설정된 문자열을 결합하여 DB Login ID로 사용한다.

  • Default

- OS별로 다름

4.123 os_roles[편집]

Operating System에 의해 Username에 대한 Role을 사용할지의 여부 지정.

  • Default

- False

4.124 parallel_adaptive_multi_user[편집]

Multi User환경에서 Parallel Execution을 사용할 경우 Adaptive Algorithm(Query가 Startup하는 시점에 시스템의 부하를 판단하여 요청된 Degree로 Parallel을 수행할 것인지 또는 Degree를 자동으로 낮출 것인지를 판단하여 결정)을 사용할 지의 여부를 지정한다. True일 경우 Adaptive Algorithm을 사용한다. 이 경우 parallel_automatic_tuning이 True로 Degree는 Default를 사용한 것으로 가정한다.

  • Default

- parallel_automatic_tunning이 True면 True 그렇지 않으면 False

4.125 parallel_automatic_tuning[편집]

이 값이 True로 설정될 경우 Oracle에서 Parallel 실행에 대한 적절한 실행 파라미터를 설정하여 실행하도록 할때 사용된다. 이 값이 설정되면 Parallel Execution을 위한 Message Buffer를 Shared Pool을 사용하지 않고 Large Pool을 사용하므로 Shared Pool을 다소 줄일 수 있다.

  • Default

- False

4.126 parallel_broadcast_enabled[편집]

Hash Join또는 Merge Join을 실행할 경우 Small Set(Row개수 측면 보다는 Size 측면에서)과 아주 큰 Large Set과의 Join일 경우 Small Results Set을 Large Results Set과의 Join을 처리하고 있는 Parallel Server에 Copy Set을 보내서 처리함으로서 성능을 향상시키는 방법.

  • Default

- False

4.127 parallel_execution_message_size[편집]

Parallel Execution(Parallel Query, PDML, Parallel Recovery, Replication)을 위한 Message Size를 지정한다. Default 값이 대부분 적당하며, 큰 값일수록 Larger Shared Pool이 필요하다. Parallel_Automatic_Tuning이 설정되면 Parallel Execution을 위한 Message Buffer를 Shared Pool을 사용하지 않고 Large Pool을 사용

  • Default

- OS 시스템에 종속적임(OS에 따라 다를 수 있음)

4.128 parallel_instance_group[편집]

RAC 관련 파라미터로서 Parallel Slave Process를 기동할 때 같은 parallel_instance_group에 속해 있는 Instance에서만 기동 시키게 된다.

  • Default

- Group Consisting Of All Instances Currently Active

4.129 parallel_max_servers[편집]

Instance당 기동할 수 있는 Query Server나 Parallel Recovery Process 최대 개수. 너무 크게 설정될 경우 운영 Peak 시기동안 Memory 부족현상이 나타날 수 있다.

  • Default

- cpu_count, parallel_automatic_tuning, parallel_adaptive_multi_user 값에 영향을 받는다.

4.130 parallel_min_percent[편집]

필요한 Parallel Degree를 사용할 수 없다면 Query를 실행하지 않는다. 만일 8 개의 PQP가 필요한데 parallel_min_percent가 50이면 최소한 4개 PQP가 필요하다. 만일 사용 가능한 PQP 수가 계산된 최소치 보다 적다면 Query는 Error와 함께 종결되고, 필요한 최초 개수 보다 크다면 Query는 효율적인 병렬화를 감소시키면서 사용 가능한 Query Server Process와 함께 실행될 것이다. PQP의 수가 적더라도 해당 파라미터가 설정되지 않았다면 사용 가능한 수의 PQP를 가지고 Query를 수행한다. (PQP = Parallel Query Process) 최악의 경우 하나의 프로세스로 수행할 수 있으므로 값을 50정도로 설정하는 것이 바람직하다.

  • Default

- None

4.131 parallel_min_servers[편집]

Instance당 기동할 수 있는 Query Server나 Parallel Recovery Process 최소 개수. Instance Startup시 Parallel Process가 기동된다. 0 ~ parallel_max_servers 만큼을 지정할 수 있다.

  • Default

- 0

4.132 parallel_server[편집]

Parallel Server 옵션은 Enable 또는 Disable 이다.

  • Default

- False

4.133 parallel_server_instances[편집]

RAC 관련 파라미터로서 현재 설정된 Instance의 개수를 설정한다.

  • Default

- 1

4.134 parallel_threads_per_cpu[편집]

이 값은 해당 Instance에 대한 Parallelism에 대한 Default Degree를 지정하며, Parallel Adaptive 및 Load Balancing Algorithm에 사용된다. 즉 Parallel execution Process의 수 또는 Parallel Execution 동안 한 CPU가 다룰 수 있는 Thread 수를 나타낸다.

  • Default

- OS별로 다름, 보통은 2

4.135 partition_view_enabled[편집]

partition_view_enabled의 Parameter는 Partition View를 사용할 경우에 Optimizer가 불필요한 Table의 Access를 Skip하도록 하기위한 기능이며, 전체 Table의 Cardinality를 계산하는 방식이 아니고 각 Table의 Cardinality를 이용하게 하는 기능으로 Partition View의 Cost를 작게 계산되도록 하여 Plan을 유도하는데 사용한다.

  • Default

- False

4.136 plsql_v2_compatibility[편집]

PL/SQL.V2 level을 호환되게 지정한다. False일 경우 PL/SQL V8이 사용된다.

  • Default

- False




4.137 pre_page_sga[편집]

Instance가 처음 기동될 때 Sahred Memory에 설정되는 모든 SGA를 접근 하므로서 실제 메모리로 SWAP IN 한다. 이렇게 함으로서 Page Fault를 다소간 방지할수 있지만 기동시 약간의 시간이 더 걸릴 수 있다. 충분한 Physical Memory가 있을 경우 사용한다.

  • Default

- False





4.138 processes[편집]

Oracle Server에 동시에 접속할 수 있는 최대 Process 개수 Backgroup Process도 포함된다(DBWR, LGWR, PMON, SMON, CKPT…). sessions, transactions 파라미터도 이 값에 의해 파생된다.

  • Default

- parallel_max_servers 파라미터에 종속적임




4.139 query_rewrite_enabled[편집]

Optimizer가 Query Rewrite(더 나은 Plan을 찾기 휘한 Cost Base Optimizer의 수행되는 단계)의 수용여부 지정 - View Merging - Subquery Merging - Transitivity (CBO only) - Materialized Views (CBO only)

  • Default

- False




4.140 query_rewrite_integrity[편집]

Query Rewrite의 수준을 지정한다. {Enforced | Trusted | Stale_Tolerated} RAC에서 노드(인스턴스)별 다른 값을 가질 수 있다.

  • Default

- Enforced




4.141 rdbms_server_dn[편집]

Oracle Server의 Distinguished Name. Enterprise Directory Service에서 사용된다.

  • Default

- None




4.142 read_only_open_delayed[편집]

Read Only Tablespace에 대해서 Database Open Time시 Open 하지 않고 처음 Access할 때 Open 할 수 있도록 하여 Database의 빠른 Open을 원할 경우 사용. Read Only Tablespace들이 Slow-Access Devices또는 Hierarchical Storage 등에 있을 떄 유용하다.

  • Default

- False




4.143 recovery_parallelism[편집]

Parallel Recovery 시에 사용되는 ProCESS개수. 0 이면 하나의 Process가 Recovery 수행. Instance가 Down 되었을 때 Recovery를 빠르게 수행할 수 있도록 값을 설정하면 유리하다.

  • Default

- OS별로 다름




4.144 remote_dependencies_mode[편집]

Session이 Remote Stored Procedures 들에 대해서 어떠한 Dependencies(Timestamp 또는 Signature)에 의해서 다룰 것인가를 지정한다. Timestamp일 경우는 Local Object보다 이후에 변경된 Object들에 대해서는 Recompile이 필요하나, Signature일 경우는 필요치 않다. Invalid Object일 경우 가끔 Dead Lock이 발생할 수 있다. 이때는 Invalid를 확인하고 해결한다.

  • Default

- Timestamp




4.145 remote_login_passwordfile[편집]

Remote 장비를 통해 Oracle Database에 접근하는 경우가 존재한다. 즉, PC를 통해 OS의 인증과정을 거치지 않고 접근할 수 있다는 것이다. 이러한 경우, 사용자 검증작업은 Oracle Password File을 통해 이루어질 수 있고, 이 Oracle Password File은 'orapwd' 명령을 사용하여 생성되고 관리된다. 서버내 Password File은 $ORACLE_HOME/dbs에 생성되고, 단위 Database을 위한 Username과 Password를 저장하고 있다. 만약, 여러 개의 Database가 동일 시스템에 존재하고 Password를 설정할 경우는 각각 별개의 Password File을 생성한다. Database가 Password File을 사용하도록 하기 위해서는 initSID.ora 내에 remote_login_passwordfile을 Exclusive로 설정한다.

  • Default

- None




4.146 remote_os_authent[편집]

Remote OS Clients의 접속을 허용하도록 지정. 이 값은 os_authent_prefix의 값을 가지고 DB접속을 허용한다.

  • Default

- None




4.147 remote_os_roles[편집]

Remote Clients의 OS Role을 허용한다.

  • Default

- False




4.148 replication_dependency_tracking[편집]

Database에 대한 Read/Write Operations에 관한 Dependency Tracking을 하도록 한다. Dependency Tracking은 Replicate 환경 하에서 DB의 변경사항을 Replication Site로 Parallel로 반영하기 위해 필요한 사항이다.

  • Default

- False




4.149 resource_limit[편집]

Database Profile에 설정된 자원 제한(Resoruce Limit) 사용 여부 결정

  • Default

- False




4.150 resource_manager_plan[편집]

Instance에 대한 Top-Level Resource Plan을 지정한다. Resource Plan은 Resource의 할당과 관련하여 Plan을 설정하는 기능으로 DBMS_RESOURCE_MANAGER 와 DBMS_RESOURCE_MANAGER_PRIVS Package에 의해 관리된다. DBA_RESC_PLAN으로 현재의 모든 Resource Plan을 확인할 수 있으며, V$RSRC_PLAN으로 현재의 Active Plan정보를 확인할 수 있다.

  • Default

- False




4.151 rollback_segments[편집]

현재의 Instance에서 사용될 Private 또는 Public Rollback Segments를 이름으로 지정한다. transactions / transactions_per_rollback_segment 이상이 지정되어 있더라도 설정된 모든 Rollback Segment를 Open한다. 그러나 transactions / transactions_per_rollback_segment 이하일 경우는 Public Rollback Segment를 Open할려고 시도한다.(DBA_ROLLBACK_SEGS)

  • Default

- Null




4.152 row_locking[편집]

Always는 Table이 Update 될 때마다 Row Locks를 발생 시키고 Table lock은 발생시키지 않는다. Intent는 Select For Update 시에 Row Locks를 발생 시키지만 Update 시에도 Table Locks를 발생 시킨다. 이 Parameter는 가능한 Always로 설정하고 Table Lock이 반드시 필요하다면 'LOCK TABLE' SQL 문장을 사용하도록 권장한다.

  • Default

- Always




4.153 serial_reuse[편집]

어떠한 Type{DISABLE | SELECT | DML | PLSQL | ALL}의 SQL Cursor들이 Serial-Reusable Memory Feature(Well-Structured Private Cursor Memory들 SGA의 Memory에 위치하게 하여 공유화 하기 위한 방식)를 사용할 것인가를 지정한다. 이는 같은 Cursor를 실행하는 Session들에 의해서 Serial하게 (동시에 사용될수는 없음) 재사용된다. cursor_space_for_time이 설정되어 있다면 설정된 값은 무시된다.

  • Default

- Null




4.154 serializable[편집]

테이블 Level의 Read Lock를 얻는다. Query를 포함한 Transaction이 Commit 되기 전까지는 다른 Transaction에 의한 동일한 Obejct의 모든 Update는 허용되지 않는다. 자기 자신만이 변경된 Image를 볼 수 있으며 다른 Transaction에 의해서 변경된 Image는 볼 수 가 없다.

  • Default

-




4.155 service_names[편집]

현재의 Instance로 Connection할 Service Name을 지정한다. RAC 환경에서는 반드시 설정되어야 한다.

  • Default

- DB_UNIQUE_NAME.DB_DOMAIN




4.156 session_cached_cursors[편집]

Cache에 관리될 Session Cursor Cache의 수를 지정. 같은 SQL 문장이 반복적으로 Parse Call이 반복될 경우 Session Cursor는 Session Cursor Cache로 이동되며, 이 Cache 수를 지정하는데 사용된다. Cache에 있는 Cursor를 다시 Call했을 경우 Cursor의 Reopen이 발생하지 않으므로 성능의 개선효과가 있다. 그러나 1회성 SQL 문장이 많은 시스템에서는 사용하지 않도록 한다.

  • Default

- 0




4.157 session_max_open_files[편집]

Session에서 Open 될 수 있는 Bfile의 Max Open 수를 지정한다. Session에서 이 값을 초과할 경우 DBMS_LOB.FILEOPEN() 또는 OCILobFileOpen()의 호출은 Error가 발생된다.

  • Default

- 10




4.158 sessions[편집]

User 및 System를 포함하여 DB를 사용하는 Session의 총 합 일반적으로 Default 개수는 1.1 * Processes + 5이며 Recursive Session를 고려하여 항상 Process 보다 커야 한다. 동시사용자의 최대수 + Background Process의 수 + Recursive Session(10%) 정도로 주로 설정하면 적당하다.

MTS 환경하에서는 1.1 * 전체 Connection 수 정도를 권장한다. enqueue_resources나 transactions는 sessions를 참고하여 산출되어진다.

  • Default

- 일반적으로 (1.1 * Processes + 5)

SELECT name, TYPE, VALUE
  FROM V$SYSTEM_PARAMETER
 WHERE name IN ('processes', 'sessions');

select * from v$resource_limit
where resource_name in ('processes','sessions');

alter system set sessions=400 scope=spfile;
alter system set processes=200 scope=spfile;

4.159 shadow_core_dump[편집]

Oracle Foreground Process의 Core Dump 발생 시 SGA의 내용을 Core Dump File에 기록할 것인가를 지정(Full,Partial). background_core_dump는 Background Process에 대해 적용

  • Default

- False




4.160 shared_memory_address[편집]

Runtime시 SGA's Starting Address를 지정한다. hi_shared_memory_address와 같이 사용된다.

  • Default

- 0




4.161 shared_pool_reserved_size[편집]

Large Object를 위하여 예약되어진 SHARED_POOL_SIZE의 공간을 조정한다. Large Object를 위한 Library Cache 영역의 Reserved List Size. Small Object는 Reserved List에 Fragment를 발생시키므로 할당되지 않는다. 이 영역은 SHARED_POOL_SIZE가 다 사용되었을 때 부터 사용되어질 수 있다.

  • Default

- SHARED_POOL_SIZE의 5%




4.162 shared_pool_size[편집]

Shared Pool Size. Shared Pool는 Shared Cursor와 Shared Procedure를 포함한다. 큰 값은 Multi User System에서 속도 향상을 가져오지만 Memory 낭비가 따른다.

  • Default

- 64bit : 64MB, 기타 : 16MB




4.163 sort_area_retained_size[편집]

Oracle이 Sort가 필요하면 sort_area_size까지 증가시키면서 Sort를 하고 Sort할 양이 이보다 많으면 Temp Segment를 생성하여 Disk Sort를 수행한다. Sort가 끝나면 Sorting 작업시 사용되었던 Memory는 다른 Sort를 위해 sort_area_retained_size 만큼 줄어들고 나머지는 O/S에 반환한다.

  • Default

- SORT_AREA_SIZE


4.164 sort_multiblock_read_count[편집]

이 값은 Disk Sort가 발생했을 경우 Temporary Tablespace에 기록되었던 Sort의 Runs(Sort의 중간단계의 기록단위)를 최대 Read할 Block 수를 지정한다.

4.165 sql_trace[편집]

SQL Trace를 모든 Session에 수행할 것인가를 결정한다.

속도 저하 때문에 모든 Oracle Session에 수행하는 것보다는 'ALTER SESSION SET SQL_TRAECE = True' 명령을 이용하여 특정 Session에 대하여 수행하는 것이 효율적이다.

time_statistics를 True로 하지 않으면 처리 시간에 대한 통계치는 구할 수 없다.

4.166 timed_os_statistics[편집]

OS Statistics 정보를 수집할 것인지의 결정. OS 정보를 수집할 Interval(Sec)를 지정한다. OS정보 수집은 성능저하를 가져오므로 가능한 필요시 Alter System으로 일시적으로 사용하고 init.ora에 설정하지 않도록 한다.

4.167 timed_statistics[편집]

모든 작업에 대한 시간 통계치 산출여부를 설정. True 일 경우 시스템에 따라서 전반적인 시스템의 성능 저하를 가져오는 경우가 있다.

4.168 transaction_auditing[편집]

이 파라미터가 True(Default)로 설정 되어 있을 경우, Transaction이 발생될 때 마다 특별한 Redo Record를 발생시키며,

이 정보는 Log Miner 등 Redo Log분석 Utility 등에서 Transaction을 발생시켰던 관련 Client 및 Server 정보를 얻기 위한 Auditing 정보로 활용된다.

True일 경우 약 5% 정도의 Redo Log가 더 발생된다. (LoginUserName, ClientInfo, OsUserName, MachineName, OsTerminal, OsProcessId, OsProgramName)

  • Default Value

- True

4.169 transactions[편집]

동시 Transactions의 최대 개수 설정. Default 값은 Recursive Transaction를 허용하기 위하여 Process 보다 크게 설정.

  • Default Value

- 일반적으로 (1.1 * Sessions) 이상 설정

4.170 transactions_per_rollback_segment[편집]

Rollback Segment에 할당되어지는 동시 Transaction 개수.

최소 RBS개수 = transactions / transaction_per_rollback_segment 오라클이 기동될 때 최소 RBS 개수 만큼 RBS를 확보하려고 Public RBS를 찾는다.

하지만 최소 RBS 개수보다 적어도 Oracle은 기동된다.

  • Default Value

- 5

4.171 undo_management[편집]

UNDO 관리 방법을 설정하는 파라미터로 주요 관리 방법은 AUM(Automatic Undo Management)과 MUM(Manual Undo Management)이 있으며 초기화 파라미터 파일에서 설정해야 한다.

AUTO로 설정하게 되면 데이터베이스는 자동 UNDO 관리 모드로 설정되며 UNDO 테이블스테이스가 필요하며 관련된 세그먼트는 _SYSSMUn$의 형식으로 할당되지만 MANUAL 모드에서는 사용자가 UNDO 세그먼트를 생성해야 한다.

또한, 데이터베이스가 운영중에는 undo_management를 동적으로 변경할 수 없다.

참고로, AUTO 모드에서는 한 개 이상의 UNDO 테이블스페이스가 존재할 수 있지만, 한 개의 UNDO 테이블스페이스만 활성화 될 수 있다.

(추가적인 내용은 "undo_retention" 항목 참조)

  • Default Value

- NULL(초기화 파라미터 파일에서 설정, 버전에 따라 다름 - 11g AUTO) - RAC의 각 노드에서 동일한 값을 가져야 함

4.172 undo_retention[편집]

파라미터의 본래 의미는 커밋(Commit)된 정보에 대해서도 언두(UNDO) 이미지를 유지하기 위한 시간이지만 지정된 수치 동안(단위 sec)은 트랜잭션이 종료된 후에라도, 트랜잭션과 관련되었던 언두 세그먼트를 재사용하지 못하도록 하는 기능을 의미한다.

오라클은 UNDO Extent에 대한 상태정보(Active / Unexpired / Expired)를 주기적으로 관리하며, 이를 위해 UNDO 테이블스페이스에 할당된 모든 Extent의 Commit Time을 목록으로 관리한다.

undo_retention으로 지정된 시간을 기준으로 Unexpired 상태의 Extent들을 Expired 상태로 변경하며, UNDO Extent가 필요할 때면 Expired 상태의 Extent부터 재사용한다.

하지만 undo_retention은 강제성을 갖지 않기 때문에 Expired Extent가 없고 새로 할당할 공간까지 부족해지면 Unexpired 상태의 Extent라도 언제든 재사용할 수 있다.

이 기능이 가능하게 됨으로써 9i 버전 이후에 FlashBack 사용이나, Long Query시의 ORA-01555(snapshot too old)를 최소화하는 것이 가능하게 됨

  • 관련 파라미터

- undo_management

- undo_tablespace

- Retention Guarantee : 파라미터는 아니며 10g부터 나온 UNDO TABLESPACE 생성(변경) 설정 기능


  1. 주요 발생 원인
    • 데이터를 읽어 내려가다가 쿼리 SCN이후에 변경된 블록을 만나(이미 앞서 읽었던 블록을 다시 방문하는 경우 일 수 도 있음) 과거 시점으로 롤백한 Read Consistent(읽기 일관성) 이미지를 얻으려고 하는데, UNDO 블록이 다른 트랜잭션에 의해 이미 재사용되 필요한 Undo 정보를 얻을 수 없는 경우
    • 커밋된 트랜잭션 테이블 슬롯이 다른 트랜젝션에 의해 재사용되 커밋 정보를 확인할 수 없는 경우
  2. 일반적인 해결방안
    • undo_retention 파라미터를 가장 오래 수행하는 트랜잭션에 걸리는 시간보다 많게 설정
    • 요청한 undo_retention을 근거로 필요한 만큼 언두 세그먼트 크기를 증가시킬 수 있도록 디스크에 충분한 공간을 확보
    • 수동(MANUAL) 언두 관리를 사용할 때는 언두 세그먼트를 늘리거나 좀 더 많은 언두 세그먼트를 추가장시간 쿼리를 수행하는 동안에 언두 데이터가 덮어 써질 가능성을 줄여주지만 그리 권장할 만한 방법은 아니며, AUM(자동 언두 관리)를 권장함
    • 쿼리 튜닝을 통한 수행 시간을 단축
    • 일반적으로 최선의 방법일수 있기에 제일 먼저 시도해야 할 필요가 있음
    • 관련된(스캔하고자 하는) 객체에 대하여 통계정보를 수집을 통한 쿼리 최적화
옵티마이저의 잘못된 판단을 최소화




- undo_retention 파라미터의 설정으로 ORA-1555의 발생 가능성을 근본적으로 제거할 수는 없음

- undo_retention은 강제성을 갖지 않기 때문에 Expired Extent가 없고 새로 할당할 공간까지 부족해지면

 Unexpired 상태의 Extent라도 언제든 재사용할 수 있다. 그래서 10g부터 새롭게 도입된 것이 Retention
 Guarantee 기능이다.
CREATE UNDO TABLESPACE UNDO_TS1
DATAFILE '/u01/oradata/proddb01/undo_ts1_01.dbf' SIZE 1024M
RETENTION GUARANTEE;

- 마지막 부분의 Retention Guarantee는 UNDO Tablespace로 하여금 만료되지 않은 UNDO 익스텐트의

 보존을 '보장'하도록 설정함

- UNDO Tablespace에 Guarantee 옵션을 설정하면, 공간이 부족해 에러를 발생시키는 한이 있더라도 Undo

 Retention으로 지정된 시간 이내에 커밋된 UNDO 정보는 재사용하지 않는다.

- 기존 UNDO Tablespace는 ALTER 구문을 이용하여 아래와 같이 수정할 수 있음

ALTER TABLESPACE UNDO_TS2 RETENTION GUARANTEE;




- 10g에서 Guarantee 기능과 함께 도입된 기능으로 시스템 상황에 따라 tuned_undoretention 값을 오라클

 이 자동으로 계산하며(내부적으로 수집한 통계정보 이용) 이를 기준으로 UNDO EXTENT의 상태정보를 관리한다.

- 이때 시용자가 설정한 Undo Retention은 V$UNDOSTAT tuned_undoretention 그 수치 이하로 내려오지

 못하도록 최소값(Low Threshold)을 지정하는 역할을 한다. 다만, UNDO 공간이 충분할 때 가급적 그렇게 요청
 하는 것이고, GUARANTEE 옵션을주지 않는 한 공간이 부족하면 언제든 재사용될 수 있다.

- Automatic Undo Retention 기능의 동작 방식은 오라클 10gR1과 오라클 10gR2간에도 차이가 나며, UNDO

 TABLESPACE의 'Undo Guarantee' 사용 여부와 언두 데이터 파일의 'Autoextend' 사용 여부에 따라 다르게
 동작한다.

- [Retention Gurantee = YES]인 경우는 UNDO 공간부족으로 인해 트랜잭션이 Commit된 정보에 덮어쓰는

 작업을 막아 Undo Retention의 설정값 만큼 보장을 해준다. 즉, UNDO Tablespace의 공간 부족 현상이 발생
 할 경우에도, Unexpired된 언두 익스텐트를 재사용하는 것을 방지하여 Undo Retention을 보장하는 것이다.

- [Retention Gurantee = NO]인 경우는 UNDO 공간부족으로 인해 트랜잭션이 실패하도록 하기보다는

 Commit된 UNDO 정보를 덮어쓴다. 이때, tuned_undoretention 값은 장시간의 쿼리를 감지한 직후에는 약
 Maxquerylen + 300초로 대략 증가함. 또한, Autoextend 모드라면, UNDO Tablespace가 확장 가능하므로
쿼리의 수행시간에 근거하여 Undo Retention을 튜닝한다.



4.173 use_indirect_data_buffers[편집]

32bit 플랫폼에서 4GB이상의 Physical Memory를 Support를 할 수 있도록 Extended Buffer Cache Mechanism의 사용을 할 수 있게 지정.

4.174 utl_file_dir[편집]

DBA가 I/O가 가능한 PL/SQL(UTL_FILE Package) File을 저장하는 Directory




5 오라클 히든 파라메터 조회[편집]

-- SYS 로 Login:

--
-- List all hidden database parameters.
--
 
SET PAUSE ON
SET PAUSE 'Press Return to Continue'
SET PAGESIZE 60
SET LINESIZE 300
 
COLUMN ksppinm FORMAT A50
COLUMN ksppstvl FORMAT A50
 
SELECT
  ksppinm,
  ksppstvl
FROM
  x$ksppi a,
  x$ksppsv b
WHERE
  a.indx=b.indx 
AND
  substr(ksppinm,1,1) = '_'
ORDER BY ksppinm
select a.ksppinm name, b.ksppstvl value
from 
  x$ksppi a,
  x$ksppsv b
WHERE
  a.indx=b.indx 
and a.ksppinm like '%bloom%';

6 추천 히든 파라메터 목록[편집]

alter system set "_optim_peek_user_binds" = false scope=both;
alter system set "_optimizer_use_feedback" = false scope=both;
alter system set "_add_col_optim_enabled" = false scope=both;
-- alter system set "_optimizer_aggr_groupby_elim" = false scope=both;

6.1 _optim_peek_user_binds[편집]

  1. _optim_peek_user_binds 파라미터는 바인드 변수를 사용한 SQL을 실행하여 Hard Parsing 하는 단계에서,
    실제 입력한 값을 Peek하여 컬럼 히스토그램 통계 정보를 참조한 실행 계획을 생성하게 하는 파라미터임.
  2. Peek된 Bind 값은 v$sql_bind_capture에 기록되며, 기본 900초 (15분) 마다 CAPTURE 된다.
  3. Side Effect 로는 Peek된 Bind 값에 따라 적절한 Plan이 다른 경우에 성능 문제가 발생할 가능성이 있다.

예를 들어 날짜를 범위 조회하는 SQL 의 경우에 조회 범위가 짧을 때 생성된 실행 계획이 공유가 된다면 조회 범위가 넓을 때는 비효율 적인 경우가 생길 수 있다.

참고로, 파라미터 비활성시에도 v$sql_bind_capture 에는 저장됨.

alter system set "_optim_peek_user_binds" = false scope=both;
. Bind variable peeking(바인드변수 엿보기) 기능 활성화 여부
. Bind Peeking : Bind 변수를 포함하는 SQL문이 최초로 실행될 때 Bind 변수값을 이용해서 실행계획을 수립하는 기능
=> Bind Peeking에 따른 잘못된 실행계획이 수립되는 것을 방지하기 위해 false 로 설정 권고

6.2 _optimizer_use_feedback[편집]

. 쿼리의 최초 실행 시 예측 건수와 실제 건수의 차이가 크면 opt_estimate 힌트의 형태로 쿼리가 변경되도록 함
=> 의도되지 않은 SQL 실행계획 유발의 우려가 있으므로 false로 설정 권고 

6.3 _add_col_optim_enabled[편집]

. column add 시 dictionary만 update 하고 이후 insert 시 해당 컬럼이 생성
=> 권고: wrong result scale로 인해 false(참고 : 19183343.8)

6.4 _optimizer_aggr_groupby_elim[편집]

. group-by and aggregation elimination 기능의 활성화 여부
=> 권고 : wrong result 발생으로 false(참고 : 19567916.8, 1924440.1)

6.5 _optimizer_reduce_groupby_key[편집]

. Group by key reduction
=> 권고 : wrong result 발생으로 false(참고 : 19567916.8, 1924440.1)

7 히든 파라메터 목록[편집]

7.1 _b_tree_bitmap_plans[편집]

enable the use of bitmap plans for tables w. only B-tree indexes FALSE 설정 Def. = TRUE

7.2 _cleanup_rollback_entries[편집]

no. of undo entries to apply per transaction cleanup 2000 설정

Def. = 100

7.3 _clusterwide_global_transactions[편집]

enable/disable clusterwide global transactions FALSE 설정 Def. = TRUE

7.4 _complex_view_merging[편집]

enable complex view merging FALSE 설정 Def. = TRUE

Complex View란 Group By나 Distinct가 있는 뷰 또는 인라인 뷰를 말하며, Complex View Merging은 이러한 View를 해체하는 개념이다.

힌트로는 Merge / No_Merge를 사용하면 된다

7.5 _datafile_write_errors_crash_inst[편집]

ance datafile write errors always crash instance FALSE 설정 Def. = TRUE

7.6 _db_mttr_advice[편집]

MTTR advisory OFF 설정 Def. = ON

7.7 _diag_daemon[편집]

start DIAG daemon FALSE 설정 Def. = TRUE

7.8 _dump_rcvr_ipc[편집]

if TRUE enables IPC dump at instance eviction time FALSE 설정 Def. = TRUE

7.9 _enable_minscn_cr[편집]

  1. enable/disable minscn optimization for CR

FALSE 설정 Def. = TRUE

7.10 _gc_maximum_bids[편집]

maximum number of bids which can be prepared 4 설정 Def. = 0

7.11 _gc_policy_time[편집]

how often to make object policy decisions in minutes 0 설정 Def. = 10

7.12 _gc_undo_affinity[편집]

if TRUE, enable dynamic undo affinity FALSE 설정 Def. = TRUE

7.13 _in_memory_undo[편집]

Make in memory undo for top level transactions FALSE 설정 Def. = TRUE

7.14 _kgl_large_heap_warning_thresh[편집]

old maximum heap size before KGL writes warnings to the alert log 33554432 설정

7.15 _library_cache_advice[편집]

whether KGL advice should be turned on FALSE 설정 Def. = TRUE

7.16 _memory_imm_mode_without_a[편집]

utosga Allow immediate mode without sga/memory target FALSE 설정 Def. = TRUE

7.17 _nlj_batching_enabled[편집]

enable batching of the RHS IO in NLJ 0 설정 Def. = 1

7.18 _nlj_batching_misses_enabled[편집]

enable exceptions for buffer cache misses 0 설정 Def. = 1

7.19 _optimizer_adaptive_cursor_sharing[편집]

Oracle 11g 부터 Bind Peeking 기능의 단점을 보완하기 위해서 바인드 변수 값에 따라

실행계획을 여러 가지로 관리할 수 있도록 하는 파라미터로 Adaptive Cursor Sharing이란 말

그대로 상황에 맞게 유연하게 Cursor를 Share하겠다는 의미이다.

이 개념을 구현하기 위해 Oracle은 Bind Sensitive Cursor, Bind Aware Cursor라는 새로운 개념을 도입함

Bind Sensitive Cursor란, 말 그대로 Bind 값에 민감한 Cursor라는 의미이다.

즉, Bind 값이 바뀌면 그것을 민감하게 처리하겠다는 의미이며

1) Equal 조건에서는 조건절에 쓰인 컬럼에 Histogram이 있고
2) Range 조건인 경우 ( Oracle은 이것을 Bind Senstive Cursor라고 부름)

Bind Aware Cursor란, Bind Sensitive Cursor에 입력된 Bind 값에 따라 실행 계획이 분화된 Cursor를 의미하는데,

Bind Aware Cursor가 생성되었다는 것은 Bind 변수의 값에 따라 Oracle이 적절한 Child Cursor를

생성했다는 것을 의미하며 이에 맞게 실행 계획을 분화(새로운 Child Cursor 생성)시킨다.

따라서 Bind Peeking에 의한 부작용이 사실상 없어지게 되지만, 조건절에 쓰인 컬럼에 Histogram이 있고,

Histogram의 분포도에 따라 실행 계획에 큰 차이가 있을 수 있다고 판단된다는 조건이 중요함

(즉, 적절한 Histogram 없이는 의미가 없음)

optimizer adaptive cursor sharing FALSE 설정 Def. = TRUE

7.20 _optimizer_adaptive_plans[편집]

SQL 수행 시 Plan 변경을 가능하도록 설정하는 파라미터(Adaptive Execution Plans)

7.21 _optimizer_mode_force[편집]

Recursive SQL(Packaged Sql)에 대해서도 현재의 Optimizer_Mode를 사용할 것인지의 여부.

7.22 _optimizer_undo_changes[편집]

이 매개 변수는 동적이 아니며 RBO 호환성은 True로 유지되어야 함(이것은 향후 릴리스에서 제거 될 예정)

7.23 _optimizer_extended_cursor_sharing[편집]

optimizer extended cursor sharing NONE 설정 Def. = UDO

7.24 _or_expand_nvl_predicate[편집]

Nvl, Decode 조건식 및 Rank 함수를 사용한 조건절을 이용하여 OR-Expansion 쿼리 변환이 가능하도록 제어하는 파라미터로

사용자가 쿼리를 직접 바꿔주지 않아도 옵티마이저가 OR 조건을 Full Table Scan 처리가 아닌 union all 형태로 변경 처리해주는 경우가 있는데

이를 OR-Expansion 이라 한다.

힌트)

- Use_concat : OR-Expansion을 유도하고자 할 때 사용

- No_expand : OR-Expansion을 방지하고자 할 때 사용


7.25 _ordered_nested_loop[편집]

Join Input이 Sort가 되어 있거나 Index를 이용하였으므로 Sort가 불필요 할 경우

Nested Loop Join을 선호하도록 Optimizer가 Cost 계산시 반영토록 하는 파라미터

7.26 _push_join_predicate[편집]

Non-Mergeable View에 대해서 View를 하나의 Query Block으로 처리하지 않고

Join으로 해결할 수 있는 방법이 가능한지 조사하도록 설정하는 파라미터

7.27 _push_join_union_view[편집]

Union All을 가지고 있는 Non-Mergeable View에 대해서 Join으로 해결 가능한지 조사하여

Union All을 포함하는 Non-Mergeable View 안쪽으로 조인 조건을 Pushdown 하는 기능을 활성화하는 파라미터


7.28 _shared_pool_reserved_min_alloc[편집]

shared_pool_reserved_size에서 지정된 Memory에서 Cache화 될 수 있는 최소 Size(Bytes)를 지정한다.

Default는 5K이며 Size가 작을 수록 shared_pool_reserved_size에 관리될수 있는 수를 늘리는 역할을 한다.

7.29 _sort_elimination_cost_ratio[편집]

Index를 이용한 불필요한 Sorting을 줄이기 위한 Parameter이다.

  1. This parameter fixes the FIRST_ROWS bug 780376 which optimizes for the
  2. order by case as opposed to the selective index filters in the WHERE
  3. clause. Setting it to five forces the optimizer to only eliminate the
  4. sort when it is 1/5th the cost of the index probe (or conversely the index probe is 5 times as costly as the sort).

7.30 _sqlexec_progression_cost[편집]

SQL실행을 위한 진행과정 Monitoring을 위한 대상 COST(Default=1000)의 Threshold를 지정한다.

진행 과정은 V$SESSION_LONGOPS에서 확인 가능하다.

또한 Cursor_Sharing Bug 관련 설정에 필요하다.

7.31 _table_scan_cost_plus_one[편집]

Small lookup table에 대한 Full Table Scan과 Index Scan 또는 Range Scan의 경우 Cost가 같게 나오는 경우를 방지하기 위해 설정한다.

즉 Full Table Scan에 Cost를 부과하여 Index Scan위주로 처리되도록 한다.

7.32 _trace_files_public[편집]

DBA Group이나 DB Owner User뿐만 아니라 일반 OS User에게도 Trace File에 대한 Read권한을 주어 Trace 분석등을 할 수 있도록 허용한다.

7.33 _use_column_stats_for_function[편집]

[col + 0] 또는 [col || ] 과 같은 No-Op Expression에 대한 Column 자체의 Analyze의 Statistics 값을 적용여부를 결정한다.



7.34 _PX_use_large_pool[편집]

Use Large Pool as source of PX buffers TRUE 설정 Def. = FALSE

7.35 _row_cache_cursors[편집]

number of cached cursors for row cache management 1000 설정

Def. = 20

7.36 _smm_advice_enabled[편집]

if TRUE, enable v$pga_advice FALSE 설정 Def. = TRUE

7.37 _trace_files_public[편집]

Create publicly accessible trace files TRUE 설정 Def. = FALSE

7.38 _undo_autotune[편집]

enable auto tuning of undo_retention FALSE설정 Def. = TRUE

7.39 _db_block_hash_buckets[편집]

_db_block_hash_buckets은 db_block_buffers * 2가 Default이며 Buffer Cache에 Block을 Loading하기 위해

Oracle Block Address(DBA)에 대해 내부적인 Hash Function을 적용하여 각각의 Block을 Hash Bucket에서 관리하게 된다.

이때 SGA영역인 Hash Bucket에 대한 여러 Process들이 동시에 같은 Hash Bucket에 접근하려는 것을 막기 위해

db block hash latch들을 두고 관리되며, 이 Parameter에 의해 결정된다.

단 Parameter의 값이 2의 승수가 아닐경우는 설정된 값보다 큰 2의 승수가 설정된다.

Default로는 _db_block_hash_buckets/128이나 db_block_buffers가 4,096개 이하일 경우는

db_block_buffers/4로 내부적으로 계산된다.

_db_block_hash_buckets = 262144 ▶ 초기화 파라미터 파일에서 설정

7.40 _db_block_lru_latches[편집]

7.3 이전에는 하나의 Latch가 LRU LIST를 관장하였으나 7.3 부터는 Parameter 설정값으로 여러 개의 Latch가 LRU List를 관장하여 LRU에 대한 Contention를 경감시킴. Default는 CPU_COUNT / 2이며 최대 CPU_COUNT x 2 x 3 (CPU*2 와 Buffer Pool의 수(3)) 또는 db_block_buffers/50까지 설정한다.

그러나 너무 많은 LRU Latch를 두게 되면 LRU List들이 짧게 되는 원인이 되므로 Cache Life가 짧아질 수가 있다.

그리고 LRU List는 적어도 50 Block을 가져야 한다. 주로 CPU 또는 CPU * 2로 설정하며, 각 Working Set(여러 Latch의 묶음단위)는 한 DBWn에 의해서 다루어지므로 Multiple DBWR(db_writer_processes)를 이용할 경우는 LRU Latch의 수는 적어도 DBWn의 수보다 같거나 커야 한다.

DBWn별로 효과적인 분산을 위해 Buffer Pool별 DBWn의 배수로 설정하는 것이 효과적이다.

V$LATCH의 Performance View를 확인해 3% 미만의 Misses율을 유지해야 한다.

  • Default Value

- CPU개수 / 2

7.41 _distributed_lock_timeout[편집]

Distributed Transaction 처리시 LOCK된 오브젝트에 대한 Waiting Time을 초단위로 지정.

ORA-2049 Error가 자주 발생 시 다소 증가시킬 필요가 있다.

  • Default Value

- 60 (단위, sec)

7.42 _distributed_recovery_connection_hold_time[편집]

Distributed Transaction 처리 시 Failed Transaction의 Connection을 얼마나 오랫동안 Open 상태로 유지할 것인지를 설정한다.

Reco Process가 매 30분 마다 Fail된 Distributed Transaction에 대한 정리작업을 수행하며,

이 값이 30분(30*60 = 1,800)이상일 경우는 Hold Time에 제한이 없다.

  • Default Value

- 200 (단위, sec)

7.43 _fast_full_scan_enabled[편집]

Index Fast Full Scan(Table을 Access하지 않고 Index Block들을 db_file_multiblock_count 만큼 Full Table Scan과 같이 읽어 처리하는 기능)처리에 대한 사용 여부 결정

  • Default Value

- True {True | False}

7.44 _like_with_bind_as_equality[편집]

Bind 변수를 사용한 Like 문장에서 [indexed-column like :b1]와 [index-column = :b1]의 Cost를 같도록 하는 파라미터. - This parameter forces the optimizer to treat expressions of the form - [indexed-column like :b1] similar to [index-column = :b1]. - Oracle Apps has many queries which use the LIKE operator on indexed - columns with binds. Since binds are involved, the CBO assigns - internal default selectivity estimates for the LIKE operator (5%), - and hence does not consider the index selective. - Bug 971158 has an Apps example which resulted in the introduction of - this parameter.

  • Default Value

- False {True | False}

7.45 _optim_enhance_nnull_detection[편집]

For bug1389308 : SQL AND EXPLAIN STATEMENT HANGS WITH MANY "OR" AND "AND"