[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%';
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/267265/viewspace-2895255/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- [20261008]验证Shared Memory Segments key以及Semaphore Arrays Key(11g).txt
- [20261008]gdb引入结构体是否可行.txt
- [20261008]bpftrace定义结构体例子.txt
- [20261007]关于oracle sskgph2函数.txt
- [20261007]oracle Semaphore Arrays Key值的冲突.txt
- [20261004]oracle sskgph2函数等价c以及python脚本.txt
- [20261004]bpftrace查看oracle函数调用堆栈问题.txt
- [20261002]验证sskgphpjw函数参与运算的字符串是否存在规律.txt
- [20261002]oracle Semaphore Arrays Key值的计算2.txt
- [20261001]oracle Semaphore Arrays Key值的计算.txt
