데이터베이스 서비스 이벤트에 대한 해결

이 문서에서는 데이터베이스 서비스 이벤트를 사용하는 동안 발생한 문제에 필요한 수정 사항에 대해 설명합니다.

다음과 같은 해결 방법을 사용할 수 있습니다.

• HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE
• AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN
• AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION
• AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN
• AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN
• AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN
• HEALTH.DB_CLUSTER.CDB.CORRUPTION
• HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG
• HEALTH.DB_CLUSTER.CDB.DATABASE_HANG
• HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE
• HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

이벤트 이름

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

이벤트 설명

이 이벤트는 다음 파일 시스템에 대한 운영체제 df(1) 명령의 결정에 따라 VM 게스트 파일 시스템 사용 가능 공간이 10% 미만으로 떨어질 때 보고됩니다.

• /
• /u01
• /u02
• /var
• /tmp

문제 설명문

하나 이상의 VM 게스트 파일 시스템에 사용 가능한 공간이 10% 미만입니다.

위험

VM 게스트 파일 시스템 여유 공간이 부족하면 디스크 공간 할당 실패가 발생할 수 있으므로 Oracle 소프트웨어(데이터베이스, Clusterware, 클라우드 툴링)에서 광범위한 오류 및 오류가 발생할 수 있습니다.

조치/복구

Oracle Cloud 및 DCS 에이전트는 자동으로 실행되어 파일 시스템 공간을 회수하기 위해 클라우드 툴로 생성된 이전 로그 파일 및 추적 파일을 비웁니다.

자동 파일 시스템 공간 재생 유틸리티가 이 이벤트를 지우기 위해 이전 파일을 충분히 비울 수 없는 경우 다음 작업을 수행합니다.

1. 수동으로 또는 고객이 설치한 응용 프로그램이나 유틸리티에서 만든 불필요한 파일 및/또는 디렉토리를 제거합니다. 고객이 설치한 소프트웨어에서 만든 파일은 Oracle의 자동 파일 시스템 공간 회수 유틸리티의 범위를 벗어납니다. root 사용자로 실행되는 다음 운영 체제 명령은 과도한 디스크 공간을 사용하는 디렉토리를 식별하는 데 유용합니다.

   sudo du -hx <file system mount point> | sort -hr

   확실한 파일 또는 디렉토리만 안전하게 제거할 수 있습니다.

2. 클라우드 툴링을 사용하여 자동 비우기 정책을 설정합니다. 자세한 내용은 Autologcleanpolicy Commands을 참조하십시오.
3. 파일 시스템 공간 사용 감소에 대한 추가 지침을 받으려면 서비스 요청을 개설하십시오.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

이벤트 이름

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

이벤트 설명

CRS(Cluster Ready Service)가 작동 중지된 것으로 감지되면 CRITICAL 유형의 이벤트가 생성됩니다.

문제 설명문

Cluster Ready Stack이 오프라인 상태이거나 실패했습니다.

위험

CRS가 노드에서 오프라인이면 노드가 응용 프로그램에 대한 데이터베이스 서비스를 제공할 수 없습니다.

조치/복구

1. 계획된 유지 관리 이벤트의 일부로 관리자가 CRS를 중지했는지 또는 로컬 스토리지의 스케일 업 또는 다운되었는지 확인합니다.
   1. 다음 패치 적용 이벤트로 CRS가 정지됩니다.
      1. GRID 업데이트
      2. 고객 업데이트
      3. 호스트 업데이트
2. CRS가 예기치 않게 중지된 경우 crsctl check crs 명령을 실행하여 현재 상태를 확인할 수 있습니다.
   1. 노드가 응답하지 않을 경우 VM 노드가 재부트 중일 수 있습니다. 노드 재부트가 완료될 때까지 기다리십시오. 일반적으로 CRS는 init 프로세스를 통해 시작됩니다.
3. CRS가 여전히 작동 중지 상태인 경우 /u01/app/grid/diag/crs/<node_name>/crs/trace에 있는 alert.log를 참조하여 실패 원인을 조사합니다. 작동 중지 이벤트의 날짜/시간에 해당하는 로그 항목을 검토하고 잠재적 해결 조치를 취합니다.
4. crsctl start crs 명령을 실행하여 CRS를 다시 시작합니다.
5. CRS를 성공적으로 재시작하면 지우기 이벤트 AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED가 생성됩니다.

