RAC应用设计方面需要在底层做很有设计。虽然ORACLE的售前人员总是说RAC的扩展性是透明的,只要把应用分到不同的节点,就可以平滑的扩展系统能力了。而事实上,RAC的CACHE FUSION机制决定db cache,library cache等在RAC环境下都会由于CACHE FUSION而带来额外的开销。

在一个单实例环境中,如果我们要访问某个Cache buffer,我们只需要闩住相关的cache buffer chains,然后去读取这个buffer就行了,而在RAC环境中,首先我们要闩住cache buffer chains,查看该buffer的当前版本是否在这个实例的db cache中,如果没有找到,那么就要发出消息询问其他的节点,是否cache在其他节点中存在,如果存在,那么就要从其他节点通过网络将这个buffer传输过来。

在一个单实例的环境中,db cache的命中率96%和97%可能对系统影响不大,而在RAC环境中,db cache命中率下降一个百分点,对于系统性能造成的总体影响要大上数倍。因此在设计RAC应用的时候,如何减少CACHE FUSION带来的负面影响是十分关键的。在一个RAC环境中,没有任何数据共享是不可能的,或多或少都会有数据共享,因此如何在实例之间共享数据是解决RAC应用性能问题的关键。

在国内的应用设计方面,为了避免CACHE FUSION使用最广的方法是应用隔离,也就是在RAC的不同节点上跑不同的应用,从而最大幅度的减少数据的共享。应用隔离确实是一种很好的RAC应用优化方案,实施起来也比较简单,不需要十分专业的RAC优化技术。不过应用隔离虽然实施难度较小,也被使用比较广泛,但是应用隔离是RAC优化中最为低级的应用层次,在很多情况下,某个应用主要集中在某几张表的访问,这样想要做的应用隔离的难度较大,在这种情况下,需要对应用做更为细致的优化。就像老白处理的这个案例,在两个节点要跑完全相同的应用,这种情况下的优化,就需要从应用底层开始设计了。从总体上来说,减少CACHE FUSION带来的性能影响的方法有一下几个方面。

1、通过表分区来限制某个分区被某个实例使用。对于RAC应用来说,表分区是很好的减少热块争用的手段。首先通过表分区,使数据分散到数个segment中,其高水位推进,数据访问等都被分散了。因此在RAC环境中设计表分区的时候也要注意,表分区逐渐的选择确实能够起到分散数据分布的作用。如果我们有一张日志表,根据日志的日期进行分区,那么虽然我们做了分区,但是还是无法起到分散数据访问的作用,因为我们总是在最新的那个分区里插入和查询数据,其他分区很少会被访问到。

2、增加db cache的命中率。在一般的OLTP系统中,db cache命中率超过90%就不算太低了,如果超过95%那就说明db cache的命中率比较高了。但是在RAC环境中,db cache的命中率越低,CACHE FUSION带来的负面影响就越大,因此在RAC环境下,保持较高的db cache命中率对于系统总体性能大的影响十分巨大。

3、增加共享池的命中率。在RAC环境中,SQL的分析等操作要比单机环境昂贵的多,主要原因是分析等操作涉及大量的全局资源的协同。在RAC环境中减少硬分析、软分析等也有十分重要的意义。因此保持较为充足的共享池资源,使用好的编程习惯,合理使用绑定变量等都有助于提高RAC环境下的系统性能。

4、加大sequence的cache,并使用noorder选项。在RAC中经常会遇到SQ锁等待,这是因为在RAC环境下,sequence也成为全局性的了,不同节点要生成序列号,就会产生对sequence资源的争用。而目前大多数系统中,sequence大多数被作为主键发生器来使用,使用的频率十分高,在RAC环境中,需要设置较大的sequence cache,否则会造成较为严重的争用,从而影响业务。

另外在业务允许的情况下,sequence尽可能使用noorder选项,从而减少sequence产生器的负担。对于十分严重的sequence争用,甚至有用户使用UUID来替代sequence.UUID是一个37位字符串,通过生成机制来确保全局唯一性。这个特点也可以用来作为主键使用。在Oracle中,可以通过select sys_guid() from dual来生成一个UUID,这个UUID是不带“-”的,所以只有32位。

