[Oracle 11gR2] 주기적으로 용량 관리를 해 줘야 하는 파일/디렉토리(로그, 진단데이터 등)
데이터베이스 운영 중 발생하는 갑작스러운 서비스 중단의 주범은 의외로 ‘디스크 공간 부족’인 경우가 많습니다. 특히 오라클은 다양한 진단 로그와 감사 파일을 생성하므로, 아래의 경로들을 정기적으로 점검하고 정리하는 프로세스가 반드시 필요합니다.
| 점검 대상 | 파라미터/명령어 | 비고 |
|---|---|---|
| 감사 파일(Audit Files) | audit_trail audit_file_dest |
.aud 파일들이 무수히 생성됨 |
| ADR 진단 데이터 | diagnostic_dest | adrci 툴로 관리 권장 |
| 네트워크 로그 | lsnrctl status | – log.xml: 오라클이 자동으로 관리해 주는 것 같습니다.(?) – listener.log: 별도 관리가 필요합니다. |
| 아카이브 로그 | db_recovery_file_dest 또는 log_archive_dest_n |
“RMAN으로 백업 및 복구하기” 글 참고 (DELETE NOPROMPT ARCHIVELOG ALL …;) |
1. 감사 파일 (Audit Files) 관리
오라클 DB 운영 중에 발생하는 가장 흔하고도 허무한 장애 중 하나가 바로 이 adump 디렉토리 관리를 놓쳐서 발생하는 ‘디스크 풀(Disk Full)’ 또는 ‘아이노드(Inode) 고갈’ 문제입니다. audit 파일 하나당 크기는 수 KB 이하로 작지만, 방치하면 수백만 개의 작은 파일이 쌓여 용량이 남아있어도 ORA-01033 오류가 발생하여 새로운 연결이 불가능해집니다.
- 감사 활성화 모드를 확인합니다.
- NONE (또는 FALSE): 감사를 수행하지 않습니다.(기본값)
- DB (또는 TRUE): 감사 기록을 DB 내부 테이블(SYS.AUD$)에 저장합니다
- OS: 감사 기록을 OS 파일(위에서 다뤘던 ADR 구조 내 adump 등)로 저장합니다.
- DB, EXTENDED: DB 설정에 추가로, 실행된 SQL 문장과 Bind 변수 값까지 모두 기록합니다.
- XML: 감사 기록을 XML 형식의 OS 파일로 저장합니다.
- XML, EXTENDED: XML 설정에 SQL 문장과 Bind 변수 값을 포함하여 기록합니다.
SQL> show parameter audit_trail; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ audit_trail string DB
- 감사 파일 경로를 확인합니다.
데이터베이스 인스턴스 시작(STARTUP), 데이터베이스 인스턴스 종료(SHUTDOWN), SYSDBA 권한을 이용한 접속 및 활동 등도 audit_file_dest 파라미터에 설정된 경로에 “.aud” 파일로 기록됩니다.SQL> show parameter audit_file_dest; NAME TYPE VALUE ------------------------------------ ----------- --------------------------------- audit_file_dest string /path/to/adump
- Audit 파일이 저장되고 있는 디바이스(마운팅포인트)의 남은 용량을 확인합니다.
$ df -hT /path/to/adump
- Audit 파일의 갯수와 용량을 확인합니다. 오라클의 adump 디렉토리는 관리하지 않으면 .aud 파일이 수십만 개씩 쌓이기 때문에
find 명령어와wc 명령어를 사용하여 파일의 갯수를 확인하고, du 명령어를 사용해서 Audit 파일의 전체 저장크기를 확인합니다.$ find /path/to/adump/ -type f -name "*.aud" > ~/adump.list $ wc -l ~/adump.list $ du -sh /path/to/adump
- 일정 기간(30일) 이상 경과한 Audit 파일의 크기를 확인하고, 삭제 여부를 결정한 후 삭제를 진행합니다. 보통 30일~90일 이전 데이터는 백업 후 삭제하는 것을 권장합니다. crontab에 등록하여 주기적으로 삭제할 수 있습니다.
$ find /path/to/adump -type f -name "*.aud" -mtime +60 -ls | awk '{sum += $7} END {printf "Total Size: %.2f GB\n", sum/1024/1024/1024}' $ find /path/to/adump -type f -name "*.aud" -mtime +60 -exec rm {} \;
2. ADR 진단 데이터 (Alert, Trace & Incident)
Oracle 11g 버전부터 도입된 ADR(Automatic Diagnostic Repository) 개념에 의해, 뿔뿔이 흩어져 있던 진단용 파라미터들이 diagnostic_dest라는 하나의 거대한 뿌리 아래로 통합 관리되기 시작하였습니다.(background_dump_dest, core_dump_dest, user_dump_dest 파라미터 등)
- ADR 파일들의 저장되는 위치를 확인합니다. diagnostic_dest 파라미터와 ADR base가 동일해야
adrci 명령어를 사용할 수 있습니다. ORACLE_BASE 환경변수로 설정되어 있지 않거나, ADR base가 다르다면set base /path/to 명령으로 ADR base를 설정해야 합니다. 또는 .bash_profile 파일에 별칭으로 등록하는 방법도 있습니다.SQL> show parameter diagnostic_dest; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ diagnostic_dest string /u02/app/oracle adrci> show base ADR base is "/u02/app/oracle" -- .bash_profile 파일에 별칭으로 등록하는 방법 alias adr='(echo -e "set base /u02/app/oracle\nshow base"; cat) | adrci'
- {diagnostic_dest}/diag/rdbms/<db_name>/<SID>/ 하위 디렉토리에 생성되어, 현황은 아래와 같습니다.
- alert: XML 형식의 로그(log.xml)가 저장됩니다. trace에 있는 텍스트 로그와 내용은 같지만, adrci 툴이나 Enterprise Manager 같은 소프트웨어가 읽기 좋게 구조화된 파일입니다.
- cdump: 오라클 프로세스가 치명적인 오류로 ‘크래시’ 났을 때 생성되는 Core Dump 파일이 저장됩니다. 평소에는 비어 있는 게 좋으며, 파일 하나하나의 용량이 매우 큽니다.
- hm: (Health Monitor)데이터베이스 건강 상태 체크(Health Check) 결과 보고서가 저장됩니다.
- incident: 특정 장애(Incident) 상황에서만 생성되는 상세 덤프 파일들이 담긴 하위 폴더들이 생깁니다.
- incpkg: (Incident Package)오라클 기술지원(SR)을 위해 장애 정보를 하나로 묶은 패키지 파일이 저장됩니다.
- ir: (Incident Repair)장애 발생 시 ‘Data Recovery Advisor’가 분석한 복구 제안 정보가 저장됩니다.
- lck: (Lock)ADR 내의 자원을 동시에 수정하지 못하도록 막는 잠금(Lock) 파일이 생깁니다.
- metadata: ADR 자체를 관리하기 위한 메타데이터 파일(인시던트 목록, 설정 정보 등)이 들어있습니다.
- metadata_dgif
- metadata_pv
- stage: 외부로 보낼 진단 데이터를 임시로 준비하는 장소입니다.
- sweep: 오래된 장애 정보를 정리(Sweep)할 때 임시로 사용하는 데이터가 남습니다.
- trace: alert_<SID>.log 파일과 pmon, dbw0, lgwr, smon과 같은 오라클 백그라운드 프로세스들이 생성하는 트레이스(.trc, .trm) 파일이 저장됩니다. 용량이 가장 빨리 커지는 곳입니다. trace 폴더에 파일 개수가 너무 많아지면 서버 성능에 영향을 줄 수 있으므로 정기적으로 지워주는 게 좋습니다. background_dump_dest 파라미터 값에 자동 업데이트됩니다.
du -sh ./*명령어를 사용해서 디렉토리별 용량을 확인할 수 있습니다.$ du -sh ./* 4.7M ./alert 4.0K ./cdump 4.0K ./hm 7.0M ./incident 4.0K ./incpkg 4.0K ./ir 4.0K ./lck 7.9M ./metadata 4.0K ./metadata_dgif 4.0K ./metadata_pv 20K ./stage 4.0K ./sweep 5.6G ./trace
adrci 명령어를 사용하여 30일(43200분=30*24*60)이 경과한 모든 로그를 삭제합니다. 파일을 삭제하는 게 아니라 파일 내용 중 30일이 경과한 로그를 삭제하는 것입니다.adrci -> show homes 명령어를 실행하면 homepath를 확인할 수 있습니다.-- XML 형식의 로그만 정리하고 싶을 때는 purge 명령어에 -type ALERT 옵션을 사용합니다. -- ./trace 디렉토리의 *.trc, *trm 파일만 삭제하고 싶다면 -type TRACE 옵션을 사용합니다. $ adrci exec="set homepath diag/rdbms/<db_name>/<SID>; purge -age 43200 -type TRACE"
3. 네트워크 로그 (Listener Log)
네트워크 로그는 오라클 파라미터로 관리되지 않으며, 파일 하나가 수 GB 이상 커질 경우 리스너 성능 저하 및 접속 장애를 일으킵니다. 주기적으로 로그를 순환(Rotate)시키거나 비워주는 작업이 필요합니다.
- 네트워크 로그의 저장경로를 확인합니다. listener.log 파일은 {ORACLE_BASE}/diag/tnslsnr/<hostname>/<listener>/trace/ 디렉토리에 생성됩니다.
$ lsnrctl status | grep "Listener Log File" $ find / -type f -name listener*.log -exec ls -hl {} \; 2> /dev/null - (방법 1 – 수작업)lsnrctl 명령어와 mv 명령어를 사용해서 네트워크 로그의 로테이션을 실행합니다.
$ lsnrctl set current_listener <LISTENER_NAME> $ lsnrctl set log_status off $ mv /path/to/log.xml /path/to/log_$(date +%Y%m%d).xml $ mv /path/to/listener.log /path/to/listener_$(date +%Y%m%d).log $ lsnrctl set log_status on
- (방법 2 – 자동화)OS레벨의 로그 로테이션 기능을 사용해서 listener.log를 로테이션합니다.(“logrotate가 어떻게 작동하는지 알아봅시다” 글을 참고하세요)
logrotate -d /etc/logrotate.d/oracle_listener명령을 실행하여 검증합니다.cat /var/lib/logrotate/logrotate.status | grep listener.log명령을 실행하여 로그 로테이션이 되었는지 확인할 수 있습니다.
-- monthly 옵션: 평소에는 한 달 단위로 관리 -- maxsize 128M 옵션: 갑자기 접속 로그가 폭주해서 128MB를 넘기면 즉시 로그 로테이션 -- copytruncate 옵션: 리스너 중단 없이 내용만 비움(핵심) $ vi /etc/logrotate.d/oracle_listener /path/to/listener.log { monthly maxsize 128M rotate 12 missingok notifempty copytruncate extension .log # dateext compress delaycompress }

읽다보니 데이터 관리의 기본이네요. 기사 내용이 데이터베이스 운영 관리에 집중되어 있어 IT 운영자분들 눈높이에 공감가요. 이 글에서도 보듯 디스크 공간 관리가 서버 안정성의 핵심인데, Suplery의 솔루션은 이 부분을 한 번에 해결해 준다니까 관심이 생깁니다. 우리 쪽 바버샵 운영에서도 재고·주문 관리가 산재해 있어 번거로움이 큰데, Suplery의 플랫폼은 재고-주문-온라인 샵을 하나로 묶어 관리 편의성을 높여주죠. 특히 실시간 재고 확인과 자동 주문 예측 같은 기능은 바쁜 매장 운영에 꽤 유용할 것 같아요. Suplery를 통해 전문 뷰티 비즈니스의 프로세스를 표준화하는 게 must-use처럼 느껴집니다. 지금 바로 살펴보면 좋을 것 같아요. 방문 없이도 직관적인 대시보드로 재고를 한눈에 관리하는 경험, 추천드립니다.