探究隐含参数_fairness_threshold


首先说明_fairness_threshold参数仅在RAC环境下才有意义,让我对这个参数引起关注是在某一次查询v$cr_block_server时,发现该视图有一个名为FAIRNESS_DOWN_CONVERTS的字段,官方文档里将其解释为:Number of times an instance receiving a request has down-converted an X lock on a block because it was not modifying the block

该参数相关性能指标在AWR的"Global CR Served Stats"章节里也有出现:



根据我的理解,将FAIRNESS_DOWN_CONVERTS的含义翻译为:RAC环境下的实例A对某个block在buffer cache里加上了Exclusive锁,但实例A此时并没有在修改该block,实例B请求从实例A的buffer cache里读访问这个block,实例A接收到请求后先将这个block上的Exclusive锁降级转换后再传输给实例B,降级转换一次,FAIRNESS_DOWN_CONVERTS值就+1。


要完全理解上述概念,我们至少需要搞清楚以下几个问题:
1、实例B为何要从实例A的buffer cache里访问这个block?
2、实例A既然没有在修改这个block,为何会对block持有Exclusive锁?
3、锁降级转换目的在于?是否每一次跨实例传输block前都需要先进行锁降级转换?


逐个问题进行解答:
1、实例B为何要从实例A的buffer cache里访问这个block?
RAC里所有实例的buffer cache通过高速专网进行互联,Cache Fusion机制将各实例的buffer cache在逻辑上聚合成一个整体,当某个实例要访问的block已被其它实例访问过且仍保留在那个实例的bffer cache里时,只要block的内容能够满足请求实例的访问要求,该block就会通过高速专网从持有实例的buffer cache传输到请求实例的buffer cache里,避免了请求实例从磁盘进行读取。这之中有一个重要前提必须满足,那就是保证持有实例block的内容是适合传输给请求实例的。换而言之,实例A要读取的block在实例B的buffer cache里,但若实例B Buffer cache里的内容是N久之前的版本,这时实例A就只能从磁盘读取了,异或者实例C的Buffer Cache拥有该block的较新版本,那么实例A就会舍弃实例B和磁盘而从实例C读取。如何为实例A选择最为合适的数据源,确保其能快速得到准确的查询结果?一切尽在Global Resource Directory,简称GRD,只在RAC里才有的GRD其实就是SGA里的一块内存区域存放内容包括了Global enqueue resource和Global cache resources,每个实例buffer cache里的block就属于global cache resource,每个block都有自己的master node,master node上的GRD里准确记录了这个block版本生成时的SCN、各节点持有的block锁类型等信息,可以通过gv$ges_resource视图查看block的master node是那个,比如对于scott.t0820_1表所在的block 6/255,其master_node为实例1:
select dbms_rowid.rowid_relative_fno(rowid) rfno,dbms_rowid.rowid_block_number(rowid) blkno from scott.t0820_1;
      RFNO      BLKNO
---------- ----------
         6        255


select to_char(6,'xxx'),to_char(255,'xxx') from dual;
TO_C TO_C
---- ----
   6   ff


select inst_id,resource_name,ON_GRANT_Q,ON_CONVERT_Q,master_node from gv$ges_resource where resource_name like '[0xff][0x6],[BL]%';
   INST_ID RESOURCE_NAME                  ON_GRANT_Q ON_CONVERT_Q MASTER_NODE
---------- ------------------------------ ---------- ------------ -----------
         1 [0xff][0x6],[BL][ext 0x0,0x0]           1            0           0     <---master_node=0表示实例1


假设一个四节点的RAC环境,block 6/255 存在于实例2的buffer cache里,也存在于实例4的buffer cache里,当实例3要查询这个block时,先根据特定的hash算法找到block的master node也就是实例1,实例1访问自己的GRD后得知实例2 buffer cache里的block刚修改过其SCN号比实例4里的要大,而比实例3查询发起时的SCN要小,所以实例1通知node 2将block传输给实例3,大致过程如下图所示:




① S实例3要查询block 6/255的内容,经过一定的hash算法得出block 6/255的master node是实例1,于是实例3向实例1发起查询block 6/255,此时的Query SCN=107
② 实例1查询GRD后得知实例2上存在的block 6/255版本比实例4更新,更适合作为结果传递给实例1,所以实例1通知实例2要求其将该block传输给实例3
③ 实例2将自己buffer cache里的block 6/255传输给实例3


RAC环境的各个实例都会存放一部分GRD信息,具体位置是在shared pool里,可以使用下面的语句了解这部分的内存占用情况:
SELECT name,bytes FROM v$sgastat WHERE name LIKE 'ges resource%' OR name LIKE 'ges enqueues';
NAME                            BYTES
-------------------------- ----------
ges resource pools                744
ges resource hash seq tab       16384
ges enqueues                 11550936
ges resource                  5708880
ges resource hash table        720896


2、实例A既然没有在修改这个block,为何会对block持有Exclusive锁?
和单实例数据一样,多实例的RAC环境下对block的访问也需要获得各种锁,单实例与多实例锁的对应关系如下:

单实例   多实例
NULL     KJUSERNL
RS       KJUSERCR
RX       KJUSERCW
S        KJUSERPR
SRX      KJUSERPW
X       KJUSEREX


其中KJUSERPR表示Protected read,KJUSEREX表示One process holds exclusive lock,我们暂只关注这两种锁。
通过一个小实验来了解一下KJUSERPR和KJUSEREX在什么情况下会出现


实例1:
create table scott.t0820_1 (id number);
insert into scott.t0820_1 values(1);
commit;
select * from scott.t0820_1;
        ID
