Database/ORACLE

[스크랩] 오라클 백그라운드 프로세스 실행 현황 및 이론 내용

99iberty 2014. 3. 18. 20:22

http://wiki.gurubee.net/pages/diffpages.action?pageId=26740657&originalId=26740748

 

백그라운드 프로세스

  • 데이터베이스를 지속적으로 수행하는 데 필요한 일상적인 유지 업무 담당
  • V$ 뷰를 보면 모든 오라클 백그라운드 프로세스를 알 수 있고, 시스템에서 현재 어느 프로세스가 사용중 인지를 볼 수 있다. 
sys@BWD> column name format a4
sys@BWD> select paddr, name, description
  2    from v$bgprocess
  3   order by name -- paddr desc
  4  /
PADDR            NAME DESCRIPTION
---------------- ---- ----------------------------------------------------------------
00               ARB0 ASM Rebalance 0
00               ARB1 ASM Rebalance 1
00               ARB2 ASM Rebalance 2
00               ARB3 ASM Rebalance 3
00               ARB4 ASM Rebalance 4
00               ARB5 ASM Rebalance 5
.
.
.
00               NSV9 Data Guard Broker NetSlave Process 9
070000001F6749C8 PMON process cleanup                              --00과 다른 PADDR을 가진 로우는 시스템에서 실행 중인 프로세스(쓰레드)다.
070000001F6751A8 PSP0 process spawner 0
070000001F67E748 QMNC AQ Coordinator
00               RBAL ASM Rebalance master
070000001F6788C8 RECO distributed recovery
00               RSM0 Data Guard Broker Resource Guard Process 0
00               RSM1 Data Guard Broker Resource Guard Process 1
00               RVWR Recovery Writer
070000001F6780E8 SMON System Monitor Process
158 rows selected.

1. 특화된 백그라운드 프로세스

  • 특화된 프로세스의 개수, 이름, 타입은 릴리즈에 따라 다를 수 있다.

    p240.그림5-4
  • 11gR2에서 데이터베이스는 최소한의 init.ora파라미터를 가지고 시작한다. 
    *.compatible='11.2.0.0.0'
*.control_file='/home/......'
*.db_block_size=8192
*.db_name='orcl'
*.memory_target=314572800
*.undo_tablespace='UNDOTBS1'
  • 12개의 백그라운드 프로세스가 기동된다(10.2.0.4) 
    sys@BWD> select paddr, name, description
  2  from v$bgprocess
  3  where paddr <> '00'
  4  order by paddr desc
  5  /
PADDR            NAME  DESCRIPTION
---------------- ----- ----------------------------------------------------------------
070000001F67CFA8 QMNC  AQ Coordinator
070000001F67C7C8 ARC0  Archival Process 0
070000001F679888 MMNL  Manageability Monitor Process 2
070000001F6790A8 MMON  Manageability Monitor Process
070000001F6788C8 RECO  distributed recovery
070000001F6780E8 SMON  System Monitor Process
070000001F677908 CKPT  checkpoint
070000001F677128 LGWR  Redo etc.
070000001F676948 DBW0  db writer process 1
070000001F675988 MMAN  Memory Manager
070000001F6751A8 PSP0  process spawner 0
070000001F6749C8 PMON  process cleanup
12 rows selected.   -- 11gR2에서는 17개  p.241

PMON

: 각 각의 오라클 프로세스들을 모니터링

  • dedicated server process가 fail로 죽으면, commited되지 않은 작업을 rollback, lock 해제, 자원 반환
  • shared server or dispatcher가 기능 정지하면, 실패한 프로세스 정리 후 동일 프로세스 재시작
  • 자신을 리스너에 등록(인스턴스의 서비스이름, 부하 메트릭같은 관련 파리미터를 리스너에 전달)

SMON

: 시스템 모니터링

  • 템포러리 공간 정리
  • DMT(dictionary-managed 테이블스페이스)의 빈익스텐트와 인접한 익스텐트를 가져와서 한 개의 큰 빈 익스텐트로 합침
  • 사용할 수 없는 상태의 데이터 파일에 발생한 COMMITTED된 트랜잭션 정보를 복구
  • 인스턴스 복구(싱글, RAC )
  • OBJ$ 테이블의 더 이상 존재하지 않는 객체 정보 삭제
  • UNDO 세그먼트 줄임
  • UNDO 세그먼트 오프라인 변경
  • DBA_TAB_MONITORING 뷰에 나타나는 모니터 통계를 삭제 등등

