멋지게 놀아라

1. 기본 아키텍처

오라클과 마찬가지로 인스턴스와 데이터 베이스로 구성 됨.

- 인스턴스

Goldilocks를 기동하기 위한 runtime 정보를 저장하고 있는 메모리 부분과 Background Process로 구성 됨.

- 데이터 베이스

메모리상의 Dictionary/User Data에 대한 정보를 저장하고 있는 File들

Log file/Property file 등 여러 File들

2. 인스턴스

1. Background Process

인스턴스를 관리하기 위하여 gmaster라는 background process가 존재 함.

gmaster는 성능 및 모니터링을 위하여, 비 동기적으로 작업을 수행하는 여러 개의 thread로 구성되어 있음.

gmaster thread들

Main thread

gmaster 프로세스를 기동/종료 한다.

Ager thread

Drop된 오브젝트들이 사용하던 자원들을 정리.

삭제가 되면 system.trc파일에서 확인 할 수 있다.

[AGER] aging table - ..... 

[AGER] aging tablespace ......

Page flushing thread

checkpoint 발생 시 dirty 페이지들을 Disk로 내려쓰기 위하여 I/O Slave들에게 작업을 배분하고, 제어하는 역할을 수행

Log flushing thread

Redo log buffer의 내용을 Redo log 파일에 쓰는 역할.

재 사용 가능한 로그파일이 없어서 Log Buffer에 있는 내용을 Log File로 내려 쓰지 못했을 경우 system.trc 파일에 기록 됨.

[LOG FLUSHER] disable logging - blocked lfsn(1)

Checkpoint thread

로그 스위치(체크포인트 이벤트)가 발생 시 Dirty 페이지들과 Log buffer의 변경 사항들을 Data File(page flusher thread)과 Redo log File(log flusher thread)에 내려쓰게 지시하는 역할

체크포인트 관련 로그는 system.trc에서 확인 할 수 있다.

[CHECKPOINT] begin ~ [CHECKPOINT] save control file ~ [CHECNPOINT] end

Log archiving thread

로그 스위치가 발생 시 온라인 redo log 파일의 복사본 생성.

로그 아카이빙은 체크포인트 과정의 일부이며, system.trc 파일에서 확인 할 수 있다.

[ARCHIVELOG BEGIN] LOG(....) => ARCHIVE(...)

[ARCHIVELOG END] (...) : SUCCESS

Cleanup thread

비 정상 종료 된 Client들의 자원을 비 동기적으로 정리 하고, 해당 트랜잭션을 Rollback 한다.

스냅샷 스테이트먼트들의 타임아웃을 검사하고, 만약 타임아웃을 초과한 세션이 있다면 이를 강제 종료 시킨다.

[CLEANUP] cleaning session .....

[CLEANUP] long statement timeout .......

비 정상적으로 종료된 세션이 배타적(exclusive) 래치를 획득 한 상태에서 공유 메모리를 변경 하는 도중에 kill -9와 같은 시그널로 종료된 경우 데이터 베이스는 더 이상 운영할 수 없는 상태가 된다. 이때 system.trc 파일에는 다음과 같은 메시지가 남으며, 이럴 경우 shutdown abort 명령으로 DB를 종료 시킨 후 재 기동 시켜야 한다.

[CLEANUP] fail to cleaning session .......

I/O Slave thread

Checkpoint 나 Data file load등과 같은 data file 관련 모든 Disk I/O작업을 병렬로 수행.

한번에 기록되는 페이지의 개수는 MAXIMUM_FLUSH_PAGE_COUNT 프로퍼티 값으로 설정.

system.trc에는 다음과 같은 메세지로 남는다.

[IO SLAVE] flush datafile ....

Process Monitor

SHARED_SESSION 프로퍼티가 YES로 설정 된 경우만 실행 된다.

balancer(gbalancer), dispatcher(gdispatcher), shared-server(gserver)등 process들을 실행하고 monitoring하여 비정상 종료된 경우 재실행 시킨다.

glsnr 리스너 프로세스는 감시 대상이 아니다.

Timer thread

사용자 트랜잭션들의 시간 측정 비용을 줄이기 위하여 비 동기적으로 시스템에 시간을 설정하며, 사용자 트랜잭션들은 시스템에 설정 된 시간을 읽는다.

설정 된 시간의 정밀도는 10ms이다.

Timer thread에서 설정한 시간을 사용하는 경우 들

- 타임아웃 : QUERY_TIMEOUT, IDLE_TIMEOUT, DDL_LOCK_TIMEOUT, ...

