1. 2018.11.02 DBMS 기본 데이터 타입
  2. 2018.11.02 데이터베이스 객체의 종류
  3. 2014.06.12 SCN과 Checkpoint
  4. 2014.06.12 Redo Log
  5. 2014.06.11 Control File
  6. 2014.06.10 Oracle Character set 에 관하여
  7. 2014.04.23 Parameter file 초기화 파라미터 파일
  8. 2014.04.23 Oracle Database 시작과 종료

DBMS 기본 데이터 타입

● 문자 데이터 타입


데이터 타입 

설명 

 CHAR(크기[BYTE|CHAR])

 고정길이 문자, 최대 2000byte, 디폴트 값 1byte 

 VARCHAR2(크기[BYTE|CHAR])

 고정길이 문자, 최대 4000byte, 디폴트 값 1byte 

 NCHAR (크기)

 고정길이 유니코드 문자 (다국어 입력 가능), 최대 2000BYTE, 디폴트 값 1byte

 NVARCHAR2 (크기)

 고정길이 유니코드 문자 (다국어 입력 가능), 최대 4000BYTE, 디폴트 값 1byte

 LONG

 최대 2GB 크기의 가변길이 문자형, 잘 사용하지 않음



● 숫자 데이터 타입


 데이터 타입 

 설명 

 NUMBER[(p,[s])]

 가변숫자, p(1~38, 디폴트 38) s(-84~127, 디폴트 0) 십진수 기준, 최대 22byte

 FLOAT[(p)]

 NUMBER의 하위 타입, p는 1~128, 디폴트 128, 이진수 기준, 최대 22byte

 BINARY_FLOAT

 32비트 부동소수점 수, 최대 4byte 

 BINARY_DOUBLE

 64비트 부동소수점 수, 최대 8byte 


- 4가지가 있지만 주로 NUMBER를 많이 사용합니다. 다른 DBMS는 INTEGER와 같은 정수형, DECIMAL과 같은 실수형을 제공합니다. 오라클도 INTEGER과 DECIMAL로 생성이 가능 하지만, 내부적으로는 NUMBER 형으로 변환되어 생성됩니다.



● 날짜 데이터 타입


데이터 타입 

 설명 

 DATE

 BC 4712년 1월 1일부터 9999년 12월 31일, 

 연,월,일,시,분,초까지 입력가능

 TIMESTAMP[(fractional_seconds_precision)]

 연도, 월, 일, 시, 분, 초는 물론 밀리초 까지 입력 가능

 fractional_seconds_precision은 0~9까지 입력할 수 있고 디폴트는 6



● LOB 데이터 타입 (Large OBject의 약자)


데이터 타입

 설명 

 CLOB

 문자형 대용량 객체. 고정길이와 가변길이 문자 집합 지원, 

 최대크기 (4GB-1)x(데이터베이스 블록 사이즈)

 NCLOB

 유니코드(다국어 지원)를 포함한 문자형 대용량 객체. 

 최대크기 (4GB-1)x(데이터베이스 블록 사이즈)

 BLOB

 이진형 대용량 객체, 최대 크기 (4GB-1)x(데이터베이스 블록 사이즈)

 BFILE

 대용량 이진 파일에 대한 로케이터(위치, 이름)저장. 최대 저장 크기는 4GB



● NULL


 - NULL은 '값이 없음'을 의미하면 테이블을 생성할 때 컬럼 속성에 기술한다. 디폴트 값이 NULL이므로 별도 지정 없으면 해당 컬럼은 NULL을 허용한다. NOT NULL로 명시한 컬럼에 데이터를 넣지 않으면 해당 로우 INSERT가 불가능하다.



'ORACLE > Oracle DBMS' 카테고리의 다른 글

DBMS 기본 데이터 타입  (0) 2018.11.02
데이터베이스 객체의 종류  (0) 2018.11.02
SCN과 Checkpoint  (0) 2014.06.12
Redo Log  (0) 2014.06.12
Control File  (0) 2014.06.11
Oracle Character set 에 관하여  (0) 2014.06.10

데이터베이스 객체의 종류

●  데이터베이스 객체의 종류


 데이터베이스 객체

 설명

 TABLE

 데이터를 담고 있는 객체 

 VIEW

 하나 이상의 테이블을 연결해서 마치 테이블인 것처럼 사용하는 객체 

 INDEX

 테이블에 있는 데이터를 빠르게 찾기 위한 객체 

 SYNONYM

 데이터베이스 객체에 대한 별칭을 부여한 객체 

 SEQUENCE

 일련번호 채번을 할 때 사용하는 객체

 FUNCTION

 특정 연산을 하고 값을 반환하는 객체

 PROCEDURE

 함수와 비슷하지만 값을 반환하지는 않는 객체 

 PACKAGE

 용도에 맞게 함수나 프로시저를 하나로 묶어놓은 객체



●  TABLE


- 데이터를 넣고 수정하고 삭제하는, 데이터를 담고 있는 가장 기본적인 객체. ROW (행)과 COLUMN (열)으로 구성된 2차원 형태(표)의 객체로 우리가 자주쓰는 엑셀과 비슷한 구조라고 보면 이해가 쉽습니다.


- TABLE 생성은 CREATE문으로 생성할 수 있는데, 기본 구문은 아래와 같습니다.


CREATE TABLE [스키마.]테이블명 (

컬럼1    컬럼1_데이터타입    [NULL, NOT NULL],

컬럼2    컬럼2_데이터타입    [NULL, NOT NULL],

...

) [TABLESPACE 테이블스페이스명];


스키마명은 생략이 가능하며, 생략하게되면 현재 자신이 로그인한 스키마 이름으로 생성됩니다.

TABLESPACE 구문도 생략이 가능한데, 해당 사용자의 디폴트 TABLESPACE에 생성됩니다.

'ORACLE > Oracle DBMS' 카테고리의 다른 글

DBMS 기본 데이터 타입  (0) 2018.11.02
데이터베이스 객체의 종류  (0) 2018.11.02
SCN과 Checkpoint  (0) 2014.06.12
Redo Log  (0) 2014.06.12
Control File  (0) 2014.06.11
Oracle Character set 에 관하여  (0) 2014.06.10

SCN과 Checkpoint

1. SCN(System Commit Number) 의 정의
 
- commit이 발생할 때 트랜잭션이 부여받는 고유한 번호(=SCN)
- 장애 발생시 복구의 중심!
- instance recovery때나 사용자가 recover명령을 수행할 때 DB에 문제가 있는지 판단하는 지표
- DB를 다시 생성하지 않는 한 RESET(0)되지 않음
- SCN은 크게 SCN base(4 bytes) + SCN Wrap(2 bytes)로 구성되어 있음

SCN 조회법

SQL> select * from v$sysstat where name='calls to kcmgas';
- Sequence에서 발생시키는 것이 아니라 "kcmgas"라는 fuction에서 구현됨
- 발생된 내역에 대한 시간정보 등의 자세한 사항은 smon_scn_time테이블을 조회하면 확인가능
- 다음에 발생될 SCN에 대한 정보는 DML수행 후 v$transaction을 조회하면 됨


2. SCN 기록 솔루션

(1) Control file header
- checkpoint 발생 때
- resetlogs 발생 때
- incomplete recovery 수행 때

(2) Data blocks (cache layer)
- block cleanout시 마지막 scn을 각 block에 기록

(3) Data blocks (ITL entries)
- data block의 transaction layer 안에 있는 ITL(interested transaction list) entries에 commit된 SCN정보를 기록(Delayed block cleanout)

(4) data file headers
 아래의 경우, 모든 데이터 파일 헤더에 SCN을 기록
- 마지막 checkpoint발생 때
- begin backup 수행 때
- 복구가 되었다면 사용자의 마지막 scn을 기록

(5) redo records / log buffer
- commit이 수행되면 commit record에 scn을 포함하여 저장

(6) 그 외 rollback segment(undo segment)와 tablespace headers에도 기록
 

3. 10g R2버전의  commit 관련 파라미터

SQL> show parameter commit;

- commit_point_strength : 분산 DB환경의 2-Phase commit에서 사용
- commit_write
user commit; -> LGWR이 해당 transaction을 redo log file에 기록!

위 내용과 관련된 4가지 방식 중 어떤 조합으로 이용할지를 결정하는 파라미터

(1) WAIT: 변경된 트랜잭션이 redo log file에 기록될때까지 기다림
(2) NOWAIT: redo log file에 기록될때까지 기다리지 않음
(3) IMMEDIATE: commit요청이 들어오면 즉시 redo log file에 기록
(4) BATCH: commit에 요청이 들어오더라도 일정시간 모아 한번에 기록