关于enqueue的一个案例
平均事务响应时间在200毫秒左右,IO基本上很空闲,两个节点的CPU使用率比较低,基本稳定在30%左右。从主要等待事件上看,global cache cr request、db file sequential read和enqueue排在前三位。enqueue等待大概占整个等待事件的13%左右。我马上打开了enqueue的图表,发现排在第一位的 enqueue是SQ。通过脚本检查v$enqueue_stat:
SELECT eq_type,cum_wait_time
from v$enqueue_stat
order by 2;
从查询结果上来看,排在前三位的是SQ、US和TX。SQ排在第一位肯定是sequence存在较为严重的冲突。我做了一个statspack报告,从 Statspack报告中可以看出row cache objects相关的等待还是比较多的,从row cache的情况看,dc_sequence的等待和丢失率也比较高。于是我检查了一下sequence的参数,所有的sequence cache参数都是缺省的20。于是我让秦工尽快联系开发人员,重建所有的sequence,将sequence 的cache参数都加大为1000。
随着系统负载的增加,CPU的使用率也提高了40%以上,global cache相关的等待事件和enqueue等待也比刚才多了一些。突然整个系统出现了异常,平均事务响应时间出现了一个突变,提高了一倍多,好像出现了短 暂的HANG住现象。我看了一下OEM的健康性图标,发现logon的指标不正常得高,在两个节点上平均每秒logon的数量达到了30多。我问秦工是不是系统有短连接的应用。秦工说他们的系统中绝大多数都是C/S结构的,平均每秒logon的数量一直都挺高的。
看样子我刚才又忽略了一个问 题,在RAC环境下,如果logon较多的话,需要加大一个sequence的cache,刚才开发厂商已经加大了所有应用的sequence的cache,但是sys.audseq$的cache却忘记调整了,检查了一下,确实sys.audseq$的cache是缺省的20.在RAC环境下, 如果logon较为频繁的话,这个sequence是必须调整的。我甚至碰到过由于logon的密度比较高,导致整个数据库HANG住的现象。于是我建议等会调整的时候,把sys.audseq$的cache调整为5000
关于sequence cache
1、Create Sequence
你首先要有CREATE SEQUENCE或者CREATE ANY SEQUENCE权限,
CREATE SEQUENCE emp_sequence
INCREMENT BY 1 -- 每次加几个
START WITH 1 -- 从1开始计数
NOMAXVALUE -- 不设置最大值
NOCYCLE -- 一直累加,不循环
CACHE 10;

5、使用只读表空间。只读表空间在RAC中时十分有用的,在CACHE FUSION下,如果某个表空间是只读的,那么表空间中数据的访问只需要本地操作就可行了,不需要RAC间协同。实际上,很多数据库中的数据,在某个时间段里都会有大量的只读数据,这些数据如果访问十分频繁,那么在RAC下就会对GES和GCS产生很严重的影响。

实际上,如果我们在设计应用系统的时候就充分考虑了RAC的问题,完全可以把可能只读访问或者在某个时间段内只读访问的数据放在相同的表空间中,这些数据可以根据业务需要设置为读写或者只读。比如,老白曾经给一个客户做过优化,他们系统中的历史数据访问十分频繁,老白建议他们把历史数据存放在单独的表空间中,平时设置为READ ONLY,只有做数据归档的时候才改回READ WRITE。通过这个简单的优化动作,减少了大量的全局访问,改善了RAC的性能。

6、减少大表的全表扫描。全表扫描特别是大表的全表扫描,对db cache的影响十分巨大,由于全表扫描会占用大量的db cache,这样就会把很多DATABLOCK从db cache中挤出去,而且大表的全表扫描会带来大量的物理读,在RAC环境中,物理读的开销远大于单机环境。

7、限制并行查询在实例范围内,不要再RAC实例之间做并行查询。实际上,绝大多数的并行查询并不需要跨实例运行,而Oracle缺省情况下并行查询是跨实例的,所以很多客户都吃过这个苦头,跨实例做并行查询主要是解决单机CPU能力不足的问题,但是跨实例并行查询会引起GCS方面的问题。目前国内用户系统的单机CPU能力一般都比较强,因此使用跨实例并行查询往往得不偿失。Oracle在RAC下的并行查询方面的配置十分灵活,通过设置instance_groups和parallel_instance_group参数就可以实现灵活的策略,通过配置这两个参数,可以轻松实现将并行查询限制在本机上。

