发现现在有相当一部分使用LoadRunner的朋友面对LoadRunner的一大堆测试结果常常无所适从，不知道如何把这些测试结果真正利用起来。因此我把我个人学习LoadRunner的一些笔记和心得贴在这里，它到目前为止还是一堆很杂乱的东西，并没有形成一个系统的东西，而且其中可能会存在很多错误，希望各位测试同行能多多批评指教。

　　一、 Web Page Breakdown

　　DNS 解析时间： 显示使用最近的 DNS 服务器将 DNS 名称解析为 IP 地址所需的时间； DNS 查找度量是指示 DNS 解析问题或 DNS 服务器问题的一个很好的指示器；

　　Connect 时间： 显示与包含指定 URL 的 Web 服务器建立初始连接所需的时间； Connect 度量是一个很好的网络问题指示器；它还可表明服务器是否对请求做出响应；

　　First buffer 时间： 显示从初始 HTTP 请求到成功收回来自 WEB 服务器的第一次缓冲时为止所经过的时间； First buffer 度量是很好的 Web 服务器延迟和网络滞后指示器；

　　SSL Handshaking time ： 显示建立 SSL 连接所用的时间

　　Receive Time ： 显示从服务器收到最后一个字节并完成下载之前经过的时间；接收度量是很好的网络质量指示器；

　　FTP 验证时间： 显示验证客户端所用的时间。

　　Client Time ： 显示因浏览器思考时间或其他与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的时间。

　　Error 时间： 显示从发出 HTTP 请求到返回错误消息这期间所经过的平均时间

　　二、 关于 TPS （ Transactions per Second ）： 每秒处理事务数

　　这个值可以说明系统在特定的负载情况下，每秒可以处理多少个客户端请求，这是一个衡量服务器端性能的重要指标，相信各位在进行性能测试的时候经常会用到这个指标。但是一直以来我都有一个疑问，到底这个值是怎么算出来的。既然是每秒事务数，那算法自然是“事务数 / 时间”。事务数很好理解，执行了多少就是多少，关键是这个时间。是整个场景执行的时间，还是仅仅是在服务器端执行的时间？因为我们知道，这两个时间肯定是有区别的，前者还包括 thinktime 的时间、 pacing 的时间以及在网络上耗费的时间等等。

　　为了弄明白这个问题，我今天特地查了一下帮助文档，看到上面是这么说的：“每秒事务数图显示在场景或会话步骤运行的每一秒中，每个事务通过、失败以及停止的次数。”如果按照这句话去理解，那么上面那个问题的答案应该是后者，也就是说，在 Transaactions per Second 这张图中， LoadRunner 是针对场景运行过程中的每一个时间点取样一次，显示在这个时间点上每个事务的通过、失败以及停止的个数。

　　另外，我还在 Analysis 里面找了一下，发现图表的时间显示粒度也是可以设置的。具体方法为：在图表上点击右键 -> 选择“ Set Granularity ”或者直接按 Ctrl+G 。我试着把时间粒度调成以毫秒为单位，结果 LoadRunner 提示当前不支持以毫秒为显示粒度，由此我推断 LoadRunner 对于 Transactions per Second 这张图，最小的取样粒度为 1 秒。

　　三、 事务响应时间（百分比）图

　　这个图显示的是事务响应时间范围的分布情况。在场景的执行中，每个定义的事务可能会不止被处理一次（因为设置了持续时间或者迭代次数）， LoadRunner 会为每个事务实例的处理分别记录响应时间。在 Summary Report 中， LoadRunner 会针对每个事务的响应时间数据集合，分别取它的最大值、最小值和平均值，通常我们会关注响应时间的平均值。然而很多时候，单单是平均响应时间可能是不够的，因为一旦最大值和最小值出现较大的偏差，即便平均响应时间处在可以接受的范围内，但并不意味着整个系统的性能就是可以接受的，我们有必要再借助其它的分析报表来进一步分析，此时事务响应时间（百分比）图就派上用场了。

　　事务响应时间（百分比）给出的是每个事务的响应时间按百分比的分布情况，它告诉我们本次测试有多少个事务的平均响应时间是落在我们可以接受的时间范围之内。如果最大响应时间非常长，但是绝大多数事务（通常情况下以 95% 为参考）的响应时间具有可以接受的响应时间，则我们认为整个系统的性能还是可以接受的。

　　注意： Analysis 将对每个可用事务百分比的事务响应时间取近似值。因此 Y 轴的值可能并不准确。

　　四、 事务响应时间（负载下）图

　　这个图显示的是事务响应时间随着场景中虚拟用户的逐渐增长的变化趋势图，该图可以帮助我们查看 Vuser 负载对性能问题的影响。当我们需要了解某个事务的响应时间随着虚拟用户的增加而产生的变化时，可以通过在控制台中设置一个渐变负载的场景的方式来实现。例如每 5 分钟加载 10 个用户等，然后考察得到的这张图表，就能够对此有一个比较好的理解。

性能测试工程师基本上都能够掌握利用测试工具来作负载、压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。 分析原则：
1. 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
2. 查找瓶颈时按以下顺序，由易到难。
    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
3 分段排除法 很有效
分析的信息来源：
1 根据场景运行过程中的错误提示信息
2 根据测试结果收集到的监控指标数据
一．错误提示分析
分析实例：
1 Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection
  Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely
分析：
 A、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题）
 B、应用服务没有死
（应用服务参数设置问题）
    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
 C、数据库的连接
(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)
2 Error: Page download timeout (120 seconds) has expired
分析：可能是以下原因造成
 A、应用服务参数设置太大导致服务器的瓶颈
 B、页面中图片太多
 C、在程序处理表的时候检查字段太大多
二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
    在方案运行中，如果出现了大于3个用
户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
    如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
2．业务操作响应时间：
     分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
    细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
  如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率; 
