01장. 오라클 데이터베이스 아키텍처

1장. 오라클 데이타베이스 아키텍처

 

학습목표

 

이 장을 완료하면 다음과 같은 작업의 수행이 가능하다. 

-    오라클 데이터베이스 서버의 주요 아키텍처 구성요소를 나열 할 수 있다.

-    메모리 구조를 설명 할 수 있다.

-    백그라운드 프로세스들을 설명 할 수 있다.

-    논리적 저장 구조와 물리적 저장 구조를 상호 연관 시킬 수 있다.

 

오라클 데이터베이스 서버 아키텍처 : 개요

 

그림 1.1

 

오라클 데이터베이스 서버는 오라클 데이터베이스와 하나 이상의 오라클 데이터베이스 인스턴스로

구성된다. 하나의 인스턴스는 메모리 구조와 백그라운드 프로세스들로 구성된다. 인스턴스가 시작 될

때마다, SGA(System Global Area)라고 부르는 공유 메모리가 할당되고 백그라운드 프로세스들이 시작된다.

SGA는 하나의 오라클 데이터베이스 인스턴스에 관한 데이터와 컨트롤 정보를 포함한다. 백그라운드

프로세스들은 각각의 유저 프로세스들에 대하여 실행 중인 여러 오라클 데이터베이스 서버 프로그램들에

의해 관리 되어지는 기능들을 통합한다. 백그라운드 프로세스들은 비동기적으로 입출력(I/O)을 수행하고,

더 나은 성능과 신뢰성을 위해 향상된 병렬처리를 제공하도록 다른 오라클 데이터베이스 프로세스들을

모니터링한다. 데이터베이스는 이 장의 뒷부분에서 논의할 물리적 파일들과 논리적 저장구조들로

구성되어 있다. 물리적 구조와 논리적 구조가 분리되어 있는 이유는 데이터의 물리적 저장구조는 논리적

저장 구조로의 접근 방식에 영향을 주지 않고 관리 될 수 있어야 하기 때문이다.

참고 : 오라클 RAC(Real Application Clusters)은 두 개 이상의 오라클 데이터베이스 인스턴스로 구성되어

있으며, 상호 연결되어 서로 통신 할 수 있는 여러 개의 클러스터 컴퓨터에서 실행되어 동일한 오라클

데이터베이스에 접근한다.

 

데이터베이스 인스턴스 접속

 

  

그림 1.2

 

사용자들이 오라클 데이터베이스 서버에 연결하면, 사용자들은 오라클 데이터베이스 인스턴스에 접속된다. 데이터베이스

인스턴스는 이러한 사용자들에게 SGA 이외의 추가 메모리 영역과, 오라클 데이터베이스 백그라운드 프로세스들 이외의

프로세스들을 제공한다.

- 클라이언트 또는 포그라운드 프로세스들로 불리우는 유저 프로세스들은 애플리케이션 프로그램의 소프트웨어 코드를

실행하기 위해 생성된다. 대부분의 환경에서는 클라이언트 프로세스들과 서버가 분리되어 있다. 유저 프로세스는

프로그램 인터페이스를 경유하는 해당 서버 프로세스와의 통신을 관리하기도 한다.

- 오라클 데이터베이스 서버는 접속된 유저 프로세스들의 요청을 처리하기 위해 서버 프로세스들을 생성한다. 서버

프로세스는 유저 프로세스와 통신하고, 관련된 유저 프로세스의 요청을 수행하기 위해 인스턴스 및 데이터베이스와

상호 반응한다.

 

오라클 데이터베이스 인스턴스는 각 서버 프로세스가 다수의 유저 프로세스들을 처리하도록 구성 될 수 있다. 적용

서버 구성에서 서버 프로세스는 하나의 유저 프로세스 요청을 처리한다. 공유 서버 구성에서는 많은 유저 프로세스들이

소수의 공유 서버 프로세스들을 공유 할 수 있어서 서버 프로세스들의 수를 최소화하고 가용 시스템 자원을 최대화

할 수 있다. 하나 이상의 디스패처 프로세스가 SGA 내부의 큐에 유저 프로세스의 요청을 저장하면 공유 서버

프로세스가 요청을 큐로부터 꺼내어 응답을 하게 된다.

오라클 데이터베이스 서버는 네트워크 접속의 처리를 담당하는 리스너를 기동한다. 사용자 애플리케이션이 리스너에

접속하면, 리스너는 적용 서버 프로세스를 생성하거나 해당 접속을 디스패처에게 전달한다.

 