RECO

: 분산 데이터베이스 복구

  • 2단계 commit을 하는 N-1개의 분산환경에서 네트웍 등의 에러로 트랜잭션이 비정상종료되면 복구

CKPT

: 체크포인트 프로세스

  • 체크포인트 정보를 control file, datafile header 에 기록
  • data file header의 체크포인트 정보는 원래 lgwr의 일이였음
  • ckpt는 옵션 프로세스였으나, 8.0버젼부터 필수 백그라운드 프로세스가 됨.

DBWn

: 데이터베이스 블록 Writer

  • 실제 checkpoint를 행함(동기화)
  • dirty buffer를 data file에 내려 써 줌으로써 버퍼캐시 공간을 확보함
  • checkpoint position을 전진(checkpoint position: 인스턴스 복구 시작점)
  • 10g에서는 최대 20개 , 11g에서는 최대 36개(DBW0~DBW9, DBWa~DBWz)

LGWR

: 로그 Writer

  • 매 3초마다 / commit / redo log buffer가 1/3 채워졌거나 1Mb redo entry가 발생시 작업실행

ARCn

: 아카이브 프로세스

  • log switch 발생시( alter system switch logfile; )
  • 10gR2, 11gR2 모두 최대 30개 생성 가능

DIAG/DIAn

: 진단 프로세스

  • 원래 10g에서는 RAC환경에서만 사용,
  • 11gR1 부터 ADR 프로세스와 함께 싱글DB에서도 인스턴스 전체 상태 모니터링
  • DIAG: 인스턴스 장애 처리에 필요한 정보 갭쳐
  • DIA1~9: 행이 걸리거나 deadlock을 감지하고 문제 해결

FBDA

: 플래시백 데이터 아카이브 프로세스

  • 일명 "토탈리콜" 기능을 실현하는 프로세스
  • 토탈리콜: 11g에 새롭게 추가된 기능
  • 작업 실행시에만 나타타 남 <default 5min>>

_http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_flashback.htm#BJFFDCEH_

DBRM

: 데이터베이스 리소스관리자 프로세스

  • 자원 계획이 실행되어 있을 경우에 활성화 됨

GEN0

: 일반적인 태스크 실행 프로세스

  • ASM 프로세스가 GEN0 프로세스에게 특정 파일 블로킹 요청
  • 슬레이브 프로세스와 본질적으로 유사

2. 나머지 특화된 프로세스

  • ASM에서만
    ASMB 자동 스토리지 관리 백그라운드 프로세스 ASM 인스턴스에 연결하여 시간에 따라 변경되는 통계를 제공
    ASM 인스턴스에 자신의 존재를 "heartbeat" 신호
    RBAL 재균형 프로세스 ASM 디스크 그룹에 DISK를 추가 하거나 제거할 때 Rebalance 작업 처리
  • RAC에서만
    LMON 락 모니터 프로세스 클러스터 내의 인스턴스의 장애 감지
    클러스터 내의 인스턴스 추가,제거할 때 락과 여타 자원 재구성
    LMSn 락 관리자 서버 프로세스 서로 관련된 SGA 블록 버퍼 캐시의 일관성을 유지(최대35개)
    LMD0 락 관리자 데몬 프로세스 LMSn 프로세스가 다루는 큐에 리소스에 대한 요청을 보내는 중재자 역할
    글로벌 데드락 감지, 해결 / 글로벌 환경에서 락 타임아웃을 감시
    LCK0 락 프로세스 LMD0와 유사한 기능 처리
    블록 버퍼를 제외한 모든 글로벌 자원에 대한 요청 처리
    LHMB 락 관리자 하트비트 프로세스 LMON,LMD0, LMSn 모니터링, heartbeat
  • 대부분 환경에서 볼 수 있는 공통 백그라운드 프로세스
    PSP0 프로세스 생성기 새로운 프로세스 or 쓰레드를 생성, 대부분 인스턴스 구동시 수행
    VKTM 가상 시간 유지기 프로세스 지속시간과 시간 간격을 측정하는 데 사용되는 정밀도가
    높은 타이머 와 사람이 읽을 수 있는 wall clock time 을 제공
    SMCO 공간 관리 조정자 프로세스 Wnnn 슬래이브 프로세스를 통해 작업 처리