内存不够出错(out of memory errors)
处理器：
1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 
合理使用的范围在60%至70%。
2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆: 
很慢的响应时间(slow response time) 
CPU空闲时间为零(zero percent idle CPU) 
过高的用户占用CPU时间(high percent user CPU) 
过高的系统占用CPU时间(high percent system CPU) 
长时间的有很长的运行进程队列(large run queue size sustained over time)
磁盘I/O：
1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
I/O资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilization) 
太长的磁盘等待队列(large disk queue length) 
等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O) 
太高的物理I/O速率:large physical I/O rate(not sufficient in itself) 
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself)) 
太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)
4．数据库服务器：
SQL Server数据库：
1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。 
3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。
Oracle数据库：
1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
快存（共享SQL区）和数据字典快存的命中率： 
select(sum(pins-reloads))/sum(pins) from v$librarycache; 
select(sum(gets-getmisses))/sum(gets) from v$rowcache; 
自由内存： select * from v$sgastat where name=’free memory’; 
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
缓冲区高速缓存命中率：
select name,value from v$sysstat where name in (’db block gets’,
‘consistent gets’,'physical reads’) ;
Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
日志缓冲区的申请情况 ：
select name,value from v$sysstat where name = ‘redo log space requests’ ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
内存排序命中率 ：
select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’
注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

 

  性能测试的结果分析是性能测试的重中之重。在实际工作中，由于测试的结果分析比较复

杂、需要具备很多相关的专业知识，因此常常会感觉拿到数据不知从何下手。这也是我学习性能

测试过程中感觉比较尴尬和棘手的事，为此我在研读了《WEB性能测试实战》后特作了以下笔

记，这里只是书中第4章WEB应用程序性能分析的一

部分，贴出来希望和大家共同讨论：

一：性能分析的基础知识：

    1.几个重要的性能指标：相应时间、吞吐量、吞吐率、TPS（每秒钟处理的交易数）、点

击率等。

    2.系统的瓶颈分为两类：网络的和服务器的。服务器瓶颈主要涉及：应用程序、WEB服务

器、数据库服务器、操作系统四个方面。

    3.常规、粗略的性能分析方法：

   当增大系统的压力（或增加并发用户数）时，吞吐率和TPS的变化曲线呈大体一致，则系统

基本稳定；若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，很可能是

网络出现带宽瓶颈，同理若点击率/TPS曲线出现变化缓慢或者平坦，说明服务器开始出现颈。

    4.作者提出了如下的性能分析基本原则，此原则本人十分赞同：

            ——由外而内、由表及里、层层深入

    应用此原则，分析步骤具体可以分为以下三步：

   第一步：将得到的响应时间和用户对性能的期望值比较确定是否存在瓶颈；

   第二步：比较Tn（网络响应时间）和Ts（服务器响应时间）可以确定瓶颈发生在网络还是服

务器；

   第三步：进一步分析，确定更细组件的响应时间，直到找出发生性能瓶颈的根本原因。

二：以WEB应用程序为例来看下具体的分析方法：

    1.用户事务分析：

    a.事务综述图(Transaction Summary ):以柱状图的形式表现了用户事务执行的成功与

失败。通过分析成功与失败的数据可以直接判断出系统是否运行正常。若失败的事务非常多，则

说明系统发生了瓶颈或者程序在执行过程中发生了问题。

    b.事务平均响应时间分析图（Average Transaction Response Time）: 该图显示在

测试场景运行期间的每一秒内事务执行所用的平均时间，还显示了测试场景运行时间内各个事务

的最大值、最小值和平均值。通过它可以分析系统的性能走向。若所有事务响应时间基本成一条

曲线，则说明系统性能基本稳定；否则如果平均事务响应时间逐渐变慢，说明性能有下降趋势，

造成性能下降的原因有可能是由于内存泄漏导致。

    c.每秒通过事务数分析图（Transaction per Second即TPS）:显示在场景运行的每一

秒中，每个事 务通过、失败以及停止的数量。通过它可以确定系统在任何给定时刻的实际事务

负载。若随着测试的进展，应用系统在单位时间内通过的事务数目在减少，则说明服务器出现瓶

颈。

     d.每秒通过事务总数分析图（Total Transactions per Second）:显示场景运行的

每一秒中，通过、失败以及停止的事务总数。若在同等压力下，曲线接近直线，则性能基本趋于

稳定；若在单位时间内通过的事务总量越来越少，即整体性能下降。原因可能是内存泄漏或者程

序中的缺陷。

      e.事务性能摘要图（Transaction Performance Summary）:显示方案中所有事务的

最小、最大平均执行时间，可以直接判断响应时间是否符合客户要求（重点关注事务平均、最大

执行时间）。

      f.事务响应时间与负载分析图（Transaction Response Time Under load）:通过

该图可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性

能数据。

      g.事务响应时间（百分比）图（Transaction Response Time(percentile)）:该

图是根据测试结果进行分析而得到的综合分析图。分析该图应从整体出发，若可能事务的最大响

应时间很长，但如果大多数事务具有可接受的响应时间，则系统的性能是符合。

      h.事务响应时间分布情况图（Transaction Response Time (Distribution)）:该

图显示了测试过程中不同响应时间的事务数量。若系统预先定义了相关事务可以接受的最小和最

大事务响应时间，则可以使用此图确定系统性能是否在接受范围内。

      分析到这一步，只能大概判断出瓶颈可能会出在那，要具体定位瓶颈还需要更深入

的分析。没有贴图，看起来有点费劲，如果你对这些图都比较了解，应该是比较简单的.

这篇文章主要介绍了相比于python2.6，python3.0的新特性。更详细的介绍请参见python3.0的文档。


Common Stumbling Blocks

本段简单的列出容易使人出错的变动。

    * print语句被print()函数取代了，可以使用关键字参数来替代老的print特殊语法。例如：
         1. Old: print "The answer is", 2*2
         2. New: print("The answer is", 2*2)
         3. Old: print x,                                      # 使用逗号结尾禁止换行
         4. New: print(x, end=" ")                     # 使用空格代替换行
         5. Old: print                                         # 输出新行
         6. New: print()                                    # 输出新行
         7. Old: print >>sys.stderr, "fatal error"
         8. New: print("fatal error", file=sys.stderr)
         9. Old: print (x, y)                               # 输出repr((x, y))
        10. New: print((x, y))                           # 不同于print(x, y)!
      你可以自定义输出项之间的分隔符：
           print("There are <", 2**32, "> possibilities!", sep="")
      输出结果是：
           There are <4294967296> possibilities!

      注意：
         1. print()函数不支持老print语句的“软空格”特性，例如，在python2.x中，print "A\n", "B"会输出"A\nB\n"，而python3.0中，print("A\n", "B")会输出"A\n B\n"
         2. 学会渐渐习惯print()吧！
         3. 使用2to3源码转换工具时，所有的print语句被自动转换成print()函数调用，对大项目，这是无需争论的。
    * python3.0使用字符串(strings)和bytes代替Unicode字符串和8位字符串，这意味着几乎所有使用Unicode编码和二进制数据的代码都要改动。这个改动很不错，在2.x的世界里，无数的bug都是因为编码问题。
    * map()和filter()返回迭代器(iterators)
    * dict方法keys(),items(),values()返回视图(同样是迭代器)而不是列表(list)
    * 内建的sorted()方法和list.sort()方法不再接受表示比较函数的cmp参数，使用key参数代替。
    * 1/2返回浮点数，使用1//2能得到整数。
    * repr()函数对于long整数不再包含拖尾的L，所以不加判断的去除最后一个字符会导致去掉一个有用的数字。

String and Bytes

    * 现在只有一种字符串:str,它的行为和实现都很像2.x的unicode串。
    * basestring超类已经去掉了，2to3工具会把每个出现的basestring替换成str。
    * PEP3137:新类型bytes，用来表示二进制数据和编码文本，str和bytes不能混合，需要时，必须进行显示的转换，转换方法是str.encode()(str->bytes)和bytes.decode()(bytes->str).
    * 在原始字符串(raw strings)中所有反斜线都按字面量解释，不再特殊处理Unicode转义字符。
    * PEP3112:bytes字面量，例如b"abc"，创建bytes实例。
    * PEP3120:默认源文件编码为UTF-8
    * PEP3131:可以使用非ASCII标识符(然而，除了注释中贡献者的名字之外，标准库仍然只包含ASCII)
    * PEP3116:新的IO实现，API几乎100%向后兼容，二进制文件使用bytes代替strings
    * 去除了StringIO和cStringIO模块，取而代之的是io.StringIO或者io.BytesIO

PEP3101：字符串格式化的新方法

    * str.format方法(原文提到替代了%操作符，实际上，format方法和%的用法差别很大，各有所长)。

PEP3106:修补了dict的keys(),items(),values()方法

    * 删除了dict.iterkeys(),dict.itervalues()和dict.iteritems()
    * dict.keys(),dict.values()和dict.items()返回dict相关数据的引用

PEP3107:函数注解(Function Annotations)

    * 注解函数参数和返回值的标准化方法

Exception Stuff

    * PEP352:异常类必须继承自BaseException,它异常结构的基类。
    * 移除了StandardError
    * Dropping sequence behavior. (slicing!) and message attribute of exception instances.
    * PEP3109:抛出异常：现在必须使用raise Exception(args)而不是原来的raise Exception, args
    * PEP3110:捕获异常，现在必须使用except Exception as identifier而不是原来的except Exception, identifier
    * PEP3134:异常链(Exception chain)。
    * 改良了一些windows不能加载模式时的异常信息，具有本地化处理。

New Class and Metaclass Stuff

    * 移除了classic class
    * PEP3115:新的metaclass语法
    * PEP3119:抽象基类。
    * PEP3129:类包装。
    * PEP3141:数字抽象基类

其他的语言变化

这里列出大多数的python语言核心和内建函数的变化。

    * 移除了backticks(使用repr()代替)
    * 移除了<>(不等号，使用!=代替)
    * as和with变成了关键字
    * True,False和None变成了关键字
    * PEP237:long不存在了，只有int，它和原来的long一样。不再支持以L结尾的数字字面量。移除sys.maxint，因为int现在已经是无限大了
    * PEP238:int相除，返回float
    * 改变了顺序操作符的行为，例如x<y，当x和y类型不匹配时抛出TypeError而不是返回随即的bool值
    * 移除了__getslice__，语法a[i:j]被解释成a.__getitem__(slice(i,j))
    * PEP3102:keyword-only arguments.在函数参数列表中，出现在*args之后的命名参数只能使用"关键字参数"的形式调用
    * PEP3104:nonlocal声明。使用nonlocal可以声明一个外部变量(不是global变量)
    * PEP3111:raw_input()改名为input()，也就是说，新的input()函数从标准输入设备(sys.stdin)读取一行并返回(不包括行结束符)，如果输入过早终止，该函数抛出EOFError，如果想使用老的input()，可以使用eval(input())代替。
    * xrange()改名为range()，range()现在不是产生一个列表(list)，而是一个迭代器。
    * PEP3113:移除了"元组参数拆包(tuple parameter unpacking)"。这种写法已经不行了：
      def foo(a, (b, c)):...
      现在要这样写:
      def foo(a, b_c):
            b,c = b_c
    * PEP3114:next()重命名为__next__(),新的内建函数next()可以调用一个对象的__next__()方法。
    * PEP3127:新的八进制字面量，二进制字面量和bin()函数。你应该写0o666而不是0666，oct()函数也做了响应的改动。同样，0b1010等价于10，bin(10)返回"0b1010"。0666这种写法现在是错误的。
    * PEP3132:支持迭代器拆包。现在你可以这样写:
      a, b, *rest = some_seqence
      甚至象这样：
      *rest, a = stuff
      一般情况下，rest对象是list，而等号右边的对象是可迭代的
    * PEP3135:新的super()。你可以不适用任何参数调用super()，正确的参数和实例会被正确选择。如果使用参数，它的行为不变，和以前一样。
    * zip(),map(),filter()返回迭代器。
    * 移除了string.letters和它的朋友们(string.lowcase和string.uppercase)，现在上场的是string.ascii_letters等
    * 移除了apply(),callable(),exefile(),file(),reduce(),reload()
    * 移除了dict.has_key()。使用in操作符进行测试
    * exec语句没有了，现在是exec()函数
    * 移除了__oct__()和__hex__()特殊方法。oct()和hex()方法使用__index__()
    * 移除了对__members__和__methods__的支持
    * nb_nonzero重命名为nb_bool,__nonzero__()重命名为__bool__()

Optimizations

    * 一般情况下，python 3.0比python 2.5慢33%左右。不过仍有提升空间。

模块变动(新的，改进的和废弃的)

    * 移除了cPickle模块，可以使用pickle模块代替。最终我们将会有一个透明高效的模块。
    * 移除了imageop模块
    * 移除了audiodev, Bastion, bsddb185, exceptions, linuxaudiodev, md5, MimeWriter, mimify, popen2, rexec, sets, sha, stringold, strop, sunaudiodev, timing和xmllib模块
    * 移除了bsddb模块(单独发布，可以从http://www.jcea.es/programacion/pybsddb.htm获取)
    * 移除了new模块
    * os.tmpnam()和os.tmpfile()函数被移动到tmpfile模块下
    * tokenize模块现在使用bytes工作。主要的入口点不再是generate_tokens，而是tokenize.tokenize()

Build and C API Changes

Python’s build process和C API的改动包括:

    * PEP3118:新的Buffer API
    * PEP3121:扩展模块的的Initialization & Finalization
    * PEP3123:使PyObject_HEAD符合标准C

其他的改动和修复

在源码里分散一系列的改进和bug修复。changes log表明，从2.6到3.0，有XXX个改动和YYY的bug修复。

一、概述 LAODRUNNER8.1 作为专业的性能测试工具,通过模拟成千上万的用户对被测应用进行操作和请求,在实验室环境中精确重现生产环境中任意可能出现的业务压力,然后通过在测试过程中获取的信息和数据来确认和查找软件的性能问题,分析性能瓶颈.

LOADRUNNER提供了三个大主要模块,这三个模块既可以作为独立的工具分别完成各自的功能,又可以作为LOADRUNNER的一部分彼此衔接,与其他模块共同完成软件性能的整体测试.这三大模块主要是:

Ø         VITUAL USER GENERATOR--------用于录制脚本

Ø         MERCURY LOADRUNNER CONTROLLER---------用于创建,运行和监视场景

Ø         MERCURY LOADRUNNER ANALYSIS--------用于分析测试结果;

二、LOADRUNNER8.1 安装 LAODRUNNER8.安装过程比较简单,只需按系统的提示一步一步操作就可以了,这里对安装过程中的一些要点进行简要的说明.

Ø         安装类型 

安装盘内有两个盘片,MERCURY LOADRUNNER8.1和MECURY LOADRUNNER 8.0ADD-INS.前者包括了LR安装程序及常用组件,后者全部为组件,各组件的作用在安装盘中都有详细的提示.

Ø         LICENSE 类型

LICENSE类型说明如下:

PERMANENT  永不过期的LICENSE;

TIME LIMITED  限定了使用的起始时间和使用周期;

TEMPORARY   从安装后开始计算,限定了使用的天数;

VUD-BASED   限定了虚拟用户数量

PLUGGED   需要DONGLE,也就是HARDWARE KEY,DONGLE在中国被音译为“狗”,主要是防止软件被盗用

Ø         RPM和WEB SERVER之间的鉴权

如果在安装时选择安装REMOTE PERFORMANCE MONITOR SERVER,LOADRUNNER会弹出一个要求输入用户名和密码的对话框,

REMOTE PERFORMANCE MONITOR SERVER是一个远程监视场景的服务器,为测试人员提供WEB化的场景页面,用于实现多台及其通过浏览器同时在线监视场景.这里设定用户名和口令的目的主要是为了REMOTE PERFORMANCE MONITOR(RPM)和运行了IIS的WEB SERVER之间进行鉴权.在RPM安装完毕之后,只有在LOADRUNNER CONTROLLER的RPM用户配置对话框中输入指定的用户名和口令,系统才能允许进行远程监控.

Ø         设定LOADRUNNER GENERATOR如何登陆到CONTROLLER

LOADRUNNER提供了两种方式让LOAD GENERATOR的虚拟用户登陆到CONTROLLER,

n         ALLOW VIRTUALUSERS TO RUN ON THIS MACHINE WITHOUT USER LOGIN

n         MANUAL LOG IN TO THE LOAD GENERATOR MACHINE

三、使用VITUAL USER GENERATOR录制开发脚本 LOADRUNNER脚本的开发过程一般需要以下几个过程

Ø         使用LOADRUNNER的VIRTUAL USER GENERATOR录制基本的测试脚本；

Ø         根据系统需求编辑测试脚本，看能否通过，

Ø         在单机模式下运行脚本看能否通过，

 1．选择协议要想正确的选择LOADRUNNER的脚本协议，首先要从LOADRNNER的工作原理上深入理解协议的作用和意义。LOADRUNER启动后，在任务栏上会有一个LOADRNNER AGENT PROCESS的进程，这个进程的一项重要的工作就是监视各种协议的客户端和服务器端的通信。只要是能够支持的协议，LOADRUNNER在录制的过程中就可以通过脚本语言将通信过程录制下来。所以只要明确了被测软件的通信过程和所使用的协议，LOADRUNNER才能正确的录制脚本。对于常见的应用软件，我们可以根据被测应用是B/S结构还是C/S结构来选择协议；

Ø         对于B/S结构，可以选择WEB（HTTP/HTTML）协议；

Ø         对于C/S结构，可以根据后端数据库的类型来选择，如SYBASECTLIB协议用于测试后台数据库为SYBASE的应用，MS SQL SERVER协议用于测试后台数据库为SQL SERVER的应用；

Ø         对于没有数据库的WINDOWS应用，可以选择WINDOWS SOCKETS这个底层的协议；

这里需要说明的是，无论使用哪种协议，LOADRUNNER的测试流程都基本是一样的，只有在设定细节上有所不同，测试人员只要对被测应用的技术架构熟悉了，就能够成功完成脚本的录制。

 2．录制测试脚本根据需求设定好脚本录制参数后，在VIRTUAL USER GENERATOR主窗口单击START RECORD按钮，系统就开始自动录制脚本。

Ø         理解脚本的三个部分；

LOADRUNNER 将测试脚本分为3个部分，VUSER_INIT,VUSER_END和ACTION,其中VUSER_INIT和VUSER_END一般用于存放应用程序初始化的脚本和注销关闭的脚本,在重复执行的时候,这两部分的内容只执行一次.而ACTION部分用于存放实际的操作脚本,这部分脚本可以多次执行,测试人员还可以根据需要创建多个ACTION 脚本,但不能创建VUSER_INIT和VUSER_END.

Ø         熟悉录制脚本工具栏；

在录制的过程中屏幕上有一个悬浮的工具栏,这是控制脚本录制的工具栏,是脚本录制过程中测试人员和VUGEN交互的主要平台,每个可用的按钮都可以执行相应的操作;

Ø         查看脚本；

n         SCRIPT. VIEW:查看全部的脚本;

n         TREE VIEW:查看从每个URL获取来的页面;

3.开发测试脚本 Ø         插入事务

有时侯测试人员根据项目需要,除了要衡量整个测试脚本的性能外,还想获取到脚本中的某一段和几段操作的性能数据；以便更详细的知道具体的是用户的哪些动作对性能的影响比较大.LOADRUNNER采用在脚本中定义事务来达到这一要求.

所谓事务(TRANSACTION),就是在脚本定义中定义的某段操作(ACTION),更确切的说,就是一段脚本语句.定义事务时,首先在脚本中找到事务的开始和结束位置,然后分别插入一个事务起始标记,这样,当脚本运行的时候,LOADRUNER会自动在事务的起始点计时,脚本在运行到事务结束点时计时结束,系统会自动记录这段操作的运行时间等性能数据；在脚本运行完毕后,系统会在结果信息中单独反映每个事务运行结果.

事务的插入操作可以在脚本运行过程中进行,也可以在脚本录制完毕后进行,建议在脚本录制完毕后进行.

n         定位事务语句的集合

n         插入事务起始点语句

将光标放置在欲定义事务的语句集合中第一条语句的上面一行,单击工具栏上的INSERT START TRANSACTION按钮,输入事务名称后,单击OK按钮,系统自动在脚本语句中插入如下语句:

LR_START_TRANSACTION(“事务名称”)

n         插入事务结束点语句

将光标放置在欲定义事务的语句集合中最后一条语句的后面一行,单击工具栏上的INSERT END TRANSACTION按钮,输入事务名称后,单击OK按钮,系统自动在脚本语句中插入如下语句:

LR_END_TRANSACTION(“事务名称“)

Ø         插入集合点

多用户同时加载并发,并发过程仅仅体现在开始执行的那一刹那,随着服务器对请求的响应时间的不一致或系统环境条件的限制,在运行过程中能集合到一点的可能性微乎其微,所以将一定数量的用户同时加载并不是真正意义上的并发.

系统压力最大的情况是:所有用户都集中到系统瓶颈的某个点上进行操作,从脚本的角度来讲,这个点就是执行脚本的某一条或一段语句,为了真实模拟这个最坏的情况,查看系统在最坏情况下的反映,LOADRUNNER提供了集合点的功能,帮助测试人员实现真正意义上的并发.

使用LOADRUUNER实现集合点功能的方法如下:

n         在脚本准备访问的语句上面插入一个空白行,并将光标移到该空白行上;

n         选择INSERT|RENDEZVOUS命令,系统弹出RENDEZVOUS对话框,

n         输入集合点名称后点击OK按钮.

系统会自动在脚本中插入下面语句

LR_RENDEZVOUS(“集合点名称”)

这样的脚本在运行的时候,就可以在集合点处实现真正的并发了.运行带有集合点的脚本时可以在SCENARIO GROUP列表的RENDEZ一栏看到虚拟用户的聚集过程.

需要说明的是,这部分内容仅介绍了如何在LOADRUNNER的脚本中插入集合点,LOADRUNNER允许测试人员对集合点的执行过程进行更详细的设定,如聚集的用户数,系统等待时间和等待策略等.

Ø         脚本参数化

让所有用户都使用相同的数据来运行,对系统造成的压力与实际情况会有所不同.而对于那些禁止一个用户多次登陆的系统,也就严重到无法测试的地步了.为了解决这个问题,让系统更加真实的模拟多用户使用的实际环境,LOADRUNNER提供了对脚本进行参数化输入的功能;

所谓的脚本参数化,就是针对脚本中的某些常量,定义一个或多个包含数据源的参数来取代,让场景中不同的虚拟用户在执行相同的脚本时,分别使用参数数据源中的不同数据代替这些常量,从而达到模拟多用户真实使用系统的目的.

n         确定需要参数化的常量

打开脚本后,首先要确定哪些常量需要参数化;

n         准备数据

既然是使用多组数据来替换常量,就需要在使用参数替换常量之前,针对性的准备一些模拟真实情况的数据.LOADRUNNER允许多种类型的数据源,如DAT的文本文件,电子表格,来自ODBC的数据库数据和其他系统提供的数据源等,每种类型的数据源都要求了不同的格式,这些在LOADRUNER的帮助文件中都有详细的说明;

n         对脚本进行参数化

在脚本中用鼠标选中要参数化的常量,然后单击鼠标右键,在弹出的快捷菜单中选择REPLACE WITH A PARAMETER命令,系统弹出SELECT OR CREATE PARAMETER对话框.通过这个对话框可以选择一个已经存在的参数,还可以根据需要创建一个新的参数.

单击PROPERTIES按钮,可以在PARAMETER PROPERTIES 对话框中设定脚本执行时参数的详细替换方式,不同的数据源类型的属性设定对话框的内容也会有所不同.

n         注:参数化输入只能用于函数中的参数,不能用参数代替非函数中的常量参数;

Ø         插入检查点

LOADRUNNER检查点的功能主要用来验证某个界面上是否存在指定的TEXT或IMAGE等对象，在使用LOADRUNNER测试WEB应用时，可以检查压力较大时WEB服务器能否返回正常的页面。

n         定位要检查的页面

定位需要检查的页面，最好将脚本视图切换到TREE VIEW方式，这样就可以直观地查看到LOADRUNNER录制时获取的每个页面了。在TREE VIEW视图中用鼠标单击页面左侧列表中页面对应的URL，就能迅速查看到准备检查的页面和页面上需要检查的图象或文本信息。

n         插入文字检查点

选择相应的URL，单击鼠标右键，在系统弹出的菜单中选择INSERT AFTER或INSERT BEFORE命令，在URL的脚本前面或后面插入函数，在ADD STEP对话框中可以插入很多的函数，如果想为WEB应用插入图像或文本检查点，需要选择WEB CHECKS下面的IMAGE CHECK或TEXT CHECK，

在系统弹出的检查点属性对话框中，输入要查询的文字或图像名称后，系统会自动在TREE VIEW视图中的树型列表中插入类似的STEP。

LOADRUNNER 还允许对要检查的文字内容和图像名称进行参数化，参数化的过程可以在插入检查点的 过程中实现，还可以在插入之后重新打开脚本实现。要想在插入检查点时就直接实现参数化，只需要在设置被检查对象的名称时单击ABC按钮，创建或选择参数输入就可以了。

n         设定与检查点有关的选项

         系统在执行时是否起用检查点，是由一个系统参数控制的，该参数的设定方法为：VUSER|RUN-TIME SETTINGS|PREFERENCES，如果想让检查点起作用，需要选中ENABLE IMAGE AND

        TEXT CHECK 复选框。

n         查看检查点是否通过

脚本运行结束后，要想查看检查点是否通过，可以在TREE VIEW视图下，用鼠标右键单击检查点步骤，选择GO TO STEP IN EXECUTION命令，则系统自动将光标定位到执行日志中获取检查点结果的一行上。

Ø         RUN-TIME SETTINGS

选择VUSER|RUN-TIME SETTINGS 命令,可以设定VIRTUAL USER GENERATOR中和脚本相关的一些运行时参数；

n         ITERATION COUNT(重复次数)

入口:GENERAL|RUN LOGIC;

参数说明:设定每个ACTION的重复执行次数;

需要注意的是,DURATION参数是优先于ITERATION的,举例说明,假定将DURATION设为5分钟,即使在RUN-TIME中将INRATIONS参数设为1,虚拟用户也会在5分钟之内进行尽可能多的反复执行脚本,在限定了DURATION的场景中,DURATION时间是从所有用户状态变为INIT开始计算的,这样就存在一个问题,有些初始化过程很长的用户,可能还没有到达RUN状态就因DURATION时间限制而中止了,要解决这个问题,测试人员可选择INITIALIZE ALL VUSERS BEFORE RUN选项,这样DURATION时间会在所有用户都到达RUN状态后开始计时.

n         THINK TIME

THINK TIME参数设定入口:GENERAL|THINK TIME

参数说明:设定脚本回放时对思考时间的处理方式.

IGNORE THINK TIME:

选择该选项,脚本回放时将不在执行LR_THINK_TIME()函数,这样会给服务器造成更大的压力.

REPLAY THINK TIME:

选择该选项,脚本回放时执行LR_THINK_TIME()函数,

1,按录制时获取的THINK TIME值回放脚本;

2,按照录制时获取值的整数倍回放脚本;

3,限定一个最大和最小的比例,按照两者之间的随机值回放脚本;

LIMIT THINK TIME TO:

用于限定THINK TIME 的最大值,脚本回放过程中,如果发现有超过这个值的,用这个最大值替代;

n         ERROR HANDLING

入口:GENERAL|MISCELLANEOUS

参数说明:设定遇到错误时的处理方式

1,CONTINUE ON ERROR,遇到错误继续运行;

2,FAIL OPEN TRANSACTIONS ON LR_ERROR_MESSAGE,

执行到事务中调用的LR_ERROR_MESSAGE()函数时将事务的结果置为FAILED

3,GENERATE SNAJPSHOT ON ERROR对错误进行快照.

n         MULTITHREADING

设定脚本运行方式;

入口:GENERATOR|MISCELLANEOUS

1,RUN VUSER AS A PROCESS,以多进程方式运行;

2,RUN VUSER AS A THREAD,以多线程方式运行;

4．在 LoadRunner 脚本中做关联 (Correlation) Ø         自动关联---- Rules Correlation

可以自动找出需要关联的值，并且自动使用关联函数建立关联。

 

在录制过程中VuGen会根据订定的规则，实时自动找出要关联的值。

1.        启用auto-correlation

n         点选VuGen的【Tools】>【Recording Options】，开启【Recording Options】对话窗口，选取【Internet Protocol】>【Correlation】，勾选【Enable correlation during recording】，以启用自动关联。

n         假如录制的应用系统属于内建关联规则的系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，请勾选相对应的应用系统。

n         或者也可以针对录制的应用系统加入新的关联规则，此即为使用者自订的关联规则。

n         设定当VuGen侦测到符合关联规则的数据时，要如何处理：

u       【Issue a pop-up message and let me decide online】：跳出一个讯息对话窗口，询问您是否要建立关联。

u       【Perform. correlation in sceipt】：直接自动建立关联

2.        录制脚本
开始录制脚本，在录制过程中，当VuGen侦测到符合关联规则的数据时，会依照设定建立关联，您会在脚本中看到类似以下的脚本，此为BroadVision应用系统建立关联的例子，在脚本批注部分可以看到关联前的数据为何。

3.        执行脚本验证关联是OK的。

Ø         自动关联----Correlation Studio

当录制的应用系统不属于VuGen预设支持的应用系统时，Rule Correlation可能既无法发挥作用，这时可以利用Correlation Studio来做关联。

Correlation Studio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。

使用Correlation Studio的步骤如下：

1.         录制脚本并执行；

2.        执行完毕后，VuGen会跳出下面的【Scan Action for Correlation】窗口，询问您是否要扫描脚本并建立关联，按下【Yes】按钮。

3.        扫描完后，可以在脚本下方的【Correlation Results】中看到扫描的结果。

4.        检查一下扫瞄的结果后，选择要做关联的数据，然后按下【Correlate】按钮，一笔一笔做，或是按下【Correlate All】让VuGen一次就对所有的数据建立关联。
注意：由于Correlation Studio会找出所有有变动的数据，但是并不是所有的数据都需要做关联，所以不建议您直接用【Correlate All】。

5.        一般来说，您必须一直重复步骤1~4直到所有需要做关联的数据都找出来为止。因为有时前面的关联还没做好之前，将无法执行到后面需要做关联的部份。

Ø         手动关联

有可能有些需要做关联的动态数据，连Correlation Studio都无法侦测出来，这时您就需要自行做手动关联了。

5.试运行脚本脚本录制完毕后,按F5键或单击菜单上的RUN按钮,可以运行脚本,在VIRTUAL USER GENERATOR中运行脚本的作用,主要是查看录制的脚本能否正常通过,如果有问题,系统会给出提示信息,并定位到出错的行上,便于用户查找到错误,修改完善测试脚本,运行结束后；系统会给出相应的运行结果.

6.保存脚本 LOADRUNNER的测试脚本在资源管理器中是以目录的形式存储的,目录名称就是LOADRUNNER识别的脚本名称.

四、MERCURY LOADRUNNER CONTROLLER创建场景进行压力负载测试时,测试人员的工作就是了解被测应用的性能需求,从应用程序中找出一个或多个性能测试点,然后针对这些性能点分别进行测试,获取相关的性能指标结果,分析被测应用,追溯性能问题产生的根源.要使用LOADRUNENR实现这一过程,就需要针对这些性能点建立一个个的场景,因此,LOADRUNNER的每个场景都定义了一个在性能测试活动中发生的事件,它能控制虚拟用户的数量,测试脚本和运行脚本的LOAD GENERATOR.对于有经验的测试人员来说，定义场景是在计划阶段进行的，它优先于脚本的录制过程，并指导脚本的录制。只不过计划阶段的场景只能限于纸面上，要想让LOADRUNNER这个测试工具实现自动的负载测试，需要在CONTROLLER中建立实实在在的场景。

对于有经验的测试人员来说,定义场景是在计划阶段进行的.它优先于脚本的录制过程，并指导脚本的录制。只不过计划阶段的场景只限于纸面上，要想让LOADRUNNER这个测试工具实现自动的负载测试，需要在CONTROLLER中建立实实在在的场景。

1．选择场景类型每次在CONTROLLER中创建一个场景的时候，系统会首先让用户选择场景的类型。LOADRUNNER为用户提供了面向目标和手工设置的两种场景策略，具体选择哪一种要根据具体的项目需求来定。

Ø         MANUAL SCENARIO这种方式是完全手动设置，测试人员需要手工设定虚拟用户数，SCHEDULE和LOADGENERATOR等

Ø         MANUAL SCENARI WITH PERCENTAGE MODE 这种方式与MAMUAL SCENARIO方式比较相似，只是在分配用户数的方式有所不同

1，后者需要设定TOTAL NUMBER OF VUSERS，即所有虚拟用户数；

2，后者需要为每个脚本分配用户数比例，由系统按照比例自动分配用户数；

3，后者脚本选择LOADGENERATOR时，除了可以选择单个的LOAD GENERATOR外，还可以设置为ALL LOAD GENERATOR，即使用所有的LOADGENERATOR。

由于这种方式没有用户组的概念，因此在设置SCHEDULE时，不能按组设置，只能按整个场景设置，

Ø          GOAL-ORIENTED SCENARIO

这种方式是基于目标自动创建场景的方式，测试人员只要输入性能测试所要达到的目标，LOADRUNNER就会自动根据目标安排场景的运行；

采用GOAL-ORIENTED SCENARIO方式创建场景时，需要单击EDIT SCENARIO GOAL按钮定义场景目标，CONTROLLER在执行的时候会根据场景目标的要求，自动加载用户，控制场景的运行；

n         VIRTUAL USERS  

以虚拟用户数作为目标，当一个应用对用户数要求比较高时，可以使用这种方式来测试一个应用程序能够允许多少个用户同时运行。基于用户数目标的原理和设定方法比较简单，他和MANUAL SCENARIO WITH PERCENTAGE MODE 方式基本相似，只需要定义要求达到的用户数就可以了。从某种意义上讲，它还不能体现面向目标类型的优势。

n         HITS PER SECOND，以每秒点击数作为目标，

n         TRANSACTIONS PER SECOND，以每秒事务数作为目标，

n         PAGES PER MINUTE，以每分钟页数作为目标，

以上三种类型都需要用户指定虚拟用户数的范围，CONTROLLER在运行场景的时候，首先加载最小的用户数，如果使用最小的用户数不能达到目标，系统会自动逐渐增加用户直到能够达到设定的目标为止。当加载的用户数达到最大值仍然不能满足要求时，就需要重新设置场景，增加最大用户数。可以通过LOAD BEHAVIOR选项设定三种不同的用户加载策略，如果没有达到目标，LOADRUNNER会重新运行场景，一次加载最大的用户数，尝试是否能够达到目标，如果出现如下情况之一，场景的运行结果都会置于FAILED状态，

CONTROLLER两次加载了最大的用户数都没有达到目标；

在运行过程中所有的用户都失败了；

LOAD GENERATOR数目不能满足要求；

CONTROLLER在增加用户的过程中，性能指标没有增加；

CONTROLLER在加载第一批用户后，没有捕获到指标的值；

n         TRANSATIONS RESPONSE TIME，以事务响应作为目标，

主要用于衡量要达到预期的事务响应时间，系统所容纳的最多用户数，如果系统已经加载了最大的用户数，响应时间仍然低于设定的值，说明系统还有能力容纳更多的用户，如果使用一部分用户就达到了设定的响应时间，说明系统是无法容纳设定的最大数量的用户的，必须通过完善应用程序来达到目的；

2．多机联合产生负载       LOADRUNNER对应用程序施压时，采用的方法就是让一台机器模拟很多用户，同时向被测用户发送请求或进行操作。这样，如果一台测试机器模拟的虚拟用户数过多，他本身性能的下降会直接影响测试效果。为了避免这种情况，LOADRUNNER允许使用多台机器运行场景来均衡测试机器的负荷。只要一台机器安装了LOAD GENERATOR并启动了LOADRUNNER AGENT PROCESS进程，就可以被CONTROLLER统一调度来运行场景，CONTROLLER负载收集统一的测试信息和执行结果。

Ø          安装LOAD GENERATOR，如果一台测试机仅用来被CONTROLLER调用执行场景，只需安装LOAD GENERATOR就可以了。方法是在LOADRUNNER安装首页选择LOAD GENERATOR选项。需要注意的是，LOAD GENERATOR的服务启动后，屏幕右下角的任务栏上会显示一个代理（AGENT）的图标；

Ø         在CONTROLLER中创建LOAD GENERATOR

CONTROLLER进行多机联合产生负载之前，首先要加载准备使用的LOAD GENERATOR，单击场景设定对话框中的GENERATORS按钮，系统会弹出LOAD GENERATORS对话框；在LOAD GENERATOR

对话框中可以查看到所有已经加载的LOAD GENERATOR信息。

n         NAME：LOAD GENERATOR所在的机器名称。如果是LOCALHOST，表明这个GENERATOR是在本机上；

n         STATUS：标识了GENERATOR目前的状态，

n         PLATFORM：显示了系统的平台名称；

n         单击ADD可以添加新的LOAD GENERATOR；添加LOAD GENERATOR后，一般要测试CONTROLLER能否正确连接到这个GENERATOR，单击CONNECT按钮，LOADRUNNER的CONTROLLER就会尝试去连接选中的LOAD GENERATOR，如果连接成功就在STATUS字段中显示READY，如果失败就会显示FAILED。

Ø         在场景中用不同的LOAD GENERATOR联合产生负载

创建好LOADGENERATOR以后，在CONTROLLER的LOAD GROUPS列表中就可以选择使用了，

使用多个LOAD GENERATOR运行场景的时候，可以让不同的虚拟用户组在不同的机器上运行，分解了CONTROLER本身的压力，更能体现系统真实的运行环境；

3．设定集合点策略     LOADRUNNER在运行场景的时候，允许测试人员根据项目需要自己设定集合点的并发策略，要设定一个集合点以何种方法运行，在创建或打开脚本中包含集合点的场景时，选择SCENARIOI|RENDEZVOUS命令，可以查看场景中所有脚本中的集合点名称，所属脚本，当前状态和相关的虚拟用户列表信息等，根据系统需求，还可以针对集合点的执行进行设定。

Ø          单击DISABLE/ENABLE RENDEZVOUS按钮可以选定集合点是否启用；

Ø          单击DISABLE/ENABLE VUSERS按钮可以设定一个用户是否参与到集合点中；

Ø          单击POLICY按钮可以设定集合点执行策略。

n         在POLICY对话框中的TIMEOUT BETWEEN VUSERS文本框中设定了一个超时时间，当第一个用户到达集合点时，系统开始计时。如果在这个设定的时间内没有达到要求的集合点用户数，系统就不在等待，释放用户让场景继续执行；

4．启用IP欺骗     LOADRUNNER进行压力负载测试的时候，是让一台机器模拟成百上千的用户对服务器施压，这样就产生了一个问题，那就是所有用户向服务器发起请求的时候，使用的都是同一个IP地址，即LOAD GENERATOR所在机器的固定IP地址，这是和实际运行环境不符的，而且有些应用系统在设计的时候会根据IP来分配资源，有些还限制同一个IP的多次登陆过程。LOADRUNNER为了解决这个问题，使用了一种称为“IP欺骗（IP SPOOFER）”的技术。也就是让一个LOAD GENERATOR上的虚拟用户模拟从不同的IP来向服务器发起请求，以达到以假乱真的目的。

Ø          配置IP SPOOFER

 LOADRNNER配置动态IP的工具是程序组中的一个小工具-IP WIZARD，它能够指导用户按步骤完成配置过程，这里有三个单选按钮；

第一个单选按钮CREATE NEW SETTING，用于创建一个新的设置，首次运行时选用；

第二个单选按钮LOAD PREVIOUS SETTING FROM可以调用以前保存的设置；

第三个单选按钮RESTORE ORIGINALSET不是用来创建动态IP，而是将设置恢复为原始状态，这个选项主要用于使用后释放IP，如果使用完毕后不释放IP的话，那么这些IP会被一直占用，别人就无法使用了。

Ø         输入WEB SERVER的IP地址，这里主要用来检测新的IP地址加到主机中后，SERVER的路由表是否需要更新，如果SERVER和CLIENT使用的是相同的子网掩码，IP CLASS类型和网络，是无需更新的；

Ø         在添加新的动态IP的时候，需要注意如下几个选项的含义：

n         PRIVATE ADDRESS SPACES：选择测试环境的IP地址类型，关于IP地址类型的定义

n         FROM IP：要使用IP段的第一个值；

n         NUMBER TO：要使用的IP地址的数目。

n         SUBMASK：子网掩码，一般采用默认设置就可以了；

如果选中VERIFY THAT NEW IP ADDRESS ARE NOT ALREADY IN USE复选框，系统会在所选范围内检测每个IP地址，为了避免冲突，LOADRUNNER只添加那些没有被其他用户使用的IP地址。

如果已经预先知道选择范围内的某些地址可能被占用，那么在NUMBER TO文本框中输入的IP地址的个数就要有相应的增加。

Ø         起用IP欺骗

在CONTROLLER窗口中，选择SCENARIO|ENABLE IP SPOOFER命令，就可以起用IP欺骗了，在IP欺骗启用后，在CONTROLLER状态栏中会显示相应的状态标识；

Ø         在OPTIONS中设置IP地址的分配方式；

创建虚拟IP地址之后，还要选择TOOLS|OPTIONS命令，在弹出的对话框中单击GENERAL标签以设定IP地址的分配方式；

n         IP ADDRESS ALLOCATION PER PROCESS：给每个进程分配不同的IP地址；

n         IP ADDRESS ALLOCATION PER THREAD： 给每个线程分配不同的IP地址；

一般来说，如果在RUN-TIME SETTING中设置的是以多线程的方式运行，则这里就给每个线程分配不同的IP地址。如果在RUN-TIME SETTING中设置的是以多进程的方式运行，则这里给每个进程分配不同的IP地址；

注意：只有在CONTROLLER中选择TOOL|EXPERT MODE 命令，才能在OPTIONS对话框中包含设定IP分配的选项；

5．使用测试管理工具进行统一管理     LOADRUNNER和MERCURY QUALIY CENTER的完美结合，给用户组织和管理LOADRUNNER的测试脚本，场景和测试数据带来了极大的便利。QUALITY CENTER是MERCURY 提出的针对质量保证的解决方案。只要将LOADRUNNER连接到基于WEB的QUALITY CENTER，则场景的存储执行和测试结果的收集就会随时随地被MERCURY QUALITY CENTER的测试项目进行有效的管理；

Ø          连接到QUALITY CENTER

要想让LOADRUNNER使用一个QUALITY CENTER 对测试内容进行管理，首先必须通过URL连接到QUALITY CENTER，这个QUALITY CENTER 既可以是安装在本地的局域网上，也可以是通过广域网访问的测试管理平台；

在CONTROLLER模块中，选择TOOLS|QUALITY CENTER CONNECTION 命令，弹出QUALITY CENTER

CONNECTION 对话框，在SERVER文本框中输入安装了QUALITY CENTER的WEB服务器的URL地址，单击CONNECT按钮，系统会试图建立对QUALITY CENTER服务器的连接，如果连接建立成功，则会在PROJECT CONNECTION 一栏显示QUALITY CENTER的项目；

在PROJECT CONNECTION 一栏输入相关的内容，即选定要连接的测试管理项目，单击CONNECT按钮，系统开始对相应的项目建立连接。一旦建立成功，则QUALITY CENTER的项目信息就变为只读状态；

Ø         断开服务器或项目

在连接状态中，可以随时单击DISCONNECT 按钮断开QUALITY CENTER服务器或项目的连接；

Ø         打开/保存测试项目场景

如果LOADRUNNER正在连接到一个测试管理工具上，那么在保存和打开场景的时候，系统弹出的对话框会有所不同，如果仍然希望在文件系统中打开/保存场景，可以单击对话框中的FILE SYSTEM按钮进行切换；关于测试管理工具如何管理和调用LOADRUNNER的场景，请参考TD。

6．控制场景的运行在CONTROLLER中单击START SCENARIO按钮开始执行场景以后，LOADRUNNER首先检查场景的配置信息，并激活被测应用，然后将虚拟用户分配到相应的LOAD GENERATOR上。当虚拟用户准备好以后就开始对被测应用施压，在施压的同时LOADRUNNER会完成如下的操作；

1)        记录在脚本中定义的每个事务的执行时间；

2)        执行脚本中定义的集合点的功能；

