[Admin] Instance Failure & Recovery

Instance Failure & Recovery 개념

Oracle 데이터베이스에서 인스턴스 장애(Instance Failure) 및 복구(Recovery) 과정을 나타냅니다.

 

1. 장애 발생 전 트랜잭션 흐름

tx51 트랜잭션 실행 (빨간색)

• UPDATE emp SET salary=2000 WHERE id=1;
• COMMIT 수행
• 변경된 데이터는 SGA(Buffer Cache)와 Redo Log Buffer에 저장
• LGWR(Log Writer) 프로세스가 Redo Log File로 변경 사항을 기록

tx52 트랜잭션 실행 (파란색)

• UPDATE A → B 수행
• 아직 COMMIT 되지 않음 (Uncommitted Transaction)

 

2. 인스턴스 장애 발생

SGA(Buffer Cache) 내의 변경 사항은 손실됨

Redo Log File 및 UNDO에는 여전히 변경 내역이 남아있음

 

 

3. 인스턴스 복구 (Instance Recovery)

SMON(System Monitor Process) 자동 복구 수행

• Redo Log를 이용해 COMMIT된 트랜잭션(tx51)의 변경사항을 재적용 (ROLLFORWARD)
• UNDO 정보를 이용해 COMMIT되지 않은 트랜잭션(tx52) 롤백(ROLLBACK)
• 데이터 일관성을 유지하며 복구 완료

 

Instance Failure & Recovery 1

• tx51은 commit되었으므로 데이터 반영됨
• tx52는 rollback되어 변경 사항이 무효화됨

 

그림 요소 분석

1. Shared SQL Area

• 실행 중이던 SQL정보 및 변경데이터 저장
• 인스턴스 장애 시 손실됨

2. Redo Log File

• LGWR가 변경사항을 기록
• 장애 발생 시 복구를 위해 사용됨

3. Data File

• 실제 데이터가 저장되는 공간
• Redo Log를 통해 복구 수행

4. UNDO Tablespace

• 변경 전 데이터를 보관하여 ROLLBACK 가능
• 비정상 종료된 트랜잭션을 되돌리기 위해 사용됨

 

1. 장애 발생 이후 데이터베이스 재시작

• sql> startup 실행
• DB Instance 시작 (Instance Started) → DB Mounted → DB Opened

2. SMON (System Monitor) 프로세스가 복구 수행

① Rolling Forward (Redo 적용)

• Redo Log File을 이용해 커밋된 트랜잭션(tx51)의 변경 사항을 재적용
• 데이터파일(Data File)에 저장되지 않은 변경사항을 다시 기록하여 데이터 정형성을 유지

② Rollback (Undo 적용)

• 커밋되지않은 트랜잭션(tx52)의 변경사항을 롤백
• Undo Tablespace를 사용해 tx52에서 변경한 데이터를 원래 값으로 복원

 

Instance Failure & Recovery 2

• SMON이 Rolling Forward를 시작
• tx51이 Commit 완료된 트랜잭션이므로 Redo Log를 사용해 복구 중
• tx52는 아직 롤백되지 않은 상태

 

Instance Failure & Recovery 3

• Rolling Forward 완료 후 Rollback 진행
• tx52가 롤백되며 데이터 변경 사항 취소
• 최종적으로 데이터베이스가 정합성을 유지하며 정상적으로 오픈됨

 

결론

✅ Redo Log를 이용한 Rolling Forward → 커밋된 트랜잭션 복구
✅ Undo를 이용한 Rollback → 비정상 종료된 미완료 트랜잭션 취소
✅ SMON(System Monitor) 프로세스가 자동으로 복구 진행

 

 

• Oracle은 Redo Log + Undo Tablespace를 활용해 장애 발생 시 자동 복구 수행
• SMON이 자동으로 Instance Recovery를 진행
• COMMIT된 트랜잭션은 유지되고, 미완료 트랜잭션은 ROLLBACK 처리됨