----------
         1
         
select distinct dbms_rowid.rowid_relative_fno(rowid) fno,dbms_rowid.rowid_block_number(rowid) blkno from scott.t0820_1;
       FNO      BLKNO
---------- ----------
         6        255
         
alter system flush buffer_cache;
update scott.t0820_1 set id=2 where id=1;
commit;


set heading on 
select inst_id,file#,block#,status from gv$bh where file#=6 and block#=255 and status!='free';
   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         1          6        255 xcur
         1          6        255 cr


select value from v$diag_info where name='Default Trace File';


VALUE
--------------------------------------------------------------------------------
/oracle/app/oracle/diag/rdbms/susedb1/susedb11/trace/susedb11_ora_8474.trc




alter system dump datafile 6 block 255;


在dump文件susedb11_ora_8474.trc的尾端可以看到block 6/255在GRD里的部分信息:
GLOBAL CACHE ELEMENT DUMP (address: 0x8afaeaa8):
  id1: 0xff id2: 0x6 pkey: OBJ#15976 block: (6/255)
  lock: X rls: 0x0 acq: 0x0 latch: 4                     <---注意这里lock: X代表了block上锁类型为KJUSEREX
  flags: 0x20 fair: 0 recovery: 0 fpin: 'kdswh11: kdst_fetch'
  bscn: 0x0.0 bctx: (nil) write: 0 scan: 0x0
  lcp: (nil) lnk: [NULL] lch: [0xadf5b3b0,0xadf5b3b0]
  seq: 18 hist: 58 145:0 28 340 66 144:0 7 352 197 48 121 113 424
  LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:
    flg: 0x02000001 state: XCURRENT tsn: 6 tsh: 2
      addr: 0xadf5b278 obj: 15976 cls: DATA bscn: 0x0.186dfc
      
在update语句commit后我们看到buffer cache里出现了block 6/255的两个版本,标示为cr的是update之前的before-image,标示为xcur的正是修改后的最新版本,xcur表示exclusive current,说明该block刚被更新过,buffer cache和磁盘上的内容可能不一样(checkpoint尚未发生)也有可能已经一样了(已发生checkpoint)。从上面的这段实验内容可以看出尽管update所在事务已经提交但实例1还是持有着block 6/255上的exclusive锁,虽然没有释放,但并不会影响其它实例对于block 6/255的访问,后面会有对这个问题的解释。


alter system flush buffer_cache;
select * from scott.t0820_1;


        ID
----------
         2


select inst_id,file#,block#,status from gv$bh where file#=6 and block#=255 and status!='free';


   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         1          6        255 scur


第二次flush buffer cache后紧接着作一次查询,观察到 block 6/255在buffer cache里的类型变为了scur,scur表示shared current,说明该block在buffer cache和磁盘里的内容一致。


再次dump后可以看到block上的锁相应变成了Lock: S
alter system dump datafile 6 block 255;


GLOBAL CACHE ELEMENT DUMP (address: 0x8afaeaa8):
  id1: 0xff id2: 0x6 pkey: OBJ#15976 block: (6/255)
  lock: S rls: 0x0 acq: 0x0 latch: 4                      <---lock: S
  flags: 0x20 fair: 0 recovery: 0 fpin: 'kdswh01: kdstgr'
  bscn: 0x0.0 bctx: (nil) write: 0 scan: 0x0 
  lcp: (nil) lnk: [NULL] lch: [0xa9f1c290,0xa9f1c290]
  seq: 28 hist: 66 144:0 7 352 197 48 121 113 424 180 58 145:0 28
  LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:
    flg: 0x00080000 state: SCURRENT tsn: 6 tsh: 1
      addr: 0xa9f1c158 obj: 15976 cls: DATA bscn: 0x0.186dfc


这个小实验说明,最后修改过某个block的实例即便事务已经提交仍会在这个block上留下Exclusive锁,当然这个Exclusive锁是可以转换成其它类型的,比如在checkpoint后会被scur取代


3、锁降级转换目的在于?是否每一次跨实例传输block前都需要先进行锁降级转换?
锁降级转换指的是buffer cache中的block状态从xcur转换为scur,考虑一下这个场景:
实例3为block A的master node,实例1会话修改了block A,此事实例1对block A持有Exclusive锁,在v$bh里的buffer类型是xcur,之后实例2会话把select访问Block A的请求递交给实例3,实例3根据GRD里的资源信息发现实例1 buffer cache里的block A的xcur版本能满足实例2的查询要求,于是通知实例1将其buffer cache里的block A传送给实例2,按照一般的思路,实例1在向实例2传输前需要将Exclusive锁转换成Share模式的锁(因为实例2是select访问),然后再传输给实例2。但考虑到既然实例1修改了block A,其再次修改Block A的可能性还是很大的,如果将Exclusive锁转换成Share锁,后续实例1再次修改block A时又需要从Share转回Exclusive,在维护GRD的层面还是会产生不少开销的。所以实例1在首次将block A传送给实例2时并不会将其持有Exclusive锁释放或者转换成其它类型,而是基于xcur类型的block A版本构造出一个类型为cr的buffer(内容与xcur类型的buffer完全一样),将这个cr block传送到实例2的buffer cache里,实例2访问cr block时无需加任何的锁,但oracle为了加以区分还是上了一个NULL类型的锁,准确的说它是一个placeholder类型的lock,在GRD里这个锁的名字是KJUSERNL。这种处理方式显然能够保留实例1对block持有的Exclusive锁。但为此产生的代价是:从xcur构造出cr类型的block也是会产生一定开销的,这其中包括
(1) build cr block的时间
(2) build cr block过程中产生的redo写入online redolog的时间
一种较为极端的情况是若实例2后面对同一个block连续发起多次select操作,会引发实例1多次构造cr block的动作。于是Oracle在保留Exclusive锁与构造cr block间作了一个折衷,提供了隐含参数_fairness_threshold,当select访问次数达到参数指定值的时候,实例1会将block上的Exclusive锁降级转换成Shared锁,对应的buffer也会从xcur转换成scur类型,当实例2第_fairness_threshold+1次访问相同block的时候实例1会把scur类型的block传输到实例2,之后实例2再次访问相同block就只要从本地Buffer cache获取。


