[ORACLE] ORA-04030·ORA-27000·ORA-27001·ORA-27002 메모리 이슈

ORA-04030·ORA-27000·ORA-27001·ORA-27002 메모리 관련 이슈 (일반오류형 매뉴얼)

구성: 개요 → 환경 → 증상 → 1차 점검 → 심화 분석 → 복구 → 재발 방지

개요

ORA-04030, ORA-27000, ORA-27001, ORA-27002는 “메모리를 더 할당해야 하는데 실패했다”는 공통 흐름으로 묶이는 경우가 많습니다. 다만 원인은 DB 내부 메모리(PGA/SGA) 부족뿐 아니라 OS 자원 제한(프로세스 제한, ulimit, 공유메모리, tmpfs, swap, 메모리 단편화)이 함께 작동하면서 발생합니다.

핵심 관점
1) DB 파라미터만 늘려도 해결되지 않는 케이스가 많습니다.
2) 같은 “메모리 부족”이라도 누가(어떤 프로세스/세션), 어디에(PGA/SGA/OS 영역), 어떤 순간에(피크 작업) 실패했는지부터 확정해야 합니다.
실무 기준으로 보면, “증상 재현 + OS/DB 동시 스냅샷”이 가장 빠른 길입니다.

환경

아래 항목을 먼저 정리해두면 분석 시간이 크게 줄어듭니다(가능하면 장애 시점/직전 시점 기준).

DB 측

버전/패치 레벨, 인스턴스 메모리 모드(AMM/ASMM/수동), SGA/PGA 설정, 동시 접속/배치 스케줄

OS 측

물리 메모리/스왑, 커널 공유메모리 파라미터, ulimit(프로세스/메모리/오픈파일), /dev/shm(tmpfs) 크기, HugePages 사용 여부

워크로드

피크 시간대 SQL/리포트/ETL, 정렬·해시·병렬 작업 유무, 세션 폭증 이벤트(배치 중첩/장애 재시도)

증상

장애 현장에서 자주 보는 패턴은 다음과 같습니다.

• 특정 배치/리포트/대량 정렬 작업 중 ORA-04030 발생 후 세션이 연쇄 실패
• 인스턴스 기동/증설 시점에 ORA-27000/27001/27002 계열과 함께 OS 에러 메시지가 동반
• 메모리 여유가 “있어 보이는데”도 특정 순간에만 실패(단편화, 공유메모리 한도, tmpfs 부족)

예시 로그 형태(환경에 따라 문구는 달라질 수 있습니다):

ORA-04030: out of process memory when trying to allocate ...
ORA-27000: OS system dependent operation: ... failed with status: ...
ORA-27001: OS system dependent operation: ... failed
ORA-27002: out of memory
Linux-x86_64 Error: 12: Cannot allocate memory

1차 점검

장애 즉시 확인(10~15분 내 가능)
1) OS 메모리/스왑 여유: 급격한 스왑 인/아웃 또는 OOM 흔적이 있는지 확인
2) /dev/shm(tmpfs) 사용량: 공유 메모리/AMM 사용 시 특히 영향
3) ulimit 확인: 프로세스 메모리/가상메모리 제한, 오픈 파일 제한, 프로세스 수 제한
4) DB 동시성 급증: 세션/프로세스 폭증 여부(연결 폭주, 배치 중첩, 재시도 루프)
5) 최근 변경사항: 패치/파라미터 변경/배치 스케줄 변경/리소스 그룹 정책 변경

즉시 완화(서비스 영향 최소화)
- 우선순위 낮은 배치/리포트 중지 또는 동시 실행 제한
- 메모리 급증 SQL(대량 정렬/해시) 임시 제어(작업 분할, 병렬 축소, 피크 시간 회피)
- 서버 메모리 고갈/스왑 폭증이면 “증상만” 막기 위해 재기동을 선택하는 경우도 있으나,
재발 방지를 위해 재기동 전후 스냅샷(메모리/ulimit/파라미터/세션)을 반드시 남겨야 합니다.

심화 분석

1차 점검에서 “진짜 병목 지점”이 어디인지 가닥을 잡았다면, 아래 순서로 범위를 좁힙니다.

A. 프로세스 메모리(PGA) 급증형

