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

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

사용 가능한 해결 방법은 다음과 같습니다.

• 건강.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

건강.DB_GUEST.FILESYSTEM.FREE_SPACE

이벤트 이름:

건강.DB_GUEST.FILESYSTEM.FREE_SPACE

이벤트 설명:

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

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

문제 설명:

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

리스크:

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

작업/복구:

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

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

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 유형의 이벤트가 생성됩니다.

문제 설명:

클러스터 준비 스택이 오프라인 상태이거나 실패했습니다.

리스크:

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 축출은 OS 스케줄러 문제이거나 CSS 데몬 내에서 정지된 스레드일 수 있습니다. 검토할 로그 파일에는 Clusterware 경보 로그, cssdagent 로그, cssdmonitor 로그, ocssd 로그, lastgasp 로그, /var/log/messages, CHM/OS 감시자 데이터 및 opatch lsinventory 세부정보가 포함됩니다.

파일 수집에 대한 자세한 내용은 AHF(Autonomous Health Framework) Trace File Analyzer(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 리스너를 통해 데이터베이스에 대한 응용 프로그램 연결이 실패합니다.

작업/복구:

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

INFORMATION 유형의 DOWN 이벤트:

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

CRITICAL 유형의 DOWN 이벤트:

1. SCAN 상태를 확인하고 SCAN 리스너를 재시작합니다.

   • opc 사용자로 VM에 로그인하고 grid 사용자에 대해 sudo에 로그인합니다.

     [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라고 합니다.

문제 설명:

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

리스크:

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

클라이언트 리스너가 모든 노드에서 작동 중지되면 SCAN 또는 VIP를 사용하여 임의의 데이터베이스에 연결하는 응용 프로그램이 실패합니다.

작업/복구:

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

INFORMATION 유형의 DOWN 이벤트:

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

CRITICAL 유형의 DOWN 이벤트:

1. 클라이언트 리스너 상태를 확인하고 클라이언트 리스너를 재시작합니다.

   • opc 사용자로 VM에 로그인하고 grid 사용자에 대해 sudo에 로그인합니다.

     [opc@vm ~] sudo su - grid

   • 노드에서 클라이언트 리스너 상태를 확인합니다.

     [grid@vm ~] srvctl status listener

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

     [grid@vm ~] srvctl start listener

   • 클라이언트 리스너의 작동이 중지된 경우 임의의 노드에서 클라이언트 리스너 상태를 다시 확인합니다. 클라이언트 리스너 failure의 원인을 조사합니다.

     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

이벤트 설명:

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

문제 설명:

데이터베이스 Instance가 다운되었습니다.

리스크:

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

작업/복구:

데이터베이스 Instance를 시작하여 DOWN_CLEARED 이벤트를 수신합니다.

INFORMATION 유형의 DOWN 이벤트:

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

CRITICAL 유형의 DOWN 이벤트:

1. 데이터베이스 상태를 확인하고 다운된 데이터베이스 Instance를 재시작합니다.

   1. oracle 사용자로 VM에 로그인합니다.

   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 추적 파일에 보고되었는지 확인합니다. 최신 EXAchk 보고서, alert.log 발췌 및 손상 오류, 최근 응용 프로그램 기록, 데이터베이스 또는 소프트웨어 변경 사항, 시스템, 클러스터웨어 및 데이터베이스 로그가 포함된 Trace File을 사용하여 동일한 기간 동안 SR(서비스 요청)을 로깅합니다. 이러한 모든 경우에서 TFA 컬렉션을 사용할 수 있어야 하며 SR에 첨부해야 합니다.
2. 복구 권장 사항에 대한 자세한 내용은 Oracle Database 손상 문제 처리에 대한 기본 참고 사항을 참조하십시오.

물리적 손상 또는 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을 사용하여 물리적으로 손상된 하나 이상의 데이터 블록을 복구할 수 있습니다. 또한 실시간 적용과 함께 Active Data Guard를 사용하면 물리적 데이터 손상의 자동 블록 복구가 자동으로 수행될 수 있습니다.

기본 또는 대기 데이터베이스에서 쓰기 손실(ORA-00752, ORA-00753 및 ORA-00600(첫번째 인수 3020 포함)로 인한 논리적 손상의 경우 기본 또는 대기 리두 적용 프로세스에서 감지됩니다. 다음 참고 사항이 유용합니다.

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

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

• 감지된 오류에 대한 자세한 내용은 Oracle Database 손상 문제 처리에 대한 기본 참고 사항을 참조하십시오.
• 기본 데이터베이스에서 대기 및 논리적 손상이 있는 경우 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(문서 ID 2373477.1)를 참조하십시오.

  • 시간별 버킷이 12보다 크면 온라인 리두 로그 크기 조정을 고려하십시오. 크기 조정 단계는 아래 항목 2를 참조하십시오.

• 데이터베이스가 일시적으로 응답하지 않으면 아카이버가 생성된 리두 로그를 따라잡지 못할 수 있습니다.

  • alert.log, $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log에서 "모든 온라인 로그에 아카이브가 필요함"을 확인합니다. 단기간에 여러 이벤트가 가능한 두 가지 솔루션을 나타낼 수 있습니다.
    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. 다음 query를 사용합니다.

        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)에서 중요한 데이터베이스 프로세스가 응답하지 않음을 감지한 경우 이 이벤트가 발생할 수 있습니다.

리스크:

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

작업/복구:

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

• 데이터베이스의 TFA 이벤트에서 ORA-32701, "DIA0 Critical Database Process Blocked" 또는 "DIA0 Critical Database Process As Root" 이벤트 날짜/시간에 해당하는 다음 메시지 패턴을 검토합니다.

  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의 일별 증분 BACKUP이 실패했습니다.

리스크:

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

작업/복구:

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

Oracle 관리 백업의 경우:

• RMAN 출력은 /opt/oracle/dcs/log/<hostname>/rman에서 찾을 수 있습니다.

• 로그에서 Failure를 검토합니다.

  • 백업 위치가 가득 찼거나 네트워킹 문제가 발생한 등 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% 이상에 도달하면 생성됩니다. ASM 디스크 그룹 공간 사용량이 90% 미만으로 떨어지면 INFORMATION 유형의 이벤트가 생성됩니다.

문제 설명:

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. 데이터베이스에서 사용되지 않은 데이터 파일 및 임시 파일을 삭제합니다. 자세한 내용은 데이터 파일 삭제를 참조하십시오.

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

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