BATCH나 NOWAIT같이 redo log buffer의 내용이 아직 redo log file에 기록이 완료되지 않아도 다른 작업을 할 수 있게해서 성능을 높이는 방식을 비동기식 커밋(asynchronuos commit)이라고 한다. BUT, 성능은 빠르겠지만 데이터까지 안전하다고 생각하는건 오산!

- max_commit_propagation_delay

RAC환경에서 어떤 데이터가 양쪽 인스턴스에 호출되었다고 가정하였을 때 (각 node1, node2) 오라클에서는 node1에서 발생한 정보를 node2에 전송할 때 piggyback이란 방식으로 전송하는데 이 방식의 특징은 commit이 발생하면 즉시 보내는 것이 아니라 다른 메시지가 갈 때 함께 업혀서 가는 방식이다. 그러다 보니 메시지 발생양은 작고 트래픽 양은 작은 장점은 있으나 틀린 내용을 조회할 수 있다는 심각한 단점이 생김. 그래서 max_commit_propagation_delay 파라미터를 사용해서 전송시간을 제어하게 됨.

10g부터는 이 파라미터의 기본값이 0으로 설정이 되어있다 (commit하면 즉시 전송)
이런 방식을 broadcast on commit(줄여서 BOC) 방식이라고 부름


4. System Change Number

SCN의 또 다른 이름
이것은 datafile, redo log file, control file간의 동기화 정보를 맞추기 위해 사용된다
이 SCN은 scn_base(4 bytes) + scn_wrap(2 bytes) + scn_sequence (1 byte)로 구성되어 있고 sequence는 동일한 scn block을 여러개의 서버프로세스가 동시에 변경할 경우에 이를 구분하게 위해 사용한다.
이 SCN은 Data block header, redo records, segment header에 기록이 된다.


5. Checkpoint


checkpoint란 commit된 데이터를 어디까지 저장했는지 확인하기 위해서 만들어 놓은 개념
data file의 복구를 결정하는 기초적인 정보
control file과 data file의 checkpoint정보를 비교하고 서로 정보가 다르면 틀린 부분을 online redo log나 archived redo log를 참조해서 복구를 하게 됨.

- database / global checkpoint

이 checkpoint가 발생하게 되면 DB buffer cache내에 있는 모든 저장안된 dirty buffer들의 내용을 전부 data file로 저장함
그리고 저장된 scn 중 가장 번호가 큰 scn번호를(=checkpoint scn) control file과 data file header부분에 기록함

- thread checkpoint / logical checkpoint

해당 thread내의 저장되지 않은 모든 dirty buffer들을 data file로 전부 내려씀
이 checkpoint는 log switch가 발생하면 생김
RAC환경일 경우는 각 노드별로 다르게 발생하며 sing instance일 경우는 database checkpoint와 같은역할

- data file checkpoint

특정 data file에만 발생하는 checkpoint
해당 tablespace를 offline한다거나 hot backup수행시에 발생하게 됨
이 checkpoint가 발생하면 해당정보를 control file과 data file header부분에 기록

- mini checkpoint

drop table과 같이 특정한 DDL 발생시 특정 블록에만 발생
 
- recovery checkpoint

데이터파일에 장애가 발생했을 때 db buffer cache에 recovery 할 block을 가져와서 redo change vector를 적용시킴.
그 후 buffer cache에서 변경된 블록을 data file에 저장해야 하는데 이때 발생하는 checkpoint를 recovery checkpoint라고 함

오라클에서는 위와 같이 여러가지 checkpoint의 종류에 우선순위를 두어서 checkpoint를 관리하는데 우선순위가 높은 경우를 fast checkpoint로 분류하고 그 반대는 low checkpoint로 분류를 해서 두 가지가 동시에 발생할 경우 우선순위가 높은 fast checkpoint부터 진행하게 된다.

예) database shutdown, tablespace begin backup, alter system checkpoint 등의 명령어로 발생되는 checkpoint는 fast checkpoint로 분류되며 DB buffer cache내부에 있는 모든 저장안 된 dirty buffer들을 즉시 data file로 저장한다(=full checkpoint) full checkpoint가 발생하면 control file과 data file header에 해당 checkpoint정보를 기록하게 된다.

low checkpoint의 경우에는 checkpoint를 해야 할 block의 목록을 즉시 내려쓰지 못하므로(우선순위가 낮기 때문) queue에 내려쓰게 된다(=Incremental checkpoint)

Oracle7 까지는 저장영역의 목록을 LRUW list로 관리했지만 8버전 이후부터는 checkpoint queue 로 대체된다
checkpoint queue 는 FIFO구조를 가지고 있다

dirty buffer 목록의 길이를 관리하기 위해 Incremental checkpoint가 발생하는 간격을 조절할 수 있도록 Oracle8에서는 DB_BLOCK_MAX_DIRTY_TARGET을 제공했고 8i버전부터는  FAST_START_MRRT_TARGET이 제공되었다

Incremental checkpoint를 하게되면 checkpoint정보를 control file에만 기록하며 data file에는 기록하지 않는다

'ORACLE > Oracle DBMS' 카테고리의 다른 글

DBMS 기본 데이터 타입  (0) 2018.11.02
데이터베이스 객체의 종류  (0) 2018.11.02
SCN과 Checkpoint  (0) 2014.06.12
Redo Log  (0) 2014.06.12
Control File  (0) 2014.06.11
Oracle Character set 에 관하여  (0) 2014.06.10

Redo Log

Redo Log


- 오라클에서는 데이터 변경이 생길 경우 만약에 발생할 장애를 대비하여 변경되기 전의 내용과 변경후의 내용을 모두 기록한다.

- 이 내용이 기록되는 장소 중 메모리가 Redo log Buffer 이며, 파일은 Redo log File 이다.

 

Redo 생성 원리


 ※ Write Log Ahead - 실제 데이터를 변경하기 전에 redo log에 먼저 기록을 한 후 데이터를 변경

 ※ Log Force at Commit - 사용자로부터 commit요청이 들어오면 관련된 모든 redo record들을 redo log file에 저장한 후 commit을 완료


 


1) 변경을 원하는 Block이 Bb Buffer Cache로 로드.

그 후 해당 Row 부분을 다른사용자가 바꿀 수 없도록 해당 Block에 Lock을 설정한 후 (=page fix)

PGA에서 Redo Log Change Vector가 생성됨.

 :Change Vector란 변경된 데이터를 나중에 복구를 할 목적으로 redo log에 기록할 변경된 데이터에 대한 모든 정보의 세트를 의미함

 예를들어 하나의 row를 insert 하는 경우 아래와 같이 여러개의 항목이 모여 하나의 change vector가 됨

 

- Change#1=Undo segment header 변경내용

- Change#2=Undo Block 변경내용

- Change#3=Data segment header 변경내용

- Change#4=Data block 변경내용

 

일반적으로 Redo Log는 트랜잭션의 변경을 복구 할 용도로 기록이 된다.

이것은 Commit된 데이터 외 Rollback 데이터를 복구 할 경우에도 사용된다는 뜻이다.

 

사용자가 commit한 후 아직 Checkpoint 발생 전에 DB가 강제종료 되었을 때 해당 데이터를 Roll forward 하는 내용도 저장해야 하지만 사용자가 Rollback한 후 아직 rollback이 완료되지 않은 상태에서 DB가 강제 종료 되었을 때도 Rollback 되지 못한 데이터를 전부 Rollback 해 주어야 한다.

그래서 Change Vector내에 Undo관련 내용까지 함께 저장되어 있는 것이다.

 

이렇게 PGA상에서 만들어진 Change Vector들은 Redo Record Format으로 Row 단위로 Redo Log Buffer에 복사된다.



2) PGA에서 change vector를 생성한 후 redo log buffer에서 필요한 용량을 계산하고 복사하려면 Latch를 획득해야 한다. 

모든 메모리 자원(shared pool, database buffer cache 등) 은 각자 적절한 latch를 가지고 있다. 

Redo Log Buffer 역시 마찬가지로 Redo Log Buffer에 내용을 쓰려면 Latch를 확보 해야하는데 첫번째로 Redo Copy Latch을 획득 해야한다. 만약 동시에 여러 서버 프로세스가 데이터를 변경하려 한다면 Redo Copy Latch를 획득하는 과정에서 과부하가 생길 수 있음. 

Redo Copy Latch는 Change Vector가 모두 Redo Log Buffer에 기록 될때까지 가지고 있어야 하기 때문에 여러개가 존재 해야한다.

