[Oracle] Oracle Architecture(4) [백그라운드 프로세스]

👇용어정리

• SGA(System Global Area) : 공유메모리 영역으로 데이터를 빠르게 처리하기 위한 공간
• PGA(Program Global Area) : 개별 메모리 공간으로 정렬 중간 데이터, 사용자 세션 정보 등 처리
• Shared Pool: 내가 방금 실행한 SQL 문장이 어떻게 실행될지 짜놓은 '계획서'를 보관합니다. 똑같은 SQL을 던지면 다시 분석 안 하고 여기서 계획서를 꺼내 씁니다
• Library Cache: SQL 문장, 실행 계획을 저장하는 곳
• Data Dictionary Cache:  메타데이터가 저장된 곳으로 테이블 정보, 권한, 통계 (설계도)를 저장하는 곳
• Database Buffer Cache: 하드디스크에서 읽어온 실제 데이터(Table 등)를 보관하는 곳입니다. 똑같은 데이터를 또 찾을 때 디스크까지 안 가고 여기서 바로 꺼내주니 속도가 엄청나게 빨라지죠.
• Redo Log Buffer: 데이터에 변화가 생겼을 때(Insert, Update 등) 그 기록을 잠시 보관합니다. 갑자기 정전이 되어도 이 기록을 보고 복구할 수 있게 해주는 보험 같은 공간입니다.
• Large Pool: 백업이나 대용량 처리처럼 메모리를 많이 잡아먹는 작업을 위해 따로 빼놓은 보조 공간입니다.
• Java Pool: 오라클 데이터베이스 내부에서 자바(Java) 코드를 실행할 때 사용하는 전용 메모리 영역입니다.
• Soft Parse: 이미 누군가 실행했던 SQL이라 실행 계획이 메모리에 있는 경우입니다. CPU를 거의 쓰지 않아 매우 빠릅니다.
• Hard Parse: 처음 들어온 SQL이라 최적화(Optimizer) 과정을 거쳐 실행 계획을 새로 짜야 합니다. CPU와 메모리를 많이 잡아먹는 '비싼' 작업입니다.
• DBWR: Data Buffer Cache의 데이터를 데이터 파일로 옮기는 프로세스 입니다.
• DBWn: DBWR 프로세스를 여러 개(n개) 운용할 때의 집합 입니다.
• LGWR: Redo Log Buffer의 내용을 Redo Log File에 옮기는 프로세스 입니다.
• CKPT: 수정된 데이터를 디스크에 작성 명령을 내리고, Control File과 Data File 헤더에  SCN을 새기는 프로세스 입니다.
• SMON: DB가 비정상 종료 시, 재기동때 Redo 로그를 보고 작업 중이던 데이터를 복구하는 프로세스 입니다.
• PMON: 클라이언트의 접속이 끊겨 서버 프로세스가 죽으면 자원을 회수하는 프로세스 입니다.

---

오라클 백그라운드 프로세스

Oracle Background Process

5대 프로세스

1. DBWR (Database Writer)

"Buffer Cache의 데이터를 데이터 파일로 옮깁니다."

• 역할: 사용자가 수정한 데이터(Dirty Block)를 메모리에서 하드디스크(Data Files)로 실제 저장하는 역할을 합니다.
• 핵심 메커니즘: 사용자가 COMMIT을 한다고 해서 DBWR가 즉시 디스크에 쓰지 않습니다. 메모리가 부족하거나, 체크포인트(Checkpoint)가 발생했을 때 효율적으로 한꺼번에 내려씁니다. (그래서 DB가 효율적인 것입니다.)

 

2. LGWR (Log Writer)

"Redo Log Buffer의 내용을 Redo Log File에 옮깁니다."

• 역할: 오라클에서 변경 이력을 담은 Redo Log Buffer를 디스크(Redo Log Files)에 기록합니다.
• 핵심 메커니즘: 사용자가 COMMIT을 누르는 순간 일을 시작합니다. 데이터 파일에 쓰기 전(DBWR)에 로그부터 확실히 남겨서, 사고가 나도 복구할 수 있게 보장합니다.

👇 ★Commit 

• Commit
  • Commit 실행 시 Redo Log Buffer에 있는 변경 이력만 Redo Log 파일에 저장합니다.
  • 발생 시점
    1. DDL 문장 실행 시 자동 커밋
    2. DCL 문장 실행 시 자동 커밋
    3. COMMIT; 실행 시
    4. DB 접속을 정상적으로 나갈때
    5. 최소 3초에 한번씩 발생

 

3. CKPT (Checkpoint Process)

