[DataBase] DB별 Architecture

>> Oracle, SQL Server의 Architecture 정리 (참고 문헌 : 데이터진흥원 - SQL 전문가 가이드)

[Oracle] Architecture	[SQL Server] Architecture

 

 

 

** DBMS를 [Instance] : process/memory와 [Database] : storage(데이터 집합)으로 구분하여 정리한다.

---

[Instance]

1) Process

1-1) Server Process : 전면에서 사용자로부터 명령을 전달받아 처리한다.

 

■ 주요 기능 : SQL 파싱/최적화, 커서 제어(생성, 데이터 취합, 송신) & Background Process Call

 

** Server Process를 요약하면 Client와 통하는 창이자 Background Process를 call하는 명령자이다.

** 다수의 Client가 Server에 동시 접속하면 부하가 생길 수 있기 때문에

    (1) 전용 서버 + Connecting Pooling, (2) 공유 서버 : Listener와 dispatcher + Queue 방식으로 접근 프로세스를 구현한다.

 

1-2) Background Process : Server Process의 Call 혹은 로직에 따라 DBMS 유지에 필요한 작업들을 처리한다.

Oracle	SQL Server	기능
System Monitor (SMON)	Database Cleanup /shirinking thread	장애가 발생한 시스템을 재가동할 때, 인스턴스 복구를 수행하고 임시 세그먼트와 익스텐트를 모니터링한다.
Process Monitor (PMON)	Open Data Service (OPS)	이상이 생긴 프로세스가 사용하던 리소스를 복구한다.
Database Writers (DBWn)	Lazywriter thread	버퍼 캐시에 있는 Dirty 버퍼를 데이터 파일에 기록한다. (Dirty 버퍼 : Free 버퍼에 변형이 일어난 상태를 의미)
Log Writer (LGWR)	Log writer thread	로그 버퍼 엔트리를 Redo 로그 파일에 기록한다.
Archiver(ARCn) [optional]	-	꽉 찬 Redo로그가 덮어 쓰여지기 전에 Achive 로그 디렉터리로 백업한다.
CheckPoint (CKPT) [optional]	Database Checkpoint thread	Writing Ahead 방식 : Redo 로그에 기록한 내용 중, 어디까지 실제 데이터 파일에 기록하였는지 checkpoint를 남기는 것으로, 로그와 실제 데이터의 싱크 시점을 의미. 장애 시, 마지막 checkpoint를 추적하여 복구 지점을 정할 수 있다.
Recoverer (RECO) [optional]	Distributed Transaction Coordinator(DTC)	분산 트랜젝션 중 발생한 문제를 해결한다.
Memory Manager (MMAN)		메모리를 관리한다.

 

 

2) Memory

2-1) system memory : 다수의 프로세스가 동시에 엑세스하는 메모리 영역

 

■ 이름 : Oracle : SGA(System global Area) / SQL Server : Memory Pool

■ 구성 : 공통 = (1) DB Buffer Cache, (2) Shared Pool (Procedure Cache), (3) 로그 버퍼

              / 그 외 = Large Pool, Java Pool, 시스템 구조 및 제어 구조 캐싱 영역 포함 가능

 

** 공유되는 매모리의 정합성을 유지하기 위한 매커니즘 : 래치(Latch), 버퍼 Lock [링크], 라이브러리 Lock/Pin [링크]

                            

----------------------

(1) DB 버퍼 캐시 : 데이터 파일을 읽은 블록을 담는 영역.

      -> 블록을 읽을 일이 있으면 DB 버퍼 캐시에 올라와 있는지를 먼저 확인하고, 없으면 올린 후에 읽는다.

           (direct path read 예외가 아니면 모든 블록은 DB 버퍼 캐시를 통해 읽힌다 : 디스크 I/O와 메모리 I/O의 속도 차 때문)

      -> 데이터의 변경도 버퍼 블록을 통해 이뤄지며, 변경된 Dirty 블록은 주기적으로 DBWR에 의해 데이터 파일에 반영된다.

      -> 버퍼 블록의 상태는 데이터 파일과의 동기화 상태에 따라 Free(완료) / Dirty(대기) / Pinned(진행중)으로 나뉜다.

      -> LRU(least recently used) : 사용 빈도 높을 수록 우선순위를 올려 버퍼 캐시에 저장되도록 하는 알고리즘

 

