ADDM 레포트

[21_장호철]

          '작업_567' 작업에 대한 ADDM 보고서
          ------------------------

분석 기간
-----
AWR 스냅샷 범위는 192 - 193입니다.
25/11/10 14:57:21에서 기간이 시작됩니다.
25/11/10 15:06:48에서 기간이 끝납니다.

분석 대상
-----
'RACDB' 데이터베이스(DB ID 1212824412)입니다.
분석 기간 중 데이터베이스 버전은 19.26.0.0.0이었습니다.
ADDM 실행 시 데이터베이스 버전은 19.0.0.0.0이었습니다.
ADDM에 의해 생성된 모든 권장 사항은 ADDM이 실행된 버전인 데이터베이스 버전 19.0.0.0.0에 대해 적합합니다.
ADDM이 racdb1 인스턴스(1 번호가 매겨지고 rac1에서 호스팅됨)의 분석을 수행했습니다.

분석 기간 중 작업
----------
총 데이터베이스 시간은 1575초입니다.
평균 활성 세션 수는 2.78입니다.

검색 결과 요약
--------
   설명                         활성 세션   권장 사항
                              작업 퍼센트
   -------------------------  ------  -----
1  시퀀스 사용량                    2.69 | 96.711
2  최상위 SQL 문                  2.65 | 95.422
3  예외적인 "Concurrency" 대기 이벤트  2.57 | 92.484
4  상호 접속 대기 시간                .11 | 3.841
5  글로벌 캐시 메시징                 .11 | 3.81


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


          검색 결과 및 권장 사항
          -------------

검색 결과 1: 시퀀스 사용량
영향은 2.69개의 활성 세션, 총 작업의 96.71\%입니다.
-----------------------------------
시퀀스 캐시 실패가 상당한 데이터베이스 시간을 소비했습니다.

   권장 사항 1: 애플리케이션 분석
   예상 이익은 2.69개의 활성 세션, 총 작업의 96.71\%입니다.
   --------------------------------------
   작업
      애플리케이션을 조사하거나 최상위 SQL을 검토하여 작업 중 시퀀스를 찾습니다. 해당 시퀀스에 대해 더 큰 캐시 크기를
      사용하십시오. RAC를 실행하는 경우 ORDER 설정 사용을 피하십시오.


검색 결과 2: 최상위 SQL 문
영향은 2.65개의 활성 세션, 총 작업의 95.42\%입니다.
-----------------------------------
상당한 데이터베이스 시간을 소비하는 SQL 문이 발견되었습니다. 이러한 명령문은 성능 향상을 위한 좋은 기회를 제공합니다.

   권장 사항 1: SQL 튜닝
   예상 이익은 2.56개의 활성 세션, 총 작업의 92.16\%입니다.
   --------------------------------------
   작업
      SELECT 문(SQL_ID "gjxq13ucm559c")에서 성능 향상이 가능한지 조사하십시오. 여기에 제공된 정보를 이
      SQL_ID에 대한 ASH 보고서로 보완할 수 있습니다.
      관련 객체
         SQL_ID가 gjxq13ucm559c인 SQL 문입니다.
         SELECT SEQ_SQ_ENQUEUE.NEXTVAL FROM DUAL
   근거
      SQL은 CPU, I/O 및 클러스터 대기에 데이터베이스 시간의 0%만 보냈습니다. 따라서 SQL 튜닝 권고자는 이 경우에
      해당되지 않습니다. SQL에 대한 성능 데이터를 보고 가능한 성능 향상을 찾으십시오.
   근거
      이 SQL에 대한 데이터베이스 시간 분포: 100% = SQL 실행, 0% = 구문분석, 0% = PL/SQL 실행, 0% =
      Java 실행
   근거
      SQL_ID "gjxq13ucm559c"을(를) 가진 SQL 문이 3000번 실행되었고 평균 경과 시간은 0.5초였습니다.
   근거
      "row cache lock" 이벤트(대기 클래스 "Concurrency")에 대한 대기 시간이 SQL문을 처리하는 데 소요된
      데이터베이스 시간 99%에 고려되었습니다(SQL_ID = "gjxq13ucm559c").

   권장 사항 2: SQL 튜닝
   예상 이익은 .09개의 활성 세션, 총 작업의 3.27\%입니다.
   ------------------------------------
   작업
      SELECT 문(SQL_ID "axmdf8vq7k1rh")에 대해 SQL 튜닝 권고자를 실행하십시오.
      관련 객체
         SQL_ID가 axmdf8vq7k1rh인 SQL 문입니다.
         select increment$,minvalue,maxvalue,cycle#,order$,cache,highwater,aud
         it$,flags from seq$ where obj#=:1
   근거
      SQL은 CPU, I/O 및 클러스터 대기에 데이터베이스 시간 중 100%를 보냈습니다. 데이터베이스 시간 중 일부는 SQL 튜닝
      권고자로 향상시킬 수 있습니다.
   근거
      이 SQL에 대한 데이터베이스 시간 분포: 100% = SQL 실행, 0% = 구문분석, 0% = PL/SQL 실행, 0% =
      Java 실행
   근거
      SQL_ID "axmdf8vq7k1rh"을(를) 가진 SQL 문이 2837번 실행되었고 평균 경과 시간은 0.013초였습니다.


