Oracle 아키텍처 입문: Database·Instance·Startup 단계

핵심 요약

Oracle 아키텍처의 출발점은 Database, Instance, Process를 서로 다른 생명주기로 구분하는 것입니다.

Database
→ Datafile·Control File·Online Redo Log처럼 영속적으로 저장되는 물리 구조

Instance
→ Database 파일을 관리하기 위해 시작되는 SGA와 Background Process의 실행 단위

Server Process
→ Client 요청을 받아 SQL·PL/SQL을 처리하고 결과를 반환하는 Process

전용 서버 구성을 단순화하면 다음과 같습니다.

Client Process
→ Oracle Net Listener가 접속 중개
→ Dedicated Server Process
→ SGA
→ Database Files

단, Shared Server 구성에서는 Client가 Dispatcher에 연결되고 여러 요청을 Shared Server Process Pool이 처리하므로 항상 Client와 Server Process가 1:1인 것은 아닙니다.

학습 목표

• Database와 Instance를 물리 파일과 실행 환경 관점에서 구분한다.
• CDB·PDB의 Datafile, Control File, Online Redo Log 관계를 설명한다.
• SGA·Background Process·Server Process·Session·Connection을 구분한다.
• NOMOUNT → MOUNT → OPEN 단계에서 실제로 열리는 파일과 가능한 작업을 설명한다.
• V$INSTANCE, V$DATABASE, V$PDBS로 현재 상태를 진단한다.
• Shutdown 방식별 다음 Startup의 Instance Recovery 필요 여부를 구분한다.
• Commit Redo와 Dirty Buffer 기록 시점이 다른 이유를 설명한다.
• Single Instance와 RAC의 Database·Instance·Redo Thread 관계를 구분한다.

1. Database·Instance·Process의 경계

1.1 Database

Oracle Database는 데이터를 영속적으로 보존하는 물리 파일 집합입니다. Oracle AI Database 26ai의 기본 Multitenant 관점에서는 CREATE DATABASE로 CDB를 만들며, CDB가 하나의 Database 단위가 됩니다.

Oracle Database(CDB)
├─ Datafiles
├─ Control Files
└─ Online Redo Log Files

PDB는 CDB 안에서 독립적인 논리 Database처럼 동작하고 전용 Datafile 집합을 가질 수 있지만, 별도의 전용 Control File과 Online Redo Log는 갖지 않고 CDB의 구조를 공유합니다.

1.2 Instance

Instance는 Database 파일을 관리하는 실행 환경입니다.

Oracle Instance
= SGA
+ Background Processes

Instance가 종료되어도 Database 파일은 Disk 또는 ASM에 남습니다. 반대로 Instance가 NOMOUNT 상태로 시작됐지만 아직 특정 Database를 Mount하지 않은 상태도 가능합니다.

1.3 Server Process·Session·Connection

Listener는 SQL을 Parse하거나 실행하지 않습니다. 전용 서버에서는 한 Client Connection이 한 Dedicated Server Process와 연결됩니다. Shared Server에서는 Dispatcher와 Request·Response Queue를 통해 Shared Server Process가 여러 Client 요청을 처리합니다.

2. Database의 핵심 물리 구조

2.1 Datafile

Datafile은 Table·Index·Undo Segment 등 논리 구조의 Oracle Block을 저장합니다.

Tablespace
→ Segment
→ Extent
→ Oracle Block
→ Datafile

PDB는 자체 Tablespace와 Datafile을 가질 수 있습니다. Temporary Tablespace는 Tempfile을 사용하며, 일반 Datafile과 목적과 Recovery 특성이 다르므로 구분합니다.

2.2 Control File

Control File은 Database의 물리 구조와 상태를 기록하는 작은 Binary File입니다.

대표 정보는 다음과 같습니다.

• Database 이름과 DBID
• Datafile과 Online Redo Log의 이름·위치
• Redo Thread와 Log Sequence
• Checkpoint 정보
• Log History
• RMAN Backup·Recovery 관련 Metadata 일부