접속(connection)과 세션(session)은 유저 프로세스들과 밀접하게 연관되어 있지만, 의미상에서 매우 다르다.

- 접속은 유저 프로세스와 오라클 데이터베이스 인스턴스간의 통신 경로이다. 통신 경로는 유저 프로세스와 오라클

데이터베이스가 동일한 컴퓨터에 존재하는 경우, 현재 사용 가능한 프로세스가 통가 메커니즘(IPC)을 사용하거나

데이터베이스 애플리케이션과 오라클 데이터베이스가 서로 다른 컴퓨터에서 실행되어 네트워크를 통해 통신하는 경우,

네트워크 소프트웨어를 사용하여 수립될 수 있다.

- 세션은 데이터베이스 인스턴스에 로그인 된 현재 데이터베이스 사용자의 상태를 나타낸다. 예를 들어, 사용자가

SQL*Plus를 시작하고, 사용자는 유효한 데이터베이스 사용자 이름과 암호를 제공하면 해당 사용자에 대하여 세션이

수립된다. 세션은 사용자가 접속한 시점부터 사용자가 연결을 끊거나 데이터베이스 애플리케이션을 빠져 나올 때까지

지속 된다.

 

참고 : 동일한 사용자 계정을 사용하는 한 명의 오라클 데이터베이스 사용자는 동시에 여러 개의 세션들을 생성하거나

빠져 나올 수 있다. 예를 들어, 사용자 계정/암호가 HR/HR의 사용자는 동일한 오라클 데이터베이스 인스턴스에 여러

번 접속 할 수 있다.

 

오라클 데이터베이스 메모리 구조 : 개요

 

그림 1.3

 

오라클 데이터베이스는 여러 목적에 의해 메모리 구조를 생성하고 사용한다. 예를 들어, 메모리는 실행 할 프로그램 코드,

사용자 간에 공유 할 데이터, 각각의 접속된 사용자를 위한 개별 데이터 영역을 저장한다. 두 개의 기본 메모리 구조가

인스턴스와 연관 되어 있다.

①   SGA(System Global Area) : SGA는 모든 서버 프로세스들과 백그라운드 프로세스들에 의해 공유된다. SGA는 다음과 같은 데이터 구조를 포함한다.

-    Database buffer cache : 데이터베이스 파일들로부터 읽어 들인 데이터 블록들을 캐시

-    Redo log buffer : 물리적 파일에 기록되기 전의 복구 정보를 캐시

-    Shared pool : 세션 간의 공유 될 수 있는 여러 구조를 캐시

-    Large pool : 오라클 백업 및 복구 작업, I/O 서버 프로세스들과 같은 특정 작업에 의해 사용되는 옵션 영역

-    Java pool : JVM(Java Virtual Machine) 내의 세션 고유 자바 코드 및 데이터를 위해 사용

-    Streams pool : 캡처와 관련된 정보를 저장하고 프로세스들에 적용하기 위해 오라클 스트림에 의해 사용

②   PGA(Program Global Areas) : 서버 프로세스 또는 백그라운드 프로세스와 관련된 데이터 및 제어 정보를

포함하는 메모리 영역. PGA는 전체 PGA 영역으로부터 부차적으로 할당 된다.

 

참고 : 오라클 데이터이스는 메모리 구조를 생성하고 관리하기 위해 초기화 파라메터들을 사용한다.

 

Database Buffer Cache

 

 

그림 1.4

 

데이터베이스 버퍼는 SGA의 일부이며 데이터 파일로부터 읽어온 데이터 블록의 복사본을 저장한다. 모든 사용자들은

해당 인스턴스에 동시에 접속하여 데이터베이스 버퍼 캐시를 공유한다. 오라클 데이터베이스 서버 프로세스가 특정

데이터의 일부분을 최초로 요구하면, 데이터베이스 버퍼 캐시에서 해당 데이터를 탐색한다. 만약, 프로세스가 캐시

내의 이미 존재하던 데이터를 찾으면(캐시 히트), 그 데이터를 메모리에서 직접 읽을 수 있다. 만약, 프로세스가 캐시

내에서 해당 데이터를 찾지 못하면(캐시 미스), 디스크 상의 데이터 파일로부터 데이터 블록을 캐시에 복사하고 해당

데이터를 읽는다. 캐시 히트로 데이터를 읽는 경우가 캐시 미스로 데이터를 읽는 경우에 비하여 빠르다.

 

캐시 내의 버퍼는 LRU(Least Recently Used) 리스트 및 터치 카운트의 조합을 사용하는 복잡한 알고리즘에 의해