我们还是通过具体实验来体会一下_fairness_threshold参数的作用,其中需要用到的rec.sql脚本内容如下:
***************
* rec.sql脚本内容
***************
set heading off
select '----gv$cr_block_server----' from dual;
set heading on 
select inst_id,fairness_down_converts,fairness_clears,light_works from gv$cr_block_server order by inst_id;
set heading off
select '----gv$bh----' from dual;
set heading on 
select inst_id,file#,block#,status from gv$bh where file#=6 and block#=231 and status!='free';
set heading off
select '----x$bh----' from dual;
set heading on 
col object_name format a20
set linesize 80
select inst_id,dbarfil,dbablk,CR_SCN_BAS,DECODE(state,0,'free',1,'xcur',2,'scur',3,'cr', 4,'read',5,'mrec',6,'irec',7,'write',8,'pi', 9,'memory',10,'mwrite',11,'donated', 12,'protected', 13,'securefile', 14,'siop',15,'recckpt', 16, 'flashfree', 17, 'flashcur', 18, 'flashna') state_name,tch from x$bh where dbarfil=6 and dbablk=231 and state!=0;


///////////////////////////////////
// 场景1:_fairness_threshold=2(默认值)
///////////////////////////////////
session说明:其中session 1 node X是真正参与测试的session,session 2 node X是专用来观察相关视图内容,获取测试相关信息的session


---session 1 node 1:修改其中一条记录后commit;
alter system set optimizer_dynamic_sampling=0 scope=memory;


select * from scott.testfn_0730;
        ID COL2
---------- ----
         1 A
         2 B


select distinct dbms_rowid.rowid_relative_fno(rowid) fno,dbms_rowid.rowid_block_number(rowid) blkno from scott.testfn_0730;
       FNO      BLKNO
---------- ----------
         6        231


update scott.testfn_0730 set col2='a' where id=1;
commit;


---session 2 node 1: 查询_fairness_threshold参数值,记录buffer cache里block的状态,DOWN_CONVERTS次数,light_works次数
col ksppinm format a30
col ksppstvl format a20
col ksppdesc format a60
col ksppstcmnt format a20
set linesize 200
select x.inst_id,ksppinm,ksppity,ksppstvl,ksppdesc from x$ksppi x, x$ksppcv y where (x.indx = y.indx) and ksppinm in ('_fairness_threshold');
   INST_ID KSPPINM                           KSPPITY KSPPSTVL             KSPPDESC
---------- ------------------------------ ---------- -------------------- ------------------------------------------------------------
         1 _fairness_threshold                     3 2                    number of times to CR serve before downgrading lock   


@rec.sql
----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                      4               0           0     <---node 1初始down_converts次数为4
         2                      4               0           0




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         1          6        231 xcur   <---session 1 node 1 update之后在buffer cache里留下了xcur、cr两个block,其中cr是block修改前的映像,xcur是当前最新的block映像
         1          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME
---------- ---------- ---------- ---------- ----------
         1          6        231          0 xcur
         1          6        231    1276027 cr             <---1276027是cr生成时的scn
         
---session 1 node 2:第一次访问testfn_0730表
select * from scott.testfn_0730;
        ID COL2
---------- ----
         1 a
         2 B


---session 2 node 2: 记录buffer cache里block的状态,DOWN_CONVERTS次数,light_works次数
@rec.sql
----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                      4               0           0     <---down_converts次数未发生变化
         2                      4               0           0




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         1          6        231 xcur
         1          6        231 cr
         2          6        231 cr   <---node 2 buffer cache新增一类型为cr的block,正是由node 1以其xcur型block为基础构造出来传输至node 2的




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME
---------- ---------- ---------- ---------- ----------
         2          6        231    1276334 cr                <---node 2上cr block scn=1276334代表了其从xcur构造而来那一刻的系统scn号


---session 2 node 1: data block dump on node 1
select value from v$diag_info where name='Default Trace File';


VALUE
--------------------------------------------------------------------------------
/oracle/app/oracle/diag/rdbms/susedb1/susedb11/trace/susedb11_ora_16988.trc


alter system dump datafile 6 block 231;  <---dump block的内容,仅取出与GC有关的部分
。。。省略部分内容
GLOBAL CACHE ELEMENT DUMP (address: 0x89f9b978):
  id1: 0xe7 id2: 0x6 pkey: OBJ#15930 block: (6/231)
  lock: X rls: 0x0 acq: 0x0 latch: 6                             <--- node1:lock: X 表示block上有Exclusive锁
  flags: 0x20 fair: 1 recovery: 0 fpin: 'kdswh11: kdst_fetch'
  bscn: 0x0.0 bctx: (nil) write: 0 scan: 0x0
  lcp: (nil) lnk: [NULL] lch: [0xadf5d770,0xadf5d770]
  seq: 11 hist: 113 424 180 58 145:0 118 66 144:0 192 352 32
  LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:
    flg: 0x02200000 state: XCURRENT tsn: 6 tsh: 2
      addr: 0xadf5d638 obj: 15930 cls: DATA bscn: 0x0.13787d