Database는 논리적으로 하나의 Control File을 가지며 가용성을 위해 동일한 내용을 가진 여러 Member로 Multiplexing할 수 있습니다. Control File이 없거나 일치하지 않으면 Database를 Mount할 수 없습니다.

2.3 Online Redo Log

Online Redo Log는 변경된 Block의 완전한 복사본이 아니라 변경을 재현할 Redo Record를 순환 방식으로 저장합니다.

DML
→ Server Process가 Redo Log Buffer에 Redo 생성
→ LGWR가 Online Redo Log에 순차 기록
→ Instance Failure 시 Recovery에 사용

CDB의 PDB들은 CDB 수준의 Online Redo Log를 공유합니다. RAC에서는 Database가 여러 Redo Thread를 가지며 각 Instance가 자신의 Thread에 Redo를 기록합니다.

2.4 Parameter File은 어디에 속하는가?

SPFILE 또는 PFILE은 Instance를 어떤 크기와 옵션으로 시작할지 정의하는 Startup 설정 파일입니다. Datafile·Control File·Online Redo Log와 함께 중요하지만, 사용자 Data를 저장하는 핵심 Database File로 분류하지 않습니다.

3. Instance의 메모리와 Background Process

3.1 SGA

SGA는 Server Process와 Background Process가 공유하는 Memory 영역입니다.

3.2 대표 Background Process

CKPT는 Data Block을 직접 Datafile에 쓰지 않습니다. Dirty Block Write는 DBWn이 담당하고, CKPT는 Checkpoint 정보 갱신과 DBWn 신호를 담당합니다.

4. Startup 단계: NOMOUNT → MOUNT → OPEN

일반적인 SQL*Plus STARTUP은 Instance 시작, Database Mount, Database Open을 연속 수행합니다. Oracle Restart나 RAC가 Database를 관리하는 환경에서는 운영 일관성을 위해 SRVCTL 사용을 우선 검토합니다.

4.1 NOMOUNT: Instance 시작

SPFILE/PFILE 탐색·읽기
→ SGA 할당
→ Background Process 시작
→ Instance 생성

이 단계에서는 Control File을 열지 않았으므로 특정 Database와 아직 연결되지 않습니다.

대표 작업:

• Database 생성
• Control File 재생성
• SPFILE 복구 등 일부 관리·복구 작업

상태 확인:

SELECT instance_name,
       status,
       database_status,
       startup_time
FROM   v$instance;

V$INSTANCE.STATUS는 일반적으로 STARTED입니다.

4.2 MOUNT: Control File을 열어 Database와 연결

Instance
→ Control File Open
→ Database 이름·Datafile·Redo Log·Checkpoint 구조 확인
→ Database Mount

Datafile과 Online Redo Log를 일반 사용자 접근용으로 열지 않았으므로 Table 조회는 불가능합니다.

대표 작업:

• Database 전체 Media Recovery
• ARCHIVELOG·NOARCHIVELOG Mode 변경
• Datafile 이름 변경
• 일부 Backup·Recovery 작업

상태 확인:

SELECT status
FROM   v$instance;

SELECT name,
       open_mode,
       database_role,
       log_mode
FROM   v$database;

일반적으로 V$INSTANCE.STATUS='MOUNTED', V$DATABASE.OPEN_MODE='MOUNTED'입니다.

4.3 OPEN: Datafile과 Online Redo Log를 열어 사용자 접근 허용

Datafile·Online Redo Log Open
→ File Header와 Control File 정보의 일관성 확인
→ 필요 시 Instance Recovery
→ 일반 사용자 SQL 허용

Primary Database는 보통 READ WRITE로 열고, 필요에 따라 READ ONLY로 열 수 있습니다.

일반적으로 V$INSTANCE.STATUS='OPEN'이고 V$DATABASE.OPEN_MODE는 READ WRITE 또는 READ ONLY입니다.

4.4 단계 비교

5. CDB와 PDB의 Open 상태