Redo Copy Latch의 개수는 "_log_simultaneous_copies" 라는 히든 파라미터로 조정 가능 (기본값은 CPU 개수 x2)



3) Redo Copy Latch를 확보한 서버프로세스는 Redo Log Buffer에 내용을 기록하기 위해 Redo Allocation Latch를 확보해야 한다.

 

9i부터는 Redo Log Bufferr를 여러개의 공간으로 나눠 각 공간별로 Redo Allocation Latch를 할당해주는 Shared Redo Strand 기능이 도입되었으며 이 값은 LOG_PARALLEISM 파라미터로 설정이 가능하다. (기본값 1)

 

10g부터는 Shared Redo Strand가 더 확장된 개념인 Private Redo Strand기능이 도입되었다.

10g부터는각 서버 프로세스들이 Private Redo Strand 공간을 만들어서 그곳에 Change Vector를 생성한 후 필요한 경우 LGWR 이 Redo Log File에 바로 기록하게 된다.

Private Redo Strand의 도입으로 인해 각 프로세스들이 Latch를 확보하기 위해 경합이 발생하던 부분이 줄어 성능면에서 더 향상되었고 이것을 Zero Copy Redo 라고도 한다. 

10g 부터는 LOG_PARALLEISM 파라미터가 _LOG_PARALLEISM_DYNAMIC 으로 (히든파라미터) 변경되고, 이 값이 True로 설정 되어 있으면 Stand 개수를 Oracle이 자동으로 관리한다. (권장값은 CPU 개수/8)


※ Redo Allocation Latch 개수 조회

 SQL> select count(*)
from v$latch_children
where name='redo allocation';


4) Redo Log Buffer에서 특정 상황이 되면 LGWR이 Redo Log Buffer에 있는 내용 중 일부를 Redo Log File에 기록한다

 

서버 프로세스가 Redo Writing Latch를 확보 

-> LGWR에게 Redo Log Buffer 에 있는 내용을 Redo Log File에 기록하라고 요청


 ※ LGWR이 Redo Log File에 기록하는 상황

 

- 3초마다

LGWR프로세스는 할 일이 없을경우 Sleep상태로 되었다가 Rdbms Ipc Message 라는 대기 이벤트의 Ttime Out이 되는 시점인 3초마다 한번씩 Wake Up을 해서 Redo Log Buffer에서 Redo Log File에 기록해야 할 내용이 있는지를 찾게된다. 그래서 기록할 부분이 있으면 Redo Log File에 기록한 후 Redo Log Buffer에서 기록된 해당 내용을 Flush 한다.

 

- Redo Log Buffer의 전체 크기인 1/3이 찼거나 1MB가 넘을경우 서버 프로세스는 Redo Log Buffer를 할당받을 때마다 현재 사용된 Log Buffer의 Block수를 계산한다. 만약 현재 사용된 Log Buffer의 Block수가 _LOG_IO_SIZE의 값보다 많을경우 LGWR에게 Redo Log Buffer의 내용을 Redo Log File에 기록하도록 요청한다.

 

- 사용자가 Commit 또는 Rollback을 수행할 때

사용자가 Commit을 수행하여 Redo Log File에 기록되는 것을 Sync Write라고도 한다

 

- DBWR이 LGWR에게 쓰기를 요청할 때

Oracle 8i부터는 DBWR이 LGWR의 on-disk RBA값보다 큰 high-RBA값을 가진 Block을 데이터파일로 기록해야 할 때 해당 Block을 Differed Write Queue에 기록시킨 후 LGWR프로세스를 먼저 수행시켜 해당 Redo Log를 먼저 내려쓰게 만든 후 Data Block을 기록하는 방식으로 Sync를 맞추게 됨.

 

위 조건들일 때 LGWR은 Redo Log Buffer에 있는 내용을 Redo Log File에 기록한 후 Redo Log Buffer에서

Redo Log File에 기록된 내용을 flush하게 된다.

 

LGWR이 Redo Log Buffer의 내용을 Redo Log File로 내려쓸 때 DBWR과 마찬가지로 Block단위로 내려쓴다. 여기서 내려쓰는 Block의 크기는 DB_BLOCK_SIZE로 결정되지만 LGWR이 내려쓰는 LOG Buffer의 Block크기는 DB_BLOCK_SIZE의 값이 아니라 OS Block Size이며 OS종류에 따라 다를 수 있다.

 

현재 Redo Log Block Size (단위 byte)

SQL> select max(lebsz) from sys.x$kccle;

 

 ※ Redo Log에 기록되지 않는 경우

 

- Direct load (SQL loader, insert /*+APPEND */)

- TABLE 생성, INDEX 생성시 nologging 옵션 (일반적인 insert, update, delete 작업은 모두 기록됨)

'ORACLE > Oracle DBMS' 카테고리의 다른 글

데이터베이스 객체의 종류  (0) 2018.11.02
SCN과 Checkpoint  (0) 2014.06.12
Redo Log  (0) 2014.06.12
Control File  (0) 2014.06.11
Oracle Character set 에 관하여  (0) 2014.06.10
Parameter file 초기화 파라미터 파일  (0) 2014.04.23

Control File

각 버전별 Control File 내용


Oracle 7

 1) 데이터 메이스에 대한 전체 요약 정보가 저장되어 있다. 데이터 파일, 리두 로그 파일, 쓰레드 등의 정보.

 2) 리두 로그 관련 정보. 리두 쓰레드 정보와 전용인지 아니면 공용인지 여부, 각 로그 그룹과 LGWR이 현재 기록중인 로그 그룹 정보.

 3) 로그 그룹의 각 로그 멥버에 관한 정보. 로그 파일의 크기, 경로, 로그 시퀀스 번호, 각 로그 파일별 최대/최소 SCN 값, 

     각 로그 파일이 속한 쓰레드 정보.

 4) 데이터 파일 정보. Read/Write 정보, on/offline 정보, Recovery stat 정보, 데이터 파일별로 최종 저장된 SCN 번호.

 5) 로그 히스토리 정보.


Oracle 8i  (7버전의 5가지 항목에 12가지 내용이 추가)

 1) 진행중인 체크포인트 관련 정보

 2) 데이터베이스내의 전체 테이블 스페이스 정보. 각 테이블 스페이스의 SCN 번호의 처음과 끝.

 3) 테이블 스페이스가 오프라인 되었거나 읽기 전용일 경우 온라인으로 만들때 writable 가능하게 하는 주요 정보.

 4) 아카이브 로그 관련 정보

 5) 백업셋 관련 정보. RMAN 관련 정보.


Oracle 9i

 1) Database Entry -  데이터베이스 전체에 대한 정보 요약. DB Name, 생성된 시간, Resetlogs SCN, checkpoint SCN, 

    Redo log Thread 정보, 아카이브 정보 등

 2) Checkpoint Progress Record - 체크포인트 관련 주요 정보

 3) Extended Database Entry - control file 백업 등의 추가 정보

 4) Redo Thread Records - Redo log Thread 관련 정보. OPS나 RAC가 아니면 Redo log Thread 정보는 자동으로 1.

 5) Log file Records - 각 리두 로그 그룹별로  시퀀스 번호와 SCN 번호등의 정보.

 6) Data File Records - 각 데이터 파일별로 file name, checkpoint SCN, stop SCN, Hot backup 상태, 오프라인 상태 정보 등.

 7) Temp File Records - Temporary file 관련 상태 정보.

 8) Tablespace Records - 테이블 스페이스 이름과 링크된 데이터 파일 정보. PITR(Point In Time Recovery) 정보.

 9) RMAN Configuration Records

 10) Log File History Records

 11) Offline Range Records

 12) Archive Log Records

 13) Backup Set Records

 14) Backup Piece Records

 15) Backup Datafile Records

 16) Backup Log Records

 17) Datafile Copy Records

 18) Backup Datafile Corruption Records

 19) Datafile Copy Corruption Records

 20) Deletion Records

 21) Proxy Copy Records

 22) Incarnation Records


Oracle 10g

 1) Database Entry

 2) Checkpoint Progress Record

 3) Extended Database Entry 

 4) Redo Thread Records

 5) Log file Records

 6) Data File Records

 7) Temp File Records

 8) Tablespace Records

 9) RMAN Configuration Records

 10) Flashback Logfile Records

 11) Thread Instance Mapping Records

 12) MTTR Records

 13) Standby Database Map Records

 14) Restore Point Records

 15) Log File History Records

 16) Offline Range Records

 17) Archive Log Records

 18) Backup Set Records

 19) Backup Piece Records

 20) Backup Datafile Records

 21) Backup Log Records

 22) Datafile Copy Records

 23) Backup Datafile Corruption Records

 24) Datafile Copy Corruption Records

 25) Deletion Records

 26) Proxy Copy Records

 27) Incarnation Records

 28) RMAN Status Records

 29) Datafile History Records

 30) Normal Restore Point Records