。。。省略部分内容


---session 2 node 2: data block dump on node 2
select value from v$diag_info where name='Default Trace File';


VALUE
--------------------------------------------------------------------------------
/oracle/app/oracle/diag/rdbms/susedb1/susedb12/trace/susedb12_ora_18928.trc


alter system dump datafile 6 block 231;  <---dump block的内容
。。。省略部分内容
GLOBAL CACHE ELEMENT DUMP (address: 0x89f9df78):
  id1: 0xe7 id2: 0x6 pkey: OBJ#15930 block: (6/231)
  lock: C rls: 0x0 acq: 0x0 latch: 6    <--- node2:lock: C 其中的C代表Consistent,表示这个block是处于consistent read目的而生成的,其不能被服用,所以block上的锁类型为KJUSERNL,KJUSERNL是一个placeholder类型的锁
  flags: 0x21 fair: 0 recovery: 0 fpin: 'kdswh11: kdst_fetch'
  bscn: 0x0.0 bctx: (nil) write: 0 scan: 0x0
  lcp: (nil) lnk: [NULL] lch: [0x8af7e248,0xadffd5a8]
  seq: 6 hist: 329 144:6 14 7 352 32
。。。省略部分内容


---session 1 node 2:第二次访问testfn_0730表
@rec.sql
----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                      4               0           0
         2                      4               0           0




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         1          6        231 xcur
         1          6        231 cr
         2          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME
---------- ---------- ---------- ---------- ----------
         2          6        231    1276334 cr
         
select * from scott.testfn_0730;
        ID COL2
---------- ----
         1 a
         2 B


---session 2 node 2: 记录buffer cache里block的状态,DOWN_CONVERTS次数
@rec.sql
----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                      5               0           0          <---node 1的down convert次数从4增加到了5,发生了一次锁降级转换
         2                      4               0           0




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         1          6        231 scur              <---node 1的xcur降级成了scur
         1          6        231 cr
         2          6        231 cr
         2          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME
---------- ---------- ---------- ---------- ----------
         2          6        231    1277433 cr            <---node 2上新增了一个SCN=1277433的cr,这个cr是在node 1上的xcur降级成scur之前构造出来的
         2          6        231    1276334 cr            <---这是第一次select后生成的cr


---session 2 node 1: 记录buffer cache里block的状态,DOWN_CONVERTS次数
@rec.sql
----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                      6               0           0   <---node 1的down convert次数从5增加到了6,不清楚这次锁降级转换是由哪个block触发的,但可以肯定与scott.testfn_0730表无关
         2                     22               1           0   <---node 2 down convert次数也从之前的4上升到22,也与scott.testfn_0730表无关,这里我们不必关注




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         1          6        231 scur
         1          6        231 cr
         2          6        231 cr
         2          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME
---------- ---------- ---------- ---------- ----------
         1          6        231          0 scur
         1          6        231    1276027 cr




---session 2 node 1: data block dump on node 1
select value from v$diag_info where name='Default Trace File';


VALUE
--------------------------------------------------------------------------------
/oracle/app/oracle/diag/rdbms/susedb1/susedb11/trace/susedb11_ora_19706.trc


alter system dump datafile 6 block 231;  <---dump block的内容,仅选取与GC有关的部分
。。。省略部分内容
GLOBAL CACHE ELEMENT DUMP (address: 0x89f9b978):
  id1: 0xe7 id2: 0x6 pkey: OBJ#15930 block: (6/231)
  lock: S rls: 0x0 acq: 0x0 latch: 6                           <---block dump结果容易看出node 1对block 6/231持有的锁已从lock : X降级为lock : S
  flags: 0x20 fair: 0 recovery: 0 fpin: 'kdswh11: kdst_fetch'
  bscn: 0x0.0 bctx: (nil) write: 0 scan: 0x0
  lcp: (nil) lnk: [NULL] lch: [0xadf5d770,0xadf5d770]
  seq: 14 hist: 45 4 54 113 424 180 58 145:0 118 66 144:0 192 352 32
  LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:
    flg: 0x02200000 state: SCURRENT tsn: 6 tsh: 2
      addr: 0xadf5d638 obj: 15930 cls: DATA bscn: 0x0.13787d
。。。省略部分内容


---session 2 node 2: data block dump on node 2
select value from v$diag_info where name='Default Trace File';


VALUE
--------------------------------------------------------------------------------
/oracle/app/oracle/diag/rdbms/susedb1/susedb12/trace/susedb12_ora_20858.trc


alter system dump datafile 6 block 231;  <---dump block的内容
。。。省略部分内容
GLOBAL CACHE ELEMENT DUMP (address: 0x89f9df78):
  id1: 0xe7 id2: 0x6 pkey: OBJ#15930 block: (6/231)
  lock: C rls: 0x0 acq: 0x0 latch: 6                                  <---node 2还是保持为lock: C,即KJUSERNL锁
  flags: 0x21 fair: 0 recovery: 0 fpin: 'kdswh11: kdst_fetch'
  bscn: 0x0.0 bctx: (nil) write: 0 scan: 0x0
  lcp: (nil) lnk: [NULL] lch: [0x8af954c8,0xadffd5a8]
  seq: 11 hist: 329 144:6 14 7 352 329 144:6 14 7 352 32
。。。省略部分内容  


---session 1 node 2:第三次访问testfn_0730表,发现多出了类型为scur的buffer
select * from scott.testfn_0730;
        ID COL2
