Exadata IPCLW traces

最近发现我们新上的exadata的oracle软件安装目录经常磁盘不足，检查发现是由于trace目录下每天产生了大量的日志文件，包括trc和trm结尾的日志。检查了alert日志并未发现任何报错，随便挑了几个日志打开发现都是IPCLW之类的报错

1
2
3
4
5
IPCLW:[0.0]{-}[CNCT]:RDS: [1559712222041287]ipclw_dump_cnh NO sbuf ctx:0x40008baf5fa8 pt:0x4000697677f0 sndh:0x4000697627e8 pid:192.168.10.4:51905
IPCLW:[0.1]{-}[CNCT]:RDS: [1559712222041287]ipclw_dump_cnh NO sbuf ctx:0x40008baf5fa8 pt:0x4000697677f0 sndh:0x400069763b38 pid:192.168.10.4:44710
IPCLW:[0.2]{-}[CNCT]:RDS: [1559712222041287]ipclw_dump_cnh NO sbuf ctx:0x40008baf5fa8 pt:0x4000697677f0 sndh:0x4000697634c8 pid:192.168.10.3:3853
IPCLW:[0.3]{-}[CNCT]:RDS: [1559712222041287]ipclw_dump_cnh NO sbuf ctx:0x40008baf5fa8 pt:0x4000697677f0 sndh:0x400069762e58 pid:192.168.10.4:49112
IPCLW:[0.4]{-}[CNCT]:RDS: [1559712222041287]ipclw_dump_cnh NO sbuf ctx:0x40008baf5fa8 pt:0x4000697677f0 sndh:0x400069762178 pid:192.168.10.3:2035

这套18c的RAC运行在X7-2上，exa版本18.1.13

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
SELECT
 CAST(extract(xmltype(confval), '/cli-output/cell/name/text()') AS VARCHAR2(20))  cv_cellname
  , CAST(extract(xmltype(confval), '/cli-output/cell/releaseVersion/text()') AS VARCHAR2(20))  cv_cellVersion 
  , CAST(extract(xmltype(confval), '/cli-output/cell/kernelVersion/text()')  AS VARCHAR2(30))  kernel_version
  , CAST(extract(xmltype(confval), '/cli-output/cell/makeModel/text()')      AS VARCHAR2(50))  make_model
FROM 
    v$cell_config  
WHERE 
    conftype = 'CELL'
ORDER BY
    cv_cellname
/

CV_CELLNAME      CV_CELLVERSION   KERNEL_VERSION         MAKE_MODEL
-------------------- -------------------- ------------------------------ --------------------------------------------------
xxx01        18.1.13.0.0.190210   4.1.12-124.24.3.el6uek.x86_64  Oracle Corporation ORACLE SERVER X7-2L High Capaci
xxx02        18.1.13.0.0.190210   4.1.12-124.24.3.el6uek.x86_64  Oracle Corporation ORACLE SERVER X7-2L High Capaci
xxx03        18.1.13.0.0.190210   4.1.12-124.24.3.el6uek.x86_64  Oracle Corporation ORACLE SERVER X7-2L High Capaci

本机是没有启用任何trace的，那么每天几千个trace文件是如何产生的呢？

看日志里写的IPCLW并没有什么头绪，后面的IP都是指向的IB的私有地址，看起来像是在dump某种网络连接的信息，根据IPCLW关键字去alert日志里查询到相关内容

1
2
3
4
5
6
KSIPC Available Transports: RC:RDS:UDP:XRC:TCP:UD_RDS
KSIPC: Client: KCL       Transport: XRC
KSIPC: Client: DLM       Transport: RDS
KSIPC CAPABILITIES :MGA:IPCLW:GRPAM:PR:TOPO:DLL:SHREG:STATSFW:CRTRK
KSXP: ksxpsg_ipclwtrans: 1 RDS
cluster interconnect IPC version: [IPCLW over RDS(mode 2) ]

可以确定IPCLW是跟集群之间的通信传输有关了。

在MOS上并没有搜到与IPCLW相关的内容，但是有关于EXADATA中EXAFUSION特性有关的信息。

什么是EXAFUSION

EXAFUSION是一种直接到线的协议，允许数据库进程直接通过IB网络读取和发送Oracle RAC之间的消息，避免了进入OS内核和运行正常网络软件堆栈的开销。从而提升了EXADATA数据库机器上RAC环境之间的响应时间和可伸缩性。数据直接从用户空间传输到了IB网络，降低了CPU使用率，提高了扩展性能。EXAFUSION对于OLTP程序特别有用，因为每个信息的开销在那些小信息量的OLTP环境中特别明显。

这个特性只能在Exadata环境中才能生效。

EXAFUSION必选项

Oracle Exadata Storage Server版本12.1.2.1.1或更新。

Oracle Database 版本12.1.0.2.0 BP11或更新。

开启EXAFUSION

oracle 18及以上，Exafusion默认开启并且无法关闭，初始化参数exafusion_enabled从18.3开始就过时了。

oracle 12.2中, Exafusion默认开启。 Exafusion可以通过设置参数exafusion_enabled=0来关闭。

oracle 12.1, Exafusion默认关闭。 Exafusion可以通过设置参数exafusion_enabled=1来开启。

参数exafusion_enabled无法动态修改,修改后要重启数据库。

RAC环境中所有实例的这个参数值都必须一样，而且无法使用滚动模式来一个个修改，必须得在集群启动之前就修改完毕。

检查Exafusion是否开启

12.2及以上，检查alert日志