案例
在监控过程中,我们发现了大量的PX等待事件,这是由于这个系统中存在大量的统计模块,这些模块做了大量的PX等待事件,这是由于这个系统中存在大量的统计模块,这些模块做了大量的全表扫描,为了提高全表扫描的性能,在很多SQL中,加了PARALLEL提示。我检查了一下并行查询,发现存在不少跨实例的并行查询。为了防止不必要的问题,建议一般情况下并行查询限制在实例内,这可以通过instance_groups参数来实现:
Rac1.Instance_groups=rac1,rac
Rac1.Parallel_instance_group=rac1
Rac2.Parallel_instance_group=rac2
Rac2.Instance_groups=rac2,rac
通过这些参数的设置,在缺省的环境下,并行查询只能在实例内进行。因为每个实例的缺省parallel_instance_group都是实例名,只有本实例的instance_group参数中包含和本实例名相同的instance_group。而如果想要某个SQL跨实例做并行查询时,可以通过下面的方法进行:
alter session set parallel_instance_group=rac;
Select ...
由于两个实例都属于RAC instance_group,所以只要把parallel_instance_group设置为"rac“就可以了。在我碰到的RAC系统中,大多数CPU的使用率都不高

注:在11gRAC中,因为向后兼容仍然可以使用instance_groups和parallel_instance_group参数。然而,在Oracle 11g RAC中不需要这样做,instance_groups参数已经被废弃并且保留只是为了向后兼容。

8、通过应用隔离,在每个实例上跑不同的应用。RAC每个节点跑不同的应用是目前国内RAC系统中很常用的一种方法,通常被称为应用隔离。应用隔离室RAC应用优化中最为初级的形态,不过也是较为有效的形态。在这种模式下,多个应用共享非关键数据,核心业务数据的关联度较小,通过将不同应用分布在不同的实例上,确保RAC的各个实例间共享的数据较少,访问冲突限制在一个可控的范围内。

9、数据的横向隔离。应用隔离室较为初级的优化形态,虽然有效但是有很多限制,比如某个应用十分庞大,一个单节点无法承担,那样就无法通过应用隔离的方式来优化了。这种情况下,数据的横向隔离就十分有效了。以电信业务为例,其核心业务数据如果能够按照本地网进行分区,那么我们就可以设置部分本地网的应用连接在实例1上,部分本地网应用连接在实例2上。通过表分区来确保核心业务数据之间的冲突降到最小,从而避免由于RAC中数据块争用带来的问题。

老白关于rac性能调优的建议(10gRAC)的更多相关文章

  1. 老白关于rac性能调优的建议

    RAC应用设计方面需要在底层做很有设计.虽然ORACLE的售前人员总是说RAC的扩展性是透明的,只要把应用分到不同的节点,就可以平滑的扩展系统能力了.而事实上,RAC的CACHE FUSION机制决定 ...

  2. iOS应用性能调优的建议和技巧--中高级--王朋

    中级(这些是你可能在一些相对复杂情况下可能用到的) 9. 重用和延迟加载Views 10. Cache, Cache, 还是Cache! 11. 权衡渲染方法 12. 处理内存警告 13. 重用大开销 ...

  3. SQL Server性能调优--优化建议(二)

    序言 优化建议 库表的合理设计对项目后期的响应时间和吞吐量起到至关重要的地位,它直接影响到了业务所需处理的sql语句的复杂程度,为提高数据库的性能,更多的把逻辑主外键.级联删除.减少check约束.给 ...

  4. SQL Server性能调优--优化建议(一)

    序言 当数据量小的时候,SQL优化或许无关紧要,但是当数据量达到一定量级之后,性能优化将变得至关重要,甚至决定系统成败. 定位慢查询 查询编译以来cpu耗时总量最多的前50条 --查询编译以来 cpu ...

  5. Apache Pulsar 在 BIGO 的性能调优实战(上)

    背景 在人工智能技术的支持下,BIGO 基于视频的产品和服务受到广泛欢迎,在 150 多个国家/地区拥有用户,其中包括 Bigo Live(直播)和 Likee(短视频).Bigo Live 在 15 ...

  6. OCM_第十五天课程:Section6 —》数据库性能调优 _SQL 访问建议 /SQL 性能分析器/配置基线模板/SQL 执行计划管理/实例限制

    注:本文为原著(其内容来自 腾科教育培训课堂).阅读本文注意事项如下: 1:所有文章的转载请标注本文出处. 2:本文非本人不得用于商业用途.违者将承当相应法律责任. 3:该系列文章目录列表: 一:&l ...

  7. OCM_第十四天课程:Section6 —》数据库性能调优_各类索引 /调优工具使用/SQL 优化建议

    注:本文为原著(其内容来自 腾科教育培训课堂).阅读本文注意事项如下: 1:所有文章的转载请标注本文出处. 2:本文非本人不得用于商业用途.违者将承当相应法律责任. 3:该系列文章目录列表: 一:&l ...

  8. iOS-------应用性能调优的25个建议和技巧

    性能对 iOS 应用的开发尤其重要,如果你的应用失去反应或者很慢,失望的用户会把他们的失望写满App Store的评论.然而由于iOS设备的限制,有时搞好性能是一件难事.开发过程中你会有很多需要注意的 ...

  9. iOS应用性能调优建议

    本文来自iOS Tutorial Team 的 Marcelo Fabri,他是Movile的一名 iOS 程序员.这是他的个人网站:http://www.marcelofabri.com/,你还可以 ...