3.유틸리티 백그라운드 프로세스

  • 필요에 따라 사용자가 선택할 수 있는 프로세스
    CJQ0와 Jnnn 프로세스 Job Queue DBMS_JOB 패키지를 통한 job queue 사용
    j000~J999 프로세스 생성 가능( job_queue_processes )
    Jnnn 프로세스는 차례대로 한 번에 한 번씩 작업처리 후 사라짐
    QMNC와 Qnnn Advanced Queue aq_tm_processes 파라미터로 qnnn 프로세스 개수 설정(10gR2: 최대 10개, 11gR2: 최대 41개)
    jnnn프로세스와 달리 작업에 상관없이 계속 상주
    EMNC 이벤트 모니터 프로세스 이벤트 관리와 공지 활동으로 조정
    Streams Event Notifications, Continuous Query Notifications, and Fast Application Notifications 등
    MMAN 메모리 관리자 자동으로 SGA의 일부 영역의 SIZE를 조절
    shared/java/streams/large pool, default buffer cache
    MMON, Mnnn과 MMNL 관리 모니터 MMON : AWR에 SGA의 통계 수집 관리 및 ADDM 분석 실행 작업 조정자
    Mnnn : 실제 AWR에 SGA의 통계 수집 관리 및 ADDM 분석 실행
    MMNL : 활성 세션 이력 정보 수집 및 변화율 계산
    CTWR 변경 추적 프로세스 RMAN의 증분 백업의 성능을 개선하기 위해 변경 추적 파일 유지
    target DB는 OMF, FRA 설정되어 있어야함
    ALTER DATABASE [ENABLE / DISABLE] BLOCK CHANGE TRACKING
    RVWR 복구 Writer Flashback Database 기능을 활성화하면 flashback buffer 원본 정보를
    FRA에 있는 Flashback logs 파일에 기록
    archive mode, FRA 설정되어 있어야 함
    ALTER DATABASE FLASHBACK on; (mount 단계에서)
    DMnn/DWnn 데이터 펌프 마스터/작업자 프로세스 기존 export/import 프로세스를 완벽하게 대체
    DMnn : 클라이언트 프로세스로부터 데이터를 수집하고 DWnn을 조정
    DWnn : 실제 메타데이터와 데이터를처리

_http://download.oracle.com/docs/cd/E11882_01/server.112/e24448/bgprocesses.htm#REFRN104_

문서정보

 

 

 

 

 

 

 

 

 

 

 

 

 

 

http://develop.sunshiny.co.kr/757

 

대략 17개의 백그라운드 프로세스가 기동된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
SUNSHINY@ora11g > select paddr, name, description
2 from v$bgprocess
3 where paddr <> '00'
4 order by paddr desc
5 /
PADDR NAME DESCRIPTION
---------------- ----- --------------------------------
00000000D04E60E0 CJQ0 Job Queue Coordinator
00000000D04E1FE0 SMCO Space Manager Process
00000000D04DFF60 QMNC AQ Coordinator
00000000D04D5CE0 MMNL Manageability Monitor Process 2
00000000D04D4CA0 MMON Manageability Monitor Process
00000000D04D3C60 RECO distributed recovery
00000000D04D2C20 SMON System Monitor Process
00000000D04D1BE0 CKPT checkpoint
00000000D04D0BA0 LGWR Redo etc.
00000000D04CFB60 DBW0 db writer process 0
00000000D04CEB20 MMAN Memory Manager
00000000D04CDAE0 DIA0 diagnosibility process 0
00000000D04CCAA0 PSP0 process spawner 0
00000000D04CBA60 DBRM DataBase Resource Manager
00000000D04CAA20 DIAG diagnosibility process
00000000D04C99E0 GEN0 generic0
00000000D04C89A0 VKTM Virtual Keeper of TiMe process
00000000D04C7960 PMON process cleanup
18 rows selected.


