by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

기본 아키텍처




목차

I. 오라클 아키텍처란?

II. 오라클 접속

III. Instance(이하 인스턴스) 영역

IV. Database 영역

I. 오라클 아키텍처란?

오라클 아키텍처는 크게 다음과 같이 나눌 수 있다.

1. Oralce Database(DISK)에 있는 자료를 읽을 때 보다 빠르게 액세스하기 위한 메모리 영역(Instance)
2. 실제 자료를 저장하고 있는 영역(Database)

이 영역에 대해 사용자가 Oracle Application(SQL*PLUS, PL/SQL Developer, ...)을 가지고
DB에 연결하여 실제 데이터를 액세스하는 프로세스를 진행하면서 어떤 일들을 하는지 살펴보고
이를 통해 오라클 아키텍처를 이해해 보고자 한다.

II. 오라클 접속

사용자가 Database에 접근하기 위해 Application Program을 통해 접속을 하면
'USER PROCESS'가 할당이 되고 이 프로세스를 서버에 연결시켜주기 위해 'SERVER PROCESS'가 할당이 된다.
'SERVER PROCESS'에 PGA(Program Global Area)가 할당된다.

1. USER PROCESS

  • 사용자가 Application Program을 실행시켰을 때 사용되는 프로세스
  • 사용자가 오라클 서버에 접속할 때마다 'USER PROCESS'가 생성
  • 사용자가 실행시킨 SQL문을 서버 프로세스에 전달하고, 그 결과를 서버 프로세스로부터 받는 역할을 수행

2. SERVER PROCESS

  • 오라클은 'SERVER PROCESS'를 생성하여 접속된 사용자 프로세스의 요구 사항을 처리
  • 'SERVER PROCESS'는 'USER PROCESS'와의 통신과 요구사항을 수행하는 오라클과의 상호 작용을 담당
  • 'SERVER PROCESS'에는 하나의 PGA 메모리 영역이 할당됨

3. PGA(Program Global Area)

  • 하나의 단일 프로세스(SERVER, BACKGROUND)에 대한 데이터와 제어 정보를 가지고 있는 메모리 공간
  • 'USER PROCESS'가 Oracle Database에 접속하고 Session이 생성될 때 Oracle에 의해 할당
  • 각 'SERVER PROCESS'에 하나만 할당되는 PGA 메모리 영역은 SGA 영역과 달리 다른 프로세스와 공유되지 않는,
    각 프로세스가 독립적으로 사용하는 non-shared 메모리 영역

4. 테스트

1) SQL*PLUS(Application Program)로 Oracle Database에 접속

해당되는 인스턴스에 아이디와 패스워드를 입력하고 접속

conn user/password@instance_name;

SQL*Plus: Release 10.2.0.1.0 - Production on Mon Oct 5 14:23:52 2009
Copyright (c) 1982, 2005, Oracle.  All rights reserved.

INSTANCE >

2) USER PROCESS 확인

현재 자신이 접속한 'USER PROCESS'를 V$SESSION 동적뷰에서 확인

SELECT OSUSER,
       SID,
       STATUS,
       DECODE(INSTR(PROGRAM, '(', 1, 1),
              0,
              PROGRAM,
              SUBSTR(PROGRAM,
                     INSTR(PROGRAM, '(', 1, 1) + 1,
                     INSTR(PROGRAM, ')', 1, 1) -
                     INSTR(PROGRAM, '(', 1, 1) - 1)
              ) PROCESS,
       TYPE,
       EVENT
FROM   V$SESSION
WHERE  STATUS = 'ACTIVE' -- 활성화 되어 있는 세션만
AND    TYPE   = 'USER'   -- USER PROCESS
;

OSUSER    SID STATUS PROCESS      TYPE EVENT
-------- ---- ------ ------------ ---- -------------------------
raxsoft  9886 ACTIVE sqlplusw.exe USER SQL*Net message to client

이 SQL은 세션중에 살아있는(ACTIVE) 세션과 'USER PROCESS' 데이터만 가져오기 위해 조건을 걸음
이렇게 조회를 할 경우 하나의 로우만 출력이 되며 현재 내 접속정보를 확인할 수 있음

OSUSER OS 클라이언트 사용자 이름
SID 세션 식별자
STATUS 세션의 상태
PROGRAM OS 프로그램 이름
TYPE 세션 타입
EVENT Oracle Wait Event

3) SERVER PROCESS 확인

현재 자신이 접속한 'SERVER PROCESS'를 V$PROCESS 동적뷰에서 확인