검색 결과 3: 예외적인 "Concurrency" 대기 이벤트
영향은 2.57개의 활성 세션, 총 작업의 92.48\%입니다.
-----------------------------------
대기 이벤트 "row cache lock"(대기 클래스 "Concurrency")이(가) 상당한 데이터베이스 시간을 소비했습니다.

   권장 사항 1: 애플리케이션 분석
   예상 이익은 2.57개의 활성 세션, 총 작업의 92.48\%입니다.
   --------------------------------------
   작업
      "row cache lock" 대기가 높은 원인을 조사하십시오. 이 대기 이벤트에 대한 설명은 Oracle의 "Database
      Reference"를 참조하십시오.
   작업
      "row cache lock" 대기 이벤트에서 많은 시간을 소비하는 SQL 문에 대한 "최상위 SQL 문" 결과를 살펴보십시오.
      예를 들어, SELECT 문(SQL_ID "gjxq13ucm559c")은 이러한 대기의 98%를 차지합니다.

   권장 사항 2: 애플리케이션 분석
   예상 이익은 2.57개의 활성 세션, 총 작업의 92.48\%입니다.
   --------------------------------------
   작업
      "row cache lock" 모듈에서 높은 "sq_enqueue" 대기 원인을 조사합니다.


   권장 사항 3: 애플리케이션 분석
   예상 이익은 2.57개의 활성 세션, 총 작업의 92.48\%입니다.
   --------------------------------------
   작업
      "row cache lock" 서비스에서 높은 "SYS$USERS" 대기 원인을 조사합니다.

   권장 사항 4: 애플리케이션 분석
   예상 이익은 2.57개의 활성 세션, 총 작업의 92.48\%입니다.
   --------------------------------------
   작업
      \"row cache lock\" 대기(P1, P2, P3 (\"cache id, mode, request\") 값 \"13\",
      \"0\" 및 \"5\")가 높은 원인을 각각 조사하십시오.

   검색 결과를 이끈 증상:
   -------------
      대기 클래스 "Concurrency"가 상당한 데이터베이스 시간을 소비했습니다.
      영향은 2.57개의 활성 세션, 총 작업의 92.53\%입니다.


검색 결과 4: 상호 접속 대기 시간
영향은 .11개의 활성 세션, 총 작업의 3.84\%입니다.
---------------------------------
클러스터 상호 접속이 예상보다 많이 지연되어 이 인스턴스에서 상당한 데이터베이스 시간이 소비되었습니다.
인스턴스가 1332Kbps의 상호 접속 대역폭을 소비했습니다.
이 상호 접속 대역폭의 41\%가 전역 캐시 메시징에 사용되었고 병렬 질의 메시징에 39\%, 데이터 잠금 관리에 11\%가 사용되었습
니다.
8K 상호 접속 메시지의 평균 대기 시간은 3049밀리초였습니다.
인스턴스가 전용 상호 접속 장치 "enp0s8:1"(IP 주소 169.254.14.199 및 소스 "NULL")을(를) 사용 중입니다.

   권장 사항 1: 호스트 구성
   예상 이익은 .11개의 활성 세션, 총 작업의 3.84\%입니다.
   ------------------------------------
   작업
      데이터베이스 인스턴스 간의 높은 네트워크 상호 접속 지연 원인을 조사하십시오. Oracle 권장 솔루션은 고속 전용 네트워
크를
      사용하는 것입니다.
   작업
      클러스터 상호 접속 구성을 확인하십시오. 어댑터 설정, 펌웨어 및 드라이버 릴리스와 같은 OS 설정을 확인하십시오. OS의
 소켓
      수신 버퍼 크기가 충분해서 전체 다중 블록 읽기를 저장할 수 있는지 확인하십시오. 해결 방법으로
      "db_file_multiblock_read_count" 매개변수의 값을 줄일 수 있습니다.

   검색 결과를 이끈 증상:
   -------------
      인스턴스간 메시지 전달은 이 인스턴스에서 많은 데이터베이스 시간을 소비했습니다.
      영향은 .11개의 활성 세션, 총 작업의 3.8\%입니다.
         대기 클래스 "Cluster"가 상당한 데이터베이스 시간을 소비했습니다.
         영향은 .11개의 활성 세션, 총 작업의 3.8\%입니다.


검색 결과 5: 글로벌 캐시 메시징
영향은 .11개의 활성 세션, 총 작업의 3.8\%입니다.
--------------------------------
인스턴스간 메시지 전달은 이 인스턴스에서 많은 데이터베이스 시간을 소비했습니다.

   권장 사항 1: 애플리케이션 분석
   예상 이익은 .11개의 활성 세션, 총 작업의 3.8\%입니다.
   -----------------------------------
   작업
      클러스터 대기에서 많은 시간을 소비하는 SQL 문에 대한 "최상위 SQL 문" 결과를 살펴보십시오. 예를 들어, SELECT
      문(SQL_ID "axmdf8vq7k1rh")은 분석 기간 중 클러스터 대기의 51%를 차지합니다.

   검색 결과를 이끈 증상:
   -------------
      대기 클래스 "Cluster"가 상당한 데이터베이스 시간을 소비했습니다.
      영향은 .11개의 활성 세션, 총 작업의 3.8\%입니다.



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

          추가 정보
          -----

기타 정보
-----
대기 클래스 "Application"은 데이터베이스 시간을 많이 소비하지 않았습니다.
대기 클래스 "Commit"는 데이터베이스 시간을 많이 소비하지 않았습니다.
대기 클래스 "Configuration"은 데이터베이스 시간을 많이 소비하지 않았습니다.
CPU가 인스턴스 병목 지점이 아닙니다.
대기 클래스 "Network"는 데이터베이스 시간을 많이 소비하지 않았습니다.
대기 클래스 "사용자 I/O"는 데이터베이스 시간을 많이 소비하지 않았습니다.
세션 접속 및 접속 해제 호출은 데이터베이스 시간을 많이 소비하지 않았습니다.
SQL 문의 하드 구문분석은 데이터베이스 시간을 많이 소비하지 않았습니다.