如何诊断cursorpinswaitonx系列二
如何分析诊断收集信息 1. 查看AWR 报告中high paring 和high version部分内容 具体查看这几个部分的内容:"SQLordered by Parse Calls' or 'SQL ordered by Version Count' SQL ordered by Parse Calls 关于这部分中的sql 解析执行是否过高,或者能否减小来
如何分析诊断收集信息
1. 查看AWR 报告中high paring 和high version部分内容
具体查看这几个部分的内容:"SQLordered by Parse Calls' or 'SQL ordered by Version Count'
SQL ordered by Parse Calls 关于这部分中的sql 解析执行是否过高,或者能否减小来。
SQL ordered by Version Count关于这部分中的high version sql ,需要找出为啥他们不能共享,可以通过 v$sql_shared_cursor 视图查找原因
2. systemstats 和errorstack 的关注点
对于systemstats 和errorstack 时效性非常重要。需要在问题发生时刻进行dump ,否则过时采集的信息是无效的。在一个高速运行的系统中,那些holders and waiter 进程转瞬即逝。
根据AWR 的 load profile 部分内容可以初步判断出 系统 sql 解析情况:
如果看到hard parses 很多,表明系统可能没有使用绑定变量,或者有新的sql 上线。
对于high version counts 也会导致 cursor:ping S wait on X
使用V$SQL_SHARED_CURSOR可以查找出 sql 不能共享的原因
有些bug可能会导致 high version counts:
Document 1057392.8 Bug 10157392 - High version counts forSQL with binds (BIND_MISMATCH)
Document 9689310.8 Bug 9689310 - Excessive child cursors /high VERSION_COUNT / OERI:17059 due to bind mismatch
Bug 可能会导致 cursor pin s wait on x :
NB |
Bug |
Fixed |
Description |
5650841 |
Hang / deadlock from ANALYZE of cluster index |
||
16191248 |
12.1.0.1.1, 12.1.0.2, 12.2.0.0 |
Hang from concurrent drop of on-commit materialized views or using DBMS_REDEFINITION |
|
14295250 |
11.2.0.4, 12.1.0.1 |
Long parse time for large query with many nested views due to much time in epxression analysis code |
|
14191508 |
11.2.0.3.8, 11.2.0.3.BP16, 11.2.0.4, 12.1.0.1 |
Slow row cache load due to SEG$ and INDSUBPART$ queries |
|
14176247 |
11.2.0.4, 12.1.0.1 |
Many child cursors using Adaptive Cursor Sharing with binds (due to BIND_EQUIV_FAILURE) |
|
18292893 |
12.1.0.2, 12.2.0.0 |
Jobs don't execute per schedule with a large number of PDBs |
|
18018515 |
12.2.0.0 |
High CPU in qctHasFakeBind (can cause 'cursor: pin S wait on X' waits) |
|
16448569 |
11.2.0.4, 12.1.0.2, 12.2.0.0 |
PQ hang/deadlock possible - "cursor: pin S wait on X" waits |
|
16400122 |
12.2.0.0 |
Spikes in library cache mutex contention for SQL using SQL Plan Baseline |
|
15850031 |
11.2.0.4, 12.2.0.0 |
Rare instance hang: deadlock between 'row cache lock' and 'cursor: pin S wait for X' |
|
14469756 |
12.2.0.0 |
Partition pruning causes delay in TBL$OR$IDX$PART$NUM |
|
14302813 |
11.2.0.4, 12.2.0.0 |
QC blocked / parse hang for parallel DML executed from remote stored procedure |
|
14029891 |
11.2.0.4, 12.1.0.1 |
mutex deadlock having SQL baselines on recursive dictionary cursor |
|
11927619 |
11.2.0.1.BP11, 11.2.0.2.BP07, 11.2.0.3, 12.1.0.1 |
DBMS_STATS slow on interval composite partitions |
|
11855965 |
11.2.0.3, 12.1.0.1 |
Truncate partition takes long time doing recursive delete on MLOG$ |
|
10213073 |
11.2.0.2.8, 11.2.0.2.BP18, 11.2.0.3, 12.1.0.1 |
CREATE SYNONYM and CREATE PACKAGE may incorrectly invalidate objects |
|
10171273 |
11.2.0.2.8, 11.2.0.2.BP08, 11.2.0.3, 12.1.0.1 |
Long parse time with non-equi subpartitioning under interval partitioning |
|
9944129 |
11.2.0.1.BP12, 11.2.0.2, 12.1.0.1 |
SQL not shared due to INST_DRTLD_MISMATCH with global transaction |
|
9935787 |
11.2.0.3, 12.1.0.1 |
Long parse time for large inlists - can cause 'cursor: pin S wait on X' waits |
|
9694101 |
10.2.0.5.7, 11.2.0.2, 12.1.0.1 |
Hang / deadlock between "cursor: pin S wait on X" and "library cache lock" involving dictionary objects |
|
9499302 |
10.2.0.5.5, 11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2, 12.1.0.1 |
Improve concurrent mutex request handling |
|
9472669 |
11.2.0.1.BP12, 11.2.0.2, 12.1.0.1 |
'cursor: pin S wait on X' waits for invalid SQL over DB link |
|
8508078 |
11.2.0.2, 12.1.0.1 |
Contention from many concurrent bad SQLs - superseded |
|
12432089 |
11.2.0.3 |
library cache lock/cursor: pin S wait on X with parallel partition stats gathering |
|
8441239 |
11.2.0.1 |
Library cache lock waits if long running TRUNCATE in progress |
|
8348464 |
11.1.0.7.2, 11.2.0.1 |
CREATE SYNONYM and CREATE PACKAGE may incorrectly invalidate objects |
|
7234778 |
11.2.0.1 |
Unnecessary "cursor: pin S wait on X" waits |
|
5485914 |
10.2.0.4 |
Mutex self deadlock on explain / trace of remote mapped SQL |
|
6143420 |
10.2.0.5, 11.1.0.6 |
Deadlock involving "ROW CACHE LOCK" on dc_users AND "CURSOR: PIN S WAIT ON X" |
|
6011045 |
10.2.0.5.5 |
DBMS_STATS causes deadlock between 'cursor: pin S wait on X' and 'library cache lock' |
|
7462072 |
10.2.0.4.3, 10.2.0.5 |
Unnecessary "cursor: pin S wait on X" waits |
|
5983020 |
10.2.0.4 |
MMON deadlock with user session executing ALTER USER |
|
7226463 |
10.2.0.5 |
EXECUTE IMMEDIATE no releasing mutex or library cache pin |
|
+ |
5907779 |
10.2.0.4 |
Self deadlock hang on "cursor: pin S wait on X" (typically from DBMS_STATS) |

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