정렬(sort), 해시 조인(hash join), 병렬 실행, 대량 집계에서 세션당 PGA가 폭증해 ORA-04030이 발생하는 유형입니다.
확인 포인트: 피크 시간대 대용량 작업/임시 작업 증가, 동시 실행 수, 세션별 메모리 사용 추이.

B. 인스턴스/공유 메모리(SGA·/dev/shm) 제약형

기동 또는 메모리 확장 시점에 공유 메모리 확보가 실패하며 ORA-27000~27002가 동반되는 유형입니다.
확인 포인트: /dev/shm 크기 부족, 공유메모리 커널 한도, HugePages 구성, 메모리 단편화.

C. OS 제한(ulimit·프로세스·가상메모리) 트리거형

물리 메모리는 남아도 “정책/제한” 때문에 할당이 막히는 유형입니다.
확인 포인트: 서비스 계정의 ulimit, systemd/컨테이너 제한, 프로세스 수/메모리 락(lock) 제한.

분석 팁(운영 환경 기준)
- “메모리 여유가 있었는데 왜 실패했나?”는 단편화, 연속 메모리 요구, tmpfs 제한, HugePages/락 정책에서 답이 나오는 경우가 많습니다.
- 관리자 입장에서 가장 위험한 오해는 “DB 파라미터만 키우면 해결”이라고 단정하는 것입니다.

복구

복구는 “원인 유형”에 맞춰 접근해야 합니다. 아래는 현장에서 자주 쓰는 조치들을 유형별로 묶은 것입니다.

1) PGA 급증형 복구

- 피크 작업 동시 실행 제한(배치 스케줄 분산, 큐잉 적용)
- 메모리 집약 SQL 튜닝(불필요한 정렬 제거, 인덱스/조인 전략 개선, 작업 분할)
- PGA 관련 목표치/상한을 운영 정책에 맞게 재조정(급격한 메모리 경쟁 완화)
- 병렬도(parallel) 과다 사용 시 축소 또는 시간대 분리

2) SGA·공유메모리 제약형 복구

- /dev/shm(tmpfs) 크기 및 사용량 점검(AMM/공유메모리 의존 시 필수)
- HugePages 사용 시 페이지 수/락 정책 확인(설정 불일치 시 기동 실패 가능)
- 공유메모리 관련 커널 파라미터 및 OS 정책 재점검
- SGA 확장/변경이 원인이면 변경 전 설정으로 롤백 후 단계적 증설

3) ulimit·정책 제한형 복구

- DB 서비스 계정의 ulimit(가상메모리, memlock, 프로세스 수, 오픈 파일) 상향 조정
- systemd 서비스 유닛/컨테이너 리소스 제한(메모리/프로세스) 확인 및 수정
- 보안 정책(rlimits) 변경 시 재기동이 필요한 항목이 있는지 확인

주의
“즉시 복구”를 위해 메모리를 크게 늘리는 조치는, 다른 워크로드를 압박해 더 큰 장애를 만들 수 있습니다.
실제 사용 시에는 DB/OS 전체 여유와 피크 패턴을 함께 보고 단계적으로 조정하는 것이 안전합니다.

재발 방지

재발 방지 체크리스트(운영 표준화)
1) 피크 작업 관리: 배치 동시성 제한, 대용량 리포트 시간 분리, 재시도 정책(무한 재시도 금지)
2) 모니터링: 세션/프로세스 수, 정렬·임시 작업 증가, 스왑/oom 징후, /dev/shm 사용량 상시 관찰
3) 변경관리: 메모리 파라미터/OS 커널/ulimit 변경은 사전 검증(부하 테스트) 후 반영
4) 가드레일: 서비스 계정 ulimit 표준값 템플릿, systemd/컨테이너 리소스 제한 문서화
5) 장애 재현: 동일 SQL/배치로 재현 환경에서 메모리 사용 패턴을 수치로 확보(“감”이 아니라 데이터로 결론)

결론적으로 ORA-04030, ORA-27000/27001/27002는 단일 원인이라기보다 “DB 메모리 사용 패턴 + OS 자원 한계 + 동시성”의 조합으로 발생하는 경우가 많습니다. 운영 환경에서는 스냅샷 기반으로 원인 유형을 먼저 확정한 뒤, 해당 레이어(DB/OS/워크로드)에 맞춘 조치를 적용하는 것이 가장 재발률이 낮습니다.