运行SQLT出现Latch:cache Buffer Chains的一种解决办法
这两天在一台10.2.0.4的数据库上面运行SQLT的报告,运行的很缓慢,大概等了1个小时还没出来,查看了一下执行SQLT会话的等待事件,显示latch:cache buffer chains。这里要说下,当SQLT运行的过程中,屏幕会有输出显示。如下所示: To actually diagnose the p
这两天在一台10.2.0.4的数据库上面运行SQLT的报告,运行的很缓慢,大概等了1个小时还没出来,查看了一下执行SQLT会话的等待事件,显示latch:cache buffer chains。这里要说下,当SQLT运行的过程中,屏幕会有输出显示。如下所示:
To actually diagnose the problem behind the disconnect, read ALERT
log and provide referenced traces to Support. After the root cause
of the disconnect is fixed then reset SQLT corresponding parameter.
To monitor progress, login into another session and execute:
SQL> SELECT * FROM SQLTXADMIN.sqlt$_log_v;
… collecting diagnostics details, please wait …
In case of a disconnect review log file in current directory
If running as SYS in 12c make sure to review sqlt_instructions.html first
当时我们就一直卡在这个界面,出不来。这里告诉我们如果要监控SQLT进程,可以查询SELECT * FROM SQLTXADMIN.sqlt$_log_v。我们登陆了另外一个会话,做了如下查询,显示下面的结果。
TIME LINE -------- ------------------------------------------------------------------------------------------------------------------------ 14:31:19 sqlt$h: -> index_hc_PK_PD_SVC_DICT 14:31:19 sqlt$h: column_hc_PD_SVC_DICT_EFF_DATE 14:31:19 sqlt$h: column_hc_PD_SVC_DICT_EXP_DATE 14:31:19 sqlt$h: column_hc_PD_SVC_DICT_MASTER_SERV_ID 14:31:19 sqlt$h: column_hc_PD_SVC_DICT_SVC_ID 14:31:19 sqlt$h: column_hc_PD_SVC_DICT_SVC_TYPE 14:31:19 sqlt$h: main_report 14:31:19 sqlt$m: -> flags 14:31:19 sqlt$m: <p><font face="幼圆" size="3">可以看到我们在做sqlt$m: init_parameters_sys的时候卡住了。但是看到了这个信息,我们也不知道它的意思。于是,我们只能考虑做下10046。</font> </p> <pre class="brush:php;toolbar:false">PARSING IN CURSOR #44 len=632 dep=1 uid=416 oct=3 lid=416 tim=35075498358274 hv=4132104666 ad='121339a8' SELECT S.END_INTERVAL_TIME, P.SNAP_ID, P.ISDEFAULT, P.ISMODIFIED, P.PARAMETER_NAME, P.INSTANCE_NUMBER, P.VALUE FROM SQLI$_DBA_HIST_PARAMETER P, SQLT$_DBA_HIS T_SNAPSHOT S, (SELECT /*+ NO_MERGE */ DISTINCT SNAP_ID, DBID FROM SQLT$_DBA_HIST_SQLSTAT WHERE STATEMENT_ID = :B1 ) ST WHERE P.STATEMENT_ID = :B1 AND P.STATE MENT_ID = S.STATEMENT_ID AND P.SNAP_ID = S.SNAP_ID AND P.DBID = S.DBID AND P.INSTANCE_NUMBER = S.INSTANCE_NUMBER AND (P.ISDEFAULT = 'FALSE' OR P.ISMODIFIED 'FALSE') AND P.SNAP_ID = ST.SNAP_ID AND P.DBID = ST.DBID ORDER BY S.END_INTERVAL_TIME DESC, P.ISDEFAULT, P.ISMODIFIED DESC, P.PARAMETER_NAME, P.INSTANCE_NU MBER END OF STMT PARSE #44:c=0,e=383,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=35075498358266 EXEC #44:c=0,e=226,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,tim=35075498358724 *** 2014-05-08 14:31:45.742 WAIT #44: nam='db file sequential read' ela= 1088 file#=2001 block#=581279 blocks=1 obj#=535668 tim=35075519750997 WAIT #44: nam='db file sequential read' ela= 783 file#=2001 block#=586373 blocks=1 obj#=535670 tim=35075520009144 WAIT #44: nam='db file sequential read' ela= 740 file#=2001 block#=579127 blocks=1 obj#=535670 tim=35075521390313 WAIT #44: nam='db file sequential read' ela= 1135 file#=2001 block#=579635 blocks=1 obj#=535670 tim=35075522675155 WAIT #44: nam='db file sequential read' ela= 1105 file#=2001 block#=581144 blocks=1 obj#=535670 tim=35075528124956 WAIT #44: nam='db file sequential read' ela= 824 file#=2001 block#=577465 blocks=1 obj#=535668 tim=35075528795240 WAIT #44: nam='db file sequential read' ela= 706 file#=2001 block#=580952 blocks=1 obj#=535668 tim=35075528935134 *** 2014-05-08 14:31:58.642 WAIT #44: nam='db file sequential read' ela= 850 file#=2001 block#=575871 blocks=1 obj#=535670 tim=35075532348467 *** 2014-05-08 14:36:51.985 WAIT #44: nam='latch: cache buffers chains' ela= 177 address=66109355216 number=122 tries=0 obj#=535670 tim=35075818825412 *** 2014-05-08 14:41:07.053 WAIT #44: nam='latch: cache buffers chains' ela= 119 address=66263337712 number=122 tries=0 obj#=535670 tim=35076067923552 *** 2014-05-08 14:43:21.686 WAIT #44: nam='latch: cache buffers chains' ela= 15 address=66046764704 number=122 tries=0 obj#=535670 tim=35076199404865 *** 2014-05-08 15:04:11.215 WAIT #44: nam='latch: cache buffers chains' ela= 43 address=66336324888 number=122 tries=0 obj#=535670 tim=35077419687444 *** 2014-05-08 15:06:45.573 WAIT #44: nam='latch: cache buffers chains' ela= 63 address=65975608120 number=122 tries=0 obj#=535670 tim=35077570432584 *** 2014-05-08 15:09:39.477 WAIT #44: nam='latch: cache buffers chains' ela= 223 address=66292257024 number=122 tries=0 obj#=535670 tim=35077740265783 *** 2014-05-08 15:12:25.390 WAIT #44: nam='latch: cache buffers chains' ela= 253 address=66066629152 number=122 tries=0 obj#=535670 tim=35077902295960 *** 2014-05-08 15:24:24.368 Received ORADEBUG command 'event 10046 trace name context forever,level 12' from process Unix process pid: 6764, image: *** 2014-05-08 15:24:42.767 Received ORADEBUG command 'event 10046 trace name context off' from process Unix process pid: 6764, image: Received ORADEBUG command 'tracefile_name' from process Unix process pid: 6764, image:
可以看到10046的等待主要是集中在latch: cache buffers chains上的。看了下运行SQL的执行计划。
PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------------------------ SQL_ID f2u123bv4pufu, child number 0 ------------------------------------- SELECT S.END_INTERVAL_TIME, P.SNAP_ID, P.ISDEFAULT, P.ISMODIFIED, P.PARAMETER_NAME, P.INSTANCE_NUMBER, P.VALUE FROM SQLI$_DBA_HIST_PARAMETER P, SQLT$_DBA_HIST_SNAPSHOT S, (SELECT /*+ NO_MERGE */ DISTINCT SNAP_ID, DBID FROM SQLT$_DBA_HIST_SQLSTAT WHERE STATEMENT_ID = :B1 ) ST WHERE P.STATEMENT_ID = :B1 AND P.STATEMENT_ID = S.STATEMENT_ID AND P.SNAP_ID = S.SNAP_ID AND P.DBID = S.DBID AND P.INSTANCE_NUMBER = S.INSTANCE_NUMBER AND (P.ISDEFAULT = 'FALSE' OR P.ISMODIFIED 'FALSE') AND P.SNAP_ID = ST.SNAP_ID AND P.DBID = ST.DBID ORDER BY S.END_INTERVAL_TIME DESC, P.ISDEFAULT, P.ISMODIFIED DESC, P.PARAMETER_NAME, P.INSTANCE_NUMBER Plan hash value: 1007730285 ---------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 64 (100)| | | 1 | SORT ORDER BY | | 81 | 60426 | 64 (5)| 00:00:01 | |* 2 | HASH JOIN | | 81 | 60426 | 63 (4)| 00:00:01 | |* 3 | TABLE ACCESS FULL | SQLT$_DBA_HIST_SNAPSHOT | 2172 | 137K| 9 (0)| 00:00:01 | | 4 | NESTED LOOPS | | 303 | 201K| 53 (2)| 00:00:01 | | 5 | VIEW | | 23 | 598 | 7 (15)| 00:00:01 | | 6 | HASH UNIQUE | | 23 | 897 | 7 (15)| 00:00:01 | | 7 | TABLE ACCESS BY INDEX ROWID| SQLT$_DBA_HIST_SQLSTAT | 23 | 897 | 6 (0)| 00:00:01 | |* 8 | INDEX RANGE SCAN | SQLT$_DBA_HIST_SQLSTAT_N1 | 9 | | 2 (0)| 00:00:01 | |* 9 | TABLE ACCESS BY INDEX ROWID | SQLI$_DBA_HIST_PARAMETER | 13 | 8515 | 2 (0)| 00:00:01 | |* 10 | INDEX RANGE SCAN | SQLI$_DBA_HIST_PARAMETER_N1 | 202 | | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("P"."STATEMENT_ID"="S"."STATEMENT_ID" AND "P"."SNAP_ID"="S"."SNAP_ID" AND "P"."DBID"="S"."DBID" AND "P"."INSTANCE_NUMBER"="S"."INSTANCE_NUMBER") 3 - filter("S"."STATEMENT_ID"=:B1) 8 - access("STATEMENT_ID"=:B1) 9 - filter((("P"."ISMODIFIED"'FALSE' OR "P"."ISDEFAULT"='FALSE') AND "P"."SNAP_ID"="ST"."SNAP_ID")) 10 - access("P"."STATEMENT_ID"=:B1 AND "P"."DBID"="ST"."DBID") Note ----- - dynamic sampling used for this statement
按道理来说这个语句应该运行很快才对,怎么会出这种问题了,看到是动态采样的。于是我就想收集了一下这几个表的统计信息。发现统计信息居然还是锁住的。于是强行解锁把这几个表的统计信息收集了。
SQL> exec dbms_stats.UNLOCK_TABLE_STATS(ownname=>'SQLTXPLAIN',TABNAME=>'SQLI$_DBA_HIST_PARAMETER'); PL/SQL procedure successfully completed. SQL> exec dbms_stats.GATHER_TABLE_STATS(ownname=>'SQLTXPLAIN',TABNAME=>'SQLI$_DBA_HIST_PARAMETER'); PL/SQL procedure successfully completed. SQL> exec dbms_stats.UNLOCK_TABLE_STATS(ownname=>'SQLTXPLAIN',TABNAME=>'SQLT$_DBA_HIST_SQLSTAT'); PL/SQL procedure successfully completed. SQL> exec dbms_stats.GATHER_TABLE_STATS(ownname=>'SQLTXPLAIN',TABNAME=>'SQLT$_DBA_HIST_SQLSTAT'); PL/SQL procedure successfully completed. SQL> exec dbms_stats.UNLOCK_TABLE_STATS(ownname=>'SQLTXPLAIN',TABNAME=>'SQLT$_DBA_HIST_SNAPSHOT'); PL/SQL procedure successfully completed. SQL> exec dbms_stats.GATHER_TABLE_STATS(ownname=>'SQLTXPLAIN',TABNAME=>'SQLT$_DBA_HIST_SNAPSHOT'); PL/SQL procedure successfully completed.
收集完了再次运行,SQLT的结果集就出来了。然后查看了一下新的执行计划。发现确实有改变。SQLT$_DBA_HIST_SQLSTAT从索引范围扫描变成了全表扫描。执行计划由nested loop变成了hash join。
PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------------------------ SQL_ID f2u123bv4pufu, child number 0 ------------------------------------- SELECT S.END_INTERVAL_TIME, P.SNAP_ID, P.ISDEFAULT, P.ISMODIFIED, P.PARAMETER_NAME, P.INSTANCE_NUMBER, P.VALUE FROM SQLI$_DBA_HIST_PARAMETER P, SQLT$_DBA_HIST_SNAPSHOT S, (SELECT /*+ NO_MERGE */ DISTINCT SNAP_ID, DBID FROM SQLT$_DBA_HIST_SQLSTAT WHERE STATEMENT_ID = :B1 ) ST WHERE P.STATEMENT_ID = :B1 AND P.STATEMENT_ID = S.STATEMENT_ID AND P.SNAP_ID = S.SNAP_ID AND P.DBID = S.DBID AND P.INSTANCE_NUMBER = S.INSTANCE_NUMBER AND (P.ISDEFAULT = 'FALSE' OR P.ISMODIFIED 'FALSE') AND P.SNAP_ID = ST.SNAP_ID AND P.DBID = ST.DBID ORDER BY S.END_INTERVAL_TIME DESC, P.ISDEFAULT, P.ISMODIFIED DESC, P.PARAMETER_NAME, P.INSTANCE_NUMBER Plan hash value: 72767641 -------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 72 (100)| | | 1 | SORT ORDER BY | | 1 | 698 | 72 (5)| 00:00:01 | |* 2 | HASH JOIN | | 1 | 698 | 71 (3)| 00:00:01 | |* 3 | HASH JOIN | | 1 | 667 | 57 (4)| 00:00:01 | |* 4 | TABLE ACCESS BY INDEX ROWID| SQLI$_DBA_HIST_PARAMETER | 1 | 655 | 0 (0)| | |* 5 | INDEX RANGE SCAN | SQLI$_DBA_HIST_PARAMETER_N1 | 1 | | 0 (0)| | | 6 | VIEW | | 707 | 8484 | 56 (2)| 00:00:01 | | 7 | HASH UNIQUE | | 707 | 12019 | 56 (2)| 00:00:01 | |* 8 | TABLE ACCESS FULL | SQLT$_DBA_HIST_SQLSTAT | 2078 | 35326 | 55 (0)| 00:00:01 | |* 9 | TABLE ACCESS FULL | SQLT$_DBA_HIST_SNAPSHOT | 2174 | 67394 | 14 (0)| 00:00:01 | -------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("P"."STATEMENT_ID"="S"."STATEMENT_ID" AND "P"."SNAP_ID"="S"."SNAP_ID" AND "P"."DBID"="S"."DBID" AND "P"."INSTANCE_NUMBER"="S"."INSTANCE_NUMBER") 3 - access("P"."SNAP_ID"="ST"."SNAP_ID" AND "P"."DBID"="ST"."DBID") 4 - filter(("P"."ISMODIFIED"'FALSE' OR "P"."ISDEFAULT"='FALSE')) 5 - access("P"."STATEMENT_ID"=:B1) 8 - filter("STATEMENT_ID"=:B1) 9 - filter("S"."STATEMENT_ID"=:B1)
原文地址:运行SQLT出现Latch:cache Buffer Chains的一种解决办法, 感谢原作者分享。

