데이터베이스 아키텍쳐(Database Architecture)
데이터 베이스 아키텍쳐 = 프로세스 + 공유메모리 영역 + 디스크(물리적 파일)영역
Oracle이나 MSSQL 같은 DBMS의 구조를 살펴보면 위와 같이 구성되어 있다. (위 사진은 오라클 구조)
프로세스(Process)
* oracle이 리눅스(linux)에서는 프로세스 단위로 생성되고 운영된다. SQL server(mssql)는 쓰레드 기반 아키텍처고 oracle이 윈도우에서는 해당 프로세스를 쓰레드로 대체한다. 어차피 같은 역할을 수행하므로 프로세스로 통칭한다.
프로세스는 크게 서버 프로세스(Server process)와 백그라운드 프로세스(Background process)로 나뉜다.
- 서버 프로세스
서버 프로세스는 사용자 프로세스(클라이언트)와 통신하면서 사용자의 각종 명령어를 처리하는 프로세스다.
자세히 설명하면, SQL을 파싱하고 필요하면 최적화를 수행하며, SQL을 실행하면서 블록을 읽고, 읽은 데이터를 정렬해서 클라이언트가 요청한 결과를 만들어 네트워크에 전송하는 일련의 작업을 처리하고, 백그라운드 프로세스가 할일을 백그라운드 프로세스에게 위임시키기 위한 시스템 콜 요청을 하는 프로세스다.
-- 서버프로세스와 클라이언트를 연결하는 방식에는 아래 2가지가 있다.
1) 전용 서버(Dedicated Server) 방식
요청이 올때 마다 서버프로세스를 새로 생성해서 연결하고 요청/응답하고 제거하는 방식 (그림에서 아래 있는 방법)
- 과정
1. Listener가 데이터베이스 연결 요청을 받음
2. Listener가 서버 프로세스 생성 및 연결 요청
3. 서버 프로세스가 resend 패킷을 클라이언트에게 전송
4. 클라이언트에서 오는 요청에 대한 응답
* SQL을 수행할 때마다 연결 요청을 반복하면 서버 프로세스의 생성과 해제도 반복하게 되므로 DBMS에 큰 부담이 된다. 따라서 전용 서버 방식을 사용하는 OLTP성 애플리케이션에서는 Connection Pooling 기법을 사용해야 한다.
2) 공유 서버(Shared Server) 방식
하나의 서버 프로세스를 여러 사용자 세션이 공유하는 방식, 미리 여러 개의 프로세스를 띄워놓고 이를 공유해서 재사용한다. (그림에서 위에 있는 방법)
1. Listener가 데이터베이스 연결 요청을 받음
2. Listener가 가용한 Dispatcher 포트번호를 클라이언트에게 전송
3. Dispatcher로 온 요청을 요청큐(Request queue)에 넣음
4. 공유서버가 요청큐에서 요청을 가져와서 해결한 후 응답을 응답큐(Response queue)에 넣음
5. Dispatcher가 응답큐로 부터 결과를 가져옴
6. 결과를 클라이언트에 리턴
- 백그라운드 프로세스
서버 프로세스가 하는일 외에 데이터 파일을 읽어서 DB 버퍼 캐시에 적재하는 일, Dirty 블록(파일에 기록된 데이터와 메모리에 기록된 데이터가 다른 데이터가 존재하는 블록)을 캐시에서 제거해 free 블록을 확보하는 일, Redo 로그 버퍼를 비우는 일등 내부적으로 DB시스템이 잘 돌아가게 해주는 역할하는 하는 프로세스다.
* 백그라운드 프로세스 요약
Oracle |
SQL Server |
설명 |
System Monitor(SMON) |
Database clean up/ shrinking thread |
장애가 발생한 시스템을 재기동할 때 복구 수행, 임시 세그먼트와 익스텐트 모니터링하는 프로세스 (* 세그먼트, 익스텐트는 아래 설명) |
Process Monitor(PMON) |
Open Data Services(OPS) |
이상이 생긴 프로세스가 사용하던 리소스 복구하기 위한 프로세스 |
Database Writer(DBWR) |
Lazywriter thread |
버퍼 캐시에 있는 Dirty 버퍼(블록)를 데이터 파일에 기록하는 프로세스 |
Log Writer(LGWR) |
Log writer thread |
로그 버퍼 엔트리를 Redo 로그 파일에 기록하는 프로세스 |
Archiver(ARCn) |
. |
꽉찬 Redo 로그가 덮어 쓰여지기 전 Archive 로그 디렉토리에 반영 |
Checkpoint(CKPT) |
Database Checkpoint thread |
Write ahead logging 방식(데이터 변경전 로그부터 쓰는 메커니즘)을 사용하는 DBMS는 Redo 로그에 기록해 둔 버퍼 블록에 대한 변경 사항 중 현재 어디까지 데이터 파일에 기록했는지(데이터 동기화)를 checkpoint로 관리하는데, 이 마지막 checkpoint 이후 로그 데이터만 디스크에 기록함으로써 인스턴스를 복구할 수 있게하는 용도로 사용되는 프로세스 |
Recverer(RECO) |
Distributed Transaction Coordinator(DTC) |
분산 트랜잭션 과정에 발생한 문제를 해결하는 프로세스 |
SMON, PMON, DBWR(DBWs), LGWR, CKPT 는 5개 필수 백그라운드 프로세스다.
디스크(물리적) 영역 - 파일 구조
디스크 영역은 크게 데이터파일 + 임시 데이터파일 + 로그 파일로 구성된다.
- 데이터 파일
위 그림은 데이터베이스 파일 구조를 논리적 영역과 물리적 영역으로 나눠서 요약한 것이다.
물리적으로 디스크에는 데이터베이스가 여러 데이터 파일(Data File)들로 구성되어있다.
각각 데이터파일은 여러 개의 Block(단위)으로 구성되어있다.
tablespace (땅) - segment (건물) - extent (건물의 어느 한 층) - block (건물 어느 한 층의 사무실)
1. 블록(block)
블록에는 다양한 데이터들이 있고 블록 헤더에는 블록을 관리하기 위한 데이터가 들어있다.
하나의 블록은 2KB, 4KB, 8KB, 16KB, 32KB, 64KB의 다양한 크기를 사용할 수 있다. (SQL server는 8KB만)
하나의 블록안에는 여러 레코드(데이터)들이 들어 있다.
데이터베이스에서는 I/O를 블록단위로 한다.
그렇기 때문에 원하는 레코드가 하나여도 블록 째로 읽어들이기 때문에 성능을 좌우하는것은 읽어올 블록의 개수를 최소로 하는 것이다.
이런 특징을 갖는 블록들을 논리적으로 블록이라는 것으로 똑같이 만들었다.
2. 익스텐트(Extent)
익스텐트는 여러 개의 연속된 블록 집합이다. (블록의 묶음)
I/O의 단위는 블록이지만 테이블 스페이스로부터 공간을 할당하는 단위는 익스텐트다.
3. 세그먼트(Segment)
세그먼트는 여러 개의 익스텐트를 가지고 있는 오브젝트다.
세그먼트는 데이터베이스의 테이블, 인덱스, Undo 처럼 저장공간이 필요로 하는 오브젝트를 말한다.
4. 테이블 스페이스(Tablespace)
테이블 스페이스는 세그먼트를 담는 콘테이너로 여러 데이터 파일로 구성된다.
보통 MySQL같은 DBMS에서 워크벤치를 사용했을 때보면 테이블스페이스 안에다가 테이블을 만드는 것을 알 수 있다.
여러 테이블이 있는 공간을 나타낸다.
위와 같은 구조로 데이터파일들이 생성되고 관리된다.
- 임시 데이터 파일
임시 데이터 파일은 대량의 정렬이나 해시 작업을 수행하다가 메모리 공간이 부족해지면 중간에 결과 집합을 잠시 저장하는 용도로 사용되는 파일이다. (잠시 저장되었다가 삭제됨)
- 로그 파일
-- online Redo 로그
캐시에 저장된 변경사항이 아직 데이터파일로 기록되지 않은 상태에서 장애가 생겨서 데이터파일로 기록하지 못한게 날아간 경우에 이것을 복구하기 위해서 online Redo 로그를 사용한다.
online Redo로그는 최소 2개 이상의 파일로 구성되고 하나의 파일이 꽉차면 다음 파일로 로그를 스위칭하고 계속 로그를 쓰다가 모든 파일이 꽉차면 다시 첫번 째 파일부터 재사용하는 형식으로 사용한다.
-- Archived Redo 로그
Online Redo 로그가 재사용되기전에 다른 위치로 백업해 둔 파일이다.
- 컨트롤 파일
데이터베이스를 시작할 때 항상 참조되는 파일.
데이터베이스에서 사용할 모든 파일들의 절대경로와 파일크기등의 정보를 저장하고 있고 파일들의 이상유무를 확인하기 위해서 참조된다.
- 파라미터 파일
공유메모리 영역을 얼마만큼 할당 받을지, 컨트롤 파일의 경로와 데이터베이스의 환경설정 등 관련 모든 정보를 포함하고 있다.
공유메모리 영역 - 메모리 구조
메모리영역은 크게 시스템 공유 메모리 영역 + 프로세스 전용 메모리 영역으로 나뉜다.
1. 공유 메모리 영역은 운영체제가 제공해준 것으로 여러 프로세스가 동시에 엑세스할 수 있는 메모리 영역이다
SGA(System Global Area)라고 부르며 DB버퍼캐시, 공유 풀, 로그버퍼, Large풀, 자바풀등이 여기에 속해 있다.
2. 프로세스 메모리 영역은 서버프로세스가 가진 자신만의 메모리 영역으로 PGA(Process Global Area)라고 부르며, 데이터를 정렬하고 세션과 커서에 대한 상태 정보를 저장하는 용도로 쓰인다.
공유 메모리 영역의 프로세스들
1) DB 버퍼 캐시
디스크 파일의 데이터 파일로 부터 읽은 데이터 블록을 담는 캐시 영역이다.
모든 읽기는 DB 버퍼 캐시를 통해 이루어지고 읽고자하는 데이터가 DB 버퍼캐시에 없으면 디스크에서 읽는다.
디스크에서 읽을 때도 버퍼 캐시에 적재한 후 버퍼 캐시에서 읽어온다.
데이터 변경이 되어서 Dirty블록이 생기면 주기적으로 DBWR 프로세스가 디스크에 기록을 한다.
* 버퍼 블록의 상태
Free 블록 : 비어있는 상태거나 데이터가 담겼지만 파일과 동기화되어 일치하는 상태로 덮어써도 상관없는 상태인 것을 말한다.
dirty 블록 : 버퍼에 캐시된 이후 변경이 발생했지만 아직 파일에 쓰지 않아(동기화 안됨) 덮어 쓸 수 없는 상태인 것을 말한다.
pinned 블록 : 읽기 또는 쓰기 작업이 진행 중인 상태를 말한다.
2) 공유 풀(Shared Pool)
공유 풀은 딕셔너리 캐시와 라이브러리 캐시로 구성된다. LRU알고리즘사용
-- 딕셔너리 캐시
테이블, 인덱스 같은 오브젝트 + 테이블 스페이스, 데이터 파일, 세그먼트, 익스텐트, 사용자, 제약에 관한 메타 데이터를 저장하는 곳이다. (테이블 메타데이터 정보같은 것들)
-- 라이브러리 캐시
사용자가 수행한 SQL문과 실행계획, 저장 프로시저를 저장해두는 캐시다.
사용자가 SQL 명령어를 통해 결과를 요청하면 이를 최적으로 수행하기 위한 루틴을 생성해야하는데 이것이 실행계획(Execution plan)이라고 한다.
쿼리 구문을 분석해서 Syntax check(문법 맞는지), semantic check(테이블 존재등 의미가 맞는지), 권한 검사(권한 있는지)를 하고 최적화 과정을 거쳐 실행계획을 생성하고 SQL실행 엔진이 이해할 수 있는 형태로 포맷팅하는 전과정을 하드 파싱이라고 한다.
최적화 과정이 가장 성능에 주요한 영향을 미치는데 이런 최적화 과정을 없애기 위해 전에 사용한 SQL문과 실행계획을 저장해두고 바로 사용할 수 있게 하기 위해서 라이브러리 캐시라는 곳에 저장해둔다.
3) 로그 버퍼
DB버퍼 캐시에 가해지는 모든 변경사항을 로그 파일에 기록한다.
로그를 건마다 기록하는 것보다 모아서 기록하는 것이 성능에 유리하기 때문에 두는 버퍼다.
버퍼 캐시 블록을 갱신하기 전에 변경사항을 먼저 로그버퍼에 기록해야 하며, dirty 블록을 디스크에 기록하기 전에 해당 로그 엔트리를 먼저 로그 파일에 기록해야한다. (Write Ahead Logging)
PGA (공유되지 않는 독립 메모리 공간)
- UGA(User Global Area)
PGA에 할당되는 메모리 공간으로 하나의 프로세스가 여러 개의 세션을 위한 독립적인 메모리 공간이 필요해지는데 이때 쓰는 것이 UGA다.
- CGA(Call Global Area)
PGA에 할당되는 메모리 공간으로 하나의 데이터베이스 Call을 넘어 다음 Call까지 계속 참조되어야 하는 정보는 UGA에 담고 Call이 진행되는 동안에만 필요한 데이터를 CGA에 담는다.
CGA는 parse call(분석), execute call(실행), fetch call(가져오기) 마다 매번 할당 받는다.
- Sort Area
데이터 정렬을 위해 사용되는 공간
끝으로 다시 위 그림을 보면서 복습하면 좋을 것 같다.
'DB > SQLP' 카테고리의 다른 글
| 데이터베이스 성능 개선 포인트! 데이터베이스 Call 수 줄이기, 네트워크 부하 줄이기(array processing, 부분 범위 처리) (0) | 2018.06.13 |
|---|---|
| SQL 파싱 처리 과정과 성능 향상 포인트 최적화!(하드파싱/소프트파싱 차이, SQL 쿼리 파싱 최적화 과정, 바인드 변수 사용) (2) | 2018.06.11 |
