oracle12c管理作业资源的一种方式

2018-01-21 18:48:53来源:cnblogs.com作者:正在战斗中人点击

分享

 数据库: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还可以通过其它方式管理调度作业的资源分配,例如通过资源组。

所以,在搭建集群的初期,选择集群的配置方式是非常重要的。

最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台