[Oracle] Oracle Architecture (5) [물리적 저장 구조]

👇용어정리

닫기

• 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 Physical File

 

 

1. Data Files

"사용자가 생성한 테이블, 인덱스, 그리고 오라클 시스템 정보가 담긴 가장 큰 파일입니다."

• 특징: 우리가 INSERT한 데이터는 결국 이 파일 안에 블록(Block) 단위로 저장됩니다.
• 실무 포인트: 데이터 파일은 테이블스페이스(Tablespace)라는 논리적 단위에 소속됩니다. 용량이 꽉 차면 새 데이터 파일을 추가 하거나 RESIZE 명령으로 늘려줘야 합니다

👇 데이터 파일 공간 확장 3가지 방법

기존 파일 크기 수동 확장(Resize)

ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/DB19/data01.dbf' RESIZE 10G;

 

자동 확장 설정(Autoextend)

SQL> ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/DB19/data01.dbf' AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED;

 

새 데이터 파일 추가

SQL> ALTER TABLESPACE TS_DATA ADD DATAFILE '/u02/app/oracle/oradata/DB19/data02.dbf' SIZE 5G;

 

👉 더 자세한 설명은 다른 게시글에 작성 하겠습니다.

 

2. Control Files

"크기는 작지만, 없으면 DB가 절대로 켜지지 않는 가장 치명적인 파일입니다."

• 내용: DB 이름, 데이터 파일과 리두 로그 파일의 경로, 현재의 SCN(동기화 번호), 백업 정보 등이 담겨 있습니다.
• 실무 포인트: 오라클은 실행 중에도 이 파일을 계속 읽고 씁니다. 만약 이 파일이 깨지면 DB는 즉시 멈춥니다. 그래서 보통 3개 정도로 다중화(Multiplexing)해서 관리합니다.

👇Control File 속 설정값과 상태 정보

1. 데이터베이스 식별 정보 (Identity)

"가장 기본이 되는 정보로, 인스턴스가 '내 몸에 맞는 데이터베이스인가?' 를 확인할 때 씁니다."

• DB Name: DB_NAME 파라미터와 일치하는지 확인합니다.
• DBID: 오라클이 내부적으로 부여한 고유 식별 번호입니다. (복구 시 매우 중요!)
• Timestamp: DB가 처음 생성된 시간 정보입니다.

 

2. 물리적 구조 정보 (Physical Structure)

"오라클이 부팅될 때 '파일들이 어디 있지?'라고 찾아가는 이정표 역할을 합니다."

• Datafiles 목록: 모든 데이터 파일의 절대 경로와 상태, 크기 정보.
• Redo Log Files 목록: 리두 로그 그룹과 각 멤버 파일들의 경로 정보.
• Tablespace 정보: 어떤 테이블스페이스가 존재하고 어떤 파일과 연결되어 있는지의 지도.

 

3. 동기화 및 관리 정보 (Synchronization)

"DB의 무결성을 증명하는 가장 중요한 '도장'들입니다."

• Checkpoint SCN: 가장 최근에 성공한 체크포인트 번호. (이게 데이터 파일 헤더와 맞아야 OPEN 됩니다.)
• Log Sequence Number: 현재 몇 번 리두 로그를 쓰고 있는지에 대한 순서 번호.
• Archive Log 기록: 어떤 리두 로그가 아카이브로 복사되었는지에 대한 히스토리.

 

4. 백업 및 RMAN 정보 (Backup Metadata)

"RMAN을 쓰신다면 이 정보가 컨트롤 파일의 상당 부분을 차지합니다."

• Backup Sets / Pieces: 언제 어떤 파일이 백업되었는지에 대한 위치와 시간.
• Datafile Copy 정보: 사용자가 수동으로 복사해둔 데이터 파일 정보.
• RMAN Configuration: RMAN의 기본 설정값들(보관 주기 등).

👇 Control File이 사용되는 DB 기동(Startup) 3단계

컨트롤 파일이 사용되는 "결정적 순간" (Startup 3단계)

 

 DB를 켤 때 STARTUP 명령어를 날리면 3단계를 거치는데 이때 컨트롤 파일의 위력이 나타납니다.

• NOMOUNT: 파라미터 파일(spfile)만 읽고 메모리(SGA)만 올린 상태. (컨트롤 파일 아직 안 읽음)
• MOUNT (중요!): 드디어 컨트롤 파일을 읽는 단계입니다. 여기서 파일 경로를 파악하고 DB 이름을 대조합니다. 컨트롤 파일이 없거나 깨지면 여기서 딱 멈춥니다.
• OPEN: 컨트롤 파일에 적힌 경로대로 실제 데이터 파일들을 찾아가서 SCN을 대조하고 문제가 없으면 DB를 엽니다.

 

