Oracle Database 11g：Ch01.Exploring the Oracle Database A.pptx
1. 오라클 데이터베이스 아키텍쳐
학습 목표
- 오라클 데이터베이스의 주요 구성요소를 살펴본다.
- 메모리 구조를 설명한다.
- 백그라운드 프로세스를 설명한다.
- 논리적 저장 구조와 물리적 저장 구조를 상호 연관시킨다.
- ASM 저장소 구성요소를 설명한다.
오라클 데이터베이스
데이터베이스는 하나의 단위로 처리되는 데이터의 집합이다. 데이터베이스의 목적은 연관 정보를 저장하고 읽는
것이다. 오라클 관계형 데이터베이스 관리 시스템(RDBMS)는 다중 사용자 환경에서 대량의 데이터를 신뢰성있게
관리 할 수 있기 때문에 많은 사용자들이 동시에 동일한 데이터에 접근 할 수 있다. 또한, 고성능을 제공하면서
이러한 작업이 가능하다. 뿐만 아니라 동시에 인가 되지 않은 접근을 방 지하고 장애 복구를 위한 효율적인 솔루션을
제공한다.
서버연결
데이터베이스 사용자는 다음 3가지 방법 중 하나로 오라클 서버에 접속 할 수 있다.
- 사용자는 오라클 인스턴스가 실행 중인 운영 체제에 로그온하고 애플리케이션 또는 툴을 실행한 다음,
해당 시스템의 데이터베이스에 접근 할 수 있다. 호스트 운영 체제에서 사용 가능한 IPC 메커니즘을
이용하여 통신 경로가 수립된다.
- 사용자는 로컬 컴퓨터의 애플리케이션 또는 툴을 시작하고, 네트워크를 경유하여 오라클 데이터베이스가
실행 중인 컴퓨터에 연결한다. 이러한 구성(클라이언트/서버)에서 네트워크 소프트웨어가 사용자와 백엔드
서버 간의 통신에 사용된다. 클라이언트/서버 아키텍처 데이터베이스 시스템은 네트워크를 경유하여
프론트엔드(클라이언트)와 백엔드(서버)로 구성된다. 네트워크 소프트웨어 사용자와 서버 간의 통신에 사용된다.
a 클라이언트는 데이터베이스 서버에서 수행될 작업을 요청하는 데이터베이스 애플리케이션이다.
클라이언트는 서버에서 관리되는 데이터를 요청, 처리, 표시한다. 클라이언트 워크스테이션은 이러한
작업에 최적화 되어 있을 수 있다. 예를 들어, 클라이언트는 대용량의 디스크가 필요하지 않으며, 뛰어난
그래픽 기능이 필요하지 않을 수 있다. 가끔은 클라이언트가 데이터베이스 서버가 아닌 다른 컴퓨터에서
실행된다. 많은 클라이언트는 하나의 서버에 대하여 동시에 실행 될 수 있다.
b 서버는 오라클 데이터베이스 소프트웨어를 실행하고 동시, 공유 데이터 접근이 필요한 기능을 처리한다.
서버는 클라이언트 애플리케이션으로부터의 요청을 수락 및 처리한다. 서버를 관리하는 컴퓨터는 해당 임무에
최적화 되어 있다. 예를 들어, 서버 컴퓨터는 대용량의 디스크와 고속의 프로세서를 가지고 있을 수 있다.
- 사용자는 로컬 컴퓨터(클라이언트)에서 툴(웹브라우저)을 경유하여 애플리케이션 서버에 접근한다. 그 다음,
애플리케이션 서버는 클라이언트를 대신하여 백엔드 데이터베이스 서버와 상호 작용한다. 전통적인 멀티티어
아키텍처는 다음 구성요소를 갖는다.
- 작업을 시작하는 클라이언트 또는 개시자 프로세스
- 작업의 일부분을 수행하는 하나 이상의 애플리케이션 서버. 애플리케이션 서버는 애플리케이션 로직의
많은 부분을 포함하며, 클라이언트를 위한 데이터 접근을 제공한다. 또한, 일부 쿼리 처리를 수행한 다음,
데이터베이스 서버로부터 일부 부하를 제거한다. 애플리케이션 서버는 클라이언트와 다중 데이터베이스 서버 간의
인터페이스 역할을 수행하며 보안의 추가적인 수준을 제공한다.
- 작업에 사용되는 대부분의 데이터를 저장하는 말단 서버 또는 데이터베이스 서버
이 아키텍처는 애플리케이션 서버의 사용으로 인하여 다음과 같은 작업을 수행 할 수 있다.
- 클라이언트(웹 브라우저 같은)의 인증 검증
- 오라클 데이터베이스 서버 연결
- 클라이언트를 대신하여 요청된 작업을 수행
오라클 데이터베이스 서버 아키텍처 : 개요
오라클 데이터베이스 서버 아키텍처는 메모리 구조, 프로세스 구조, 저장 구조의 3가지 주요 구조로 이루어저
있다. 기본적은 오라클 데이터베이스 시스템은 오라클 데이터베이스와 데이터베이스 인스턴스로 구성된다.
데이터베이스는 물리적 구조와 논리적 구조로 구성되어 있다. 물리적 구조와 논리적 구조는 분리 되어 있기
때문에 데이터의 물리적 구조는 논리적 저장 구조의 접근 방법에 영향을 주지 않고 관리가 가능하다.
인스턴스는 메모리 구조와 인스턴스와 연관된 백그라운드 프로세스로 구성된다. 인스턴스가 시작 될 때마다
SGA(System Global Area)로 부르는 공유 메모리 영역이 할당되고 백그라운드 프로세스가 시작된다. 프로세스들은
컴퓨터의 메모리 내에서 수행되는 작업이다. 프로세스는 “제어 스레드” 또는 일련의 절차를 수행하는 운영 체제
내의 메커니즘으로 정의 된다. 데이터베이스 인스턴스가 시작된 후, 오라클 소프트웨어는 인스턴스와 특정
데이터베이스를 연관시킨다. 이것을 데이터베이스 마운트라고 부른다. 그 다음, 데이터베이스는 오픈 될 준비가
되며, 인가 받은 사용자들에 의해 접근이 가능한 상태가 된다.
주의 : 오라클 ASM(Automatic Storage Management)은 메모리 및 프로세스 구성요소에 대하여 인스턴스 개념을
사용하지만 특정 데이터베이스와 연관되지 않는다.
인스턴스 : 데이터베이스 구성
각 데이터베이스 인스턴스는 오직 하나의 데이터베이스와 연관된다. 만약, 동일한 서버에 여러 개의
데이터베이스가 존재한다면, 각 데이터베이스에 대하여 별도의 데이터베이스 인스턴스가 존재 한다.
데이터베이스 인스턴스는 공유 될 수 없다. RAC(Real Application Cluster)데이터베이스는 보통 동일한 공유
데이터베이스에 대하여 분리된 서버에 여러 개의 인스턴스를 갖는다. 이 모델에서 동일한 데이터베이스는
각 RAC 인스턴스에 연관되며, 이러한 요구사항을 만족시키기 위해 적어도 하나의 데이터베이스가 하나의
인스턴스에 연관된다.
데이터베이스 인스턴스 연결
연결과 세션은 사용자 프로세스에 대하여 밀접히 연관되어 있지만, 그 의미는 매우 다르다. 연결은 사용자
프로세스와 오라클 데이터베이스 인스턴스 간의 통신 경로이다. 통신 경로는 IPC 메커니즘(사용자 프로세스와
오라클데이터베이스를 실행하는 컴퓨터) 또는 네트워크 소프트웨어(데이터베이스 애플리케이션과 오라클
데이터베이스를 실행하는 서로 다른 컴퓨터가 네트워크를 경유 하여 통신)를 이용하여 수립된다.
세션은 데이터베이스 인스턴스에 로그인한 현재 사용자의 상태를 나타낸다. 예를 들어, 사용자가 SQL*Plus를 시작하면,
사용자는 유효한 사용자명과 암호를 반드시 제공하여야 한다. 그 다음, 해당 사용자를 위한 세션이 수립된다.
세션은 사용자가 접속한 시간부터 데이터베이스 애플리케이션과의 접속을 해제하거나 종료 할 때까지 유지된다.
하나의 오라클 데이터베이스에 대하여 동일한 사용자명을 이용하여 여러 개의 세션이 동시에 생성되고 존재 할 수
있다. 예를 들어, HR/HR의 사용자명/암호를 사용하는 사용자는 동일한 오라클 데이터베이스 인스턴스에 여러 번
접속 할 수 있다.
오라클 데이터베이스 메모리 구조
오라클 데이터베이스는 다양한 목적으로 메모리 구조를 생성하고 사용한다. 예를 들어, 메모리는 실행 할 프로그램
코드, 사용자 간 공유할 데이터, 연결된 각 사용자에 대한 개별 데이터 영역을 저장한다. 2개의 기본 메모리 구조가
인스턴스와 관련되어 있다.
- SGA(System Global Area) : SGA 구성요소라고 알려진 공유 메모리 구조 그룹이며 하나의 오라클 데이터베이스
인스턴스에 대한 데이터 및 제어 정보를 포함한다. SGA는 모든 서버 프로세스와 백그라운드 프로세스에 의해
공유 된다. SGA에 저장된 데이터의 예로서 캐시된 데이터 블록과 공유 SQL 영역이 있다.
- PGA(Program Global Area) : 서버 프로세스 또는 백그라운드 프로세스에 대한 데이터 및 제어 정보를 포함
하는 메모리 영역. PGA는 서버 프로세스 또는 백그라운드 프로세스가 시작될 때, 오라클 데이터베이스에 의해
생성되는 비 공유 메모리이다. 서버 프로세스만이 PGA에 접근 할 수 있다. 각 서버 프로세스와 백그라운드
프로세스는 자신만의 고유한 PGA를 갖는다.
SGA는 인스턴스에 대한 데이터 및 제어 정보를 갖는 메모리 영역이다. SGA는 다음과 같은 데이 터 구조를 갖는다.
- Shared pool : 사용자들 간의 공유 될 수 있는 다양한 구조를 캐시한다.
- Database buffer cache : 데이터베이스로부터 읽어온 데이터의 블록들을 캐시한다.
- KEEP buffer pool : 데이터베이스 버퍼 캐시의 특별한 타입으로 오랜 시간 동안 메모리 내에 데이터 블록이 유지 될 수 있도록 한다.
- RECYCLE buffer pool : 데이터베이스 버퍼 캐시의 특별한 타입으로 빠른 시간 내에 메모 리에서 블록이 재거되어 재활용 될 수 있도록 한다.
- nK buffer cache : 다수의 특별한 데이터베이스 버퍼 캐시 중의 하나로서 디폴트 데이터베이스 블록 크기가 아닌 다른 크기의 블록을 저장 할 수 있도록 설계한 것이다.
- Redo log buffer : 리두 정보(인스턴스 복구용)가 디스크의 물리적 리두 로그 파일에 기록 되기 전에 캐시되는 곳이다.
- Large pool : 오라클 백업 및 복구 작업, I/O 서버 프로세스와 같은 특정 대용량 프로세스 들을 위해 대용량 메모리 할당을 제공하는 선택 영역
- Java pool : JVM(Java Virtual Machine)내의 모든 세션 고유 자바 코드 및 데이터를 위해 사용된다.
- Streams pool : 캡처 및 적용에 필요한 정보를 저장하기 위해 Oracle Streams에 의해 사용된다.
Enterprise Manager 또는 SQL*Plus를 이용하여 인스턴스를 기동하면 SGA에 할당된 메모리의 크기가 표시된다.
PGA는 각 서버 프로세스를 위한 데이터 및 제어 정보를 포함하는 메모리 영역이다. 오라클 서버 프로세스는
클라이언트의 요청을 처리한다. 각 서버 프로세스는 해당 서버 프로세스가 시작 될 때 할당된 자신 고유의
PGA를 갖는다. PGA로의 접근은 서버 프로세스만이 가능하며, 서버 프로세스를 대신하여 오라클 코드에 의해서만
PGA를 읽고 기록할 수 있다. PGA는 스택 공간과 UGA(User Global Area)로 구분되어 있다. 동적 SGA 인프라를
사용하면 데이터베이스 버퍼 캐시(database buffer cache), 공유 풀(shared pool), 대용량 풀(large pool),
자바 풀( java pool), 스트림 풀(stream pool)의 크기를 인스턴스를 정지하지 않은 상태에서 변경 할 수 있다.
오라클 데이터베이스는 메모리 구조를 생성 및 관리하기 위해 초기화 파라메터를 사용한다. 메모리를 관리하는 가장
간단한 방법은 데이터베이스가 자동으로 관리 및 튜닝하도록 하는 것이다. 이를 위해서 메모리 크기 목표치(MEMORY_TARGET)와
최대 메모리 크기(MEMORY_MAX_TARGET) 초기화 파라메터를 사용하면 된다.
Shared Pool
SGA의 공유 풀 부분은 라이브러리 캐시, 데이터 딕셔너리 캐시, SQL 쿼리 결과 캐시, PL/SQL 함수 결과 캐시,
병렬 실행 메시지를 위한 버퍼, 제어 구조들을 포함한다. 데이터 딕셔너리는 데이터베이스, 해당 구조, 사용자들에
대한 참조 정보를 포함하는 데이터베이스 테이블과 뷰의 집합이다. 오라클 데이터베이스는 SQL 문장을 파싱하는
동안 자주 데이터 딕셔너리에 접근한다. 이러한 접근은 오라클 데이터베이스를 지속적으로 운영하는데 필수적이다.
데이터 딕셔너리는 오라클 데이터베이스에 의해 매우 자주 접근되기 때문에 딕셔너리 데이터를 저장하도록 메모리
내에 두 곳의 저장 장소가 설계되었다. 한 곳은 데이터 딕셔너리 캐시라고 부르며 버퍼 대신 행으로서 데이터를
저장하기 때문에 로우 캐시라고도 한다. 딕셔너리 데이터를 저장하는 메모리 내의 다른 장소는 라이브러리
캐시이다. 모든 오라클 데이터베이스 사용자 프로세스들은 데이터 딕셔너리 정보에 접근하기 위해 이 두 개의
캐시를 공유한다.
오라클 데이터베이스는 공유 SQL 영역(뿐만 아니라 PGA 내의 개별 SQL 영역)에서 실행되는 각 SQL 문장을
나타낸다. 오라클 데이터베이스는 2명의 사용자들이 동일한 SQL 문장을 실행하는 경우를 인식하여 해당 사용자
들을 위해 공유 SQL 영역을 재사용한다.
공유 풀 영역은 주어진 SQL 문장에 대하여 파싱 트리와 실행 계획을 포함한다. 오라클 데이터베이스는
여러 번 실행되는 SQL 문장에 대하여 하나의 공유 SQL 영역을 사용함으로서 메모리를 절약하는데 많은 사용자
들이 동일한 애플리케이션을 실행하는 경우에 주로 발생한다.
새로운 SQL 문장이 파싱되면 오라클 데이터베이스는 공유 SQL 영역에 파싱 결과를 저장하기 위해 공유 풀에
메모리를 할당한다. 이 메모리의 크기는 문장의 복잡성에 따라 달라진다.
오라클 데이터베이스는 개별 SQL 문장을 처리하는 방식과 거의 동일한 방식으로 PL/SQL 프로그램 유닛
(프로시저, 함수, 패키지, 익명 블록, 데이터베이스 트리거)을 처리한다. 오라클 데이터베이스는 프로그램 유닛의 파싱
및 컴파일 형태를 저장하기 위해 공유 영역을 할당한다. 오라클 데이터베이스는 로컬 변수, 전역 변수, 패키지
변수(패키지 인스턴스화로 알려져 있는)를 실행하는 세션 고유 값과 SQL 실행을 위한 버퍼를 저장하기 위한
개별 영역을 할당한다. 만약, 한 사람 이상의 사용자가 동일한 프로그램 유닛을 실행하면 단일 공유 영역이
모든 사용자에 의해서 사용된다. 이 때, 모든 사용자들은 자신의 세션에 고유한 값을 저장하기 위해 개별 SQL
영역에 대한 별도의 복사본을 유지한다.
PL/SQL 프로그램 유닛 내에 포함된 개별 SQL 문장은 다른 SQL 문장과 유사하게 처리된다. PL/SQL 프로그램 유닛에
포함된 문장임에도 불구하고, 이러한 SQL 문장은 파싱된 표현을 저장하기 위한 공유 영역과 해당 문장을
실행하는 각 세션 별 개별 영역을 사용한다.
SQL 쿼리 결과 캐시와 PL/SQL 함수 결과 캐시는 Oracle Database 11g의 새로운 기능이다. 이 기 능들은 동일한
인프라를 공유하며 동일한 동적 성능 뷰(V$)에 표시되고, 동일한 제공 패키지를 이용하여 관리된다.
쿼리 및 부분 쿼리 결과는 SQL 쿼리 결과 캐시 내 메모리에 캐시 되어 질 수 있다. 그 다음, 데이터 베이스는 이러한
쿼리 및 부분 쿼리가 다시 실행되면 캐시된 결과를 사용한다. SQL 쿼리 결과 캐시로부터 읽어온 결과는 쿼리를 다시
실행하는 것보다 빠르기 때문에 자주 반복되는 쿼리의 경우, 결과가 캐시에 저장되면 상당한 성능 향상을 얻을
수 있게 된다. PL/SQL 함수는 때때로 쿼리에서 제공된 하나 또는 여러 개의 입력을 계산하여 리턴하는데 사용
된다. 일부의 경우, 이러한 쿼리는 함수 호출 횟수와 비교 할 때, 그 결과는 자주 변하지 않는 데이터에
접근한다. PL/SQL 함수의 원본 문장에 특별한 문법을 사용하면, 함수 결과가 PL/SQL 함수 결과 캐시에
저장되도록 요청하고, 정확성을 보장하기 위해 테이블들에 DML이 발생하면 캐시가 삭제 되도록 할 수 있다.
공유 풀의 고정 영역은 SGA에 대한 기동 오버헤드를 나타낸다. 이 영역은 일반적인 크기의 공유 풀 또는
SQL과 비교할 때 매우 작은 영역이다.
Database Buffer Cache
데이터베이스 버퍼 캐시는 데이터 파일 또는 읽기 일관성 모델을 만족시키기 위해 동적으로 구축된 블록 이미지를
저장하는 SQL의 일부분이다. 인스턴스에 동시에 접속한 모든 사용자들은 데이터베이스 버퍼 캐시를 공유한다.
오라클 데이터베이스 사용자가 최초로 데이터의 특정 부분을 요구하면, 데이터베이스 버퍼 캐시에서 해당 데이터를
검색한다. 만약, 캐시 내에 해당 데이터가 이미 존재한다면(캐시 적중), 메모리로부터 해당 데이터를 읽을 수 있다.
그러나, 캐시 내에서 해당 데이터를 찾을 수 없다면(캐시 실패), 디스크 상의 데이터 파일에 존재하는 데이터에 직접
접근하기 전에 먼저 캐시 내의 버퍼에 해당 블록을 먼저 복사하여야 한다. 캐시 적중을 통한 데이터 접근은 캐시
실패를 통한 데이터 접근에 비하여 고속이다.
캐시 내의 버퍼는 LRU(Least Recently Used)리스트와 터치 카운트의 조합을 사용하는 복잡한 알고리즘으로 관리된다.
LRU는 가장 최근에 사용된 블록들이 메모리에 유지되도록 하여 디스크 접근을 최소화하도록 보장한다.
KEEP 버퍼 풀과 RECYCLE 버퍼 풀은 특별한 버퍼 풀 튜닝을 위해 사용된다. KEEP 버퍼 풀은 블록 이 LRU에 의해
유지되는 기간보다 오랫동안 메모리 내의 버퍼에 유지되도록 설계되었다. RECYCLE 버퍼는 블록이 LRU에 의해
유지되는 기간보다 더 빨리 버퍼에서 삭제되도록 설계되었다.
추가적인 버퍼 캐시는 디폴트 블록 크기와 다른 크기의 블록들을 저장 할 수 있도록 구성 할 수 있다.
Redo Log Buffer
리두 로그 버퍼는 데이터베이스에 발생한 변경 사항에 대한 정보를 저장하는 SGA 내의 순환형 버퍼이다. 이 정보는
리두 엔트리에 저장된다. 리두 엔트리는 DML, DDL, 내부 작업에 의해서 데이터베이스에서 발생한 변경 사항을 재구축
(또는 재적용)하는데 필수적인 정보를 포함한다. 리두 엔트리는 필요한 경우, 데이터베이스 복구에 사용된다. 서버
프로세스가 버퍼 캐시를 변경하면, 리두 엔트리가 생성되고 SGA내의 리두 로그 버퍼에 기록된다. 리두 엔트리는 버퍼
내에서 연속적이고 순차적인 공간을 갖는다. LGWR 백그라운드 프로세스는 리두 로그 버퍼를 디스크상의 활성 리두
로그 파일(또는 파일 그룹)에 기록한다.
Large Pool
데이터베이스 관리자는 다음과 같은 대용량 메모리 할당 작업을 위해 대용량 풀이라고 부르는 옵션 메모리 영역을 구성 할 수 있다.
- 공유 서버 및 Oracle XA 인터페이스(다중 데이터베이스에서 트랜잭션의 상호작용을 위해서 사용)를 위한 세션 메모리
- I/O 서버 프로세스
- 오라클 데이터베이스 백업 및 복원 작업
- 병렬 쿼리 작업
- 개선된 큐 메모리 테이블 저장소
공유 서버, Oracle XA, 병렬 쿼리 버퍼를 위해 대용량 풀에 메모리를 할당하면, 오라클 데이터베이스는 공유 풀은 공유
SQL을 캐시하는데 주로 사용될 수 있으며, 공유 SQL 캐시를 축소함으로서 유발되는 성능 부담을 피할 수 있다.
또한, 오라클 데이터베이스 백업 및 복원 작업, I/O 서버 프로세스, 병렬 버퍼를 위한 메모리는 약 수 백 킬로바이트의
버퍼를 필요로 한다. 대용량 풀은 공유 풀에 비해서 그러한 대용량 메모리에 요청을 더욱 만족시킨다. 대용량 풀은
LRU 리스트에 의해 관리되지 않는다.
Java Pool과 Streams Pool
자바 풀 메모리는 JVM 내의 모든 세션 고유 자바 코드와 데이터를 저장하는데 사용된다. 자바 풀 메모리는 오라클
데이터베이스가 실행되는 모드에 따라 서로 다른 방식으로 사용된다. 스트림 풀은 Oracle Streams에 의해서만 사용된
다. 스트림 풀은 버퍼링 된 큐 메시지를 저장하고 Oracle Streams 캡처 프로세스와 적용 프로세스를 위한 메모리를
제공한다. 특별히 설정하지 않는 한, 스트림 풀의 크기는 0부터 시작한다. Oracle Streams가 사용되는 경우,
풀의 크기는 필요에 따라 동적으로 증가한다.
PGA(Program Global Area)
PGA는 서버 프로세스에 대한 데이터 및 제어 정보를 포함하는 개별 메모리 영역이다. 각 서버 프로세스는 고유한
PGA를 포함한다. PGA로의 접근은 해당 서버 프로세스로 한정되며 오라클 코드에 의해서만 읽을 수 있다. 개발자의
코드로 PGA에 접근 할 수 없다. 모든 PGA는 스택 공간을 포함한다. 전용 서버 환경에서, 데이터베이스 인스턴스에
접속된 각 사용자는 별도의 서버 프로세스를 갖는다. 이러한 유형의 접속의 경우, PGA는 UGA(User Global Area)라고
알려져 있는 하위 메모리 영역을 포함한다. UGA는 다음과 같은 항목으로 구성된다.
- 커서에 대한 실행 정보를 저장하기 위한 커서 영역
- 세션에 대한 제어 정보를 위한 사용자 세션 데이터 저장소
- 다음 항목으로 구성된 SQL 문장을 처리하기 위한 SQL 작업 영역
① ORDER BY와 GROUP BY와 같은 데이터 정렬 기능을 수행하는 정렬 영역
② 테이블의 해시 조인을 수행하는 해시 영역
③ 데이터 웨어 하우스에서 일반적인 비트맵 인덱스 생성을 위해 사용되는 비트맵 생성 영역
④ 비트맵 인덱스 실행 계획을 풀이하기 위한 비트맵 병합 영역
공유 서버 환경에서 다중 클라이언트 사용자는 서버 프로세스를 공유한다. 이 모델에서 UGA는 PGA에서 SGA(공유 풀
또는 대용량 풀이 구성되어 있으면 대용량 풀)로 이동하여, PGA는 스택 공간만 남는다.
퀴즈
서버 프로세스 또는 백그라운드 프로세스에 대한 데이터 및 제어 정보를 포함하고 있는 메모리 영역은?
1. Shared Pool
2. PGA
3. Buffer Cache
4. User Session data
퀴즈
데이터 파일로부터 데이터베이스 버퍼 캐시로 읽어 들이는 것은?
1. 행
2. 변경 사항
3. 블록
4. SQL
프로세스 아키텍처
오라클 데이터베이스 시스템에서 프로세스들은 3개의 주요 그룹으로 분류된다.
- 애플리케이션 또는 오라클 툴 코드를 실행하는 유저 프로세스
- 오라클 데이터베이스 서버 코드(서버 프로세스와 백그라운드 프로세스 포함)를 실행하는 오라클 데이터베이스 프로세스
- 단일 데이터베이스에 한정되지 않는 오라클 데몬 및 애플리케이션 프로세스
사용자가 애플리케이션 프로그램 또는 SQL*Plus와 같은 오라클 툴을 실행하는 경우, 사용자의 애플리케이션의
지칭하기 위해 유저 프로세스라는 용어를 사용한다. 유저 프로세스는 데이터베이스 서버 머신에 존재 할 수도 있으며,
존재 하지 않을 수도 있다. 또한, 오라클 데이터베이스는 유저 프로세스가 제출한 명령을 실행하기 위해 서버
프로세스를 생성한다. 여기에 추가하여 오라클 서버는 인스턴스에 대해 백그라운드 프로세스의 집합을 가지는데,
이 백그라운드 프로세스는 메모리 구조를 관리하고, 디스크에 데이터를 기록하기 위해 비동기적으로 I/O를 수행하며,
다른 필수 작업을 수행하기 위해 다른 프로세스 및 운영체제와 서로 상호작용한다.
프로세스 구조는 운영체제와 오라클 데이터베이스 옵션의 선택에 따라 달라진다. 접속된 사용자들에 대한 코드는 전용
서버 또는 공유 서버로 구성되어 질 수 있다.
- 전용 서버:각 세션에 대하여 데이터베이스 애플리케이션이 오라클 데이터베이스 서버 코드를 실행하는 전용 서버
프로세스에 의해 처리되는 유저 프로세스에 의해서 실행된다.
- 공유 서버:각 연결에 대하여 전용 서버 프로세스가 필요하지 않다. 디스패처가 유입된 네트워크 세션 요청을 공유
서버 프로세스 풀에 직접 전달한다.
공유 서버 프로세스는 어떠한 클라이언트 요청도 처리한다.
프로세스 구조
서버 프로세스 인스턴스에 연결된 유저 프로세스의 요청을 처리하기 위해 오라클 데이터베이스는 서버 프로세스를
생성한다. 유저 프로세스는 오라클 데이터베이스에 접속한 애플리케이션 또는 툴로 표현된다. 유저 프로세스는 오라클
데이터베이스와 동일한 머신에 있거나 원격 클라이언트에 존재하여 오라클 데이터베이스에 접근하기 위해 네트워크를
이용한다. 전용 서버 환경에서 유저 프로세스는 먼저 리스너 프로세스와 통신하고, 리스너는 서버 프로세스를 생성한다.
각 유저 애플리케이션을 대신하여 생성된 서버 프로세스는 다음의 하나 이상의 작업을 수행 할 수 있다.
- 애플리케이션에 의해 제출된 SQL 문장을 파싱 및 실행
- 디스크의 데이터 파일로부터 필요한 데이터 블록을 읽어 SGA의 공유 데이터베이스 버퍼 에 저장(SGA 내에 해당 블록이 존재하지 않는 경우).
- 애플리케이션이 정보를 처리 할 수 있는 방식으로 결과를 리턴
백그라운드 프로세스
성능을 최대화하고 많은 사용자를 수용하기 위해, 다중 프로세스 오라클 데이터베이스 시스템은 백그라운드 프로세스
라고 부르는 추가 오라클 데이터베이스 프로세스를 사용한다. 오라클 데이터베이스 인스턴스는 여러 개의 백그라운드
프로세스를 갖는다.
RAC 환경이 아니고, ASM 환경이 아닌 경우, 확인 할 수 있는 백그라운드 프로세스는 다음과 같다.
① DBWn(Database writer process)
② LGWR(Log writer process)
③ CKPT(Checkpoint process)
④ SMON(System monitor process)
⑤ PMON(Process monitor process)
⑥ RECO(Recoverer process)
⑦ CJQ0(Job queue coordinator)
⑧ Jnnn(Job slave processes)
⑨ ARCn(Archiver processes)
⑩ QMNn(Queue monitor processes)
RAC과 같은 더욱 개선된 구조에서 그 외의 백그라운드 프로세스를 발견 할 수도 있다. 백그라운드 프로세스에 대한
더욱 자세한 정보를 살펴보려면 V$BGPROCESS 뷰를 확인한다.
인스턴스가 시작되면 일부 백그라운드 프로세스들은 자동으로 생성되지만, 일부 프로세스들은 필요에 따라 기동된다.
다른 프로세스 구조는 단일 데이터베이스에 한정되지 않고, 동일한 서버 내의 여러 데이터베이스들에 의해 공유 될 수
있다. 그리드 인프라 및 네트워킹 프로세스가 이러한 범주에 포함된다.
리눅스 및 유닉스 시스템에서 오라클 그리드 인프라 프로세스들에는 다음과 같은 것들이 있다.
① ohasd : 오라클 클러스터웨어 프로세스의 기동을 책임지고 있는 Oracle High Availability Service 데몬
② ocssd : Cluser Synchronization Service 데몬
③ diskmon : HP Oracle Exadata Storage Server에 대한 입출력을 책임지는 Disk Monitor 데 몬
④ cssdagent : 오라클 고유 요구사항 및 복잡한 리소스를 지원하는 확장된 클러스터웨어
⑤ orarootagent : 네트워크와 같이 root에 의해 소유되는 리소스를 관리하는데 도움을 주는 특별한 오라클 에이전트 프로세스
DBWn
DBWn(Database Writer) 프로세스는 버퍼의 내용을 데이터 파일에 기록한다. DBWn 프로세스는 데이터베이스 버퍼
캐시 내의 변경된(dirty) 버퍼를 디스크에 기록하는 책임을 갖는다. 대부분의 시스템은 하나의 DBW0 프로세스로
충분하지만 사용자의 시스템에 많은 데이터를 변경한다면 쓰기 성능을 향상시키기 위해 추가 프로세스
(DBW1~DBW9와 DBWa~DBWz)를 구성 할 수도 있다. 이러한 추가 DBWn프로세스는 단일 프로세서 시스템에서는
유용하지 않다.
데이터베이스 버퍼 캐시 내의 버퍼가 변경되면, 해당 버퍼는 변경되었다는 표시가 기록되고 SCN 순서대로 유지되는
체크포인트 큐의 선두에 추가된다. 그러므로, 이 순서는 변경된 버퍼가 리두 로그에 기록되는 순서와 일기하게 된다.
버퍼 캐시 내의 사용 가능한 버퍼의 개수가 내부 임계치(서버 프로세스가 사용 가능한 버퍼를 검색하는데 어려워하는
지점) 아래로 떨어지면, DBWn은 LRU 말단의 자주 사용하지 않는 버퍼를 데이터 파일에 기록하므로, 프로세스들은
자신이 필요 할 때 버퍼를 교체 할 수 있다. 또한, DBWn은 체크포인트 큐의 말단의 버퍼를 기록하여 체크포인트가
계속 진행되도록 한다. SGA는 리두 스트림 내의 위치인 RBA(Redo byte address)를 갖는 메모리 구조를 포함하며,
이 위치는 인스턴스 장애가 발생하는 경우, 복구가 시작되는 위치를 나타낸다. 이 구조는 리두를 나타내는 포인터로서
동작하고 매 3초마다 CKPT 프로세스에 의해 컨트롤 파일에 기록된다. DBWn는 SCN 순서대로 변경된 버퍼를 변경
하고, 리두는 SCN 순서대로 배치되어 있기 때문에 DBWn가 LRUW 리스트에서 변경된 버퍼를 기록 할 때마다
SGA 메모리 구조 내의 포인터는 인스턴스 복구가 시작되는 지점을 가리키게 되여, 인스턴스 복구가 진행될 때,
정확한 위치에서 리두를 읽게 되므로 불필요한 I/O를 방지한다. 이것을 증분 체크포인트라고 부른다.
주의 : DBWn은 기록을 해야 되는 경우(예를 들어, 테이블스페이스가 읽기 전용으로 변경되거나 오프라인 상태로 되는
경우)가 존재한다. 그러한 경우, 해당 데이터 파일에만 소속된 변경된 버퍼는 SCN 순서와 관련 없이 데이터베이스에
기록되어야 하기 때문에 증분 체크포인트가 발생하지 않는다. LRU 알고리즘은 디스크 읽기 횟수를 최소화하기 위해
버퍼 캐시내의 자주 접근하는 블록들을 유지시킨다. 테이블에 CACHE 옵션을 지정하면 해당 블록을 메모리에 좀 더
오랫동안 유지 시킬 수 있다.
DB_WRITER_PROCESSES 초기화 파라메터에는 DBWn 프로세스의 개수를 지정한다. DBWn 프로세스의 최대 개수는
36이다. 만약, 데이터베이스 기동 시, 이 파라메터가 지정되지 않으면, 오라클 데이터베이스는 CPU의 개수와 프로세서
그룹에 따라 DB_WRITER_PROCESSES의 설정 방법을 결정한다.
DBWn 프로세스는 다음과 같은 조건 하에서 변경된 버퍼를 기록한다.
① 서버 프로세스가 버퍼의 임계치 이상으로 검색한 후에도 재사용 가능한 깨끗한 버퍼를 찾지 못하는 경우,
DBWn에게 기록 요청을 보낸다. DBWn는 다른 작업을 수행하는 동안 비동기적으로 디스크에 변경된 버퍼를 기록한다.
② DBWn은 체크포인트가 진행되도록 버퍼를 기록하며, 체크포인트는 인스턴스 복구가 시작 되는 리두 로그의 위치이다.
이 로그 위치는 버퍼 캐시 내의 가장 오래된 변경된 버퍼에 의해 결정된다.
모든 경우에 있어서 DBWn은 효율성을 향상시키기 위해 여러 개의 블록을 한번에 기록한다. 다중 블록으로 기록되는
블록의 개수는 운영 체제에 의해 변경된다.
LGWR
LGWR은 리두 로그 버퍼 엔트리를 디스크 상의 리두 로그 파일에 기록하여 리두 로그 버퍼 관리를 담당한다. LGWR은
가장 마지막으로 리두 로그 버퍼에 복사된 리두 엔트리 이후, 모든 리두 엔트리를 리두 로그 버퍼에 복사한다. 리두
로그 버퍼는 순환형이다. LGWR은 리두 로그 버퍼에서 리두 로그 파일로 리두 엔트리를 기록하고, 서버 프로세스들은
디스크에 기록된 리두 로그 버퍼의 엔트리에 새로운 엔트리를 복사한다. 리두 로그에 대한 접근이 많은 경우일지라도,
GWR은 충분히 고속이기 때문에 새로운 엔트리를 기록할 버퍼가 언제나 확보되도록 보장해준다. LGWR은 버퍼의 연속
된 한 부분을 디스크에 기록한다.
LGWR가 동작하는 시점은 다음과 같다.
① 유저 프로세스가 트랜잭션을 커밋한 경우
② 리두 로그 버퍼가 1/3이상 채워진 경우
③ DBWn가 필요에 따라 변경된 버퍼를 디스크에 기록하는 경우
④ 매 3초마다
DBWn가 변경된 버퍼를 수정하기 전에 해당 버퍼에 대한 변경사항과 관련된 모든 리두 레코드는 먼저 디스크에
기록되어야만 한다. 만약, 일부 리두 레코드가 아직 기록되지 않았다는 사실을 DBWn가 발견하면, LGWR에게 해당
리두 레코드를 디스크에 기록하도록 요청하고, LGWR가 해당 리두 로그 버퍼를 디스크에 기록 할 때까지 DBWn는
해당 데이터 버퍼의 변경 작업을 대기한다. LGWR은 현재의 로그 그룹에 기록한다. 해당 그룹 내 파일들 중 어느 하나
가 망가지거나 사용 할 수 없는 경우, LGWR은 해당 그룹 내의 다른 파일에 계속 기록하며, LGWR 추적 파일과 시스템
의 경보 로그 파일에 오류를 기록한다. 만약, 어느 한 그룹의 모든 파일들이 망가졌거나, 해당 그룹 이 아카이브 되지
않아서 해당 그룹을 사용하지 못하면, LGWR은 작업을 계속 진행 할 수 없다.
사용자가 COMMIT 문장을 실행하면, LGWR은 리두 로그 버퍼에 커밋 레코드를 기록하고, 트랜잭션의 리두 엔트리와
함께 즉시 디스크에 기록된다. 데이터 블록에 대한 해당 변경 사항은 효율성을 고려하여 기록이 지연된다. 이것을
고속 커밋 메커니즘이라고 한다. 트랜잭션의 커밋 레코드를 포함하는 리두 엔트리의 기록은 트랜잭션의 커밋 여부를
결정하는 단일 이벤트이다. 오라클 데이터베이스는 데이터 버퍼가 아직 디스크에 기록되어 있지 않더라도 트랜잭션이
커밋되면 성공 코드를 리턴한다.
만약, 추가로 버퍼 공간이 필요한 경우, LGWR은 가끔씩 트랜잭션이 완료되기 전에 리두 로그 엔트리를 기록한다.
이러한 엔트리는 해당 트랜잭션이 나중에 커밋되었을 때만 영구적이 된다. 사용 자가 트랜잭션을 커밋하면, 해당
트랜잭션에는 SCN(System Change Number)이 할당되며, 오라클 데이터베이스는 리두 로그 내의 트랜잭션 리두
엔트리에 SCN을 기록한다. RAC과 분산 데이터베이스에서 복구 작업이 동기화 될 수 있도록 SCN은 리두 로그에
기록된다. 데이터베이스의 활동성이 높은 시간에 LGWR은 그룹 커밋을 이용하여 리두 로그 파일을 기록 할 수 있다.
예를 들어, 사용자가 트랜잭션을 커밋한다고 가정하자. LGWR은 해당 트랜잭션의 리두 엔트리를 디스크에 반드시
기록하여야 한다. 이러한 상황이 발생했을 때, 다른 사용자들이 COMMIT 문장을 실행한다.
그러나, LGWR은 지난 트랜잭션의 쓰기 작업이 완료될 때까지 해당 트랜잭션을 커밋하기 위해 리두 로그 파일을 기록
할 수 없다. 첫 번째 트랜잭션의 엔트리가 리두 로그 파일에 기록된 후, 대기 트랜잭션(아직 커밋 되지 않은)의 리두
엔트리의 전체 목록이 한번의 작업으로 디스크에 기록 될 수 있어서, 개별적으로 트랜잭션을 처리하는 것보다 더 적은
I/O가 발생하게 된다. 그러므로, 오라클 데이터베이스는 디스크 I/O를 최소화하고 LGWR의 성능을 최대화 한다. 만약,
커밋에 대한 요청이 계속 빠르게 발생하면, 리두 로그 버퍼로부터 발생하는 모든 쓰기(LGWR에 의한) 작업은 여러
개의 커밋 레코드를 포함 할 수 있다.
CKPT(Checkpoint)
체크포인트는 데이터베이스의 리두 스레드 내의 SCN을 정의한 데이터 구조이다. 체크포인트는 컨트롤 파일과 각
데이터 파일 헤더에 기록된다. 이것들은 복구의 아주 중요한 요소이다. 체크포인트가 발생하면, 오라클 데이터베이스는
체크포인트의 구체적인 내용을 기록하기 위해 모든 데이터 파일의 헤더를 반드시 업데이트 하여야 한다. 이 작업은
CKPT 프로세스에 의해 수행된다. CKPT 프로세스는 디스크에 대한 쓰기 작업을 블록킹하지 않으므로, DBWn은 언제나
자신의 작업을 수행 할 수 있다. 파일 헤더에 기록된 SCN은 해당 SCN 이전에 데이터베이스 블록에 발생 한 모든
변경사항이 디스크에 기록되었음을 보장해준다.
SMON(System Monitor)
SMON은 필요한 경우, 인스턴스 기동 시 복구를 수행한다. 또한, SMON은 더 이상 사용되지 않는 임시 세그먼트를
정리하는 역할을 수행하기도 한다. 만약, 파일 읽기 또는 오프라인 오류로 인하여 인스턴스 복구가 진행되는 동안,
종료된 트랜잭션이 누락된 경우, SMON은 해당 테이블스페이스 또는 파일이 다시 온라인 상태로 복귀될 때, 해당
트랜잭션을 복구한다. SMON은 정기적으로 자신이 필요한지를 확인한다. 만약, 다른 프로세스가 SMON을 필요로
할 경우, SMON을 호출한다.
PMON(Process Monitor)
PMON은 유저 프로세스가 실패한 경우, 프로세스 복구를 수행한다. PMON은 데이터베이스 버퍼 캐시를 정리하는
역할과 유저 프로세스가 사용 중이었던 리소스를 해제하는 역할을 수행한다. 예를 들어, PMON이 활성화된 트랜잭션의
테이블 상태를 리셋하고, 잠금을 정리한 다음, 활성화된 프로세스 목록에서 실패한 프로세스의 ID를 제거한다. PMON
은 주기적으로 디스패처와 서버 프로세스의 상태를 확인하고, 실행이 중지된(오라클 데이터베이스가 내부적으로 종료
시키지 않은) 프로세스를 재시작한다. 또한, PMON은 네트워크 리스너에게 인스턴스와 디스패처 프로세스에 대한 정보
를 등록하기도 한다. SMON과 유사하게 PMON은 자신이 필요한지 여부를 주기적으로 확인하여, 다른 프로세스
가 SMON을 필요로하면 호출된다.
RECO(Recoverer)
RECO 프로세스는 분산 데이터베이스 구조에서 분산 트랜잭션을 포함하는 실패를 자동으로 해결 하는데 사용되는
백그라운드 프로세스이다. 인스턴스의 RECO 프로세스는 의심스러운 분산 트랜 잭션이 포함된 다른 데이터베이스에
자동으로 연결한다. RECO 프로세스가 트랜잭션에 포함된 데이터베이스 서버 사이에 연결을 재수립하면, 각
데이터베이스의 지연 트랜잭션 테이블에서 해결 할 의심스러운 트랜잭션에 해당하는 모든 행들을 제거하여, 모든
의심스러운 트랜잭션들을 자동으로 해소한다. 만약, RECO 프로세스가 원격 서버에 대한 연결을 실패한 경우, RECO는
일정 시간 이후, 다시 접속을 시도한다. 그러나, 다른 연결을 시도하기 전에 좀 더 많은 시간을 대기(지수적으로 증가)
하게 된다.
ARCn(Archiver)
ARCn은 로그 스위치가 발생한 후, 리두 로그 파일을 지정된 스토리지 디바이스에 복사한다. ARCn 프로세스는
데이터베이스가 ARCHIVELOG 모드이고 자동 아카이브가 활성화 되어 있을 때만 존재한다. 만약, 아카이브 작업에
많은 부하가 발생 될 것으로 예상된다면(대량 데이터 로드와 같은) 아카이브 프로세스의 최대 개수를 증가시킬 수
있다. 여기에는 다수의 아카이브 로그 위치가 존재 할 수 있다. 각 위치에 대해서는 최소한 하나 이상의 아카이브
프로세스를 두도록 권장한다. 디폴트는 4개의 아카이브 프로세스를 두는 것이다.
프로세스 기동 순서
오라클 그리드 인프라가 설치되는 동안, 래퍼(wrapper) 스크립트를 기동하기 위해 운영체제의 /etc/inittab에 항목들이
위치된다. 래퍼 스크립트는 환경 변수와 오라클 그리드 인프라 데몬 및 프로세스 기동을 책임진다. 오라클 그리드
인프라를 중지하기 위해 명령이 사용되면, 해당 데몬은 중지하지만, 래퍼 스크립트 프로세스는 계속 실행 중인 상태로
유지된다. 유닉스의 /etc/inittab 파일은 다음과 같다. 래퍼 스크립트는 재시작(respawn)으로 기동되므로 해당 래퍼
스크립트 프로세스가 중지되면 다시 기동된다.
일부 오라클 그리드 인프라 데몬은 실시간 우선 순위를 갖는 root 사용자 권한으로 실행되며, 그 이외의 것들은 실행
된 후, 유저 모드 우선 순위를 갖는 그리드 인프라 소유자 권한으로 실행된다. 윈도우 플랫폼에서는 래퍼 초기화
스크립트 대신 운영 체제 서비스가 대신 사용되며, 해당 데몬은 실행 파일이다.
주의 : 래퍼 스크립트를 직접 실행하는 것은 허용되지 않는다.
데이터베이스 스토리지 아키텍처
오라클 데이터베이스를 구성하는 파일들은 다음과 같이 분류된다.
- 컨트롤 파일 : 데이터베이스 자체에 대한 데이터를 포함한다(즉, 물리적 데이터베이스 구조 정보). 이러한 파일은
데이터베이스에 매우 중요하다. 이 파일이 없으면 데이터베이스 내 데이터에 접근하기 위하여 데이터 파일들을
오픈 할 수 없다. 또한, 백업본과 관련된 메타 데이터를 포함 할 수도 있다.
- 데이터 파일 : 데이터베이스의 사용자 또는 애플리케이션 데이터, 메타 데이터, 데이터 딕셔너리를 포함한다.
- 온라인 리두 로그 파일 : 데이터베이스의 인스턴스 복구가 가능하도록 한다. 만약, 해당 데이터베이스 서버가
망가지고 어떠한 데이터 파일도 유실되지 않았다면, 인스턴스는 이...???
다음 추가 파일들은 데이터베이스를 성공적으로 운영하는데 있어서 중요하다.
- 파라메터 파일 : 인스턴스가 기동 될 때, 해당 인스턴스가 어떻게 구성되어야 하는지 정의하는데 사용된다.
- 패스워드 파일 : 사용자가 sysdba, sysoper, sysasm 롤을 이용하여 인스턴스에 원격으로 접속하고, 관리 작업을 수행
할 수 있도록 해준다.
- 백업 파일 : 데이터베이스 복구에 사용된다. 일반적으로 미디어 오류 또는 사용자 오류로 인하여 원본 파일을
망가뜨리거나 삭제한 경우, 백업 파일을 복원한다.
- 아카이브 리두 로그 파일 : 인스턴스에 의해 발생한 데이터 변경 사항(redo)의 현재 진행 중인 이력을 포함한다.
이러한 파일들과 데이터베이스 백업을 사용하여, 유실된 데이터 파일을 복구 할 수 있다. 즉, 아카이브 로그는
복원된 데이터 파일의 복구를 가능하게 해 준다.
- 추적 파일 : 각 서버 및 백그라운드 프로세스는 연관 추적 파일에 기록 할 수 있다. 내부 오류가 프로세스에 의해
감지되면, 해당 프로세스는 오류에 대한 정보를 해당 추적 파일에 덤프한다. 추적 파일에 기록된 일부 정보는 데이터
베이스 관리자에 의해 사용되며, 그 외 정보는 오라클 지원 서비스에 의해 사용된다.
- 경보 로그 파일 : 여기에는 특별한 추적 항목이 존재한다. 데이터베이스의 경보 로그는 메시지와 오류가 발생
순서대로 기록된다. 오라클은 이 경보 로그를 주기적으로 검토하도록 권장한다.
논리적 및 물리적 데이터베이스 구조
데이터베이스는 논리적 및 물리적 구조를 갖는다.
데이터베이스, 테이블스페이스, 데이터 파일 데이터베이스, 테이블스페이스, 데이터 파일 간의 관계는 위 그림과 같다.
각 데이터베이스는 논리적으로 2개 이상의 테이블스페이스로 구성된다. 테이블스페이스 내 모든 segment들의
데이터를 물리적으로 저장하기 위해 각 테이블스페이스에 대하여 하나 이상의 데이터 파일들이 명시적으로 생성된다.
만약, 테이블스페이스가 TEMPORARY 테이블스페이스인 경우, 데이터 파일 대신 임시 파일을 갖는다.
테이블스페이스의 데이터 파일은 모든 지원 가능한 스토리지에 물리적으로 저장될 수 있다.
테이블스페이스
데이터베이스는 테이블스페이스라고 부르는 논리적 저장소로 구성되며, 이 테이블스페이스는 연관된 논리적 구조 또는
데이터 파일들을 그룹화한다. 예를 들어, 테이블스페이스는 관리 작업을 단순화하기 위해 어느 한 애플리케이션의
모든 segment들을 그룹화한다.
데이터 block
오라클 데이터베이스 데이터는 데이터 block에 저장되며, 가장 작은 수준의 저장 단위이다. 하나의 데이터 block은
디스크 상의 특정 바이트 수를 갖는 물리적인 공간과 연관된다. 데이터 block의 크기는 각 테이블스페이스가 생성될
때 지정된다. 데이터베이스는 오라클 데이터 block 단위로 데이터베이스 공간을 사용하고 공간을 할당한다.
extent
논리적 데이터베이스의 다음 수준은 extent이다. extent는 특정 타입의 정보를 저장하는데 사용되는 특정한
개수의 연속된 오라클 데이터 block이다(단일 할당으로 이루어짐). extent 내의 오라클 데이터 block들은 논리적으로
연속되어 있지만 RAID 스트라이핑 및 파일 시스템 구현에 따라 디스크 상에 물리적으로 분산 되어 질 수 있다.
segment
extent 이상의 논리적 데이터베이스 저장소를 segment라고 부른다. segment는 특정 논리적 구조를 위해 할당된
extent의 집합이다. 예를 들면, 다음과 같다.
- 데이터 segment : 각 넌클러스터, 넌-IOT 테이블은 하나의 데이터 segment를 갖지만, 익스터널 테이블, 전역
임시 테이블, 파티션 테이블은 예외적으로 하나 이상의 segment를 갖는다. 테이블의 모든 데이터는 해당 데이터
segment의 extent에 저장된다. 파티션 테이블의 경우, 각 파티션은 데이터 segment를 갖는다. 각 클러스터는
데이터 segment를 갖는다. 클러스터 내 모든 테이블의 데이터는 클러스터의 데이터 segment에 저장된다.
- 인덱스 segment : 각 인덱스는 자신의 모든 데이터를 저장하기 위해 인덱스 segment를 갖는다. 파티션 인덱스의
경우, 각 파티션은 인덱스 segment를 갖는다.
- 언두 segment : 각 데이터베이스 인스턴스에 대하여 하나의 UNDO 테이블스페이스가 생성된다. 이
테이블스페이스는 언두 정보를 임시적으로 저장하기 위해 여러 개의 언두 segment를 포함한다. 언두 segment 내의
정보는 읽기 일관성 데이터베이스 정보를 생성하고 데이터베이스 복구 시, 사용자들의 커밋되지 않는 트랜잭션을
롤백하는데 사용된다.
- 임시 segment : SQL 문장을 실행하기 위해 임시 작업 영역이 필요한 경우, 오라클 데이터베이스에 의해 임시
segment가 생성된다. 해당 문장이 실행되면, 임시 segment의 extent는 인스턴스에 리턴된다. 모든 사용자들에
대하여 디폴트 임시 테이블스페이스를 지정하거나 데이터베이스 전체에서 사용되는 디폴트 임시 테이블스페이스를 지정한다.
주의 : 위에 나열되지 않은 다른 종류의 segment가 존재한다. 뷰, 패키지, 트리거 등과 같이 데이터베이스 객체이지만
segment로 고려하지 않는 스키마 객체가 있다. segment는 할당된 자신의 디스크 공간을 소유한다. 그러나, 다른
객체는 시스템 메타 데이터 segment에 저장된 행들로 존재한다.
오라클 데이터베이스 서버는 동적으로 공간을 할당한다. segment의 기존 extent들이 가득차면, extent가 추가로
할당된다. extent는 필요에 따라 할당되기 때문에 segment의 extent들은 디스크 상에 연속적이거나 연속적이지
않을 수도 있으며, 동일한 테이블스페이스의 서로 다른 데이터 파일에 할당 될 수도 있다.
segment, extent, block
테이블과 인덱스와 같은 데이터베이스 객체들의 일부는 테이블스페이스 내에 세그먼트로 저장된다. 각 세그먼트는
하나 이상의 익스텐트가 포함된다. 익스텐트는 연속된 데이터 블록으로 구성되며, 각 익스텐트는 오직 하나의 데이터
파일에만 존재 할 수 있다. 데이터 블록은 데이터베이스 내에서 가장 작은 I/O 단위이다.
데이터베이스가 운영체제로부터 데이터 블록 집합을 요청하면, OS는 이 요청을 실제 파일 시스템이나 스토리지 장치의
디스크 블록에 맵핑한다. 그러므로, 데이터베이스 내의 어떠한 데이터라도 물리적 주소를 알아야 할 필요가 없다.
또한, 데이터 파일은 여러 개의 디스크에 스트라이핑되거나 미러링 될 수 있다.
데이터 블록의 크기는 데이터베이스 생성 시에 설정 될 수 있다. 디폴트 크기인 8KB는 거의 모든 데이터베이스에
적절하다. 만약, 사용자의 데이터베이스가 대용량 테이블 및 인덱스를 갖는 데이터 웨어하우스 애플리케이션을
지원해야 한다면, 블록의 크기를 증가시키는 것이 유리하다.
만약, 사용자의 데이터베이스가 읽기 및 쓰기가 랜덤으로 발생하는 트랜잭션 애플리케이션을 지원하여야 하는 경우,
블록의 크기를 축소시키는 것이 유리하다. 지정 가능한 최대 블록 크기는 운영체제에 따라 달라진다. 오라클 블록의
최소 크기는 2KB이며, 이 크기는 거의 사용되지 않는다.
테이블스페이스와 데이터 파일
데이터베이스는 테이블스페이스로 구성되어 있으며, 테이블스페이스는 연관된 논리적 구조들을 그룹핑하는데 사용
될 수 있는 논리적 저장단위이다. 각 데이터베이스는 논리적으로 SYSTEM과 SYSAUX의 2개 이상의 테이블스페이스로
구성된다. 테이블스페이스 내의 모든 논리적 구조들의 데이터를 물리적으로 저장하려면, 각 테이블스페이스에 대하여
하나 이상의 데이터 파일을 지정 하여 생성한다.
위 그림은 두 개의 데이터 파일로 구성된 테이블스페이스를 보여준다. 160KB 크기의 세그먼트는 2개의 데이터
파일에 걸쳐 있으며, 2개의 익스텐트로 구성되어 있다. 64KB 크기의 첫 번째 익스텐트는 첫 번째 데이터 파일에
있으며, 96KB 크기의 두 번째 익스텐트는 두 번째 데이터 파일에 존재한다. 두 익스텐트는 연속된 8KB 오라클
블록들로 구성된다.
주의 : 오직 하나의 대용량 파일을 갖는 빅파일(bigfile)테이블스페이스를 생성 할 수도 있다. 이 파일은 로우ID
아키텍처가 허용 가능한 최대 크기의 용량을 가질 수 있다. 최대 용량은 블록 크기에 256을 곱한 것으로 32KB
블록의 경우 파일의 크기는 128TB가 된다. 전통적인 테이블스페이스(디폴트)는 여러 개의 데이터 파일을 가질 수
있지만, 대용량 파일을 가질 수는 없다.
SYSTEM과 SYSAUX 테이블스페이스
각 오라클 데이터베이스는 반드시 SYSTEM과 SYSAUX 테이블스페이스를 포함하여야 한다. 이 테이블스페이스들은
데이터베이스가 생성 될 때, 같이 생성된다. 시스템은 디폴트로 스몰파일(smallfile)테이블스페이스를 생성한다. 또한,
빅파일 테이블스페이스로 생성 할 수도 있으며, 이러한 경우, 오라클 데이터베이스는 대용량 파일을 관리 할 수 있게
된다.
테이블스페이스는 온라인 또는 오프라인 상태가 될 수 있다. 데이터베이스가 오픈되면, SYSTEM 테이블스페이스는
언제나 온라인 상태가 된다. 이 테이블스페이스에는 데이터 딕셔너리 테이블과 같이 데이터베이스의 핵심 기능을
지원하는 테이블이 저장된다.
SYSAUX 테이블스페이스는 SYSTEM 테이블스페이스의 보조 테이블스페이스이다. SYSAUX 테이블스페이스에는 많은
데이터베이스 구성요소들이 저장되며, 모든 데이터베이스 구성요소의 올바른 기능 수행을 위해 항상 온라인 상태가
되어야 한다. SYSTEM과 SYSAUX 테이블스페이스에는 애플리케이션의 데이터를 저장하지 않도록 권장한다. 이러한
경우, 추가 테이블스페이스를 생성하도록 한다.
주의 : SYSAUX 테이블스페이스는 테이블스페이스 복구를 위해 오프라인 상태가 될 수도 있지만, SYSTEM
테이블스페이스를 오프라인 상태로 변경 할 수는 없다. 두 테이블스페이스 모두 읽기 전 용 상태가 될 수는 있다.
자동 저장소 관리
ASM(Automatic Storage Management)는 오라클 데이터베이스 파일들에 대한 파일 시스템과 볼륨 관리자의
수직적 통합을 제공한다. ASM은 SMP(Symmetric multiprocessing) 머신 또는 RAC의 다중 노드에서 사용 할 수 있다.
오라클 ACFS(ASM Cluster File System)는 실행 파일, 리포트, BFILE, 비디오, 오디오, 텍스트, 이미지, 그 외 일반
목적의 애플리케이션 파일 데이터와 같은 오라클 데이터베이스 외부의 애플리케이션 파일들을 지원하기 위해 ASM
기능을 확장시킨 멀티 플랫폼이며 확장 가능한 파일 시스템 및 저장소 관리 기술이다.
ASM은 수동으로 I/O 튜닝을 수행 할 필요가 없으며, 성능을 최적화하기 위해 모든 사용 가능한 자원들에 대하여 I/O
부하를 분산시킨다. ASM은 데이터베이스를 종료하지 않고 데이터베이스의 용량을 증가시킬 수 있도록 하여, DBA가
동적 데이터베이스 환경을 관리할 수 있도록 해준다.
ASM은 내결함성을 제공하기 위해 데이터에 대한 여분의 복사본을 유지 관리하거나 벤더 제공 저 장 메커니즘의
최상단에 구축 될 수도 있다. 데이터 관리는 지정한 신뢰성 및 각 파일 단위로 사용자와 상호 작용하는 대신에
데이터의 성능 특성을 선택하여 수행된다.
ASM 기능은 수동 저장소 관리를 자동화하여 DBA의 부담을 줄여주며, 향상된 효율로 대용량 데이터베이스를 관리
할 수 있도록 하여 관리자의 능력을 향상시켜 준다.
ASM 저장소 구성요소
ASM은 기존의 데이터베이스 기능을 제거하지 않는다. 기존 데이터베이스는 원래 수행되던 작업 을 진행 할 수 있다.
신규 파일들은 ASM 파일로 생성될 수 있으며, 기존 파일들은 과거 방식대로 관리되거나 ASM으로 마이그레이션
될 수 있다.
위 그림은 오라클 데이터베이스 데이터 파일들과 ASM 저장소 구성요소 간의 관계를 설명한 것이다. 까마귀 발
기호는 1대 다 관계를 나타낸다. 오라클 데이터베이스 데이터 파일은 운영체제에 저장된 파일 또는 ASM 파일과 1대
1의 관계를 갖는다.
오라클 ASM 디스크 그룹은 논리적 단위로서 하나 이상의 오라클 ASM 디스크 집합이다. 디스크 그룹 내의 데이터
구조는 메타 데이터 요청에 대하여 저장 공간의 일부를 사용하는 자기 기술 형태이다. 오라클 ASM 디스크들은
오라클 ASM 디스크 그룹을 구성하는 저장소 디바이스이며, 물리적 디스크 또는 파티션, 스토리지 어레이의
LUN(Logical Unit Number), LV(Logical Volume), 네트워크 파일이 될 수 있다. 각 ASM 디스크는 여러 개의 ASM
할당 단위로 구성되며, 이 할당 단위는 ASM이 할당 가능한 가장 작은 연속된 디스크 공간의 크기이다.
ASM 디스크 그룹을 생성 할 때, 디스크 그룹의 호환성 수준에 따라 ASM 할당 단위를 1, 2, 4, 8, 16, 32, 64MB로
설정 할 수 있다. 하나 이상의 ASM 할당 단위는 ASM 익스텐트를 구성한다. 오라클 ASM 익스텐트는 오라클 ASM
파일의 내용을 저장하는데 사용되는 raw 저장소이다. 오라클 ASM 파일은 하나 이상의 파일 익스텐트로 구성된다.
대용량의 ASM 파일을 위해 1*AU 크기, 4*AU 크기, 16*AU 크기의 가변 익스텐트 크기가 사용된다.
오라클 데이터베이스와 상호 작용 : 메모리, 프로세스, 저장소
다음 예는 가장 기본적인 수준에서 오라클 데이터베이스 동작을 설명한 것이다. 유저 프로세스와 관련 서버 프로세스는
분리된 컴퓨터에 존재하고, 네트워크를 경유하여 연결되어 있다고 가정한다.
1. 오라클 데이터베이스가 설치된 노드에서 인스턴스가 기동 되었으며, 이를 호스트 또는 데이터베이스 서버라고 부른다.
2. 사용자가 유저 프로세스를 기동하는 애플리케이션을 시작한다. 애플리케이션은 서버와의 연결을 시도한다(연결은
로컬, 클라이언트/서버, 미들티어에 의한 3티어 연결이 될 수 있다).
3. 서버는 적절한 Oracle Net Services 핸들러를 갖는 리스너를 실행한다. 리스너는 애플리케이션으로부터 연결 요청을
탐지하고 유저 프로세스를 대신하여 전용 서버 프로세스를 생성한다.
4. 사용자는 DML 유형의 SQL 문장을 실행하고 트랜잭션을 커밋한다. 예를 들어, 사용자는 테이블 내의 고객 주소를
변경하고 변경 사항을 커밋한다.
5. 서버 프로세스는 문장을 수신하고, 공유 풀(SGA 구성요소)에서 동일한 SQL 문장이 포함된 공유 SQL 영역을 확인
한다. 만약, 공유 SQL 영역이 발견되면, 서버 프로세스는 요청된 데이터에 대하여 사용자의 접근 권한을 확인하고
해당 문장을 처리하기 위해 기존 공유 SQL 영역을 사용한다. 만약, 공유 SQL 영역이 발견되지 않으면, 해당 문장을
파싱하고 처리하기 위해 새로운 공유 SQL 영역이 할당된다.
6. 서버 프로세스는 실제 데이터 파일(테이블) 또는 데이터베이스 버퍼 캐시 내에 저장된 값으로부터 필요한 데이터 값을 읽는다.
7. 서버 프로세스는 SGA 내의 데이터를 변경한다. 트랜잭션이 커밋되었기 때문에 LGWR 프로세스가 즉시 리두 로그
파일 내에 해당 트랜잭션을 기록한다. DBWn 프로세스는 가장 효율이 우수한 시점에 변경된 블록을 디스크에 기록한다.
8. 만약, 트랜잭션이 성공하면, 서버 프로세스는 네트워크를 경유하여 메시지를 애플리케이션에 전송한다. 그렇지 않은
경우, 오류 메시지가 전송된다.
9. 이 전체 과정에서 다른 백그라운드 프로세스는 간섭이 필요한 조건을 지켜보고 있다가 실행된다. 또한, 데이터
베이스 서버는 다른 사용자의 트랜잭션을 관리하고 동일한 데이터 를 요청하는 트랜잭션 간에 경합을 방지한다.
퀴즈
PMON에 대한 설명으로 올바른 것은?
1. 인스턴스 기동 시 복구를 수행한다.
2. 유저 프로세스 실패 시 프로세스 복구를 수행한다.
3. 모든 의심 트랜잭션을 자동으로 해결한다.
4. 리두 로그 버퍼를 리두 로그 파일에 기록한다.
퀴즈
어떤 종류의 인스턴스가 ASM 파일에 접근하는가?
1. RDBMS 인스턴스
2. ASM 인스턴스
3. RDBMS와 ASM 인스턴스
'oracle11R2 > Workshop I' 카테고리의 다른 글
| 05장. Configuring the Oracle Network Environment (0) | 2011.07.16 |
|---|---|
| Oracle Database 11g：Administration Workshop I (0) | 2011.07.09 |
| 04장. 데이터베이스 인스턴스 관리 (0) | 2011.06.28 |
| 03장. DBCA를 이용한 오라클 데이터베이스 생성 (0) | 2011.06.26 |
| 02장. 오라클 소프트웨어 설치 (0) | 2011.06.24 |