"메모리와 디스크의 정보를 일치시킵니다."

• 역할: DBWR에게 "지금까지 수정된 거 다 디스크에 써!"라고 신호를 보내고, 컨트롤 파일과 데이터 파일 헤더에 "여기까지 저장 완료!"라는 번호(SCN)를 새깁니다.
• 실무 포인트: 이 번호가 서로 맞지 않으면 오라클은 "데이터가 깨졌다"고 판단하여 DB가 켜지지 않습니다.

👇 ★CheckPoint

• Checkpoint
  • Checkpoint 실행 시 CKPT가 DBWn(DBWR 그룹 약어)를 호출하여 Data Buffer Cache에서 수정되었지만 디스크에 아직 작성되지 않은 데이터들을 Data File에 작성합니다. 즉, 데이터 수정이 일어나면 Data File에 옮겨는 역할을 합니다.
  • Checkpoint 완료되면 Control File과 Data File Header에 SCN을 남깁니다.
  • 발생 시점
    1. Redo Log 파일이 꽉 차서 Log Switch가 일어날 때.
    2. 관리자가 ALTER SYSTEM CHECKPOINT; 명령을 직접 내릴 때
    3. DB를 정상 종료 할 때

 

4. SMON (System Monitor)

"시스템 장애 후 재시작 시 자동 복구를 수행합니다."

• 역할(DB 인스턴스 전체 대상)
  • 정전 등으로 DB가 비정상 종료되었다면, 다시 켤 때 Redo 로그를 보고 작업 중이던 데이터를 복구합니다.
    
    1. Control File의 SCN과 Data File의 SCN을 비교
    2. SCN이 서로 다르다면  Redo Log를 읽어 Data File에 적히지 않은 데이터를 메모리에 다시 작성
    3. 커밋되지 않은 작업들은 Roll-Back
  • Temp 테이블스페이스를 쓴 후 더 이상 안 쓰는 데이터(임시 세그먼트) 정리하여 공간을 정리합니다.

 

5. PMON (Process Monitor)

"죽은 프로세스를 감시하고 자원을 회수합니다."

• 역할(클라이언트 대상)
  • 클라이언트 접속이 갑자기 끊기거나 서버 프로세스가 죽으면, 그 프로세스가 잡고 있던 Lock을 해제하고 메모리(PGA)를 다시 확보합니다.
  • 비정상 적으로 클라이언트 접속이 끊기면 작업 중인 트랜잭션을 롤백을 수행하여 데이터 일관성을 유지합니다. 

 

 

❗Data Buffer Cache와 Redo Log Buffer의 메모리에 기록을 남기는 역할은 Server Process라는것을 헷갈리면 안됩니다.

 

---

추가 백그라운 프로세스

1. ARCn (Archiver Process)

"꽉 찬 Redo Log 파일을 아카이브 로그 파일로 복제합니다."

• 역할: 온라인 리두 로그 파일이 다 차면, 다음 파일로 넘어가기 전에 그 내용을 별도의 공간(Archive Destination)에 복사해 둡니다.
• 실무 포인트: DB가 Archive Log Mode일 때만 작동합니다. 이 프로세스가 없으면 리두 로그가 덮어씌워져서 과거 시점으로의 복구가 불가능해집니다. 만약 아카이브 저장 경로가 꽉 차서 ARCn이 일을 못 하면, DB 전체가 멈춰버리는 무서운 상황이 발생합니다.

 

2. RECO (Recoverer Process)

"서로 다른 DB 간의 꼬인 매듭을 풀어줍니다."

• 역할: 여러 개의 DB가 연결된 환경(Database Link 등)에서 트랜잭션을 수행하다가 한쪽 네트워크가 끊겨서 "한쪽은 커밋, 한쪽은 미결정" 상태가 된 데이터를 찾아내어 자동으로 해결(Rollback 또는 Commit)합니다.

 

3. LREG (Listener Registration Process)

"리스너에게 인스턴스의 생존 신고를 합니다."

• 역할: 우리가 앞서 배운 **'동적 등록(Dynamic Registration)'**의 주인공입니다. DB가 뜨면 리스너를 찾아가 "나 지금 서비스 준비 됐어!"라고 알려줍니다.
• 실무 포인트: 예전 버전에서는 PMON이 이 일을 같이 했지만, 지금은 LREG가 전담하여 리스너와의 소통을 책임집니다.

 

4. MMNL / MMON (Manageability Monitor)

"DB의 건강 상태(통계 정보)를 수집합니다."