Oracle 11g

 1) Database Entry

 2) Checkpoint Progress Record

 3) Extended Database Entry 

 4) Redo Thread Records

 5) Log file Records

 6) Data File Records

 7) Temp File Records

 8) Tablespace Records

 9) RMAN Configuration Records

 10) Flashback Logfile Records

 11) Thread Instance Mapping Records

 12) MTTR Records

 13) Standby Database Map Records

 14) Restore Point Records

 15) ACM Service Records

 16) Log File History Records

 17) Offline Range Records

 18) Archive Log Records

 19) Foreign Archive Records

 20) Backup Set Records

 21) Backup Piece Records

 22) Backup Datafile Records

 23) Backup Log Records

 24) Datafile Copy Records

 25) Backup Datafile Corruption Records

 26) Datafile Copy Corruption Records

 27) Deletion Records

 28) Proxy Copy Records

 29) Incarnation Records

 30) RMAN Status Records

 31) Datafile History Records

 32) Normal Restore Point Records

 33) Database Block Corruption Records


'ORACLE > Oracle DBMS' 카테고리의 다른 글

SCN과 Checkpoint  (0) 2014.06.12
Redo Log  (0) 2014.06.12
Control File  (0) 2014.06.11
Oracle Character set 에 관하여  (0) 2014.06.10
Parameter file 초기화 파라미터 파일  (0) 2014.04.23
Oracle Database 시작과 종료  (0) 2014.04.23

Oracle Character set 에 관하여

Oracle Character Set 에 관하여


DB를 처음 구성하는데있어 가장 먼저 결정 해야 하는 몇가지 요소가 있는데,

DB Name (SID 명), Datafile들이 저장되는 경로 및 용량, 그리고 Charater Set 이다.


캐릭터 셋은 한번 결정하고 나면 나중에 변경하기 굉장히 어렵기 때문에 처음 DB를 구성할때 신중히 결정 해야 한다.


한국어를 지원하는 캐릭터 셋으로 대표적인 것이 두가지 있다.


KO16KSC5601 과 KO16MSWIN949


이 두가지 캐릭터 셋은 한글을 표현하는 EUC_KR의 캐릭터 셋이다.


KO16KSC5601

한글 완성형 코드와 일치하며 일반적으로 많이 사용되는 2350자의 한글, 4888자의 한자와 히라카나, 카타카나, 그리고 영문 및 각종 기호들을 포함하고 있다.

 

KO16MSWIN949

Windows-949 Character Set은 MS사의 Windows Codepage 949번, 즉 한글 코드 페이지를 따른 코드셋이다. 이는 완성형(KO16KSC5601)을 그대로 포함하고 있으며, 추가로 현대 한글 조합으로 표현 할 수 있는 모든 가짓수에 해당하는 8822자의 한글을 추가해 포함하고 있다. 그러니까 "Windows-949 Character Set은 KSC5601의 수퍼셋(SuperSet)"이 되며, 따라서 "KO16MSWIN949 또한 KO16KSC5601의 수퍼셋"이 된다.


즉, KO16MSWIN949가 KO16KSC5601를 포함하고 있다고 봐도 무방하며, 실제로 DB 마이그레이션 작업시

KO16KSC5601의 DB를 KO16MSWIN949 로 마이그레이션 할때는 크게 문제 되지 않는다. 

반면, 반대로 작업 시에는 문제가 발생 할수 있다. 역시 표기 할수 있는 글자 수의 차이 때문이다.


또 유니코드의 캐릭터 셋인 UTF-8과 AL32UTF8 도 한글을 지원 하는데 해당 캐릭터 셋은 한글 뿐만 아니라 모든 언어의 표기가 가능 하다.


UTF8 / AL32UTF8

UTF8 은 유니코드를 구현한 Character Set 중에 가변결이 인코딩 방식을 택하고 있는 Character Set이다. 가변 길이를 위해 일종의 플래그 비트를 각 바이트마다 포함시켜야 하다보니, 한 글자를 표현하는데 필요한 바이트의 길이가 최대 3바이트(AL32UTF의 경우 6바이트)까지 늘어날 수 있다.


한글지원 Character Set 비교표


 

 KO16KSC5601

 KO16MSWIN949

 UTF8

 AL32UTF8

 한글지원 상태

 2350자

 11172자

 11172자

 11172자

 캐릭터셋/인코딩

 한글완성형

 한글조합형

 8.1.6이전:Unicode 2.1

 8.1.7이후:Unicode 3.0

 9i R1  : Unicode 3.0

 9i R2  : Unicode 3.1

 10g R1 : Unicode 3.2

 10g R2 : Unicode 4.0

 한글바이트 

 2 Bytes

 2 Bytes

 3 Bytes

 3 Bytes

 지원버전

 7.x 이상

 8.0.6 이상

 8.0이상

 9i R1 이상

 National Character Set

 불가능

 불가능

 가능

 불가능

 기타

 

 

 

 


National CharacterSet


National CharacterSet은 유니코드를 지원하지 않는 CharacterSet을 가진 데이터베이스에서 유니코드를 지원하기 위해 부가적으로 설정할 수 있는 CharacterSet이다.

즉, 하나의 데이터베이스 인스턴스는 "CharacterSet"과 "National CharacterSet"을 가진다. 처음 시스템 구축 당시와는 달리, 한글 이외의 다른 언어를 급히 저장해야 할 필요성이 있는 경우 National CharacterSet을 적절히 활용할 수 있다.

National CharacterSet이 가능한 CharacterSet은 단 두가지로, UTF8과 AL16UTF16(기본값)이다.

Nation CharacterSet을 사용하기 위해서는 특정 타입으로 테이블읠 컬럼 또는 PL/SQL 변수를 선언해야 한다. CHAR와 VARCHAR2, CLOB에 대응되는 National CharacterSet 기반의 타입으로는 NCHAR, NVARCHAR2, NCLOB이 있다.


즉, KO16MSWIN949 데이터베이스에서 다음과 같이 테이블을 생성할 경우,


create table test_table (
varchar_value VARCHAR2(2000),
nvarchar_value NVARCHAR2(2000));


"varchar_value" 컬럼에는 KO16MSWIN949에 속하는 글자들만 저장 할 수 있는 반면, nvarchar_value 칼럼에는 유니코드에 속한 모든 글자들을 저장할 수 있다. 약간의 부가적인 코드가 필요할 뿐 실제 프로그래밍 방식은 거의 동일한다.

 


CharacterSet 선택의 원칙


 - 한글 지원을 위해서는 반드시 위의 네가지 CharacterSet 중에 하나를 선택해야 함

 - 한국에서만 사용하는 시스템이라면 KO16MSWIN949를 선택한다.

 - 한국어뿐 아니라 중국어, 일본어, 러시아어 등 다양한 언어로 된 데이터를 저장해야 한다면 UTF8, AL32UTF8을 선택한다. 

   인코딩 변환으로 한국어 기반의 CharacterSet에 비해 속도의 저하가 있다고 알려져 있음

 - 대부분이 한글이며, 일부 외국어가 필요하다면, 한국어 기반의 CharacterSet(KO16MSWIN949)을 사용하되, 

   National CharacterSet을 이용한 칼럼에 외국어를 저장한다.



한글과 유니코드

기 존에 KSC5601에 문제점이 많았었는지 아니면 비 Latin 계열 문자의 설움인지 잘 모르지만, 한국은 처음부터 Unicode 표준 제정에 참가 하였다. 그 결과 Unicode에 독립적으로 한글만 표현할 수 있는 영역이 있을 정도다.
모든 표준이 그렇듯이 지금 Unicode 버전은 3.0이다.
- Unicode 1.X : KSC5601에 정의되어 있는 글자만 표현가능
- Unicode 2.X : 새로운 한글 영역에 한글 정의
- Unicode 3.X : Unicode 2.X 이후 한글부분에서는 변화된 내용없음
 
Unicode에서 한글 자모음은  1100~11FF에 240글자가 정의되어 있으며, 이는 훈민정음 이후 없어진 모든 글자들을 포함하고 있다. 그리고 이 부분에는 한글의 초성/중성/종성이 모두 포함되어 있다.
 
