数据库：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还可以通过其它方式管理调度作业的资源分配，例如通过资源组。
所以，在搭建集群的初期，选择集群的配置方式是非常重要的。
原文地址：https://www.cnblogs.com/lzfhope/p/8322130.html