SELECT VP.ADDR,
       VP.PID,
       VP.SPID,
       VP.USERNAME,
       VP.PROGRAM
FROM   V$SESSION VS,
       V$PROCESS VP
WHERE  VS.PADDR  = VP.ADDR   -- V$SESSION에서 V$PROCESS와 조인하기 위해 프로세스의 메모리 주소를 사용
AND    VS.STATUS = 'ACTIVE'  -- 활성화 되어 있는 세션만
AND    VS.TYPE   = 'USER'    -- USER PROCESS
AND    VS.OSUSER = 'raxsoft' -- 내 세션만 가져오도록
;

ADDR             PID SPID   USERNAME PROGRAM
---------------- --- ------ -------- -----------------------
070000016B32E4B0  20 377176 oraods   instance_name
ADDR 프로세스의 메모리 주소
PID 프로세스 ID
SPID OS 프로세스 ID
USERNAME OS 유저 이름
PROGRAM OS 프로그램 이름(RAC일 경우 Instance Name)

III. Instance(이하 인스턴스) 영역

1. 인스턴스란?

인스턴스는 오라클의 메모리 영역으로 SGA Memory와 BackGround Process로 구성이 되어 있다.

  • 인스턴스는 흔히 사용하는 워드프로세서와 비교하면 이해하기가 쉽다.
  • 워드프로세스를 통해 사용자가 입력하는 내용을 파일에 직업 I/O 한다면 느리므로 메모리 캐시를 통해 빠르게 액세스를 할 수 있다.
  • 이와 마찬가지로 오라클에서도 데이터베이스를 빠르게 액세스하기 위해 SGA라고 하는 메모리 캐시 영역을 두고 있으며 이들을 효율적으로
    관리하기 위해 여러 BackGround Process가 있는데 이들로 이루어진 것을 인스턴스라고 지칭함.
  • 일반적으로 오라클을 설치하면 하나의 데이터베이스에 하나의 인스턴스가 생성되지만
    RAC(Real Application CLUSTER) 환경에서는 하나의 데이터베이스를 액세스하는 다중 인스턴스로 구성
  • 또한 RAC 모델은 데이터파일만 공유하는 과거의 방식에서 캐시를 공유하는 방식으로 지원
    즉 4개의 인스턴스가 하나의 데이터베이스를 사용한다고 할 때 4개의 인스턴스 모두 공유 메모리 캐시를
    사용하므로 1번의 인스턴스 메모리 캐시에 없을 경우 글로벌 캐시에 데이터 블록이 있다면 그것을
    사용할 수 있다.
  • 각 인스턴스를 고속의 전용 네트워크로 연결하기 때문에 가능함.

2. SGA(SYSTEM GLOBAL AREA)

SGA는 인스턴스에서 가장 중요한 메모리 캐시 영역을 담당하고 있으며 총 6개의 메모리 영역이 존재함

1) DB Buffer Cache

  • Data Files로부터 읽은 Data Block의 복사본을 담고 있는 영역
  • 인스턴스에 동시 접속한 모든 'USER PROCESS'는 'DB Buffer Cache'에 대한 액세스를 공유
  • 또한 아직까지 DISK에 Write하지 않은 수정도니 데이터를 보유할 수도 있음
  • LRU 알고리즘에 의하여 가장 오래 전에 사용된것은 DISK로 밀어내고 가장 최근의 블록을 유지하게 하여 I/O 성능을 향상시키고자 함
  • DBWR(Database Writer Process)에 의해서 관리
  • Free Buffer는 'SERVER PROCESS'에 할당되어 사용되고, 사용 후 Dirty Buffer가 된 Buffer들은 DBWR에 의해 디스크에 씌여진 후
    다시 Free Buffer가 되어 'SERVER PROCESS'에 의해 재사용되는 작업을 반복함
  • Buffer Cache는 Dirty List(LRU Write List(LRUW))와 Least Recently Used(LRU) List 두 개의 List로 구성
    • LRUW(LRU Write List) List
      • 수정되어 DIS에 반영되어야 할 블록들의 리스트
      • LRUW에 모인 Dirty Buffer는 DBWR에 의해 디스크로 쓰여지고나면 이 Buffer는 Free Mark 되어
        다시 사용될 수 있도록 LRU List의 끝부분에 위치함
    • LRU(Least Recently Used) List
      • 최근에 읽은 Datafile Block을 Buffer Cache에 보관하고, 새로운 Block이 파일에서 읽혀질 필요가 있을 경우
        가장 오래된 버퍼들로부터 메모리에서 없어지도록 관리하기 위한 알고리즘