• 역할: AWR(Automatic Workload Repository) 보고서를 만들기 위해 1시간마다(기본값) 스냅샷을 찍고 통계 데이터를 보관합니다.
• 실무 포인트: 우리가 나중에 성능 튜닝을 할 때 보게 될 수많은 지표들이 다 이 녀석들이 부지런히 메모리(SGA)에서 긁어모은 데이터들입니다.

---

💡시나리오로 감 잡기

아래 상황을 읽어보고, 어떤 원인일지 잠시만 멈춰서 생각해보세요. 

시나리오 1. COMMIT 후에도 변하지 않는 데이터 파일

• 제목: "커밋은 성공했는데, 왜 데이터 파일(.dbf) 수정 시간은 그대로일까?"
• 상황: 대량의 데이터를 UPDATE하고 COMMIT까지 완료했습니다. 하지만 OS에서 데이터 파일의 수정 시간을 확인해 보니 변경되지 않았습니다.

👇원인과 해결

• 원인: 오라클은 성능을 위해 'Lazy Writing' 전략을 사용합니다. COMMIT 시점에 무거운 데이터 파일(DBWR)을 수정하는 대신, 가벼운 리두 로그(LGWR)에만 변경 이력을 빠르게 기록하고 사용자에게 성공을 알립니다.
• 해결: 정상적인 동작입니다. 실제 데이터 파일은 나중에 체크포인트(Checkpoint)가 발생하거나 메모리가 부족할 때 DBWR가 백그라운드에서 조용히 처리하므로 기다리면 됩니다.

 

시나리오 2. 갑작스러운 정전과 데이터 증발 의문

• 제목: "데이터 파일에 쓰기 전 정전이 났는데, 내 데이터는 안전할까?"
• 상황: 중요한 데이터를 수정하고 COMMIT을 누른 직후, 서버 전원이 나갔습니다. 아직 DBWR가 디스크에 쓰기 전이라 데이터가 사라졌을까 봐 걱정되는 상황입니다.

👇원인과 해결

• 원인: 데이터 파일엔 기록되지 않았지만, COMMIT 순간 LGWR가 Redo Log File에 변경 이력을 이미 저장해 두었습니다. 즉, '보험'은 들어져 있는 상태입니다.
• 해결: 서버를 다시 켜면 SMON이 자동으로 가동됩니다. SMON은 리두 로그를 읽어 데이터 파일에 반영되지 않은 내용을 메모리에 복구(Roll-Forward)하여 데이터를 안전하게 살려냅니다.

 

시나리오 3. 강제 종료 후 풀리지 않는 자물쇠(Lock)

• 제목: "DBeaver를 강제 종료했는데, 왜 해당 로우(Row)는 수정 불가 상태일까?"
• 상황: 쿼리를 실행하다가 프로그램이 멈춰서 강제 종료했습니다. 다시 접속해 보니 아까 수정하던 데이터가 여전히 Lock이 걸려 있어 수정할 수 없습니다.

👇원인과 해결

• 원인: 클라이언트 프로그램만 꺼졌을 뿐, 서버의 Server Process는 주인을 잃은 채 여전히 메모리와 자원(Lock)을 붙잡고 있는 '고스트 세션' 상태가 되었기 때문입니다.
• 해결: PMON이 해결사로 나섭니다. PMON은 주기적으로 프로세스들을 감시하다가 연결이 끊긴 프로세스를 발견하면, 즉시 해당 작업을 롤백하고 잡고 있던 Lock을 해제하여 자원을 회수합니다.

 

시나리오 4. "실행 계획이 갑자기 나빠져서 쿼리가 느려졌어요"

• 제목: "어제까지 빠르던 쿼리가 오늘 갑자기 느려진 배후, MMON의 스냅샷"
• 상황: 특별한 설정 변경이 없었는데 특정 쿼리의 성능이 급격히 저하되었습니다. 확인해보니 실행 계획(Execution Plan)이 엉뚱하게 바뀌어 있습니다.

👇원인과 해결

• 원인: MMON 프로세스가 주기적으로 수집한 통계 정보 때문입니다. 데이터 양이 급격히 변한 상태에서 MMON이 새로운 통계 정보를 갱신했고, 이를 바탕으로 옵티마이저가 '더 낫다고 판단한(사실은 아닌)' 새로운 계획을 짰기 때문입니다.
• 해결: 잘못 수집된 통계 정보를 이전 시점으로 되돌리거나(Restore Statistics), 해당 SQL에 힌트(Hint)를 주어 강제로 좋은 실행 계획을 쓰도록 고정해야 합니다.