3 oracle background processes

1. 오라클 서버(oracle server)와 관련된 프로세스(process)

유저 프로세스(User process)

- 사용자가 작성한 sql 문을 서버 프로세스(server process) 로 전달, 결과를 가져오는 프로세스

서버 프로세스(server process) 

- 유저 프로세스(user process)가 전해준 sql문을 실제 수행하는 프로세스

백그라운드 프로세스(background process)

- 오라클 서버(oracle server)가 시작되면 자동으로 시작, 운영과 유지를 담당하는 프로세스

백그라운드 프로세스(background process) 종류   

필수 background process

선택적 background process (특정 기능을 사용할 때만 생성됨)

2 .각 프로세스의 시작과 종료

- 유저 프로세스, 서버 프로세스(User process, Server process) : 사용자가 접속하면 생성, 접속을 종료하면 사라짐

- 필수 백그라운드 프로세스(background process) : 오라클 서버(oracle server)가 시작되면 시작, 서버(server)가 종료되면 종료됨

3. 필수 백그라운드 프로세스(background process)

1) DBWR(database Writer)

- 역할 

데이터베이스 버퍼 캐쉬(database buffer cache)에서 변경 완료 후 

저장되어야 하는 블록(Dirty Block)을 데이터 파일로 저장하는 작업을 수행하는 프로세스(process)

-DBWR이 DB Buffer Cache의 Dirty buffer의 내용을 데이터 파일에 내려쓰는 경우

1	체크포인트(check point) 신호가 발생했을 때
2	더티 버퍼(Dirty buffer)가 임계값을 지났을 때(1/3)
3	타임 아웃(Time out)이 발생했을 때(3초 마다)
4	RAC ping이 발생했을 때
5	테이블스페이스(Tablespace)가 읽기전용(read only) 상태로 변경될 때
6	테이블스페이스(Tablespace)가 오프라인(offline) 될 때
7	테이블스페이스(Tablespace)가 begin backup 상태가 될 때
8	Drop table이나 Truncate table 될 때
9	Direct Path Read/Write가 진행될 때
10	일부 병행 쿼리(Parallel query) 작업이 진행될 때

*7. hot backup, begin backup, online backup 모두 같은 말임

- DBWR 백드라운드 프로세스(background process)는 기본적으로 DBW0 1개가 작동함

   I/O 가 많아 추가로 더 필요할 경우 최대 10개(DBW0~DBW9) 를 동시에 사용해 성능을 높일 수 있음

   단, 단일 프로세스의 시스템에서는 사용 못 함

- DBWR 개수 확인하기

SYS>show parameter processes;

NAME                                 TYPE        VALUE

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

aq_tm_processes                      integer     0

db_writer_processes                  integer     1

gcs_server_processes                integer     0

global_txn_processes                 integer     1

job_queue_processes                 integer     1000

log_archive_max_processes        integer     4

processes                                 integer     150

2) LGWR(Log Writer)

- 작동순서, 역할

데이터 변경 -> 변경내용의 정보들을 redo log buffer에 기록 -> redo log file에 저장

데이터 변경이 되면 서버 프로세스가 변경내역(Change vector)을 redo log buffer에 기록함

Redo log buffer에 있는 내용을 디스크에 있는 redo log file로 저장하는 역할을 함

 

- LGWR이 Redo log buffer에 있는 내용을 디스크의 redo log file로 저장하는 경우

1	commit이 발생했을 때
2	redo log buffer 내용이 1/3이 찼을 때
3	변경량이 1M가 되었을 때
4	3초마다
5	DBWR이 내려쓰기 전에

- redo log file 저장 이유

redo log buffer은 메모리라서 서버가 꺼지면 내용이 날아갈 수 있기 때문에 

안전하게 하드디스크의 redo log file에 저장함 

수행원리

1. 데이터가 변경되는 경우(DDL이나 DML  수행시)

2. 항상 redo log buffer에 변경 내용을 먼저 기록 후(log ahead method 혹은 write-ahead라고 함)

3. database buffer cache에서 내용 변경

4. commit 

    디스크로 데이터를 저장하는 것이 아니라,

    redo log file을 저장하는 것임 

    

- commit 시 database buffer cache 의 내용을 저장하지 않고,

         redo log buffer의 내용을 redo log file에 먼저 저장하는 이유 :

   1. 저장시간을 단축 시킬 수 있음

- 데이터베이스 버퍼캐쉬의 블록 (database buffer cache의 block) 기본 8k (10g)

  변경 내용이 작다 하더라도 해당 블록은 전부 저장한다면 시간이 많이 걸림

   redo log buffer block의 크기(기본 512 byte)는 os별로 다르긴 하지만,   

   데이터베이스 버퍼캐쉬의 블록 (database buffer cache의 block)보다 훨씬 작기때문에 빨리 저장할 수 있음 

   (11g부터는 관리자가 redo log file 생성시 블록크기 선택 생성가능(512 byte, 1kb, 4kb)

-  데이터베이스 버퍼캐쉬의 블록 (database buffer cache의 block) 을 저장할 때는

    데이터 파일의 원래 블록을 찾아서 덮어써야 하기 때문에 시간이 오래 걸림

    redo log file에 변경된 내용만 순서대로 쓰면 되기때문에 시간이 단축됨 

    2. 많은 사용자가 동시에 commit을 했을 때 LGWR의 group commit를 사용하면 I/O를 줄일 수 있음