Oracle数据库性能优化方法论和最佳实践.html.pdf

收藏

编号:20200522090014603113    类型:共享资源    大小:10.83MB    格式:PDF    上传时间:2020-05-22
  
1
文币
关 键 词:
Oracle 数据库 性能 优化 方法论 最佳 实践 html
资源描述:
前言 为什么要写这本书 十多年前笔者就打算写一本Oracle数据库性能优化方面的书,屡次都是在提笔写了几行字后就放弃了。近几年,随着Oracle数据库的普及和水 平的不断提高,国内出现不少Oracle数据库方面的高水平作品,相当多的作品都涉及了性能优化方面的话题。但是几乎所有作品都只是讲解了性能 优化相关的知识和经验,对于优化思路和方法很少涉及。作为性能优化方面的“老兵”,始终认为优化思路和方法要重于知识和经验,只要有适当 的优化方法论指引,性能优化甚至可以成为Oracle数据库领域相对简单的业务。 近几年,随着美创科技公司开创并实践的基于流程、资源和组件分析的性能优化方法论的成熟,笔者比以往有了更大的动机来完成本书,期望 它可以在Oracle性能优化史甚至整个数据库性能优化史上留下印迹,让广大的Oracle数据库使用人员和从业人员可以更加简单地完成Oracle性能优 化工作,而不仅仅是个别高级DBA的专利工作。 读者对象 对于读书,笔者始终相信一本书只要有几句话可以对读者有帮助,那么这本书的价值就可以得到体现。作为优化方法论类相关的书,一般阅读 起来会显得枯燥,尤其是对于初学者,甚至可能会比较困难,但是只要保持耐心,相信读者一定能够获得收益。本书适合以下读者: ·中高级Oracle DBA ·中高级其他数据库的DBA ·性能优化从业人员 ·数据库架构设计师 ·数据库开发工程师 ·容量规划工程师 ·对于性能优化保持兴趣的数据库从业者 ·曾经遭遇性能障碍的数据库使用者 如何阅读本书 本书分为四大部分: 第一部分为漫谈篇(第1~2章),简单地介绍了性能优化领域的一些特征、误区,以及性能优化方法论的发展。 第二部分为流程篇(第3~4章),详细地讲解了数据库登录和数据访问处理流程,该篇通过流程的输入和输出以及流程分解来描述流程,从而 帮助读者加强流程认知,进而实现流程优化。 第三部分为资源(硬件资源)篇(第5~9章),分别讲述了CPU、内存、I/O、网络等硬件资源的输入和输出特征,以及优化的主要方法。 第四部分为资源(并发性资源)篇(第10~14章),分别讲述了队列锁、row cache lock、library cache lock、buffer lock、latch、mutex 等不同并发性资源的作用场合、输入和输出特征,以及优化的主要方法。 由于篇幅所限,优化方法论包含的重要组成部分“组件”并没有包含在本书内容之中。 建议按照顺序阅读本书,当然读者如果仅仅是为了了解某个特定领域的知识,可以不用理会本书的章节顺序,选择自身需要的内容阅读即可。 作为优化方法论类图书,本书不是一次性阅读的快消品,需要多次阅读。由于本书在某些地方涉及了一些其他作品所不具备的细节,也可以作为一 本案头书,必要时可以查阅。 勘误和支持 除封面署名外,美创科技技术服务部对于本书的编写提供了很大的支持,特别是周亮、姜宜民等人。由于作者的水平有限,编写时间仓促,书 中难免会出现一些错误或者不准确的地方,恳请读者批评指正。如果你有更多的宝贵意见,也欢迎发送邮件至邮箱liuzl@ ,期待能够 得到你们的真挚反馈。 致谢 首先要感谢我的夫人陈尚礼,她的支持和鼓励使我没有中途放弃本书的写作。 感谢美创科技技术服务部的同事们,他们提供了大量的性能优化案例使本书内容更加充实。特别是潘敏君和应以峰,我们一起合作完成了本 书。特别感谢周亮,每个章节完成后他都在第一时间进行了校对和纠正,在通篇完成之后又花费了大量时间来进行校对和修订。 特别感谢机械工业出版社华章公司的编辑杨绣国,是你的耐心和鼓励才得以让本书完成。 最后感谢我的女儿,是她时不时地几句“书写完了没有?”让我抓紧把书写完,不至于中途放弃。 谨以此书献给我最亲爱的家人,以及众多对于Oracle数据库性能优化领域感兴趣的朋友们! 柳遵梁 2015年9月于中国杭州 第1章 Oracle性能优化漫谈 1.1 从生活场景漫谈性能优化 Oracle数据库性能优化一直是一个让人既胆怯又兴奋的话题,在初级DBA眼里,这是一个神秘的领域,即使是资深的Oracle DBA,也可能无 法描述清楚性能优化究竟要做什么,应达成什么目标。那么性能优化究竟是做什么的呢?简而言之,性能优化就是让我们的工作速度变快,快到让 我们满意为止。自然,又有读者会问了,我们的工作是什么呢?什么程度才算快,是否可以衡量?看,头疼的问题又来了。 第1章 Oracle性能优化漫谈 1.1 从生活场景漫谈性能优化 Oracle数据库性能优化一直是一个让人既胆怯又兴奋的话题,在初级DBA眼里,这是一个神秘的领域,即使是资深的Oracle DBA,也可能无 法描述清楚性能优化究竟要做什么,应达成什么目标。那么性能优化究竟是做什么的呢?简而言之,性能优化就是让我们的工作速度变快,快到让 我们满意为止。自然,又有读者会问了,我们的工作是什么呢?什么程度才算快,是否可以衡量?看,头疼的问题又来了。 1.2 性能优化目标的确定和衡量 性能优化,顾名思义就是一个改善的过程,通过这个过程实现从当前A到B的目标,其中A和B必须可以被描述和衡量。其中,A为当前状态的 描述和测量。B为需要达到目标状态的描述和测量。 很遗憾的是,在现实的Oracle性能优化实践中,很多情况下A和B不可描述或未被准确描述,只知道我要变快,而且是尽可能的快,最终使性 能优化变成一锅乱炖。 大家都知道,性能优化的常规目标是使响应速度变快,但快和慢是相对而言的,如果两者没有一致的描述基准,那么就会产生问题。比如,如 果觉得现在的系统速度慢,那就必须先弄清楚是如何衡量速度慢的,为什么这种状况就认为它速度慢了呢?以一个电信受理业务为例,客户反馈受 理很慢,需要进行优化,要变快。客户只会告诉你受理慢,不会告诉你更多,其他的东西需要性能优化工作者去挖掘,比如和客户进行沟通,也许 你会郁闷地发现,和你沟通的客户根本就无法说明白为什么慢,以及慢在哪里。 1.3 吞吐量和响应时间 吞吐量和响应时间是衡量Oracle业务系统的基本指标,也是业务系统性能的终极指标。如何选择恰当的指标单元来描述吞吐量和响应时间,并 且熟练运用吞吐量和响应时间之间的关系是性能优化工作者最为重要的学习和实践。吞吐量和响应时间的关系曲线如此重要,以至于本书几乎所有 的章节都是为了帮助大家更好地选择恰当的吞吐量指标,以及更好地理解吞吐量和响应时间的关系曲线。Oracle虽然从Oracle 10gR1就开始提供 Time Based Analyze(TBA)性能优化分析方法论,但显然其并未认识到吞吐量和响应时间曲线的重要性,甚至到现在依然没有明确指出该曲线 对性能优化具有的根本性理论指导作用,这也致使TBA分析方法论一直没有得到很好的利用。 1.4 Oracle性能优化工作的分类 在Oracle上进行性能优化时,不同场景下的优化工作方法和内容有很大的不同。下面从实践角度来展开优化工作的分类。 1.5 测量和变化 1.5.1 测量和性能 没有测量就没有性能,任何科学都建立在可测量的基础之上。Oracle数据库和基于它的性能优化理所当然是一门科学,而不是一门艺术。科学 的性能优化首先必须是可以建立测量的目标系统性能指标。一个无法测量的系统或者一个只能依赖于人的眼睛、耳朵等器官来进行感知的系统是无 法进行性能优化的。为了完成性能优化,需要做大量的可测量性工作。幸运的是,Oracle对于可测量的性能付出了巨大的努力,使其性能相关的测 量指标远远超出了其他数据库。 从性能优化的角度出发,可以从以下几方面来建立性能优化测量指标体系。 ·流程:指从发命令给数据库,到数据库返回我们需要的结果的整个业务处理流程。 ·资源:指在业务处理流程过程中需要使用的软硬件资源,比如CPU、内存等。 ·组件:在流程处理中涉及的处理单元,比如buffer cache等。 流程是业务用户可直接感受的性能指标,与人的感官感觉紧密相连,性能优化的根本目标就是使业务流程顺利运转。构建性能优化可测量体系 的一个简便方法是从顶层目标出发,进行分解和推导,发现其测量因子之间的依赖性、相关性和影响性。在构建此体系的过程中,若把Oracle数据 库及业务流程中涉及的所有组件和资源都作为一个设备或服务来看,则会有相当的便利,更具有真实性。 在业务流程中,当把资源和组件统一作为一个服务中心看待时,也可由此构造出统一的可测量指标体系,如下: ·输入型指标; ·输出型指标; ·状态型指标。 通过上述测量指标一起作用构建出Oracle数据库的监控体系后,即可检测Oracle业务流程是否正常运转。除此之外,为了更快地完成性能优 化,还应该力求在可测量指标之间建立关联,比如依赖性指标、相关性指标、影响性指标等。这样就可以通过指标相关性驱动最终发现真正导致性 能变化的指标,并且采取措施纠正它。 再次查看吞吐量和响应时间的关系曲线,明显可以看到,响应时间是流程的输出结果,而吞吐量则是流程的输入元素。 下面来看一个简单的概念性示例。 假设系统业务为TPCC测试的订单业务,采用订单数量作为吞吐量输入指标。 吞吐量(输入型指标)=每分钟完成的订单数。 吞吐量(输入型指标)=(60/每个订单的响应时间)×并行处理会话 这里并不是在念绕口令,同一个指标采用不同的计算方式在性能优化分析中具有重大意义,它可以让你清晰地了解指标之间的关系,从而采取 正确的优化方式。 根据上面变种的吞吐量公式,可以认为以下两个结论是正确的。 ·在并行处理会话确定的前提下,降低每个订单的响应时间可以提高吞吐量。 ·在每个订单的响应时间确定的情况下,增加并行处理会话可以提高吞吐量。 有足够经验的DBA都知道,上面的结论完全是理论推导。在实际的环境中,若遇到吞吐量下降的场景,且每个订单的响应时间延长,那么总是 可以观察到并行会话的数量增加。甚至可以认为,在业务量变化不大的前提下,并行会话的增加必然意味着吞吐量的下降,而这正是订单的响应时 间的延长导致并行处理会话增加而引起的。 在业务变化不大的前提下,从以上分析可以得出如下结论: ·订单的响应时间延长会导致吞吐量下降。 ·订单的响应时间延长会导致并行处理会话增加。 ·并行处理会话的增加和吞吐量降低具有相关关系。 为什么要这样来描述?原因很简单,因为每个订单的响应时间是相对难以测量的指标,而并行处理会话极其容易被测量。 订单的响应时间=订单的处理时间+订单的等待时间 对于订单的处理时间和订单的等待时间,Oracle都在系统级别做出了很好的测量。 假设图1-8所示的曲线图中那两个圆点是响应时间和吞吐量的最佳平衡点,且在这个平衡点上有服务时间和排队时间,当具体的订单运行点落 到平衡点的右边或者上边的时候就意味着出现了性能问题。每次订单处理都由一系列的众多过程组成,每次订单的处理时间和排队时间自然也由一 系列众多过程的处理之和构成,可以用以下公式来表达: 订单的处理时间=处理次数1×每次处理时间1+处理次数2×每次处理时间2+…… 订单的排队时间=排队次数1×每次排队时间1+排队次数2×每次排队时间2+…… 注意 当处理次数发生明显变化时,意味着业务特征或访问特征发生了变化。对于任何性能优化DBA来说,这都是一个与性能相关的直接 要素。而对于每次处理时间,从Oracle数据库的描述中可以看到,服务处理是由CPU来执行的,正常情况下应该保持稳定,一旦其发生明显变化, 就意味着CPU无法提供足够的能力。 排队次数同处理次数一样代表着业务特征或访问特征,排队时间则表示访问能力。应该说,Oracle数据库系统的性能优化工作者是极其幸运 的,响应时间的分解几乎都可以直接或间接通过测量获得,这就使得Oracle数据库系统成为一个优化就绪的数据库系统。Oracle数据库不仅具有大量 的状态型指标,还具有丰富的输入和输出指标。Oracle数据库不仅关系自身的零部件是否运行正常,而且关心业务操作和流程运行是否正常,也正 因为如此,它使得所有这些东西都可以被直接或者间接测量。 在笔者看来,也许只有Oracle数据库才是性能优化就绪的数据库。 1.6 基线管理 1.6.1 基准点和基线 人们在谈论Oracle业务系统的性能时通常会说它运行得快或慢,但大家都知道快和慢没有一个绝对的标准,所有的快或慢都是基于比较而言 的。比如我们在操场上15s跑完100m,没有人会觉得你跑得快,因为大家都有一个比较的基准,大部分人都可以在12~15s跑完。同样是100m,如 果你是上楼梯,那大家可能会觉得你的速度太惊人了。所以,快慢好坏都是基于比较而言的,没有比较就没有性能的好和坏。因此,为了使性能优 化工作更加科学,需要建立量化的性能基准点,而不能依赖于经验来建立,毕竟经验很难放之四海而皆准,每次衡量快或者慢的时候都可以与这个 基准点进行比较,这个基准点即为基线。在Oracle数据库中,同样需要建立基准点或者基线,用来描述Oracle业务系统在某个特定的状态下,特定 的输入响应和输出响应以及相应提供服务的各个资源和组件状况。当后续的业务运营和基线产生预料之外的偏离时,则表示业务系统发生了变化, 不管是否会产生业务系统性能问题,都需要运维人员介入。 业务运行的状态可能在不同的时间点表现出完全不同的业务特征,在不同的业务特征之间进行比较是没有任何意义的。这时应该建立多个基准 点来完整地描述业务系统的运行特征。比如电信计费系统在白天和晚上、月底和月初都会表现出不同的特征,因此就需要对不同时间点都建立相应 的基准点或基线。 下面通过一个简单的例子来说明基线之于性能优化的重要性。 某业务系统的性能最近变得很差,需要进行性能优化。性能优化专家发现一个明显的现象——CPU利用率达到100%,几乎没有空闲时间。依 据经验,该专家认为这个100%的CPU利用率是属于一个坏指标,并且认为这是其根本原因。通过艰苦的优化工作,CPU利用率有所下降,但是性 能并没有提高,可以想象,应该是专家找错了方向。事实上,这个系统自上线以来其CPU一直工作在100%状态下,且运行良好。在这种情况下, 如果有了CPU的利用率基线,专家就不会犯这个错误,可以正确地把握方向。而且,如果进一步测量指标可以发现,虽然CPU利用率为100%,但 是其服务能力没有任何问题,并且没有在CPU上形成大规模冲突导致其单次服务能力下降。 基线的存在可以大大减轻性能优化者的负担,基线的存在可以使性能优化不再是高手的专利,普通的性能优化工作者甚至是缺乏任何数据库知 识的人都可以轻松地发现导致业务系统性能变差的原因:只要把每个可测量的指标值和该指标的基线值进行比较,出现大规模偏差的一般就是性能 问题的根源所在。 1.7 Oracle性能优化的神话和误区 Oracle性能优化工作是Oracle数据库科学最为神秘莫测的领域,自然也就会流传着各种传言和八卦。本书最主要的目的就是真正使Oracle性能 优化成为一门严谨的科学,使任何阅读并且理解本书内容的读者可以比较简单地完成Oracle性能优化工作,使自己在其他人面前成为“巫 师”或“神秘的对象”。 第2章 Oracle性能优化方法论的发展 Oracle数据库在开发和使用过程中对数据库的性能优化极为重视,几乎在每个版本的更新中都会对可优化的数据库做出改善。不仅如 此,Oracle数据库还会使用优化方法来指导性能优化,会不断推出新的性能优化方法论,并依据优化方法论持续完善其可观察的性能优化体系。 从Oracle 6到现在的Oracle 12c,经历了Oracle 7、Oracle 8、Oracle 8i、Oracle 9i cursor c is select * from v$lock where sid=sys_context('userenv','sid') and type='TX'; begin -- Test statements here for i in 1 loop delete from tobj where rownum2; for i in c loop dbms_output.put_line(i.addr||';'||i.kaddr||';'||i.id1||'.'||i.id2||';'||i.lmode||';'||i.request); exit when c%notfound; end loop; end loop; rollback; end; 脚本的输出如下: 000007FF15744320;000007FF15744398;524290.141720;6;0 000007FF15744320;000007FF15744398;524290.141720;6;0 000007FF15744320;000007FF15744398;524290.141720;6;0 000007FF15744320;000007FF15744398;524290.141720;6;0 000007FF15744320;000007FF15744398;524290.141720;6;0 000007FF15744320;000007FF15744398;524290.141720;6;0 000007FF15744320;000007FF15744398;524290.141720;6;0 000007FF15744320;000007FF15744398;524290.141720;6;0 000007FF15744320;000007FF15744398;524290.141720;6;0 000007FF15744320;000007FF15744398;524290.141720;6;0 10.4 TM锁 TM锁(TM Lock)又被称为DML锁,用于实现对表格对象的一致性访问。从v$enqueue_statistics中可以查询关于TM lock的简单说明,如 图10-65所示。 图10-65 v$enqueue_statistic中关于TM lock的简单说明 记录存储在表格中,是为了避免在访问数据时对象发生变更,任何需要TX锁的操作都需要在表格上加锁。大部分情况下增加的是模式为3的RX 锁,有时候会在请求时要求S锁,在获得之后降级为RX锁,如图10-66所示。 图10-66 更新操作获得TM lock 10.5 sequence相关的锁 作为Oracle内置的一种高效序列发生器的实现,sequence在减少了TX lock冲突的同时,自身也产生了问题。sequence相关的锁定问题是 Oracle性能优化中相对重要的一个篇章,sequence相关的性能问题也比较多见。本章仅描述队列锁问题,sequence相关的latch在latch章节介 绍。 sequence相关的主要锁定问题为SQ lock、row cache lock和DFS lock handle(SV lock)。 sequence的基本结构如下。 数据字典表SEQ$,SEQ$在row cache中映射dc_sequences、sequence cache,Oracle为了加速数据字典处理,会把SEQ$缓存到row cache中,而sequence.nextval导致的SEQ$则构成自包含事务,不可回滚。 10.6 HW lock和ST lock HW lock和ST lock都和空间管理有关,在空间频繁扩展和收回的业务中,HW lock和ST lock可能会经常看到。ST lock在表空间数据字典管理 时代是主要的锁冲突问题,进入位图管理时代,ST lock已经比较少见。而HW锁在日志型应用中是一种比较常见的锁冲突类型。Oracle自身对ST 和HW锁的描述如图10-108所示。 图10-108 ST lock和HW lock的描述 从描述来看,在位图管理时代,ST lock已经消失了。不管它是否消失,在位图管理时代几乎没有遭遇过ST lock,这里就不再对ST lock进行阐 述,仅介绍HW lock。 10.7 CF lock CF lock作用在控制文件上,任何控制文件的读和写都需要CF lock参与。显而易见,控制文件的访问需要I/O操作,也就是说,CF lock的持有 时间是比较长的。过多进程过度频繁地访问CF lock,必然会引起全局业务系统的瘫痪。另外,CF lock作用在控制文件上,磁盘I/O系统锁导致的 各种问题都会引起CF lock的长期持有,比如笔者多次遇到I/O阻塞无响应而导致数据库实例宕机的问题。 10.8 US lock US lock作用于undo segment,是undo segment的对象锁。Oracle在自动管理的undo segment中,总是优先考虑每个事务具有独立的 undo segment,同时为了更高的undo segment管理效率,会经常执行undo segment的offline操作以匹配事务规模,在需要undo segment的 时候执行online。基于同样的目的,smon进程会定期对undo segment执行shrink。除offline、online及shrink外,实际中一个重要的US lock获 得场景就是undo segment retention的自动管理。回滚段自动管理带来了便利性,但在某些高并发性的业务中,特别是在事务众多的系统中会造 成频繁地undo segment retention问题,频繁地自动offline和online,会造成用户进程等待US lock。 另外需要注意的是,在验证中,undo segment extends并不需要US lock参数,而是需要latch:undo global data的参与。latch:undo global data将在后面讲述,这里不会涉及。 10.9 RO lock RO lock主要用于drop或truncate后在buffer cache中进行对象清理。为了维护drop或truncate操作的一致性,需要发起一个local checkpoint操作,把涉及的buffer cache block写回磁盘。为了使其效率更高,Oracle通过fast object reuse机制来实现buffer cache block的快 速重用。不管是在fast object reuse过程中还是在flush buffer cache过程中都需要RO锁。 显然,表格数据在buffer cache中的数据块越多,drop table或truncate table的速度就越慢,需要获取的RO锁就越多,如图10-130所示。 图10-130 RO锁和truncate操作 Fast Object reuse就是在执行truncate或者drop操作的时候不对truncate或者drop涉及的buffer cache对象执行清理操作,而是交由smon 进程慢慢清理。图10-131所示的测试清楚地展示了这种状况。 图10-131 truncate涉及对象的缓慢清理过程 10.10 队列锁运行性能的衡量 10.10.1 队列锁运行性能的衡量指标 队列锁资源的性能主要通过以下指标来衡量。 (1)总请求数(total_requests per second) total_requests pre second:锁资源的总请求次数,该指标用于衡量锁资源的繁忙程度。 (2)总等待数(total_waits per second)和锁等待比例(wait request ratio) total_waits per second:锁资源的总等待次数,该指标用于衡量锁冲突的程度,在并发性系统中,与total_requests具有一致性关系。 wait_request_ratio:锁等待比例,计算公式为wait_requst_ratio=total wait per second/total requests per second。 (3)成功请求数(succ_requests per second)和成功请求率(lock request ratio) succ_requests:成功获得锁的次数。 lock request ratio:成功获得锁资源的比例,计算公式为succ_request per second/total requests per second。 (4)失败请求数(failed_requests) failed_requests:锁请求失败的次数,包含死锁的次数。 (5)死锁发生次数(deadlock_requests) deadlock_requests:死锁发生的次数。 (6)平均响应时间(avgresponsetime) avgresponsetime:平均锁等待和持有时间,该指标很有用,但是目前无法获得。 (7)平均等待时间(avgWaitTime) avgWaitTime:平均锁等待时间。 (8)最大等待时间(maxWaitTime) maxWaitTime:最长锁等待时间,锁性能事故的发布往往不是由平均等待决定的,而是由最大等待决定的。 10.11 队列锁资源优化的目标和道路 队列锁属于并发性控制资源,并发性控制资源就是只有当并发业务多时才有可能发生队列锁资源问题。 假设200个用户共同更新某一行,更新一行的事务需要100ms。大家都知道100ms再正常不过。200个transaction以队列形式排队,每个处理 100ms,到达第200个transation时,他的事务处理时间为200*100ms=20000ms=20s。这下问题来了,20s的响应几乎在所有的oltp系统都无法 接受。当然这是极端情况,但性能问题都是在极端情况下发生的。 可能有人会说,怎么可能会出现这样的业务逻辑呢!是的,这样的业务逻辑不存在。但是以下的业务逻辑是普遍存在的,否则就不存在锁定问 题了。 2~3个transaction更新相同的行,每2~3个transaction形成相互依赖。事实上,这种情况的200个transaction并发和200个transaction作用 于相同行的transaction并发没有任何区别。业务有时确实需要这样操作,这也是Oracle为什么会有处理上限的根本原因之一。 队列锁资源不同于简单的硬件资源,不同的队列锁有其不同的产生场景,但总体而言,所有队列锁的处理方式都是一致的。基本而言,队列锁 资源的问题主要由以下几个因素构成。 ·业务压力导致的巨量队列锁资源需求。 ·业务不当导致过多持有队列锁。 ·持有队列锁的时间过长。 ·缺乏事务失败思维导致事务规模过大。 ·调度和运维不当导致队列锁长期持有。 ·拥有队列锁资源的进程处于僵死或不活动状态。 10.12 队列锁资源优化案例 1.超级事务回滚导致队列锁资源和smon资源缺乏 某运营商的账务系统在某时刻出现业务系统性能下降,简单检查为大量的TX锁等待,同时发现smon在进行大型事务回滚。该业务锁等待的原 因非常简单,手工处理的批量update操作意外被中止,引起系统回滚。回滚操作依赖于smon,其回滚的速度非常缓慢。在这种情况下,只能等待 回滚完成,或者重新启动数据库加速回滚。超级事务失败是一个实践中普遍存在的性能故障,每年总有发生。 2.select for update锁定所有记录 在业务运行过程中,某张主要表格发生大规模的TX锁冲突,导致业务完全挂起。其原因非常简单,某个维护人员通过PLSQL发起了一个select for update操作,导致表格大量的行被锁定。 3.sequence cache过小引起数据库登录挂起 某运营商实时计费系统偶尔会出现session挂起,所有的session登录几乎完全被挂起,而运行中的session则可以正常操作。检查systemdump 发现,所有的挂起session都在等待audses$的sequence,只要把占有的SQ lock的sesssion杀掉,所有登录都可以继续。检查audses$的cache为 默认的20,增大audses$的cache为10000,业务系统再也没有出现类似状况。 4.SQ lock和US lock冲突导致业务系统缓慢 某运营商业务系统突然变得异常缓慢,大量的SQ lock、US lock、row cache objects latch、undo global data latch及row cache lock 锁。简单关闭_undo_autotune可恢复业务,但是其根本原因是新上线的某业务中包含了高并发的sequence,其cache默认为20。 5.rman调度删除归档日志导致业务短暂挂起 某医院业务系统间歇性地出现业务停顿5秒左右,已经持续了一些时间。检查之后,发现问题源于无法获得CF lock,而CF lock被rman进程所 持有。修改定期运行rman删除归档日志为操作系统删除,问题得以解决。 6.控制文件自动备份到NFS引起系统挂起 某运营商每一两月会发生一次业务系统挂起,挂起时表现为ckpt进程等待CF lock。检查错误日志,发现存在控制文件自动备份,而且自动备 份的目标为NFS。把自动备份调度到本地磁盘,然后通过操作系统工具复制到NFS,故障完全消失。 7.Oracle错误引发dump redolog导致ckpt等待 某运营商业务系统发生挂起,挂起时间大约为5分钟,挂起期间ckpt等待CF lock。检查系统发现挂起期间发生一个oracle错误,该错误引起了 diag进程执行redo log dump,该dump的持续时间大约5分钟。对所有dump文件大小进行限制,该故障后续再次发生,无法确认是否该处理有 效。 8.业务处理中的ddl引起业务稳定性不足 某银行在一个业务批处理中包含truncate语句,发现truncate语句的性能不可预估,有时候很快,有时候则很慢。建议进行循环分区以替代这 个需要不断truncate的表格,新进入的数据都是具有时间序列的数据,该业务每月执行一次。以月份除以3的余数作为分区键,这样新的数据自然 就落入了自己的分区,在业务批处理启动之前或其他运维空闲时段对过期数据进行truncate,避免在业务周期发生truncate。循环分区处理之后, 业务批处理运行稳定可靠。 第11章 资源供给:row cache lock和library cache lock 11.1 简单案例分享 某运营商持续出现library cache lock、library cache load lock及library cache latch冲突,即使重新启动,也只在最初略有缓解,之后很快 就会继续发生状况。最初判断是因为shared pool不足引起的,持续观察shared pool,发现自由空间在迅速减少,当减少到一定程度之后出现大量 的libray cache lock和library cache load lock。在此过程中,系统中存在大量的hard parse,增加cursor sharing之后,该问题基本消失。但 是,打开cursor sharing之后导致部分业务不可继续,无法启用cursor sharing。于是持续监控shared pool,在shared pool达到阈值后进行flush pool,终于使该问题得到控制。最后判断此为Oracle bug,因Oracle无法正确处理shared pool的lru策略,等待Oracle patch而导致。后续补丁 到位之后,打上补丁,该问题消失。 第11章 资源供给:row cache lock和library cache lock 11.1 简单案例分享 某运营商持续出现library cache lock、library cache load lock及library cache latch冲突,即使重新启动,也只在最初略有缓解,之后很快 就会继续发生状况。最初判断是因为shared pool不足引起的,持续观察shared pool,发现自由空间在迅速减少,当减少到一定程度之后出现大量 的libray cache lock和library cache load lock。在此过程中,系统中存在大量的hard parse,增加cursor sharing之后,该问题基本消失。但 是,打开cursor sharing之后导致部分业务不可继续,无法启用cursor sharing。于是持续监控shared pool,在shared pool达到阈值后进行flush pool,终于使该问题得到控制。最后判断此为Oracle bug,因Oracle无法正确处理shared pool的lru策略,等待Oracle patch而导致。后续补丁 到位之后,打上补丁,该问题消失。 11.2 row cache lock和ddl lock row cache用于保存数据字典的缓冲,而row cache lock则是对数据字典做出变更或禁止其他人变更时,加载在row cache obect上的锁。我 们平常所讲的ddl锁事实上是row cache lock的一个子集,因此ddl lock必然会涉及row cache lock,只是ddl lock不仅包含row cache lock,还 包含library cache lock等其他enqueue资源。 11.3 library cache lock library cache lock主要在ddl操作和parse操作过程中产生。回顾前面章节涉及的library cache结构,如图11-13所示。 图11-13 library cache结构图 library cache lock就产生在object handles中,在object handles链中object handle的增加和减少都需要library cache lock的参与。和 library cache lock紧密相关的有两个enqueue:library cache load lock和library cache pin。library cache load lock的作用是把library cache object加载到library cache中,而library cache pin则作用在library cache object handle下面的heap上。关于这三个enqueue是如何工作的,请 参见 11.4 row cache lock和library cache lock运行性能的衡量 11.4.1 row cache lock资源运行性能的衡量指标 row cache lock锁资源的性能,主要通过以下指标来衡量。 (1)总更新数(total_modified per second) total_modified per second:数据字典被更新的次数,每次更新都意味着一次exclusive row cache lock的占用。 (2)总刷新数(total_flushed per second) total_flushed per second:由于row cache对象交换需要刷出row cache的次数,所以频繁地被刷出意味着shared pool不足,导致其需要再 次被装载。 (3)等待次数(wait count per second) wait count per second:需要等待获得row cache lock的次数。 (4)平均等待时间(avgWaitTime) avgWaitTime:平均锁等待时间。 (5)最大等待时间(maxWaitTime) maxWaitTime:最长锁等待时间,锁性能事故的发布往往不是由平均等待决定的,而是由最大等待决定的。 11.5 row cache lock锁资源优化的目标和道路 row cache lock锁资源主要获得的场景来源于以下两个方面。 ·数据字典的变化。 ·row cache object首次装载到row cache和重新装载到row cache。 11.6 library cache lock锁资源的目标和道路 library cache lock的
展开阅读全文
  文库网所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
0条评论

还可以输入200字符

暂无评论,赶快抢占沙发吧。

关于本文
本文标题:Oracle数据库性能优化方法论和最佳实践.html.pdf
链接地址:http://www.wenkunet.com/p-2185385.html
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

文库网用户QQ群:731843829    百度熊掌号:文库网精选     微信公众号:WENKUNET

copyright© 2018-2020 文库网 wenkunet.com 网站版权所有

经营许可证编号:粤ICP备19143267号-1 


1.png 2.png 3.png 4.png 5.png 6.png 7.png 8.png 9.png 10.png