오라클 프로세스는 서버 자체 즉 인스턴스와 관련된 프로세스로부터 사용자와 관련된 프로세스에 이르기까지 각기 기능을 수행하는 프로세스가 포함되어 있습니다. 오라클의 프로세스는 크게 세가지로 나누어 볼 수 있는데 그 내용은 아래와 같습니다.
1.서버 프로세스 : 클라이언트 요청에 기반을 두고 실행, 전용 및 공유 서버 프로세스가 있습니다.
2.백그라운드 프로세스 : 데이터베이스와 함께 구동하여 블록을 디스크에 기록하고 온라인 재실행 로그를 관리하고 중지된 프로세스들을 정리하는 등과 같은 다양한 유지 관리 작업을 수행 합니다.
3.사용자 프로세스 : User가 실행시킨 SQL문을 서버 프로세스에 전달 합니다.
사용자 프로세스(User Process)
사용자는 애플리케이션 프로그램(Pro*C등)이나 오라클 툴(EM, SQL*Plus)을 이용해서 오라클 서버에 접속하게 되는데 이때 사용자의 애플리케이션을 수행하기 위해 사용자 프로세스를 생성 합니다.
사용자가 SQL*Plus등을 통해 SQL문을 작성하게 되면 User Process는 User가 작성한 SQL문을 서버 프로세스에게 전달하고 처리된 결과를 서버 프로세스로부터 받는 역할을 수행 합니다.
서버 프로세스
전용 서버와 공유 서버 모두 동일하게 SQL을 처리한다. 사용자가 SELECT * FROM EMP 질의를 데이터베이스에 요청할 때 전용/공유 서버가 이 질의를 파싱하고 공유 풀에 파싱한 결과를 저장 합니다.(만약 동일한 파싱 결과가 공유 풀에 있다면 이를 이용) 또한 전용/공유 서버는 질의 실행 계획을 만들어 수행하고 이 과정에서 필요한 데이터를 버퍼 캐시에서 찾거나 디스크로부터 데이터를 읽어 들입니다.
전용 서버 모드에서는 클라이언트 세션과 서버 프로세스(혹은 스레드) 사이에는 일대일 대응 관계가 성립합니다. 즉 유닉스 기계에서 100개의 세션이 존재하면 이에 대응하여 실행하는 100개의 전용 서버 프로세스들이 존재하게 됩니다.
공유서버 프로세스의 경우 클라이언트와 서버가 동일한 기계에 있더라도 반드시 리스너를 통해 접속을 하게 됩니다. 클라이언트는 리스너를 통해 연결되고 다시 디스패처에게 전달 됩니다. 결국 디스패처는 클라이언트 애플리케이션과 공유 서버 프로세스 사이의 중재자 역할을 하는 것입니다.
백그라운드 프로세스(Background Process)
오라클 인스턴스는 SGA와 Background Process로 구성되어 있습니다.백그라운드 프로세스는 데이터베이스가 계속 동작하는데 필요한 일반적인 유지 관리 업무를 수행 합니다. 예를들면 필요할 때 마다 블록들을 데이터 파일에 기록 하면서 데이터베이스 버퍼 캐세를 유지하는 프로세스가 있으며 온라인 Redo Log가 꽉 차면 이를 아카이브에 기록하는 일을 하는 프로세스도 있으며, 중지된 프로세스를 정리하는 프로세스도 있습니다.
필수적인 5가지 프로세스를 우선 살펴 봅니다.
1.DBWR(Database Writer)
SGA에 존재하는 데이터베이스 버퍼 캐시로부터 데이터베이스 블록을 디스크 상의 데이터 파일에 저장하는 작업을 수행 합니다.오라클 인스턴스는 DBW0~DBW9까지 최대 10개의 DBWR을 가질 수 있으며 이 프로세스들은 여러 개의 데이터 파일에 I/O 작업을 수행 합니다. 대부분의 인스턴스에서는 하나의 DBWR을 사용합니다. DBWR가 동작하여 데이터베이스 버퍼 캐시로부터 데이터 파일에 쓰는 경우는 아래와 같습니다.
오라클이 체크포인트를 수행 할 필요가 있을 때 데이터파일에 기록 합니다.(데이터 블록을 변경하여 리두로그와 일치하도록 하기 위한 것)
오라클은 트랜잭션이 커밋 될때 트랜잭션애 대한 리두를 기록한 다음 실제 블록에 기록 합니다. 정기적으로 오라클은 데이터 파일의 내용을 커밋된 트랜잭션에 대해 기록된 리두 로그와 일치 시키기 위해 체크포인트를 수행 합니다.
오라클은 사용자가 요청한 블록을 캐시로 읽어 들이고자 할 때 데이터베이스 버퍼 캐시에 공간이 부족한 경우 데이터 파일에 기록 합니다. 데이터 파일에 쓰여지는 블록은 가정 이전에 사용 된(LRU알고리즘) 블록 입니다.
Dirty List에 저장된 Dirty Buffer의 수가 한계치에 도달 했을 때
Time Out(3초)이 발생 시
테이블스페이스가 Offline, Readonlym begin backup 상태가 된 경우
테이블스페이스가 Drop, Truncate 되는 경우
데이터베이스 버퍼 캐시의 데이터가 변경된 경우 즉시 데이터 파일에 기록하지 않는 것을 쓰기 지연(Deffered Write)이라고 하며 이는 빈번한 I/O로 인한 성능 저하를 막기 위해서 입니다. 또한 같은 이유로 Commit이 발행될 때 마다 DBWR가 데이터파일에 기록하는 것 역시 아닙니다. Commit이 일어 날 때 마다 바쁘게 일하는 것은 LGWR 입니다.
2.LGWR(Log Writer)
서버 프로세스가 데이터베이스 버퍼 캐시에 저장된 원본 데이터와 변경된 데이터의 복사본을 리두로그 엔트리(리두로그 버퍼)에 저장하면 LGWR 프로세스는 리두로그 버퍼에 존재하는 리두로그 엔트리들을 디스크에 있는 온라인 리두 로그 파일에 기록 합니다. 그리고 이 프로세스는 현재 온라인 리두 로그의 로그 시퀀스 번호를 데이터 파일 헤더와 컨트롤 파일에 기록하고 마지막으로 Dirty Buffer List를 비웁니다. 데이터베이스 환경 설정에 따라 변경된 블록들이 다양한 시점에 DBWR에 의해 디스크에 쓰여져서 체크포인트가 발생하면 LGWR는 DBWR에게 변경 사항을 기록하도록 신호를 보냅니다.
LGWR이 Redo Log Buffer를 Online Redo Log에 기록 하는 경우
? Commit 발생 시
? Redo Log Buffer가 1/2 찬 경우
? Redo Log Buffer에 쓰여진 양이 1M 됐을 때
? Checkpoint 발생시 기록하며 그 이후 DBWR에게 알려 줌
? 지정한 시간을 초과한 경우(Time out) : 3초
3.CKPT(Checkpoint)
CheckPoint,는 두 가지로 구분하여 생각해 보기로 합니다. 먼저 SGA의 변경된 데이터베이스 버퍼 캐시와 리두 로그 버퍼의 내용이 데이터 파일에 저장 되도록 DBWR와 LGWR를 호출 하는 이벤트 기능, 다른 하나는 체크포인트가 발생시 각 데이터 파일의 헤더 부분에 체크포인트 이벤트의 현재 시점을 그리고 컨트롤 파일에는 발생된 체크포인트 이벤트의 정보를 기록하는 체크포인트 프로세스 입니다. 이 기록을 이용해 추후 장애 밯생 시 현재 기록된 시점까지 복구가 가능 하도록 합니다. 이벤트와 프로세스는 동시에 발생해 작업을 수행하므로 Checkpoint Process로 통합하여 부르고 있습니다.
이전에 본 것처럼 DBWR, LGWR은 체크포인트 발생 시 인스턴스의 내용을 디스크에 기록 합니다. 이렇게 저장 된 후 CKPT 프로세스는 각 파일의 헤더 부분에 현재 시점의 정보를 기록 합니다.
즉 CKPT의 주된 임무는 동기화 입니다. CKPT를 통해 데이터베이스를 구성하는 3가지 파일인 Control File, Data File, Redo Log File등의 시간 정보를 같은 시점으로 맞추어 동기화 시켜주게 되는데 만약 데이터베이스 시작 시 동기화 정보가 일치하지 않으면 startup 되지 않고 복구가 필요하게 됩니다.
그럼 체크포인트는 언제 발생하는지에 대해 알아보도록 하겠습니다.
초기화 파라미터에서 설정을 통해 CKPT 발생 횟수와 발생간격에 대해 설정이 가능 합니다.
Log_Checkpoint_Interval = 20000->지정한 수만큼의 Redo Log Block이
기록 되었을 때 Checkpoint가 발생 됩니다.
Log_Checkpoint_Timeout = 2800->지정한 시간이 경과시 Checkpoint가 발생
Oracle Instance가 Shutdown 될 때
DBA가 SQL문을 통해 강제로 발생
SQL>alter system checkpoint;
체크포인트를 자주 발생 시키면 복구 시간은 단축 되지만 checkpoint가 실행되는 시간과 자원 만큼의 System 성능은 저하 됩니다. 즉 Checkpoint의 잦은 사용으로 기록을 남기면 저장은 잘되나 DISK I/O가 늘어 성능은 떨어 질 수 있습니다. 단 상대적으로 많은 데이터 파일을 가지고 있는 경우에는 CKPT 프로세스를 사용 함으로서 성능을 향상 시킬 수 있습니다.
4.PMON(Process Monitor)
PMON은 오라클 서버의 각 프로세스를 모니터하여 정상적으로 작동 하고 있지 않는 프로세스를 Shutdown 시키는 역할을 하며 비정상적으로 shutdown된 프로세스가 가지고 있던 자원을 회수하여 다른 프로세스가 사용 할 수 있도록 합니다. 또한 shutdown된 프로세스에 의해 발생된 Lock을 풀어 줍니다.
5.SMON(System Monitor)
PMON이 Process를 모니터 하는 것처럼 System을 모니터 합니다. 보다 구체적으로 말하면 오라클 인스턴스를 관리하는 겁니다. 갑자기 정전 등으로 컴퓨터의 전원이 나가게 되면 인스턴스가 장애를 입을 수도 있습니다. 이후 전원이 들어와 오라클이 다시 시작될 때 SMON이 자동으로 인스턴스를 복구 하게 되는 것이죠…
-----------------------------------------------------------------
이젠 나머지 백그라운드 프로세스에 대해 간단히 보도록 하겠습니다.
-----------------------------------------------------------------
6.ARCH
ARCH 프로세스는 Redo Log File에 기록된 내용이 덮어 쓰여 지기전에 디스크에 파일로서 기록하는 일을 합니다. 즉 Redo Log File은 최소 2개의 그룹 파일에 순환적으로 기록 되므로 1번 파일이 꽉 차면 2번 파일, 다시 2번 파일이 꽉 차면 덮어 쓰기 때문에 이전 변경 사항을 기록 해 놓은 것을 잃어 버리게 됩니다. 이것을 막기 위해 ARCH 프로세스가 사용 됩니다. ARCH 프로세스는 초기 파라미터 파일에 LOG_ARCHIVE_MAX_PROCESSES라는 파라미터를 설정 하여 여러 개를 지정 가능 하므로 ARC0~ARCn으로 기술 되어 집니다.
예를들어 Redo Log 그룹1이 다 차면 그룹2로 넘어가기 전에 LOG SWITCH라는 이벤트가 발생 하면서 그룹2에 계속 데이터베이스의 변경 사항이 기록 되면서 동시에 ARCH 프로세스가 그룹1의 Redo Log File을 디스크에 아카이브 파일로 저장 하게 됩니다.
ARCH 프로세스는 기본적으로 false로 되어 있으며 활성화 시키기 위해서는 Parameter 파일의 LOG_ARCHIVE_START=true로 합니다.
7.LMS(Lock Manager Server)
LMS는 lock(잠금)과 관련된 프로세스로 RAC(Real Application Cluster) 환경에서 인스턴스 사이에 요구되는 LOCK을 관리하기 위한 프로세스 입니다. RAC 환경에서는 여러 인스턴스들이 하나의 데이터베이스를 사용하므로 이들 사이의 LOCK을 관리해야 합니다.
8.SNPn(Snapshot process)
SNPn은 테이블에 있는 Snapshot의 데이터를 자동으로 갱신하는 역할을 합니다. 스냅샷은 읽기 전용 테이블로서 원격지에 있는 테이블의 복사본 입니다.
9.RECO(Recover Process)
RECO는 분산 데이터베이스 환경에서 일시 정지 되어 있거나 실패한 트랜잭션을 처리 합니다.
10.Pnnn
RAC(Real Application Cluster) 환경에서 사용되는 Process로 병렬 질의, 인덱스, 데이터 로딩등의 기능을 제공 합니다.
11.Dnnn(Dispatcher Process)
Shared Server 환경에서 사용되는 Dispatcher Process로 서버 프로세스와 여러 개의 사용자 프로세스 사이에서 사용자의 요구를 서버에 전달하고 서버의 응답을 사용자에게 전달하는 역할을 합니다.