Direct IO+asm引起css initialization-阿里云开发者社区

开发者社区> 数据库> 正文

Direct IO+asm引起css initialization

简介:

作者简介:

640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy
何剑敏 Oracle ACS华南区售后团队,首席技术工程师

现供职于Oracle ACS华南区售后团队,首席技术工程师。多年从事第一线的数据库运维工作,有丰富项目经验、维护经验和调优经验,专注于数据库的整体运维。


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

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=


怀疑是否是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进行分析,就可以比较清楚的看清他们之间的差别了:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

图二:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=


第21行和41行可以看到差别,第一个的cache属性是加在表上的,第二个表的cache属性是加在LOB上的。所以,如果我们把LOB对象加到cache中,就不会那么剧烈的遭受css initialization。

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


文章转自数据和云公众号,原文链接

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章