- TRACE 파일에 남은 메세지 기록 시간

- 로그인, 트랜잭션 시작 시간

- 트랜잭션 완료 후 리두 로그에 기록되는 시간

Cluster Recover thread

Cluster System 에서 Global Transaction 의 복구 처리

Failover thread

Cluster System 에서 특정 노드나 네트워크 장애 시 장애 Member 에 대한 Offline 및 Coordinator 재 선정 등의 Failover 처리를 담당

glsnr

Client-Server 모델일 경우 어플리케이션의 접속 요청을 대기 하는 Listener 프로세스.

dedicate 모드일 경우는 새로운 gserver 프로세스를 기동시켜서 Client와 연결 시키고, shared 모드이면 load-balancer(gbalancer)를 통하여 부하가 적은 dispatcher(gdispatcher)를 선택하여 Client와 연결 시킨다.

gserver

Client-Server모델에서 Client와 연결된 서버 프로세스

Cluster 환경일 때 추가적으로 기동되는 프로세서들(thread)

- Cluster Recover Thread

Cluster System에서 Global Transaction 의 복구를 처리하는 역할을 담당한다.

- Failover Thread

Cluster System에서 특정 노드나 네트워크 장애 시 장애 Member 에 대한 Offline 및 Coordinator 재 선정 등의 Failover 처리를 담당한다.

- cdispatcher

Cluster 패킷의 송수신 및 세션 관리 등을 담당한다.

- cserver

자신이 속한 Member 노드의 Database 에 대한 변경 및 조회 연산을 수행한다.

2. 메모리 영역

인스턴스는 크게 테이블 스페이스 영역과 여러 프로세스가 공동으로 사용하는 Static 영역(SSA)으로 구분 됨.

각 세션마다 독립적으로 사용할 수 있는 힙 전용 메모리 PSA가 있다.

Static 영역(SSA)

SSA의 물리적 시작 주소는 SHARED_MEMORY_STATIC_KEY와 SHARED_MEMORY_ADDRESS에 의해서 결정 된다.

SSA 크기는 SHARED_MEMORY_STATIC_SIZE에 의해서 결정된다. Session/Lock/Transaction Pool 및 Dictionary Cache에서 사용되는 메모리들은 시스템에서 자동으로 관리하며 사용자가 임의로 사용량을 제어할 수 없는 반면 Log Buffer와 Plan Cache는 사용자가 임의로 제어할 수 있다.

Log Buffer와 Plan Cache의 기본 값을 늘리는 경우는 증가량 만큼 SHARED_MEMORY_STATIC_SIZE를 증가시켜야 한다.

인스턴스 기본 정보, 세션정보, SQL 정보, Transaction 정보, Redo Log Buffer, Dictionary cache정보, 기타 여러 운영 정보 등이 있는 영역.

- Log Buffer

- Dictionary Cache

- Plan Cache

- Session Pool

- Lock Pool

- Transaction Pool

테이블스페이스영역

테이블 스페이스의 내용을 담은 Page Frame들과 이를 제어하기 위한 Page Control Header들로 구성 됨.

PSA(Private Static Area)

각 세션마다 독립적으로 사용하는 힙 메모리 영역이며, 최대 크기는 PRIVATE_STATIC_AREA_SIZE에 의해서 결정된다.

PSA는 세션이 만들어 질떄는 초기 값만 할당되며, 필요 시 최대 크기까지 할당 될 수 있다.

3. 데이터 베이스

데이터 베이스는 크게 메모리 영역과 Disk 영역으로 구성된다.

- 메모리 영역

하나 이상의 테이블 스페이스들의 집합체 이며, In-Memory 구조이므로 Replace 작업에 의해서 Disk로 내려가는 경우가 발생 하지 않음.

- Disk 영역

각 테이블 스페이스당 한 개씩 존재하는 Data file들과, 인스턴스 구성 정보를 저장하고 있는 Control File, 인스턴스 환경 설정이 저장된 프로퍼티 파일,

그리고 복구를 위해 기록되는 Redo log file들로 구성 됨.

1. 프로퍼티 파일

인스턴스나 데이터 베이스 관련 프로퍼티를 변경 하고 싶은 경우는 프로퍼티 파일이나, 환경변수에 GOLDILOCKS_<property_name> 형태의 변수로 값을 설정해서 사용 우선순위는 프로퍼티 파일 > 환경변수 순으로 적용된다.

 V$PROPERTY 테이블을 조회 하여 조회 가능