1
2
3
4
5
KSIPC: Client: KCL Transport: XRC
KSIPC: Client: DLM Transport: RDS
KSIPC CAPABILITIES :MGA:IPCLW:GRPAM:PR:TOPO:DLL:SHREG
KSXP: ksxpsg_ipclwtrans: 1 RDS
cluster interconnect IPC version: [IPCLW over RDS(mode 2) ]

12.1版本，检查alert日志

1
Exafusion(RDS, XRC) enabled

测试

接下来可以做几个测试来验证这些trace文件是如何产生的。

1
2
3
4
5
SQL> select value from v$diag_info where NAME='Default Trace File';

VALUE
----------------------------------------------------------------------------------------------------
/u01/app/oracle/diag/rdbms/xxx/xxx1/trace/xxx1_ora_255033.trc

执行一个只要本地查询的语句

1
2
3
4
5
SQL> select count(*) from v$instance;

  COUNT(*)
----------
         1

检查生成的trace文件

1
2
SQL> ! cat /u01/app/oracle/diag/rdbms/xxx/xxx1/trace/xxx1_ora_255033.trc
cat: /u01/app/oracle/diag/rdbms/xxx/xxx1/trace/xxx1_ora_255033.trc: No such file or directory

执行一个需要跨实例的语句

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
SQL> select count(*) from gv$instance;

  COUNT(*)
----------
     2

SQL> ! cat /u01/app/oracle/diag/rdbms/xxx/xxx1/trace/xxx1_ora_255033.trc
Trace file /u01/app/oracle/diag/rdbms/xxx/xxx1/trace/xxx1_ora_255033.trc
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.5.0.0.0
Build label:    RDBMS_18.1.0.0.0_LINUX.X64_180103.1
ORACLE_HOME:    /u01/app/oracle/product/18.0.0.0/dbhome_1
System name:    Linux

......省略

IPCLW:[0.0]{-}[CNCT]:RDS: [1559785604727267]ipclw_dump_cnh NO sbuf ctx:0x40009dafa168 pt:0x40009daf5f60 sndh:0x400094b63790 pid:192.168.10.3:4000

可以看到跟之前类似的trace文件就生成了。

知道trace产生的原因了，那么就要想办法关闭这些trace的生成，因为确实对磁盘造成了不小的压力。

通过oradebug doc component能方便的获取相关组件和事件的信息

SQL> oradebug doc component rdbms.VOS

  VOS                  VOS (ks)
    hang_analysis          Hang Analysis (ksdhng)
    background_proc        Background Processes (ksb, ksbt)
    system_param           System Parameters (ksp, kspt)
    ksu                Kernel Service User (ksu)
      ksutac               KSU Timeout Actions ((null))
    ksv_trace              Kernel Services Slave Management (ksv)
    file               File I/O (ksfd, ksfdaf)
    ksq                Kernel Service Enqueues (ksq)
    ksolt_trace            Kernel Services Lightweight Threads (ksolt)
    KSIM               Kernel Service Instance Management (ksim)
      KSIM_GRPOP           Kernel Service Instance Management Group Operation ((null))
    KSIPC              VOS IPC (ksipc)
      KSMSQ            Message queue services (ksmsq)
    KSMSQ_MQL          Message Queueing Layer ((null))
      KSRMA            ksrma (ksrma)
      KSRMF            ksrmf (ksrmf)
      KSIPC_AM             Active Messaging ((null))
      KSIPC_GRP            KSIPC Group Services ((null))
      KSIPC_SN             KSIPC Shared Nothing ((null))
      KSIPC_KV             KSIPC Key Value ((null))
      KSIPC_TOPO           KSIPC Topology Services ((null))
      KSIPC_PR             KSIPC Path Record ((null))
      KSIPC_IPCLW          IPC LightWeight ((null))
      KSIPC_IPCOR          IPC Core Functionality ((null))
      KSIPC_SHREG          KSIPC Shared Registration ((null))
    LREG               Listener Registration (kml)
    ksupd              KSU Planned Draining (ksupd)

可以通过下面的方法来关闭trace生成

1
2
ALTER SESSION SET EVENTS='trace[RDBMS.KSIPC_IPCLW] disk disable, memory disable'; 
ALTER SYSTEM SET EVENTS='trace[RDBMS.KSIPC_IPCLW] disk disable, memory disable';

重复我们之前的测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
SQL> select value from v$diag_info where NAME='Default Trace File';

VALUE
------------------------------------------------------------------------------------
/u01/app/oracle/diag/rdbms/xxx/xxx1/trace/xxx1_ora_181480.trc

SQL> select count(*) from v$instance;

  COUNT(*)
----------
     1

SQL> ! cat /u01/app/oracle/diag/rdbms/xxx/xxx1/trace/xxx1_ora_181480.trc
cat: /u01/app/oracle/diag/rdbms/xxx/xxx1/trace/xxx1_ora_181480.trc: No such file or directory

SQL> select count(*) from gv$instance;

  COUNT(*)
----------
     2

SQL> ! cat /u01/app/oracle/diag/rdbms/xxx/xxx1/trace/xxx1_ora_181480.trc
cat: /u01/app/oracle/diag/rdbms/xxx/xxx1/trace/xxx1_ora_181480.trc: No such file or directory
1
2
3
4
SQL> oradebug setmypid
Statement processed.
SQL> oradebug eventdump session;
trace [RDBMS.KSIPC_IPCLW] disk disable, memory disable

Exafusion是exadata的新特性，从12.2开始默认就是开启的，IPCLW的trace默认也是开启。

Exadata
Exadata IPCLW traces
https://www.xbdba.com/2019/06/05/exadata-ipclw-traces/
作者
xbdba
发布于
2019年6月5日
许可协议