[I. 오라클 아키텍처] 기본 아키텍쳐

01. 기본 아키텍쳐

   (01) 기본 아키텍쳐

오라클의 기본 아키텍쳐를 간단히 표현하면 다음과 같다.

• 디스크에 저장된 데이터 집합 (데이터베이스)

• SGA(System Global Area) 공유 캐시 메모리 영역

• 디스크와 SGA를 액세스하는 프로세스

특히 SGA와 프로세스 집합을 합쳐 인스턴스(Instance)라고 부르며,

SGA는 여러 프로세스가 동시에 액세스 할 수 있기 때문에,

SGA의 자료구조를 보호하고 접근요청을 직렬화하는 래치(Latch)와

저장된 자료를 보호하기 위한 락(Lock)이 필요하다.

위의 그림은 오라클 인스턴스를 간략히 표현한 것 인데,

그림에서 볼 수 있듯이 프로세스는 다시 서버 프로세스와 백그라운드 프로세스로 나눌 수 있다.

서버 프로세스는 클라이언트를 위한 다음과 같은 일련의 서비스를 제공한다.

• 클라이언트가 던진 SQL을 파싱하고 필요하면 최적화를 수행하며,

• 커서를 열어 SQL를 수행하며 데이터 블록을 읽고,

• 읽은 데이터를 정렬하여 클라이언트가 요청한 결과집합을 만들어,

• 이를 네트워크로 전송하는 작업.

만약 도중에 서버 프로세스가 스스로 처리하지 못하는 다음과 같은 작업들을 만난다면,

OS, IO 서브시스템, 백그라운드 프로세스 등에 신호를 보내어 대신 일을 처리하도록 요청한다.

• 데이터베이스 장애 발생시 회복작업

• 데이터파일로부터 DB버퍼로 블럭을 적재하거나, Dirty 블럭을 캐시에서 밀어내어 Free 블럭을 확보하는 일.

• Redo 로그 버퍼를 비우고 백업하는 작업 등...

아래 표는 오라클의 각 백그라운드 프로세스가 어떠한 일을 담당하는지를 개략적으로 표현한다.

ORACLE	SQL Server	설명
SMON(System Monitor)	Database cleanup / Shrinking Thread	장애가 발생한 시스템을 재기동할 때 인스턴스 복구를 수행하고, 임시 세그먼트와 익스텐트를 모니터링한다
PMON(Process Minitor)	Open Data Services(OPS)	이상이 생긴 프로세스가 사용하던 리소스를 복구한다
DBWn(Database Writers)	Lazywriter Thread	버퍼 캐시에 있는 더티 버퍼를 데이터 파일에 기록
LGWR (Log Writer)	Log writer Thread	로그 버퍼 엔트리를 redo 로그 파일에 기록한다
ARCn(Archiver)	N/A	꽉찬 리두로그가 덮어 쓰여지기 전에 archive로그 디렉토리로 백업한다
CKPT(Checkpoint)	Database Checkpoint Thread	checkpoint 프로시스는 이전의 checkpoint 가 일어났던 마지막 시점 이후의 데이터베이스 변경 사항을 데이터파일에 기록하도록 트리거링하고, 기록이 완료되면 현재 어디까지 기록했는지를 컨트롤 파일과 데이터 파일 헤더에 기록한다. 좀더 자세히 설명하면 wirte Ahead Logging 방식을 사용하는 DBMS는 리두로그에 기록해 둔 버퍼 블록에 대한 변경사항 중 현재 어디까지를 데이터 파일에 기록했는지 체크 포인트정보를 관리해야 한다. 이는 버퍼캐시와 데이터 파일이 동기화된 시점을 가리키며, 장애가 발생하면 마지막 체크포인트 이후 로그 데이터만 디스크에 기록함으로써 인스턴스를 복구할수 있도록 하는 용도로 사용된다.이 정보를 갱신하는 주기가 길수록 장애 발생시 인스턴스 복구 시간도길어진다.
RECO(Recoverer)	Distributed Transaction Coordinator(DTC)	분산 트랜잭션 과정에 발생한 문제를 해결한다

   (02) 세션수립 방식

위의 그림은 전용서버 방식(Dedicated Server, 기본값)을 사용하여 

오라클에 접근할 때 클라이언트 세션이 수립되는 과정을 나타낸다.

성능관점에서 주의깊게 보아야 할 부분은 리스너에 연결요청을 한 순간에,

서버 측에서는 하나의 프로세스를 띄우고(fork), 

프로세스만의 독립 메모리 영역인 PGA(Personal,Private,Process Global Area)를 할당한다는 것 인데.

이 작업들은 비용이 매우 큰 작업이므로 매번 SQL 작업이 들어올 때 마다 

DBMS에 연결요청을 한다면 성능이 결코 좋을리 없다.

위의 이슈를 하결하기 위하여 어플리케이션 수준에서 

커넥션 풀링(Connection Pooling) 기법을 사용함으로써 부하를 최소화하는데,

이것은 하나의 작업(SQL 실행)이 끝나더라도 커넥션만을 제어함으로써 

서버 프로세스를 종료하지 않고 반복 재사용하도록 하는 것 이다.

그에 반하여 공유서버 방식(Shared Server)은 디스패처(dispatcher)를 경유하여 접근하는 방식인데,

커넥션 풀링 기법을 DBMS 수준에서 구현한 것과 같다.