[Oracle 11gR2] 주기적으로 용량 관리를 해 줘야 하는 파일/디렉토리(로그, 진단데이터 등)
데이터베이스 운영 중 발생하는 갑작스러운 서비스 중단의 주범은 의외로 ‘디스크 공간 부족’인 경우가 많습니다. 특히 오라클은 다양한 진단 로그와 감사 파일을 생성하므로, 아래의 경로들을 정기적으로 점검하고 정리하는 프로세스가 반드시 필요합니다.
| 점검 대상 | 파라미터/명령어 | 비고 |
|---|---|---|
| Audit 파일 | audit_file_dest | .aud 파일들이 무수히 생성됨 |
| 장애 덤프 | diagnostic_dest | adrci 툴로 관리 권장 |
| 네트워크 로그 | lsnrctl status | 리스너 로그 (log.xml) |
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 3.3M ./metadata 4.0K ./metadata_dgif 4.0K ./metadata_pv 4.0K ./stage 4.0K ./sweep 382M ./trace
adrci 명령어를 사용하여 30일(43200분=30*24*60)이 경과한 모든 로그를 삭제합니다.adrci -> show homes 명령어를 실행하면 homepath를 확인할 수 있습니다.$ adrci exec="set homepath diag/rdbms/<db_name>/<SID>; purge -age 43200"