3)        收集每个虚拟用户发出的告警，错误和提示信息；

在场景执行过程中，学员可以查看虚拟用户发出的各种信息，可以随时停止一个用户或多个用户组的执行，可以让LOADRUNNER命令某些用户和用户组在场景执行结束前进行重复操作等。

Ø         初始化用户组

单击START SCENARIO 按钮执行场景时，虚拟用户并没有立刻执行脚本，而是首先执行一个初始化过程，初始化完毕的用户状态会变为READY，只有状态为READY 的用户才能真正开始执行脚本。由于各种条件的限制，场景中用户的初始化过程是无法达到完全同步的，这就造就了用户无法同时运行测试脚本。为了让用户能够同时对被测应用施压，LOADRUNNER提供了初始化用户组的策略，让所有用户在执行脚本之前全部变为READY 状态。

初始化用户组的方法是在开始运行场景之前，先在RUN选项卡中选中要初始化的用户组，然后单击工具栏的INITIALIZE THE SELECTED VUSERS按钮，或者单击鼠标右键，在弹出的菜单中选择INITIALIZE GROUPS命令，如果初始化成功，用户状态变为READY，如果失败，用户的状态就会变为ERROR。

Ø         停止场景的运行

     一个场景会在以下三种情况停止运行：

1)        所有用户都执行完脚本；

