資料庫：12.1.0.2，rac，cdb模式 筆者負責移動兩個12.1.0.2的cdb集群，一個在aix上，一個在linux上，不幸的是，它們都是混合型，數據有100多T。 由於其它部門交付的時候，已經是12c，之前對12c不是很熟悉，但還是想看看是否可以在不分庫的前提下，最大化性能。 結果不行，因 ...
資料庫：12.1.0.2，rac，cdb模式
筆者負責移動兩個12.1.0.2的cdb集群，一個在aix上，一個在linux上，不幸的是，它們都是混合型，數據有100多T。
由於其它部門交付的時候，已經是12c，之前對12c不是很熟悉，但還是想看看是否可以在不分庫的前提下，最大化性能。
結果不行，因為有些偏向OLTP的應用會常常覺得慢。
怎麼辦？只好先通過SERVICE指定節點，每個服務至少兩個節點，服務內部採用taf配置，一個主節點，一個備用節點。
例如為某個oltp創建的服務如下：
srvctl add service -db wgdb -service nsn_flowdb -preferred wgdb2 -available wgdb4 -tafpolicy preconnect -policy automatic -failovertype session -failovermethod basic -failoverretry 180 -failoverdelay 2 -pdb nsn_flow
並且在節點2上，只分配給所有這些oltp類型應用，其它olap類型的在其它節點。
個人覺得，就這點上，oracle資料庫遠遠優於各種rdbms和bigdata，光這個方面，就可以節約企業的不少資源和成本。
其它rdbms的資源管理有點複雜，遠遠不如oracle這麼方便。
話說，oracle做得這麼方便，就是為了向cloud靠攏。
之後一段時間，大部分時候，oltp應用都很快，但偶爾還是會發生慢的情況，例如某個上午或者下午的某個時間點。
怎麼回事？然後分析了下作業的運行日誌，發現作業本身並不按照創建的服務運行，而是在所有節點上，按照oracle資料庫自己的均衡演算法，分佈在各個節點上運行。
又研究了下oracle的作業，發現可以通過調度類來控制服務，很高興，不需要什麼複雜的操作。
但問題又來了：
1.現有的作業採用的是預設調度類，預設調度類並不指定節點
2.後續各個開發人員如果在沒有強制的情況下，還是會使用預設的調度類
於是決定修改其它pdb的預設調度類：
begin dbms_scheduler.set_attribute(name => 'DEFAULT_JOB_CLASS',attribute => 'comments',value => 'This is for all olap app'); dbms_scheduler.set_attribute(name => 'DEFAULT_JOB_CLASS',attribute => 'service',value => 'wybigdata'); end;
至於，在特定節點上跑OLap過程慢，沒有關係，olap就是可以容忍這樣的情況。
鑒於oracle的調度這麼強大，後續決定強制各個廠商改用調度來執行他們的作業，而不是job,後者台糟糕，早應該拋入歷史垃圾堆了。
除了通過service來控制資源分配，oracle還可以通過其它方式管理調度作業的資源分配，例如通過資源組。
所以，在搭建集群的初期，選擇集群的配置方式是非常重要的。
