[Oracle] Chapter 11. 백그라운드 프로세스의 동작과 역활

11.1 백그라운드 프로세스를 왜 배워야 하는가?

 

현실 사회에서도 전면에 나서는 일과 뒤에서 지원하는 일이 있다. 밖에서 보면 전면에 나서서 일하는 사람만 눈에 띄지만, 실제로는 뒤에서 지원하는 업무 체계가 잘 잡힌 회사나 가게가 대단한 경우가 오히려 많다. 지원 스태프가 일을 제대로 하지 못하면 장애가 발생하기도 하며, 전면에 나서서 일하는 직원들에게 폐를 끼칠 수도 있다.

오라클도 잘 작동하고 있을 때는 상관이 없지만, 일단 장애가 발생하고 나면 백그라운드 프로세스의 동작과 관련된 지식이 필요할 때가 많다. 또한, 지원 스태프들의 일을 제대로 이해하지 않으면 업무 전체를 이해했다고도 할 수 없으므로 눈에 잘 띄는 서버 프로세스뿐만 아니라 백그라운드 프로세스도 잘 배워야 한다.

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

11.2 백그라운드 프로세스와 서버 프로세스의 관계

 

11.2.1 백그라운드 프로세스의 동작

이번 장에서도 오라클을 창고 회사에 비유해서 설명하겠다. 오라클 클라이언트가 물건을 맡기거나 찾아가는 고객에 해당하며, 서버 프로세스가 그 의뢰를 처리하는 사원이라고 생각하자. 그리고 디스크는 창고, 캐시는 짐을 일시적으로 보관해두는 작업장이다.

 

잘 모르는 프로세스는 대부분은 백그라운드 프로세스이다. 지원 스태프가 이렇게 많이 존재하면 '정말 중요할 때 서버 프로세스의 처리가 늦어지는 건 아닌가?' 라는 걱정이 들 수도 있다. 기본적으로 모든 사원(프로세스)은 잠들어 있는 상태이다. 정확히 말하면 업무가 없을 때는 잠을 자며, 업무가 생기면 눈을 뜨고, 업무가 끝나면 다시 잠드는 형태로 동작한다. 서버 프로세스는 일이 생기기 전까지는 'SQL*Net message from client'를 띄우며 대기한다. 그동안은 OS상에서 슬립 상태로 존재하며, 메시지(SQL문 등)가 도착하면 눈을 뜨고 처리를 시작한다. 서버 프로세스는 SQL을 처리하는 도중에 백그라운드 프로세스에 의뢰해야 할 일이 생기면 어떻게 동작할까요? 그럴 때 서버 프로세스는 '처리가 끝나면 꺠워줘'라고 말하고 작업을 의뢰한 후에 잠든다. 의뢰를 받은 백그라운드 프로세스도 마찬가지로 동작하며, 일을 받기 전에는 잠들어 있다가(슬립 상태) 처리가 끝나면 필요한 서버 프로세스를 꺠우고 자신은 다시 잠들게 된다. 기본적으로 슬립 상태에서는 CPU를 소비하지 않으므로 프로세스의 수는 크게 중요하지 않다.(OS가 프로세스를 관리하기 위해 발생하는 부하가 신경 쓰이는 분들도 계시겠지만, 이 정도의 프로세스 수는 문제가 없다. 또한, 프로세스 수가 많으면 메모리는 그만큼 소비하게 된다. 아울러 v$session_wait에서 'DIAG'라는 백그라운드 프로세스가 처리를 계속하는 것처럼 표시될 때가 있지만, 실제로는 일시적인 것으로 금방 처리한 후에는 슬립하기 떄문에 걱정할 필요는 없다.)

 

1. 오라클클라이언트 : SQL문을 데이터베이스에 던진후 응답을 기다리며, 그동안은 슬립 상태가되어 응답이 돌아오기를 기다린다.

2. 서버프로세스 : SQL문이나 요청이 올떄까지는 Idle 대기 이벤트 'SQL*Net message from client'로 기다립니다. 응답이 도착하면 슬립 상태에서 빠져나와 작업을 처리하기 시작한다. SQL 처리를 하는 도중에도 필요에 따라 I/O 등의 대기 이벤트가 되어 기다리기도 하고, 백그라운드 프로세스에게 작업을 의뢰하기도 한다. 예를 들어, 커밋할 때는 LGWR에게 REDO 로그를 기록하도록 의뢰한다. 의뢰한 후에는 'log file sync' 상태로 슬립하여 기다린다.