2)        测试人员手动停止了场景的运行；

3)        执行超时；

LOADRUNNER可以根据用户的设定，采用不同的停止方式；

1)        要手动停止整个场景的运行，只需在场景运行过程中单击RUN标签中的STOP按钮即可。

2)        如果希望选定的用户组停止执行，可以单击工具栏的STOP VUSERS按钮；

3)        如果OPIONS的RUN-TIME SETTING中设定了WAIT FOR CURRENT INTERATION TO END BEFORE STOPPING 或者WAIT FOR CURRENT ACTION TO END BEFORE STOPPING ，那么可以单击GRADUAL STOP按钮逐渐停止场景的运行；

Ø         对正在运行的场景增加用户数

在场景运行的时候，还可以在RUN/STOP VUSER对话框中增加用户，对话框的内容会根据所选择的模式的不同而有所不同。如果使用的是VUSER GROUP MODE，则在RUN/STOP VUSERS对话框的“#” 一栏中为每个用户组输入新的用户总数后，单击“RUN”按纽，系统会自动初始化新增加的用户数并开始运行；如果使用的是PERCENTAGE MODE，那么只要输入用户总数，系统会根据比例自动分配新的用户到不同的组中。

五、MERCURY LOADRUNNER CONTROLLER监视场景     影响事务响应时间的一个主要因素就是系统资源和应用服务器的使用情况。通过监视场景执行时的系统和服务器资源，基本能够确定系统的瓶颈在哪里。下面简单介绍通过添加性能计时器来监视各个服务器的运行情况，确定系统的瓶颈；

1． 在线监视场景    LOADRUNNER允许测试人员在场景的执行过程中在线查看产生的性能数据，除了监视本机的性能指标外，CONTROLLER还允许用户在线监视服务器的性能；

   使用CONTROLLER监视场景之前，需要定义和配置LOADRUNNER的监视组件，根据监视指标的不同，相应的配置过程和参数也完全不同，要想完成监视组件的配置过程，测试人员除了掌握LOADRUNNER的使用以外，更重要的是要对被监视的服务器中的应用相当熟悉。

  一般来说，在监视一个服务器之前，要经过如下两个步骤：

1)        在服务器端配置被监视服务器的监视环境；（有些指标不需对服务器进行特殊配置）

关于如何配置服务器端监视环境，由于不同类型的指标配置方法也不尽相同，需要测试人员熟悉被测应用的系统架构，并查阅相关的LOADRUNNER文档；

2)        在LOADRUNNER的CONTROLLER中配置要监视的MONITOR；

在LOADRUNNER CONTROLLER中，对监视指标进行了分类，具体的分类方式及每个类别包括的性能指标在RUN 视图的AVALIABLE GRAPHS列表中都有详细的说明。 

Ø         添加计数器

很多服务器（DATABASE SERVER，WEB SERVER等）和系统资源的性能指标数据，是通过手动在CONTROLLER中添加计数器来实现的；下面来介绍如何在CONTROLLER中添加性能计数器。注意的是，使用不同的操作系统，计数器会不完全相同；

在AVAILABLE列表中，单击要监视的图表，选择MONITOR|ADD MEASUREMENTS；或者在AVAILABLE GRAPH中先将准备监视的指标拖至右侧图表栏中，然后用鼠标右键单击该图表，在弹出的快捷菜单选择ADD MEASUREMENTS，系统会自动弹出相应的监视服务器对话框；单击上部的ADD按钮，在MONITORED SERVER MACHINES中添加要监视的服务器名称（或IP地址）和相应的系统平台；单击下部的ADD按钮在RESOURCE MEASUREMENTS ON列表中添加相应的计数器，这里可以选择一个或多个性能指标。如果添加成功的话，场景运行的时候，就可以在线监视所选择的指标数据了

注意：必须以被监视机器的管理员身份登陆到CONTROLLER所在机器，才能添加被监视机器的性能计数器；

Ø         常见的计数器

1)        MEMORY相关，内存问题主要检查应用程序是否存在内存泄露，如果发生了泄露，PROCESS\PRIVATE BYTES计数器和PROCESS\WORKING SET计数器的值往往会升高,同时AVALIABLE BYTES的值会降低.内存泄露应该通过一个长时间的测试来检查,主要测试当所有内存都耗尽时应用程序的反应情况;

2)        PROCESSOR相关,判断应用程序是否存在处理器的瓶颈

n         如果PROCESSOR QUEUE LENGTH显示的队列长度保持不变(>=2),且处理器的利用率%PROCESSOR TIME超过90%,那么很可能存在处理器瓶颈;

n         如果发现PROCESSOR QUEUE LENGTH显示的队列长度超过2,而处理器利用率却一直很低,那么或许更应该去解决处理器的阻塞问题,处理器一般不是瓶颈;

n         如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(CONTEXT SWITCHES/SEC,显示的上下文切换次数)比较大,那么就会造成大量的系统资源;

n         如果系统吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在1500以上,那么意味着上下文切换的次数过高;

n         还可以比较CONTEXT SWITCHES/SEC和%PRIVILEGED TIME来判断上下文切换是否过量;如果后者的值超过40%,且上下文切换的速率也很高,那么应该检查为什么会产生这么高的上下文切换;

3)        网络吞吐量及带宽

BYTES TOTAL/SEC: 判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较,相除结果应该小于50%;

4)        磁盘相关

     判断磁盘瓶颈的方法是通过以下的公式来计算:

     每磁盘的I/O数=[读次数+(4*写次数)]/磁盘个数

如果计算的每磁盘的I/O数大于磁盘的处理能力,那么磁盘存在瓶颈;

5)        WEB SERVER相关

 

 

6)        数据库服务器相关

 

2．定制图表显示方式 Ø          定制在线监视图表个数；

场景运行时,LOADRUNNER让用户默认在线监视4个图表,测试人员可以根据需要自己定制图表的个数:

鼠标右键单击一个图像,在弹出的快捷菜单中选择VIEW GRAPHS(或选择VIEW|VIEW GRAPHS命令),然后选择或设定显示图象的个数就可以了;

Ø          设定监视器选项；

     选择TOOLS|OPTION命令,在MONITORS选项卡中可以统一设定监视器的一些参数选项,

1)        TRANSACTION  DATA

用于监视事务图表的数据行为,这些参数不能在场景运行过程中更改,参数修改后需要重新连接虚拟用户的LOADGENERATOR才能生效;

n         ENABLE TRASACTION MONITOR:如果选择该选项,场景启动后就自动开始监视事务,默认情况下,该选项是选中的;

n         FREQUENCY:设定MONITOR抽样数据产生事务,获取数据点和生成网络资源在线图表的频率.默认为5秒,如果是小的场景建议使用1秒;如果大一些的场景,建议3-5秒;这个参数越低,采样间隔越小,监视图表越精确,网络工作量也就越大;

2)        SERVER RESOURCE MONITORS

定义了服务器资源监视器的行为,修改该选项对已经被激活的图表不起作用,只对随后被激活的图表起作用;

DATA SAMPLING RATE:定义了服务器两次采样数据的时间间隔,默认为3秒,这个参数对所有图表都起作用,如果要对单个图表起作用,需要在单个图表的配置属性中定义,

     每个图表都有一个最小的采样频率,如果这里设定的值低于图表的最小采样频率,图表仍然使用最小的采样频率;

3)        ERROR HANDLING

     定义了监视过程中的错误处理方式；

n         SEND ERROR TO THE OUTPUT WINDOW：遇到错误时将出错信息输出到OUTPUT窗口；

n         POP-UP AN ERROR MASSAGE BOX：遇到错误时弹出错误信息窗口；

4)        DEBUG

设定DEBUG场景的方式；

DISPLAY DEBUG MESSAGE：选中该复选框，系统会向输出日志中发送DEBUG相关信息，定义DEBUG的等级；

Ø          配置图表和计数器属性；

n         设定图表属性

如果想对一个图表单独配置显示属性，只需选择该图表，选择MONITOR|ONLINE GRAPHS|CONFIGURE命令，或者在右键单击图表后选择CONFIGURE命令，系统都会打开GRAPH CONFIGURE对话框。在该对话框中可以设定图表的数据刷新频率，X轴（时间轴）和Y轴的显示方式，显示比例等；

n         设定计数器属性

要设定图表中单个计数器的属性，可以用鼠标右键单击图表列表中的相应计数器，在弹出的菜单中选择CONFIGURE命令，可以设定计数器在图表中的显示颜色，显示比例和是否隐藏等；

Ø         合并图表；

     LOADRUNNER为了便于测试人员比较两个图表数据之间的关系，提供了图表合并的功能，也就是可以将同一个场景中的两个图表中的计数器合并到一个图表中，合并以后的图表共用一个X轴。

    要合并两个图象，只需右键单击一个图表，在弹出的快捷菜单中选择OVERLAY GRAPHS命令，然后在系统提示的对话框中选择另一个图表，并为新图表命名，需要注意的是只有X轴相同的图表才能合并；

3．其他与监视图表相关的功能 Ø         穿越防火墙监视图表；

为了安全起见，运行MONITOR和VUSER的机器安装了防火墙，这样处于防火墙之外的CONTROLLER在控制虚拟用户执行和监视场景的时候就会碰到一些麻烦；

LOADRUNER通过在防火墙上使用基于HTTPS或者使用标准SSL端口（443）的安全的TCP/IP的协议来解决这个问题。使用LOAD GENERATOR机器或MONITOR机器上的代理充当通信过程的媒介，与MI LISTENER通信。 MI

LISTENER是一个需要单独安装的LOADRUNNER组件，它服务于CONTROLLER和LOADRUNNER代理之间，

如果未安装MI LISTENER组件，LOADRUNNER也可以穿越防火墙实现监控MONITOR和执行VUSERS，这时需要在

LOAD GENERATOR 端和CONTROLLER端的防火墙上均打开54345端口；

Ø         远程监视场景；

LOADRUNNER提供了一个组件，用于同时通过多个机器上的WEB页面远程监视场景，每个监视还可以根据需要定制不同监视图表；

要完成远程监控，需要一个远程性能监视服务器，（REMOTE PERFORMANCE MONITOR SERVER），它是一个包括很多ASP页面和性能图表过滤器的网站，和CONTROLLER交互数据，并且决定能够在线查看场景的用户数。远程性能监视服务器上必须安装LOADRUNNER的REMOTE PERFORMANCE MONITOR SERVER组件，该组件有如下系统需求：

n          WEB SERVER: IIS5.0

n          操作系统:WINDOWS 2000SERVER或WINDOWS 2000ADVANCED SERVER

n          客户端浏览器:IE5.0或NETSCAPE6.2以上;

六、使用ANALYSIS分析测试结果      要查找系统瓶颈，就必需分析LOADRUNNER获取的性能指标数据，在LOADRUNNER场景运行的同时获取了大量的数据，可以根据以下几种方式分析这些数据：

1)        查看VUSER LOG文件,这些文件包括了场景运行过程中每个用户的跟踪数据,VUSER LOG文件一般放在脚本目录中;

2)        在CONTROLLER的OUTPUT窗口查看场景的执行过程信息;

3)        使用ANALYSIS模块分析执行结果图表;

4)        使用SPREADSHEET直接查看生成图表的原始数据---GRAPH  DATA或者RAW DATA;

5)        让LOADRUNNER自动生成HTML或WORD格式的测试报告,通过报告分析;

LOADRUNNER的ANALYSIS模块是分析系统的性能指标的一个主要工具,它能够直接打开场景的执行结果文件,将场景数据信息生成相关的图表进行显示.ANALYSIS集成了强大的数据统计分析功能,允许测试员对图表进行比较和合并等多种操作,分析后的图表能够自动生成需要的测试报告文档;ANALYSIS作为LOADRUNNER的一个主要模块,是帮助测试人员分析系统性能瓶颈的得力助手;

1、 使用ANALYSIS分析测试结果场景运行完毕，在结果目录下会自动保存一个扩展名为LRR的结果文件，ANALYSIS能够打开这个结果文件，加载时自动处理LRR文件内的结果信息，并自动生成相应的结果图表；

每次对结果信息进行处理的时候，ANALYSIS是在一个开启的会话内进行工作的。每个会话至少包括一套场景结果（即一个LRR文件）。在ANALYSIS中对结果信息进行另存的时候，除了重新保存数据自身信息外，还保存了结果数据在ANALYSIS中实现的显示方式和层次关系，以及哪些图表被激活等信息，这时保存的文件扩展名为LRA，

Ø         打开分析图表；

除了系统提示的默认的图表外，测试人员还可以查看其他包含数据的图表，方法是：在左侧的图表列表中双击NEW GRAPH，弹出OPEN A NEW GRAPH对话框，对话框中所有名称为篮色的图表均为包含数据的图表；

选中后单击OPEN A NEW GRAPH按钮即可以添加到主窗口中；

Ø         使用ANALYSIS分析结果图表；

     加载场景运行结果文件（.LRR）后,ANALYSIS就可以根据需要对相关的性能指标进行分析了.首次加载结果文件后可以看到,在ANALYSIS中包含了很多图表,也同时说明了LOADRUNNER在场景运行过程中获取了很多和性能相关的数据;针对每一个被测应用来说,到底哪个性能指标是影响性能的关键了.了解常用的性能指标,熟悉使用ANALYSIS分析工具分析测试结果是确定系统瓶颈的关键.再次强调,不同的应用程序,影响其性能的因素也不同,要分析被测软件的性能因素,首先要熟悉被测软件的技术架构;

     LOADRUNNER除了将获取的原始数据形成直观的图表外,还对数据进行了一些统计,,例如在多数分析图表下方的图例列表中,给出了最大值,最小值,平均值,中间值和STD等一些统计字段,便于用户分析;

     STD是一个统计学概念,称为标准偏差值,是用来衡量数据的偏离程度的.当平均值不多时,可以从STD指标看出统计图表列数据到底是分散还是集中的.STD越小表示图表的列数据越集中,拿AVERAGE RESPONSE TIME来说,也就表示每个虚拟用户单一的响应时间值大致是差不多的,即被测系统的反应很稳定,没有大起大落;