(2) Shared Pool : SQL 최적 실행 경로를 작성(하드 파싱)의 반복을 줄이기 위해 메타데이터, 실행계획 등을 저장한는 공간.

      -> 딕셔너리 캐시 : 테이블 스페이스, 데이터 파일, 세그먼트, 익스텐트, 사용자, 제약 등의 메타 데이터를 캐시 저장/재활용

      -> 라이브러리 캐시 : SQL문과 실행계획, 임시 프로시저를 캐시 저장/재활용

 

(3) Log buffer : 버퍼 캐시에 가해지는 변경에 대한 모든 로그이다.

      -> 로그 데이터도 버퍼 캐시에 저장되었다가 한 번에 Redo Log file (Transaction Log)에 저장된다.

      -> 버퍼 캐시의 내용이 데이터 파일에 쓰이기 전에 필연적으로 로그 파일 저장이 발생한다.

 

2-2) process memory : 개별 프로세스만의 고유 정보들을 저장하는 용도

 

** Oracle에만 존재 (SQL Server에는 없는 개념 : Memory Pool의 버퍼 캐시와 connection context에서 처리함)

----------------

(1) User Global Area (UGA) : 세션(사용자)마다를 위한 메모리 할당이다. (전용 : PGA에, 공유 : SGA에 할당된다)

(2) Call Global Area (CGA) : 하나의 Call (Parse/Excute/Fetch Call)에 필요한 메모리 = Call이 끝나면 반환된다.

(3) Sort Area : sorting을 위한 메모리 할당 (과정 중에는 CGA에, 최종 반환에는 UGA에 할당된다)

---

[Database]

3) Storage

** 큰 틀에서 물리적 데이터 파일 저장은 동일하나, 논리적 구현에서 조금 차이를 보인다. 단위 별로 설명을 작성한다.

 

3-1) 물리적 데이터 파일

3-2) 논리적 저장 단위

 

Block (Page) : I/O의 기본 단위

■ 크기 : Oracle = 2/4/8/16/32KB 중 선택 사용, SQL Server = 8KB 단일 단위 사용

    -> 레코드가 하나의 블록에 저장되는 RDBMS들의 특성상, 하나의 컬럼만 조회할 때도 레코드가 속한 블록 전체를 읽어야할 수 있다.

    -> 블록의 스캔량은 SQL 성능을 좌우하는 성능지표로 실행 계획 수립의 기준이 된다.

 

Extent : 공간을 할당하는 단위

■ 크기 : 8개의 연속된 블록(페이지)로 구성되며 Oracle은 다양하지만 SQL Server = 8개 (64KB) 단일 단위 사용

    -> 연속된 블록을 할당받는다. 익스텐트들은 여러 데이터 파일에 멀리 저장될 수 있다.

 

Segment (Heap/Index) : 테이블/인덱스/Undo 와 같은 DB 내의 오브젝트들

■ 크기 : 복수의 익스텐트를 할당받는다. (세그먼트와 1:1 관계가 일반적이나, 파티션/인덱스 테이블은 1:M의 관계를 갖는다)

    -> 한 세그먼트는 본인이 속한 테이블 스페이스(파일 그룹) 내 여러 데이터 파일에 분산 저장될 수 있다.

 

TableSpace (File Group) : 세그먼트들을 담는 컨테이너

 

3-3) 임시 데이터 파일 : 대량의 정렬이나 해시 작업 수행 중, 메모리 부족이 발생되면 공간을 할당하기 전 중간 과정을 저장

        -> Oracle은 다양한 임시 저장소를 지정할 수 있고, SQL Server는 tempdb를 이용한다.

 

3-4) 로그 파일 : 버퍼 캐시에 가해지는 모든 변경사항을 기록 (Oracle:Redo로그, SQL Server:Transaction로그)

        -> 데이터 변경에 대한 디스크 I/O는 Random I/O여서 느리지만, 로그는 Append 방식으로 저장되어 빠르다.

        -> 로그 파일이 빠른 속도로 저장된 후, 순차적으로 DBWR, Checkpoint 등의 프로세스로 버퍼 케시와 동기화한다.

 

        ** Oracle : 모든 공간이 차면 처음으로 돌아간다(Round Robin). Redo Log의 백업으로 Archive Redo이다.

        ** SQL Server : 데이터베이스마다 하나씩 생성되며, ldf 확장자로 저장된다. (너무 조각화되지 않도록 크게 만든다)

        

 

 

** 참고 문서 : [링크]