CDB Root가 Open됐다고 모든 User PDB가 같은 Mode로 Open됐다고 볼 수 없습니다.

SELECT con_id,
       name,
       open_mode,
       restricted
FROM   v$pdbs
ORDER BY con_id;

V$PDBS.OPEN_MODE의 대표 값은 MOUNTED, READ WRITE, READ ONLY, MIGRATE입니다. CDB는 정상 Open됐지만 특정 Application 접속만 실패한다면 다음을 확인합니다.

1. 대상 PDB의 OPEN_MODE
2. 대상 Service의 등록·상태
3. 접속 Descriptor의 Service Name
4. PDB가 Restricted 상태인지 여부

필요한 경우 PDB Open 상태를 저장해 다음 CDB Startup 때 복원하도록 SAVE STATE를 사용할 수 있지만, 시험에서는 먼저 CDB 상태와 PDB 상태를 별도로 확인하는 원리를 적용합니다.

6. 상태·파일 확인 SQL

6.1 Instance와 Database

SELECT instance_name,
       status,
       database_status,
       startup_time,
       parallel,
       database_type
FROM   v$instance;

SELECT name,
       dbid,
       open_mode,
       database_role,
       log_mode,
       checkpoint_change#
FROM   v$database;

V$INSTANCE는 현재 Instance 상태를 보여 줍니다. V$DATABASE는 Control File에서 읽은 Database 정보를 보여 주므로 MOUNT 단계에서도 핵심 정보를 확인할 수 있습니다.

6.2 핵심 파일

SELECT name,
       status
FROM   v$controlfile;

SELECT file#,
       name,
       status,
       checkpoint_change#
FROM   v$datafile
ORDER BY file#;

SELECT group#,
       member,
       status
FROM   v$logfile
ORDER BY group#, member;

RAC 전체 Instance 상태를 동시에 볼 때는 GV$INSTANCE처럼 GV$ View와 INST_ID를 사용합니다.

7. Shutdown 방식

운영에서는 예측 가능한 종료를 위해 일반적으로 SHUTDOWN IMMEDIATE를 많이 사용합니다. SHUTDOWN ABORT는 다른 방식으로 종료할 수 없거나 즉시 중단해야 하는 경우에 제한적으로 사용합니다.

8. Commit·Checkpoint·Instance Recovery

8.1 Fast Commit

COMMIT
→ Transaction에 Commit SCN 할당
→ Commit Record와 관련 Redo를 LGWR가 Online Redo Log에 기록
→ 성공 반환

Commit 성공 시점에 모든 Dirty Block이 Datafile에 기록될 필요는 없습니다. DBWn은 효율적인 시점에 Dirty Block을 기록합니다.

8.2 Write-Ahead 원칙

DBWn이 Dirty Block을 Datafile에 기록하기 전에 그 Block 변경을 보호하는 Redo가 Online Redo Log에 먼저 기록돼 있어야 합니다. 필요한 Redo가 아직 기록되지 않았다면 DBWn은 LGWR에 Redo Write를 요청하고 완료를 기다립니다.

8.3 CKPT와 Checkpoint

CKPT는 Checkpoint 위치·SCN을 Control File과 Datafile Header에 갱신하고 DBWn에 Dirty Block Write를 요청합니다. Checkpoint가 전진할수록 Instance Recovery가 다시 적용해야 할 Redo 범위가 줄어듭니다.

8.4 ABORT 이후 Recovery

불완전 종료 후 Instance Recovery는 자동으로 수행됩니다.

1. Cache Recovery
   → Checkpoint 이후 Online Redo를 Roll Forward
   → Commit·Uncommit 변경이 모두 Block에 재현될 수 있음

2. Transaction Recovery
   → Undo를 사용해 미Commit Transaction 변경을 Rollback
   → Transaction 일관성 복원

따라서 Recovery는 단순히 Commit 변경만 재적용하는 과정이 아니라 Redo Roll Forward 후 미Commit 변경 Undo까지 포함합니다.