3. Redo Log Files

"데이터에 일어난 모든 변화를 시간 순서대로 기록하는 파일입니다."

• 내용: 로그 멤버가 최소 2개 이상의 로그 그룹으로 같은 그룹 안에 멤버 로그들은  "A 유저가 10번 로우를 '사과'에서 '포도'로 바꿨음" 같은 기록을 동시에 똑같이 기록을 담습니다.
• 실무 포인트: 최소 2개 이상의 그룹이 필요하며, 순환(Round-Robin) 방식으로 사용됩니다. 정전 시 SMON이 이 파일을 읽어 메모리 내용을 복구합니다.

👇 Redo Log File 동작 원리

1. 순환 방식 (Round-Robin)과 로그 스위치 (Log Switch)

 

"리두 로그는 무한정 커지는 파일이 아니라, 정해진 크기를 돌려쓰는 구조입니다."

1. Writing: 1번 그룹이 꽉 찰 때까지 LGWR이 Redo Log Buffer에 기록합니다.
2. Log Switch: 1번이 다 차면 2번 그룹으로 넘어갑니다. 이때 발생하는 이벤트를 Log Switch라고 합니다.
   • redo01.log → redo02.log로 작성 대상도 함께 Switch
3. Checkpoint & Archive: 2번으로 넘어가자마자 두 가지 일이 동시에 일어납니다.
   • CKPT: "1번 그룹에 있던 내용을 이제 데이터 파일에 다 적어라!" (체크포인트 발생)
   • ARCH: "1번 그룹 내용을 아카이브 로그 파일로 복사해둬!" (아카이브 모드일 경우)
4. Reuse: 마지막 그룹까지 다 쓰면 다시 1번으로 돌아와 내용을 덮어씁니다.

 

4. Parameter File (PFILE / SPFILE): DB의 "시동 키"

오라클 인스턴스가 시작될 때 "메모리는 얼마나 쓸지, 프로세스는 몇 개나 띄울지" 결정하는 설정 파일입니다.

• PFILE (initSID.ora): 텍스트 형식(Text)이라 메모장으로 수정이 가능하고 DB 재시작 후 반영합니다.
• SPFILE (spfileSID.ora): 이진(Binary) 형식으로, DB 실행 중에 ALTER SYSTEM 명령으로 설정을 바꿀 수 있고 설정에 따라 즉시 또는 재시작 후 반영합니다. (요즘은 대부분 SPFILE을 씁니다.)

👇실무 포인트 및 Parameter File 주요 설정값

1. SPFILE의 강력한 기능: SCOPE 옵션

 

"실무에서 SPFILE을 쓰는 가장 큰 이유는 DB를 끄지 않고도 설정을 바꿀 수 있기 때문입니다. 이때 SCOPE 옵션 3가지를 꼭 기억해야 합니다."

• SCOPE=MEMORY: 현재 작동 중인 인스턴스에만 즉시 반영 (DB 끄면 초기화됨).
• SCOPE=SPFILE: 파일에만 기록해두고, 다음번 DB 재시작 때부터 반영. (정적 파라미터 수정 시 사용)
• SCOPE=BOTH (기본값): 현재 인스턴스에도 즉시 반영하고, 파일에도 기록해서 다음 부팅 때도 유지.

 

3. "어떤 파일이 먼저 읽히나요?" (우선순위)

" STARTUP 명령을 내리면 오라클은 정해진 순서대로 파일을 찾습니다."

1. spfile[SID].ora (가장 먼저 찾음)
2. spfile.ora (없으면 찾음)
3. init[SID].ora (PFILE, 마지막 보루)

꿀팁: 만약 SPFILE 설정 오류로 DB가 안 켜진다면? SPFILE을 PFILE로 변환해서 텍스트로 수정한 뒤 다시 켜면 됩니다! (CREATE PFILE FROM SPFILE;)

 

4. 파라미터 파일에 담긴 주요 설정값

1. 메모리 관련 (SGA/PGA)

• SGA_TARGET: SGA(Shared Pool, Buffer Cache 등)의 전체 크기를 설정합니다. 0보다 크게 설정하면 오라클이 알아서 세부 메모리를 배분합니다 (ASMM).
• PGA_AGGREGATE_TARGET: 모든 세션이 사용하는 정렬(Sort) 및 해시(Hash) 작업용 메모리의 합계입니다.
• MEMORY_TARGET: SGA와 PGA를 통틀어 전체 메모리를 오라클이 관리하게 합니다 (AMM).

2. 세션 및 프로세스 (Sessions/Processes) 