관리된다. DBWn(Database Writers) 프로세스들은 데이터베이스 버퍼 캐시 내의 변경된(dirty) 버퍼들을 필요할 때

디스크에 기록하는 역할을 담당한다.

 

Redo Log Buffer

그림 1.5

 

리두 로그 버퍼는 SGA 내의 순환형 버퍼이며, 데이터베이스에서 발생한 변경 사항들에 대한 정보를 저장한다. 이 정보는

리두 엔트리에 저장된다. 리두 엔트리는 INSERT, UPDATE, DELETE, CREATE, ALTER, DROP 작업에 의해 데이터베이스에

발생된 변경사항을 재 구축(또는 재적용)하기 위해 필수 적인 정보를 포함한다. 리두 엔트리는 필요에 따라 데이터베이스

복구에 사용된다. 리두 엔트리는 오라클 데이터베이스 서버 프로세스들에 의해서 사용자 메모리 영역에서 SGA 내부의

리두 로그 버퍼로 복사된다. 리두 엔트리는 버퍼 내에 연속적이고 순차적인 영역에 저장된다. LGWR(Log Writer)

백그라운드 프로세스는 리두 로그 버퍼를 활성화 되어 있는 리두 로그 파일(또는 파일 그룹)에 기록한다. LGWR은

비동기 I/O를 수행 할 수 있는 백그라운드 프로세스이다.

 

참고 : 시스템의 CPU 개수에 따라 하나 이상의 리두 로그 버퍼가 존재 할 수도 있으며, 이러한 리두 로그 버퍼는 자동적으로 할당 된다.

 

Shared Pool

 

그림 1.6

 

SGA의 Shared Pool 영역은 다음과 같은 주요 부분을 포함한다.

①   라이브러리 캐시는 SQL 문장, PL/SQL 프로시저, 패키지의 공유 가능한 부분을 포함한다. 이 영역은 잠금과 같은 제어 구조를 포함하기도 한다.

②   데이터 딕셔너리는 데이터베이스와 관련된 참조 정보를 포함하는 데이터베이스 테이블들의 집합이다. 데이터 딕셔너리는 오라클 데이터베이스에

의해 자주 사용되며, 메모리내의 두 개의 특별한 영역이 딕셔너리 데이터의 저장을 위해 설계되었다. 첫 번째 영역은 로우 캐시(row cache)라고 알려진

데이터 딕셔너리 캐시이며, 다른 영역은 라이브러리 캐시라고 부른다. 모든 오라클 데이터베이스 서버 프로세스들은 데이터 딕셔너리 정보에 접근하기

위해 이러한 두 개의 캐시를 공유한다.

③   결과 캐시(result cache)는 SQL 쿼리 결과 캐시와 PL/SQL 함수 결과 캐시로 구성된다. 이 캐시는 SQL 쿼리 또는 PL/SQL 함수들의 결과를 저장하여,

다음 번에 재실행시 실행 속 도를 빠르게 해준다.

④   제어 구조는 필수적인 잠금 구조이다.

참고 : 일반적으로 Shared Pool 내의 모든 항목들은 수정된 LRU 알고리즘에 따라 플러시 될 때까지 남아 있게 된다.

 

DML 문장의 처리 : 예제

 

그림 1.7

 

DML(Data Manipulation Language) 문장을 실행하기 위한 단계는 다음과 같다.

1. 서버 프로세스는 관련 문장을 수신하고 유사한 SQL 문장이 포함된 공유 SQL 영역이 라이브러리 캐시 내에

존재하는지 확인한다. 만약, 공유 SQL 영역이 발견되면, 서버 프로세스는 요청된 데이터에 대한 사용자의 접근 권한을

확인하고 해당 문장을 처리하기 위해 존재하고 있던 공유 SQL 영역을 사용한다. 그렇지 않으면, 해당 문장에 대하여

새로운 공유 SQL 영역을 할당 받고, 문장을 Parsing 및 처리한다.

2. 만약, 해당 데이터와 롤백 블록이 버퍼 캐시에 존재하지 않으면, 서버 프로세스는 데이터 파일에서 해당 블록을

버퍼 캐시로 잃어 들인다. 서버 프로세스는 수정한 행들에 대하여 잠금을 설정한다.

3. 서버 프로세스는 데이터 버퍼의 변경 사항 뿐만 아니라 언두 정보를 기록한다. 이러한 변경 사항은 메모리 및

롤백 버퍼가 수정되기 전에 리두 로그 버퍼에 먼저 기록된다. 이러한 작업을 기록적 로깅(write-ahead logging)이라고 부른다.