오라클 데이터베이스 10g 릴리즈 2에서는 memory_target 파라미터만 sga_target과 pga_aggreate_target 파라미터로 바뀐 위와 동일한 init.ora를 사용하면, 12개의 백그라운드 프로세스만 보게 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
SUNSHINY@ora10g > select paddr, name, description
2 from v$bgprocess
3 where paddr <> '00'
4 order by paddr desc
5 /
PADDR NAME DESCRIPTION
-------- ---------- ----------------------------------
6FA8C3B8 QMNC AQ Coordinator
6FA8ACD8 MMNL Manageability Monitor Process 2
6FA8A720 MMON Manageability Monitor Process
6FA8A168 CJQ0 Job Queue Coordinator
6FA89BB0 RECO distributed recovery
6FA895F8 SMON System Monitor Process
6FA89040 CKPT checkpoint
6FA88A88 LGWR Redo etc.
6FA884D0 DBW0 db writer process 0
6FA87F18 MMAN Memory Manager
6FA87960 PSP0 process spawner 0
6FA873A8 PMON process cleanup
12 rows selected.


인스턴스를 시작할 때 위 프로세스 모두를 볼 수 있는 것은 아니지만, 대다수 프로세스는 존재할 것이다.
데이터베이스가 ARCHIVELOG 모드고 자동 아카이빙으로 설정했다면, ARCn(archiver) 프로세스를 볼 수 있다.
또한 오라클 RAC(한 클러스터 내에 존재하는 서로 다른 장비에서 수행 중인 여러 개 인스턴스가 같은 물리적 데이터베이스를 마운트하고 오픈할 수 있는 오라클 구성)를 구동하고 있다면, LMD0, LCKn, LMON 그리고 LMSn 프로세스를 볼 수 있다.

다라서 그림 5-4는 오라클 인스턴스를 시작하고 데이터베이스를 마운트하고 오픈했다면 불 수 있는 프로세스들을 보여주고 있다.
리눅스 시스템처럼 오라클이 멀티프로세스 아키텍처로 구현한 운영체제에서는 물리적으로 아래와 같은 프로세스를 볼 수 있다.
인스턴스를 시작한 후에 다음과 같은 리스트를 볼 수 있다.
[oracle@sunshiny-net ~]$ ps -aef | grep ora_...._$ORACLE_SID | grep -v grep
oracle 4210 1 0 08:11 ? 00:00:04 ora_pmon_ora11g
oracle 4212 1 0 08:11 ? 00:00:21 ora_vktm_ora11g
oracle 4216 1 0 08:11 ? 00:00:00 ora_gen0_ora11g
oracle 4218 1 0 08:11 ? 00:00:00 ora_diag_ora11g
oracle 4220 1 0 08:11 ? 00:00:00 ora_dbrm_ora11g
oracle 4222 1 0 08:11 ? 00:00:00 ora_psp0_ora11g
oracle 4224 1 0 08:11 ? 00:00:14 ora_dia0_ora11g
oracle 4226 1 0 08:11 ? 00:00:00 ora_mman_ora11g
oracle 4228 1 0 08:11 ? 00:00:00 ora_dbw0_ora11g
oracle 4230 1 0 08:11 ? 00:00:00 ora_lgwr_ora11g
oracle 4232 1 0 08:11 ? 00:00:02 ora_ckpt_ora11g
oracle 4234 1 0 08:11 ? 00:00:01 ora_smon_ora11g
oracle 4236 1 0 08:11 ? 00:00:00 ora_reco_ora11g
oracle 4238 1 0 08:11 ? 00:00:05 ora_mmon_ora11g
oracle 4240 1 0 08:11 ? 00:00:09 ora_mmnl_ora11g
oracle 4242 1 0 08:11 ? 00:00:00 ora_d000_ora11g
oracle 4244 1 0 08:11 ? 00:00:00 ora_d001_ora11g
oracle 4246 1 0 08:11 ? 00:00:00 ora_d002_ora11g
oracle 4248 1 0 08:11 ? 00:00:01 ora_s000_ora11g
oracle 4250 1 0 08:11 ? 00:00:00 ora_s001_ora11g
oracle 4252 1 0 08:11 ? 00:00:00 ora_s002_ora11g
oracle 4254 1 0 08:11 ? 00:00:00 ora_s003_ora11g
oracle 4256 1 0 08:11 ? 00:00:07 ora_s004_ora11g
oracle 4346 1 0 08:11 ? 00:00:00 ora_qmnc_ora11g
oracle 4404 1 0 15:07 ? 00:00:00 ora_w000_ora11g
oracle 4408 1 0 08:11 ? 00:00:04 ora_cjq0_ora11g
oracle 4451 1 0 08:11 ? 00:00:00 ora_q000_ora11g
oracle 4454 1 0 08:11 ? 00:00:00 ora_q001_ora11g
oracle 5357 1 0 08:17 ? 00:00:00 ora_smco_ora11g

