2016年1月 Oracle大版内专家分月排行榜第一2015年6月 Oracle大版内专家分月排行榜第一2015年4月 Oracle大版内专家分月排行榜第一2015年3月 Oracle大版内专家分月排行榜第一2015年2月 Oracle大版内专家分月排行榜第一2014年6月 Oracle大版内专家分月排行榜第一2009年11月 Oracle大版内专家分月排行榜第一2009年10月 Oracle大版内专家分月排行榜第一
2015年9月 Oracle大版内专家分月排行榜第二2015年7月 Oracle大版内专家分月排行榜第二2015年1月 Oracle大版内专家分月排行榜第二2014年12月 Oracle大版内专家分月排行榜第二2014年11月 Oracle大版内专家分月排行榜第二2014年8月 Oracle大版内专家分月排行榜第二2014年7月 Oracle大版内专家分月排行榜第二2014年5月 Oracle大版内专家分月排行榜第二2010年1月 Oracle大版内专家分月排行榜第二2009年9月 Oracle大版内专家分月排行榜第二
2017年6月 Oracle大版内专家分月排行榜第三2017年3月 Oracle大版内专家分月排行榜第三2006年12月 Oracle大版内专家分月排行榜第三
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。Oracle RAC 11g实战指南全文阅读_Oracle RAC 11g实战指南免费阅读_百度阅读
&0手机专享价
扫码免费下载该书再送20元代金券
在电脑上继续阅读
您需要支付版权费用
会员免费读
开通图书VIP会员
万本精品好书免费读
用手机扫描以下二维码
开通图书VIP会员，万本精品好书免费读用户名：waldens
文章数：268
评论数：93
访问量：168141
注册日期：
阅读量：1297
阅读量：3317
阅读量：444375
阅读量：1130196
51CTO推荐博文
一、DB Time和Elapsed time
Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap:
21787 21-Feb-13 20:00:22
21798 22-Feb-13 07:00:47
660.42 (mins)
928.06 (mins)
--Elapsed & DB Time
--Elapsed Time=(:00:00 - :00:00)≈ 660
--DB Time=928.06 ,运行环境为16核CPU, 660*16=10560, cpu花费了928.06分钟在处理Oralce非空闲等待和运算上
--从上可知，整个系统还是比较空闲CPU负载= db time/(Elapsed time * cpu个数)*100%DB TIME= 所有前台session花费在database调用上的总和时间•注意是前台进程foreground sessions•包括CPU时间、IO Time、和其他一系列非空闲等待时间，别忘了cpu on queue timeAverage Active Session AAS= DB time/Elapsed TimeDB Time =60 min ， Elapsed Time =60 min AAS=60/60=1 负载一般DB Time= 1min , Elapsed Time= 60 min AAS= 1/60 负载很轻DB Time= 60000 min，Elapsed Time= 60 min AAS=1000  系统hang了DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queue如果仅有2个逻辑CPU，而2个session在60分钟都没等待事件，一直跑在CPU上，那么：DB CPU= 2 * 60 mins ， DB Time = 2* 60 + 0 + 0 =120AAS = 120/60=2 正好等于OS load 2。如果有3个session都100%仅消耗CPU，那么总有一个要wait on queueDB CPU = 2* 60 mins ，wait on CPU queue= 60 minsAAS= (120+ 60)/60=3  主机load 亦为3，此时vmstat 看waiting for run timeCPU是指核数，在Oracle查看他探测到的CPU COUNT。所以上面的看到总Elapsed time*16，在对比下db time也是可以大概感受到系统是否繁忙的。SQL& show parameter cpu_countNAME & & & & & & & & & & & & & & & & TYPE & & & &VALUE------------------------------------ ----------- ------------------------------cpu_count & & & & & & & & & & & & & &integer & & 16二.Host Cpu（整个主机的CPU负载情况）“Load Average” begin/end值代表CPU的大致运行队列大小。上图中快照开始到结束，平均 CPU负载增加了。%User+%System=& 总的CPU使用率，在这里是29.0%。空闲的CPU使用率为71%。三.Instance CPU(数据库实例消耗的CPU)1.%Total CPU,该实例所使用的CPU占总CPU的比例―&% of total CPU for Instance2.%Busy CPU，该实例所使用的Cpu占总的被使用CPU的比例―& % of busy CPU for Instance3.例如共4个逻辑CPU，其中3个被完全使用，3个中的1个完全被该实例使用，则%Total CPU= ¼ =25%，而%Busy CPU= 1/3= 33%4.当CPU高时一般看%Busy CPU可以确定CPU到底是否是本实例消耗的，还是主机上其他程序.5.%DB time waiting for CPU (Resource Manager)是指当使用了resource manager限制某个用户和会话使用CPU，而产生的等待。会产生resmgr:cpu quantum等待事件，如果产生该等待事件需要和RSRC_MGR的值结合起来判断。解决方法是需要修改资源限制的plan。案例如下图：本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)问诊白求恩 - RAC 节点参数不一致引发的悲剧
编辑手记：在Oracle RAC中，有一些参数是数据库级别的，所有实例都使用同一个参数值，有些参数是实例级别的，实例间可以设置不一样的值。然而，对于部分实例级别的参数，节点间设置不同却可能引发故障。
在白求恩智能诊断平台上（），对于数据库参数的检测非常细致，根据参数对于数据库的影响大小，可以分为：性能类参数，稳定性类参数及规范操作类参数。
在我们诊断过程中，发现大部分人在参数的配置上比较随意。最常见的问题包括以下一些：
10g DRM参数配置
在Oracle 10g版本中，开始提出了DRM特性，默认情况下，当某个对象的被访问频率超过50时，而同时该对象的master又是其他节点时，那么Oracle则会触发DRM操作来修改master节点，这样的好处是可以大幅降低gc grant之类的等待事件。
在进程DRM操作的过程中，Oracle会将该资源的相关信息进行临时frozen，然后将该资源在其他节点进行unfrozen，然后更改资源的master节点。由于frozen的资源是GRD（Global Resource Directory）中的资源。在整个DRM的过程之中，访问该资源的进程都将被临时挂起。正因为如此，当系统出现DRM操作时，很可能导致系统或进程出现异常的。
Oracle DRM的Bug也非常多，尤其是Oracle 10gR2版本中，因此在10g的生产环境中，我们一般是建议关闭DRM特性的。
关闭DRM，常规的操作是:
_gc_affinity_time=0
_gc_undo_affinity=FALSE
但这2个参数是静态参数，也就是说必须要重启实例才能生效。实际上可以设置另外2个动态的隐含参数，来达到这个目的。
_gc_affinity_limit=250
_gc_affinity_minimum=
甚至可以将以上2个参数值设置得更大。这2个参数是立即生效的，在所有的节点上设置这2个参数之后，系统不再进行DRM。
RAC 全局事务处理
集群范围全局性事务(Clusterwide global transactions)是11g的新特性。集群范围全局性事务指的是在RAC中的每个节点均有一个本地事务，它属于一种分布式事务，当_clusterwide_global_transactions=true(default)时，Oracle会把这些本地事务当做一个事务对待，当_clusterwide_global_transactions=false时，Oracle会将这些本地事务当做单独的事务通过多阶段提交协调处理。
在默认设置为TRUE的情况下，可能会遭遇以下bug.
ORA-600 [ktbsdp1] ORA-600 [kghfrempty:ds] ORA-600 [kdBlkCheckError]. Corruption in Rollback with Clusterwide Global Transactions in RAC
ORA-00600: [kjuscl:!free]
因此，建议将该参数修改为FALSE，修改后不会对性能产生任何影响。
节点间LMS不一致引发的故障
LMS进程主要负责节点之间的数据交互，是RAC中最忙碌是一个进程。其默认值由系统的CPU数量计算得出，不同版本中的计算方法有差异。也可以通过gcs_server_process参数进行配置。一般情况下，要求节点之间的LMS进程数量一致。
接下来分享一个跟LMS相关的故障。
情景描述：一个批量执行的业务，时快时慢，经检查在执行计划完全一致的情况下，执行时间在2hour ~10hour 不等。
采样AWR报告，整体DBtime如下：
而这些DBtime主要消耗在RAC Global Cache环节。
这里对gc current grant 2-way等待事件简单说明：
gc cr&current grant 2-way 是一种 grant message package 的传递，当取cr 或current block 时向block master instance 请求x或s的权限 ，当请求的block在从任何实例上的buffer cache中都没有发现, lms进程会通知FG进程从disk 读取block到local buffer cache中
节点之间的等待如此长，是不是节点流量过大所以产生等待呢？
然而事实并不是这样，节点间流量很小。那么为什么会产生如此多的等待。
我们来分析RAC的Global Cache环节到底在做什么？
以cr块的访问为例，
Avg global cache cr block receive time=
Avg global cache cr block build time+
Avg global cache cr block send time+
Avg global cache cr block flush time+
Avg message sent queue time on ksxp+
在上图中，我们发现以下四项相加的时间仅为0+0+3.1+0.2=3.3，与消耗的总时间87相差甚远。那么时间都到哪里去了？
我们通过AWR报告继续分析RAC的全局统计信息
我们发现，在最后一行，出现了流量控制，高达16.28。此处的数据为系统运行最慢的时候的，那么对比运行正常的时候发现，正常情况下，流量控制的值为0.8.
所以，16.28 vs 0.8.这是问题的关键！
但是，根据前面的分析，节点之间的流量并不大，为什么会做流量控制？
一把情况下，节点间做流量控制的原因有以下几条：
1、私网网络链路不通畅
2、RAC对端节点负载较高
3、两个节点的传输配置有差异
在这个案例中，前两者都不存在问题。那么就是两个节点的传输配置有差异。我们知道，节点之间数据传输是LMS进程执行的，因此，说明了LMS的配置有差异。
我们查询gcs_server_process 参数，发现没有配置。然后查看CPU数量，结果如下
果然是CPU不对等，因此，在lms 多的节点上(本案例的节点1 ) 有更强的cache fusion 请求的能力疯狂的抛向LMS进程小的节点（节点2）时， 节点2 的负载过重无法对称的处理， 就会出现这个性能问题。
Oracle为了避免这种攻击的产生，于是做了流量控制，导致系统中大量等待。
最后，我们手动修改了gcs_server_process 参数，使得LMS进程数量一致。问题得到解决。
白求恩，从架构到细节，全方位诊断系统安全与健康，比你更了解你的数据库。现在登录立即体验：
加入"云和恩墨大讲堂"微信群，参与讨论学习
搜索 盖国强（Eygle）微信号：eyygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。
关注公众号，获得后续精彩分享
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点Oracle RAC必备知识点整理_数据库技术_Linux公社-Linux系统门户网站
你好，游客
Oracle RAC必备知识点整理
来源：Linux社区&
作者：kuqlan
数据库规划要从业务特性和需求为导向，不要为了RAC的可用性而上RAC，实际上RAC也不是万能的，需要如下知识点需要掌握。
1.使用RAC的好处
1.1 提升应用系统性能，提高数据库事务处理能力
在单台主机资源或者单实例数据库的事务处理能力受到瓶颈时，使用RAC能极大提高并发能力。
主机的资源使用率不是简单的求和。比如在2个节点的RAC环境中，每个节点的CPU使用率为50%，如果所有资源转移到单个节点，其使用率不会等于100%，可能70%。所以资源的使用很大程度上在于交互成本。
当交互成本过大时，其处理效率会极大的降低。
1.2提高数据库高可用性，尤其是双活的架构下。其好处如下：
同城本地服务器和同城异地服务器之间的无需任何切换，实现极为稳定可预期的秒级失败业务切换。
业务连接的后台数据中心，是同城双活中心，任一站点的故障，业务不受到影响，这大大提高了业务的响应能力，也大大增加了检修等日常运维管理时间。
3.RAC的选型考虑
全表扫描情况是不是很多？
索引争用厉不厉害？
高水位争用厉不厉害？
sequence争用厉不厉害？
正版授权、安装、运维费用是否在预算范围内？
4.RAC的副作用
资源争用成本会成倍放大，负载均衡下尤其严重
代码访问深度变深，带来的bug,数据库的整体稳定性甚至不如单节点
节点之间SQL执行计划不一致
心跳网络的故障率很高
各个版本之间的差异化
对维护人员的技能经验要求较高
如果在单实例中数据块争用比较厉害，那么迁移到RAC之后就会是一场灾难，性能可能会更加恶化。在这种情形下，多买了一台小机，只实现了HA的功能，但付出的是性能下降。得不偿失！
其中一个实例hang住时，RAC的可用性得不到保障
全面检查操作系统补丁情况，建议安装最新的数据库补丁
心跳网络使用双网卡绑定
主机的操作系统版本要求一致，配置最好一致
部署主机资源监控脚本，如部署OSW
做好各项暴力测试，如CRS/主机启动测试，插拔网线测试
预防性的设置好各类参数，如的DRM参数
应用端做针对RAC特性调整，建议业务分节点运行
死锁可能在多个节点发生
不要将数据文件增加到本地硬盘上
先关数据库，再关CRS软件，最后关主机
单机转成RAC之后，适当加大buffer cache和shared pool的大小
开启并行要慎重，程序不要跨节点并行运行
容易忽略的数据库参数
7.学习RAC的几点建议
具备操作系统的相关知识，熟悉vmware或Oracle vbox基本操作
安装、升级，且反复安装、升级
阅读官方文档，知道&有什么&，&怎么做&，再查其他文档
在实验环境中操作，尤其需要操作以下内容：
CRS的资源管理
ASM磁盘、磁盘组的添加删除操作
OCR/VOTING DISK的备份、恢复、镜像、删除操作
VIP/PUBLIC IP/HAIP/PRIVATE IP更改操作
学会查看CRS日志文件
要学会查看gv$视图
了解业务特性，尤其需要知道哪张表在哪个节点访问频率最高
熟悉CRS日志存放位置
更多Oracle相关信息见 专题页面
本文永久更新链接地址：
相关资讯 & & &
& (04月10日)
& (03月24日)
& (05月31日)
& (03月24日)
& (03月23日)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款