3. 백그라운드 프로세스 : 일반적으로 LGWR은 'rdbms ipc message'로 슬립하며 기다리고, 기록하는 중에는 'log file parallel write'로 기다린다. 기록하는 처리가 끝나면 서버 프로세스에 통보(잠을 깨운다)한다.

 

이렇게 슬립 상태가 많은 상황은 오라클 이외의 소프트웨어에서도 마찬가지이다. 주위에서 쉽게 볼 수 있는 일반적인 장비에서도 CPU는 한두 개인데, 프로세스는 수십에서 수백까지 활성화되어 있는 상태가 많다. 그 말인즉슨, 대부분 프로세스느 많은 시간을 슬립한 상태로 있다는 것을 의미한다. 비유를 들어 설명하자면, 급여(비용)를 사무실에 있는 시간(슬립도 포함)에 비례해서 지급하는 것이 아니라 일을 하는 시간(슬립은 포함하지 않음)에 비례해서 지급한다는 이야기이다. 사원이 많은 창고 회사이긴 하지만 일한 시간에 따라서 급여가 지급되는 회사라고 생각하면 된다.

 

11.2.2 슬립과 대기의 관계

'슬립한 상태' = '(오라클에서 말하는) 대기'이다. 예를 들어, 'SQL*Net message from client'는 오라클 클라이언트에서 통신(메세지)을 기다리고 있는 상태이며, OS상에서는 슬립하고 있다. 디스크에서 읽어오는 대기 이벤트인 'db file sequential(scattered) read'일 때도 디스크에서 읽어오는 것을 기다리며 OS상에서는 슬립하고 있다. 이전에 소개한 'Idle 대기 이벤트'는 대기 안에서도 SQL의 처리와는 관계없는 글자 그대로 '쉬고 있는' 대기를 말한다.

그런데 백그라운드 프로세스 중 몆 가지는 쉬지 않고 정기적으로 작업을 한다. 이것은 OS의 웨이크 업(wake up)기능을 사용하고 있다. 몆 초에서 몆십 초, 길게는 몆 시간마다 눈을 뜨게 설정되어 있으며, 눈을 뜰 떄마다 작업을 수행한다. v$session_wait를 보면 Idle 대기 이벤트로 얼마나 슬립하고 있었는지를 알 수 있다.(리스트 11.2) 이것이 대기한 시간이 긴 대기 이벤트가 존재하는 이유이다. 백그라운드 프로세스의 대기 이벤트 중 유명한 것들에는 리스트 11.2에서 보이는 'rdbms ipc message', 'smon timer', 'pmon timer'가 있다.

 

리스트 11.2

SELECT sid, program, event, p1, p2, p3, state, seconds_in_wait FROM v$session;

11.3 DBWR의 동작과 역활

여기부터는 백그라운드 프로세스의 동작을 하나씩 설명한다. 단, 그전에 DBWR, LGWR, ARCH라는 세 가지 백그라운드 프로세스에 관해 간단히 복습한다. DBWR은 변경된 데이터를 캐시에서 디스크로 기록하는 역활을 한다. 하지만 커밋한 시점에 기록하는 것은 아니며, 나중에 한번에 수행한다. 그 대신 LGWR이라고 하는 백그라운드 프로세스가 커밋한 시점의 REDO 로그(데이터 변경 정보)를 디스크에 기록한다. REDO 로그가 디스크에 기록되어 있으면, 만에 하나라도 DBWR이 데이터를 디스크에 기록하지 못했더라도 복구할 수 있다. LGWR은 REDO 로그파일에 REDO 로그를 기록하며, ARCH라는 백그라운드 프로세스가 아카이브 REDO 로그 파일에 기록한다.

 

1. 서버프로세스 : REDO 로그 버퍼에 REDO로그를 집어넣음

2. LGWR : 서버프로세스에서 의뢰를 받거나, 또는 자발적으로 REDO 로그 버퍼에서 REDO 로그파일로 REDO 로그를 기록함

3. ARCH : REDO 로그 파일에서 아카이브 REDO 로그 파일로 옮김

-- LGWR 프로세스와 ARCH 프로세스가 REDO를 다른 쪽으로 옮기는 작업을 수행해주므로, 처리하는 속도만 충분하다면 로그 버퍼나 REDO 로그 파일이 넘치는 일은 발생하지 않는다.

 

11.3.1 어떤 식으로 I/O를 하는 것인가?