---------- ----
         1 a
         2 B


---session 2 node 2: 记录buffer cache里block的状态,DOWN_CONVERTS次数
@rec.sql
----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                      7               0           0     <---比上一次增加了1
         2                     27               1           0




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         2          6        231 scur         <---node 2新生成出了一个scur,这个scur是从node 1传输过来的(node 1上的scur刚从xcur降级而来),scur表示该block在内存中的内容与磁盘上的内容一致
         2          6        231 cr
         2          6        231 cr
         1          6        231 scur
         1          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME
---------- ---------- ---------- ---------- ----------
         2          6        231          0 scur
         2          6        231    1277433 cr
         2          6        231    1276334 cr


---session 2 node 1: 记录buffer cache里block的状态,DOWN_CONVERTS次数
@rec.sql
----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                      7               0           0
         2                     27               1           0




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         2          6        231 scur         
         2          6        231 cr
         2          6        231 cr
         1          6        231 scur
         1          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME
---------- ---------- ---------- ---------- ----------
         1          6        231          0 scur
         1          6        231    1276027 cr


---session 2 node 1: data block dump on node 1
select value from v$diag_info where name='Default Trace File';


VALUE
--------------------------------------------------------------------------------
/oracle/app/oracle/diag/rdbms/susedb1/susedb11/trace/susedb11_ora_21738.trc


alter system dump datafile 6 block 231;  <---dump block的内容,仅显示与GC有关的部分
。。。省略部分内容
GLOBAL CACHE ELEMENT DUMP (address: 0x89f9b978):
  id1: 0xe7 id2: 0x6 pkey: OBJ#15930 block: (6/231)
  lock: S rls: 0x0 acq: 0x0 latch: 6                              <---node1对block的锁维持lock: S
  flags: 0x20 fair: 0 recovery: 0 fpin: 'kdswh11: kdst_fetch'
  bscn: 0x0.0 bctx: (nil) write: 0 scan: 0x0
  lcp: (nil) lnk: [NULL] lch: [0xadf5d770,0xadf5d770]
  seq: 16 hist: 227 160 45 4 54 113 424 180 58 145:0 118 66 144:0 192
  LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:
    flg: 0x02200000 lflg: 0x2 state: SCURRENT tsn: 6 tsh: 1
      addr: 0xadf5d638 obj: 15930 cls: DATA bscn: 0x0.13787d
。。。省略部分内容


---session 2 node 2: data block dump on node 2
select value from v$diag_info where name='Default Trace File';


VALUE
--------------------------------------------------------------------------------
/oracle/app/oracle/diag/rdbms/susedb1/susedb12/trace/susedb12_ora_22849.trc


alter system dump datafile 6 block 231;  <---dump block的内容
。。。省略部分内容
GLOBAL CACHE ELEMENT DUMP (address: 0x89f9df78):
  id1: 0xe7 id2: 0x6 pkey: OBJ#15930 block: (6/231)
  lock: S rls: 0x0 acq: 0x0 latch: 6 <---node 2上持有的锁从lock: C变为了lock: S,因为node 2有了自己的scur block
  flags: 0x20 fair: 0 recovery: 0 fpin: 'kdswh11: kdst_fetch'
  bscn: 0x0.0 bctx: (nil) write: 0 scan: 0x0
  lcp: (nil) lnk: [NULL] lch: [0xabf5f310,0xabf5f310]
  seq: 16 hist: 227 144:0 213 7 352 329 144:6 14 7 352 329
  LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:
    flg: 0x08080000 state: SCURRENT tsn: 6 tsh: 1
      addr: 0xabf5f1d8 obj: 15930 cls: DATA bscn: 0x0.13787d
。。。省略部分内容          


---session 1 node 2:第四次访问testfn_0730表,从第四次开始往后每次都是访问scur这个buffer
select * from scott.testfn_0730;
        ID COL2
---------- ----
         1 a
         2 B


---session 2 node 2: 记录buffer cache里block的状态,DOWN_CONVERTS次数
SQL> @rec.sql


----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                     37               2           1
         2                     40               1           0




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         1          6        231 scur
         1          6        231 cr
         2          6        231 scur
         2          6        231 cr
         2          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME        TCH
---------- ---------- ---------- ---------- ---------- ----------
         2          6        231          0 scur                3   <---scur的访问次数一直在增加
         2          6        231    1277433 cr                  1
         2          6        231    1276334 cr                  1


---session 3 node 2:node 2上新开一个session访问testfn_0730表,发现也都是访问scur这个buffer,此时已不需要从远程实例cache里进行传输
select * from scott.testfn_0730;
         
SQL> @rec.sql


----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                     44               2           1
         2                     40               1           0




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         1          6        231 scur              <---node 1、node 2的buffer数量没有再增加
         1          6        231 cr
         2          6        231 scur
         2          6        231 cr
         2          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME        TCH
---------- ---------- ---------- ---------- ---------- ----------
         2          6        231          0 scur                4     <---tch数量的不断上升表明node 2对block 6/231的访问最后都落到了scur block上
         2          6        231    1277433 cr                  1
         2          6        231    1276334 cr                  1


小结一下:
_fairness_threshold=2时,当node 2第2次访问node 1 buffer cache里的block时,buffer cache里该block的类型从xcur转换成scur,v$cr_block_server.FAIRNESS_DOWN_CONVERTS计数器加1;node 1持有的锁从Exclusive转换为Share,node 2持有的锁仍然是KJUSERNL;尽管如此,node 1仍然会构造出一个cr block传送给node 2,我们能在node 2的buffer cache里看到这个cr block;node 2第3次访问block时,node 2 buffer cache里才会新增一个从node 1传输而来的scur block,并且持有锁的类型也从KJUSERNL变为了Share。如果block内容一直不被更改,从_fairness_threshold+2轮查询开始node 2可在其本地的buffer cache里直接访问到该scur类型的block,不必从远程的node 1节点获得


