369
Direct IO+asm引起css initialization
作者簡介：
何劍敏 Oracle ACS華南區售後團隊，首席技術工程師
現供職於Oracle ACS華南區售後團隊，首席技術工程師。多年從事第一線的數據庫運維工作，有豐富項目經驗、維護經驗和調優經驗，專注於數據庫的整體運維。
某數據庫升級到12c後（應用代碼也升級了）,出現了大量css initialization的等待：
懷疑是否是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進行分析，就可以比較清楚的看清他們之間的差別了：
圖二：
第21行和41行可以看到差別，第一個的cache屬性是加在表上的，第二個表的cache屬性是加在LOB上的。所以，如果我們把LOB對象加到cache中，就不會那麼劇烈的遭受css initialization。
最後，客戶是通過LOB字段改成varchar2字段解決了。
文章轉自數據和雲公眾號，原文鏈接
最後更新：2017-07-18 11:32:46