Unicode 에서 한글 음절은 한글영역인 AC00~D7A3에 한글자모음으로 정의된 조합형 코드인 초성(19개) X 중성(21개) X 종성(27개+1개(받침 없음)) = 11172개의 완성형 한글이 가나다 순으로 정의되어 있으며, 이 방식은 자모 조합과 자모 분리가 용이하여 모든 현대 한글 및 한글 고어도 표현이 가능하다.
 
Unicode 에서 한자는 CJK 상형문자 영역인 4E00~9FFF에 중국->일본->중국->한국 순으로 발음 기준으로 정의되어 있으며, CJK 상형문자 영역에 없는 한자는 CJK Compatibility Area adn Specials(F900~FA2D)에 별도 정의되어 있다.
 
Unicode CES
Unicode는 CCS이며 이런 Unicode를 표현하는 CES가 여러 개 존재한다. 대표적인 UTF-8도 Unicode를 표현하는 CES중 하나이다.
 - UCS 2 : Unicode를 표현하는 CES에 표준이며 ISO/IEC10646의 CCS의 모든 문자를 2Bytes로
   인코딩하여 검색, display, 구문해석에 용이한 특징이 있다.
 - UTF-8 : ASCII 문자는 동일한 값에 1Byte로 표현, 유럽 및 기타 1Byte 글자는 2Bytes로 표현,
   한국, 중국, 일본 한자 등은 3Bytes로 표현

이 때까지 언급한 한글 문제를 한번에 해결할 수 있는 방법은 없을까? 이러한 문제를 해결하기 위한 고심의 산물이 바로 Unicode이다.
그렇다고 해서 Unicode가 만병통치약은 아님을 분명히 하고 시작을 하자.
 
CCS와 CES
Coded Character Set(CCS)은 각각의 문자에 대하여 비트로 표현할 수 있는 정수값에 각각의 문자 하나씩을 할당하는 방식을 말하며 한국에서는 KSC-XXXX 또는 ISO-XXXX로 표현하는 Character Set이 대표적인 예이다.
 
Character Encoding Schema(CES)는 각각의 문자에 대하여 16진수(Octet) 하나씩 할당하는 방식으로 CCS방식보다 많은 문자를 표현할 수 있다는 장점을 가지고 있다. 대표적인 CES는 UTF-8이다.
 
Unicode
Any platform, any program, any language라는 슬로건으로 모든 문자에 대하여 고유 번호(Code)가 할당된 것을 말하며, 이는 모든 나라의 언어를 하나의 CCS로 정의해 놓았으며, 이러한 CCS를 표현하는 여러 개의 CES가 존재한다는 개념이다.
- General Scripts Area(0000~1FFF) : Latin 계열 문자와 중동, 태국 문자 등의 할당 영역
- Symbol Area(2000~27BF) : 마침표, 느낌표와 같은 문자 기호와 숫자 등의 할당 영역
- CJK Phonetics and Symbols Area(3000~33FF) : 한국, 중국, 일본(CJK)에서 사용하는 음성/기호문자 할당영역
- CJK Ideographs Area(4E00~9FFF) : 한국, 중국, 일본(CJK)에서 사용하는 한자를 할당하는 영역
- Hangul Syllables Area(AC00~D7A3) : 한글 11172자를 할당하는 영역
- Surrogates Area(D800~DFFF) : 차후 사용목적으로 비어 있는 영역
- Private Use Area(E000~F8FF) : 사용자 및 공급자가 마음대로 사용할 수 있는 영역
- Compatibility Area and Specials (F900~FFFF) : 기존 Unicode안에 존재하는 값과 또 다른 값을 가지는 글자들을 할당하는 영역(일부 한자 포함)


NLS_LANG

오라클에서는 많은 환경변수 값을 사용하고 있다. 그렇지만 지금은 한글에 관한 이야기를 하고 있으므로 NLS_LANG만 가지고 설명한다.
오 라클 DB 서버와 클라이언트간 NLS_LANG 값을 동일하게 하여 사용하는 경우가 99%가량이다. 이렇게 사용하는 이유는 Oracle Client 프로그램을 이용하여 직접 오라클 DB에 접속하여 작업하는 경우가 대부분이기 때문이다.
그러나 NLS_LANG 변수의 값은 오라클 DB 환경변수 값이 아나라, 사용자 자신이 속해 있는 환경을 오라클 DB 서버에 알려주는 역할을 하는 환경변수이다.
 
NLS_LANG = [언어]_[영역].[캐릭터셋]

언어 : 현재 사용자가 사용하는 언어적 특성을 결정짓는 값
영역 : 현재 사용자가 위치한 영역의 특성을 결정짓는 값
캐릭터셋 : 현재 사용자의 시스템이 인식할 수 있는 캐릭터 셋의 값
 
만약 Windows Client에서 한국어 환경을 사용하는 경우 NLS_LANG 값을 'KOREAN_KOREA.KO16MSWIN949"로, 유닉스 클라이언트에서 한국어를 입출력한다면 'KOREAN_KOREA.KO16KSC5601'로 NLS_LANG를 설정 할 것이다.
 
오라클 서버 CharacterSet과 클라이언트 CharacterSet을 동일하게 설정해야 하는 경우
앞서 이야기 했지만 NLS_LANG 값은 클라이언트 값이기 때문에 오라클 DB 서버와 동일하게 설정할 필요는 없지만 작업 및 그 동안 관습에 따라 오라클 DB서버와 NLS_LANG 변수 값을 동일하게 설정하는 경우가 많다.
그러나 오라클에서 아래에 나열한 작업이 필요할 경우 꼭 오라클 DB와 NLS_LANG 값을 동일하게 하는 것을 권장하고 있다.

 - 데이터베이스로부터 데이터를 export 받을 때
 - export 받은 데이터베이스와 같은 CharacterSet을 가진 DB로 export된 파일을 import할 때
 - 기타 다국어 지원 애플리케이션에서 목적에 따라 사용할 때

 
NLS_LANG 관련 주요 변수

 - NLS_TERRITORY : 영역 설정 - NLS_LANG 변수 값에 의해 자동 설정
    * 설정 방법 예> ALTER SESSION SET NLS_TERRITORY = 'KOREA'

 - NLS_LANGUAGE : 언어 설정 - NLS_LANG 변수 값에 의해 자동 설정되는 초기화 변수
     * 설정 방법 예> ALTER SESSION SET NLS_LANGUATE = 'KOREAN'

 - NLS_LANG : 언어, 영역, 캐릭터셋 설정 - 기본 값은 'AMERICAN_AMERICA.US7ASCII'
      * 설정 방법 예> OS 환경변수로 설정

 - NLS_COMP : SQL에서의 비교 방식(<, >, =) 설정 - BINARY값으로 비교
      * 설정 방법 예> ALTER SESSION SET NLS_COMP = ''

 - NLS_SORT : 문자열 정렬방식 설정 -  NLS_LANGUAGE 값에 따라 결정
      * 설정 방법 예> ALTER SESSION SET NLS_SORT = 'KOREAN_M'
 
 - NLS_TERRITORY 변수에 따라 그 값이 결정되는 변수

    * NLS_CREDIT - 대차대조표 '대변' 항목의 금액표기를 위한 기호. 보통 '공백' 문자
    * NLS_CURRENCY
    * NLS_DATE_FORMAT
    * NLS_DEBIT - 대차대조표 '차변' 항목의 금액표기를 위한 기호. 보통 '마이너스' 문자
    * NLS_ISO_CURRENCY
    * NLS_LIST_SEPARATOR - 숫자를 가로로 나열할 때 각 숫자를 구분하는 기호로. 한국의 경우 콤마.
    * NLS_MOMETARY_CHARACTERS - 금액 표기시 금액을 읽기 쉽게 나누는 문자로. 한국에서는 3자리마다 ","를 추가
    * NLS_NUMERIC_CHARACTERS - 소수점 기호와 숫자 그룹핑을 위한 문자 설정. 우리나라에서는 '.,' (dot와 comma).
    * NLS_TIMESTAMP_FORMAT
    * NLS_TIMESTAMP_TZ_FORMAT
    * NLS_DUAL_CURRENCY - 유로화 변경 기간 동안의 혼란을 막기 위해 만들어진 매개변수. 9iR2와 그 이후로는 EU의 유로화 변경이 완료된 상태로 NLS_CURRENCY와 값이 동일하다. 다만 미래에 다른 지역에서도 통화기호의 변경이 일어나면 사용될 수 있음
 
 - NLS_LANGUAGE 변수에 따라 그 값이 결정되는 변수
  
    * NLS_DATE_LANGUAGE
    * NLS_SORT
    * NLS_



언어의 정렬


