이 글은 Oracle Retail에 통합된 ODI 12.2.1.2 환경에서 디스크 부족을 조사한 과거 운영 사례를 정리합니다. 경로와 용량은 이 사례의 구성에 해당하며, 모든 ODI 설치 환경에 공통으로 적용되는 기준은 아닙니다.
당시 스토리지 사용률은 99%에 이르렀습니다. 어떤 파일이 공간을 차지하는지 확인하고, 보관·복구 조건을 검토한 뒤 정리 대상을 정하는 순서로 설명합니다. 현재 환경에서 같은 결과가 나온다고 보장하지는 않습니다.
디스크 여유 공간이 부족하면 데이터 통합 작업이나 로그·백업 파일 쓰기가 실패할 수 있습니다. 실패한 작업과 파일을 확인하고, 저장 공간 부족이 실제 원인인지 로그와 함께 조사합니다.
- 임시 공간 부족으로 인한 데이터 통합 실패
- 로그 파일 쓰기 실패와 장애 진단 자료 누락
- 백업 파일 쓰기 실패 또는 불완전한 백업 생성
- 임시 파일 쓰기 실패나 공간 확보 작업으로 인한 처리 지연
빠른 스토리지 상태 점검 가이드
서버 전체에 여유가 있어도 작업 경로가 있는 파일시스템은 부족할 수 있습니다. 아래 사용량을 볼 때는 실제 작업 경로가 어느 파일시스템에 있는지도 확인하세요.
먼저 파일시스템별 사용량과 남은 공간을 확인합니다.
이 글의 80% 사용률과 20% 여유 공간은 경고 기준의 예시이며, Oracle이 정한 ODI 공통 필수 요건이 아닙니다. 남은 용량뿐 아니라 일별 증가량, 피크 작업의 임시 공간, 백업과 장애 대응 시간을 함께 보고 임계값을 정합니다.
사용률과 함께 아래 변화도 살펴봅니다:
- 환경별 경고 기준 초과(이 글의 예시: 80%)
- 급격한 여유 공간 감소
- 대용량 임시 파일 축적
주요 스토리지 문제 영역
이 사례에서는 RI Stage, RDE, OBIEE 관련 경로를 나누어 사용량을 조사했습니다. 아래 구성도와 20GB·15GB·80GB 수치는 사례 설명용이며, ODI의 표준 디렉토리 구성이나 제품별 필요 용량을 뜻하지 않습니다.
시스템 구성
이 사례는 Oracle Retail 애플리케이션에 통합된 ODI 환경을 다룹니다. RI Stage·RDE 경로와 구성은 당시 설치 환경에 해당합니다.
- 제품: Oracle Retail (Retek) / Oracle Data Integrator
- 버전: ODI 12.2.1.2.0 (Build: ODI_12.2.1.2.0_GENERIC_161008.2132)
- 환경: 프로덕션 서버
- 자세한 시스템 요구사항
RI Stage 영역
이 사례의 RI Stage 영역에는 백업과 설정·로그 파일이 모여 있었습니다. 20GB라는 수치보다 파일별 증가량과 복구에 필요한 보관 범위를 확인하는 것이 중요합니다. 백업의 생성일만으로 삭제 여부를 결정하지 마세요.
RDE 영역
RDE 영역에는 실행에 필요한 미들웨어와 Java 관련 파일이 함께 있었습니다. 설치 파일, 실행 중인 파일과 백업을 구분하고, 서비스가 참조하는 경로를 확인한 뒤 정리 대상을 검토합니다.
OBIEE 애플리케이션 스토리지
OBIEE 관련 경로에서는 미들웨어, 설치 버전과 캐시 파일을 구분해 사용량을 확인합니다. 80GB는 이 사례의 설명값입니다. 오래된 버전처럼 보여도 현재 서비스나 복구 절차가 참조할 수 있으므로 삭제 전에 의존 관계를 확인해야 합니다.
단계별 스토리지 최적화
사용량 조사 → 정리 절차 검증 → 보관 정책 수립 순서로 진행합니다. 공간 확보와 복구 가능성을 함께 확인하는 것이 핵심입니다.
1단계: 문제 영역 분석
정리 전에 경로별 사용량과 파일 종류를 확인합니다. 첫 명령은 수정 시각 조건에 맞는 .log 파일 목록을 정렬하며, 모든 대용량 파일을 찾는 명령은 아닙니다. 두 번째는 디렉토리 사용량을 요약합니다. 경로가 실제 설치 위치와 맞는지 먼저 확인하세요.
1. 수정 시각 조건에 맞는 로그 파일 목록 확인:
find /usr01 -name "*.log" -type f -mtime +30 -ls | sort -k7 | head -20
2. 용량이 큰 디렉토리 찾기:
du -h --max-depth=3 /usr01/oracle/Middleware | sort -rh | head -10
2단계: 정기적 유지보수 구현
아래는 회전된 파일 로그를 압축·삭제하는 기존 예시입니다. 패턴은 .out[0-9]*와 .log[0-9]*이며 모든 .out·.log 파일을 처리하지는 않습니다. +90과 +365는 수정 시각의 경과 일수 조건입니다. 디렉토리 존재 확인만으로 안전한 삭제가 보장되지 않습니다.
실제 경로·파일 목록, 실행 중인 작업, 보관 의무와 복구 가능한 백업을 확인하고 비운영 환경에서 검증하기 전에는 실행하거나 예약하지 마세요.
파일 로그 정리는 ODI work repository의 세션·Load Plan 실행 이력을 정리하는 작업과도 별개입니다.
#!/bin/bash # Oracle ODI 스토리지 관리 자동화 스크립트 # 이 스크립트는 로그 압축 및 삭제를 자동화합니다. TARGET_DIR="/usr01/oracle/Middleware/logs" # 디렉토리 존재 여부 확인 if [ ! -d "$TARGET_DIR" ]; then echo "오류: 디렉토리 $TARGET_DIR가 존재하지 않습니다" exit 1 fi cd "$TARGET_DIR" || exit 1 echo "작업 디렉토리: $TARGET_DIR" # 90일 이상된 로그 압축 find "$TARGET_DIR" -name "*.out[0-9]*" -type f -mtime +90 -exec gzip {} \; find "$TARGET_DIR" -name "*.log[0-9]*" -type f -mtime +90 -exec gzip {} \; # 1년이 지난 압축 로그 삭제 find "$TARGET_DIR" -name "*.out[0-9]*.gz" -type f -mtime +365 -delete find "$TARGET_DIR" -name "*.log[0-9]*.gz" -type f -mtime +365 -delete echo "정리 작업 완료: $TARGET_DIR"
아래 매일 02시 crontab은 예약 표현의 예시입니다. 대상 스크립트의 경로·권한·보관 조건·실패 기록과 알림을 먼저 검증한 뒤 실행 주기를 정합니다.
# 매일 새벽 2시 실행 0 2 * * * /path/to/odi_storage_cleanup.sh
3단계: 스토리지 정책 수립
보관 정책은 복구 목표, 감사 요건과 작업 주기에 따라 정합니다. 아래 30일·90일 예시는 앞선 +90·+365 스크립트와 다른 정책이며, 하나의 공통 설정으로 섞어 적용하지 마세요.
백업 관리
30일 보관·7일 이후 압축은 과거 예시일 뿐 권장 기본값이 아닙니다.
아래 코드는 30일 조건의 .bak·.backup 삭제만 수행하며 압축이나 별도 볼륨 복사를 하지 않습니다.
/*/backup은 여러 경로로 확장될 수 있으므로 실제 대상과 복원 가능 여부를 확인하기 전에는 실행하지 마세요. 별도 볼륨만으로 백업의 안전성이나 복구 가능성이 보장되지는 않습니다.
# 30일 이상된 백업 파일 정리 find /*/backup -name "*.bak" -mtime +30 -delete find /*/backup -name "*.backup" -mtime +30 -delete
로그 순환
- 아래 예시는 수정 시각 +30 조건의 .log를 압축
- 수정 시각 +90 조건의 .gz를 삭제: 필요한 진단 자료와 다른 압축 파일이 포함되는지 확인
- 보관 기간·확장 경로·증가량을 확인한 뒤 적용 여부 판단
# 30일 이상된 로그 압축 find /*/logs -name "*.log" -mtime +30 -exec gzip {} \; # 90일 이상된 압축 로그 삭제 find /*/logs -name "*.gz" -mtime +90 -delete
임시 파일 정리
- 성공한 로드의 스테이징 파일도 재처리·복구 필요 여부부터 확인
- 아래 예시는 /stage 파일의 수정 시각 +30 조건으로 삭제하며, 7일 조건이 아님
- 현재 작업이 참조하는 파일과 실제 대상 목록을 확인한 뒤 별도 승인
# 30일 이상된 임시 파일 제거 find /stage -type f -mtime +30 -delete
스토리지 운영 점검 항목
사전 모니터링
- 80%는 예시: 증가량과 대응 시간을 반영해 경고 기준 설정
- 주간 증가 추세 추적
- 정리 작업 로그 검토
설정 최적화
- 로그 레벨 적절히 조정
- 임시 공간 적절히 구성
- 현실적인 보관 기간 설정
성장 계획
- 20%는 예시: 피크 임시 공간·백업·증가량을 반영해 여유 용량 산정
- 분기별 용량 검토
- 증가 패턴 문서화
자주 하는 실수 피하기
정리 계획을 세울 때 다음 항목을 빠뜨리지 마세요:
- 임시 파일 방치하기
- 데이터 로드 중에 임시 파일이 급격히 쌓일 수 있습니다
- 증가량과 작업 참조 여부를 확인한 뒤 정리 대상을 정합니다
- 불필요한 백업 보관
- 복구·감사 요건을 기준으로 보관 범위를 정합니다
- 오래된 백업도 복구 정책과 복원 검증을 확인한 뒤 정리하세요
- 설정 후 방치
- 정리 작업을 예약한 뒤에도 증가량과 실패 기록을 확인해야 합니다
- 작업량이나 보관 요건이 바뀌면 경고 기준과 정리 주기를 다시 검토합니다
전문가 도움이 필요한 시점
복구 가능 여부나 서비스 의존 관계를 판단하기 어렵다면 담당 DBA·애플리케이션 운영자·스토리지 담당자와 함께 검토해야 합니다. 특히 다음 상황에서는 정리와 용량 확장 계획을 함께 확인하세요:
- 환경별 경고 기준을 계속 초과하거나 작업에 필요한 여유 공간이 부족한 경우(90%는 예시)
- 공간 문제가 자주 발생
- 환경 확장이 필요한 경우
자주 묻는 질문
결론
스토리지 관리는 사용량 분석, 보관 정책과 복구 검증을 함께 다루는 운영 작업입니다. 아래 요약 도표는 관리 목표이며 성능이나 장애 예방을 보장하는 결과표가 아닙니다. 이 사례만으로 현재 환경의 정리 주기와 삭제 안전성을 판단하지 마세요.
추가 리소스
#OracleODI #스토리지관리 #ODI최적화 #OBIEE #시스템운영 #데이터베이스관리 #기술블로그
질문이나 운영 사례를 공유할 때는 ODI 버전, 문제가 생긴 경로와 파일 종류, 증가 추이를 함께 적어 주세요.
이 사례의 삭제 명령이나 보관 기간을 그대로 적용하기보다, 현재 환경의 복구 요건과 실제 정리 대상을 확인하는 데 활용하세요.