[20220518]enq FU - contention等待事件.txt --//检查生产系统,发现inactive session 和 enq: FU - contention 等待事件,从来没有遇到过,仔细探究看看. --//本文集中探究enq: FU - contention 等待事件. 1.环境: 实例1> @ ver1 PORT_STRING VERSION BANNER ------------------------------ -------------- -------------------------------------------------------------------------------- x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production 2.ashtop查看: 实例1> @ashtop event 1=1 &day Total Distinct Distinct Seconds AAS %This EVENT FIRST_SEEN LAST_SEEN Execs Seen Tstamps --------- ------- ------- ------------------------------------------ ------------------- ------------------- ---------- -------- 334312 3.9 93% | 2022-05-16 10:52:20 2022-05-17 10:52:12 15444 32265 13951 .2 4% | inactive session 2022-05-16 10:52:18 2022-05-17 10:52:11 6248 8976 2854 .0 1% | enq: FU - contention 2022-05-16 11:11:39 2022-05-17 10:14:18 1 2854 2342 .0 1% | RMAN backup & recovery I/O 2022-05-16 19:30:08 2022-05-17 01:52:46 1 496 1236 .0 0% | control file sequential read 2022-05-16 10:57:37 2022-05-17 10:51:08 528 996 734 .0 0% | enq: TX - row lock contention 2022-05-16 15:43:39 2022-05-16 17:16:01 3 734 --//inactive session 和 enq: FU - contention等待事件,先集中探究enq: FU - contention等待事件. --//inactive session 等待事件另外写一篇blog. 3.分析: 实例1> @ enq fu EQ_NAME EQ REQ_REASON TOTAL_REQ# TOTAL_WAIT# SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME REQ_DESCRIPTION EVENT# ------------------------------ -- ---------- ---------- ----------- ---------- ----------- ------------- ---------------------------------------------------------------------------------------------------- ---------- Cross-Instance Call Invocation CI contention 0 0 0 0 0 Coordinates cross-instance function invocations 427 DBFUS FU contention 1 0 1 0 0 This enqueue is used to serialize the capture of the DB Feature Usage and High Water Mark 1328 Statistics --//FU: This enqueue is used to serialize the capture of the DB Feature Usage and High Water Mark Statistics --//翻译如下: 此队列用于序列化数据库特性使用情况和高水位标记统计数据的捕获,怎么意思??? --//注:事后从输出也看出ENQ=FU的TOTAL_REQ#=1,SUCC_REQ#=1.说明有1个进程目前持有enq FU的enquence. 实例1> @ ashtop sql_id,module1 "event='enq: FU - contention'" &day Total Distinct Distinct Seconds AAS %This SQL_ID MODULE1 FIRST_SEEN LAST_SEEN Execs Seen Tstamps --------- ------- ------- ------------- -------------------- ------------------- ------------------- ---------- -------- 2854 .0 100% | mmon_slave 2022-05-16 11:11:39 2022-05-17 10:14:18 1 2854 --//来自mmon_slave模块, 时间跨度接近一天。 --//在实例1上执行: $ ls -l *mmon* -rw-r----- 1 oracle asmadmin 3442 2022-05-17 08:34:09 ywdb1_mmon_25038.trc -rw-r----- 1 oracle asmadmin 369 2022-05-17 08:34:09 ywdb1_mmon_25038.trm --//检查跟踪文件发现: *** 2022-05-14 09:31:52.750 *** SESSION ID:(7897.1) 2022-05-14 09:31:52.750 *** CLIENT ID:() 2022-05-14 09:31:52.750 *** SERVICE NAME:(SYS$BACKGROUND) 2022-05-14 09:31:52.750 *** MODULE NAME:() 2022-05-14 09:31:52.750 *** ACTION NAME:() 2022-05-14 09:31:52.750 Unable to schedule a MMON slave at: Auto DBFUS Main Slave was not permitted to be scheduled - A slave for this action is already running. Unable to schedule a MMON slave at: Auto DBFUS Main *** 2022-05-14 10:31:54.627 Slave was not permitted to be scheduled - A slave for this action is already running. Unable to schedule a MMON slave at: Auto DBFUS Main *** 2022-05-14 11:31:56.643 Slave was not permitted to be scheduled - A slave for this action is already running. Unable to schedule a MMON slave at: Auto DBFUS Main --//间隔1小时 *** 2022-05-14 13:32:00.531 Slave was not permitted to be scheduled - A slave for this action is already running. Unable to schedule a MMON slave at: Auto DBFUS Main --//间隔2小时 .. *** 2022-05-16 14:33:33.430 Slave was not permitted to be scheduled - A slave for this action is already running. Unable to schedule a MMON slave at: Auto DBFUS Main *** 2022-05-16 23:33:52.277 Slave was not permitted to be scheduled - A slave for this action is already running. Unable to schedule a MMON slave at: Auto DBFUS Main --//间隔9小时 *** 2022-05-17 08:34:09.598 Slave was not permitted to be scheduled - A slave for this action is already running. --//间隔9小时. --//从2022-05-14 09:31:52.750开始就出现问题,似乎还有一个slave在运行。 --//注:事后发现从间隔时间上看可以调度时间间隔1小时,不过后面写跟踪文件的间隔似乎不断增加, --//上班再仔细看看,补充测试: --//http://blog.itpub.net/267265/viewspace-2641133/ => [20190412]bash显示日期相减.txt $ zdate 2022/05/19 08:36:15 $ grep "\*\*\* 2022" ywdb1_mmon_25038.trc | awk '{print $2 " " $3}' |xargs -IQ date -d "Q" "+%s" | awk 'NR==1{a=$1} NR>1{print ($1-a)/3600;a=$1}' 1.00056 1.00056 2.00111 2.00111 2.00111 4.00194 4.00222 4.00194 8.00417 8.00389 8.00444 9.005 9.00528 9.00472 9.005 9.005 9.005 9.005 9.005 --//可以看出跟踪文件记录时间的变化,开始1,2,4,8,9.... --//检查实例2,在实例2上查看ywdb2_mmon_17152.trc文件,发现如下: *** 2022-05-14 09:12:09.707 *** SESSION ID:(7897.1) 2022-05-14 09:12:09.707 *** CLIENT ID:() 2022-05-14 09:12:09.707 *** SERVICE NAME:(SYS$BACKGROUND) 2022-05-14 09:12:09.707 *** MODULE NAME:() 2022-05-14 09:12:09.707 *** ACTION NAME:() 2022-05-14 09:12:09.707 ***KEWFDBFUS: Auto-DBFUS slave failed, return Code: 2***KEWFDBFUS: Auto-DBFUS slave failed, return Code: 2 ............... --//似乎没有换行, 2022-05-14 09:12:09.707出现问题,感觉是执行Auto-DBFUS slave failed.怎么意思不理解. --//注:输出时没有时间信息. --//结合实例1,实例2看到的情况,可以做这样的猜测,实例1上执行时,另外的实例2上也在执行的情况下,oracle在执行前要获取enq FU的enquennce, --//这样保证不能在2个实例上同时执行. --//还可以猜测实例1上已经有一个进程持有enq FU的enquennce,这样实例1再次执行时报告A slave for this action is already running, --//而实例2在执行前需要持有enq FU的enquence,因为实例1上的enq FU没有释放,这样报***KEWFDBFUS: Auto-DBFUS slave failed, return Code: 2. --//注:以上的分析来自事后,慢慢看下面的展开分析. 实例1> @ashtop SESSION_ID,module1,inst_id "event='enq: FU - contention'" &1day Total Distinct Distinct Seconds AAS %This SESSION_ID MODULE1 INST_ID FIRST_SEEN LAST_SEEN Execs Seen Tstamps --------- ------- ------- ---------- ---------- ------- ------------------- ------------------- ---------- -------- 238 .0 8% | 3408 mmon_slave 2 2022-05-17 02:12:05 2022-05-17 06:14:11 1 238 237 .0 8% | 3971 mmon_slave 2 2022-05-16 20:11:55 2022-05-17 03:14:05 1 237 120 .0 4% | 8482 mmon_slave 2 2022-05-16 21:11:56 2022-05-16 21:13:55 1 120 119 .0 4% | 14 mmon_slave 2 2022-05-16 22:11:58 2022-05-16 22:13:56 1 119 119 .0 4% | 576 mmon_slave 2 2022-05-16 19:11:53 2022-05-16 19:13:52 1 119 119 .0 4% | 1712 mmon_slave 2 2022-05-17 10:12:20 2022-05-17 10:14:18 1 119 119 .0 4% | 2563 mmon_slave 2 2022-05-16 16:11:47 2022-05-16 16:13:46 1 119 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 119 .0 4% | 3973 mmon_slave 2 2022-05-17 05:12:11 2022-05-17 05:14:09 1 119 119 .0 4% | 4254 mmon_slave 2 2022-05-17 01:12:03 2022-05-17 01:14:02 1 119 119 .0 4% | 5102 mmon_slave 2 2022-05-16 12:11:40 2022-05-16 12:13:39 1 119 119 .0 4% | 5937 mmon_slave 2 2022-05-16 14:11:44 2022-05-16 14:13:42 1 119 119 .0 4% | 6213 mmon_slave 2 2022-05-16 23:11:59 2022-05-16 23:13:58 1 119 119 .0 4% | 6775 mmon_slave 2 2022-05-17 04:12:08 2022-05-17 04:14:07 1 119 119 .0 4% | 7060 mmon_slave 2 2022-05-16 15:11:46 2022-05-16 15:13:44 1 119 119 .0 4% | 7066 mmon_slave 2 2022-05-17 00:12:01 2022-05-17 00:14:00 1 119 119 .0 4% | 7069 mmon_slave 2 2022-05-16 13:11:42 2022-05-16 13:13:40 1 119 119 .0 4% | 7350 mmon_slave 2 2022-05-17 07:12:14 2022-05-17 07:14:12 1 119 119 .0 4% | 7903 mmon_slave 2 2022-05-17 09:12:18 2022-05-17 09:14:16 1 119 119 .0 4% | 8753 mmon_slave 2 2022-05-16 17:11:49 2022-05-16 17:13:48 1 119 118 .0 4% | 294 mmon_slave 2 2022-05-16 18:11:51 2022-05-16 18:13:49 1 118 118 .0 4% | 1716 mmon_slave 2 2022-05-17 08:12:16 2022-05-17 08:14:14 1 118 118 .0 4% | 7918 mmon_slave 2 2022-05-17 11:12:21 2022-05-17 11:14:19 1 118 22 rows selected. --//似乎enq: FU - contention等待事件出现在实例2.还可以猜测每次等待120秒上下,我估计过了120秒,该进程可能被kill掉,不然 --//SESSION_ID不会出现不同的情况. --//注:事后在家里我才发现应该在查询时应该增加一个字段session_serial#. --//单独取出FIRST_SEEN字段,排序,经过一系列编辑处理后生成如下脚本: select to_date('2022-05-16 13:11:42') - to_date('2022-05-16 12:11:40') from dual ; select to_date('2022-05-16 14:11:44') - to_date('2022-05-16 13:11:42') from dual ; select to_date('2022-05-16 15:11:46') - to_date('2022-05-16 14:11:44') from dual ; select to_date('2022-05-16 16:11:47') - to_date('2022-05-16 15:11:46') from dual ; select to_date('2022-05-16 17:11:49') - to_date('2022-05-16 16:11:47') from dual ; select to_date('2022-05-16 18:11:51') - to_date('2022-05-16 17:11:49') from dual ; select to_date('2022-05-16 19:11:53') - to_date('2022-05-16 18:11:51') from dual ; select to_date('2022-05-16 20:11:55') - to_date('2022-05-16 19:11:53') from dual ; select to_date('2022-05-16 21:11:56') - to_date('2022-05-16 20:11:55') from dual ; select to_date('2022-05-16 22:11:58') - to_date('2022-05-16 21:11:56') from dual ; select to_date('2022-05-16 23:11:59') - to_date('2022-05-16 22:11:58') from dual ; select to_date('2022-05-17 00:12:01') - to_date('2022-05-16 23:11:59') from dual ; select to_date('2022-05-17 01:12:03') - to_date('2022-05-17 00:12:01') from dual ; select to_date('2022-05-17 02:12:05') - to_date('2022-05-17 01:12:03') from dual ; select to_date('2022-05-17 04:12:08') - to_date('2022-05-17 02:12:05') from dual ; --//2个小时 select to_date('2022-05-17 05:12:11') - to_date('2022-05-17 04:12:08') from dual ; select to_date('2022-05-17 07:12:14') - to_date('2022-05-17 05:12:11') from dual ; --//2个小时 select to_date('2022-05-17 08:12:16') - to_date('2022-05-17 07:12:14') from dual ; select to_date('2022-05-17 09:12:18') - to_date('2022-05-17 08:12:16') from dual ; select to_date('2022-05-17 10:12:20') - to_date('2022-05-17 09:12:18') from dual ; select to_date('2022-05-17 11:12:21') - to_date('2022-05-17 10:12:20') from dual ; --//我不执行了,前后对比你就可以猜测oracle间隔1个小时调度这个执行.注意记录跟踪文件时间的变化看上面的计算。 --//这样一天相当于 24*120 = 2880秒,与我前面看到2854 秒相当接近. --//利用tpt的dash_wait_chains2脚本,注意该命令查看的是dba_hist_active_sess_history视图. 实例1> @ tpt/ash/dash_wait_chains2 BLOCKING_SESSION||','||BLOCKING_SESSION_SERIAL#||',@'||BLOCKING_INST_ID||'=>'||session_id||','||SESSION_SERIAL#||',@'||inst_id||'=>'||event "event='enq: FU - contention'" &day -- Display ASH Wait Chain Signatures script v0.7 BETA by Tanel Poder ( http://blog.tanelpoder.com ) %This SECONDS AAS WAIT_CHAIN FIRST_SEEN LAST_SEEN ------ ---------- ---------- ----------------------------------------------------------------------------- ------------------- ------------------- 4% 120 0 -> 3958,15327,@1=>2563,19865,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 16:11:53 2022-05-16 16:13:43 4% 120 0 -> 3958,15327,@1=>576,18913,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 19:12:01 2022-05-16 19:13:51 4% 120 0 -> 3958,15327,@1=>8482,27213,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 21:12:05 2022-05-16 21:13:56 4% 120 0 -> 3958,15327,@1=>3973,13337,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-17 05:12:12 2022-05-17 05:14:02 4% 120 0 -> 3958,15327,@1=>7060,61585,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 15:11:40 2022-05-16 15:13:31 4% 120 0 -> 3958,15327,@1=>1712,2789,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-17 10:12:23 2022-05-17 10:14:13 4% 110 0 -> 3958,15327,@1=>3971,21789,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-17 03:12:18 2022-05-17 03:13:58 4% 110 0 -> 3958,15327,@1=>3971,20963,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 20:12:13 2022-05-16 20:13:53 4% 110 0 -> 3958,15327,@1=>14,53877,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 22:12:07 2022-05-16 22:13:48 4% 110 0 -> 3958,15327,@1=>7066,18339,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-17 00:12:11 2022-05-17 00:13:52 4% 110 0 -> 3958,15327,@1=>3408,13363,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-17 02:12:16 2022-05-17 02:13:56 4% 110 0 -> 3958,15327,@1=>6775,4533,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-17 04:12:10 2022-05-17 04:13:50 4% 110 0 -> 3958,15327,@1=>8753,64495,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 17:12:06 2022-05-16 17:13:46 4% 110 0 -> 3958,15327,@1=>7350,25325,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-17 07:12:26 2022-05-17 07:14:06 4% 110 0 -> 3958,15327,@1=>5937,52023,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 14:11:58 2022-05-16 14:13:38 4% 110 0 -> 3958,15327,@1=>5102,12305,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 12:11:53 2022-05-16 12:13:33 4% 110 0 -> 3958,15327,@1=>3408,13837,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-17 06:12:24 2022-05-17 06:14:04 4% 110 0 -> 3958,15327,@1=>7903,51465,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-17 09:12:30 2022-05-17 09:14:11 4% 110 0 -> 3958,15327,@1=>294,55109,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 18:12:08 2022-05-16 18:13:49 4% 110 0 -> 3958,15327,@1=>7069,16489,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 13:11:55 2022-05-16 13:13:36 4% 100 0 -> 3958,15327,@1=>6213,65203,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-16 23:12:09 2022-05-16 23:13:40 4% 100 0 -> 3958,15327,@1=>1716,28411,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-17 08:12:38 2022-05-17 08:14:08 4% 100 0 -> 3958,15327,@1=>4254,31191,@2=>enq: FU - contention -> ,,@=>3958,15327,@1=> 2022-05-17 01:12:23 2022-05-17 01:13:54 1% 20 0 -> ,,@=>1716,28411,@2=>enq: FU - contention 2022-05-17 08:12:17 2022-05-17 08:12:27 0% 10 0 -> ,,@=>4254,31191,@2=>enq: FU - contention 2022-05-17 01:12:12 2022-05-17 01:12:12 0% 10 0 -> ,,@=>3971,20963,@2=>enq: FU - contention 2022-05-16 20:12:03 2022-05-16 20:12:03 0% 10 0 -> ,,@=>5937,52023,@2=>enq: FU - contention 2022-05-16 14:11:46 2022-05-16 14:11:46 0% 10 0 -> ,,@=>8753,64495,@2=>enq: FU - contention 2022-05-16 17:11:55 2022-05-16 17:11:55 0% 10 0 -> ,,@=>7069,16489,@2=>enq: FU - contention 2022-05-16 13:11:43 2022-05-16 13:11:43 0% 10 0 -> ,,@=>5102,12305,@2=>enq: FU - contention 2022-05-16 12:11:40 2022-05-16 12:11:40 30 rows selected. --//sid=3958出现自锁,在实例1上。注意前面120秒,再次验证自己的判断. --//注:dash_wait_chains2 显示的是一个等待或者阻塞的链条,你可以发现sid=2563,19865也出现在前面执行 --//@ashtop SESSION_ID,module1,inst_id "event='enq: FU - contention'" &1day 的输出中. 实例1> @ sid 3958 sid = 3958 SPID PID SID SERIAL# CLIENT_INFO PNAME TRACEFILE PROGRAM TERMINAL SQL_ID STATUS C50 ----- --- ---- ------- ----------- ----- ---------------------------------------------------------------- -------------------- -------- ------------- -------- -------------------------------------------------- 31997 430 3958 15327 M001 /u01/app/oracle/diag/rdbms/ywdb/ywdb1/trace/ywdb1_m001_31997.trc oracle@fyhis1 (M001) UNKNOWN a78s414xwpn92 ACTIVE alter system kill session '3958,15327' immediate; --//注意:STATUS=ACTIVE,也就是SQL_ID=a78s414xwpn92还在运行. 实例1> @ sql_id a78s414xwpn92 --SQL_ID = a78s414xwpn92 SELECT MAX(TOTAL_MB), MIN(TOTAL_MB), SUM(TOTAL_MB), COUNT(*) FROM V$ASM_DISKGROUP; --//也就是前面运行的sql语句(sql_id=a78s414xwpn92)一直在运行,没有执行完成,这样实例1一直持有enq FU的enquence没有释放. --//手工打开新的回话,尝试手工执行该sql语句很慢,好像挂起一样,kill该回话.继续分析. --//SELECT MAX(TOTAL_MB), MIN(TOTAL_MB), SUM(TOTAL_MB), COUNT(*) FROM V$ASM_DISKGROUP; --//实例1执行: 实例1> @ bgx mmon PROGRAM MODULE ACTION SID PID SPID -------------------------- ------------ ------------------- ---- ------- ------ oracle@fyhis1 (MMON) 7897 28 25038 实例1> @ bgx m001 PROGRAM MODULE ACTION SID PID SPID -------------------------- ------------ ------------------- ---- ------- ------ oracle@fyhis1 (M001) MMON_SLAVE 0000009 FINISHED190 3958 430 31997 --//ACTION='0000009 FINISHED190' 什么意思. --//实例2执行: 实例2> @ bgx mmon PROGRAM MODULE ACTION SID PID SPID -------------------------- ------------ ------------------- ---- ------- ------ oracle@fyhis2 (MMON) 7897 28 17152 实例2> @ bgx m001 no rows selected --//实际上到这里也基本知道出现enq: FU - contention等待事件的原因.主要是执行sql_id=a78s414xwpn92一直无法完成,导致 --//实例1一直持有enq: FU的enquence,这样实例2再次执行(间隔1小时)时无法获取enq: FU的enquence,一直在不断的请求, --//120秒后直接kill m001模块. --//实例2报***KEWFDBFUS: Auto-DBFUS slave failed, return Code: 2. --//实例1报: --//Unable to schedule a MMON slave at: Auto DBFUS Main --// Slave was not permitted to be scheduled --// - A slave for this action is already running. --//Unable to schedule a MMON slave at: Auto DBFUS Main --//剩下的问题是分析为什么sql_id=a78s414xwpn92无法执行完成.另外写一篇blog分析. --//我简单看了一下查询V$ASM_DISKGROUP就是访问基表 X$KFGRP,我单独查询 --//select * from X$KFGRP where rownum=1; --//会话都会挂起,我在其它rac环境做了类似测试,执行都很快完成,看来也许是访问权限出了问题。尝试gdb跟踪: # rlwrap gdb -f -p 21329 --//提示如下。新升级的版本gdb要使用很麻烦,暂时放弃探究。 Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64 libaio-0.3.107-10.el6.x86_64 numactl-2.0.7-8.el6.x86_64 --//另外说明一下m001对应的进程是可以kill掉的. 实例1> @ bgkill m001 INDX KSUPRPNM PROCESS_FLAG KSUPRPID ---------- ------------------------------ ----------------- ------------------------ 430 oracle@fyhis1 (M001) 2 31997 --//即使kill掉该进程,也应该没用,因为再次执行时还是要执行sql_id=a78s414xwpn92,从前面的手工执行的情况看该语句执行很慢.因为 --//还会出现enq: FU -contention 等待事件.要想不再出现可以修改_swrf_mmon_dbfus=false. 实例2> @ hide dbfus NAME DESCRIPTION DEFAULT_VALUE SESSION_VALUE SYSTEM_VALUE ISSES ISSYS_MOD ---------------- ----------------------------------------- ------------- ------------- ------------ ----- --------- _swrf_mmon_dbfus Enable/disable SWRF MMON DB Feature Usage TRUE TRUE TRUE FALSE IMMEDIATE _swrf_test_dbfus Enable/disable DB Feature Usage Testing TRUE FALSE FALSE FALSE IMMEDIATE --//alter system set "_swrf_mmon_dbfus"=false scope=memory; --//安全一点先尝试如下: --//alter system disable restricted session; --//alter system enable restricted session; $ ps -fp 31997 UID PID PPID C STIME TTY TIME CMD oracle 31997 1 0 May14 ? 00:00:06 ora_m001_ywdb1 $ kill -9 31997 --//select * from X$KFGRP where rownum=1; --//会话都会挂起。 实例1> alter system set "_swrf_mmon_dbfus"=false scope=memory; System altered. --//先临时关闭它看看。 4.附上使用的脚本. $ cat bgx.sql select s.program, s.module, s.action, s.sid, p.pid, p.spid from v$session s, v$process p where s.paddr=p.addr and S.PROGRAM like upper('%&1%') and p.background=1 order by s.program; $ cat bgkill.sql column KSUPRPNM format a30 SELECT indx,ksuprpnm,TO_CHAR(ksuprflg,'XXXXXXXXXXXXXXXX') process_flag,KSUPRPID FROM x$ksupr WHERE BITAND(ksuprflg,4) != 4 and KSUPRPID is not null and ksuprpnm like upper('%&&1%') ORDER BY indx ; $ cat enq.sql column EQ_NAME format a30 column REQ_REASON format a36 column REQ_DESCRIPTION format a100 select * from v$enqueue_statistics where EQ_TYPE like upper('%&&1%') or REQ_DESCRIPTION like '%&&1%';
[20220518]enq FU - contention等待事件.txt
来源:这里教程网
时间:2026-03-03 17:38:56
作者:
编辑推荐:
- [20220518]enq FU - contention等待事件.txt03-03
- 【ASK_ORACLE】RAC节点自动重启但日志里未报错的原因和解决方法03-03
- oracle锁级别相关测试03-03
- [20220519]完善tpt dash_wait_chains2.sql脚本.txt03-03
- 虎牙斗鱼“同病相怜”03-03
- Oracle 查询占用临时表空间大的历史会话和SQL03-03
- ORA-14047 报错03-03
- 数据库之泪第一章节03-03
下一篇:
相关推荐
-
雷神推出 MIX PRO II 迷你主机:基于 Ultra 200H,玻璃上盖 + ARGB 灯效
2 月 9 日消息,雷神 (THUNDEROBOT) 现已宣布推出基于英
-
制造商 Musnap 推出彩色墨水屏电纸书 Ocean C:支持手写笔、第三方安卓应用
2 月 10 日消息,制造商 Musnap 现已在海外推出一款 Oce
热文推荐
- 虎牙斗鱼“同病相怜”
虎牙斗鱼“同病相怜”
26-03-03 - 电动牙刷博弈:素士、Usmile们合纵连横
电动牙刷博弈:素士、Usmile们合纵连横
26-03-03 - 手持网络性能以太网测试怎么选?
手持网络性能以太网测试怎么选?
26-03-03 - 主键可以重复?
主键可以重复?
26-03-03 - 一个非常老但是很有用的功能-闪回
一个非常老但是很有用的功能-闪回
26-03-03 - 工业机器人如何保证网络性能
工业机器人如何保证网络性能
26-03-03 - oracle rac 12彻底删除,彻底删除该死的rac
oracle rac 12彻底删除,彻底删除该死的rac
26-03-03 - dblink的关联与本地关联差异
dblink的关联与本地关联差异
26-03-03 - 费控SaaS:告别拓荒、迈向生态竞争
费控SaaS:告别拓荒、迈向生态竞争
26-03-03 - 批量删除大量小文件
批量删除大量小文件
26-03-03