핫 AI 도구

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

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

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

Clothoff.io
AI 옷 제거제

Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

인기 기사

뜨거운 도구

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

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

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

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

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

Linux 시스템에서 .sh 파일을 실행하는 방법은 무엇입니까? Linux 시스템에서 .sh 파일은 일련의 명령을 실행하는 데 사용되는 셸 스크립트라는 파일입니다. .sh 파일 실행은 매우 일반적인 작업입니다. 이 기사에서는 Linux 시스템에서 .sh 파일을 실행하는 방법을 소개하고 구체적인 코드 예제를 제공합니다. 방법 1: 절대 경로를 사용하여 .sh 파일을 실행합니다. Linux 시스템에서 .sh 파일을 실행하려면 절대 경로를 사용하여 파일 위치를 지정할 수 있습니다. 구체적인 단계는 다음과 같습니다. 터미널을 엽니다.

Python에서는 PyExecJS 라이브러리 또는 Python의 js2py 라이브러리를 사용하여 Javascript 코드를 실행할 수 있습니다. PyExecJs 라이브러리는 Node.js, JavaScriptCore 및 Google의 V8 엔진을 포함한 다양한 JavaScript 엔진을 사용하여 Python에서 JavaScript 코드를 실행하기 위한 일관된 API를 제공합니다. js2py 라이브러리를 사용하면 JavaScript 코드를 구문 분석하고 Python에서 해석하여 Python에서 JavaScript 코드를 실행할 수 있습니다. 이 기사에서는 PyExecJS 라이브러리를 사용하여 Python에서 javasc를 실행하는 방법을 설명합니다.