PHP 500 오류에 대한 종합 가이드: 원인, 진단 및 수정 사항 PHP 개발 중에 HTTP 상태 코드 500과 관련된 오류가 자주 발생합니다. 이 오류는 일반적으로 "500InternalServerError"라고 불리며, 이는 서버 측에서 요청을 처리하는 동안 알 수 없는 오류가 발생했음을 의미합니다. 이 기사에서는 PHP500 오류의 일반적인 원인, 진단 방법, 수정 방법을 살펴보고 참조할 수 있는 구체적인 코드 예제를 제공합니다. 1.500 오류의 일반적인 원인 1.

샤오미 Mi 15 시리즈는 10월 정식 출시될 예정이며, 전체 시리즈 코드명이 외신 MiCode 코드베이스에 노출됐다. 그중 주력 제품인 샤오미 미 15 울트라의 코드명은 '쉬안위안(Xuanyuan)'('쉬안위안(Xuanyuan)'이라는 뜻)이다. 이 이름은 중국 신화 속 황제(Yellow Emperor)에서 유래한 것으로 귀족을 상징한다. Xiaomi 15의 코드명은 "Dada"이고, Xiaomi 15Pro의 이름은 "Haotian"("Haotian"을 의미)입니다. Xiaomi Mi 15S Pro의 내부 코드명은 "dijun"으로, "산과 바다의 고전"의 창조신인 Jun 황제를 암시합니다. Xiaomi 15Ultra 시리즈 커버

지난해 화웨이 메이트60 시리즈가 출시된 이후 개인적으로는 메이트60프로를 메인폰으로 사용해오고 있다. 거의 1년 동안 Huawei Mate60Pro는 여러 번의 OTA 업그레이드를 거쳤으며 전반적인 경험이 크게 개선되어 사람들에게 끊임없이 새로운 느낌을 줍니다. 예를 들어, 최근 Huawei Mate60 시리즈는 이미징 기능이 다시 한 번 크게 업그레이드되었습니다. 첫 번째는 행인과 잔해를 지능적으로 제거하고 빈 영역을 자동으로 채울 수 있는 새로운 AI 제거 기능입니다. 두 번째로 메인 카메라의 색상 정확도와 망원 선명도가 크게 업그레이드되었습니다. 개학 시즌을 고려하여 Huawei Mate60 시리즈도 가을 프로모션을 시작했습니다. 휴대폰 구매 시 최대 800위안 할인 혜택을 누릴 수 있으며, 시작 가격은 최저 4,999위안입니다. 일반적으로 사용되며 종종 가치가 높은 새로운 제품