下面看看_fairness_threshold=3的时候,是否遵循上述规律
///////////////////////////////
// 场景2:修改_fairness_threshold=3
///////////////////////////////
session说明:其中session 1 node X是真正参与测试的session,session 2 node X是专用来观察相关视图内容,获取测试相关信息的session


---session 1 node 1:修改其中一条记录后commit;
alter system set optimizer_dynamic_sampling=0 scope=memory;


select * from scott.testfn_0730;
        ID COL2
---------- ----
         1 A
         2 B


select distinct dbms_rowid.rowid_relative_fno(rowid) fno,dbms_rowid.rowid_block_number(rowid) blkno from scott.testfn_0730;
       FNO      BLKNO
---------- ----------
         6        231


update scott.testfn_0730 set col2='a' where id=1;
commit;


---session 2 node 1: 查询_fairness_threshold参数值,记录buffer cache里block的状态,DOWN_CONVERTS次数,light_works次数
col ksppinm format a30
col ksppstvl format a20
col ksppdesc format a60
col ksppstcmnt format a20
set linesize 200
select x.inst_id,ksppinm,ksppity,ksppstvl,ksppdesc from x$ksppi x, x$ksppcv y where (x.indx = y.indx) and ksppinm in ('_fairness_threshold');
   INST_ID KSPPINM                           KSPPITY KSPPSTVL             KSPPDESC
---------- ------------------------------ ---------- -------------------- ------------------------------------------------------------
         1 _fairness_threshold                     3 3                    number of times to CR serve before downgrading lock


@rec.sql
----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                     28               4           0
         2                     53               1           8




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         1          6        231 xcur
         1          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME        TCH
---------- ---------- ---------- ---------- ---------- ----------
         1          6        231          0 xcur                2
         1          6        231    1800959 cr                  2
           
---session 1 node 2:第一次访问testfn_0730表
select * from scott.testfn_0730;
        ID COL2
---------- ----
         1 a
         2 B


---session 2 node 2: 记录buffer cache里block的状态,DOWN_CONVERTS次数,light_works次数
@rec.sql


----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                     29               4           0
         2                     53               1           8




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         2          6        231 cr            <---node 2第一次访问的是一个cr类型的block由node1构造后传输而来
         1          6        231 xcur
         1          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME        TCH
---------- ---------- ---------- ---------- ---------- ----------
         2          6        231    1800996 cr                  1


---session 1 node 2:第二次访问testfn_0730表         
select * from scott.testfn_0730;
        ID COL2
---------- ----
         1 a
         2 B


---session 2 node 2: 记录buffer cache里block的状态,DOWN_CONVERTS次数
@rec.sql
----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                     41               4           0
         2                     53               1           8




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         2          6        231 cr              <---node 2第二次访问后在buffer cache里有了第二个cr类型的block
         2          6        231 cr
         1          6        231 xcur
         1          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME        TCH
---------- ---------- ---------- ---------- ---------- ----------
         2          6        231    1801011 cr                  1         <---CR_SCN_BAS=1801011对应的cr block是第二次查询所构造出的CR
         2          6        231    1800996 cr                  1 <---CR_SCN_BAS=1800996对应的cr block是第一次查询所构造出的CR


---session 1 node 2:第三次访问testfn_0730表
select * from scott.testfn_0730;
        ID COL2
---------- ----
         1 a
         2 B


---session 2 node 2: 记录buffer cache里block的状态,DOWN_CONVERTS次数
@rec.sql
----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                     42               4           0     <---因为达到了_fairness_threshold所指定的阀值触发了down convert动作,所以FAIRNESS_DOWN_CONVERTS较上次查询的41增加了1
         2                     53               1           8




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         2          6        231 cr
         2          6        231 cr
         2          6        231 cr
         1          6        231 scur                  <---node 1 buffer cache中的xcur转换成了scur
         1          6        231 cr




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME        TCH
---------- ---------- ---------- ---------- ---------- ----------
         2          6        231    1801037 cr                  1      <---第三次查询构造出的cr
         2          6        231    1801011 cr                  1
         2          6        231    1800996 cr                  1
         
---session 2 node 1: data block dump on node 1
select value from v$diag_info where name='Default Trace File';


VALUE
--------------------------------------------------------------------------------
/oracle/app/oracle/diag/rdbms/susedb1/susedb11/trace/susedb11_ora_11782.trc


alter system dump datafile 6 block 231;  <---dump block的内容,仅取出与GC有关的部分
。。。省略部分内容
GLOBAL CACHE ELEMENT DUMP (address: 0x8cfd7568):
  id1: 0xe7 id2: 0x6 pkey: OBJ#15930 block: (6/231)                 
  lock: SG rls: 0x0 acq: 0x0 latch: 6                              <---lock:SG 表示node 1上已经降级成了Share锁,G是global的意思
  flags: 0x20 fair: 0 recovery: 0 fpin: 'kdswh11: kdst_fetch'
  bscn: 0x0.1ac5e4 bctx: (nil) write: 0 scan: 0x0
  lcp: (nil) lnk: [NULL] lch: [0xabf051b0,0xabf051b0]
  seq: 13 hist: 170 1 4 54 58 145:0 28 340 239 144:0 7 352 32
  LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:
    flg: 0x02000001 state: SCURRENT tsn: 6 tsh: 2
      addr: 0xabf05078 obj: 15930 cls: DATA bscn: 0x0.1b7b02 piscn: 0x0.1b7b4d
