pat98's always & forever

• 현상
➢ 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 적용이 필요함

• 현상
➢ 19.8 이하 버젼에서 Wnnn의 CPU 사용률이 높아짐 (gc current block busy 대기 이벤트 증가)
➢ 자동 통계정보 수집 시 대량의 Library cache lock/cursor: pin S wait on X 가 발생하는데 blocker가 Wnnn process(Space Manager Slave)로 나타남
➢ 자동 통계정보 수집 중 특정 쿼리에서 Library cache lock이 잡히고 해소되지 않아 다른 세션들이 cursor: pin S wait on X 를 대기하면서 이슈 발생

• 원인
➢ Bug 23734075 로 인한 Wnnn 프로세스가 "_assm_segment_repair_timelimit" 에 설정된 시간 60초보다 더 많이 수행되어 최대 120초까지 사용

• 해결 방안
1. 패치 23734075 적용 또는 19.9 이상 DB RU 적용
2. Note 23734075.8 의 Workaround Parameter 설정 금지
<Note:23734075.8> "_assm_segment_repair_bg"=false 이 문서에 나오는 이 hidden parameter를 false로 하게 되면
Space Management Background processes를 비활성화할 경우, high DML 환경에서 Free block 이 Full 상태로 Mark 되어
Free 여부를 평가하지 못하여 공간 낭비 발생 가능
3. <Note:2467681.1> Space Management Slave Process Wnnn highly uses the physical memory

• 현상
➢ SYS.IDL_UB1$ 테이블의 크기 증가
➢ SEGMENT_NAME SUM(BYTES/1024/1024)IDL_UB1$ 368 (MB)
➢ 신규 구성 DB에서 SYSTEM 테이블스페이스 사이즈 증가하여 확인해보니 SYS.IDL_UB1$ 테이블 증가

• 원인 및 현상 설명
1. 해당 dictionary table IDL_UB1$ 의 size 는 고객사에서 사용하는 PL/SQL code 나 JavaVM code 에 따라 증가할 수 있음
2. UB1, UB2 크기는 dictionary table에 저장되는 테이블 정보와 관련된 부분으로 object의 수 , PL/SQL package의 수 등에 따라 변동이 있을 수 있음
3. IDL_UB1$의 size가 커지지 않도록 하는 방법은 없으며 , user에 의한 변경은 허용되지 않음