4. 롤백 버퍼는 수정되기 전의 데이터 값을 포함한다. 롤백 버퍼는 DML 문장이 롤백 될 수 있기 때문에 해당 데이터의

변경 전 이미지를 저장하는데 사용된다. 데이터 버퍼는 데이터의 새로운 값을 기록한다.

5.   해당 사용자는 DML 작업의 피드백(해당 작업에 의해서 얼마나 많은 행들이 변경 되었는지를 수신한다.

 

참고 : 버퍼 캐시 내의 모든 변경된 블록들은 더티 버퍼로 표시된다. 즉, 해당 버퍼는 디스크상의 해당 블록과 동일하지

않다. 이러한 버퍼는 DBWn 프로세스들에 의해 즉시 디스크에 기록되지 않는다.

 

COMMIT 처리 : 예제

 

그림 1.8

 

COMMIT이실행되면다음과같은절차가수행된다.

1. 서버 프로세스는 리두 로그 버퍼에 커밋 레코드를 SCN(SystemChangeNumber)과 함께 기록한다. SCN은 점차적으로

증가하며 데이터베이스 내부에서 고유한 숫자이다.

이번 호는 오라클 데이터베이스에 의해 사용되며 데이터 동기화를 위한 내부 타임 스탬프 및 데이터 파일로부터

데이터를 읽어 오는 경우 읽기 일관성을 제공하는 용도로 사용된다. SCN을 사용하면 오라클 데이터베이스는 운영체제의

날짜 및 시간과 관련 없이 일관성 확인을 수행 할 수 있다.

 

2. 백그라운드 LGWR 프로세스는 리두 로그 파일에 모든 리두 로그 버퍼 엔트리와 커밋 레코드가 연속적으로 기록한다.

이후, 오라클 데이터베이스는 인스턴스 장애가 발생했더라도 이러한 변경사항이 복구 될 수 있다는 사실을 보장한다.

3. 서버 프로세스는 유저 프로세스에게 해당 트랜잭션의 완료정보를 피드백 한다.

 

참고 : DBWn은 결국 자신의 내부 타이밍 메커니즘에 기반하여 실제 변경 사항을 디스크에 기록하게 된다.

 

Large Pool

 

그림 1.9

 

다음과 같은 대용량 메모리 할당이 필요할 경우, Large Pool이라고 부르는 옵션 메모리 영역을 구성 할 수 있다.

①   공유 서버, Oracle XA 인터페이스(트랜잭션이 하나 이상의 데이터베이스와 상호 반응해야 하는 경우에 사용), 병렬 실행 버퍼를 위한 세션 메모리

②   I/O 서버 프로세스들

③   오라클 데이터베이스 백업 및 복원 작업

위 메모리 구성요소들을 Large Pool에 할당하면, 오라클 데이터베이스는 SQL 및 PL/SQL 영역의 공유 부분을 캐시

하는데 Shared Pool을 대부분 사용 할 수 있게 된다. 최초에 Shared Pool은 SQL 및 PL/SQL 영역을 저장하기 위해

설계되었다. Large Pool을 사용하게 되면 같은 메모리 영역을 공유하는 대용량 메모리 할당 영역과 소규모 메모리 할당

영역으로 인한 단편화 문제를 방지 할 수 있다. Shared Pool과는 달리 Large Pool은 LRU 리스트를 갖지 않는다.

 

인스턴스가 다음과 같은 구성 요소를 사용한다면 Large Pool을 구성하도록 한다.

①   병렬 실행 : 병렬 쿼리는 병렬 실행 메시지 버퍼를 캐시하기 위해 Shared Pool 메모리 를 사용한다.

②   복구 관리자(Recovery Manager) : 복구 관리자는 백업 및 복원 작업을 수행하는 동안에 I/O 버퍼를 캐시하기 위해 Shared Pool을 사용한다.

③   공유 서버(Shared Server) : 공유 서버 아키텍처에서 각 클라이언트 프로세스에 대한 세션 메모리는 Shared Pool에 포함된다.

 

Java Pool 과 Streams Pool

Java Pool은 JVM 내부의 모든 세션 고유 자바 코드 및 데이터를 위해 사용된다. Java Pool은 오라클 데이터베이스가

실행되는 모드에 따라 서로 다른 방식으로 사용된다. Streams Pool은 Oracle Streams에 의해 독점적으로 사용된다.

Streams Pool은 버퍼링 된 큐 메시지를 저장하고 Oracle Streams 캡처를 위한 메모리를 제공하고 프로세스들에 적용한다.

 

참고 : 자바 프로그래밍과 Oracle Streams에 대한 자세한 논의는 이 과정에서 벗어남.

 

PGA(Program Global Area)

 

그림 1.10

 

PGA 메모리의 내용은 인스턴스가 공유 서버 옵션으로 실행되는지 여부에 따라 달라진다.

일반적으로, PGA 메모리는 다음과 같은 영역으로 구분된다.

①   l 세션 메모리는 세션 변수(로그온 정보) 및 세션과 연관된 다른 정보를 저장하기 위해 할당되는 메모리이다.

공유 서버의 경우, 세션 메모리는 공유된다.

②   l 커서는 특정 SQL 문장의 개별 메모리 구조에 대한 핸들이다.

③   l SQL 작업 영역은 Sort, Hash Join, Bitmap Merge, Bitmap Create와 같은 메모리를 과도하게 사용하는 작업을

지원하기 위해 할당된다. 일반적으로 작업 영역이 클수록 메모리 소비가 큰 특정 작업의 성능은 크게 향상된다.

 

백그라운드 프로세스 역할

그림 1.11

 

non-RAC, non-ASM 환경에서 일반적으로 볼 수 있는 백그라운드 프로세스들은 다음과 같다.

①   DBWn(Database writer process) : 비동기적으로 Database 버퍼 캐시 내의 수정된(더티) 버퍼를 디스크에 기록한다.

②   LGWR(Log writer process) : 로그 버퍼 내에 리두 정보라고 부르는 복구 정보를 디스크 상의 리두 로그 파일에 기록한다.

③   CKPT(Checkpoint process) : 컨트롤 파일과 각 데이터 파일 헤더에 체크포인트 정보를 기록한다.

④   SMON(System Monitor process) : 인스턴스 기동시에 복구를 수행하고 사용되지 않은 임시 세그먼트를 정리한다.

⑤   PMON(Process monitor process) : 유저 프로세스에 장애가 발생한 경우, 프로세스 복구를 수행한다.

⑥   RCBG(Result cache recoverer background process) : Shared Pool 내의 결과 캐시를 유지 관리하는데 사용된다.

⑦   CJQ0(Job queue process) : Scheduler를 통해 일괄 처리에 사용된 사용자 작업을 실행한다.

⑧   ARCn(Arhiver process) : 로그 스위치가 발생하면 리두 로그 파일을 지정된 스토리지 장치로 복사한다.

⑨   QMNn(Queue monitor processes) : Oracle Streams 메시지 큐를 모니터 한다.

⑩   MMON(Manageability monitoring process) : 관리능력과 관련된 백그라운드 작업을 수행한다.

⑪   MMAN(Memory Manager background process) : SGA와 PGA 메모리 구성요소를 자동으로 관리하는데 사용된다.

 

자동 공유 메모리 관리

 

그림 1.12

 

초기 버젼의 오라클 Database에서는 SGA의 전체 크기를 정확하게 제어 할 수 없었다. 그 이유는 오라클이 고정

SGA 영역과 내부 메타 데이터 할당 영역을 사용자가 설정한 SGA 파라메터의 전체 크기와 별개로 할당하였기 때문이다.

초기 버전에서는 Database 버퍼 캐시, Shared Pool, Java Pool, Streams Pool, Large Pool에 대한 메모리 크기를

직접 설정해주어야 했기 때문에 이러한 구성 요소들을 최적의 크기로 설정하는 것은 대단한 도전이었다. 크기를 너무

작게 지정 하면 성능이 저하되고 메모리 부족으로 인한 에러가 발생했으며, 크기를 너무 크게 지정하면 낭비되는

메모리가 많았다.

 

Oracle Database 10g부터는 ASMM(Automatic Shared Memory Management) 기능을 사용하여 Database가 전체

SGA 크기 이내에서 각 메모리 구성요소의 크기를 자동으로 결정할 수 있도록 한다. 시스템은 SGA 내의 모든 메모리를

포함하는 SGA 용량 파라메터(SGA_TARGET)를 사용하며, 여기에는 크기가 자동 조정되는 메모리 구성요소, 크기를 직접

지정해야 하는 구성요소, Database 기동 시에 할당되는 내부 메모리 할당 공간을 포함한다. ASMM은 모든 SGA 구성

요소들에 의해 사용되는 전체 메모리 공간을 지정 할 수 있도록 하여 SGA의 설정을 단순화 시켰다. SGA의 전체 용량을

설정하면, 오라클 Database는 작업 부하에 따라 메모리 크기가 자동으로 조절되는 구성요소들 간에 메모리를 적절히

분산시킨다.

 

참고 : ASMM을 사용하려면 STATISTICS_LEVEL을 TYPICAL 또는 ALL로 설정하여야 한다.

 

자동 SQL 실행 메모리 관리

 

그림 1.13

 

이 기능은 PGA 내부의 작업 영역에 메모리를 자동으로 할당하는 모드를 제공한다. 사용자는 PGA_AGGREGATE_TARGET

파라메터에 인스턴스 세션들의 PGA 영역에 할당한 전체 메모리 크기를 지정하여야 한다. 자동 모드에서는 메모리를

대량으로 소비하는 작업(sort 및 hash join)을 수행 할 때 사용되는 작업 영역이 자동 및 동적으로 조정된다.

 

이 기능은 DSS(Decision Support System) 작업부하 및 복잡한 쿼리를 사용하는 혼합 작업부하를 위한 여러 성능 및

확장성을 제공한다. 전체 시스템 성능은 최대화되고 쿼리들 간의 처리량과 응답시간을 최적화하기 위해 더욱더

효율적으로 가용 메모리가 할당된다. 특별히, 메모리의 향상된 사용으로 인한 이득은 부하가 많이 발생하는 시점에

더욱더 유용하다.

 

참고 : 초기 버전의 오라클 데이터베이스 서버에서는 sort 또는 hash join과 같은 SQL 연산에 사용되는 최대 작업

영역의 크기를 직접 지정해주어야 했기 때문에 작업 부하가 변경되면 이러한 작업은 매우 어려웠다. 현재의 오라클

데이터베이스는 직접 PGA 메모리를 관리 할 수 있도록 지원하지만 특정 세션에만 유용하기 때문에 가능하면 PGA

메모리 관리 기능을 활성화 상태로 두는 것을 권장한다.

 

자동 메모리 관리

 

그림 1.14

 

앞에서 살펴 본 것처럼 인스턴스의 여러 메모리 영역의 크기는 SQL 처리 속도에 직접적으로 영향을 미친다. Database의

작업부하에 따라 이러한 구성요소들의 크기를 직접 설정하는 것은 어렵다. 자동 메모리 관리를 사용하면 시스템은 작업

부하의 메모리 요청에 따라 각 메모리 구성요소의 크기를 자동으로 설정한다.

 

Database 인스턴스에 대하여 MEMORY_TARGET 초기화 파라메터를 설정하면 MMAN 백그라운드 프로세스는 대상

메모리 크기를 자동적으로 조정하여, SGA 내부 구성요소들 간에 필요한 메모리와 SGA와 전체 PGA 간에 필요한

메모리를 적절히 분산시킨다.

 

좀 더 구체적으로 ASMM 기능은 두 개의 백그라운드 프로세스로 구현된 SGA 메모리 중개자인 MMON(Manageability

Monitor)과 MMAN(Memory Manager)를 사용한다. MMON에 의해서 통계 데이터와 메모리 권고 데이터가 주기적으로

수집되며, MMAN은 MMON의 결정에 따라 메모리 구성요소의 크기를 조절한다.

 

참고 : 현재, 이 메커니즘은 Linux, Solaris, HP-UX, AIX, Windows에만 구현되어 있다.

 

Database 스토리지 아키텍처

 

 

그림 1.15

 

오라클 데이터베이스를 구성하는 파일들은 다음과 같이 분류된다.

①   Control files : 데이터베이스 자신에 대한 데이터를 포함한다. (즉, 물리적 데이터베이스 구조 정보). 이 파일들은

데이터베이스에 매우 중요하기 때문에 이 파일들이 없으면 데이터베이스 내의 해당 데이터에 접근하는 데이터

파일들을 오픈 할 수 없다.

②   Data files : 데이터베이스의 사용자 또는 애플리케이션 데이터 뿐만 아니라 메타 데이터와 데이터 딕셔너리를 포함한다.

③   Online redo log files : 데이터베이스의 인스턴스 복구를 가능하게 해준다. 만약, 데이터베이스 서버에 장애가

발생하였고, 어떤 데이터 파일도 유실되지 않았다면, 인스턴스는 이 파일만 가지고 데이터베이스를 복구 할 수 있다.

 

다음 추가 파일들은 데이터베이스의 성공적인 운영을 위해 매우 중요하다.

①   Parameter file : 인스턴스가 기동 될 때, 어떻게 인스턴스를 구성 할 것인지를 정의하는데 사용된다.

②   Password file : sysdba, sysoper, sysasm이 데이터베이스에 원격으로 접속하여 관리 작업을 수행 할 수 있도록 해준다.

③   Backup files : 데이터베이스 복구에 사용된다. 미디어 장애 또는 사용자 오류로 인하여 원본 파일이 망가지거나

삭제된 경우에는 일반적으로 백업 파일을 복원한다.

④   Archived redo log files : 인스턴스에 의해 발생한 데이터 변경(redo) 이력을 포함한다. 이러한 파일들과

데이터베이스의 백업본을 이용하여, 유실된 데이터 파일을 복구 할 수 있다. 즉, 아카이브 로그는 복원된 데이터 파일의

복구를 가능하게 해준다.

⑤   Trace files : 각 서버 및 백그라운드 프로세스는 연관된 트레이스 파일에 기록 할 수 있다. 내부 에러가 프로세스에

의해 탐지되면, 해당 프로세스는 에러에 대한 정보를 자신의 트레이스 파일에 덤프한다. 트레이스 파일에 기록된 정보

중 일부는 개발자에 의해 사용되거나 오라클 지원 서비스에 의해 사용된다.

⑥   Alert log file : 특별한 트레이스 파일이다. 데이터베이스의 경보 로그는 메시지와 에러를 시간 순서대로 기록한다.

각 인스턴스는 하나의 경보 로그 파일을 가지며, 사용자는 주기 적으로 이를 검토하여야 한다.

 

논리적 및 물리적 데이터베이스 구조

 

 

그림 1.16

 

Database는 논리적 구조와 물리적 구조를 갖는다.

 

Tablespaces

Database는 Tablespace라고 부르는 논리적 저장 단위로 나누어지며, 연관된 논리적 저장 구조를 함께

그룹화한다. 예를 들어, Tablespace들은 일부 관리 작업을 단순화하기 위해 애플리케이션의 모든 객체들을

그룹화한다. 서로 다른 애플리케이션들에 대해 하나의 Tablespace만 가질 수 있다.

 

Databases, Tablespaces, Data Files

 

Database, Tablespace, 데이터 파일들간의 관계는 위 그림과 같다. 각 Database는 논리적으로 하나 이상의

Tablespace로 분할되며, Tablespace 내의 모든 논리적 구조들의 데이터를 물리적으로 저장하기 위해 각 Tablespace는

하나 이상의 데이터 파일들로 생성된다. TEMPORARY Tablespace는 임시 파일을 포함한다.

 

Schemas

 

스키마는 Database 사용자가 소유하는 Database 객체의 집합이다. 스키마 객체는 데이터베이스의 데이터를 직접

참조하는 논리적 구조이다. 스키마 객체는 테이블, 뷰, 시퀀스, 저장 프로시저, 동의어, 인덱스, 클러스터, Database

링크와 같은 저장 구조를 포함한다. 일반적으로, 스키마 객체는 애플리케이션이 Database 내에 생성 할 수 있는 모든

것을 포함한다.

 

Data Blocks

 

오라클 Database의 데이터는 최소 저장 단위인 데이터 블록에 저장된다. 하나의 데이터 블록은 디스크 상의 물리적

Database 공간 내, 수 바이트에 해당한다. 데이터 블록 크기는 테이블스페이스를 생성 할 때 각각 지정 할 수 있다.

Database는 오라클 데이터 블록 단위로 빈 데이터베이스 공간을 사용 및 할당한다.

 

Extents

 

논리적 Database 공간의 다음 단계는 익스텐트이다. 익스텐트는 특정 유형의 정보를 저장하는데 사용되는 연속된

데이터 블록의 특정 개수다.

Segments

 

익스텐트의 논리적인 상위 Database 저장 수준은 세그먼트이다. 세그먼트는 특정 논리적 구조에 할당된 익스텐트의

집합이다. 세그먼트의 여러 가지 유형은 다음과 같다.

①   Data segments : 각각의 넌 클러스터, 넌 인덱스 구조 테이블은 데이터 세그먼트를 갖는다. 단, 외부 테이블과

세그먼트를 갖지 않는 전역 임시 테이블은 예외이고, 파티션 테이블은 하나 이상의 세그먼트를 갖는다. 테이블의

모든 데이터는 데이터 세그먼트의 익스텐트에 저장된다. 파티션 테이블의 경우, 각 파티션은 데이터 세그먼트를

갖는다. 각 클러스터는 하나의 데이터 세그먼트를 갖는다. 클러스터 내의 각 테이블 데이터는 클러스터의 데이터

세그먼트 내에 저장된다.

②   Index segments : 각 인덱스는 자신의 전체 데이터를 저장하는 인덱스 세그먼트를 가진다. 파티션 인덱스의

경우, 각 파티션은 하나의 인덱스 세그먼트를 갖는다.

③   Undo segments : 각 Database 인스턴스에 대하여 하나의 UNDO Tablespace가 생성된다. 이 Tablespace는

언두 정보를 임시적으로 저장하기 위해 여러 개의 언두 세그먼트를 포함한다. 언두 세그먼트 내의 해당 정보는 읽기

일관성 Database 정보를 생성하는데 사용되고, Database 복구가 진행되는 동안에 사용자들의 커밋되지 않은 트랜잭션을

롤백하는데 사용된다.

④   Temporary segments : SQL 문장을 완료하기 위해 임시 작업 영역을 필요로하면 오라클 Database는 임시 세그먼트를

생성한다. 문장의 수행이 완료되면, 임시 세그먼트의 익스텐트는 추후 재사용되기 위해 인스턴스에 반납된다.

모든 사용자들을 위해 디폴트 임시 Tablespace를 지정하거나, Database 전체에서 사용될 디폴트 임시 Tablespace를 지정 할 수 있다.

 

오라클 Database는 동적으로 공간을 할당한다. 세그먼트의 기존 익스텐트가 가득 차게 되면, 익스텐트가 추가된다.

익스텐트는 필요할 때만 추가되기 때문에 세그먼트의 익스텐트는 디스크 상에 연속되거나 연속되지 않을 수 있다.

 

Segments, Extents, Blocks

 

 

그림 1.17

 

테이블 및 인덱스와 같은 Database 객체는 Tablespace 내에서 세그먼트로 저장된다. 각 세그먼트는 하나 이상의

익스텐트를 포함한다. 익스텐트는 연속된 데이터 블록으로 구성되기 때 문에 각 익스텐트는 오직 하나의 데이터

파일에만 존재 할 수 있다. 데이터 블록은 Database 내의 가장 작은 I/O 단위이다. Database가 운영체제로부터

다수의 데이터 블록들을 요구하면, 운영체제는 이러한 데이터 블록들을 스토리지 디바이스상의 실제 파일 시스템 또는

디스크 블록으로 맵핑한다. 그러므로, 사용자는 Database 내의 데이터의 물리적 주소를 알 필요가 없으며, 데이터

파일은 여러 개의 디스크 상에 스트라이핑 되거나 미러링 될 수도 있다. 데이터 블록의 크기는 Database 생성 시에

설정 될 수 있다. 8KB의 디폴트 크기는 대부분의 Database에 적당하며, Database가 대용량 테이블 및 인덱스를

가진 데이터웨어 하우스 애플리케이션을 지원해야 한다면 대용량의 블록 크기가 장점이 될 수도 있다. 만약, Database가

읽기와 쓰기가 랜덤으로 발생하는 트랜잭션 애플리케이션을 지원해야 한다면, 작은 블록이 유리 할 수 있다.

최대 블록 크기는 운영체제에 따라 달라지며, 오라클 블록의 가장 작은 크기는 2KB이지만, 거의 사용되지 않는다.

사용자는 비 표준 블록 크기를 갖는 Tablespace를 가질 수 있다.

 

SYSTEM 및 SYSAUX Tablespace

 

각각의 오라클 Database는 반드시 SYSTEM Tablespace와 SYSAUX Tablespace를 가져야 하며, Database

생성시에 자동으로 생성된다. 시스템 디폴트는 smallfile Tablespace 이지만, bigfile Tablespace를 생성 할 수도

있다. Bigfile Tablespace는 초대용량 파일(8 엑사 바이트)을 관리 할 수 있도록 해준다.

테이블 스페이스는 온라인 또는 오프라인 상태가 될 수 있지만, SYSTEM Tablespace는 Database가 오픈 되면 항상

온라인 상태가 되어야 한다. 그 이유는 데이터 딕셔너리 테이블과 같은 Database의 핵심 기능을 지원하기 위한

테이블을 포함하고 있기 때문이다.

 

SYSAUX Tablespace는 SYSTEM Tablespace의 보조 Tablespace이다. SYSAUX 테이블 스페이스는 많은

Database 구성요소들을 포함하고 있기 때문에 모든 Database 구성요소들이 올바르게 동작되도록 하려면 반드시 온라인

상태로 두어야 한다.

 

참고 : SYSAUX Tablespace는 Tablespace 복구를 수행하는 동안 오프라인 상태가 될 수 있지만, SYSTEM Tablespace의

경우에는 오프라인 상태가 될 수 없다. 두 Tablespace는 읽기 전용 상태가 될 수 없다.