1)        TRANSACTION  PERFORMANCE SUMMARY

可以基本确认哪个事务的响应时间比较长,一般来说,响应时间长的事务是分析的重点;

2)        AVERAGE  TRANSACTION RESPONSE TIME

     可以详细查看每个事务在场景运行中的响应时间,

3)        WEB PAGE BREAKDOWN

用于分解页面,查看页面中哪些组件导致事务的响应时间比较长,

n         DNS RESOLUTION时间     DNS服务器解析IP地址的时间,这个度量时间可以确定DNS服务器或者DNS服务器的配置是否有问题,如果DNS运行正常,这个值一般比较小;

n         CONNECTION时间    浏览器和WEB SERVER建立初始化连接的时间,这个度量可以判断网络情况,也可以判断WEBSERVER是否响应这个请求;

n         SSL HANDSHAKING 时间     建立SSL连接的时间,使用SSL协议页面比较少,一般应用在HTTPS通信;

n         FTP AUTHENTICATION时间     FTP服务器在处理客户端的命令之前,首先要对客户端进行鉴权,这个度量就是FTP服务器对客户端进行鉴权的时间;

n         FIRST BUFFER时间    指连接建立成功后,从WEB SERVER发出的第一个数据包经过网络传输到客户端,浏览器成功接受到第一个字节的时间.这个度量既包括WEB SERVER的延迟时间,也包括了网络的反应时间.

n         RECEIVE时间   从浏览器收到第一个字节起,直到成功收到最后一个字节,所经历的时间.这个度量和组件大小结合,可以判断网络的质量;

n         CLIENT时间   指请求在客户端的延迟时间,这个延迟可能是浏览器的THINK TIME等引起的

n         ERROR时间    指从发送HTTP请求到HTTP错误信息返回的时间;

4)        TIME TO FIRST BUFFER BREAKDOWN

可以将页面或组件的时间分解为服务器时间和网络时间,帮助测试人员判断问题缘由到底是服务器还是网络存在瓶颈;

5)        THROUTPUT

     可分析整个压力测试过程中WEB SERVER的吞吐量,即虚拟用户在测试过程中各时刻从服务器上接收到的数据量.

6)        DOWNLOAD COMPONENT SIZE

页面元素的大小分解和比较

7)        WINDOWS  RESOURCE

系统资源图表,可以监视服务器端的系统资源使用情况,从而判断服务器的CPU,内存等是否是导致性能降低的原因;

Ø         关于分析图表的几个选项

n         自动整理合并结果

在使用ANALYSIS分析场景结果之前，首先要明确结果文件中收集了哪些信息，默认情况下，各个虚拟用户的执行结果数据都是存放在各个虚拟用户所在的机器上的，场景执行结束后，才被系统自动整理合并后放置到结果目录下，LOADRUNNER是否执行这个整理合并操作是受CONTROLLER中的AUTO COLLATE RESULTS选项控制的。该选项设定方法是在RESULTS下选择AUTO COLLATE RESULTS复选框；

n         设定收集结果信息方式 

对于结果文件大于100MB的大型场景，ANALYSIS加载结果数据时会耗费很长时间，测试人员在等待全部数据加载的同时可以首先查看结果的概要数据，这样，在测试人员浏览概要信息的时候系统会陆续加载其他详细信息数据；

测试人员可以根据需要设定是否产生概要数据，以及以何种方式显示结果信息，设定入口：菜单 TOOLS|OPTION|RESULT COLLECTION ，

在DATA SOURCE一栏有三个选项供测试人员选择；

只生成概要数据；只生成全部详细数据；在生成全部详细数据的同时显示概要数据；

n         设定数据聚集粒度

n         使用系统自动聚合的公式自动聚合数据 ;

n         使用系统自动聚合公式只对WEB数据进行聚合;

n         单击AGGREGATION CONFIGURATION自己定义聚合方式 ;

2、使用ANALYSIS技巧 Ø         查看图表技巧

1)        将鼠标放置到图表上需要放大部分的起始位置，然后按住鼠标左键拖动，松开鼠标后鼠标圈住的矩形部分的图表放大显示，便于用户查看图表细节；

2)        在图例列表中选择一个MEASUREMENT，单击鼠标右键，在系统弹出的菜单中选择CONFIGURE MEASUREMENT命令，之后就可以设定显示颜色和比例，通过设定比例，可以让不同数量级的数据都在图表的主要区域显示，使每个图表的趋势都很明显；

3)        在图例列表中单击鼠标右键，选择CONFIGURE COLUMN，可以设定在图例列表包含哪些列，以及表格中的图例如何排序等；

4)        在图表中单击鼠标右键，选择SET FILTER/GROUP BY，可以筛选图表中要显示数据和数据的分组方式；

Ø         分析图表技巧

1)        向下钻取图表

选中一个图表中的某条折线,单击鼠标右键后选择DRILL DOWN,可以对选定的MEASUERMENT J进行向下钻取,钻取的方向可以根据需要进行选择,要取消钻取,需要使用SET FILTER/GROUP BY功能;

2)        查看原始数据

在图表下面的RAW DATA或GRAPH DATA中,可以查看图表的原始数据;

3)        自动关联图表

在一个图表上单击鼠标右键,在弹出的菜单中选择AUTO COLLATE命令,依据提示进行设定后,系统会自动搜寻和该图表趋势有一定规律的图表,合并到该图表上,该功能便于测试人员分析指标间的联系,

4)        合并图表

为了便于分析指标间的相互关系,在ANALYSIS中还可以手动将两个图表合并为一个图表.两个图表合并的条件是具有相同的X轴,合并图表的方法是:在ANALYSIS中用鼠标右键单击想要合并图表重中的一个,在弹出的菜单中选择MERGE GRAPH,根据系统提示选择被合并的图表和合并方式,系统会自动生成新的合并后图表.下面是ANALYSIS图表的3种合并方式

n         OVERLAY

两个图表合并和共用一个X轴，左边的Y轴上标识当前图表的刻度值，右边的Y轴标识被合并图表的刻度值。当有多个图表被合并时，仍显示一个Y轴刻度，这时可以通过设定图表的显示比例让所有图表都显示在主区域；

n         TILE

         两个图表合并后共用一个X轴，Y轴会被分为两个部分，这样合并的两个图表，看起来相对独立一些，其中一个显示在另一个的上部；

n         CORRELATE

         在合并图表后的图表中，其中一个图表的Y轴作为合并后的Y轴，而另一个图表的Y轴作为合并后图表的X轴，这样合并的图表更能看出两个图表变化趋势之间的关系；

Ø         使用QUALITY CENTER管理分析结果

要分析QUALITY CENTER 中的测试结果,首先要做的就是建立到QUALITY CENTER WEB服务器和相关项目的连接;

1)        连接到QUALITY CENTER

在ANALYSIS模块主菜单中选择TOOLS|QUALITY CENTER CONNECTION，弹出QUALITY CENTER CONNECTION对话框，在这里建立连接和取消连接的方法；

2)        使用QUALITY CENTER管理分析结果

     在连接的建立状态，测试人员可以选择是打开文件系统文件，还是打开保存在QUALITY  CENTER的项目中的场景执行结果文件，还可以在QUALITY CENTER中创建会话，保存结果分析文件等。

Ø         引入外部数据

监视场景的时候,可以通过添加计数器的方式监视服务器的系统资源,使用ANALYSIS打开场景的结果文件后,就可以对这些系统资源的数据图表进行分析.

     但有时受客观条件的限制，测试人员无法在LR场景中监视服务器系统资源，这时可以采用一个办法，就是让服务器自己监视自己的资源，并生成相应的CSV文件，当使用ANALYSIS分析结果的时候，把这些单独的CSV文件作为外部数据导入到ANALYSIS中；

     LOADRUNNER提供了ANALYSIS IMPORT DATA工具允许测试人员把一些非自身生成的数据信息引入和集成到ANALYSIS的SESSION中，引入之后，就可以使用ANALYSIS的工具对它们进行查看和分析了。

     工具入口：菜单TOOLS|EXTERNAL MONITORS|IMPORT DATA

     单击ADD FILE 按钮，输入保存的外部数据源文件后，需要在FILE FORMAT中正确选择数据源的格式，否则可能导致引入过程失败

V$SEGSTAT

本视图实时监控段级(segment-level)统计项，支持oracle9ir2及更高版本

V$SEGSTAT中的常用列

l         TS#：表空间标识

l         OBJ#：字典对象标识

l         DATAOBJ#：数据对象标识

l         STATISTIC_NAME：统计项名称

l         STATISTIC#：统计项标识

l         VALUE：统计项值

V$SEGSTAT中的连接列

Column                             View                                         Joined Column(s)

--------------                         -----------------------                           ------------------------

TS#                                   V$TABLESPACE                         TS#

OBJ#                                  ALL_OBJECTS                           OBJECT_ID

示例：

1.查询指定对象的统计

select * from v$segstat where ts# = 11

   and obj# = (select object_id fromuser_objects

                where object_name = 'TMPTABLE1'and wner = 'JSS')

V$SEGMENT_STATISTICS

　　这是一个友好的视图，支持Oracle9ir2及更高版本。实时监测段级(segment-level)统计项，可用于鉴定性能问题源于表或索引

V$SEGMENT_STATISTICS中的列

l         OWNER：对象所有者

l         OBJECT_NAME：对象名称

l         SUBOBJECT_NAME：子对象名称

l         TABLESPACE_NAME：对象所在表空间

l         TS#：表空间标识

l         OBJ#：字典对象标识

l         DATAOBJ#：数据对象标识

l         OBJECT_TYPE：对象类型

l         STATISTIC_NAME：统计项名称

l         STATISTIC#：统计项标识

l         VALUE：统计项值

基本与上相同，只是信息更加详细，不再赘述。

V$SESSION_LONGOPS

本视图显示运行超过6秒的操作的状态。包括备份，恢复，统计信息收集，查询等等。

要监控查询执行进展状况，你必须使用cost-based优化方式，并且：

l         设置TIMED_STATISTICS或SQL_TRACE参数值为true。

l         通过ANALYZE或DBMS_STATS数据包收集对象统计信息。

你可以通过DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS过程添加application-specific长运行操作信息到本视图。关于DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS的更多信息可以浏览：Oracle Supplied PL/SQL Packages and Types Reference。

V$SESSION_LONGOPS列说明

l         SID：Session标识

l         SERIAL#：Session串号

l         OPNAME：操作简要说明

l         TARGET：操作运行所在的对象

l         TARGET_DESC：目标对象说明

l         SOFAR：至今为止完成的工作量

l         TOTALWORK：总工作量

l         UNITS：工作量单位

l         START_TIME：操作开始时间

l         LAST_UPDATE_TIME：统计项最后更新时间

l         TIME_REMAINING：预计完成操作的剩余时间(秒)

l         ELAPSED_SECONDS：从操作开始总花费时间(秒)

l         CONTEXT：前后关系

l         MESSAGE：统计项的完整描述

l         USERNAME：执行操作的用户ID

l         SQL_ADDRESS：用于连接查询的列

l         SQL_HASH_VALUE：用于连接查询的列

l         QCSID：

示例：

找一较大表，确认该表查询将超过6秒，哎呀让它快咱没把握，让它慢这可是我的强项啊~~

SQL> set timing on

SQL> create table ttt as select level lv,rownum rn from dual connect by level<10000000;   --创建一个临时表

Table created

Executed in 19.5 seconds

SQL> commit;

Commit complete

Executed in 0 seconds

SQL> select * from (select * from ttt order by lv desc) where rownum<2;    --执行一个费时的查询

        LV         RN

---------- ----------

   9999999    9999999

Executed in 9.766 seconds   --哈哈，成功超过6秒

SQL> select sid,opname,sofar,totalwork,units,sql_hash_value from v$session_longops;      ----看看v$session_longops中是不是已经有记录了

       SID OPNAME                                                                SOFAR TOTALWORK UNITS                            SQL_HASH_VALUE

---------- ---------------------------------------------------------------- ---------- ---------- -------------------------------- --------------

        10 Table Scan                                                            47276      47276 Blocks                               2583310173

Executed in 0.047 seconds

SQL> select a.sql_text from v$sqlarea a,v$session_longops b where a.HASH_VALUE=b.SQL_HASH_VALUE;   --通过hash_value联系查询出刚执行的查询语句。

SQL_TEXT

--------------------------------------------------------------------------------

select * from (select * from ttt order by lv desc) where rownum<2

Executed in 0.063 seconds

Ps:itpub论坛的fenng版版数年前有篇文章描述了v$sessin_longops的来源，有兴趣的朋友可以研究研究：

http://www.dbanotes.net/database/vsession_longops.html

V$PROCESS

　　本视图包含当前系统oracle运行的所有进程信息。常被用于将oracle或服务进程的操作系统进程ID与数据库session之间建立联系。在某些情况下非常有用：

1.         如果数据库瓶颈是系统资源(如：cpu,内存)，并且占用资源最多的用户总是停留在某几个服务进程，那么进行如下诸项：

l         找出资源进程

l         找出它们的session,你必须将进程与会话联系起来。

l         找出为什么session占用了如此多的资源

2.         SQL跟踪文件名是基于服务进程的操作系统进程ID。要找出session的跟踪文件，你必须将session与服务进程联系起来。

3.         某些事件，如rdbms ipc reply，鉴别session进程的Oracle进程ID在等什么。要发现这些进程在做什么，你必须找出它们的session。

4.         你所看到的服务器上的后台进程(DBWR,LGWR,PMON等)都是服务进程。要想知道他们在做什么，你必须找到他们的session。

V$PROCESS中的常用列

l         ADDR：进程对象地址

l         PID：oracle进程ID

l         SPID：操作系统进程ID

V$PROCESS中的连接列

Column                       View                            Joined Column(s)

ADDR                          V$SESSION                 PADDR

示例：

1.         查找指定系统用户在oracle中的session信息及进程id，假设操作系统用户为：junsansi

select s.sid,s.SERIAL#, s.username,p.spid

from v$session s, v$process p

where s.osuser = 'junsansi'

   and s.PADDR = p.ADDR

2.         查看锁和等待

SELECT/*+ rule */

lpad(' ', decode(l.xidusn, 0, 3, 0)) || l.oracle_username User_name,

o.owner,o.object_name,o.object_type,s.sid,s.serial#,p.spid

FROM v$locked_object l, dba_objects o, v$session s, v$process p

WHERE l.object_id = o.object_id

   AND l.session_id = s.sid and s.paddr = p.addr

ORDERBY o.object_id, xidusn DESC

3.        

附注：

　　在linux环境可以通过ps查看进程信息包括pid,windows中任务管理器的PID与v$process中pid不能一一对应，这块在oracleDocument中也没有找到介绍，后来google了一下，有资料介绍说是由于windows是多线程服务器,每个进程包含一系列线程。这点于unix等不同，Unix每个Oralce进程独立存在，在Nt上所有线程由Oralce进程衍生。

　　要在windows中显示oracle相关进程pid，我们可以通过一个简单的sql语句来实现。

SELECT s.SID, p.pid, p.spid signaled, s.osuser, s.program

FROM v$process p, v$session s

WHERE p.addr = s.paddr;

还可以通过和 v$bgprocess 连接查询到后台进程的名字：

SELECT s.SID SID, p.spid threadid, p.program processname, bg.NAMENAME

FROM v$process p, v$session s, v$bgprocess bg

WHERE p.addr = s.paddr

   AND p.addr = bg.paddr

   AND bg.paddr <> '00';

V$FILESTAT

　　本视图记录各文件物理I/O信息。如果瓶颈与I/O相关，可用于分析发生的活动I/O事件。V$FILESTAT显示出数据库I/O的下列信息(不包括日志文件)：

l         物理读写数

l         块读写数

l         I/O读写总耗时

　　以上数值自实例启动即开始记录。如果获取了两个快照，那么二者之间的差异即是这一时间段内活动I/O统计。

V$FILESTAT中的常用列：

l         FILE#：文件序号；

l         PHYRDS：已完成的物理读次数；

l         PHYBLKRD：块读取数；

l         PHYWRTS：DBWR完成的物理写次数；

l         PHYBLKWRT：写入磁盘的块数；

V$FILESTAT注意项：

l         因为multiblock读调用，物理读数和数据块读数有可能不同；

l         因为进程直写，物理写和数据块写也可能不一致；

l         Sum(physical blocks read) 近似于v$sysstat中的physical reads；

l         Sum(physical blocks written) 近似于v$sysstat中的physical writes；

