ORA-00064 오류 원인과 해결 방법 완벽 가이드

ORA-00064
2026년 05월 22일 | Oracle DBA 가이드

?? 이 글에서 다루는 내용

ORA-00064 에러의 원인 분석, 해결 SQL, 예방 방법을 실무 관점에서 정리합니다.

# ORA-00064: object is too large to allocate on this OS

> 30년 경력 Oracle DBA의 실무 경험을 바탕으로 작성한 트러블슈팅 가이드입니다.

ORA-00064란?

ORA-00064는 Oracle 인스턴스 기동 시 또는 특정 메모리 할당 요청 시, 운영체제(OS)가 해당 객체(주로 SGA 또는 공유 메모리 세그먼트)를 위한 메모리를 할당할 수 없을 때 발생하는 에러입니다. 즉, Oracle이 init.ora 또는 spfile에 설정된 파라미터 값(예: sga_target, processes, sga_max_size 등)에 따라 메모리 자원을 요청했지만, OS 레벨의 커널 파라미터 또는 물리적 메모리 한계로 인해 할당이 거부된 상황입니다. 이 에러는 특히 새로운 Oracle 인스턴스를 처음 기동하거나, 파라미터 변경 후 재기동 시 자주 접하게 되며, DBA라면 반드시 해결 방법을 숙지해야 합니다.

주요 발생 원인

1. OS 커널의 공유 메모리 파라미터(SHMMAX/SHMALL) 설정 부족

가장 빈번한 원인입니다. Linux/Unix 환경에서 Oracle SGA는 공유 메모리(Shared Memory Segment)를 사용하는데, OS 커널 파라미터인 SHMMAX(단일 공유 메모리 세그먼트 최대 크기)나 SHMALL(전체 공유 메모리 페이지 합계)이 Oracle이 요청하는 SGA 크기보다 작게 설정되어 있을 경우 이 에러가 발생합니다. 예를 들어 sga_target=8G로 설정했는데 SHMMAX가 2GB로 제한되어 있다면, OS는 요청을 거부합니다.

2. Oracle 파라미터 값이 물리 메모리(RAM)를 초과하거나 과도하게 설정됨

sga_target, sga_max_size, memory_target, pga_aggregate_target 등의 파라미터 합산 값이 실제 서버에 장착된 물리 메모리를 초과하도록 잘못 설정된 경우에도 이 에러가 발생합니다. 특히 memory_target 또는 memory_max_target을 사용하는 AMM(Automatic Memory Management) 구성에서, /dev/shm(tmpfs) 크기가 memory_target 값보다 작은 경우 Linux 환경에서 이 에러가 빈번하게 발생합니다.

3. processes 파라미터 과도 설정으로 인한 OS 자원 한계 초과

processes 파라미터는 Oracle 인스턴스에 동시에 접속할 수 있는 최대 프로세스 수를 정의하며, 이 값이 매우 크게 설정된 경우 내부적으로 필요한 공유 메모리 구조체(예: 래치, 잠금 구조 등)의 크기도 비례하여 증가합니다. OS의 최대 프로세스 수 제한(kernel.pid_max, ulimit 등)을 초과하거나, 해당 구조체를 위한 메모리 할당이 OS 한계를 넘어설 때 ORA-00064가 발생할 수 있습니다.

해결 방법

원인 1 해결: OS 커널 공유 메모리 파라미터 조정 (Linux 기준)

현재 커널 파라미터 값을 확인하고 Oracle SGA 크기에 맞게 조정합니다.

-- 현재 SGA 관련 파라미터 확인 (Oracle 기동 가능한 경우)
SELECT name, value
FROM v$parameter
WHERE name IN ('sga_target', 'sga_max_size', 'memory_target', 'memory_max_target')
ORDER BY name;

# OS에서 현재 공유 메모리 커널 파라미터 확인
$ ipcs -lm
$ sysctl -a | grep -i shm

# /etc/sysctl.conf 수정 예시 (SGA = 8GB 기준)
# SHMMAX: 단일 세그먼트 최대 크기 (bytes) - SGA보다 크게 설정
# SHMALL: 전체 공유 메모리 총 페이지 수 (page size = 4096 bytes 기준)

$ vi /etc/sysctl.conf

# 아래 값을 추가 또는 수정 (8GB SGA 기준)
kernel.shmmax = 10737418240    # 10GB (bytes)
kernel.shmall = 2621440        # 10GB / 4096 = 2621440 pages
kernel.shmmni = 4096

# 변경사항 즉시 적용
$ sysctl -p

-- spfile에서 SGA 파라미터 조정 (필요 시 줄이기)
-- sqlplus / as sysdba 접속 후 수행

ALTER SYSTEM SET sga_target = 6G SCOPE=SPFILE;
ALTER SYSTEM SET sga_max_size = 6G SCOPE=SPFILE;

-- 변경 후 인스턴스 재기동
SHUTDOWN IMMEDIATE;
STARTUP;

원인 2 해결: AMM 환경에서 /dev/shm 크기 조정 및 파라미터 수정

# /dev/shm 현재 크기 확인
$ df -h /dev/shm

# /dev/shm 크기를 memory_target 이상으로 조정 (예: 12GB)
$ mount -o remount,size=12G /dev/shm

# 영구 적용을 위해 /etc/fstab 수정
$ vi /etc/fstab
# 아래 라인 추가 또는 수정
tmpfs  /dev/shm  tmpfs  defaults,size=12G  0 0

-- AMM 비활성화 후 ASMM으로 전환 (권장)
-- AMM(memory_target) 대신 ASMM(sga_target + pga_aggregate_target) 사용