PMON : 프로세스 모니터
PMON(process monitor)은 비정상적으로 커넥션을 종료한 후에 정리하는 일을 담당한다.
예를 들면 dedicated server가 '실패' 하거나 다른 특정한 이유로 죽으면, PMON은 잘못된 작업을 바로잡고(작업을 복구하거나 원상태로 되돌리는 것) 자원을 해제한다.
PMON은 커밋되지 않은 작업에 대해서 롤백을 개시하고 락을 해제하고, 실패한 프로세스에 할당된 SGA 자원을 풀어준다.

PMON은 커넥션이 갑자기 중단된 후에 정리하는 일과는 별도로 다른 오라클 백그라운드 프로세스를 모니터하고, 필요하다면(그리고 가능하다면) 해당 프로세스를 재시작하는 일을 맡고 있다.
만약 shared server 또는 dispatcher가 실패한다면(갑자기 기능을 멈춘다면), PMON이 개입하여 동일한 프로세스를 재시작시킨다(실패한 프로세스에 대한 정리 작업 후에).
PMON은 모든 오라클 프로세스를 지켜보다가 적절한 시점에 재시작시키거나 또는 인스턴스를 종료시킨다.
예를 들면 LGWR(데이터베이스 log writer 프로세스)이 실패한 경우에는 인스턴스를 중지하는 것이 적절한 조치다.
이것은 매우 심각한 오류이기 때문에 가장 안전한 조치 방법은 인스턴스를 종료시키고 정상적인 복구 절차를 밟아서 데이터를 고치도록 해야 한다(주의할 것은 이것은 드문 경우이므로 오라클 지원센터로 즉시 알려주어야 한다는 사실이다).

인스턴스를 위해 PMON이 수행하는 또 다른 일은 자신을 오라클 TNS 리스너에 등록하는 일이다.
인스턴스를 구동하면 PMON 프로세스는 알려진(well-known) 포트 번호로 폴링(polling)한다.
오라클이 사용하는 기본 포트 번호 1521이다. 리스너가 알려진 포트 번호와 다른 포트 번호로 시작한다면 무슨 일이 일어날까?
LOCAL_LISTENER 파라미터를 통해 리스너 주소를 명시적으로 설정해줄 필요가 있다는 사실만 제외하면 메커니즘은 동일하다.
데이터베이스 인스턴스가 구동할 때 리스너가 실행중이라면 PMON은 리스너와 연동하여 인스턴스의 서비스 이름, 부하 메트릭(metrics) 같은 관련 파라미터를 리스너에 전달한다.
리스너가 실행 상태가 아니라면 PMON은 주기적으로 리스너와 접속을 시도하여 자기 자신을 등록하려고 한다.

SMON : 시스템 모니터
SMON(system monitor)은 시스템 레벨의 모든 작업을 수행하는 프로세스다.
PMON은 개별 프로세스에 관심이 있는 반면, SMON은 시스템 레벨 관점으로 일을 바라보며 데이터베이스를 위한 가비지 컬렉터(garbage collector) 역할을 수행한다.
그런 작업 중에 다음과 같은 작업을 포함하고 있다.

* 템포러리 공간 정리 : 만약에 CREATE_INDEX 세션이 갑자기 중단 되면, SMON은 TEMPORARY로 표시된 익스텐트를 정리하는 일을 맡는다.
다른 작업이 생성한 임시 익스텐트 또한 SMON이 맡아서 처리한다.