우선, DBMS에서 중요한 비동기 I/O를 간단히 소개하기 전에 동기 I/O에 관해서 설명하겠다. 동기 I/O란, 서버 프로세스가 수행하는 'db file sequential read'와 같은 I/O를 말한다. 동기 I/O는 기본적인 I/O로서 한 개의 I/O 처리가 끝나기 전까지는 다음 처리를 할 수 없다. 그것과 비교하면 비동기 I/O는 I/O가 종료하기 전에 다음 처리를 실행할 수 있는 I/O를 말한다. 비동기 I/O를 사용하면 여러 개의 I/O를 동시에 처리할 수 있기 떄문에 디스크를 효율적으로 사용하게 된다.

 

이런 비동기 I/O라는 방식이 없다면 디스크는 여유가 넘치는데도 I/O에 병목 현상이 발생할 수 있다. 하지만 비동기 I/O라 할지라도 부하가 커지면 SQL을 처리하기 위해 데이터를 읽어오는 속도가 느려질 수 있으므로 디스크에 너무 많은 부하를 주어서는 안 된다. 그래서 부하가 많을 떄 DBWR은 부하가 너무 집중되지 않게 하기 위해 긴 시간에 걸쳐 가능한 부하를 균일하게 줄 수 있도록 동작한다.

 

DBWR의 대기 이벤트 'rdbms ipc message'는 Idle 상태라는 것을 나타내며, 'db file parallel write'는 동시에 병렬로 데이터를 디스크에 기록하고 있다는 것을 의미한다.(기럭하고 있는 도중에도 시점에 따라서는 이런 대기 이벤트가 표시되지 않기도 한다.) 단, OS에 따라서는 비동기 I/O를 사용하기 위한 조건이 있어서 실제로는 한 개의 I/O가 끝나고 다음 I/O를 처리하는 형태로 수행하는 경우도 있다.

 

11.3.2 DBWR의 수는 왜 장비마다 다른 것일까?

DBWR 프로세스는 OS상에서는 'DBWn'이라고 표시된다(n에는 숫자가 들어간다.) 이것은 DBWR이 여러 개 기동하고 있다는 것을 의미하며, 프로세스가 여러 개가 되면 DBW0, DBW1, DBW2 처럼 이어진다. 대형 시스템이나 디스크에 기록하는 속도가 느린 환경에서 DBWR을 여러 개 기동하며 성능을 향상할 수 있으며, 특히 비동기 I/O를 사용할 수 없는 환경에서 효과적이다. 많은 DBWR(DBW1이나 DBW2 등)이 한꺼번에 동작하는 모습을 보면 장관이다. 여기서도 '병렬 처리를 가능케 하고 높은 처리량을 실현한다'라는 키워드를 지키고 있다는 점을 기억하자. DBWR의 수는 초기화 파라미터 'DB_WRITER_PROCESSES'에서 조정할 수 있다.

 

11.3.3 어떤 때 DBWR에 장애가 발생하는가?

장애가 발생하는 것은 대부분 성능이 부족한 떄와 I/O의 행(hang)이나 지연이 발생했을 때이다. 예를 들어, 디스크의 성능이 한계에 다다랐을 때나 기록하는 속도가 따라가지 못할 떄 등이 있다. 이렇게 DBWR이 버퍼 캐시의 변경된 블록을 디스크에 기록하는 속도가 느려지면, 서버 프로세스가 사용할 수 있는 빈 버퍼가 미처 확보되지 못하므로 'free buffer waits'라는 대기 이벤트를 띄우고 기다린다. I/O가 일시적으로 행에 걸리면 DBWR도 일시적으로 행에 걸린다. 그러면 'free buffer waits'가 되거나, 해당 블록이 사용 중*이런 때는 기록 중)이라는 'write complete waits'나 'buffer busy waits'에 의해 서버 프로세스가 대기한다.

 

11.4 LGWR의 동작과 역활

 

11.4.1 언제 I/O를 하는 거야?

v$session 결과에서도 알 수 있듯이, 일반적으로 LGWR은 'rdbms ipc message' 상태로 슬립하고 있다. 앞에서도 설명했지만 LGWR은 커밋했을 때 REDO 로그를 기록하고, 커밋을 하지 않았어도 3초에 한 번 'rdbms ipc message'에서 깨어나서 로그 버퍼의 데이털르 기록하며, 기록할 때 LGWR은 'log file parallel write' 상태로 대기한다.