2) Shared Pool

  • Shared Pool은 하나의 데이터베이스에 행해지는 모든 SQL 문을 처리하기 위해서 사용되며
    Library Cache, Datadictionary Cache로 구성되어 있음
    • Library Cache
      • 이 메모리 영역은 사용자가 같은 SQL을 재실행할 경우 Hard Parse를 생략하고 Soft Parse를 할 수 있도록 SQL 정보를 저장
      • SQL과 PL/SQL 영역을 저장하고 있음
    • Datadictionary Cache
      • 데이터베이스 테이블과 뷰에 대한 정보, 구조, 사용자등에 대한 정보가 저장하여 Soft Parse를 할 수 있도록 함

3) Redo Log Buffer

  • 리두 로그 버퍼는 데이터베이스에서 일어난 모든 변화를 저장하는 메모리 공간
  • 이 영역에 저장된 값들은 LGWR에 의해 데이터베이스 복구에 사용되는 온라인 리두로그 파일에 저장
  • 리두 정보는 데이터가 COMMIT 되기 전에 먼저 보관이 되어야 어떤 상황에서도 복구가 가능하므로
    변경 내용을 먼저 리두 로그 버퍼에 저장하고 난 후에 DB Buffer Block에 리두 로그 버퍼 내용을 적용

4) Streams Pool

  • 오라클 10g부터 지원하는 메모리 영역이며 다른 DB로 데이터를 전달할 때 사용하는 메모리 영역

5) Large Pool

  • SGA에서 대용량 메모리를 할당할 때 사용

6)Java Pool

  • Oracle JVM에 접속해 있는 모든 세션에서 사용하는 자바코드가 사용하는 메모리 영역

SGA 사이즈는 아래의 스크립트로 확인할 수 있다.

SHOW SGA
;

Total System Global Area 5,972,688,896 bytes
Fixed Size                   2,089,824 bytes
Variable Size            2,499,808,416 bytes
Database Buffers         3,456,106,496 bytes
Redo Buffers                14,684,160 bytes
Total System Global Area SGA를 구성하는 영역 크기의 합계로 SGA_MAX_SIZE 파라미터로부터 영향을 받음
Fixed Size 데이터베이스나 인스턴스의 상태를 저장하는 영역으로, 백그라운드 프로세스가 액세스하는 영역
Variable Size SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE 파라미터로부터 영향을 받음
Database Buffers 데이터파일로부터 읽어 들인 데이터 블록 내용을 저장하는 영역
Redo Buffers 데이터베이스에 가해진 모든 변경 사항에 대한 내역을 저장하는 영역

3. BackGround Process

BackGround Process의 종류를 확인하려면 V$BGPROCESS 동적뷰를 통해 확인할 수 있다.

SELECT NAME,
       PADDR
FROM   V$BGPROCESS;

NAME    PADDR
-----   ---------------------------------------------------
ARB0	ASM Rebalance 0
ARC0	Archival Process 0
ASMB	ASM Background
CJQ0	Job Queue Coordinator
CKPT	checkpoint
CTWR	Change Tracking Writer
DBW0	db writer process 0
DIAG	diagnosibility process
DMON	DG Broker Monitor Process
EMN0	Event Monitor Process 0
FMON	File Mapping Monitor Process
GMON	diskgroup monitor
INSV	Data Guard Broker INstance SlaVe Process
LCK0	Lock Process 0
LGWR	Redo etc.
LMD0	global enqueue service daemon 0
LMON	global enqueue service monitor
LMS0	global cache service process 0
LNS0	Network Server 0
LSP0	Logical Standby
LSP1	Dictionary build process for Logical Standby
LSP2	Set Guard Standby Information for Logical Standby
MMAN	Memory Manager
MMNL	Manageability Monitor Process 2
MMON	Manageability Monitor Process
MRP0	Managed Standby Recovery
NSV0	Data Guard Broker NetSlave Process 0
PMON	process cleanup
PSP0	process spawner 0
QMNC	AQ Coordinator
RBAL	ASM Rebalance master
RECO	distributed recovery
RSM0	Data Guard Broker Resource Guard Process 0
RVWR	Recovery Writer
SMON	System Monitor Process

이 중 내가 접속한 인스턴스에 있는 BackGround Process 또한 확인이 가능하다.