* 빈 공간 합침 : 만약에 딕셔너리가 관리하는 테이블스페이스를 사용하고 있다면, SMON은 테이블 스페이스에서 빈 익스텐트와 서로 인접한 익스텐트를 가져와서 한 개의 큰 빈 익스텐트로 합치는 일을 맡는다.
이것은 pctincrease 가 0이 아닌 디폴트 스토리지 절을 가진 dictionary-managed 테이블 스페이스에서만 일어난다.

* 가용하지 않는 파일을 대상으로 활동 중인 트랜잭션 복구 : 이것은 데이터베이스 구동 시 SMON의 역할과 비슷하다.
SMON은 인스턴스를 복구하는 시점에 복구할 데이터 파일을 사용할 수 없어서 건너뛴, 실패한 트랜잭션을 복구한다.
예를 들면 데이터 파일이 마운트되지 않은 디스크 상에 존재했을 수도 있다. 데이터 파일이 가용하게 되면 SMON은 파일을 복구한다.

* RAC에서 실패한 노드의 인스턴스 복구를 수행 : 오라클 RAC 구성에서 클러스터 내에 존재하는 한 데이터베이스 인스턴스가 실패하면(예:인스턴스가 실행 중인 장비가 실패한 경우), 클러스터 내에 존재하는 다른 노드가 실패한 인스턴스의 리두 로그 파일을 열어서 모든 데이터에 대한 복구작업을 수행한다.

* OBJ$ 정리하기 : OBJ$ 테이블은 데이터베이스에서 거의 모든 객체(테이블, 인덱스, 트리거, 뷰 등)에 대한 엔트리(entry)를 포함하고 있는 low-level 데이터 딕셔너리 테이블이다.
OBJ$ 테이블은 삭제된 객체 엔트리뿐만 아니라 오라클의 의존성(dependency) 메커니즘에서 사용했지만, 현재는 더 이상 존재하지 않는 객체를 표현하는 엔트리를 갖고 있다.
SMON은 OBJ$ 테이블에서 더 이상 필요하지 않은 이런 로우를 제거하는 프로세스다.

* 언두 세그먼트 줄이기 : SMON은 자동으로 언두 세그먼트의 크기를 최적으로 줄이는 작업을 수행한다(설정되었다면).

* 언두 세그먼트 오프라인하기 : DBA는 활동 중인 트랜잭션이 아직 사용 중인 언두 세그먼트를 오프라인 상태로 바꿀 수 있다.
활동 중인 트랜잭션이 오프라인 상태인 언두 세그먼트를 사용하는 것은 가능하지만, 이렇게 되면 언두 세그먼트는 불완전한 오프라인('pending offline'으로 표시된다) 상태로 바뀐다.
SMON은 백그라운드에서 언두 세그먼트를 완전한 오프라인 상태로 바꾸기 위해 성공할 때까지 주기적으로 시도한다.

위에서 나열한 일 말고도 SMON은 DBA_TAB_MONITORING 뷰에서 나타나는 모니터링 통계를 삭제하는 일, SMON_SCN_TIME 테이블에서 저장된 SCN 대 타임스탬프 매핑 정보를 제거하는 일 등 수행하는 일이 많다.
그러므로 SMON 프로세스는 CPU 시간을 적지 않게 사용하며 아주 정상적인 활동으로 생각할 수 있다.
SMON은 주기적으로 깨어나서(또는 다른 백그라운드 프로세스가 SMON을 깨울 수 있다) 허드랫일 같은 가벼운 일들을 수행한다.

RECO : 분산 데이터베이스 복구
RECO(distributed database recovery)는 매우 특화된 작업을 수행한다.
2PC(two-phase commit, 2단계 커밋)를 하는 동안 장비가 멈춰 서거나 커넥션 손실 때문에 준비 상태로 남아 있는 트랜잭션을 복구한다.
2PC는 많은 이기종 데이터베이스에 영향을 미치는 변경을 원자적으로(atomically) 커밋하는 분산 프로토콜이다.
......
만약 어떤 사이트가 YES라고 응답한 다음 커밋할 준비를 하고 있는데 코디네이터로부터 커밋 지시를 받기도 전에 네트워크가 실패하거나 또는 여타 오류가 발생하면, 이 트랜잭션은 in-doubt 분산 트랜잭션이 된다.
2PC는 in-doubt 트랜잭션이 발생할 수 있는 시간 윈도우를 제한하기 위해 노력하지만, 해당 트랜잭션을 제거할 수는 없다.
바로 그때 실패하면 in-doubt 트랜잭션은 RECO의 책임이 된다.
RECO는 해당 트랜잭션의 결과를 알기 위해 코디네이터와 접촉을 시도한다.
RECO가 코디네이터와 접촉을 하기 전까지 해당 트랜잭션은 커밋되지 않은 상태로 남아 있다.
드디어 RECO가 트랜잭션 코디네이터와 다시 접촉하면 해당 트랜잭션을 커밋하거나 롤백한다.

