pat98's always & forever

19c RAC로 올린 이후 Log File Sync wait event가 증가하는 사례

• 현상
➢ RAC 19c로 upgrade 이후에 LGWR process가 Log File Sync 로 대기 및 RDBMS IPC message wait event가 급격히 증가하는 이슈
➢ AWR 정보에서 "redo write broadcast ack time"이 증가하는 증상으로 현상 파악
➢ LGWR에 의해서 SCN ACK messages가 delayed completion되면서 대기 시간이 늘어나는 문제
➢ LGWR 트레이스 파일에 ‘Warning: log write broadcast wait time xxx ms’ 메시지가 나타남

• 원인
➢ OS Watcher report를 분석했을 때 OS 단에서 IO가 지연되는 증상은 없는 경우임
➢ Bug.30614411 - LMS ignoring message handler for SCN broadcast message causing the originating instance to wait very
long for broadcast completion
➢ <Note:2699312.1> Intermittent Long 'log file sync' Waits on 2 Node RAC After Upgrading to 19c

• 해결 방안
1. DB RU 19.8 에서 fix되었다고 되어 있으나, 실제 inventory.xml을 보면 19.9 에서 Bug.30614411에 대한 Fix를 포함하고 있음
2. Patch 30614411 적용
3. <Note:2698757.1> Wait Time for Log File Sync Increases on RAC

• 현상
➢ RAC 환경에서 ‘gc buffer busy release’를 오랫 동안 대기하면서 데이터베이스가 hang 걸린것처럼 보이는 현상. 여러 세션에서 ‘gc buffer busy release’ 현상이 나타남
➢ X holder가 존재하는 동안, read-mostly object를 exclusive lock 을 대기하여 session hang 발생

• 원인
➢ Bug.30381614 – RAC Database Sessions Waiting for a Long Time on ‘gc buffer busy release’
➢ <Note:30381614.8> - RAC Database Sessions Waiting for a Long Time on ‘gc buffer busy release’

• 해결 방안
1. Patch 30381614 적용 또는 mostly locking 을 Disable (Workaround)해야 함
2. Mostly locking을 disable하는 방안 : _gc_read_mostly_locking=FALSE
Rolling 방식으로 mostly locking을 disable하기 위한 방안 :
_gc_persistent_read_mostly=FALSE and _lm_drm_disable=4

• 현상
➢ Rare case에서 모든 노드의 DBWR process가 terminate되어 인스턴스 crash 발생
➢ DLM(Dynamic Lock Manager)의 노드 간 메시지 전송 수행 중에 message sequence가 UB2를 overflow하면서 DBWR process가 down되어 인스턴스 crash 발생

• 원인
➢ Bug.32097882 All Instances Restarted by Database Writer: Instance Terminated by DBW0
➢ <Note:32097882.8> - Bug.32097882 All Instances Restarted by Database Writer: Instance Terminated by DBW0

• 해결 방안
1. Patch 32097882 적용
2. 19.10 이상 DB RU 적용 권고 – 그러나, 19.10 은 현재 권장하지 않으므로, DB RU 19.11 이상 권장

양 노드의 CPU count가 다른 경우에는 성능 저하 방지를 위해 반드시 명시적으로 셋팅

• 정의
✓ RAC 환경에서 LMS 프로세스 갯수를 결정하는 파라미터
✓ 11g R2 이상에서는 기본값: SGA > 100G 인 경우, default * 2를 할당
✓ 하위 버젼에서 상위 버젼으로 업그레이드하는 경우에는 기존값 그대로 유지 , 신규 설치하는 서버의 경우에는 각 버젼에 맞게 버젼 별로 default로 지정되는 자동 할당값을 권고함

• 기준값
✓ Oracle 10g 기준으로는 CPU_COUNT / 4
✓ Oracle 11g 이상 : 2+(CPU_COUNT / 32)

• 권장사항
✓ 노드 별로 동일한 값 설정 : 만약 두 노드의 default 값이 다르다면 높은 값으로 통일하여 설정할 것을 권장
✓ 성능 저하 예방 : <Note:1911398.1> High "gc cr grant 2-way" / "gc current block 2-ay" Wait due to Different CPU Count on Cluster Nodes
✓ 양 노드 간에 CPU_COUNT 값이 서로 달라서 gcs_server_processes 값이 상이하게 잡혀 있는 경우, GC 관련 Wait이 과다하게 발생한 경우, 이 파라미터 값을 똑같이   설정하라는 가이드

• 현상
➢ 11g에서 수행했던 Pro*C 어플리케이션을 19c로 올린 이후 수행 시 오픈 커서가 계속 증가하는 이슈
➢ 19c Upgrade 이후에 동일 세션 id가 cursor를 계속 오픈하게 되는 증상이 발생하여 확인해본 결과 3200개 이상의 cursor가 동일 SQL_ID에 대해서 동일 세션에 대해서 사용 중으로 나오고 있는 증상

• 원인
➢ <Note:29457978.8> Bug.29457978 REF CURSOR Leak In Precompilers 18c Version
➢ 사용 중이던 Pro*C 클라이언트 버젼이 설치 초기 버젼인 19.3 이었음

• 해결 방안
1. 데이터베이스가 설치된 머신은 19.9로 올렸는데 , Pro*C 클라이언트 단에서는 여전히 19.3 을 사용하는 것으로 되어 있어 19.9로 올려서 컴파일한 후 이슈가 해결됨 . DB RU 19.6에서 Fix된 이슈임