정산 이벤트

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

정산 이벤트 설명

CRS가 성공적으로 시작되면 INFORMATION 이벤트가 생성됩니다.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

이벤트 이름

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

이벤트 설명

CRS(Cluster Ready Service)가 클러스터에서 노드를 비울 때 CRITICAL 유형의 이벤트가 생성됩니다. CRS alert.log는 클러스터에서 노드가 제거되고 있음을 나타내는 CRS-1632 오류에 대해 구문 분석됩니다.

문제 설명문

Oracle Clusterware는 중요한 문제가 감지될 경우 클러스터에서 하나 이상의 노드를 제거하여 노드 축출을 수행하도록 설계되었습니다. 중요한 문제는 네트워크 하트비트를 통해 응답하지 않는 노드, 디스크 하트비트를 통해 응답하지 않는 노드, 정지되었거나 심각하게 저하된 시스템 또는 정지된 ocssd.bin 프로세스일 수 있습니다. 이 노드 축출의 목적은 비정상 멤버를 제거하여 클러스터의 전체 건전성을 유지하는 것입니다.

위험

축출된 노드를 재시작하는 데 걸리는 시간 동안 노드가 응용 프로그램에 대한 데이터베이스 서비스를 제공할 수 없습니다.

조치/복구

CRS 노드 축출은 OCSSD(일명 CSS 데몬), CSSDAGENT 또는 CSSDMONITOR 프로세스로 인해 발생할 수 있습니다. 이를 위해서는 노드 축출 및 관련 로그 파일 검토를 담당하는 프로세스를 결정해야 합니다. OCSSD 축출의 일반적인 원인은 네트워크 장애/대기 시간, CSS 선호 디스크의 IO 문제, 멤버 종료 에스컬레이션입니다. CSSDAGENT 또는 CSSDMONITOR 축출은 CSS 데몬 내에서 OS 스케줄러 문제 또는 정지된 스레드일 수 있습니다. 검토할 로그 파일에는 clusterware 경보 로그, cssdagent 로그, cssdmonitor 로그, ocssd 로그, lastgasp 로그, /var/log/messages, CHM/OS 감시자 데이터 및 opatch lsinventory 세부정보가 포함됩니다.

파일 수집에 대한 자세한 내용은 AHF(자율운영 건전성 프레임워크) TFA(추적 파일 분석기) 및 ORAchk/EXAchk를 참조하십시오. CRS 노드 축출 문제 해결에 대한 자세한 내용은 Troubleshooting Clusterware Node Evictions (Reboots)을 참조하십시오.

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

이벤트 이름

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

이벤트 설명

DOWN 이벤트는 SCAN 리스너의 작동이 중지될 때 생성됩니다. 이 이벤트는 Server Control Utility(srvctl) 또는 Listener Control(lsnrctl) 명령 또는 Grid Infrastructure 소프트웨어 업데이트 수행과 같이 해당 명령을 사용하는 Oracle Cloud 유지 관리 작업과 같은 사용자 작업으로 인해 SCAN 리스너가 종료된 경우의 INFORMATION 유형입니다. SCAN 리스너가 예기치 않게 다운될 때의 이벤트 유형은 CRITICAL입니다. 해당 DOWN_CLEARED 이벤트는 SCAN 리스너가 시작될 때 생성됩니다.

LISTENER_SCAN[1,2,3]이라는 클러스터당 세 개의 SCAN 리스너가 있습니다.

문제 설명문

SCAN 리스너의 작동이 중지되어 응용 프로그램 연결을 허용할 수 없습니다.

위험

모든 SCAN 리스너의 작동이 중지된 경우 SCAN 리스너를 통해 데이터베이스에 대한 응용 프로그램 연결은 실패합니다.

조치/복구

DOWN_CLEARED 이벤트를 수신할 SCAN 리스너를 시작합니다.

INFORMATION 유형의 DOWN 이벤트