'parallel'이라고 되어 있는 부분에서 LGWR이 가능한 병렬로 수행하여 기록하려한다는 점을 유추할 수 있다. 또한, 서버 프로세스가 LGWR이 REDO 로그를 기록하는 것을 기다릴 때는 'log file sync'라는 대기 이벤트로 기다린다.

 

11.4.2 어떤 때 LGWR에 장애가 발생하는가?

성능이 부족하거나 REDO 로그의 생성량이 많을 떄, 아카이브를 받는 디스크가 가득 찻을 떄, 그리고 로그 버퍼의 용량이 작은 경우에 장애가 발생한다. 성능이 부족한 경우라고 말했지만, 9장에서 설명했듯이 여러 개의 REDO 로그 정보를 한꺼번에 모아서 내려쓰기 떄문에 성능이 그렇게 쉽게 부족해지진 않는다. 가장 흔히 발생하는 상황은 아카이블르 내려받는 디스크가 가득 차서 발생하는 장애이다. 또한, 로그 버퍼의 용량이 작을 때는 'log buffer space'대기 이벤트 등으로 대기한다. 최근에는 메모리 크기가 커졌기 떄문에 로그 버퍼를 128M 이상으로 설정하는 경우도 있다.

 

11.5 SMON의 동작과 역활

SMON(System MONitor)이라고 불리는 백그라운드 프로세스가 존재한다. 한마디로 설명하자면, '(주로) 공간 전문 청소 업체'이다. 테이블스페이스 안의 빈 공간들을 합친다든가, 처리 도중에 종료된 트랜잭션을 롤백한다든가, 임시 세그먼트를 청소하거나 한다. 평상시에는 'smon timer'라는 대기 이벤트 상태로 슬립하고 있다. 또 다른 큰 특징으로는 데이터베이스가 비정상 종료(서버 장비의 정지, 강제 종료 등)된 후 재기동할 때 인스턴스 복구라고 불리는 처릴르 수행한다. 오라클은 비정상 종료 됐을 때 데이터의 일관성을 보장할 수 없는 살태였을 수도 있지만, 온라인 REDO 로그 파일과 데이터 파일을 사용해서 이들이 일관성을 보장할 수 있도록 처리한다. 

 

11.6 PMON의 동작과 역활

PMON(Process MONitor)이라고 불리는 백그라운드 프로세스가 존재한다. 한마디로 설명하자면, '(주로) 메모리와 프로세스 전문 청소 업체'이다. PMON은 서버 프로세스가 비정상 종료했을 때 메모리나 프로세스를 정리한다. 필요할 때는 세션이나 프로세스를 청소하거나, 정리된 프로세스가 내부 Lock이나 메모리를 보유하고 있다면 그것을 해제한다. 이 작업을 하지 않으면 서버 프로세스 한 개가 중지되었을 떄 자칫 인스턴스 전체가 중지될 위험이 있다. 그런 부분을 보면 PMON은 매우 중요한 작업을 하는 프로세스라고 말할 수 있다.

PMON은 필요한 경우 청소를 약 1분에 한 번 수행한다. 평상시에는 'pmon timer'라는 대기 이벤트 상태로 슬립하고 있습니다. PMON은 다른 프로세스들을 감시해주고 있지만, PMON 자신이 비정상 종료하게 된다면 어떻게 될까? 답은 '인스턴스가 정지한다'이다. PMON에 문제가 발생한 상태라면 다른 프로세스를 감시할 수 없으며, 데이터베이스 전체가 불안정한 상태로 빠질 가능성이 크다. 최악에는 분명 기록한 데이터인데도 불구하고 반영되지 않은 등의 사태를 피하기 위해 MMAN 프로세스가 PMON의 이상을 감지하고 인스턴스를 정지하도록 명령한다.

 

11.7 LREG의 동작과 역활

LREG(Listener REGistration)라는 프로세스는 인스턴스의 정보, 현재 프로세스의 수, 인스턴스의 부하를 리스너에게 등록하는 작업을 한다. 오라클 11g까지는 PMON이 이런 처리를 수행했지만, 오라클 12c 이후에서는 LREG라는 전용 프로세스가 역활을 이어받았다. listener.ora 파일에 인스턴스의 정보를 등록하지 않더라도, 리스너는 인스턴스의 정보를 알고 있는 경우가 있는데, 이는 LREG가 리스너에 정보를 등록했기 때문이다. 또한, 초기화 파라미터로 커넥션 수의 상한을 설정했을 때 리스너가 현재의 커넥션 수를 알고 있는 것은 LREG가 정기적으로 리스너에게 알려주기 때문이다.

 

