Oracle 프로세스?|

[정민이]

Oracle 프로세스?

Oracle 프로세스 구조는 다중 작업이 발생하는 방법과 다중 작업이 수행되는 방식을 정의 하므로
매우 중요합니다.
A.단일 프로세스 Oracle Instance :단일 사용자 Oracle은 하나의 프로세스가 모든 Oracle Code를
실행하는 시스템입니다. Oracle의 일부분과 Client응용프로그램을 분리하여 실행하는데 다른
프로세스를
사용하지 않습니다.대신 Oracle의 모든 코드와 단일사용자의 데이터베이스 응용 프로그램은 단일
프로세스에 의해 실행됩니다.

B.다중 프로세스 Oracle Instance : 다중사용자 Oracle은 여러 개의 프로세스가 Oracle의 각기
다른 부분을 실행하고 접속한 각사용자들은 개별 프로세스를 실행합니다.

C.다중 사용자 환경에서의 Oracle 프로세스
1. 데이터베이스 기록자(DBWR)
  -  DataBase Buffer의 내용을 데이터 파일에 기록하는 역할을 하며 DataBase Buffer Cache를
관리하는 Oracle BackGround 프로세스임
  -  DataBase Buffer Cache에 있는 내용이 수정되면 해당 버퍼는 'Dirty'로 표시되는데 이
Dirty Buffer를 Disk에 기록하여 Buffer Cache를 깨끗한 상태로 유지하는 역할을 함
  -  LRU 알고리즘에 의해 최근에 사용된 데이터블록을 메모리에 유지합니다.
  -  Buffer Cache는 Multi Latch를 자지는데 래치는 공유 데이터구조를 보호하는 자동내부
잠금입니다. DB_BLOCK_LRU_LATCHES라는 Parameter는 시스템에 구성되는 래치수
     와 기본적으로 CPU에 설정되는 Latch 수를 제어합니다.
  -  서버프로세스가 Buffer를 Dirty목록으로 이동시킨후 Dirty목록이 임계길이에 도달했음을
발견하면 Server 프로세스는 DBWR에 신호를 보냅니다.
  -  체크포인트가 발생하면 LGWR(로그기록자)는 DBWR에 신호를 보냅니다. 즉 Check Point가
발생하면 LGWR는 디스크에 기록되어야 하는 수정된 Buffer 목록을
     지정합니다. DBWR는 디스크에 지정된 Buffer의 내용을 기록합니다.

2.  로그기록자(LGWR)
- Redo Log Buffer를 디스크에 있는 Redo Log File에 등록합니다.
- 사용자 프로세스가 Transaction을 Commit할때의 Commit Record및 매3초 마다의 Redo Log
buffer, DBWR가 수정된 버퍼를 디스크에 기록할때의 Redo Buffer의 내용등을 기록합니다.

- 사용자가 Commit명령을 발생시키면 LGWR는 Commit Record를 즉시 Redo Log Buffer에 넣지만
해당 데이터 버퍼의 변경은 변경사항을 데이터 파일에 기록하는 것이
   더 효율적일때까지 지연됩니다.

3 체크포인트(CKPT)
- Check Point가 발생하면 Oracle은 모든 DataFile의 Header를 갱신하여 체크포인트임을
나타내야 합니다. 보통 LGWR가 이러한 작업을 수행하지만 체크포인트가 시스템 Performance를
저하 시킨다면 CKPT를 활성화하여 체크포인트 수행작업을 LGWR가 수행하는 다른 작업과 분리할
수 있습니다.
-  체크포인트가 모든 응용프로그램에 꼭 필요한 것은 아니며 DataFile의 수가 많아 Check
Point중에 LGWR프로세스 성능이 저하되면 CKPT프로세스를 활성화 할수있다.
- 초기화 Parameter CHECK_POINT_PROCESS는 CKPT프로세스를 활성화 하거나 비활성화 합니다.

4. 시스템모니터(SMON)
- 인스턴스 시작시에 인스턴스의 복구를 수행, 더 이상 사용하지 않는 임시 Segment를 삭제하며
사용 가능한 빈영역을 더 큰 블록으로 만들기위해 인법한 빈 확장영역을 하나로 통합합니다.

5. 프로세스모니터(PMON)
- 사용자 프로세스에 장애가 발생하면 프로세스 복구를 수행,Cache를 비우고 해당 프로세스가
사용한 자원을 해제하며,활성 Transaction의 Table상태를 재설정하고 Lock을 해제하며 Active
Process목록에서 ID를 제거한다.
- 주기적으로 Dispatch와 서버 프로세스의 상태를 점검하고 활동중이 아니면 재시작합니다.  
  
6. 복구자(RECO)
- 분산 Transaction을 포함한 장애를 자동으로 해결하는 분산 Option과 함께 사용되는 프로세스,
시스템이 분산 트랜잭션을 허용하고 DISTRIBUTED_TRANSACTIONS가 0보다 클때만 존재합니다.

7. 아카이브(ARCH)
- Online Redo Log File이 꽉차면 이를 지정된 저장장소에 저장,Redo Log가 Archive Mode에서
운영되고 자동 Archiving기능이 활성화 되어 있을 때만 존재합니다.

8. 잠금(LcKn)
- 병렬서버 옵션에서 최대 10개 까지의 잠금Process(LCK0~LCK10)가 인스텀스의 Lock을 제공합니다.
그러나 대부분의 병렬서버 시스템에서는 하나의 LCK프로세스(LCK0)만
  으로도 충분합니다.

9. 스냅샷갱신(SNPn)
- 분산 옵션에서 최대 10갸 까지의 스냅샷갱신프로세스(SNP0~SNP10)가 자동으로 Table SnapShot을
화면에 다시 표시합니다.

10. 디스패쳐(Dnnn)
- 디스패쳐 프로세스를 사용하면 사용자 프로세스는 제한된 수의 서버 프로세스를 공유할 수
있습니다. 디스패쳐가 없다면 각 사용자 프로세스는 하나의 전용(Dedicated)서
   버 프로세스를 필요로 합니다. 그러나 Multi Thread Server에서는 동일한 수의 사용자에
대해 더 적은 수의 공유서버 프로세스를 필요로 합니다.
- 단일 DataBase Instance에 대해 다중 Dispatcher 프로세스를 생성할 수 있습니다. Oracle을
사용하는 시스템의 Network Protocol에 대해 적어도 하나의 디스페처가 생성되어야 합니다. DBA는
프로세스당 접속수에 대한 OS의 한계에 따라 가장 적합한수의 디스패처를 시작해야 하며
인스턴스가 실행되는 동안 디스패처 프로세스를 추가또는 삭제할수 있다.

- 인스턴스가 시작되면 Listener는 사용자를 Oracle과 접속시키는 통신경로를 설정하며,
각 디스패처는 리스너에 접속 요구사항을 수신할 수 있는 주소를 부여합니다.
사용자 프로세스가 접속을 요구하면 리스너는 요구사항을 점검하고 사용자가 디스패처를 사용할 수
있을지에 대해 결정합니다. 사용할 수 있을 경우 리스너는 로드할 양이 가장적은 디스패처 주소를
돌려주며 사용자 프로세스는 디스패처에 직접 접속됩니다.