1. Grid Infrastructure 소프트웨어 업데이트 수행과 같은 Oracle Cloud 유지보수 작업으로 인해 이벤트가 발생한 경우 필요한 작업이 없습니다. 영향을 받는 SCAN 리스너는 사용 가능한 Instance로 자동으로 failover됩니다.
2. 사용자 작업으로 인해 이벤트가 발생한 경우 다음 기회에 SCAN 리스너를 시작합니다.

CRITICAL 유형의 DOWN 이벤트

1. SCAN 상태를 확인하고 SCAN 리스너를 재시작합니다.
   • VM에 opc 유저로 로그인하고 sudo을 grid 유저로 로그인합니다.

     [opc@vm ~] sudo su - grid

   • 노드에서 SCAN 리스너 상태 확인:

     [grid@vm ~] srvctl status scan_listener

   • SCAN 리스너를 시작합니다.

     [grid@vm ~] srvctl start scan_listener

   • 노드에서 SCAN 리스너 상태 재확인: scan_listener가 여전히 작동 중지 상태이면 스캔 리스너 실패의 원인을 조사합니다.
     1. 로그에 표시된 <hostName>에 대해 30분 전과 10분 전의 CRS 및 OS 로그를 모두 수집합니다. 이벤트 페이로드의 시간은 항상 UTC로 제공됩니다. tfactl 모음의 경우 VM 클러스터의 시간대로 시간을 조정하십시오.

        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName> 
            –from "<eventTime adjusted for local vm timezone> - 30 minute " 
            -to "<eventTime adjusted for local vm timezone> + 10 minutes"

     2. SCAN 리스너 문제는 기록됩니다.

        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

이벤트 이름

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

이벤트 설명

클라이언트 리스너의 작동이 중지되면 DOWN 이벤트가 생성됩니다. 이 이벤트는 Server Control Utility(srvctl) 또는 Listener Control(lsnrctl) 명령 또는 Grid Infrastructure 소프트웨어 업데이트 수행과 같이 해당 명령을 사용하는 Oracle Cloud 유지 관리 작업과 같은 사용자 작업으로 인해 클라이언트 리스너가 종료된 경우 INFORMATION 유형입니다. 클라이언트 리스너가 예상치 않게 다운될 때의 이벤트 유형은 CRITICAL입니다. 해당 DOWN_CLEARED 이벤트는 클라이언트 리스너가 시작될 때 생성됩니다.

노드당 하나의 클라이언트 리스너가 있으며 각각 LISTENER라고 합니다.

문제 설명문

클라이언트 리스너의 작동이 중지되어 응용 프로그램 연결을 허용할 수 없습니다.

위험

노드의 클라이언트 리스너가 작동 중지된 경우 노드의 데이터베이스 인스턴스가 응용 프로그램에 대한 서비스를 제공할 수 없습니다.

클라이언트 리스너가 모든 노드에서 다운된 경우 SCAN 또는 VIP를 사용하여 데이터베이스에 연결하는 모든 응용 프로그램은 실패합니다.

조치/복구

DOWN_CLEARED 이벤트를 수신할 클라이언트 리스너를 시작합니다.

INFORMATION 유형의 DOWN 이벤트

1. Grid Infrastructure 소프트웨어 업데이트 수행과 같은 Oracle Cloud 유지보수 작업으로 인해 이벤트가 발생한 경우 필요한 작업이 없습니다. Grid 인스턴스에 영향을 주는 유지 관리가 완료되면 영향을 받는 클라이언트 리스너가 자동으로 재시작됩니다.
2. 사용자 작업으로 인해 이벤트가 발생한 경우 다음 기회에 클라이언트 리스너를 시작합니다.

CRITICAL 유형의 DOWN 이벤트

1. 클라이언트 리스너 상태를 확인하고 클라이언트 리스너를 재시작합니다.
   • VM에 opc 유저로 로그인하고 sudo을 grid 유저로 로그인합니다.

     [opc@vm ~] sudo su - grid

   • 노드에서 클라이언트 리스너 상태 확인:

     [grid@vm ~] srvctl status listener

   • 클라이언트 리스너를 시작합니다.

     [grid@vm ~] srvctl start listener

   • 클라이언트 리스너의 작동이 중지된 경우 노드에서 클라이언트 리스너 상태를 다시 확인합니다. 클라이언트 리스너 실패의 원인을 조사합니다.
     1. tfactl를 사용하여 로그에 표시된 hostName에 대해 30분 전과 10분 전의 CRS 및 OS 로그를 모두 수집합니다. 이벤트 페이로드의 시간은 항상 UTC로 제공됩니다. tfactl 모음의 경우 VM 클러스터의 시간대로 시간을 조정하십시오.

        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName> 
            –from "<eventTime adjusted for local vm timezone> - 30 minute " 
            -to "<eventTime adjusted for local vm timezone> + 10 minutes"

     2. 다음 위치에 있는 리스너 로그를 검토합니다.

        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