11.8 ARCH의 동작과 역활

ARCH(ARCHiver) 프로세스는 OS상에서 'ARCn'라고 표시된다.(n에는 숫자가 들어간다). 아카이버 프로세스는 REDO 로그 파일을 아카이브(보관)하는 프로세스이다. ARCH에 의해서 보관된 REDO 로그 파일을 아카이브 REDO 로그 파일이라고 부른다. 아카이브 로그 모드(REDO 로그를 아카이브해서 남기는 모드)일 때는 아카이브 REDO 로그가 생성될 떄까지는 해당 REDO 로그 파일을 다시 사용할 수 없다. 따라서 ARCH 프로세스가 중지되면 데이터베이스에 큰 문제가 발생할 수도 있다. 평상시에는 대기 이벤트 'rdbms ipc message' 상태로 슬립하고 있지만, 로그 스위치(LGWR이 내려쓸 REDO 로그 파일을 전환하는 작업)가 수행되어 아카이브 생성할 필요가 있을 떄 동작을 시작한다.

ARCH 프로세스는 노-아카이브 로그 모드에서는 생성되지 않으며, 아카이브 로그 모드에서만 생성된다. 프로세스는 처리 부하량에 따라 여러 개 기동되지만 'LOG_ARCHIVE_MAX_PROCESSES' 파라미터를 통해 최초에 기동해둘 프로세스 수를 제어할 수 있다.

그 외에는 데이터 가드(Data Guard)라는 데이터베이스의 복제/동기화를 수행하는 기능을 사용할 때도 ARCH 프로세스가 사용된다. 데이터 가드는 복제할 원본 데이터베이스에서 대상 데이터베이스에 REDO 로그를 전송하고 적용함으로써 데이터를 동기화한다. REDO 전송이 늦어지거나, 어떤 이유로 인해 REDO를 전송하지 못했을 때는 원본 데이터베이스와 대상 데이터베이스 간에 정보(동기화)가 맞지 않게 되므로 아카이브 REDO 로그를 전송한다(설정에 따라 다르지만 REDO의 정보는 TMON이나 NSS와 같은 프로세스가 보내며, RFS 프로세스가 수신을 담당한다). 그떄 복제 대상 데이터베이스에 통신이 되는지 확인과 아카이브 REDO의 전송 같은 작업을 ARCH가 담당하며, 아카이브 REDO 로그를 생성하는 작업도 병행해서 수행한다.

 

11.9 그 외의 백그라운드 프로세스

 

11.9.1 CKPT

체크포인트(버퍼 캐시의 변경된 데이터를 데이터 파일에 반영하는 작업)를 할 때 데이터 파일의 헤더에 관리 정보를 기록하는 프로세스이다. 진정한 지원 스태프라고 할 수 있기 때문에 평소에는 크게 신경 쓸 일이 없는 프로세스 중 하나이다.

체크포인트를 수행할 때 데이터 파일에 기록하지 못하는 상황이 발생할 수 있다. 그럴 떄는 데이터의 정합성을 확보하기 위해 오라클은 인스턴스를 정지시키거나 데이터 파일을 오프라인으로 변경한다.

 

11.9.2 그 외의 여러 프로세스

('X'에는 숫자가 들어갑니다)