오라클 DB에서 한글을 사용하다보면 정렬에 관한 문제가 발생하는 경우가 있다. 특히 동양권(한국/일본) 언어에서는 자국에 원어이외에 한자를 사용하고 있으므로 인해 여러가지 문제가 발생하는 경우가 있다.

 

KO16KSC5601에서 한글 정렬

KO16KSC5601 에서는 한글 2350자의 바이너리 정렬 순서가 한글의 언어적 정렬 방식과 동일하다. 따라서, 단순히 Order by 명령만으로 정렬의 효과를 거둘 수 있다. 한자의 경우 한글 뒤에 한자의 음에 맞게 정렬이 된다.

이것은 단지 한글 2350자들과 한자 4888자의 정렬일뿐이며, 나머지 글자들에 대해서는 입출력도 불가능하다.


KO16MSWIN949에서 한글 정렬

KO16MSWIN949 는 KO16KSC5601에서 지원되지 않는 8822자의 한글을 추가적으로 지원한다는 점에서 KO16KSC5601의 대안으로 자주 이용되는 Character Set이다. 하지만, 총 11172자의 한글의 바이트 코드가 한글의 언어적 정렬 순서와 불일치 한다.


UTF8/AL32UTF8에서 한글 정렬

UTF8 데이터베이스의 경우, 한글만을 고려하면 별다른 정렬 옵션이 필요없다. 왜냐하면 한글 11172자의 정렬 순서와 바이트 코드 정렬 순서가 일치하기 때문이다.

그러나 한자를 포함한다면 한자->한글 식으로 정렬이 된다.


 

NLS_SORT


UTF8과 KO16MSWIN949에서는 원하는 형태의 정렬이 일어나지 않는다. 이럴 때 NLS_SORT 값을 활용하여 원하는 형태의 정렬을 구현할 수 있다.


NLS_SORT='KOREAN_M'

  - 한글은 단순히 유니코드 바이트 정렬에 의존한다.

  - 모든 한글은 한자에 우선한다.

  - 한자는 발음 순서대로 정렬된다.

한마디로 KO16KSC5601에서 사용되던 정렬 방식으로 모든 한글과 한자를 정렬하겠다는 방법이다.

 

NLS_SORT='UNICODE_BINARY'

이 방법을 사용하면 각각의 문자에 대응하는 이진코드값을 기준으로 정렬된다. 이때는 한자->한글 순이다.

즉, 한글과 한자를 사용하는 경우에는 NLS_SORT='KOREAN_M'을 사용해야 한다.




'ORACLE > Oracle DBMS' 카테고리의 다른 글

Redo Log  (0) 2014.06.12
Control File  (0) 2014.06.11
Oracle Character set 에 관하여  (0) 2014.06.10
Parameter file 초기화 파라미터 파일  (0) 2014.04.23
Oracle Database 시작과 종료  (0) 2014.04.23
Oracle Background Processes  (0) 2014.04.17

Parameter file 초기화 파라미터 파일

Parameter 란?


- 사용자가 원하는 어떤 값을 오라클에게 전해주기 위해 사용하는 변수 같은 역할을 하는 것.


- 묵시적 파라미터 : 관리자가 지정하지 않을 경우 자동으로 기본값을 가진다.

- 명시적 파라미터 : 관리자가 지정해 주어야만 값을 가진다.



pfie과 spfile의 비교


 항목 / 파일

 pfile

 spfile

 파일 경로

 $ORACLE_HOME/dbs (UNIX) , $ORACLE_HOME\database (Windows)

 파일 이름

 initSID.ora

 SpfileSID.ora

 내용 변경

 관리자 (유저)

 서버 프로세스

 파일 형태

 TEXT (OS 편집기로 편집가능)

 Binary (OS 편집기로 편집 불가)


pfile을 8i까지 기본으로 사용했으나 9i부터 spfile을 기본으로 사용.

spfile과 pfile이 동시에 존재 한다면 spfile을 먼저 읽어 들이게되어 spfile의 정보를 가지고 startup 하게 된다.



사용하고 있는 DB가 spfile을 사용하고 있는지 pfile을 사용하고 있는지 확인하기


pfile을 사용하는 경우

SQL> show parameter spfile

NAME                                               TYPE         VALUE
------------------------------------ ----------- ------------------------------
spfile                                                string


spfile을 사용하는 경우

SQL> show parameter spfile

NAME                                               TYPE         VALUE
------------------------------------ ----------- ------------------------------
spfile                                                string          /oracle/product/11.2.3/dbs/spfi

                                                                         leORA11.ora                                          <--- spfile의 경로가 나온다.



파라메터 파일 내용 변경하기


pfile은 initSID.ora를 vi로 열어 직접 변경 후 DB를 재구동 해주면 설정값이 적용된다.


spfile은 서버프로세스에 변경을 요청해야 하기 때문에 alter system set 명령을 이용하여 변경하여야 한다.


 - db_cache_size 변경 예제

SYS> alter system set db_cache_size=50m scope=memory;


문장 마지막에 scope 옵션이 있는데, scope 옵션에는 3가지가 올 수 있다.


MEMORY  -  spfile 내용은 변경하지 않고 현재 작동중인 instance에만 적용. DB를 재구동하면 이 설정값은 사라진다.

SPFILE  -  spfile에 내용을 변경하나 현재 작동중인 instance에는 적용하지 않고, DB를 재구동 해야지만 적용된다.

BOTH  -  현재 작동중인 Instance에 적용하고, spfile의 내용도 변경하여 DB를 재구동 하여도 변경된 설정값을 가진다.


spfile에서 pfile 만드는 법


SYS> create pfile from spfile;


pfile에서 spfile 만드는 법


SYS> create spfile from pfile;


※ 주의 dbs 경로에 pfile과 spfile이 모두 존재하는데, 현재 instance가 spfile로 구동되어 있다면, pfile에서 spfile을 만들었을 경우,

 기존 pfile에 문제가 있는 파라미터라면 spfile이 덮어 씌워져 장애가 발생 할 수 있다. 



주요 파라미터들의 의미


1. BACKGROUND_DUMP_DEST

-백그라운드 프로세스 발생 로그와 ALERT LOG 기록경로


2. CLIENT_RESULT_CACHE_LAG (11g 부터)

- CLIENT에 캐시 되어있는 RESULT 유효 사용기간 (milliseconds 단위)


3. CLIENT_RESULT_CAHCE_SIZE (11g 부터)

- RESULT CACHE 크기


4. CLUSTER_DATABASE

- 기본값 FALSE, REAL APPLICATION CLUSTER (RAC) 기능 쓰는지 여부


5. COMPATIBLE

- 호환가능한 이전 버전을 지정


6. CONTORL_FILES :

- CONTROL_FILES 경로 지정, 최대 8개


7. CURSOR_SHARING

- HARD PARSING 줄이고 커서 공유 사용하는데 목적, 동일문장 기준 설정

EXACT : 모든 문장이나 변수 값까지 동일해야함.

SIMILAR : 문장은 동일하나 바인드 변수 값이 달라도됨

FORCE : 문장은 동일하나 상수 값이 다른 SQL도 인정


8. DB_BLOCK_SIZE

- DB 생성후 지정, 이후 변경 불가. DB에 사용될 STANDARD BLOCK SIZE 지정


9. DB_CACHE_ADVICE

- V$DB_CACHE_ADVICE 뷰에서 서로 다른 캐시 사이즈에 대한 통계정보를 모을지 안모을지 지정

OFF : 기능 사용 안함. 메모리 할당 안함.

READY : 기능 사용안함, 할당된 메모리 유지

ON : 기능사용, 추가적인 CPU와 메모리 사용량 증가


10. PGA_AGGREGATE_TARGET

- 하나의 인스턴스에 접속한 서버프로세스가 사용 가능한 총 PGA 크기 설정

값이 0 이면 WORK_SIZE_POLICY 의 값이 MANUAL 로 설정

값이 0 이상이면 WORK_SIZE_POLICY 의 값이 AUTO 로 설정


11. PROCESS

- 기본값은 100, OS 상 오라클 관련 프로세스 최대값 ( USER PROCESS, SERVER ETC)

SESSIONS 과 TRANSACTIONS 파라미터 기본값은 이 파라미터가 기준


12. RECYCLEBIN

- 기본값 ON, 휴지통과 같은 개념. OFF로 하면 TABLE DROP 후 바로 삭제


13. REMOTE_LISTENER

- 원격지 서버 리스너 이름


14. REMOTE_LOGIN_PASSWORDFILE

- 외부 접속시 암호파일 사용여부

SHARED : SYS 유저와 NON-SYS 유저 포함. 하나이상의 DB가 암호파일 공유해서 사용