2. 오픈된 커서가 계속 증가하여 OPEN_CURSORS 파라미터를 1000에서 2000으로 올려놓았지만, 이것은 근본적인 해결책이 될 수 없음

• 현상
➢ 기본적으로 통계정보를 31일 치를 보관하면서 SM/OPTSTAT의 크기가 증가하는 이슈
➢ 19c Upgrade 이후에는 이전 버젼에 생성된 31일 간 통계정보로 돌아가는 것은 의미가 없고,오랜 기간의 보관 주기를 가지는 것은 디스크 낭비 현상을 야기시키므로, 줄이는 것을 권고

• 해결 방안
1. SM/OPTSTAT에 의해 차지하는 통계정보 백업의 SIZE 확인
SQL> select SPACE_USAGE_KBYTES/1024 MB from V$SYSAUX_OCCUPANTS where OCCUPANT_NAME='SM/OPTSTAT’;

2.통계정보 보관주기 (Retention)에 대한 확인
SQL> select DBMS_STATS.GET_STATS_HISTORY_RETENTION from DUAL;

3. 통계정보 보관주기 축소 (10일 )
SQL> exec DBMS_STATS.ALTER_STATS_HISTORY_RETENTION(10);

• 현상
➢ AUTO_STATS_ADVISOR_TASK가 자동 수행되어 SYSAUX 공간 사용률 증가 가능성 있음
➢ Statistics Advisor : Optimizer Statistics의 수집에 대한 가이드를 분석 리포팅해주는 Tool
➢ 12.2.0.1 이후 Statistics Advisor가 자동으로 활성화되어 SYSAUX 사용률 증가 및 CPU 사용률 증가
➢ 수동으로도 수행 가능하므로, 자동으로 수행되지 않도록 할 수 있음

• 해결 방안
1. Patch 적용 : patch 26749785 : PERF_DIAG: NEED TO HAVE MORE CONTROL IN DICTIONARY FOR
AUTO_STATS_ADVISOR_TASK

2. Disable 방안 : SQL> exec dbms_stats.set_global_prefs('AUTO_STATS_ADVISOR_TASK','FALSE’);

3. 확인 방법 : 패치를 적용해야 확인 가능함
SQL> select dbms_stats.get_prefs('AUTO_STATS_ADVISOR_TASK') from dual;
DBMS_STATS.GET_PREFS('AUTO_STATS_ADVISOR_TASK’)
--------------------------------------------------------------------------------
FALSE
➢ 참고 : <Note:2686022.1> How to disable Optimizer Statistics Advisor from 12.2 Onwards.
➢ https://mikedietrichde.com/2017/08/22/oracle-optimizer-statistics-advisor-in-oracle-database-12-2-0-1/

• 현상
➢ DB에 로그인하는 USER 수가 많은 시스템에서 신규 세션 로그인 시 Library Cache Lock waiting
➢ USER$ update 문이 “gc cr request” 또는 “kjc wait” event로 주로 대기하면서 신규 세션 로그인 불가
➢ Oracle DB 12.2.0.1. 이상 RAC에서 데이터베이스 workload와 초당 로그인이 많이 발생하는 경우 발생

• 원인
➢ 12c New Feature : SYS.USER$의 SPARE6 컬럼에 “Last Successful Login Time” 기록
➢ Bug 33121934 - Library cache lock / load lock / mutex x during connection storm (Doc ID 33121934.8)

• 해결 방안
1. USER$에 DBA_USER의 LAST_LOGIN을 기록하지 않도록 하는 방안
PATCH 33121934 적용

2. 패치 적용 후, parameter _disable_last_successful_login_time = TRUE 적용 권고
Bug 32164034 - Database Hang Updating USER$ When LSLT (LAST SUCCESSFUL LOGIN TIME) Is Enabled
(Doc ID 32164034.8)

• 현상
➢ MGA 래치란? 오라클 프로세스 간의 주소 공간을 공유할 수 있도록 하기 위해 12.2부터 등장한 heap 메모리 영역으로 주로 Parallel query slave들이 동적으로 메모리를 할당하여 프로세스들 간에 통신하는 용도로 사용됨 . (parallel query)
➢ 프로세스들은 필요한 기간 동안 MGA heap memory의 Name space라고 하는 영역에 동적으로 연결하여
메모리 할당을 받는 메커니즘
➢ Parallel coordinator가 여러개 떠서 쿼리 결과들을 공유하는 과정에서 MGA Sync calls의 latch
contention 문제 발생

• 원인
➢ <Bug:30293345> - LATCH: MGA SHARED CONTEXT LATCH WAITS AFTER MIGRATION TO 18C

• 해결 방안
1. Patch 30293345 적용
또는

2. DB RU 19.9 이상 권고

• 현상
➢ NULL constant를 사용하는 SQL에서 VARCHAR2 또는 RAW type에 32KB 이상 많은 Sharable 메모리를 사용하며 공유 메모리 크기 증가하는 현상
➢ 이 현상 발생 시 메모리 사용률 증가의 원인을 찾기가 쉽지 않음
➢ 테스트 어플리케이션을 수행하여 해당 이슈를 만났는지 확인하려면 pdy3M63_Finish_Page_Table()에 의해 생성된 페이지의 크기를 모니터링해야 함

• 원인
➢ <Bug.29438150> Increased Sharable Memory In 19c

• 해결 방안
1. <Note:29438150.8> Bug.29438150 Increased Sharable Memory In 19c
2. 본 이슈의 해결을 위해서는 patch 29438150 적용이 필요함