iPhone15와 iPhone15Pro는 오늘 공식적으로 출시되었습니다. 그러나 Pro 시리즈는 고급 모델로서 가격이 더 높을 뿐만 아니라 많은 독점 기능을 갖추고 있습니다. iPhone15에서만 사용할 수 있는 기능입니다. 모니터에는 동일한 디스플레이 패널이 장착되어 있지만 ProMotion 자동 적응형 업데이트 빈도 기술과 상시 디스플레이 기능은 여전히 Pro 시리즈에만 적용됩니다. 나머지 iPhone 15 및 iPhone 15 Pro 시리즈는 해상도, 대비, 최대 밝기 등이 동일합니다. 액션 버튼 액션 버튼은 현재 iPhone 15 Pro 시리즈 전용 디자인으로 사용자가 개인화할 수 있습니다.

많은 친구들이 컴퓨터를 시작하면 블루 스크린 코드 0X000000ED가 나타나고 시스템에 들어가거나 작동할 수 없습니다. 무슨 일이 일어나고 있는 걸까요? 하드 디스크에 결함이 있어 시작 시 정상적인 로딩이 불가능할 수 있습니다. PE 부팅 디스크를 사용하고 안전 모드로 들어가 이 문제를 해결해 보겠습니다. 0x00000ed 블루 스크린 처리 방법 블루 스크린 코드: 0x000000ED 블루 스크린 원인: 하드 드라이브가 호환되지 않거나 불량 섹터가 있어 시작 시 정상적으로 로드되지 않을 수 있습니다. 설명 부팅 볼륨으로 로드하는 동안 I/0 하위 시스템이 실패했습니다. 방법 1: 1. 먼저 안전 모드로 들어갈 수 있는지 확인하십시오. 가능하다면 실행/CMD 입력을 열고 chkdsk/f/r 명령을 입력한 후 Enter를 누른 다음 다운로드하십시오.

하얼빈 의과대학 임상약학 취업 전망은 어떻습니까? 전국 취업 상황이 낙관적이지는 않지만 약학 졸업생의 취업 전망은 여전히 좋습니다. 전반적으로 제약산업 졸업생의 공급은 수요보다 적다. 제약회사와 제약공장은 이러한 졸업생을 흡수하는 주요 통로이기도 하다. 보도에 따르면 최근 몇 년간 조제약품, 천연의약화학 등 전공 대학원생의 수급비율은 1:10에 달하기도 했다. 임상약학전공 취업방향: 임상의학을 전공하는 학생은 졸업 후 의료보건학과, 의학연구 및 기타 학과에서 진료, 예방, 의학연구 등에 종사할 수 있습니다. 채용 직위: 의료 담당자, 제약 영업 담당자, 영업 담당자, 영업 관리자, 지역 영업 관리자, 투자 관리자, 제품 관리자, 제품 전문가, 간호사

Go 언어 웹 사이트 액세스 속도 문제를 신속하게 진단하고 해결하는 일반적인 방법 요약: 인터넷의 인기로 인해 웹 사이트 액세스 속도는 사용자 경험에 매우 중요합니다. 이 글에서는 Go 언어 웹사이트 접속 속도 문제를 신속하게 진단하고 해결하는 일반적인 방법을 소개하고 관련 코드 예제를 제공합니다. 소개: Go 언어는 웹사이트와 서비스를 구축하는 데 일반적으로 사용되는 고성능 프로그래밍 언어입니다. 그러나 Go 언어를 사용하여 구축된 웹사이트는 접속 속도 측면에서 몇 가지 문제가 발생할 수 있습니다. 이 문서에서는 개발자가 신속하게 진단하고 문제를 해결하는 데 도움이 되는 몇 가지 일반적인 방법을 소개합니다.

Windows 메모리 진단은 메모리가 정상인지 확인하는 데 도움이 되지만, 실제로는 제어판에서 시스템 도구만 열면 win11 메모리 진단을 사용하는 방법을 모르는 사용자가 많습니다. win11에서 메모리 진단을 사용하는 방법 1. 먼저 바탕화면 하단의 "시작 메뉴" 또는 "검색" 버튼을 클릭합니다. 2. 위의 검색창에서 검색을 클릭하고 "제어판" 기능을 엽니다. 3. 제어판에서 "시스템 및 보안" 옵션을 클릭하여 엽니다. 4. 이 페이지 하단의 "Windows 도구" 옵션을 엽니다. 5. 옵션을 두 번 클릭하여 "Windows 메모리 진단" 도구를 실행합니다. 6. 마지막으로 "지금 다시 시작하고 문제 확인"을 클릭하세요. (시스템이 자동으로 다시 시작됩니다. 파일이 있는 경우
