[20220518]enq FU - contention等待事件.txt

来源:这里教程网 时间:2026-03-03 17:38:56 作者:

[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%';

相关推荐