SELECT OSUSER,
       SID,
       STATUS,
       DECODE(INSTR(PROGRAM, '(', 1, 1),
              0,
              PROGRAM,
              SUBSTR(PROGRAM,
                     INSTR(PROGRAM, '(', 1, 1) + 1,
                     INSTR(PROGRAM, ')', 1, 1) -
                     INSTR(PROGRAM, '(', 1, 1) - 1)
              ) PROCESS,
       TYPE,
       EVENT
FROM   V$SESSION
WHERE  STATUS = 'ACTIVE' -- 활성화 되어 있는 세션만
-- AND    TYPE   = 'USER'   -- USER PROCESS
ORDER BY TYPE, PROCESS
;

OSUSER     SID STATUS PROCESS      TYPE       EVENT
-------- ----- ------ ------------ ---------- --------------------------------------------------------
oraods    9981 ACTIVE ARC0         BACKGROUND rdbms ipc message
oraods    9978 ACTIVE ARC1         BACKGROUND rdbms ipc message
oraods    9990 ACTIVE CJQ0         BACKGROUND rdbms ipc message
oraods    9993 ACTIVE CKPT         BACKGROUND rdbms ipc message
oraods    9997 ACTIVE DBW0         BACKGROUND rdbms ipc message
oraods    9996 ACTIVE DBW1         BACKGROUND rdbms ipc message
oraods    9995 ACTIVE DBW2         BACKGROUND rdbms ipc message
oraods    9994 ACTIVE LGWR         BACKGROUND rdbms ipc message
oraods    9998 ACTIVE MMAN         BACKGROUND rdbms ipc message
oraods    9988 ACTIVE MMNL         BACKGROUND rdbms ipc message
oraods    9989 ACTIVE MMON         BACKGROUND rdbms ipc message
oraods   10000 ACTIVE PMON         BACKGROUND pmon timer
oraods    9999 ACTIVE PSP0         BACKGROUND rdbms ipc message
oraods    9977 ACTIVE QMNC         BACKGROUND Streams AQ: qmn coordinator idle wait
oraods    9991 ACTIVE RECO         BACKGROUND rdbms ipc message
oraods    9992 ACTIVE SMON         BACKGROUND smon timer
oraods    9947 ACTIVE q000         BACKGROUND Streams AQ: qmn slave idle wait
oraods    9975 ACTIVE q001         BACKGROUND Streams AQ: waiting for time management or cleanup tasks
oraods    9968 ACTIVE q003         BACKGROUND Streams AQ: qmn slave idle wait
raxsoft   9886 ACTIVE sqlplusw.exe USER       SQL*Net message to client

여기서 사용되는 BackGround Process의 내용을 살펴보면 다음과 같다.