기본 경로 : $GOLDILOCKS_DATA/conf/goldilocks.property.conf  (Text 파일/편집가능)

               $GOLDILOCKS_DATA/conf/goldilocks.property.binary 

               (binary 파일/편집불가/시스템에 의해서 자동으로 생성 됨/Binary파일이 존재 시에 Text파일을 읽지 않음/gdump툴을 이용하여 내용 조회/Alter system set명령으로 변경)

               ALTER SYSTEM SET property_name = value / ALTER SYSTEM RESET property_name

프로퍼티 값 설정 방법

- 값의 유형으로는 문자/숫자/논리형의 세가지 종류가 있다.

- 문자형의 값은 single quotation을 사용해서 설정해야 한다.

- 문자형의 값이 $GOLDILOCKS_DATA의 경로를 포함할 경우 <GOLDILOCKS_DATA>로 사용해야 한다.

- 논리형의 값은 ON/OFF, ENABLE/DISABLE, 1/0, TRUE/FALSE, YES/NO를 사용할 수 있다.

- 숫자 형에 계산식은 사용할 수 없다. (ex. LOG_BUFFER_SIZE=1024 * 1024 (X))

- 사이즈 값을 나타내는 숫자 형의 프로퍼티 값으로는 K (kilobyte), M (megabyte), G (gigabyte), T (terabyte), P (petabyte)를 사용할 수 있다.

주요 프로퍼티들

데이터 베이스 생성시 사용되는 프로퍼티들

데이터 베이스 기동 시 사용되는 프로퍼티들

2. Control File

데이터 베이스의 물리적 구조와 데이터의 일관성에 대한 정보를 저장하고 있다.

Control File은 Database의 디스크상의 물리적인 저장 정보를 기록하고 있는 파일이며, Instance의 Startup시에 가장 처음으로 읽어 들여 Database의 상태를 파악하도록 하는 파일이다. Control File에는 아래와 같은 항목들이 기록 되어 있다

- 이전 Checkpoint시의 Instance 상태

- 이전 Startup시의 Transaction Durability Mode (CDS/TDS)

- 온라인 Redo Log File 정보

- 각 테이블스페이스의 Data File 정보

- Incremental backup 정보

Control File은 바이너리 형식으로 저장되어 있어서, 내용을 확인하려면  "gdump"라는 유틸리티를 사용 해야 한다.

[SHELL]> gdump CONTROL control_0.ctl

- Control File을 gdump 툴을 사용하여 조회하면 각 온라인 Redo File들의 이름과 현재 상태가 표시된다.

- Control File을 gdump 툴을 사용하여 조회하면 각 테이블스페이스에 속한 데이터파일들과 각각의 상태가 표시된다. (V$DATAFILE 테이블을 조회)

- Control File을 gdump 툴을 사용하여 조회하면 현재 Database에 존재하는 각 테이블스페이스의 이름과 상태가 표시된다. (V$TABLESPACE 테이블을 조회)

3. On-line Redo log file

데이터베이스에서 수행되는 모든 DML 작업은 데이터의 영속성을 보장하기 위하여 WAL(Write Ahead Logging)정책을 이용하여 로그를 먼저 남기게 한다.

Database가 비정상적으로 종료되었을 때 미처 Data File에 기록되지 않은 변경 정보들을 Instance의 재기동시 복구하기 위해서, 해당 Instance에서 수행되는 모든 Transaction들이 Database 변경 연산 수행할 때 정보를 남긴 파일이다.

기본적으로 Database가 생성될 때 LOG_FILE_SIZE 프로퍼티의 값에 해당하는 크기로 4개가 생성되며, 필요한 경우 추가도 가능하다.

이 Redo Log 파일들은 circular 방식으로 순환하며 재사용된다.

온라인 Redo Log File이 다음 파일로 Switching 되는 시점에는 Checkpoint가 발생하여, 일부 Dirty된 페이지들을 해당 Data File로 내리게 되는데, 만일 Checkpoint 연산이 지연되어 다음으로 사용될 온라인 Redo Log File에서 변경된 페이지가 아직 내려가지 못한 경우에는(ACTIVE 상태인 경우) 모든 Transaction 들이 Checkpoint 완료 시까지 정지되게 된다. 따라서, Application들의 성격에 따라 적당한 크기의 온라인 Redo File을 생성하는 것이 Database 시스템 성능 향상에 도움이 된다.

로그 그룹의 상태

로그 그룹 추가 (Mount 단계에서만 가능)

로그 멤버 추가 (Mount 단계에서만 가능)

로그 멤버 이름 변경 (Mount 단계에서만 가능)

로그 그룹/멤버 제거 (Mount 단계에서만 가능)

