[Oracle 11gR2] 주기적으로 용량 관리를 해 줘야 하는 파일/디렉토리(로그, 진단데이터 등)
데이터베이스 운영 중 발생하는 갑작스러운 서비스 중단의 주범은 의외로 ‘디스크 공간 부족’인 경우가 많습니다. 특히 오라클은 다양한 진단 로그와 감사 파일을 생성하므로, 아래의 경로들을 정기적으로 점검하고 정리하는 프로세스가 반드시 필요합니다.
| 점검 대상 | 파라미터/명령어 | 비고 |
|---|---|---|
| 감사 파일(Audit Files) | 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 오류가 발생하여 새로운 연결이 불가능해집니다.
- 경로를 확인합니다.
SQL> show parameter audit_file_dest; NAME TYPE VALUE ------------------------------------ ----------- --------------------------------- audit_file_dest string /u01/app/oracle/admin/CMAIN/adump
- Audit 파일이 저장되고 있는 디바이스(마운팅포인트)의 남은 용량을 확인합니다.
$ df -hT /u01/app/oracle/admin/CMAIN/adump
- Audit 파일의 갯수와 용량을 확인합니다. 오라클의 adump 디렉토리는 관리하지 않으면 .aud 파일이 수십만 개씩 쌓이기 때문에
find 명령어와wc 명령어를 사용합니다. du 명령어를 사용해서 Audit 파일의 전체 저장크기를 확인해 봅니다.$ find /u01/app/oracle/admin/CMAIN/adump/ -type f -name "*.aud" > ~/adump.list $ wc -l ~/adump.list $ du -sh /u01/app/oracle/admin/CMAIN/adump
- 일정 기간(30일) 이상 경과한 Audit 파일의 크기를 확인하고, 삭제 여부를 결정한 후 삭제를 진행합니다. 보통 30일~90일 이전 데이터는 백업 후 삭제하는 것을 권장합니다.
$ find /u01/app/oracle/admin/CMAIN/adump -type f -name "*.aud" -mtime +60 -ls | awk '{sum += $7} END {printf "Total Size: %.2f GB\n", sum/1024/1024/1024}' $ find /u01/app/oracle/admin/CMAIN/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 파일들의 저장되는 위치를 확인합니다.
SQL> show parameter diagnostic_dest; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ diagnostic_dest string /u01/app/oracle
- {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 파일과 각종 프로세스 트레이스(.trc, .trm) 파일이 저장됩니다. 용량이 가장 빨리 커지는 곳입니다. trace 폴더에 파일 개수가 너무 많아지면 서버 성능에 영향을 줄 수 있으므로 정기적으로 지워주는 게 좋습니다.
du -sh ./*명령어를 사용해서 디렉토리별 용량을 확인할 수 있습니다.$ du -sh ./* 66M ./alert 4.0K ./cdump 4.0K ./hm 4.0K ./incident 4.0K ./incpkg 4.0K ./ir 4.0K ./lck 4.7M ./metadata 4.0K ./metadata_dgif 4.0K ./metadata_pv 4.0K ./stage 4.0K ./sweep 382M ./trace
adrci 명령어를 사용하여 30일(43200분=30*24*60)이 경과한 모든 로그를 삭제합니다. 파일을 삭제하는 게 아니라 파일 내용 중 30일이 경과한 로그를 삭제하는 것입니다.adrci -> show homes 명령어를 실행하면 homepath를 확인할 수 있습니다.-- XML 형식의 로그만 정리하고 싶을 때는 purge 명령어에 -type ALERT 옵션을 추가합니다. $ adrci exec="set homepath diag/rdbms/<db_name>/<SID>; purge -age 43200 [-type ALERT]" $ du -sh ./* 0 ./alert 0 ./cdump 0 ./hm 0 ./incident 0 ./incpkg 4.0K ./ir 4.0K ./lck 4.7M ./metadata 0 ./metadata_dgif 0 ./metadata_pv 0 ./stage 0 ./sweep 3.9M ./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 }