프로세스	설명
SXXX	공유 서버 프로세스이다. 공유 서버 구성(오라클 클라이언트와 서버 프로세스가 1:1로 대응하지 않는 구성)용 서버 프로세스이다.
DXXX	디스패처이다. 이것도 마찬가지로 공유 서버 구성을 위한 프로세스이다. 오라클 클라이언트에서 요청을 받아 공유 서버 프로세스에게 보내는(dispatch) 일을 한다.
JXXX	오라클 '잡(job)'을 위한 프로세스이다. 잡 코디네이터에 의해 기동한다.
CJQX	잡의 코디네이터이다. JXXX를 늘리거나 줄이며, 오라클 기동 시에 함께 기동한다.
PXXX	슬레이브 프로세스라고 부를 수 있다. 병렬 쿼리(대량의 데이터를 병렬로 처리해서 결과를 빠르게 가져오기 위한 쿼리)를 위한 프로세스이다. 병렬 쿼리를 사용할 떄는 여러 개의 슬레이브 프로세스가 손발이 되어 데이터를 읽어오거나 정렬 등을 수행한다. 그러나 병렬로 처리한다고 해서 반드시 빨라지지는 않는다.
QMNX QXXX	AQ(Advanced Queuing : 비동기식 방식으로 메세지를 주고받는 기능)를 위한 프로세스이다. 메세지를 관리하고 통보하는 등의 작업을 수행한다.
QMNC	QMNX, QXXX와 마찬가지로 AQ를 위한 프로세스이다. 코디네이터의 역활을 수행한다.
MMAN	Memory MANager 프로세스이다. SGA 안의 메모리를 조정한다. 이 프로세스는 오라클 10g에서부터 존재하며, 기본적으로 오라클과 함께 기동한다.
MMON	AWR을 수집하기 기록하기 위한 프로세스이다. 오라클 10g 이후부터는 기본으로 오라클과 함께 기동한다.
LMSX LMD0 LCKX LMON DIAG	RAC용 프로세스이다. RAC는 여러 장비에서 데이터베이스(데이터나 Lock을 포함)를 공유하는 구성을 말한다. LMSX는 캐시 퓨전(Cache Fusion, 장비 간의 데이터를 주고받는것)을 수행하는 프로세스이다. DIAG는 장애가 발생했을 떄의 정보를 수집하기 위한 프로세스이다. DIAG는 v$session_wait에서 처리하는 중으로 보이더라도 실제로는 슬립하고 있는 경우도 있으므로 오해하지 않도록 주의할 필요가 있다. 버전에 따라 다르지만, 그 외의 프로세스는 장비 간의 Lock 등을 다루기 위한 프로세스이다. 또한, RAC가 아닌 환경에서도 실수로 RAC를 설치하면 이 프로세스들이 기동한다.
RECO	분산 트랜잭션에 발생하는 문제를 해결하기 위한 프로세스이다. 분산 트랜잭션이란 여러 데이터베이스에 걸친 트랜잭션을 말한다. 단, 분산 트랜잭션을 사용하지 않고 있다면 신경 쓸 필요는 없다.

Tip.

유닉스상의 오라클에 로그인 할 수 없을 떄는 어떻게 해야 하는가?

어쩌다가 오라클에 행이 발생해서 관리자(예: SYSTEM) 계정으로 로그인할 수 없을 때가 있다. 유닉스 계열의 OS에서 그런 일이 발생했을 때는 SYSDBA로 연결을 시도하면 로그인 할 수 있는 경우가 있다.

그래도 로그인할 수 없을 때는 강제로 정지하기 위한 수단으로 프로세스를 KILL 명령어를 사용하여 정리하는 방법도 고려할 수 있지만, 오라클의 프로세스가 1000~2000개나 된다면 많은 시간이 걸린다. 그럴 때는 SMON 등의 백그라운드 프로세스 하나를 KILL하면 오라클이 스스로 인스턴스를 빠르게 정지시킨다. 도저희 손을 쓸 수 없을 때나 장애 테스트를 할 때 장애를 재현하는 방법으로 사용해라.

또한, 장애 모니터링의 일환으로써 정기적으로 오라클에 로그인하여 정상 가동 여부(로그인 할 수 없는 상황을 이용해 이상이 발생했다는 것을 탐지)를 확인하는 도구(툴)나 소프트웨어가 있지만, 앞서 설명한 대로 이상을 탐지할 수 없는 상황도 있으므로 SYSDBA 등의 특수한 권한을 가진 계정을 이용해서 가동 여부를 확인하는 방법은 이용하지 않는 편이 좋다. 따라서 오라클을 모니터링을 위한 별도의 계정을 생성하여 사용하는 것을 권장한다.

 

11.10 요약

PMON 프로세스	다른 프로세스가 비정상 종료되지 않았는가를 점검하며, 발견했을 떄는 정리하는 역활도 수행한다.
SMON 프로세스	공간을 정리하는 담당이다. 단편화된 공간의 정리나 UNDO 세그먼트의 크기 조정, 비정상 종료한 트랜잭션의 롤백 등을 수행한다.
DBWR 프로세스	작업장에 어질러져있는 데이터를 창고로 되돌리는 담당이다.(버퍼 캐시(공유 메모리)의 변경된 데이터의 기록)
LGWR 프로세스	로그 버퍼(공유 메모리)의 REDO 로그를 기록
ARCH 프로세스	REDO 로그 파일을 읽어서 아카이브 REDO 로그 파일을 생성
CKPT 프로세스	데이터 파일에 포함된 관리정보를 갱신하는 데이터 파일 관리 담당이다.(체크포인트를 수행할 떄 데이터 파일의 헤더에 관리 정보를 기록)