CKPT : 체크포인트 프로세스
CKPT(checkpoint)는 이름이 의미하는 것처럼 체크포인트를 하지는 않는다.
체크포인트 작업은 대부분 DBWn의 작업이다.
CKPT는 데이터 파일의 파일 헤더를 수정하여 체크포인트를 직접 수행하는 프로세스를 도와줄 뿐이다.

DBWn : 데이터베이스 블록 Writer
DBWn(database block writer)은 dirty 블록을 디스크에 기록하는 일을 담당하는 백그라운드 프로세스다.
DBWn은 보통 버퍼 캐시에 빈 공간을 만들기 위해서 캐시에 있는 dirty 블록을 디스크로 내려 쓰거나(다른 데이터 읽기를 위한 빈 버퍼를 만들기 위해서) 체크포인트를 전진시킨다(인스턴스가 실패하면 오라클이 인스턴스를 복구하기 위해 온라인 리두 로그 파일에서 읽기 시작하는 지점을 앞으로 이동시킨다).
오라클이 다음 로그 파일로 넘어갈 때 체크포인트 시그널을 받는다.
오라클은 방금 다 채운 온라인 로그 파일을 더 이상 필요로 하지 않으므로 체크포인트를 전진시킬 필요가 없다.
만약 리두 로그 파일을 재사용해야 하는데 체크포인트를 앞으로 이동시킬 수 없다면, 'checkpoint not complete' 메시지를 받게 된다.

DBWn의 성능은 매우 중요하다.
만약 블록을 디스크에 기록하는 속도가 다른 블록을 캐시하기 위해 버퍼를 비우는 속도를 따라가지 못하면, Free Buffer Waits 대기 횟수와 Write Complete Waits 대기 시간이 증가한다.

DBWn은 한 개 이상 구성할 수 있다(실제로 36개(DBW0~DBW9, DBWa~DBWz)까지 구성할 수 있다).
대부분의 시스템은 보통 DBWn 프로세스를 하나만 실행하지만, 멀티 CPU 시스템에서는 두 개 이상 실행할 수 있다.
이것은 일반적으로 SGA에 있는 대용량 블록 캐시를 깨끗하게 유지하고, dirty(변경된) 블록을 디스크로 플러시하는 워크로드를 분산하는 데 사용된다.

정의에 의하면 DBWn은 디스크 곳곳에 흩어져 있는 블록을 갱신한다(DBWn은 산발적 쓰기(scattered writes) 작업을 훨씬 더 많이 수행한다).
데이터를 수정할 때 여기저기에 저장되어 있는 인덱스 블록과 랜덤하게 디스크에 분산되어 있는 데이터 블록을 변경한다.
반면에 LGWR은 리두 로그에 순차적인 쓰기 작업을 더 많이 수행한다.
이것은 DBWn과 LGWR의 중요한 차이점이며, 오라클이 DBWn 프로세스뿐만 아니라 리두 로그와 LGWR 프로세스를 별도로 갖고 있는 이유 중 하나다.
산발적 쓰기는 순차적 쓰기보다 현저하게 느리다.
그래서 DBWn 프로세스가 SGA 버퍼의 dirty 블록을 디스크에 기록할 수 있도록 LGWR 프로세스가 대규모 순차적인 쓰기를 함으로써 성능 향상을 달성할 수 있다.
사용자가 대기하는 동안 DBWn은 백그라운드에서 느린 작업을 수행하고, LGWR은 좀 더 빠른 작업을 수행한다는 사실은 전체적으로 더 나은 성능을 기대할 수 있다는 것을 의미한다.
그러므로 오라클이 필요 이상으로 I/O(로그 파일과 데이터 파일에 쓰기)를 좀 더 많이 수행한다고 하더라도 괜찮다.
커밋을 하는 동안 오라클이 물리적으로 변경된 블록을 디스크에 쓴다면 이론상으로는 온라인 리두 로그에 쓰는 일은 건너뛸 수 있다.
그러나 이렇게 건너뛰는 일은 실제로는 일어나지 않는다.
LGWR은 모든 트랜잭션에 대하여 리두 정보를 온라인 리두 로그에 쓰고, DBWn이 백그라운드에서 데이터베이스 블록을 디스크에 플러시한다.

