검색결과 리스트
글
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이다.
'Oracle 참고서적 정리 > 오라클 관리실무' 카테고리의 다른 글
6-1 Redo Log 관리하기(Redo Log 생성원리) (0) | 2015.06.18 |
---|---|
5. Control File 관리하기 (0) | 2015.06.17 |
4.Oracle 시작하기와 종료하기. (0) | 2015.06.15 |
2. SQL 문장 실행 원리 (0) | 2015.06.14 |
1. Oracle Server 전체구조. (0) | 2015.06.10 |
RECENT COMMENT