4. Archive log file

log archiving thread는 체크포인트 수행 시 체크포인트 thread에 의해 활성화되어, 리두 로그 파일 중 아카이빙 되어야 할 대상을 찾아서 아카이빙을 수행한다.

 ARCHIVELOG_DIR_1에 설정된 디렉터리에 프로퍼티 ARCHIVELOG_FILE에 설정된 프리픽스와 각 리두 로그 파일의 sequence 번호를 이용한 아카이브 리두 로그 파일 이름으로 생성된다.

아카이브 로그 모드는 프로퍼티 ARCHIVELOG_MODE = 1 이면 아카이브 모드, 0 이면 노 아카이브 모드이다.

명령으로 할 경우는 Mount 단계에서  ALTER DATABASE ARCHIVELOG; / ALTER DATABASE NOARCHIVELOG; 명령을 이용한다.

복구에 필요한 아카이브 로그 파일을 찾는 방법

1. 백업된 데이터 파일의 파일 헤더에 기록된 체크포인트 Lsn을 구한다.

2. 아카이브 리두 로그 파일을 덤프하여 체크포인트 Lsn을 포함하는 아카이브 리두 로그 파일을 구한다.

3. 백업을 이용한 미디어 복구 시 필요한 아카이브 리두 로그 파일은 2에서 구한 아카이브 리두 로그 파일의 직전 로그 파일 부터가 된다.

5. Undo Segment

Undo Segment들은 MEM_UNDO_TBS 테이블스페이스에 저장되며, Transaction들이 부분 혹은 전체 Rollback을 할 때 사용하기 위해 변경 연산 수행 전에 이전 이

미지들을 미리 기록해 둔 Segment이며, 변경연산을 수행하는 Transaction당 한 개씩 할당되어 사용된다.

동시에 다수의 변경 Transaction이 발생하거나, 혹은 대량의 변경연산이 하나의 Transaction으로 수행되는 경우(bulk delete 등)에 대비하여 충분한 Undo 테이블스페이

스를 확보해 두는 것이 좋다.

6. Data File

Data File은 테이블스페이스에 저장된 테이블/인덱스의 내용이 그대로 저장된 파일이다.

Data File은 다음의 요소로 구성되어 있다.

- Page

Database I/O의 최소 단위로 현재 8Kbyte로 정의 되어 있다.

- Extent

일정 개수의 연속된 Page의 집합이다. Segment가 테이블스페이스로부터 공간을 할당해 가는 최소 단위이다.

각 테이블스페이스별로 Extent의 크기는 다를 수 있다

- Segment

특정 타입의 데이터들을 모아 둔 객체이다. Extent들의 집합으로 구성된다

예외적으로 MEM_TEMP_TBS 테이블스페이스와 같은 임시 테이블스페이스는 Redo Logging도 하지 않으며, DataFile도 생성하지 않는다.

데이터 파일 복구

데이터 파일의 정합성이 깨진 경우 데이터 파일을 소유한 테이블스페이스를 OFFLINE상태로 변경한 후 데이터베이스 시작을 수행하거나 해당 데이터 파일에 대한 복구를 수행한 후 데이터베이스를 시작할 수 있다.

테이블 스페이스 Offline

테이블 스페이스 생성

테이블 스페이스 삭제

테이블 스페이스 데이터 파일 추가/삭제/이동

데이터 파일을 삭제 하기 위해서는, 데이터 파일을 추가 한 이후에 한번 도 사용한 적이 없어야 한다.

데이터 파일 이동을 위해서는 테이블 스페이스를 OFFLINE 시킨 후 O/S상에서 해당 파일을 이동 시킨 후에 RENAME 명령을 이용한다.

Temporary 테이블 스페이스 관리

7. Store Mode

Store Mode란 Transaction들이 연산성능을 향상시키기 위해 ACID 프로퍼티 중에서 어떤 부분을 포기할 것인가에 관한 것을 정해 놓은 것이다.

GOLDILOCKS는 특정한 환경 하에서 성능을 최대로 낼 수 있도록 하기 위해 Instance단위로 Store Mode를 정하여 사용할 수 있도록 한다.

GOLDILOCKS는 현재 아래의 2가지 Store Mode를 지원한다.

Store Mode는 Instance를 Startup할 때 프로퍼티 설정을 통해 이루어지며 Transaction들이 서로 다른 Store Mode로 동작할 수는 없다.

또한 Instance가 Online 상태에서는 변경할 수도 없기 때문에 Startup시에 신중하게 생각해서 결정해야 한다.