ARB0 ASM Rebalance  
ARC0 Archival Process 아카이브기능을 수행하는 프로세스
CJQ0 Job queue process 9i 부터 소개된 잡큐 프로세스
CKPT Check Point ※ 체크포인트는 마지막 체크포인트 이후에 변경된 모든 블럭을 데이타 파일에
쓰도록 유도하고 체크 포인트를 기록하기 위해 데이타 화일 헤더와 콘트롤 파일을 변경
(현재 Redo log와 Checkpoint번호로 data file과 Control file의 헤더를 동기화)
※ 온라인 리두 로그 화일이 채워지면 이것이 자동적으로 실행
※ init.ora화일에 있는 log_checkpoint_interval파라미터는 체크포인트를 발생 주기로 조정하는데 사용
D000 Dispatcher Process ※ SL*NET V2멀티스레드 서버(MTS)구조의 한부분
※ 다중 연결을 처리함으로써 필요한 자원을 최소화 하는데 도움을 줌
DBW0 Database Writer ※ 데이타 블럭 버퍼 캐쉬와 딕셔너리 캐쉬의 내용을 관리하는 프로세스
※ Data Base Buffer cache 내용을 데이터 파일에 저장하는 작업을 수행
※ DBWR숫자는 데이타베이스의 INIT.ORA 파일에 있는 DB_WRITERS 파라메타를 통해 지정
LGWR Log Writer ※ 리두로그버퍼의 내용을 온라인 리두 로그파일에 기록
※ 일반적인 데이타베이스 작업 수행시 리두로그버퍼를 직접 읽어 온라인 리두 로그 파일에 기록하는 프로세스
LMS0 global cache service process  
MMAN Memory Manager ※ 공유 메모리의 자동 튜닝을 위하여 MMAN이라는 백그라운드 프로세스가 새롭게 등장
※ MMAN이라는 백그라운드 프로세스가 5분 마다 주기적으로 수집한 작업 부하(Workload) 정보를 바탕으로
동적으로 구성되어 메모리는 가장 필요한 곳으로 동적으로 할당.
※ SPFILE을 사용하면 MMAN이 변경한 파라미터들의 정보가 자동으로 SPFILE에 저장되므로 가능한 Oracle 9i 이상부터는 SPFILE 의 사용을 권장
MMNL Manageability Monitor Lightweight ※ 10g부터 소개, AWR 기능용 프로세스
※ MMNL 프로세스는 매초마다 active sessions의 스냅샷을 관리하고 계산하는 작업을 진행
MMON Manageability Monitor ※ MMON 프로세스는 약간의 시간 간격 사이에 발생되는 여러 통계 정보 스냅샷이나 미리 정의된 기준값을 초과할 때 위험을 알리는 등의 여러 가지 작업을 관리
※ MMON 프로세스는 이와 같은 작업을 수행하기 위한 여러개의 하위 프로세스를 생성할 수 있음
PMON Process Monitor ※ 비정상 종료된 데이터베이스 접속을 종료
※ 이전에 실패한 사용자 프로세스의 Resource를 풀어줌
(Lock되어 있는 프로세스가 소멸될 때 그 자원에 걸린 Lock를 해제)
PSP0 Process Spawner Process 10g R2부터 소개된 프로세스
q000 Queue Slave QMN 슬레이브 프로세스, 구 QMNn 프로세스
QMNC AQ Coordinator QMN 코디네이터 프로세스
RECO Recover Process ※ 10g 이후에는 필수 프로세스
※ 오라클7에서 분산 데이타베이스 내에서 발생한 오류를 해결하는데 사용
※ 이 프로세스는 IN-DOUBT 트랜잭션과 관련있는 데이타베이스에 접속을 시도하면 그 트랜잭션을 해결
※ init.ora화일에 distributed_transactions파라미터가 0보다 큰 값으로 지정되어야만 생성
SMON System Monitor ※ 시스템을 감시하는 기능
※ 오라클 인스턴스 Fail시 인스턴스를 복구한다(온라인 리두 로그 파일을 사용)
※ 더이상 필요하지 않는 TEMPORARY SEGMENT를 제거

IV. Database 영역

1. 데이터베이스란?

  • Data files, Control files, Redo log files, Parameters Files을 합해서 오라클 데이터베이스 라고 하며 데이터베이스 이름(DB_NAME)으로 식별

2. Data Files

  • 데이터 파일은 실제 데이터가 저장되는 하드디스크상의 물리적 파일
  • 테이블이나 인덱스 같은 데이타 베이스의 논리적 구조는 데이타베이스를 위해 할당된 데이타 파일에 물리적으로 저장
  • 데이터 파일은 생성시에 그 크기를 명시하고, 더 많은 저장 공간이 필요할 경우 크기 확장 가능

3. Control Files

  • 컨트롤 파일은 데이터베이스의 제어 정보를 가지고 있는 파일로 오라클 서버의 데이터베이스 이름이 컨트롤 파일에 저장
  • 컨트롤 파일은 오라클 DB를 마운트 하고 Open하여 DB를 사용하는데 꼭 필요한 파일
  • 컨트롤 파일이 손상되면 오라클을 mount, open할 수 없으므로 적어도 두개 이상의 컨트롤 파일을 백업 받아서 다른 디스크에 저장해 놓는 것이 좋음

4. Redo Log Files

  • 리두 로그 파일은 데이터베이스에서 생긴 모든 변화를 기록 하는 파일
  • 만약 수정된 내용을 데이타 파일에 반영하는데 실패하더라도, 변경사항은 리두로그 파일에서 얻을 수 있기 때문에, 작업내용은 결코 유실되지 않음
  • 리두 로그 파일은 데이타베이스를 장애로부터 보호하기 위해 필수적
  • 리두 로그 파일은 데이터를 복구 하는데 사용
  • SGA 내의 리두 로그 버퍼 캐쉬에 저장된 데이터들은 리두 로그 버퍼가 일정 수준 이상 채워지게 되면 LGWR에 의해서 리두 로그 파일로 저장
  • 리두 로그 파일은 적어도 두개 이상의 그룹을 가지며, 한 그룹내의 각 맴버들은 모두 동일한 테이터를 가짐

문서에 대하여

참고자료

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. 10월 17, 2009

    강정식 says:

    1. 질문1 v$session에서 sid와 serial을 같이 묶어야 unique한데 그 이유는?

    1. 질문1

    • v$session에서 sid와 serial을 같이 묶어야 unique한데 그 이유는?