9. Single Instance와 RAC

9.1 Single Instance

Database 1개
↕
Instance 1개

9.2 RAC

                 ┌─ Instance 1: SGA·Background Process·Redo Thread 1
Shared Database ─┼─ Instance 2: SGA·Background Process·Redo Thread 2
                 └─ Instance 3: SGA·Background Process·Redo Thread 3

RAC의 각 Instance는 독립 SGA와 Background Process를 가지며 같은 Database의 Datafile과 Control File을 공유합니다. 각 Instance는 자신의 Redo Thread를 사용합니다. 한 Instance가 비정상 종료되면 살아 있는 다른 Instance가 해당 Redo Thread의 Instance Recovery를 수행할 수 있습니다.

RAC를 하나의 거대한 공유 SGA로 이해하면 안 됩니다.

10. SQL 요청을 아키텍처에 연결하기

다음 SQL을 Dedicated Server 환경에서 실행한다고 가정합니다.

SELECT customer_name
FROM   customers
WHERE  customer_id = :customer_id;

1. Client가 Service로 접속 요청
2. Listener가 Connection을 Server Process로 중개
3. Server Process가 SQL Parse
4. Shared Pool에서 Cursor·실행계획 확인
5. Buffer Cache에서 필요한 Block 검색
6. Cache Miss이면 Server Process가 Datafile Block을 Buffer Cache로 Read
7. Row 처리 후 Client에 Fetch 결과 반환

DML과 Commit은 다음 요소가 추가됩니다.

UPDATE
→ Buffer Cache의 Current Block 변경
→ Undo 생성
→ Redo Log Buffer에 Redo 생성

COMMIT
→ LGWR가 Commit Redo를 Online Redo Log에 기록
→ Lock 해제와 성공 반환
→ Dirty Block은 이후 DBWn이 Datafile에 기록 가능

11. 혼동하기 쉬운 판단

12. 단계 기반 진단 절차

12.1 Instance가 시작되지 않음

확인 대상
→ SPFILE/PFILE 위치·문법
→ Memory 할당 가능 여부
→ 필수 Background Process 시작 실패
→ Alert Log와 Trace

12.2 STARTED지만 Mount 실패

확인 대상
→ CONTROL_FILES 설정
→ Control File Member 존재·권한·일관성
→ Database 이름·DBID·Control File 상태

12.3 MOUNTED지만 Open 실패

확인 대상
→ Datafile·Online Redo Log 접근 가능성
→ File Header와 Control File Checkpoint 불일치
→ Media Recovery 또는 Instance Recovery 필요 여부
→ Alert Log의 ORA 오류

12.4 CDB는 Open됐지만 Application 접속 실패

확인 대상
→ V$PDBS.OPEN_MODE
→ Service 등록과 Listener 상태
→ 접속 Service Name
→ Restricted Mode

12.5 최종 판단 순서

1. File·Memory·Process 중 무엇의 문제인가?
2. V$INSTANCE.STATUS가 STARTED·MOUNTED·OPEN 중 무엇인가?
3. V$DATABASE.OPEN_MODE는 무엇인가?
4. Multitenant이면 대상 PDB의 OPEN_MODE는 무엇인가?
5. 실패 단계에서 처음 필요한 파일은 무엇인가?
6. Alert Log와 Dynamic Performance View의 증거가 일치하는가?

핵심 정리

Database
→ Datafile·Control File·Online Redo Log의 영속 물리 구조

Instance
→ SGA + Background Processes

NOMOUNT
→ Parameter File, SGA, Background Process, V$INSTANCE.STATUS=STARTED

MOUNT
→ Control File Open, V$INSTANCE.STATUS=MOUNTED

OPEN
→ Datafile·Online Redo Log Open, V$INSTANCE.STATUS=OPEN

Fast Commit
→ LGWR가 Commit Redo를 Durable하게 기록

Instance Recovery
→ Redo Roll Forward + 미Commit 변경 Undo