• PROCESSES: 오라클이 운영체제(OS)에서 띄울 수 있는 최대 프로세스 수입니다. (백그라운드 프로세스 포함)
• SESSIONS: 동시 접속 가능한 세션 수입니다. 보통 (1.1 * PROCESSES) + 5 정도로 자동 설정되지만, 직접 지정하기도 합니다.
• DB_WRITER_PROCESSES: 우리가 배운 DBWn의 개수입니다. 데이터 변경이 많은 대용량 DB라면 이 숫자를 늘려 쓰기 성능을 높입니다.

3. 파일 및 경로 (File Locations)

• CONTROL_FILES: 컨트롤 파일의 경로들입니다. (반드시 2~3개 이상 다중화 경로를 적어줍니다.)
• DB_RECOVERY_FILE_DEST: 아카이브 로그나 백업 파일이 저장되는 **FRA(Fast Recovery Area)**의 경로입니다.
• LOG_ARCHIVE_DEST_n: 아카이브 로그를 저장할 경로를 최대 31개까지 지정할 수 있습니다.

4. 성능 및 튜닝 (Performance) 

• DB_BLOCK_SIZE: DB의 최소 단위인 블록 크기(보통 8KB). 이 값은 DB 생성 후 절대 바꿀 수 없으므로 처음에 잘 정해야 합니다.
• UNDO_RETENTION: 커밋된 언두 데이터를 얼마나 오랫동안 유지할지(초 단위) 설정합니다. Flashback 기능이나 긴 쿼리의 ORA-01555 방지에 중요합니다.
• OPTIMIZER_MODE: 쿼리를 실행할 때 '전체 응답 속도'를 중시할지, '첫 번째 행이 나오는 속도'를 중시할지 결정합니다.

---

💡 시나리오로 감 잡기

1. DB가 켜지질 않아요 (ORA-00205)

• 상황: 점검 후 DB를 올리려고 startup 명령을 내렸는데, NOMOUNT 단계는 통과했지만 MOUNT 단계에서 에러가 나며 멈췄습니다.

👇원인과 해결

• 원인: Control File을 찾지 못했기 때문입니다. 오라클은 MOUNT 단계에서 컨트롤 파일을 읽어 데이터 파일들의 위치를 파악하는데, 이 파일이 없으니 다음 단계로 진행을 못 하는 것입니다.
• 해결: spfile에 적힌 컨트롤 파일 경로가 맞는지 확인하고, 유실되었다면 백업본으로 복구해야 합니다.

 

2. 메모리 설정을 잘못 바꿨어요!

• 상황: SGA 크기를 너무 크게 설정하고 scope=spfile로 적용한 뒤 재부팅했는데, 메모리 부족으로 DB가 아예 뜨지 않습니다. spfile은 바이너리라 수정도 안 되네요!

👇원인과 해결

• 원인: SPFILE은 직접 수정이 불가능하기 때문에 발생한 전형적인 실수입니다.
• 해결: 정상이었던 시절의 PFILE이 있다면 그것으로 startup pfile='...'을 시도하거나, SPFILE에서 PFILE을 추출(Create pfile from spfile)하여 값을 수정한 뒤 다시 올려야 합니다.

 

3. 컨트롤 파일이 담긴 디스크가 깨졌을 때

• 상황: STARTUP을 날렸는데 ORA-00205: error in identifying control file 에러가 뜨며 MOUNT단계에서 DB가 켜지지 않습니다.

👇원인과 해결

 

• 원인: DB의 지도 역할을 하는 Control File이 물리적인 디스크 오류로 손상되었습니다.
• 해결: 다중화(Multiplexing)의 힘을 발휘할 때입니다. 파라미터 파일(SPFILE)에 등록된 다른 경로의 살아있는 컨트롤 파일을 복사해서 깨진 위치에 갖다 놓거나, 파라미터 파일의 경로 설정을 살아있는 파일 쪽으로 수정해서 다시 켭니다.

 

 

4. 로그 스위치가 안 일어나서 DB가 멈췄을 때

• 상황: 대량의 데이터를 INSERT 중인데 어느 순간 DB가 응답하지 않습니다. alert log에 Checkpoint not complete 메시지가 가득합니다.

👇원인과 해결

• 원인: Redo Log File 1번이 꽉 차서 2번으로 넘어가야 하는데(Log Switch), 아직 2번의 내용이 Data File에 다 안 적혀서(Checkpoint) 덮어쓸 공간이 없는 상태입니다.
• 해결: DBWn이 더 빨리 일할 수 있도록 리두 로그 파일의 크기를 키우거나 그룹 개수를 늘려줍니다. 혹은 디스크 성능을 체크합니다.