-- pfile 생성 후 직접 편집
CREATE PFILE='/tmp/init_fix.ora' FROM SPFILE;
-- 에디터로 /tmp/init_fix.ora 열어 아래와 같이 수정
-- memory_target=0
-- memory_max_target=0
-- sga_target=6G
-- pga_aggregate_target=2G

-- 수정된 pfile로 기동
STARTUP PFILE='/tmp/init_fix.ora';

-- 정상 기동 확인 후 spfile 재생성
CREATE SPFILE FROM PFILE='/tmp/init_fix.ora';

-- AMM 완전 비활성화 확인
SELECT name, value
FROM v$parameter
WHERE name IN ('memory_target','memory_max_target','sga_target','pga_aggregate_target');

원인 3 해결: processes 파라미터 적정값 조정

-- 현재 processes 설정 및 실제 사용 현황 확인
SELECT name, value
FROM v$parameter
WHERE name = 'processes';

-- 현재 실제 접속 프로세스 수 확인
SELECT COUNT(*) AS current_processes
FROM v$process;

-- 최대 동시 세션 이력 확인 (AWR 사용 가능 시)
SELECT snap_id,
       instance_number,
       num_lcpus,
       MAX(num_cpus) AS max_cpus
FROM dba_hist_osstat
GROUP BY snap_id, instance_number, num_lcpus;

-- 적정 수준으로 processes 파라미터 조정 예시
-- 일반적으로 (최대 동시 세션 수 * 1.2) + 여유분 으로 설정
ALTER SYSTEM SET processes = 500 SCOPE=SPFILE;

-- OS ulimit 확인 및 조정 (oracle 계정 기준)
-- /etc/security/limits.conf 설정 예시

# oracle 계정 ulimit 확인
$ su - oracle
$ ulimit -a | grep -E "open files|max user processes"

# /etc/security/limits.conf 수정
$ vi /etc/security/limits.conf

oracle  soft  nproc   16384
oracle  hard  nproc   16384
oracle  soft  nofile  65536
oracle  hard  nofile  65536

# 적용 확인 (재로그인 후)
$ ulimit -u

예방 방법

1. Oracle 설치 전/후 OS 커널 파라미터 사전 검증 자동화

Oracle 공식 권고안(Oracle Database Installation Guide)에 명시된 커널 파라미터 최솟값을 기반으로, 인스턴스 기동 전 사전 검증 스크립트를 작성하여 운영 표준으로 채택하는 것이 좋습니다. 아래 스크립트를 cron 또는 Ansible playbook에 통합하면, 파라미터 변경 후 재기동 시 발생할 수 있는 장애를 사전에 차단할 수 있습니다.

#!/bin/bash
# Oracle SGA/커널 파라미터 사전 검증 스크립트

SGA_TARGET_GB=8  # 설정 예정 SGA (GB)
SGA_BYTES=$((SGA_TARGET_GB * 1024 * 1024 * 1024))
PAGE_SIZE=$(getconf PAGE_SIZE)

SHMMAX=$(sysctl -n kernel.shmmax)
SHMALL=$(sysctl -n kernel.shmall)
SHMALL_BYTES=$((SHMALL * PAGE_SIZE))
SHM_DEV=$(df /dev/shm | awk 'NR==2{print $2}')  # KB 단위

echo "=== Oracle 메모리 파라미터 검증 ==="
echo "목표 SGA 크기    : ${SGA_TARGET_GB}GB (${SGA_BYTES} bytes)"
echo "현재 SHMMAX     : ${SHMMAX} bytes"
echo "현재 SHMALL     : ${SHMALL_BYTES} bytes"
echo "/dev/shm 크기   : $((SHM_DEV / 1024 / 1024))GB"

if [ "$SHMMAX" -lt "$SGA_BYTES" ]; then
    echo "[WARNING] SHMMAX가 SGA 크기보다 작습니다. 조정 필요!"
else
    echo "[OK] SHMMAX 설정 정상"
fi

if [ "$SHMALL_BYTES" -lt "$SGA_BYTES" ]; then
    echo "[WARNING] SHMALL이 SGA 크기보다 작습니다. 조정 필요!"
else
    echo "[OK] SHMALL 설정 정상"
fi

-- Oracle 파라미터 변경 이력 관리 쿼리 (변경 전후 비교용)
SELECT name,
       value          AS current_value,
       default_value,
       description
FROM v$parameter
WHERE name IN (
    'sga_target', 'sga_max_size',
    'pga_aggregate_target',
    'memory_target', 'memory_max_target',
    'processes', 'sessions'
)
ORDER BY name;

2. 파라미터 변경 시 반드시 SCOPE=SPFILE 단계적 적용 및 변경 관리 프로세스 수립

운영 환경에서 메모리 관련 파라미터를 변경할 때는 반드시 pfile을 사전에 백업하고, SCOPE=SPFILE로 변경한 뒤 재기동 전에 OS 설정과의 정합성을 다시 한번 검토하는 절차를 변경 관리 프로세스로 문서화해야 합니다. 특히 클라우드(OCI, AWS RDS 제외 EC2 자체 설치 등) 또는 가상화 환경에서는 물리 메모리와 할당 가능 메모리 간의 차이가 존재할 수 있으므로, free -h, vmstat, ipcs -m 명령어를 통한 실시간 메모리 현황 모니터링을 재기동 전 필수 체크리스트로 포함시키는 것을 강력히 권장합니다.

-- 변경 전 현재 spfile 내용 백업
CREATE PFILE='/backup/oracle/pfile_backup_YYYYMMDD.ora' FROM SPFILE;

-- 변경 후 검증을 위한 파라미터 확인
SELECT name, value, ismodified, description
FROM v$parameter
WHERE ismodified != 'FALSE'
ORDER BY name;