EXCLUSIVE : SYS 유저와 NON-SYS 유저 포함. 하나의 DB당 하나의 암호 사용

NONE : 암호파일 무시, OS 인증 방식


15. RESULT_CACHE_MAX_RESULT (11g 부터)

- RESULT CACHE 내의 RESULT 최대 크기 지정. 기본값은 RESULT_CACHE_MAX_SIZE 의 5%


16. RESULT_CACHE_MAX_SIZE (11g 부터)

- RESULT CACHE 크기지정, SHARED_POOL_SIZE 의 1%, SGA_TARGET 의 0.5 %, MEMORY_TARGET 의 0.25% 권장


17. RESULT_CACHE_MODE (11g 부터)

- RESULT CACHE 운영방식

MANUAL : /*+result_cache*/ 힌트를 사용한 쿼리는 result cache에 등록

FORCE : 사용되는 모든 SQL RESULT CACHE 등록, /*+no_result_cache* SQL문 RESULT CACHE 등록 하지 않음

AUTO : 많이 사용되는 쿼리 및 설정된 범위를 넘는 쿼리 등록


19. SESSIONS

- 오라클 서버에서 생성 가능한 최대 세션 수. 최대 동시 접속자 수 지정.

궈장값 (전체 동시접속 인원수 + 백그라운드 프로세스 수) X 10%


20. DB_CACHE_SIZE

- DB 크기 지정


21. DB_CREATE_FILE_DEST

- OMF(ORACLE MANAGED FILE) 환경에서 DATA FILE  생성 위치 지정


22. DB_CREATE_ONLINE_LOG_DEST_n

- 최대 5곳 까지 다중화 가능 (n 부분에 5까지 지정)

OMF 환경에서 REDO LOG FILE 과 CONTROL FILE 이 생성될 위치


23. DB_DOMAIN

- 물리적으로 다른 네트워크로 떨어진 오라클 인스턴스들을 하나의 논리적 그룹으로 묶어주는 역활


24. DB_FILE_MULTI_BLOCK _SIZE

- LRU 알고리즘 적용 받지않는 KEEP BUFFER CACHE 크기 지정


25. DB_NAME

- 8문자까지 지정 가능, 대소문자 구분 안함

SINGLE 환경일 경우 INSTANCE NAME과 DB NAME이 같이 사용할 수 있고.

RAC 환경일 경우 INSTANCE NAME 과 DB NAME은 다르다


26. DB_nK_CACHE_SIZE

- NON-STANDARD BLCOK SIZE 크기


27. DB_RECOVERY_FILE_DEST

- FLASH RECOVERY AREA 경로지정

RMAN 백업파일, FLASHBACK LOG FILE, ARCHIVED LOG FILE 저장 (11g 부터는 FLASH RECOVERY AREA)


28. DB_UNIQUE_NAME

- 기본값은 DB_NAME (INSTANCE일 경우), +ASM (ASM 일경우)

회사내에서 유일 해야만 하는 DB이름


29. DB_WRITER_PROCESS

- DBWR 의 갯수지정. 1 또는 CPU 갯수/8


30. INSTANCE_NUMBER

- 해당 인스턴스 고유번호 지정. RAC 환경에서 (1부터 최대값)


31. LDAP_ARCHIVE_DEST_n

- 지정가능 경로 총 10개, REDO LOG FILE 저장경로 지정.


32. LDAP_DIRECTORY_SYSAUTH

- 기본값은 NO, SYSDBA 나 SYSOPER 권한의 디렉토리 인증기능 사용


33. LOG_ARCHIVE_DEST_STATE_n

- 지정경로 사용여부

ENABLE : 기본값, 해당경로 사용

DEFER : 정의된 경로값 유지, 다음 활성화 될때까지 사용안되고 분류

ALTERNATE : 지정된 경로 값들이 모두 실패할 경우, 이 경로가 활성화 됨


34. NLS_LANGUAGE

- DB내에 기본적으로 사용될 언어지정

NLS_DATE_LANGUAGE 와 NLS_SORT 에도 영향을 줌


35. NLS_TERRITORY

- 해당 언어와, 날짜(요일,주) 사용하는 지역 지정


36. OPEN_CURSORS

- 1개의 세션당 PL/SQL 등에서 사용하는 CURSOR의 최대 OPEN 갯수 지정


37. COMPLEX_VIEW_MERGING_FALSE

- 실행계획 세울때 뷰 쿼리를 메인 쿼리와 합쳐서 수행하는 MERGE 기능 (VIEW를 포함하는 쿼리일 경우)

단순 VIEW는 GROUP BY 나 DISTINCT 등이 없는것, 복합 VIEW는 있는것인데 후자일때 MERGE 방법이 복잡해진다. 상황에 맞게 사용


38. _CURSOR_FEATURES_ENABLED = 10

- BUG 6795880 ( 'kksfbc child completion 대기상태 Hang) 해결방법


39. _FAST_START_INSTANCE_RECOVERY_TARGET = 360

- RAC 환경, 한쪽 노드가 장애로 CRASH 되었을 경우 다른 노드에서 해당 CRASH 를 RECOVERY 할 시간 지정


40. _GBY_HASH_AGGREGATION_ENABLED = FALSE

- (10g R2부터) group by 를 order by 처럼 정렬되게 출력함

기존 방식을 group by 수행하면 hash 알고리즘으로 그룹핑해서 정렬되지 않고, order by 를 같이 써줘야 했음


41. _GC_AFFINITY_TIME=0

- RAC 환경에서 자동으로 요청번호를 조사해서 마스터 노드 지정 해주는 시간 간격 (동적 리스타터링)

요청빈도가 많은 쪽이 마스터


42. _GC_UNDO_AFFINITY = FALSE

- RAC에서 UNDO SEGMENT를 활성화 한 노드가 자동으로 마스터노드가 되는 기능을 사용안함으로 지정


43. _IN_MEMORY_UNDO = FALSE

- 작은 트랜잭션이 많을 경우 사용. 대량 DATA 변경되는 경우 사용안함.

활성화는 UNDO DATA 를 UNDO SEGMENT에 기록하지 않고 SHARED POOL 에 만들어져 있는 IMU (IN MEMORY UDNO) POOL에 기록

IMU POOL이 가득차면 기록된 DATA를 한꺼번에 UNDO SEGMENT 에 쓰고, 그 후 UNDO 데이터는UNDO SEGMENT 에 기록된다


44. SESSION_CACHED_CURSORS

- 하나의 SESSION이 CACHE할 수 있는 CURSORS 수


45. SESSION_MAX_OPEN_FILES

- 1개의 세션에서 열 수 있는 최대 BFILES 의 개수


46. SGA_TARGET (10g 부터)

- ASSM (AUTOMATIC SHARED MEMORY MANAGEMENT) 사용시 SGA 전체 사이즈 지정

대상 : DB_CACHE_SIZE, LARGE_POOL_SIZE, STREAMS_POOL_SIZE, SHARED_POOL_SIZE, JAVA_POOL_SIZE

비대상 : LOG BUFFER, BUFFER CAHCE (KEEP, RECYCLE OTHER BLOCK SIZE), FIXED SIZE, INTERNAL ALLOCATIONS


47. UNDO_TABLESPACE

- UNDO TABLESPACE 이름 지정


48. UNDO_MANAGEMENT

- UNDO DATA의 관리 방법 지정

AUTO : AUM (AUTOMATIC UNDO MANAGEMENT) 기능 오라클 자동관리

MANUAL : MUM (MANUAL UNDO MANAGEMENT) 기능 수동관리


49. USER_DUMP_DEST

- USER PROCESS가 생성하는 TRACE FILE 저장 경로




10g 설치 후 변경해야 하는 파라미터들


50. __DG_BROKER_SERVICE_NAMES =''

- DATA GUARD 기능 해재해서 불필요한 SERVICE가 LISTENER에 등록 방지


51. _B_TREE_BITMAP_PLANS = FALSE

- 실행계획 세울때 옵티마이저가 WHERE 절에 조건이 여러개이고 각 조건에 B-TREE 인덱스가 생성되어있을 경우, B-TREE

인덱스를 BITMAP 인덱스로 변환 후 실행계획 세우는데 이것을DISABLE해줌


51. _BLOOM_FILTER_ENABLED = FALSE

- RAC 환경일때 BUG 가 있으므로 기능해제. BLOOM FILTER 란 많은 양의 데이터 중 특정 데이터 ( 조인 파티셔닝 ) 있는지 없는지

빨리 찾아주는 기능


51. _CLEANUP_ROLLBACK_ENTRIES = 2000

- SMON 이 종료된 (KILLED SESSION) 을 ROLLBACK하는 건수. 많을 수록 ROLLBACK속도 향상 다른작업 속도 느려짐


52. CLOSED_CACHED_OPEN_CURSORS = TRUE

- 세션이 강제 종료된 자주 안쓰는 CURSOR를 CLOSE 해줘야함. CURSOR 는 PL/SQL에서 DATA 처리용인데,

COMIMIT 과 ROLLBACK 후 CURSOR 를 CLOSE 해줘야 메모리 막고 에러줄임. 자주쓰는 CURSOR는 CLOSE하면 큰 부하 가져옴

상황에 맞게 사용


53. _KSS_USE_MUTEX_PIN = FALSE

- 기본값은 사용함. SHARED CURSOR 관리를 MUTEX로 관리하라는 기능.

그러나 기존 LOCK/LATCH 보다 기능이 떨어져서 비활성화 시킴


54. _OPTIM_PEEK_USER_BINDS = FALSE

- BIND KEEPING 이라는 기능인데 실행계획 세울때 사용. 부작용이 많아서 비활성화


55. _OPTIMIZER_COST_BASED_TRANSFORMATION = OFF

- 옵티마이저는 SQL문에서 VIEW나 SUB-QUERY를 발견하면 RULE BASE로 QUERY TRANSFORMATION (변환작업)을한다.

10g 이후 부터 COST BASE로 변환작업을 하는데 정상적으로 변환이 일어나지 않아서 실행계획이 잘못 수행되므로 비활성화 시킴


56. _OPTIMIZER_PUSH_PRED_COST_BASED = FALSE

- 통계정보가 정확하다면 PUSH PREDICATE 로 최적의 판단을 하지만, 그렇지 않을 경우가 있으므로 RULE BASE 기반에서 쿼리

변화이 일어나게 설정하도록 PUSH PREDICATE을 비활성화 해준다


57. _PX_USE_LARGE_POOL = TRUE

- PARALLEL QUERY 를 수행한 경우 LARGE POOL 사용우무 결정


58. _ROW_CACHE_CURSORS = 1000

- 데이터 딕셔너리 캐시에 캐싱되는 양을 지정. 기본값 20 인데 충분하지 않음




11g 설치 후 변경 해줘야 하는 파라미터들


59. OPEN_LINKS

- 초기값 4개, 권장값 40개, 하나의 세션에 동시에 사용할 수 있는 DB 링크의 갯수 지정


60. OPEN_LINKS_PER_INSTANCE

- 초기값 4개, 권장값 40개 , 하나의 인스턴스에 동시에 사용할수 있는 DB 링크의 개수 지정


61. MEMORY_TARGET

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


62. DB_WRITER_PROCESS

- 초기값 1, 권장값 2, DBWR이 기본 갯수 지정


63. SESSION_CHACHED_CURSORS

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


64. _DIAG_DAEMON

- 기본값 TRUE, 권장값 FALSE. 분석 데몬의 자동시작 유무 결정


'ORACLE > Oracle DBMS' 카테고리의 다른 글

Control File  (0) 2014.06.11
Oracle Character set 에 관하여  (0) 2014.06.10
Parameter file 초기화 파라미터 파일  (0) 2014.04.23
Oracle Database 시작과 종료  (0) 2014.04.23
Oracle Background Processes  (0) 2014.04.17
Update 문장의 실행 원리  (0) 2014.04.15

Oracle Database 시작과 종료

Oracle DB를 사용하기 위해서는 Oracle이 Open 되어 있어야 하는데, DB를 시작하거나 종료하기 위해서는 SYSDBA의 권한을 가지고 있는 계정으로 접속해야 한다.

SYSDBA 계정으로 접속하는 방법은 여러가지가 있다.

설치후 기본값을 가지고 있는 상태라면, / as sysdba 를 통해 접속이 가능하다.


<10g 이후 - 10g,11g,12c>

$ sqlplus / as sysdba

$ sqlplus sys/manager  as sysdba


<9i 이전 - 9i, 8i>

$ sqlplus "/as sysdba"

ORA11:/oracle> sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Wed Apr 23 09:54:20 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup;
ORACLE instance started.

Total System Global Area  521936896 bytes
Fixed Size                  2202320 bytes
Variable Size             150996272 bytes
Database Buffers          360710144 bytes
Redo Buffers                8028160 bytes
Database mounted.
Database opened.
SQL> 


STARTUP - Startup 명령을 치면 오라클 프로세스가 가장 먼저 Parameter file을 찾아서 읽는다.

Parameter file은 8i까지 기본으로 사용하던 정적 Parameter file 인 pfile과 9i부터 새로 사용하기 시작한 동적 Parameter file 인 spfile이 있다.


NOMOUNT - 오라클 프로세스는 NOMOUNT 단계에서 Parameter file을 읽고 그 파일안에 있는 설정 값을 가지고 instance를 생성한다.

인스턴스는 SGA와 Background 프로세스들로 구성되어 있기 때문에, NOMOUNT 단계에서 RAM에 인스턴스를 위한 메모리 공간을 확보한다.

그리고 인스턴스가 시작하고나서 종료할때까지 중요한 이벤트를 기록하는 Alertlog에 로깅을 시작한다.


MOUNT - NOMOUNT 단계를 마치면 Control file을 읽고 MOUNT 단계로 진행한다.

Control file 위치는 Parameter file 안에 저장 되어 있으며, Database 의 이상 유무를 확인한다.

Instance Crush로 판단되면 Redo log file을 읽어 Instance recovery를 수행. Redo log에 복구할 내용이 없으면 Archive를 찾는데, 이 경우 사용자가 직접 recovery를 해야 한다.


OPEN - DB가 정상적으로 open되어 데이터 조회, 입력, 삭제 등의 업무를 진행 할 수 있다.


※ 참고 : Oracle 7 버전에서는 sqlplus "/as sysdba" 명령을 가지고 SQL> 로 접속하여 startup을 하는 것이 아니라, 서버 매니저 'SVRMGR>' 로 접속하여 DB구동을 한다.



DATABASE OPEN 하기


- NOMOUNT 단계까지만 시작한후 나머지 단계 진행하기

SYS> STARTUP NOMOUNT;

SYS> ALTER DATABASE MOUNT;

SYS> ALTER DATABASE OPEN;


- MOUNT 단계까지만 시작한후 나머지 단계 진행하기

SYS> STARTUP MOUNT;

SYS> ALTER DATABASE OPEN;


- 읽기 전용 상태로 OPEN 하기 (데이터 수정 불가, 조회만 가능)

SYS> STARTUP MOUNT;

SYS> ALTER DATABASE OPEN READ ONLY;


 - RESTRICTED MODE (제한 모드, 허가받은 사용자만 데이터 수정 가능)

SYS> STARTUP RESTRICT;


현재 OPEN 되어 있는 DB에서 RESTRICT 모드 전환

SYS> ALTER SYSTEM ENABLE RESTRICTED SESSION;

SYS> ALTER SYSTEM DISABLE RESTRICTED SESSION;



DATABASE SHUTDOWN 하기


SYS> shutdown;

SYS> shutdown immediate;


Shutdown의 4가지 옵션


1. Normal (기본)

 - shutdown 명령 전에 접속되어 있던 사용자가 있을 경우 강제로 종료시키지 않고 해당 사용자들이 모두 스스로 접속 할때까지 기다렸다가 종료.


2. Transactional

 - 사용자의 접속 종료를 기다리지 않고 강제로 접속 중지 시킨후 instance를 종료. 강제로 접속을 중지시키는 시점은 Transaction이 끝나는 시점.


3. Immediate

 - 사용자의 행동에 상관없이 즉시 접속을 강제 종료. 종료 시점에 commit된 데이터는 datafile에 기록하고, commit 되지 않은 데이터는 Rollback.


4. Abort

 - immediate 처럼 즉시 강제 종료 하나, commit 된 데이터를 저장하거나, commit 되지 않은 데이터를 Rollback 하지 않는다.

  비정상 종료이며 다른 말로 Instance Crush 라고 부른다. startup 시 SMON이 Instance Recovery를 수행하여 복구해야 한다.




'ORACLE > Oracle DBMS' 카테고리의 다른 글

Oracle Character set 에 관하여  (0) 2014.06.10
Parameter file 초기화 파라미터 파일  (0) 2014.04.23
Oracle Database 시작과 종료  (0) 2014.04.23
Oracle Background Processes  (0) 2014.04.17
Update 문장의 실행 원리  (0) 2014.04.15
Select 문장의 실행 원리  (0) 2014.04.15