PyCharm은 매우 인기 있는 Python 통합 개발 환경(IDE)으로 Python 개발을 더욱 효율적이고 편리하게 만들어주는 다양한 기능과 도구를 제공합니다. 이 기사에서는 PyCharm의 기본 작동 방법을 소개하고 독자가 도구 작동을 빠르게 시작하고 능숙하게 사용할 수 있도록 구체적인 코드 예제를 제공합니다. 1. PyCharm 다운로드 및 설치 먼저 PyCharm 공식 웹사이트(https://www.jetbrains.com/pyc)로 이동해야 합니다.

win7에서 exe 파일을 실행할 수 없는 이유는 무엇입니까? Windows7 운영 체제를 사용할 때 많은 사용자가 exe 파일을 실행할 수 없는 일반적인 문제에 직면할 수 있습니다. exe 파일은 Windows 운영 체제에서 일반적으로 사용되는 실행 파일로 다양한 응용 프로그램을 설치하고 실행하는 데 사용됩니다. 그러나 일부 사용자는 exe 파일을 실행하려고 할 때 시스템이 응답하지 않거나 오류 메시지를 표시하는 것을 발견할 수 있습니다. 이 문제에는 여러 가지 이유가 있습니다. 다음은 몇 가지 일반적인 원인과 해당 해결 방법입니다.

win7에서 bat 파일을 실행할 수 없는 이유는 무엇입니까? 최근 Windows7 운영 체제를 사용하는 많은 사용자가 .bat 파일을 실행할 수 없다고 보고했습니다. 이는 광범위한 논의와 혼란을 불러일으켰습니다. 잘 작동하는 운영 체제에서 간단한 .bat 파일을 실행할 수 없는 이유는 무엇입니까? 먼저 .bat 파일의 배경을 이해해야 합니다. 배치 파일이라고도 하는 .bat 파일은 Windows 명령 해석기(cmd.ex)에서 사용할 수 있는 일련의 명령이 포함된 일반 텍스트 파일입니다.

실제로는 이렇습니다. 당시 리더가 perf 하드웨어 성능 모니터링 작업을 지시했습니다. perf를 사용하는 동안 perf list 명령을 입력했는데 다음 정보가 표시되었습니다. 내 작업은 이러한 캐시 이벤트를 활성화하는 것입니다. 하지만 요점은 이러한 누락과 로드가 무엇을 의미하는지 전혀 모른다는 것입니다.

matlab에서 m 파일을 실행하는 방법을 아시나요? 아래에서 matlab에서 m 파일을 실행하는 방법에 대한 튜토리얼을 가져오겠습니다. 1. 먼저 matlab을 열어보세요. 소프트웨어를 선택하고 아래 그림과 같이 왼쪽 상단 모서리 "열기"를 선택합니다. 2. 그리고 아래 그림과 같이 실행할 m 파일을 선택하고 엽니다. 3. 아래 그림과 같이 창에서 F5 키를 눌러 프로그램을 실행합니다. 4. 아래 그림과 같이 명령줄 창과 작업 공간에서 실행 결과를 볼 수 있습니다. 5. 아래 그림과 같이 "실행"을 직접 클릭하여 파일을 실행할 수도 있습니다. 6. 마지막으로 아래 그림과 같이 명령줄 창과 작업 공간에서 m 파일의 실행 결과를 볼 수 있습니다. 위는 편집자가 가져온 MATLAB 방법입니다.

Microsoft의 새로운 시스템인 Windows 10과 관련하여 친구들은 어떤 버전의 Windows 10 운영 체제가 가장 빠르고 원활하게 실행되는지 알고 싶어합니다. 버전 업데이트는 실제로 시스템 콘텐츠 및 기능에 대한 업데이트 및 결함 수리입니다. 가장 빠르게 실행되는 win10 버전은 무엇입니까? 1. win10의 각 버전 간의 차이점은 주로 해당 기능에 있습니다. 2. 다른 기능을 제외하고 다른 측면은 동일합니다. 3. win10의 다양한 버전 간에는 큰 차이가 없습니다. 실행 속도 측면에서 가장 큰 차이점은 자신의 컴퓨터 구성을 살펴보십시오. ~ win10 Home Edition: 1. Win10 Home Edition은 보급형 시스템 버전인 win8.1의 핵심 버전과 동일합니다. 2. win10 홈 버전의 국가별 버전은 win8.1의 OEM 중국어 버전과 동일합니다.