l         数据读(由缓存读比直读好)由服务进程处理。从buffer cache写只能由DBWR进行，直写由服务进程处理。

V$FILESTAT中的连接列

Column                             View                                          Joined Column(s)

-----------                                   -------------------------                  -------------------------

FILE#                                 DBA_DATA_FILES                     FILE_ID

FILE#                                 V$DATAFILE                            FILE#

示例：

1.获得数据文件物理读写和数据块读写信息：

select df.tablespace_name name,

       df.file_name       "file",

       f.phyrds           pyr,

       f.phyblkrd         pbr,

       f.phywrts          pyw,

       f.phyblkwrt        pbw

from v$filestat f, dba_data_files df where f.file# = df.file_id

orderby df.tablespace_name;

注意：尽管oracle记录的读写次数非常精确，但如果数据库运行在Unix文件系统(UFS)有可能不能表现真实的磁盘读写，例如，读次数可能并非真实的磁盘读，而是UFS缓存。不过裸设备的读写次数应该是比较精准的。

(1)-V$SESSION_WAIT

　　这是一个寻找性能瓶颈的关键视图。它提供了任何情况下session在数据库中当前正在等待什么(如果session当前什么也没在做，则显示它最后的等待事件)。当系统存在性能问题时，本视图可以做为一个起点指明探寻问题的方向。

　　V$SESSION_WAIT中，每一个连接到实例的session都对应一条记录。

V$SESSION_WAIT中的常用列

l         SID: session标识

l         EVENT: session当前等待的事件，或者最后一次等待事件。

l         WAIT_TIME: session等待事件的时间(单位，百分之一秒)如果本列为0，说明session当前session还未有任何等待。

l         SEQ#: session等待事件将触发其值自增长

l         P1, P2, P3: 等待事件中等待的详细资料

l         P1TEXT, P2TEXT, P3TEXT: 解释说明p1,p2,p3事件

附注：

1.State字段有四种含义﹕

(1)Waiting：SESSION正等待这个事件。

(2)Waited unknown time：由于设置了timed_statistics值为false，导致不能得到时间信息。表示发生了等待，但时间很短。

(3)Wait short time：表示发生了等待，但由于时间非常短不超过一个时间单位，所以没有记录。

(4)Waited knnow time：如果session等待然后得到了所需资源，那么将从waiting进入本状态。

2.Wait_time值也有四种含义：

(1)值>0：最后一次等待时间(单位：10ms)，当前未在等待状态。

(2)值=0：session正在等待当前的事件。

(3)值=-1：最后一次等待时间小于1个统计单位，当前未在等待状态。

(4)值=-2：时间统计状态未置为可用，当前未在等待状态。

3.Wait_time和Second_in_wait字段值与state相关:

(1)如果state值为Waiting，那么wait_time值无用。Second_in_wait值是实际的等待时间(单位：秒)。

(2)如果state值为Wait unknow time，那么wait_time值和Second_in_wait值都无用。

(3)如果state值为Wait short time，那么wait_time值和Second_in_wait值都无用。

(4)如果state值为Waiting known time，那么wait_time值就是实际等待时间(单位：秒)，Second_in_wait值无用。

V$SESSION_WAIT中的连接列

Column        View                     Joined Column(s)

SID              V$SESSION          SID

示例：

1.列出当前系统的等待事件

SELECT event,

       sum(decode(wait_time,0,1,0)) "Curr",

       sum(decode(wait_time,0,0,1)) "Prev",

      count(*)"Total"

FROM v$session_wait GROUPBY event ORDERBYcount(*);

EVENT                                             Prev       Curr       Tot

---------------------------------------------       ----        -----       -----

PL/SQL lock timer                             0            1            1

SQL*Net more data from client           0            1            1

smon timer                                        0            1            1

pmon timer                                        0            1            1

SQL*Net message to client                  2            0            2

db file scattered read                           2            0            2

rdbms ipc message                            0            7            7

Enqueue                                           0            12           12

pipe get                                             0            12           12

db file sequential read                          3            10           13

latch free                                          9            6            15

SQL*Net message from client             835        1380       2215

这个按事件和wait_time的分组查询列出下列的信息：

l         多数的session都是空闲事件如：SQL*Net message from client, pipe get, PMON timer等。

l         session的cpu占用可以通过上次session的非等待事件大致算出，除此问题外：看起来多数session没有在等待什么事情(难道他们都在干活？)但其最后等待事件都是SQL*Net message from client。

2.列出指定ID的等待事件

select * from v$session_wait where sid=100;

3.应用p1,p2,p3进行等待事件的分析

v$session_wait视图的列代表的缓冲区忙等待事件如下：

P1—与等待相关的数据文件的全部文件数量。

P2—P1中的数据文件的块数量。

P3—描述等待产生原因的代码。

例：select p1 "File #", p2 "Block #", p3 "Reason Code"

　　from v$session_wait

　　where event = 'buffer busy waits';

如果以上查询的结果显示一个块在忙等待，以下的查询将显示这一块的名称和类型：

select owner, segment_name, segment_type

　from dba_extents

　where file_id = &P1　and &P2 between block_id and block_id + blocks -1;

　　我们也可以查询dba_data_files以确定等待的文件的file_name，方法是使用v$session_wait中的P1。

　　从v$session_wait中查询P3(原因编码)的值可以知道session等待的原因。原因编码的范围从0到300，下列为部分编码所代表的事项：

0 块被读入缓冲区。

100 我们想要NEW(创建)一个块，但这一块当前被另一session读入。

110 我们想将当前块设为共享，但这一块被另一session读入，所以我们必须等待read()结束。

120 我们想获得当前的块，但其他人已经将这一块读入缓冲区，所以我们只能等待他人的读入结束。

130 块被另一session读入，而且没有找到其它协调的块，所以我们必须等待读的结束。缓冲区死锁后这种情况也有可能产生。所以必须读入块的CR。

200 我们想新创建一个block，但其他人在使用，所以我们只好等待他人使用结束。

210 Session想读入SCUR或XCUR中的块，如果块交换或者session处于非连续的TX模式，所以等待可能需要很长的时间。

220 在缓冲区查询一个块的当前版本，但有人以不合法的模式使用这一块，所以我们只能等待。

230 以CR/CRX方式获得一个块，但块中的更改开始并且没有结束。

231 CR/CRX扫描找到当前块，但块中的更改开始并且没有结束。

(2)-V$SESSION_EVENT

　　本视图记录了每个session的每一项等待事件。由上文所知V$SESSION_WAIT显示了session的当前等待事件，而V$SESSION_EVENT则记录了session自启动起所有的事件。

V$SESSION_EVENT中的常用列

l         SID：session标识

l         EVENT：session等待的事件

l         TOTAL_WAITS：此session当前事件的总等待数

l         TIME_WAITED：此session总等待时间(单位，百分之一秒)

l         AVERAGE_WAIT：此session当前事件平均等待时间(单位，百分之一秒)

l         TOTAL_TIMEOUTS：等待超时次数

其它用法与V$SESSION_WAIT相似，不详述了

附注：

Oracle的等待事件是衡量Oracle运行状况的重要依据及指标。等待事件的概念是在Oracle7.0.1.2中引入的，大致有100个等待事件。在Oracle 8.0中这个数目增加到了大约150个，在Oracle8i中大约有200个事件,在Oracle9i中大约有360个等待事件。主要有两种类别的等待事件，即空闲(idle)等待事件和非空闲(non-idle)等待事件。

关于空闲事件和非空闲事件目前通过google可以搜索到非常多详尽的相关信息，同时

Oracle Database Performance Tuning Guide and Reference中关于Wait Events也有非常详尽的描述，在此就不多费口舌了。不过我在itpub论坛看到有热心人整理的chm格式非空闲事件说明，有兴趣的朋友可以下载，链接如下：

非空闲事件说明

详见：http://www.itpub.net/728733.html

V$SESSION

　　在本视图中，每一个连接到数据库实例中的session都拥有一条记录。包括用户session及后台进程如DBWR，LGWR，arcchiver等等。

V$SESSION中的常用列

V$SESSION是基础信息视图，用于找寻用户SID或SADDR。不过，它也有一些列会动态的变化，可用于检查用户。如例：

SQL_HASH_VALUE，SQL_ADDRESS：这两列用于鉴别默认被session执行的SQL语句。如果为null或0，那就说明这个session没有执行任何SQL语句。PREV_HASH_VALUE和PREV_ADDRESS两列用来鉴别被session执行的上一条语句。

STATUS：这列用来判断session状态是：

l         Achtive：正执行SQL语句(waiting for/using a resource)

l         Inactive：等待操作(即等待需要执行的SQL语句)

l         Killed：被标注为删除

下列各列提供session的信息，可被用于当一个或多个combination未知时找到session。

Session信息

l         SID：SESSION标识，常用于连接其它列

l         SERIAL#：如果某个SID又被其它的session使用的话则此数值自增加(当一个       SESSION结束，另一个SESSION开始并使用了同一个SID)。

l         AUDSID：审查session ID唯一性，确认它通常也用于当寻找并行查询模式

l         USERNAME：当前session在oracle中的用户名。

Client信息

数据库session被一个运行在数据库服务器上或从中间服务器甚至桌面通过SQL*Net连接到数据库的客户端进程启动，下列各列提供这个客户端的信息

l         OSUSER：客户端操作系统用户名

l         MACHINE：客户端执行的机器

l         TERMINAL：客户端运行的终端

l         PROCESS：客户端进程的ID

l         PROGRAM：客户端执行的客户端程序

要显示用户所连接PC的 TERMINAL、OSUSER，需在该PC的ORACLE.INI或Windows中设置关键字TERMINAL，USERNAME。

Application信息

调用DBMS_APPLICATION_INFO包以设置一些信息区分用户。这将显示下列各列。

l         CLIENT_INFO：DBMS_APPLICATION_INFO中设置

l         ACTION：DBMS_APPLICATION_INFO中设置

l         MODULE：DBMS_APPLICATION_INFO中设置

下列V$SESSION列同样可能会被用到：

l         ROW_WAIT_OBJ#

l         ROW_WAIT_FILE#

l         ROW_WAIT_BLOCK#

l         ROW_WAIT_ROW#

V$SESSION中的连接列

Column                                                            View                                              Joined Column(s)

SID             V$SESSION_WAIT,,V$SESSTAT,,V$LOCK,V$SESSION_EVENT,V$OPEN_CURSOR                 SID

(SQL_HASH_VALUE, SQL_ADDRESS)                  V$SQLTEXT, V$SQLAREA, V$SQL    (HASH_VALUE, ADDRESS)

(PREV_HASH_VALUE, PREV_SQL_ADDRESS)     V$SQLTEXT, V$SQLAREA, V$SQL    (HASH_VALUE, ADDRESS)

TADDR                                                             V$TRANSACTION                                    ADDR

PADDR                                                              V$PROCESS                                             ADDR

示例：

1.查找你的session信息

SELECT SID, OSUSER, USERNAME, MACHINE, PROCESS

FROM V$SESSION WHERE audsid = userenv('SESSIONID');

2.当machine已知的情况下查找session

SELECT SID, OSUSER, USERNAME, MACHINE, TERMINAL

FROM V$SESSION

WHERE terminal = 'pts/tl'AND machine = 'rgmdbs1';

3.查找当前被某个指定session正在运行的sql语句。假设sessionID为100

select b.sql_text

from v$session a,v$sqlarea b

where a.sql_hash_value=b.hash_valueand a.sid=100

寻找被指定session执行的SQL语句是一个公共需求，如果session是瓶颈的主要原因，那根据其当前在执行的语句可以查看session在做些什么。

V$SQLTEXT

　　本视图包括Shared pool中SQL语句的完整文本，一条SQL语句可能分成多个块被保存于多个记录内。

　　注：V$SQLAREA只包括头1000个字符。

V$SQLTEXT中的常用列

l         HASH_VALUE：SQL语句的Hash值

l         ADDRESS：sql语句在SGA中的地址

l         SQL_TEXT：SQL文本。

l         PIECE：SQL语句块的序号

V$SQLTEXT中的连接列

Column                                          View                                    Joined Column(s)

HASH_VALUE, ADDRESS         V$SQL, V$SESSION            HASH_VALUE, ADDRESS

HASH_VALUE. ADDRESS         V$SESSION                          SQL_HASH_VALUE, SQL_ADDRESS

示例：已知hash_value:3111103299，查询sql语句：

select * from v$sqltext

where hash_value='3111103299'

orderby piece

V$SQLAREA

　　本视图持续跟踪所有shared pool中的共享cursor，在shared pool中的每一条SQL语句都对应一列。本视图在分析SQL语句资源使用方面非常重要。

V$SQLAREA中的信息列

l         HASH_VALUE：SQL语句的Hash值。

l         ADDRESS：SQL语句在SGA中的地址。

这两列被用于鉴别SQL语句，有时，两条不同的语句可能hash值相同。这时候，必须连同ADDRESS一同使用来确认SQL语句。

l         PARSING_USER_ID：为语句解析第一条CURSOR的用户

l         VERSION_COUNT：语句cursor的数量

l         KEPT_VERSIONS：

l         SHARABLE_MEMORY：cursor使用的共享内存总数

l         PERSISTENT_MEMORY：cursor使用的常驻内存总数

l         RUNTIME_MEMORY：cursor使用的运行时内存总数。

l         SQL_TEXT：SQL语句的文本（最大只能保存该语句的前1000个字符）。

l         MODULE,ACTION：使用了DBMS_APPLICATION_INFO时session解析第一条cursor时的信息

V$SQLAREA中的其它常用列

l         SORTS: 语句的排序数

l         CPU_TIME: 语句被解析和执行的CPU时间

l         ELAPSED_TIME: 语句被解析和执行的共用时间

l         PARSE_CALLS: 语句的解析调用(软、硬)次数

l         EXECUTIONS: 语句的执行次数

l         INVALIDATIONS: 语句的cursor失效次数

l         LOADS: 语句载入(载出)数量

l         ROWS_PROCESSED: 语句返回的列总数

V$SQLAREA中的连接列

Column                                          View                                                               Joined Column(s)

HASH_VALUE, ADDRESS         V$SESSION                                                     SQL_HASH_VALUE, SQL_ADDRESS

HASH_VALUE, ADDRESS         V$SQLTEXT, V$SQL, V$OPEN_CURSOR   HASH_VALUE, ADDRESS

SQL_TEXT                                   V$DB_OBJECT_CACHE                               NAME

示例：

1.查看消耗资源最多的SQL：

SELECT hash_value, executions, buffer_gets, disk_reads, parse_calls

FROM V$SQLAREA

WHERE buffer_gets > 10000000OR disk_reads > 1000000

ORDERBY buffer_gets + 100 * disk_reads DESC;

2.查看某条SQL语句的资源消耗：

SELECT hash_value, buffer_gets, disk_reads, executions, parse_calls

FROM V$SQLAREA

WHERE hash_Value = 228801498AND address = hextoraw('CBD8E4B0');

(1) v$sql

　　一条语句可以映射多个cursor,因为对象所指的cursor可以有不同用户(如例1)。如果有多个cursor(子游标)存在，在V$SQLAREA为所有cursor提供集合信息。

　　在个别cursor上，v$sql可被使用。该视图包含cursor级别资料。当试图定位session或用户以分析cursor时被使用。

　　PLAN_HASH_VALUE列存储的是数值表示的cursor执行计划。可被用来对比执行计划。PLAN_HASH_VALUE让你不必一行一行对比即可轻松鉴别两条执行计划是否相同。

V$SQL中的列说明：

l         SQL_TEXT：SQL文本的前1000个字符

l         SHARABLE_MEM：占用的共享内存大小(单位：byte)

l         PERSISTENT_MEM：生命期内的固定内存大小(单位：byte)

l         RUNTIME_MEM：执行期内的固定内存大小

l         SORTS：完成的排序数

l         LOADED_VERSIONS：显示上下文堆是否载入，1是0否

l         OPEN_VERSIONS：显示子游标是否被锁，1是0否

l         USERS_OPENING：执行语句的用户数

l         FETCHES：SQL语句的fetch数。

l         EXECUTIONS：自它被载入缓存库后的执行次数

l         USERS_EXECUTING：执行语句的用户数

l         LOADS：对象被载入过的次数

l         FIRST_LOAD_TIME：初次载入时间

l         INVALIDATIONS：无效的次数

l         PARSE_CALLS：解析调用次数

l         DISK_READS：读磁盘次数

l         BUFFER_GETS：读缓存区次数

l         ROWS_PROCESSED：解析SQL语句返回的总列数