。。。省略部分内容


---session 2 node 2: data block dump on node 2
select value from v$diag_info where name='Default Trace File';


VALUE
--------------------------------------------------------------------------------
/oracle/app/oracle/diag/rdbms/susedb1/susedb12/trace/susedb12_ora_10722.trc


alter system dump datafile 6 block 231;  <---dump block的内容
。。。省略部分内容
GLOBAL CACHE ELEMENT DUMP (address: 0x8aff9088):
  id1: 0xe7 id2: 0x6 pkey: OBJ#15930 block: (6/231)
  lock: C rls: 0x0 acq: 0x0 latch: 6 <---lock:C 表示node 2持有的还是KJUSERNL类型的锁
  flags: 0x21 fair: 0 recovery: 0 fpin: 'kdswh11: kdst_fetch'
  bscn: 0x0.0 bctx: (nil) write: 0 scan: 0x0
  lcp: (nil) lnk: [NULL] lch: [0xb833b270,0x8afc13c8]
  seq: 22 hist: 329 144:6 14 7 144:5 192 352 329 144:6 14 7
。。。省略部分内容


---session 1 node 2:第四次访问testfn_0730表
select * from scott.testfn_0730;
        ID COL2
---------- ----
         1 a
         2 B


---session 2 node 2: 记录buffer cache里block的状态,DOWN_CONVERTS次数
@rec.sql
----gv$cr_block_server----




   INST_ID FAIRNESS_DOWN_CONVERTS FAIRNESS_CLEARS LIGHT_WORKS
---------- ---------------------- --------------- -----------
         1                     46               4           0
         2                     53               1           8




----gv$bh----




   INST_ID      FILE#     BLOCK# STATUS
---------- ---------- ---------- ----------
         2          6        231 scur                    <---第四轮查询过后node 2上不再生成新的cr,取而代之的是node 1传输过来的scur
         2          6        231 cr
         2          6        231 cr
         2          6        231 cr
         1          6        231 scur
         1          6        231 cr


6 rows selected.




----x$bh----




   INST_ID    DBARFIL     DBABLK CR_SCN_BAS STATE_NAME        TCH
---------- ---------- ---------- ---------- ---------- ----------
         2          6        231          0 scur                1
         2          6        231    1801037 cr                  1
         2          6        231    1801011 cr                  1
         2          6        231    1800996 cr                  1


---session 2 node 1: data block dump on node 1
select value from v$diag_info where name='Default Trace File';


VALUE
--------------------------------------------------------------------------------
/oracle/app/oracle/diag/rdbms/susedb1/susedb11/trace/susedb11_ora_10588.trc


alter system dump datafile 6 block 231;  <---dump block的内容,仅选取与GC有关的部分
。。。省略部分内容
GLOBAL CACHE ELEMENT DUMP (address: 0x8cfd7568):
  id1: 0xe7 id2: 0x6 pkey: OBJ#15930 block: (6/231)
  lock: SG rls: 0x0 acq: 0x0 latch: 6 <---lock:SG node 1上仍然维持Share锁
  flags: 0x20 fair: 0 recovery: 0 fpin: 'kdswh11: kdst_fetch'
  bscn: 0x0.1ac5e4 bctx: (nil) write: 0 scan: 0x0
  lcp: (nil) lnk: [NULL] lch: [0xabf051b0,0xabf051b0]
  seq: 20 hist: 225 212 424 72 257 59 227 170 1 4 54 58 145:0 28 340
  LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:
    flg: 0x02200000 state: SCURRENT tsn: 6 tsh: 2
      addr: 0xabf05078 obj: 15930 cls: DATA bscn: 0x0.1b7b02
。。。省略部分内容


---session 2 node 2: data block dump on node 2
select value from v$diag_info where name='Default Trace File';


VALUE
--------------------------------------------------------------------------------
/oracle/app/oracle/diag/rdbms/susedb1/susedb12/trace/susedb12_ora_11315.trc


alter system dump datafile 6 block 231;  <---dump block的内容
。。。省略部分内容
GLOBAL CACHE ELEMENT DUMP (address: 0x8aff9088):
  id1: 0xe7 id2: 0x6 pkey: OBJ#15930 block: (6/231)
  lock: S rls: 0x0 acq: 0x0 latch: 6                            <---lock:SG node 2从KJUSERNL类的锁转换成Share锁
  flags: 0x20 fair: 0 recovery: 0 fpin: 'kdswh11: kdst_fetch'
  bscn: 0x0.0 bctx: (nil) write: 0 scan: 0x0
  lcp: (nil) lnk: [NULL] lch: [0xabeefc70,0xabeefc70]
  seq: 29 hist: 227 144:0 213 7 144:5 192 352 329 144:6 14 7
  LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:
    flg: 0x08080000 state: SCURRENT tsn: 6 tsh: 1
      addr: 0xabeefb38 obj: 15930 cls: DATA bscn: 0x0.1b7b02
。。。省略部分内容  


