-
编辑 删除
资源供给：再谈内存和虚拟内存
简单案例描述： 某客户业务系统一直运行正常，突然之间业务系统急剧变慢，数据库体现大量的buffer busy waits，部分cache buffer chain，操作系统表现出页面交换，内存吃紧。原因很简单，有人发起了一和大文件的ftp操作，消耗了大量内存。类似的事件也很多会如此表现，...
-
编辑 删除
资源供给：内存和虚拟内存
简单案例： 某客户运行在HP Unix上的Oracle数据库周期性的出现业务系统性能下降，甚至于业务系统挂起，每次都需要重新启动服务器来完成。服务器拥有很高的内存，数据库也没有分配太高的内存，原因当然也很简单，交换空间配置太少，使进程派生受限，导致进程空间的内存不断被交...
-
编辑 删除
资源供给：再谈CPU
虽然CPU利用率达到100%并不是判断CPU是否有效的足够依据，但100%的CPU会带来一定问题，就是我们无法判断CPU究竟是足够有效还是完全跟不上。对于OLTP并发还可以通过CPU Queue来完成观察，对于批处理应用我们几乎无法来判断是否有问题，只能依据业务层面的数据来判断CPU是否给足够有利...
-
编辑 删除
资源供给：CPU
CPU资源运行的主要指标：CPU ratio和CPU Queue CPU Time 和CPU queue Time
-
编辑 删除
关于类似于awr的性能分析报告
在可测量的指标体系完成之后，本来是应该构造一个类似于AWR报告的性能分析报告，以使性能优化方法论可以落到实处，不过这个要花费大量时间，在空闲时间比较多的时候会完成这么一个性能分析报告，使初学者也可以依据这份报告完成大部分性能优化作业。当然如果我可以坚持到乱弹的这些东西成书...
-
编辑 删除
从几个简单案例说起
本来这部分内容应该安排在最前面，作为抛砖引玉的，不过在这里给出，会更加容易理解。 案例一、某银行网上银行系统每月或者每几月会出现一次或者几次业务性能快速下跌，响应迟缓。具体表现为CPU利用率居高不下，在大多数情况下，重新启动之后...
-
编辑 删除
Oracle性能测量体系（commit Time)
在高事务并发的业务系统中,commit time是Oracle的巨大伤痛所在，commit time是目前为止Oracle最大的串行化所在，其处理能力直接决定了数据库可以处理多少负载。特别在database link环境中，commit time会带来致命的杀伤力，这也是在database link环境中无法做到高并发的基本原因之一。 &nb...
-
编辑 删除
Oracle性能测量体系（Execute Time)
在数据库处理时间响应中，一般来说Execute处理阶段是消耗资源的大户，也是消耗时间的主体部分。特别在批处理系统，没有人去关心parse time的微薄消耗。 Execute RT:= Execute CPU Time + Execute Queue TIme &n...
-
编辑 删除
Oracle性能测量体系（Parse Time)续
Parse Time:= Parse CPU Time + Queue Wait Time Parse阶段几乎所有操作都在shared pool内进行操作，主要的Queue Wait time包含以下几种： library cache latch|library cache: mutex &nb...
-
编辑 删除
Oracle性能测量体系（Parse Time)
Parse阶段的性能测量体系，确定时间响应和吞吐量orac
-
编辑 删除
Oracle性能测量体系
吞吐量曲线的两个基本点：吞吐量和响应时间，所有的Oracle性能测量体系都由这两个指标派生而来。 响应时间： 每个LIO的响应时间 &...
-
编辑 删除
吞吐量的确定（续）
实际运行的性能曲线，已经很明显的看到db time和lio之间响应曲线，符合吞吐量的曲线，也很明显的可以发现在CPU资源保证充足的情况下，随着吞吐量的上升，每个LIO的服务时间几乎没有发生变化，主要是Queue Time大幅度...
-
编辑 删除
吞吐量的确定（续）
BEGIN_TIME END_TIME LIO DBTIME WAITRATIO CPURATIO 2013/10/31 7:21:05 2013/10/31 7:22:05 10.81397292 0.14081063 44.4490605 55.5509395 2013/10/31 7:23:05...
-
编辑 删除
吞吐量的确定
不管业务程序设计的如何优秀，优异表现总是在一定的吞吐量范畴之内，当超过吞吐量限制之后性能必然会产生变异。在衡量性能的时候，确定吞吐量就成为一个基础性工作。 &...
-
编辑 删除
流程分析响应时间的确定
经过前面的陈述，我们可以确定流程分析响应时间的测量值 业务响应时间：= Client处理时间（Client运行 + 网络传输 ） + 数据库处理时间 ...
-
编辑 删除
数据库处理时间的确定
Oracle从10g开始已经构造了相对完整的响应时间分析方法，并且分别在系统全局，session和SQL级别做了分别的处理，已经比较完善。 回到吞吐量曲线和响应时间公式： ...
-
编辑 删除
网络传输时间和客户端处理时间的界定（交互式应用）
在确定了批处理业务的SQLNet Message from client表示网络传输和client处理之后，我们来看交互式应用的情况。交互式情况的问题在于并非像批处理一样持续运行，总是纳入运行时间，而是中间存在着...
-
编辑 删除
网络传输时间和客户端处理时间的界定（批处理应用）
批处理的测试案例构造： 简单的采用Jmeter来进行测试，类似于实现下面简单的逻辑： declare ...
-
编辑 删除
网络传输时间以及Client的处理的测试方案
流程分析方法需要测量网络传输时间以及client处理的测试方案。 测试工具，基本采用hammerora以及PLSQL包 &nb...
-
编辑 删除
业务响应时间和数据库性能
在某种程度上，用户并不关心数据库性能，他关心数据库性能是因为他认为业务系统性能不佳是数据库性能不佳引起的。数据库仅仅是业务系统响应性能的一部分因素，可能是很重要的因素，也可...