이벤트 이름

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

이벤트 설명

DOWN 이벤트는 데이터베이스 Instance의 작동이 중지될 때 생성됩니다. 이 이벤트는 SQL*Plus(sqlplus) 또는 Server Control Utility(srvctl) 명령 또는 데이터베이스 홈 소프트웨어 업데이트 수행과 같이 해당 명령을 사용하는 Oracle Cloud 유지 관리 작업과 같은 사용자 작업으로 인해 데이터베이스 인스턴스가 종료될 때 INFORMATION 유형입니다. 데이터베이스 Instance가 예기치 않게 다운되는 경우 이 이벤트는 CRITICAL 유형입니다. 해당 DOWN_CLEARED 이벤트는 데이터베이스 인스턴스가 시작될 때 생성됩니다.

문제 설명문

데이터베이스 Instance의 작동이 중지되었습니다.

위험

데이터베이스 인스턴스가 작동 중지되었습니다. 그러면 클러스터의 다른 노드에서 데이터베이스 인스턴스를 사용할 수 있을 경우 성능이 저하되거나, 모든 노드의 데이터베이스 인스턴스가 작동 중지된 경우 작동 중지 시간이 완료될 수 있습니다.

조치/복구

DOWN_CLEARED 이벤트를 수신할 데이터베이스 instance를 시작합니다.

INFORMATION 유형의 DOWN 이벤트

1. 데이터베이스 홈 소프트웨어 업데이트 수행과 같은 Oracle Cloud 유지보수 작업으로 인해 이벤트가 발생한 경우 필요한 작업이 없습니다. 인스턴스에 영향을 주는 유지보수가 완료되면 영향을 받는 데이터베이스 인스턴스가 자동으로 재시작됩니다.
2. 사용자 작업으로 인해 이벤트가 발생한 경우 다음 기회에 영향을 받는 데이터베이스 인스턴스를 시작합니다.

CRITICAL 유형의 DOWN 이벤트

1. 데이터베이스 상태를 확인하고 다운된 데이터베이스 Instance를 재시작합니다.
   1. VM에 oracle 유저로 로그인합니다.
   2. 다음과 같이 환경을 설정합니다.

      [oracle@vm ~] . <dbName>.env

   3. 데이터베이스 상태 확인:

      [oracle@vm ~] srvctl status database -db <dbName>

   4. 데이터베이스 인스턴스를 시작합니다:

      [oracle@vm ~] srvctl start instance -db <dbName> -instance <instanceName>

