oracle中Direct IO+asm引起css initialization

某数据库升级到12c后（应用代码也升级了）,出现了大量css initialization的等待：

SQL> select event,sql_id,count(*) from  v$session
where event='CSS initialization' group by event,sql_id;

EVENT                  SQL_ID          COUNT(*)
---------------------- ------------- ----------
CSS initialization     1qkdw0dtyjydf       5
CSS initialization     2g9g4as2nasad       1
CSS initialization     5r5mwAS0m4mxq       1
CSS initialization     712df0y5u236f     529
CSS initialization     aasd9k80jrvax     342
CSS initialization     a4uvs112123q6       1
CSS initialization     c5ax6wp98nam4       1
CSS initialization     fsadasd6asd12       4

怀疑是否是12c的新特性导致。

CSS initialization 说明：
在RAC（或使用ASM的单实例）数据库环境下，当前台进程需要执行direct IO操作时，需要向CSSD进程进行注册，此时该前台进程发生CSS initialization等待。
在11g还是12c上，CSS initialization的触发原理都没有改变，该event是一个direct IO的预期行为，任何前台进程在需要进行direct IO的情况下，都必须进行一次CSS注册，之后就可以被允许进行direct IO操作。

我们知道，对LOB对象操作的时候，第一次操作的时候，是会进行direct IO的，后续的操作，要看LOB对象是否有cache，如果有cache，那么就不会进行direct OI，也就不会进行CSS initialization。

如果没有cache，那么每一次dml操作都要进行CSS initialization。那么就会出现这个客户遇到的情况一样，大并发的情况下，大量进程处于CSS initialization的等待了，并且cssd.bin进程的CPU使用率也会变得非常高。

所以通过情况下，我们不建议对频繁操作的核心业务表加LOB字段的。如果确实需要LOB字段，需要使用cache特性。请注意，这里是LOB对象的cache，而不是table的cache属性。我犯过一个错误，一个细微的差别导致加cache到table上，而不是LOB对象上，所以无论怎么测试，都无法重新客户的场景。

我建立的表如下：

CREATE TABLE wrong_tab_securefile_cache (
id NUMBER,
clob_data CLOB
)
LOB(clob_data) STORE AS SECUREFILE cache
tablespace users;

正确的表的建立方式如下：
CREATE TABLE tab_securefile_cache (
id NUMBER,
clob_data CLOB
)
LOB(clob_data) STORE AS SECUREFILE (cache)
tablespace users;

仅仅是有没有括号的差别，即一个是cache，一个是（cache）。

但是如果你用dbms_metadata进行分析，就可以比较清楚的看清他们之间的差别了：

SQL> select dbms_metadata.get_ddl('TABLE','WRONG_TAB_SECUREFILE_CACHE','SYS') FROM DUAL;
 
DBMS_METADATA.GET_DDL('TABLE','WRONG_TAB_SECUREFILE_CACHE','SYS')
--------------------------------------------------------------------------------
 
  CREATE TABLE "SYS"."WRONG_TAB_SECUREFILE_CACHE"
   (    "ID" NUMBER,
        "CLOB_DATA" CLOB
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
 NOCOMPRESS LOGGING
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "USERS"
 LOB ("CLOB_DATA") STORE AS SECUREFILE (
  TABLESPACE "USERS" ENABLE STORAGE IN ROW CHUNK 8192
  NOCACHE LOGGING  NOCOMPRESS  KEEP_DUPLICATES
  STORAGE(INITIAL 106496 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT))
   CACHE
 
 
SQL >
SQL> select dbms_metadata.get_ddl('TABLE','TAB_SECUREFILE_CACHE','SYS') FROM DUAL;
 
DBMS_METADATA.GET_DDL('TABLE','TAB_SECUREFILE_CACHE','SYS')
--------------------------------------------------------------------------------
 
  CREATE TABLE "SYS"."TAB_SECUREFILE_CACHE"
   (    "ID" NUMBER,
        "CLOB_DATA" CLOB
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
 NOCOMPRESS LOGGING
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "USERS"
 LOB ("CLOB_DATA") STORE AS SECUREFILE (
  TABLESPACE "USERS" ENABLE STORAGE IN ROW CHUNK 8192
  CACHE  NOCOMPRESS  KEEP_DUPLICATES
  STORAGE(INITIAL 106496 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT))
 
 
SQL>

第21行和41行可以看到差别，第一个的cache属性是加在表上的，第二个表的cache属性是加在LOB上的。

所以，如果我们把LOB对象加到cache中，就不会那么剧烈的遭受css initialization。

最后，客户是通过LOB字段改成varchar2字段解决了。