Oracle Background Process.

 

- Oracle Process 종류

1) User Process:   사용자가 작성한 SQL 문장을 Server 프로세스로 전달하고 결과를 가져오는 프로세스.

2) Server Process: User Process가 전해 준 SQL문장을 실제 실행하는 프로세스.

3) Background Process: Oracle Server가 시작되면 자동으로 시작되어 운영과 유지를 담당하는 프로세스.


1. 필수 Background Process.


 1) DBWR(Database Writer) : Database Buffer Cache에서 변경완료 후 저장되어야 하는 블록(Dirty Block)을 데이터파일로 저장하는 역할.

* DBWR이 DB Buffer Cache의 Dirty Buffer 내용을 파일에 내려쓰는 경우.

- Check Point 신호가 발생했을 때.

- Dirty Buffer가 임계값을 지났을 때

- Time out이 발생했을 때

- RAC Ping이 발생했을 때.

- Tablespace가 Read only 상태로 변경될 때.

- Tablespace가 offline될 때.

- Tablespace가 begin backup 상태가 될 때.

- Drop table이나 Truncate table될 때.

- Diret Path Read/Write가 진행될 때.

- 일부 Parallel Query 작업이 진행될 때.

* DBWR 백그라운드 프로세스는 기본적으로 하나 작동하지만, I/O가 많을 경우 여러개를 동시에 사용할 수 있다.

SQL> Show parameter process ; 명령어를 통해 확인가능.


 2)LGWR(Log Writer) : 

-  Server Process가 변경내역을 Redo Log Buffer에 기록하게된다.

-  LGWR은 Redo Log Buffer에 있는 내용을 디스크의 Redo Log File로 저장한다.

-  만약 Commit 요청이 들어왔는데 Redo Log File이 없는 경우, Alert Log 파일에 해당 내용을 기록해 두고 LGWR은 다음 Commit요청을 수행하지 않고 대기.

 

* LGWR이 Redo Log Buffer의 내용을 파일에 내려쓰는 경우

- Commit 발생했을 때.

- 1/3이 찼을 때

- 변경량이 1M이 되었을 때

- 3초마다

- DBWR이 내려쓰기 전에

** 오라클은 데이터가 변경되는 경우 항상 Redo Log Buffer에 변경내용을 먼저 기록한 후DB Buffer Cache내용을 변경한다.(Log Ahead Method, Write-Ahead라고 하기도함.)

** Commit을 수행하면 데이터를 저장하는 것이 아니라, Redo Log를 저장하는 것이다.

** Commit 수행 시 Redo Log Buffer내용을 먼저 쓰는 이유

      -  변경된 내용이 적을 경우라도 해당 블록을 전부 저장해야하므로 많은 시간이 소모되는데, Redo Log Buffer의 Block크기는 DB Buffer Cache의 블록 크기보다 작기 때문.

      -  DB Buffer Cache의 블록을 저장할 때 데이터파일에서 해당 블록의 위치를 찾아서 덮어써야하기 때문에 오래걸림, Redo Log Buffer에 내용을 쓸때는 그냥 순서대로 씀.

      

3)PMON(Process Monitor)

- PMON은 모든 프로세스를 감시하고, 비정상적으로 종료된 프로세스가 있다면, 관련 복구작업을 하는 역할.

- 인스턴스가 시작될 때 해당 인스턴스 정보를 Listener에 등록하고 관리하는 역할을 함.


4)SMON(System Monitor)

- 인스턴스가 비정상 종료 되었을 경우, Instance 인스턴스를 시작할 때 Clean Up하는 역할 (Instance Recovery라고 함.)

- Instance Recovey 과정에서 누락된 Transaction을 Recovery하는 역할.

- 비정상 종료된 Transaction Temporary Segment를 Cleanup하는 역할.

(Create 등 작업을 하던 도중 해당 Transaction이 비정상 종료되면, Temporaray segment를 Cleanup해준다)

- Dictionary Managed Tablespace에서  Free Extents를 모아주는 역할도 함.


ex) 인스턴스 비정상 종료 시 Instance Recovery 과정.

상황: Scott 사용자가 test Table에 작업을 하다 비정상 종료됬을 경우

1.  A 입력

2. B 입력

3. Commit

4. C 입력

5. Database가 비정상종료됨.


=> 

1. Prameter File을 읽어서 Nomount단계에서 Instance 생성.

2. Mount단계에서 Control file의 내용을 확인해서 Instance Crash상황임을 확인.

3. Redo Log File에서 위 1,2,3,4 단계의 작업을 다시 수행 (Roll Forward)

* COMMIT이 되지않은 4번입력까지 수행.

4. Database Open

5. Commit이 되지않은 4번 작업 취소(Roll backward)

6. Instance Recovery 완료.

 * Instance Recovery 할 때  Online Redo Log File만 읽고 진행하며, 만약 복구내용이 Archived Redo Log File에 있다면 DBA가 수동으로 Media Recovery를 수행해야한다.


5)CKPT (Checkpoint Process)

- CKPT Process는 DBWR에게 Checkpoint 신호를 전달해 주며, Control file과 Datafile Header에 해당 Check Point 정보를 기록하는 역할 수행.

- Checkpoint 정보에는 Checkpoint 위치와 SCN, 해당 내용을 담고 있는 Redo log 내용의 위치값을 담고있다.


6)MMON, MMNL (10g이후 추가됨.)

- MMON Process는 AWR과 관련된 다양한 작업을 수행

- MMNL Process는 Active Session History정보를 디스크의 파일로 기록하는 역할 수행.


7) RECO

- 분산 데이터베이스 환경에서 Transaction처리 도중에, 장애가 발생할 경우 해당 Transaction을 자동으로 복구해주는 역할 수행

* 분산 데이터베이스가 아닐 경우 큰 의미는 없다.

 

2. 선택적인 Background Process

1) ARCn(Archiver Processes)

- Archive Log Mode로 데이터베이스를 운영할 경우 Online Redo Log File을 Archiving해 주는 역할 수행.


2)CJQ0 & JNNN

- 오라클에서 제공하는 Job 기능을 수행하는 프로세스.


3)FBDA(FlashBack Data Archiver Process)

- Flashback 기능 중에 Undo Data를 사용하는 기능이 있는데, 이 기능들은 Undo Data를 다른 프로세스가 덮어 써버릴 경우 Flashback을 할 수 없게되는 단점이 있다.

11g부터 FBDA를 사용할 경우 Undo data를 다른 사용자가 덮어쓰기 전에 Archive해서 보관해주는 기능이 도입되었고, Undo Data를 다른곳으로 복사해주는 역할을 수행하는

프로세스가 FBDA이다.