2. 데이터베이스 Instance Failure의 원인을 조사합니다.
   1. 데이터베이스에 대한 TFA(Trace File Analyzer) 이벤트를 검토합니다.

      [oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>

   2. 다음 위치에 있는 데이터베이스 Alert Log를 검토합니다.

      $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

HEALTH.DB_CLUSTER.CDB.CORRUPTION

이벤트 이름

HEALTH.DB_CLUSTER.CDB.CORRUPTION

이벤트 설명

데이터베이스 손상이 기본 또는 대기 데이터베이스에서 감지되었습니다. 데이터베이스 alert.log는 물리적 블록 손상, 논리적 블록 손상 또는 손실된 쓰기로 인한 논리적 블록 손상을 나타내는 특정 오류에 대해 구문 분석됩니다.

문제 설명문

손상으로 인해 응용 프로그램이나 데이터베이스 오류가 발생할 수 있으며, 이 경우 즉시 해결되지 않으면 상당한 데이터 손실이 발생할 수 있습니다.

손상된 블록은 Oracle Database에서 찾으려는 것과 다르게 변경된 블록입니다. 블록 손상은 다음과 같이 물리적 또는 논리적 손상으로 분류할 수 있습니다.

• 매체 손상이라고도 하는 물리적 블록 손상에서는 데이터베이스가 블록을 전혀 인식하지 못합니다. 체크섬은 유효하지 않거나 블록에 모두 0이 포함되어 있습니다. 보다 복잡한 블록 손상의 예로는 블록 헤더와 바닥글이 일치하지 않는 경우를 들 수 있습니다.
• 논리적 블록 손상에서는 블록의 내용이 물리적으로 건전하고 물리적 블록 검사를 통과하지만, 블록이 논리적으로 일관성이 없을 수 있습니다. 논리적 블록 손상의 예로는 잘못된 블록 유형, 잘못된 데이터 또는 리두 블록 시퀀스 번호, 행 피스 또는 인덱스 항목 손상 또는 데이터 딕셔너리 손상이 있습니다.

블록 손상은 또한 블록간 손상과 블록간 손상으로 나눌 수 있습니다.

• 블록내 손상에서는 블록 자체에 손상이 있고, 이는 물리적 블록 손상이거나 논리적 블록 손상일 수 있습니다.
• 블록 간 손상에서는 블록 사이에 손상이 있고, 이는 논리적 블록 손상일 수 있습니다.

Oracle은 alert.log에서 다음 오류를 확인합니다.

• ORA-01578
• ORA-00752
• ORA-00753
• ORA-00600 [3020]
• ORA-00600 [kdsgrp1]
• ORA-00600 [kclchkblk_3]
• ORA-00600 [13013]
• ORA-00600 [5463]

위험

데이터 손상은 하드웨어, 소프트웨어 또는 네트워크 구성 요소로 인해 손상된 데이터를 읽거나 쓰게 될 때 발생합니다. 데이터 손상 정전의 서비스 레벨 영향은 응용 프로그램이나 데이터베이스의 작은 부분(단일 데이터베이스 블록까지)에서 응용 프로그램이나 데이터베이스의 많은 부분(기본적으로 사용할 수 없도록 설정)에 이르기까지 다양합니다. 수정 조치를 즉시 수행하지 않으면 잠재적 작동 중지 시간 및 데이터 손실이 증가할 수 있습니다.

조치/복구

현재 이벤트 알림은 현재 물리적 블록 손상(ORA-01578), 손실된 쓰기(ORA-00752, ORA-00753 및 ORA-00600와 첫번째 인수 3020) 및 논리적 손상(일반적으로 ORA-00600에서 kdsgrp1, kdsgrp1, kclchkblk_3, 13013 또는 5463의 첫번째 인수로 감지됨)에 대해 트리거됩니다.

다음 단계를 수행하는 것이 좋습니다.

1. 이러한 손상이 alert.log 추적 파일에 보고되었는지 확인합니다. alert.log에서 발췌한 최신 EXAchk 보고서와 손상 오류, 최근 응용 프로그램, 데이터베이스 또는 소프트웨어 변경 사항의 내역, 동일한 기간 동안의 시스템, 클러스터웨어 및 데이터베이스 로그를 포함하는 추적 파일을 사용하여 SR(서비스 요청)을 기록합니다. 이러한 모든 경우 TFA 컬렉션을 사용할 수 있어야 하며 SR에 첨부해야 합니다.
2. 복구 권장 사항에 대한 자세한 내용은 Primary Note for Handling Oracle Database Corruption Issues를 참조하십시오.

물리적 손상 또는 ORA-1578 오류의 경우 다음 참고 사항이 도움이 됩니다.

• OERR: ORA-1578 "ORACLE data block corrupted (file # %s, block # %s)" 주 노트(문서 ID 1578.1)
• RMAN을 사용하여 데이터베이스에서 모든 손상된 객체를 식별하는 방법(문서 ID 472231.1)
• ORA-1578/RMAN/DBVERIFY가 보고한 손상된 객체를 식별하는 방법(문서 ID 819533.1)
• Oracle Database 손상 문제 처리에 대한 기본 노트

주:

RMAN을 사용하면 물리적으로 손상된 하나 이상의 데이터 블록을 Recovery할 수 있습니다. 또한 실시간 적용과 함께 Active Data Guard를 사용하면 물리적 데이터 손상에 대한 자동 블록 복구가 자동으로 수행됩니다.

primary 또는 standby database에서 손실된 쓰기(첫번째 인수가 3020인 ORA-00752, ORA-00753 및 ORA-00600)로 인해 발생한 논리적 손상은 primary 또는 standby의 리두 적용 프로세스에서 감지됩니다. 다음 참고 사항이 도움이 됩니다.

• Oracle Database 손상 문제 처리에 대한 기본 노트
• Primary 또는 Standby에 대기 데이터베이스가 있고 쓰기 손상이 손실된 경우 Resolving ORA-00752 or ORA-600 [3020] During Standby Recovery (Doc ID 1265884.1)을 참조하십시오.

논리적 손상(일반적으로 ORA-00600에서 kdsgrp1, kclchkblk_3, 13013 또는 5463 인수를 사용하여 감지됨)

• 감지된 오류에 대한 자세한 내용은 Primary Note for Handling Oracle Database Corruption Issues를 참조하십시오.
• 기본 데이터베이스에 대기 및 논리적 손상이 있는 경우 Resolving Logical Block Corruption Errors in a Physical Standby Database (Doc ID 2821699.1)을 참조하십시오.

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

이벤트 이름

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

이벤트 설명

CDB(컨테이너 데이터베이스)가 활성 온라인 리두 로그를 아카이브할 수 없거나 로그 아카이브 대상에 충분히 빨리 활성 온라인 리두 로그를 아카이브할 수 없는 경우 CRITICAL 유형의 이벤트가 생성됩니다.

문제 설명문

LGWR(로그 기록자)의 로그 버퍼를 온라인 리두 로그에 기록할 수 없기 때문에 CDB RAC Instance가 일시적으로 또는 영구적으로 정지될 수 있습니다. 이는 모든 온라인 로그에 아카이브가 필요하기 때문입니다. 아카이버(ARC)가 하나 이상의 온라인 리두 로그를 아카이브할 수 있게 되면 LGWR는 로그 버퍼를 온라인 리두 로그에 기록하는 작업을 재개할 수 있으며 응용 프로그램의 영향이 줄어듭니다.

위험

아카이버가 일시적으로 응답하지 않으면 데이터베이스 변경 사항을 커밋하려고 시도할 때 응용 프로그램이 잠시 중단되거나 정지될 수 있습니다. 아카이버가 복원되지 않으면 응용 프로그램 프로세스에서 처리 지연이 연장될 수 있습니다.

조치/복구

• 각 스레드/인스턴스에 대한 시간별 빈도를 확인하려면 Script To Find Redolog Switch History and Find Archivelog Size For Each Instances In RAC (Doc ID 2373477.1)를 참조하십시오.
  • 시간당 버킷이 12보다 크면 온라인 리두 로그의 크기 조정을 고려하십시오. 단계 크기를 조정하려면 아래 항목 2를 참조하십시오.
• 데이터베이스가 일시적으로 응답하지 않으면 아카이버가 생성된 리두 로그를 따라잡지 못할 수 있습니다.
  • alert.log, $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log에서 "All online logs need archiving"에 대해 짧은 기간의 여러 이벤트가 두 가지 가능한 해결책을 나타낼 수 있는지 확인합니다.
    1. 스레드당 리두 로그 그룹 수가 4개 미만인 경우 4에 도달하도록 로그 그룹을 더 추가하는 것이 좋습니다. 리두 로그 추가 단계는 아래 item1를 참조하십시오.
    2. 가능한 다른 해결 방법은 리두 로그의 크기를 조정하는 것입니다. 단계 크기를 조정하려면 아래 항목 2를 참조하십시오.
• Data Guard 및 비Data Guard에 대한 크기 조정 지침은 적절하게 온라인 리두 로그 구성을 참조하십시오.
• 각 스레드에 대한 리두 로그 그룹을 추가합니다. 추가 리두 로그는 현재 로그 크기와 같아야 합니다.
  1. 다음 query를 사용합니다.

     select max(group#) Ending_group_number, thread#, 
         count(*) number_of_groups_per_thread, 
         bytes redo_size_in_bytes from v$log group by thread#,bytes

  2. 현재 리두 로그와 동일한 크기를 사용하여 스레드당 하나의 새 그룹을 추가합니다.

     alter database add logfile thread <thread_number> 
         group <max group + 1> ('<DATA_DISKGROUP>') size <redo_size_in_bytes>

• 더 큰 리두 로그를 추가하고 현재 더 작은 리두 로그를 삭제하여 온라인 리두 로그의 크기를 조정합니다.
  1. 다음 query를 사용합니다.

     select max(group#) Ending_group_number, thread#, 
         count(*) number_of_groups_per_thread, 
         bytes redo_size_in_bytes from v$log group by thread#,bytes

  2. 현재 존재하는 각 스레드 number_of_groups_per_thread에 대해 동일한 수의 리두 로그를 추가합니다. new_redo_size_in_bytes는 적절하게 온라인 리두 로그 구성을 기반으로 해야 합니다.

     1. alter database add logfile thread <thread_number> 
            group <max group + 1> ('<DATA_DISKGROUP>') size <new_redo_size_in_bytes>

     2. 원래의 작은 리두 로그를 삭제해야 합니다. 리두 로그의 상태가 비활성인 경우에만 삭제할 수 있습니다. 리두 로그의 상태를 확인하려면 다음을 선택하십시오.

        select group#, thread#, status, bytes from v$log order by bytes, group#, thread#;

        원래의 더 작은 리두 로그 삭제

        alter database drop logfile <group#>;

• 데이터베이스가 응답하지 않으면 기본 로그 아카이브 대상 및 대체 항목이 가득 찰 수 있습니다.
  • RECO 및 DATA 디스크 그룹의 공간 확보에 대한 자세한 내용은 HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE를 참조하십시오.

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

이벤트 이름

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

이벤트 설명

CDB(컨테이너 데이터베이스)에서 프로세스 또는 세션이 응답하지 않을 때 CRITICAL 유형의 이벤트가 생성됩니다.

문제 설명문

차단자 분석기가 응답하지 않는 프로세스 또는 블록을 감지하여 ORA-32701 오류 메시지를 생성했습니다. 또한 진단 프로세스(DIA0)에서 중요한 데이터베이스 프로세스가 응답하지 않음을 감지한 경우 이 이벤트가 발생할 수 있습니다.

위험

응답하지 않는 프로세스 또는 블록은 리소스, 운영 체제 또는 응용 프로그램 코딩 관련 문제를 나타낼 수 있습니다.

조치/복구

세션 블록의 원인을 조사합니다.

• ORA-32701, "DIA0 Critical Database Process Blocked" 또는 "DIA0 Critical Database Process As Root" 이벤트 날짜/시간에 해당하는 메시지 패턴은 데이터베이스에 대한 TFA 이벤트를 검토하십시오.

  tfactl events -database <dbName> -instance <instanceName>

• 다음 위치에서 연관된 alert.log를 검토합니다.

  $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

• ORA-32701의 경우: 오버로드된 시스템으로 인해 진행 속도가 느려질 수 있으며 이는 블록으로 해석될 수 있습니다. 차단기 분석기는 최종 차단기 프로세스를 종료하여 블록 해결을 시도할 수 있습니다.
• DIA0 Critical Database Process 메시지의 경우: 프로세스 및 블록 이유를 나타내는 관련 진단 라인을 검토합니다.

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

이벤트 이름

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

이벤트 설명

v$rman_status 뷰에 FAILED 상태의 CDB 백업이 있는 경우 CRITICAL 유형의 이벤트가 생성됩니다.

문제 설명문

CDB의 일별 증분 백업을 실패했습니다.

위험

백업에 실패하면 백업을 사용하여 데이터베이스를 복원/복구할 수 있는 기능이 손상될 수 있습니다. RPO(Recoverability Point Object) 및 RTO(Recoverability Time Object)에 영향을 줄 수 있습니다.

조치/복구

이벤트 날짜/시간에 해당하는 RMAN 로그를 검토합니다. 이벤트 시간 기록 eventTime은 UTC로, VM의 시간대에 대해 필요에 따라 조정합니다.

Oracle Managed 백업의 경우:

• RMAN 출력은 /opt/oracle/dcs/log/<hostname>/rman에서 찾을 수 있습니다.
• 로그에서 실패를 검토합니다.
  • 백업 위치가 가득 찼거나 네트워킹 문제가 있는 등 RMAN 외의 외부 이벤트로 인해 Failure가 발생한 경우 외부 문제를 해결합니다.
  • 다른 RMAN 스크립트 오류의 경우 진단 로그를 수집하고 서비스 요청을 개설하십시오.

    dbcli collect-diagnostics -h

    Usage: collect-diagnostics [options]
      Options:
        --components, -c
           Supported components: [all, dcs, crs, acfs, asm, db]
           all -- Collects diagnosis for all supported components [all, dcs, crs, acfs, asm, db]
           dcs -- Collects diagnosis for dcs
           crs -- Collects diagnosis for crs
           acfs -- Collects diagnosis for acfs
           asm -- Collects diagnosis for asm.
           db -- Collects diagnosis for db.
           For multiple parameter values, follow the example as "-c c1 c2"
           Default: [dcs]
        --dbNames, -d
           Comma separated database names. Valid only if 'db' or 'all' specified in Components list.
        --endTime, -et
           End time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format
        --help, -h
           get help
        --json, -j
           json output
        --objectstoreuri, -ou
           Pre Authenticated Request URI
        --redaction, -r
           Diagnostic logs redaction. Might take longer time with some components.
        --startTime, -st
        Start time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format

• 문제가 일시적이거나 해결된 경우 새 Incremental 백업을 수행합니다. 자세한 내용은 콘솔을 사용하여 데이터베이스 백업을 참조하십시오.

RMAN을 통해 수행한 고객 소유 및 관리 백업의 경우:

• 백업에 대한 RMAN 로그를 검토합니다.

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

이벤트 이름

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

이벤트 설명

CRITICAL 유형의 이벤트는 ASM 디스크 그룹이 90% 이상의 공간 사용량에 도달하면 생성됩니다. INFORMATION 유형의 이벤트는 ASM 디스크 그룹 공간 사용량이 90% 미만으로 떨어질 때 생성됩니다.

문제 설명문

ASM 디스크 그룹 공간 사용량이 90%를 초과합니다.

위험

ASM 디스크 그룹 공간이 부족하면 데이터베이스 생성 실패, 테이블스페이스 및 데이터 파일 생성 실패, 자동 데이터 파일 확장 실패 또는 ASM 밸런스 조정 실패가 발생할 수 있습니다.

조치/복구

ASM 디스크 그룹 사용된 공간은 ASM instance에 연결된 상태에서 다음 query를 실행하여 결정됩니다.

sudo su - grid
sqlplus / as sysasm

select 'ora.'||name||'.dg', total_mb, free_mb, 
    round ((1-(free_mb/total_mb))*100,2) pct_used from v$asm_diskgroup;

NAME             TOTAL_MB    FREE_MB   PCT_USED
---------------- ---------- ---------- ----------
ora.DATAC1.dg     75497472    7408292      90.19
ora.RECOC1.dg     18874368   17720208       6.11

ASM 디스크 그룹 용량은 다음과 같은 방법으로 늘릴 수 있습니다.

1. VM 클러스터 스토리지의 크기를 조정하여 ASM 디스크 그룹 용량을 더 추가합니다. 자세한 내용은 가상 머신 DB 시스템에 대한 스토리지 스케일 업을 참조하십시오.

DATA 디스크 그룹 공간 사용은 다음과 같은 방법으로 줄일 수 있습니다.

1. 데이터베이스에서 사용되지 않은 데이터 파일 및 임시 파일을 삭제합니다. 자세한 내용은 Dropping Data Files을 참조하십시오.

다음과 같은 방법으로 RECO 디스크 그룹 공간 사용을 줄일 수 있습니다.

1. 불필요한 Guaranteed Restore Point를 삭제합니다. 자세한 내용은 일반 및 보장된 복원 지점 사용을 참조하십시오.
2. FRA(Flash Recovery Area) 외부에서 이미 백업된 아카이브된 리두 로그 또는 데이터베이스 백업을 삭제합니다. 자세한 내용은 빠른 복구 영역 유지 관리를 참조하십시오.

---

제목 및 저작권 정보

Copyright ©2022,2025,

Oracle and/or its affiliates.