l         COMMAND_TYPE：命令类型代号

l         OPTIMIZER_MODE：SQL语句的优化器模型

l         OPTIMIZER_COST：优化器给出的本次查询成本

l         PARSING_USER_ID：第一个解析的用户ID

l         PARSING_SCHEMA_ID：第一个解析的计划ID

l         KEPT_VERSIONS：指出是否当前子游标被使用DBMS_SHARED_POOL包标记为常驻内存

l         ADDRESS：当前游标父句柄地址

l         TYPE_CHK_HEAP：当前堆类型检查说明

l         HASH_VALUE：缓存库中父语句的Hash值

l         PLAN_HASH_VALUE：数值表示的执行计划。

l         CHILD_NUMBER：子游标数量

l         MODULE：在第一次解析这条语句是通过调用DBMS_APPLICATION_INFO.SET_MODULE设置的模块名称。

l         ACTION：在第一次解析这条语句是通过调用DBMS_APPLICATION_INFO.SET_ACTION设置的动作名称。

l         SERIALIZABLE_ABORTS：事务未能序列化次数

l         OUTLINE_CATEGORY：如果outline在解释cursor期间被应用，那么本列将显示出outline各类，否则本列为空

l         CPU_TIME：解析/执行/取得等CPU使用时间(单位，毫秒)

l         ELAPSED_TIME：解析/执行/取得等消耗时间(单位，毫秒)

l         OUTLINE_SID：outline session标识

l         CHILD_ADDRESS：子游标地址

l         SQLTYPE：指出当前语句使用的SQL语言版本

l         REMOTE：指出是否游标是一个远程映象(Y/N)

l         OBJECT_STATUS：对象状态(VALID or INVALID)

l         IS_OBSOLETE：当子游标的数量太多的时候，指出游标是否被废弃(Y/N)

(2)-V$SQL_PLAN

　　本视图提供了一种方式检查那些执行过的并且仍在缓存中的cursor的执行计划。

　　通常，本视图提供的信息与打印出的EXPLAIN PLAN非常相似，不过，EXPLAIN PLAN显示的是理论上的计划，并不一定在执行的时候就会被使用，但V$SQL_PLAN中包括的是实际被使用的计划。获自EXPLAIN PLAN语句的执行计划跟具体执行的计划可以不同，因为cursor可能被不同的session参数值编译(如，HASH_AREA_SIZE)。

V$SQL_PLAN中数据可以：

l         确认当前的执行计划

l         鉴别创建表索引效果

l         寻找cursor包括的存取路径(例如，全表查询或范围索引查询)

l         鉴别索引的选择是否最优

l         决定是否最优化选择的详细执行计划(如，nested loops join)如开发者所愿。

　　本视图同时也可被用于当成一种关键机制在计划对比中。计划对比通常用于下列各项发生改变时：

l         删除和新建索引

l         在数据库对象上执行分析语句

l         修改初始参数值

l         从rule-based切换至cost-based优化方式

l         升级应用程序或数据库到新版本之后

　　如果之前的计划仍然在(例如，从V$SQL_PLAN选择出记录并保存到oracle表中供参考)，那么就有可能去鉴别一条SQL语句在执行计划改变后性能方面有什么变化。

注意：

Oracle公司强烈推荐你使用DBMS_STATS包而非ANALYZE收集优化统计。该包可以让你平行地搜集统计项，收集分区对象(partitioned objects)的全集统计，并且通过其它方式更好的调整你的统计收集方式。此处，cost-based优化器将最终使用被DBMS_STATS收集的统计项。浏览Oracle9i Supplied PL/SQL包和类型参考以获得关于此包的更多信息。

不过，你必须使用ANALYZE语句而非DBMS_STATS进行统计收集，不涉及cost-based优化器，就像：

·使用VALIDATE或LIST CHAINED ROWS子句

·在freelist blocks上收集信息。

V$SQL_PLAN中的常用列：

除了一些新加列，本视图几乎包括所有的PLAN_TABLE列，那些同样存在于PLAN_TABLE中的列拥有相同的值：

l         ADDRESS：当前cursor父句柄位置

l         HASH_VALUE：在library cache中父语句的HASH值。

ADDRESS和HASH_VALUE这两列可以被用于连接v$sqlarea查询 cursor-specific 信息。

l         CHILD_NUMBER：使用这个执行计划的子cursor数

列ADDRESS,HASH_VALUE以及CHILD_NUMBER可被用于连接v$sql查询子cursor信息。

l         OPERATION: 在各步骤执行内部操作的名称，例如：TABLE ACCESS

l         OPTIONS: 描述列OPERATION在操作上的变种，例如：FULL

l         OBJECT_NODE: 用于访问对象的数据库链接database link 的名称对于使用并行执行的本地查询该列能够描述操作中输出的次序。

l         OBJECT#: 表或索引对象数量

l         OBJECT_OWNER: 对于包含有表或索引的架构schema 给出其所有者的名称

l         OBJECT_NAME: 表或索引名

l         OPTIMIZER: 执行计划中首列的默认优化模式；例如，CHOOSE。比如业务是个存储数据库，它将告知是否对象是最优化的。

l         ID: 在执行计划中分派到每一步的序号。

l         PARENT_ID: 对ID 步骤的输出进行操作的下一个执行步骤的ID。

l         DEPTH: 业务树深度(或级)。

l         POSITION: 对于具有相同PARENT_ID 的操作其相应的处理次序。

l         COST: cost-based方式优化的操作开销的评估，如果语句使用rule-based方式，本列将为空。

l         CARDINALITY: 根据cost-based方式操作所访问的行数的评估。

l         BYTES: 根据cost-based方式操作产生的字节的评估，。

l         OTHER_TAG: 其它列的内容说明。

l         PARTITION_START: 范围存取分区中的开始分区。

l         PARTITION_STOP: 范围存取分区中的停止分区。

l         PARTITION_ID: 计算PARTITION_START和PARTITION_STOP这对列值的步数

l         OTHER: 其它信息即执行步骤细节，供用户参考。

l         DISTRIBUTION: 为了并行查询，存储用于从生产服务器到消费服务器分配列的方法

l         CPU_COST: 根据cost-based方式CPU操作开销的评估。如果语句使用rule-based方式，本列为空。

l         IO_COST: 根据cost-based方式I/O操作开销的评估。如果语句使用rule-based方式，本列为空。

l         TEMP_SPACE: cost-based方式操作(sort or hash-join)的临时空间占用评估。如果语句使用rule-based方式，本列为空。

l         ACCESS_PREDICATES: 指明以便在存取结构中定位列，例如，在范围索引查询中的开始或者结束位置。

l         FILTER_PREDICATES: 在生成数据之前即指明过滤列。

CONNECT BY操作产生DEPTH列替换LEVEL伪列，有时被用于在SQL脚本中帮助indent PLAN_TABLE数据

V$SQL_PLAN中的连接列

　　列ADDRESS,HASH_VALUE和CHILD_NUMBER被用于连接V$SQL或V$SQLAREA来获取cursor-specific信息，例如，BUFFER_GET,或连接V$SQLTEXT获取完整的SQL语句。

Column View                                                            Joined                 Column(s)

ADDRESS, HASH_VALUE                                    V$SQLAREA    ADDRESS, HASH_VALUE

ADDRESS,HASH_VALUE,CHILD_NUMBER      V$SQL       ADDRESS,HASH_VALUE,CHILD_NUMBER

ADDRESS, HASH_VALUE                                    V$SQLTEXT      ADDRESS, HASH_VALUE

确认SQL语句的优化计划

　　下列语句显示一条指定SQL语句的执行计划。查看一条SQL语句的执行计划是调整优化SQL语句的第一步。这条被查询到执行计划的SQL语句是通过语句的HASH_VALUE和ADDRESS列识别。分两步执行：

1.SELECT sql_text, address, hash_value FROM v$sql

WHERE sql_text like '%TAG%';

SQL_TEXT   ADDRESS HASH_VALUE

-------- -------- ----------

          82157784 1224822469

2.SELECT operation, options, object_name, cost FROM v$sql_plan

WHERE address = '82157784' AND hash_value = 1224822469;

OPERATION            OPTIONS       OBJECT_NAME        COST

-------------------- ------------- ------------------ ----

SELECT STATEMENT                                         5

SORT

    AGGREGATE

      HASH JOIN                                          5

      TABLE ACCESS   FULL          DEPARTMENTS           2

       TABLE ACCESS   FULL          EMPLOYEES             2

按照OracleOnlineBook中的描述，v$sesstat存储session从login到logout的详细资源使用统计。

　　类似于v$sysstat,该视图存储下列类别的统计：

l         事件发生次数的统计，如用户提交数。

l         数据产生，存取或者操作的total列(如：redo size)

l         执行操作所花费的时间累积，例如session CPU占用(如果TIMED_STATISTICS值为true)

注意：

如果初始参数STATISTICS_LEVEL被设置为TYPICAL或ALL，时间统计被数据库自动收集如果STATISTICS_LEVEL被设置为BASIC，你必须设置TIMED_STATISTICS值为TRUE以打开收集功能。

如果你已设置了DB_CACHE_ADVICE,TIMED_STATISTICS或TIMED_OS_STATISTICS，或在初始参数文件或使用ALTER_SYSTEM或ALTER SESSION，那么你所设定的值的值将覆盖STATISTICS_LEVEL的值。

v$sysstat和v$sesstat差别如下：

n         v$sesstat只保存session数据，而v$sysstat则保存所有sessions的累积值。

n         v$sesstat只是暂存数据，session退出后数据即清空。v$sysstat则是累积的，只有当实例被shutdown才会清空。

n         v$sesstat不包括统计项名称，如果要获得统计项名称则必须与v$sysstat或v$statname连接查询获得。

v$sesstat可被用于找出如下类型session：

n         高资源占用

n         高平均资源占用比(登陆后资源使用率)

n         默认资源占用比(两快照之间)

在V$SESSTAT中使用统计

　　多数v$sesstat中的统计参考是v$sysstat描述的子集，包括session logical reads, CPU used by this session, db block changes, redo size, physical writes, parse count (hard), parse count (total), sorts (memory), and sorts (disk).

V$SESSTAT常用列说明

n         SID：session唯一ID

n         STATISTIC#：资源唯一ID

n         VALUE：资源使用

示例1：下列找出当前session中最高的logical和Physical I/O比率.

　　下列SQL语句显示了所有连接到数据库的session逻辑、物理读比率(每秒)。logical和physical I/O比率是通过自登陆后的时间消耗计算得出。对于sessions连接到数据库这种长周期操作而言也许不够精确，不过做个示例却足够了。

先获得session逻辑读和物理读统计项的STATISTIC#值：

SELECTname, statistic#

FROM V$STATNAME

WHEREnameIN ('session logical reads','physical reads') ;

NAME                           STATISTIC#

------------------------------ ----------

session logical reads                   9

physical reads                         40

通过上面获得的STATISTIC#值执行下列语句：