LGWR : 로그 Writer
LGWR(log writer) 프로세스는 SGA에 위치한 리두 로그 버퍼의 내용을 디스크에 플러시하는 책임을 맡고 있다.
다음 중 한 조건을 만족할 때 이 작업을 수행한다.

* 매 3초마다

* 트랜잭션이 커밋을 발생할 때마다

* 리두 로그 버퍼가 1/3로 채워졌거나 버퍼에 저장된 데이터를 1MB 담고 있을 때

이런 이유 때문에 매우 큰(수백/수천 메가바이트) 리두 로그 버퍼를 설정해도 실제로는 쓸모가 없다.
오라클은 훨씬 자주 그리고 지속적으로 리두 로그 버퍼를 플러시하기 때문에 리두 로그 버퍼의 전체 공간을 결코 사용할 수 없을 것이다.
DBWn이 수행해야 하는 산발적 I/O와 비교해 보면 로그는 순차적으로 쓰인다.
이와 같은 큰 배치 쓰기 작업은 파일의 각 부분에 많이 산발적 쓰기를 수행하는 것보다 훨씬 효율적이다.
이것이 우선적으로 LGWR과 리두 로그를 갖고 있는 주요 이유 중 하나다.
단지 순차적 I/O를 이용하여 변경된 바이트를 쓰는 작업의 효율성은 이후 초래될 추가 I/O보다 훨씬 크다.
오라클은 커밋할 때 데이터베이스 블록을 디스크에 직접 쓸 수 있지만, 블록 전부를 산발적으로 쓰는 작업을 수반하기 때문에 LGWR이 변경을 순차적으로 쓰는 일보다는 현저하게 느리다.

ARCn : 아카이브 프로세스
ARCn(archive) 프로세스는 LGWR이 온라인 리두 로그 파일을 채웠을 때 그 파일을 다른 위치로 복제하는 일을 담당한다.
이렇게 아카이빙된 리두 로그 파일은 미디어 복구 시에 사용될 수 있다.
온라인 리두 로그는 정전으로 인해 인스턴스가 종료됐을 때 데이터 파일을 수정하기 위해 사용될 수 있고, 아카이빙된 리두 로그는 하드 디스크에 장애가 발생했을 때 데이터 파일을 수정하기 위해 사용될 수 있다.
가령 데이터 파일 /d01/oradata/ora11g/system.dbf를 포함하고 있는 디스크 드라이브를 잃게 되면 지난 주에 받아 놓은 백업 본을 이용해 데이터 파일을 복구하고, 백업이 일어난 시점부터 생성된 아카이브 리두 로그와 온라인 리두 로그 모두 적용하여 장애가 발생한 시점으로 복구한다.
이 방식으로 데이터베이스에 있는 모든 데이터 파일을 복원할 수 있으며, 아무런 데이터의 손실 없이 업무를 진행할 수 있다.

 

 

 

 

저작자표시 비영리 변경금지

'Database > ORACLE' 카테고리의 다른 글

[스크랩] 오라클 block/extent/segment/tablespace 정의  (0) 2014.04.09
[스크랩] Data Pump 관련 내용  (0) 2014.04.08
[스크랩] Oracle Log 확인  (0) 2014.03.14
[스크랩] SQL문 처리과정  (0) 2014.03.03
DML 문장 / SELECT 문장 실행순서 (약간 이상)  (0) 2014.02.05

'Database/ORACLE'의 다른글

  • 현재글[스크랩] 오라클 백그라운드 프로세스 실행 현황 및 이론 내용

관련글

티스토리툴바