數據庫：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還可以通過其它方式管理調度作業的資源分配，例如通過資源組。

所以，在搭建集群的初期，選擇集群的配置方式是非常重要的。

oracle12c管理作業資源的一種方式