SELECT ses.sid

     , DECODE(ses.action,NULL,'online','batch')          "User"

     , MAX(DECODE(sta.statistic#,9,sta.value,0))

       /greatest(3600*24*(sysdate-ses.logon_time),1)     "Log IO/s"

     , MAX(DECODE(sta.statistic#,40,sta.value,0))

       /greatest(3600*24*(sysdate-ses.logon_time),1)     "Phy IO/s"

     , 60*24*(sysdate-ses.logon_time)                    "Minutes"

FROM V$SESSION ses

    , V$SESSTAT sta

WHERE ses.status     = 'ACTIVE'

AND sta.sid        = ses.sid

AND sta.statistic# IN (9,40)

GROUP BY ses.sid, ses.action, ses.logon_time

ORDER BY

        SUM( DECODE(sta.statistic#,40,100*sta.value,sta.value) )

      / greatest(3600*24*(sysdate-ses.logon_time),1) DESC;

SID User   Log IO/s Phy IO/s Minutes

----- ------ -------- -------- -------

1951 batch       291    257.3       1

470 online    6,161     62.9       0

730 batch     7,568     43.2     197

2153 online    1,482     98.9      10

2386 batch     7,620     35.6      35

1815 batch     7,503     35.5     26

1965 online    4,879     42.9      19

1668 online    4,318     44.5       1

1142 online      955     69.2      35

1855 batch       573     70.5       8

1971 online    1,138     56.6       1

1323 online    3,263     32.4       5

1479 batch     2,857     35.1       3

421 online    1,322     46.8      15

2405 online      258     50.4       8

示例2：又例如通过v$sesstat和v$statname连接查询某个SID各项信息。

select a.*,b.name

from v$sesstat a,v$statname b

where a.sid=10and a.statistic#=b.statistic#;

(2)-v$mystat

　　本视图是v$sesstat的一个子集，返回当前session的统计项。当通过触发器审计session资源使用，可以使用v$mystat来捕获资源使用，这将比直接扫描v$sesstat的列要节省资源的多。

按照OracleDocument中的描述，v$sysstat存储自数据库实例运行那刻起就开始累计全实例(instance-wide)的资源使用情况。

类似于v$sesstat，该视图存储下列的统计信息：

1>.事件发生次数的统计(如：user commits)

2>.数据产生，存取或者操作的total列(如：redo size)

3>.如果TIMED_STATISTICS值为true,则统计花费在执行操作上的总时间(如：CPU used by this session)

v$sysstat视图常用列介绍：

l         STATISTIC#: 标识

l         NAME: 统计项名称

l         VALUE: 资源使用量

该视图还有一列class-统计类别但极少会被使用，各类信息如下：

1 代表事例活动

2 代表Redo buffer活动

4 代表锁

8 代表数据缓冲活动

16 代表OS活动

32 代表并行活动

64 代表表访问

128 代表调试信息

注意：Statistic#的值在不同版本中各不相同，使用时要用Name做为查询条件而不要以statistic#的值做为条件。

使用v$sysstat中的数据

　　该视图中数据常被用于监控系统性能。如buffer cache命中率、软解析率等都可从该视图数据计算得出。

　　该视图中的数据也被用于监控系统资源使用情况，以及系统资源利用率的变化。正因如此多的性能数据，检查某区间内系统资源使用情况可以这样做，在一个时间段开始时创建一个视图数据快照，结束时再创建一个，二者之间各统计项值的不同(end value - begin value)即是这一时间段内的资源消耗情况。这是oracle工具的常用方法，诸如Statspack以及BSTAT/ESTAT都是如此。

　　为了对比某个区间段的数据，源数据可以被格式化（每次事务，每次执行，每秒钟或每次登陆），格式化后数据更容易从两者中鉴别出差异。这类的对比在升级前，升级后或仅仅想看看一段时间内用户数量增长或数据增加如何影响资源使用方面更加实用。

　　你也可以使用v$sysstat数据通过查询v$system_event视图来检查资源消耗和资源回收。

V$SYSSTAT中的常用统计

　　V$SYSSTAT中包含多个统计项，这部分介绍了一些关键的v$sysstat统计项，在调优方面相当有用。下列按字母先后排序：

数据库使用状态的一些关键指标：

l         CPU used by this session：所有session的cpu占用量，不包括后台进程。这项统计的单位是百分之x秒.完全调用一次不超过10ms

l         db block changes：那部分造成SGA中数据块变化的insert,update或delete操作数 这项统计可以大概看出整体数据库状态。在各项事务级别，这项统计指出脏缓存比率。

l         execute count：执行的sql语句数量(包括递归sql)

l         logons current：当前连接到实例的Sessions。如果当前有两个快照则取平均值。

l         logons cumulative：自实例启动后的总登陆次数。

l         parse count (hard)：在shared pool中解析调用的未命中次数。当sql语句执行并且该语句不在shared pool或虽然在shared pool但因为两者存在部分差异而不能被使用时产生硬解析。如果一条sql语句原文与当前存在的相同，但查询表不同则认为它们是两条不同语句，则硬解析即会发生。硬解析会带来cpu和资源使用的高昂开销，因为它需要oracle在shared pool中重新分配内存，然后再确定执行计划，最终语句才会被执行。

l         parse count (total)：解析调用总数，包括软解析和硬解析。当session执行了一条sql语句，该语句已经存在于shared pool并且可以被使用则产生软解析。当语句被使用(即共享) 所有数据相关的现有sql语句(如最优化的执行计划)必须同样适用于当前的声明。这两项统计可被用于计算软解析命中率。

l         parse time cpu：总cpu解析时间(单位：10ms)。包括硬解析和软解析。

l         parse time elapsed：完成解析调用的总时间花费。

l         physical reads：OS blocks read数。包括插入到SGA缓存区的物理读以及PGA中的直读这项统计并非i/o请求数。

l         physical writes：从SGA缓存区被DBWR写到磁盘的数据块以及PGA进程直写的数据块数量。

l         redo log space requests：在redo logs中服务进程的等待空间，表示需要更长时间的log switch。

l         redo size：redo发生的总次数(以及因此写入log buffer)，以byte为单位。这项统计显示出update活跃性。

l         session logical reads：逻辑读请求数。

l         sorts (memory) and sorts (disk)：sorts(memory)是适于在SORT_AREA_SIZE(因此不需要在磁盘进行排序)的排序操作的数量。sorts(disk)则是由于排序所需空间太大，SORT_AREA_SIZE不能满足而不得不在磁盘进行排序操作的数量。这两项统计通常用于计算in-memory sort ratio。

l         sorts (rows): 列排序总数。这项统计可被'sorts (total)'统计项除尽以确定每次排序的列。该项可指出数据卷和应用特征。

l         table fetch by rowid：使用ROWID返回的总列数(由于索引访问或sql语句中使用了'where rowid=&rowid'而产生)

l         table scans (rows gotten)：全表扫描中读取的总列数

l         table scans (blocks gotten)：全表扫描中读取的总块数，不包括那些split的列。

l         user commits + user rollbacks：系统事务起用次数。当需要计算其它统计中每项事务比率时该项可以被做为除数。例如，计算事务中逻辑读，可以使用下列公式：session logical reads / (user commits + user rollbacks)。

注：SQL语句的解析有软解析soft parse与硬解析hard parse之说，以下是5个步骤：

1：语法是否合法(sql写法)

2：语义是否合法(权限，对象是否存在)

3：检查该sql是否在公享池中存在

-- 如果存在,直接跳过4和5,运行sql. 此时算soft parse

4：选择执行计划

5：产生执行计划

-- 如果5个步骤全做,这就叫hard parse.

注意物理I/O

　　oracle报告物理读也许并未导致实际物理磁盘I/O操作。这完全有可能因为多数操作系统都有缓存文件，可能是那些块在被读取。块也可能存于磁盘或控制级缓存以再次避免实际I/O。Oracle报告有物理读也许仅仅表示被请求的块并不在缓存中。

由V$SYSSTAT得出实例效率比(Instance Efficiency Ratios)

下列是些典型的instance efficiency ratios 由v$sysstat数据计算得来，每项比率值应该尽可能接近1：

l         Buffer cache hit ratio：该项显示buffer cache大小是否合适。

公式：1-((physical reads-physical reads direct-physical reads direct (lob)) / session logical reads)

执行：

select1-((a.value-b.value-c.value)/d.value)

from v$sysstat a,v$sysstat b,v$sysstat c,v$sysstat d

where a.name='physical reads'and

         b.name='physical reads direct'and

         c.name='physical reads direct (lob)'and

         d.name='session logical reads';

l         Soft parse ratio：这项将显示系统是否有太多硬解析。该值将会与原始统计数据对比以确保精确。例如，软解析率仅为0.2则表示硬解析率太高。不过，如果总解析量(parse count total)偏低，这项值可以被忽略。

公式：1 - ( parse count (hard) / parse count (total) )

执行：

select1-(a.value/b.value)

from v$sysstat a,v$sysstat b

Wherea.name='parse count (hard)'and b.name='parse count (total)';

l         In-memory sort ratio：该项显示内存中完成的排序所占比例。最理想状态下，在OLTP系统中，大部分排序不仅小并且能够完全在内存里完成排序。

公式：sorts (memory) / ( sorts (memory) + sorts (disk) )

执行：

select a.value/(b.value+c.value)

from v$sysstat a,v$sysstat b,v$sysstat c

wherea.name='sorts (memory)'and

         b.name='sorts (memory)'andc.name='sorts (disk)';

l         Parse to execute ratio：在生产环境，最理想状态是一条sql语句一次解析多数运行。

公式：1 - (parse count/execute count)

执行：

select1-(a.value/b.value)

from v$sysstat a,v$sysstat b

where a.name='parse count (total)'and b.name='execute count';

l         Parse CPU to total CPU ratio：该项显示总的CPU花费在执行及解析上的比率。如果这项比率较低，说明系统执行了太多的解析。

公式：1 - (parse time cpu / CPU used by this session)

执行：

select1-(a.value/b.value)

from v$sysstat a,v$sysstat b

where a.name='parse time cpu'and

        b.name='CPU used by this session';

l         Parse time CPU to parse time elapsed：通常，该项显示锁竞争比率。这项比率计算

是否时间花费在解析分配给CPU进行周期运算(即生产工作)。解析时间花费不在CPU周期运算通常表示由于锁竞争导致了时间花费

公式：parse time cpu / parse time elapsed

执行：

select a.value/b.value

from v$sysstat a,v$sysstat b

where a.name='parse time cpu'and b.name='parse time elapsed';

从V$SYSSTAT获取负载间档(Load Profile)数据

　　负载间档是监控系统吞吐量和负载变化的重要部分，该部分提供如下每秒和每个事务的统计信息：logons cumulative, parse count (total), parse count (hard), executes, physical reads, physical writes, block changes, and redo size.

　　被格式化的数据可检查'rates'是否过高，或用于对比其它基线数据设置为识别system profile在期间如何变化。例如，计算每个事务中block changes可用如下公式：

db block changes / ( user commits + user rollbacks )

执行：

select a.value/(b.value+c.value)

from v$sysstat a,v$sysstat b,v$sysstat c

where a.name='db block changes'and

        b.name='user commits'andc.name='user rollbacks';

其它计算统计以衡量负载方式，如下：

l         Blocks changed for each read：这项显示出block changes在block reads中的比例。它将指出是否系统主要用于只读访问或是主要进行诸多数据操作(如：inserts/updates/deletes)

公式：db block changes / session logical reads

执行：

select a.value/b.value

from v$sysstat a,v$sysstat b

where a.name='db block changes'and

         b.name='session logical reads' ;

l         Rows for each sort：

公式：sorts (rows) / ( sorts (memory) + sorts (disk) )

执行：

select a.value/(b.value+c.value)

from v$sysstat a,v$sysstat b,v$sysstat c

where a.name='sorts (rows)'and

         b.name='sorts (memory)'andc.name='sorts (disk)';

V$SQLTEXT中的常用列

HASH_VALUE：SQL语句的Hash值
ADDRESS：sql语句在SGA中的地址
SQL_TEXT：SQL文本。
PIECE：SQL语句块的序号

V$SQLTEXT中的连接列
Column      View      Joined Column(s)
HASH_VALUE, ADDRESS   V$SQL, V$SESSION   HASH_VALUE, ADDRESS
HASH_VALUE. ADDRESS   V$SESSION    SQL_HASH_VALUE, SQL_ADDRESS

示例：已知hash_value:3111103299，查询sql语句：
select * from v$sqltext
where hash_value='3111103299'
order by piece

本视图持续跟踪所有shared pool中的共享cursor，在shared pool中的每一条SQL语句都对应一列。本视图在分析SQL语句资源使用方面非常重要。

V$SQLAREA中的信息列

HASH_VALUE：SQL语句的Hash值。
ADDRESS：SQL语句在SGA中的地址。
这两列被用于鉴别SQL语句，有时，两条不同的语句可能hash值相同。这时候，必须连同ADDRESS一同使用来确认SQL语句。
PARSING_USER_ID：为语句解析第一条CURSOR的用户
VERSION_COUNT：语句cursor的数量
KEPT_VERSIONS：
SHARABLE_MEMORY：cursor使用的共享内存总数
PERSISTENT_MEMORY：cursor使用的常驻内存总数
RUNTIME_MEMORY：cursor使用的运行时内存总数。
SQL_TEXT：SQL语句的文本（最大只能保存该语句的前1000个字符）。
MODULE,ACTION：使用了DBMS_APPLICATION_INFO时session解析第一条cursor时的信息

V$SQLAREA中的其它常用列

SORTS: 语句的排序数
CPU_TIME: 语句被解析和执行的CPU时间
ELAPSED_TIME: 语句被解析和执行的共用时间
PARSE_CALLS: 语句的解析调用(软、硬)次数
EXECUTIONS: 语句的执行次数
INVALIDATIONS: 语句的cursor失效次数
LOADS: 语句载入(载出)数量
ROWS_PROCESSED: 语句返回的列总数

V$SQLAREA中的连接列
Column      View         Joined Column(s)
HASH_VALUE, ADDRESS   V$SESSION       SQL_HASH_VALUE, SQL_ADDRESS
HASH_VALUE, ADDRESS   V$SQLTEXT, V$SQL, V$OPEN_CURSOR HASH_VALUE, ADDRESS
SQL_TEXT     V$DB_OBJECT_CACHE     NAME

示例：
1.查看消耗资源最多的SQL：
SELECT hash_value, executions, buffer_gets, disk_reads, parse_calls
FROM V$SQLAREA
WHERE buffer_gets > 10000000 OR disk_reads > 1000000
ORDER BY buffer_gets + 100 * disk_reads DESC;

2.查看某条SQL语句的资源消耗：
SELECT hash_value, buffer_gets, disk_reads, executions, parse_calls
FROM V$SQLAREA
WHERE hash_Value = 228801498 AND address = hextoraw('CBD8E4B0');

1 监视连接前的准备工作
1)  在被监控WinXP主机上修改访问模式，办法是：安全策略在作怪（管理工具 -> 本地安全策略 -> 安全选项 -> "网络访问：本地帐户的共享和安全模式"）。默认情况下，XP的访问方式是"仅来宾"的方式，那么你访问它，当然就固定为Guest来访问，而guest账户没有监控的权限，所以要把访问方式改为“经典”模式，这样就可以以administrator的身份登陆了。
注意：一定需要设置密码，否则在MonitorConfiguration中添加 Measurements仍然会提示拒绝登录。
2) 保证被监视的winXP系统开启以下三个服务Remote Procedure Call(RPC) 和Remote Registry Service 、Remote Registry。其中Remote Procedure Call (RPC) Locator的登陆选项中要输入当前主机帐户和密码，然后重启该服务，其他服务设置不变。
注意：网上有些写着只要开启两个服务Remote Procedure Call(RPC) 和Remote Registry Service就可以，不确认其监视的Windows版本，但是Win XP必须开启Remote Registry这个服务。
3) 确认安装Controller的机器可以连接到被监视的WinXP机器。如果监控失败，并且 LoadRunner 找不到指定的服务器，请确认指定的服务器是否可用。在 Controller 或优化控制台计算机命令行中键入 ping <server_name>（或ip），执行 “ping” 操作。
4) 验证可以正常连接之后，如果有其他问题，可以参见下表解决：

问题1.无法监控其他域中的 Windows 计算机，或者“访问被拒绝”。
解决：要获得对远程计算机的管理权限，请在命令提示符下执行以下命令：%net use \\<计算机名>/用户:[<域>\<远程计算机名>] 提示输入密码时，输入远程计算机的密码。

问题2：无法监控 NT/Win 2000 计算机（发出一条错误消息：“未找到计算机名”或“无法连接到主机”）
解决：要监控的 NT/Win 2000 计算机仅允许具有管理员权限的用户进行监控。要允许非管理员用户进行监控，必须授予用户对特定文件和注册表项的读取权限（Microsoft 技术说明编号 Q158438）。需要执行下列步骤：
a. 使用浏览器或文件管理器，授予用户对下列项的读取权限：
   %windir%\system32\PERFCxxx.DAT 
     %windir%\system32\PERFHxxx.DAT 
     其中 xxx 是系统的基本语言 ID，例如，英语的 ID 为 009。这些文件可能已丢失或损坏。如果对此有怀疑，请从安装 CD 中提取这些文件。
b. 使用 REGEDT32，授予用户对下列项的读取权限：
   HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
     NT\CurrentVersion\Perflib以及该项的所有子项。
c. 使用 REGEDT32，至少授予用户对下列项的读取权限：
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg

问题3：无法从 NT 计算机监控某些 Win 2000 计数器。
解决：在 Win 2000 计算机上运行 Controller 或优化控制台。

问题4：某些 Windows 默认计数器生成错误
解决：删除有问题的计数器，并使用“添加度量”对话框添加相应计数器。

问题5：无法从被监控的计算机上获得 SQL Server 6.5 版的性能计数器。
解决：这是 SQL Server 6.5 版的一个错误。解决方法为：在被监控的计算机上使用 regedt32，授予用户对以下注册表项的读取权限：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer

问题6：选定度量未显示在图中。
解决：确保已注册显示文件和 online.exe。要在不执行完全安装的情况下注册监控器的 dll，请运行LoadRunner\bin中的set_mon.bat批处理文件。

问题7：监控 Windows 计算机时，图中不显示任何度量。
解决：检查内置的 Windows 性能监控器。如果该监控器不能正常工作，则可能是通信设置有问题。

问题8：监控 UNIX 计算机时，图中不显示任何度量。
解决：确保rstatd正在 UNIX 计算机上运行（请参阅“系统资源监控”）。

问题9：无法监控下列 Web 服务器之一：MS IIS、MS ASP 或ColdFusion
解决：请参阅上面的问题“无法监控 Windows 计算机”。

问题10：无法监控 WebLogic (JMX) 服务器
解决：打开<LoadRunner 根文件夹>\dat\monitors\WebLogicMon.ini文件，并搜索：[WebLogicMonitor]JVM=javaw.exe
将 javaw.exe 更改为 java.exe。将打开一个包含跟踪信息的窗口。

5) 确认并打开共享文件。首先，在被监视的WINXP机器:右击我的电脑，选择管理->共享文件夹->共享 在这里面要有C$这个共享文件夹。该文件可能存在，也可能不存在，没有的话，需要手动增加。然后，在安装LR的机器上使用运行，输入\\被监视机器IP\C$ 然后输入管理员帐号和密码，如果能看到被监视机器的C盘了，就说明你得到了那台机器的管理员权限，可以使用LR去连接了。
注意：这两步必须都进行操作，否则即使该共享文件已经存在但未在LR机器中进行连接，也可能无法正常使用。
2用LR监视windows的步骤

具体步骤参见LoadRunner Controller User’s Guild > Working with Firewalls >Monitoring Over a Firewall>Configuring Server Monitor Properties。

 

一、远程机上设置：

1、确保启动相应的服务项目。本来远程桌面需要的服务项目是默认开启的，但我自己以前曾经将系统服务减少以保证运行速度和安全。所以在此使用过程中发现了麻烦所在，尝试了半天，终于还是确认了需要开启以下服务项目才能进行远程登录。

若以下服务项目没开启的话，远程登录会提示以下信息：

“客服端无法连接到远程计算机。

连接可能没有启用，或者计算机太忙，无法接受新连接。也有可能网络问题使你无法连接。

请以后再试。如果问题继续出现，请跟系统管理员联系。”

出现以上提示的话，可以考虑下是否服务项目没启动的问题。

远程登录需要的服务项目：

Server

Terminal Services

Telnet

NT LM Security Support Provider（Telnet需要依存与此服务，因此需要先启动此服务）

2、取消防火墙对远程控制的限制。

防火墙会导致远程机登录本地机时连接超时的状况。

怎么设置防火墙？？自己搞哦。不行的话关闭了防火墙。

3、添加远程登录桌面用户：

        依次点击“开始——所有程序——管理工具——计算机管理”；

        在系统工具中点击“本地用户和组”，双击右边的“用户”；

        在右边空白处右击后选择“新用户”，在弹出的对话框中输入“用户名、全名、密码、确认密码”，其他的自己可以做设置。然后确定退出。

        右击新建的用户名——属性——隶属于，在弹出的对话框中点“添加”——高级——立刻查找——选中名称为“Remote Desktop Users”，确定退出，这样就完成了远程登录帐户的设置。

4、开启远程登录设置：

       右击我的电脑——属性——远程——远程桌面——在“允许用户远程连接到此计算机”前打勾。确定后即可在远程机上登录了。

二、本地机设置：

这个很简单拉。

依次打开“开始菜单——所有程序——附件——通讯——远程桌面连接”；

在打开的对话框中点击“选项”，计算机上填入要登录的主机的IP地址，还有刚才设置的用户名和密码，在“高级”选项中设置网络类型来优化设置，然后点击“连接”就行鸟。。

写完这篇，似乎会有一个安全性的问题，即使你设置了远程登录密码。但也有被破解的可能性存在。

所以，若你暂时不使用远程登录的话，可以将设置的帐号禁用，禁用刚才提到的服务项目即可。