小结一下:
_fairness_threshold=3时,当node 2第3次访问node 1 buffer cache里的block时,node 1 buffer cache里该block的类型从xcur转换成scur,v$cr_block_server.FAIRNESS_DOWN_CONVERTS计数器加1;node 1持有的锁从Exclusive转换为Share,node 2持有的锁仍然是KJUSERNL;此时,node 1仍然会构造出一个cr block传送给node 2,我们能在node 2的buffer cache里看到这个cr block;node 2第4次访问block时,node 2 buffer cache里才会新增一个从node 1传输而来的scur block,并且持有锁的类型也从KJUSERNL变为了Share。如果block内容一直不被更改,从_fairness_threshold+2轮查询开始node 2可在其本地的buffer cache里直接访问到该scur类型的block,不必从远程的node 1节点获得


总结:
_fairness_threshold的可以看出oracle研发过程中的精雕细琢,为了在锁转换产生的开销与cr block构造产生的开销之间找到平衡,提供_fairness_threshold参数的同时给了用户一个灵活调节的手段,细节决定成败,Oracle RAC无愧为业界优秀的数据库集群软件

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
    今天看到有一个网友提了一个问题,描述很简短     测试DG时,主库不能宕机,如何测试failover?     其实这个需求从业务层面来说是合理的,一个数据量很大的核心数据库,如果需要做灾难演练,就希望在备库上做一下演练工作,而这个演练其实又不想影响到目前的主库,而且又希望能够尽可能模拟真实的情况,我想这样对于运维部门来说是最具有考核力度,而对于开发业务部门来说是最受欢迎的,因为他们什么都不需要改动。 而从技术角度来看,似乎有一些地方需要考量,如果备库Failover为主库,那么这个主库肯定是可以

简单分析percona-zabbix-templates - 2016-09-01 04:09:15

    当Zabbix和Percona两者相遇,会擦出不少的开源火花来,众人拾柴火焰高,最终受益的还是大部分运维人员。     我很早就用过Percona提供的MySQL监控模板,但是却没有刨根问底,只是简单使用而已,自从定制了Orabbix之后,我还是信心满满,MySQL的数据字典相对要少很多,监控起来可能想必Oracle要少很多,不过关于Percona的这个插件,我还是带着好奇之心,内部是否有很多独门秘籍,我想好好学学那些监控项对应的SQL,好好弥补我对于MySQL监控的一些空缺,所以简单分析这个模板就
问题描述 : 近期的 rman 备份中,归档日志的备份没有被删除, rman 的脚本和策略都没变过,归档的备份一直保留,每过一段时间就要物理删除备份,很是奇怪。 rman的 configure 如下 RMAN show all; RMAN configuration parameters for database withdb_unique_name HUBSRAC are: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; CONFIGURE BACKUP OPTI
一 前言  纳西姆.尼古拉斯.塔勒布的经典著作《黑天鹅》中对“黑天鹅现象”的定义是 - 不可预测,人们事前往往低估其发生的可能性 - 造成极大影响 - 事后回头再看,又觉得此事发生的有理 二 分析   稳定性 是一项衡量基础系统是否永续服务的绝对指标,作为资深DBA从业人员,相信大多数公司运维团队都会制定稳定性的SLA指标达到N个9,为用户提供Full-Time 服务。然而前一段时间各种"黑天鹅”式的因素导致一系列的系统故障,严重影响了C端B端的用户的使用体验。 故 障 是数据库系统或者说业务系统的“脆弱
最近有个同事碰到一个问题,想让我给点思路。我大体了解了一下,是一个系统目前在做压力测试,但是经业务反馈发现某个环节的处理时间有些长,排查了一圈,最后这件事情就落在了DB这边,希望DB能够给点意见,是否存在一些性能瓶颈。     我们从开发同学那里得到的一个基本的SQL语句,根据关键字从v$sql中做了提取,发现对应的SQL语句的执行时间还是OK的。 得到的SQL语句如下: SQL_ID        SQL_FULLTEXT ------------- ---------------------------

Oracle之不可见索引 - 2016-08-27 17:08:09

Oracle 之不可见索引 1    BLOG 文档结构图   2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  Oracle 不可见索引的使用   Tips: ① 本文在 ITpub ( http://blog.itpub.net/26736162 )、博客园 ( http://www.cnblogs.com/lhrbest )和微信公众号( xiaomaimiaolhr )有同步更新
【故障处理】序列 cache 值过小导致 CPU 利用率过高 1    BLOG 文档结构图       2    前言部分 2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~ : ① enq: SQ - contention 等待事件的解决 ② 一般等待事件的解决办法 ③  DFS lock handle 等待事件 ④ 与序列有关的等待事件   Tips: ① 本文在 ITpub ( http://blog.itpub.
这两天做性能测试碰见一个问题,比较有意思。 一条SQL,使用了绑定变量,查看V$SQLAREA发现version_count是2,  查看V$SQL,发现有两条记录,分别对应了0和1两个child cursor:  再查看这两个child cursor对应的执行计划:  child cursor:0 -----------------------------------------------------------------------------------------------------| I

OCP如何查看历史成绩(2) - 2016-08-25 14:08:08

OCP如何查看历史成绩( 2 ) 之前写过一篇文章 OCP如何查看历史成绩: http://blog.itpub.net/26736162/viewspace-1624996/  , 但是现在界面好像有所变动,而且有的连接也找不见了,今天有朋友问如何查询历史的成绩,晚上小麦苗就抽了点时间来找找,顺便记录下来。最近心情不好,不想写技术文章了。       首先登陆网址: https://education.oracle.com/ https://education.oracle.com/pls/eval-e
下午的时候收到这么一条报警。 ZABBIX- 监控系统 : ------------------------------------ 报警内容 : Too many parallel sessions on xxxxx_ xx机房 _xxxxx ------------------------------------ 报警级别 : PROBLEM ------------------------------------ 监控项目 : parallel_session_cnt : 66 -----------