목차
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이 파일에서 읽혀질 필요가 있을 경우
가장 오래된 버퍼들로부터 메모리에서 없어지도록 관리하기 위한 알고리즘
- 최근에 읽은 Datafile Block을 Buffer Cache에 보관하고, 새로운 Block이 파일에서 읽혀질 필요가 있을 경우
- LRUW(LRU Write List) List
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를 할 수 있도록 함
- Library Cache
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에 의해서 리두 로그 파일로 저장
- 리두 로그 파일은 적어도 두개 이상의 그룹을 가지며, 한 그룹내의 각 맴버들은 모두 동일한 테이터를 가짐
문서에 대하여
- 최초작성자 : 강정식
- 최초작성일 : 2009년 10월 17일
- 이 문서는 오라클클럽 코어 오라클 데이터베이스 스터디 모임에서 작성하였습니다.
- 이 문서의 내용은 (주)비투엔컬설팅에서 출간한 '오라클 성능 고도화 원리와 해법I'를 참고하였습니다.
참고자료
문서정보
- 이 문서는 구루비에서 작성하였습니다.
- 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
- 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=3900028&
- 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.
'IT > oracle' 카테고리의 다른 글
SYNONYM(동의어) (0) | 2015.04.06 |
---|---|
감사(Auditing)란? (0) | 2015.04.06 |
DATA RECOVERY ADVISOR (0) | 2015.04.06 |
Automatic Workload Repository (0) | 2015.04.06 |
ASMM : 자동 공유 메모리 관리란? (0) | 2015.04.06 |
ARCHIVELOG 모드로 변경 (0) | 2015.04.06 |
ARCHIVELOG 모드 (0) | 2015.04.06 |
NOARCHIVELOG 모드 (0) | 2015.04.06 |
Backup의 종류 (0) | 2015.04.06 |
Oracle Backup And Recovery (0) | 2015.04.06 |