随机推荐

  1. python3 进一步了解装饰器 NLP第四条

    还是先来抄一段NLP第四条: 四,只有感官经验塑造出来的世界,没有绝对的真实世界   每个人运用自己的感觉器官把资料摄入(摄入过程),由于感官运用是主观地有选择性的,因此不能,亦不需要把所有资料捕获. ...

  2. 分布式架构原理解析,Java开发必修课

    1. 分布式术语 1.1. 异常 服务器宕机 内存错误.服务器停电等都会导致服务器宕机,此时节点无法正常工作,称为不可用. 服务器宕机会导致节点失去所有内存信息,因此需要将内存信息保存到持久化介质上. ...

  3. 吴恩达机器学习笔记61-应用实例:图片文字识别(Application Example: Photo OCR)【完结】

    最后一章内容,主要是OCR的实例,很多都是和经验或者实际应用有关:看完了,总之,善始善终,继续加油!! 一.图像识别(店名识别)的步骤: 图像文字识别应用所作的事是,从一张给定的图片中识别文字.这比从 ...

  4. jenkins 自动化部署实战

    jenkins 作为一个自动化的集成工具,已经是必不可少的了.它里面提供各种插件,以及完备的基础流程设施,为大家的自动化集成之路提供了很多的方便.所以,我们有必要完整的实践一回.以切身体会到它的好处! ...

  5. android客户端向服务器发送请求中文乱码的问

    android客户端向服务器发送请求的时候,并将参数保存到数据库时遇到了中文乱码的问题: 解决方法: url = "http://xxxx.com/Orders/saveorder.html ...

  6. Android序列化

    1.序列化的目的 (1)永久的保存对象数据(将对象数据保存在文件当中,或者是磁盘中 (2)通过序列化对象在网络中传递对象 (3)通过序列化对象在进程间传递 (4)在Intent之间,基本的数据类型直接 ...

  7. 泥瓦匠想做一个与众不同的技术"匠"

    点击蓝字,关注泥瓦匠 本文阅读大约 3 分钟.感谢阅读 喝了最后一口百事可乐,想到它的 slogan:新一代的选择.新一代的选择,每个人选择不同,人生道路历程也不同.就像我刚毕业的时候,毕业选择不一样 ...

  8. jquery快速入门(四)

    jQuery 遍历 向上遍历 DOM 树 parent() parent() 方法返回被选元素的直接父元素.该方法只会向上一级对 DOM 树进行遍历. parents() parents() 方法返回 ...

  9. winform中使用委托进行窗体之间的传值

    一.传统的方式 创建一个公共数据资源类,用于存储窗体2的TextBox的值: public class ComValue { public static string Txtvalue { get; ...

  10. ABAP案例:灵活读取SAP各表的数据

    案例说明     RFC读取表中数据. Import 参数名称 Type spec. 参考打印 FIELDS_NAME1 TYPE CHAR25 TABLE_NAME1 TYPE CHAR25 WHE ...