[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 오류가 발생하여 새로운 연결이 불가능해집니다.

  1. 경로를 확인합니다.
    SQL> show parameter audit_file_dest;
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ---------------------------------
    audit_file_dest                      string      /u01/app/oracle/admin/CMAIN/adump
    
  2. Audit 파일이 저장되고 있는 디바이스(마운팅포인트)의 남은 용량을 확인합니다.
    $ df -hT /u01/app/oracle/admin/CMAIN/adump
    
  3. 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
    
  4. 일정 기간(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 파라미터 등)

  1. ADR 파일들의 저장되는 위치를 확인합니다.
    SQL> show parameter diagnostic_dest;
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ------------------------------
    diagnostic_dest                      string      /u01/app/oracle
    
  2. {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 폴더에 파일 개수가 너무 많아지면 서버 성능에 영향을 줄 수 있으므로 정기적으로 지워주는 게 좋습니다.
  3. 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                      
    
  4. 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)시키거나 비워주는 작업이 필요합니다.

  1. 네트워크 로그의 저장경로를 확인합니다. 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
    
  2. (방법 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
    
  3. (방법 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
    }
    

You may also like...

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다