努力 创新 求实

发布新日志

  • LoadRunner: Oracle 数据库性能指标说明

    2010-12-28 11:35:04

    计数器名称

    解释

    CPU used by this session (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (绝对)

    这是从用户调用开始到结束期间会话所用的 CPU 时间( 10 毫秒计)。某些用户调用可以在 10 毫秒内完成,因此,开始和结束用户调用时间可能相同。在这种情况下,将在统计信息中添加 0 毫秒。各种操作系统报都报告存在类似的问题,尤其是有多种上下文需要切换的系统。帮助对整体速度有所了解

    enqueue deadlocks (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (绝对)

    不同会话之间的排队死锁总数。 用以确定应用不合理处

    enqueue timeouts (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (绝对)

    完成前超时的排队操作(获取和转换)的总数。用以确定是否有需要优化语句

    execute count (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    执行 SQL 语句的总调用数(用户和递归)用以确定sql的执行频率,频率大且慢的需要优化

    opened cursors current (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (绝对)

    当前打开光标的总数。确定当前系统并行度

    parse count (hard) (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    分析调用(实际分析)的总数。硬分析意味着分配大批量工作和其他内存结构,然后生成分析树。就内存使用情况而言,硬分析是一种费用很高的操作。这几项用以确定说起来分析的消耗

    parse count (total) (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    分析调用(硬和软)的总数。软分析是一种检查,可确保底层对象上的权限未更改。

    parse time cpu (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    分析(硬和软)所用的总 CPU 时间( 10 毫秒计)

    parse time elapsed (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    分析的总已用时间( 10 毫秒计)。从该统计数据中减去分析时间 CPU,就可得到等待分析资源的时间总计。详细信息,请参阅上述的分析时间 CPU

    physical reads (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    从磁盘读取的总数据块数。此值等于“直接物理读取”次数加上对缓冲区缓存的总读取次数。这几项用以确定数据读写压力

    physical reads direct (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (绝对)

     

    physical reads direct (lob) (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (绝对)

     

    physical writes (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    向磁盘写入的总数据块数。此值等于“直接物理写入”次数加上从缓冲区缓存的总写入次数。

    physical writes direct (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (绝对)

     

    physical writes direct (lob) (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (绝对)

     

    redo log space requests (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    活动日志文件已满,Oracle 正等待分配磁盘空间以便恢复日志项。已通过执行日志切换创建了空间。与 SGA 大小和工作负载提交率有关的小日志文件可能会造成问题。进行日志切换时,在切换到新日志文件之前,Oracle 必须确保提交的所有脏缓冲区写入了磁盘。如果大的 SGA 充满脏缓冲区和小的恢复日志文件,日志切换必须等待 DBWR 将脏缓冲区写入磁盘,然后才能继续。还将检查日志文件空间,日志文件空间切换将等待 V$SESSION_WAIT 中的事件。确定日志存储性能

    session pga memory (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (绝对)

    此统计数据显示会话的当前 PGA 大小。此统计数据仅在 V$SESSTAT 中有用,它在 V$SYSSTAT 中没有意义。pga的大小调整有一些参考作用

    session pga memory max (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (绝对)

    此统计数据显示会话的峰值 PGA 大小。此统计数据仅在 V$SESSTAT 中有用,它在 V$SYSSTAT 中没有意义。

    sorts (disk) (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    如果对于给定的排序操作,磁盘写入数不为零,则此统计数据就会递增。需要磁盘 I/O 的排序很耗费资源。请尝试增加初始化参数 SORT_AREA_SIZE 的大小。有关详细信息,请参阅“SORT_AREA_SIZE”。对调整排序区大小有一定参考作用

    sorts (memory) (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    如果磁盘写入数为零,排序就完全在内存中进行,此统计数据就会递增。它进一步表明应用程序工作负载中的排序活动。您不可能比内存排序做得还好,除非根本没有任何排序活动。排序通常发生在表连接 SQL 操作期间,并按选择标准规范执行。

    sorts (rows) (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    总排序行数。

    table fetch by rowid (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    使用 ROWID 提取行(通常从索引恢复)时,每个返回的行都使此计数器递增。此统计数据表明行提取操作正在索引的帮助下进行。因为表扫描通常表明查询未得到优化或表没有索引,所以,当应用程序中出现上述问题时,此统计数据应该也会递增。确定索引使用情况

    table fetch continued row (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    在提取期间遇到跨多个块的行时,此统计数据就会递增。检索跨多个块的行会增加逻辑 I/O,递增系数与超过需要访问的块数对应。 将其导出,然后重新引入,可能会消除此问题。请仔细检查 STORAGE 参数 PCT_FREE PCT_USED。如果行数大于数据库块数(例如,使用的数据类型为 LONG,行又相当大),将无法更正此问题。对调整数据库块大小和分析数据碎片有一定参考作用

    table scan blocks gotten (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (绝对)

    协助查询全表扫描的合理性

    user commits (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    当用户提交事务时,为反映对数据库块所做的更改而生成的恢复必须写入磁盘。提交数通常最接近用户事务比率。(评估应用合理性)

    user rollbacks (V$SESSTAT 1/[SYS]/ABCDEF/ORACLE.EXE) (比率)

    此统计数据存储的是用户手动发出 ROLLBACK 语句的次数或在用户事务期间出错的次数。

      注:红色字标识 ,是请教了数据组专员解说的。

  • 有效的用例编写规则

    2010-12-21 16:04:28

     

    第一章 什么是高质量的用例

    1.1 为什么要使用用例

    用例提供了一种用于构建故事的半形式框架;

    在每个用例和所有描述层次中,用例都描述了错误情况的系统需求;

    虽然本质上是一种功能分解技术,但用例已经成为面向对象软件开发的一个流行元素;

    用例提供了可以在其上处理其他项目信息的骨架:

    项目经理根据用例进行估计和发布进度;

    数据及业务规则制定人员可以把自己的需求和所需用例联系起来;

    用户界面设计人员可以进行设计,并将其与相关用例联系起来;

    测试人员可以根据用例中描述的成功和失败情况构建测试场景(测试用例);

    1.2 编写用例容易出现的问题
    用户界面太多,用户界面应属于设计范畴,鼠标、按键等内容不应出现在用例中;
    较低目标层次上的用例太多,无法展示系统将会给其最终用户提供什么功能;
    使用用例表示非行为信息,性能需求、业务规则等不要在用例中描述;
    太冗长,最好在3~9步;
    目标实现不完整,尤其是错误处理;
    句子片断,主、谓、宾尽量完整;
    1.3
    为什么使用用例模式语言
    描述了用例的质量标志及其编写过程,提供了能够经受时间考验的用例改进建议;在评审用例初稿和改进其质量的过程中,这个工具能起到很大作用。
    1.4
    什么是模式
    模式是质量标志和策略;
    1.5
    使用模式语言时错误观念

    模式提供了一个关于其自身和模式内容的完整方法;只起补充作用
    使用模式肯定会成功;
    模式为老问题提供了新的解决方案;只是经常出现的问题的通用可靠方案
    模式适用于所有情况;仅是处于某种上下文中的问题的解决方案
    1.6
    模式组织

    模式分类

    子类

    开发模式

    团队组织 :判断和改进用例团队组织方式的质量的模式;

    过程 :判断和改进团队用来创建用例的方法质量的模式;

    编辑 :随着潜在需求的变化和编写人员知识的增加,判断和改进单个用例的质量;

    结构模式

    用例集 :判断和改进用例集质量的模式;

    用例 :判断和改进单个用力质量的模式;

    场景和步骤 :判断和改进用力场景以及这些场景中的步骤质量的模式;

    用例关系 :判断和改进集合中用例之间的结构关系质量的模式;

    1.7 用例的读者和编写者
    有两组不同的认阅读和使用用例:(1)最终用户或业务专家;(2)程序员。
    用例编写组必须包括:
    至少一位具有编程背景的认,以获得描述所要求的准确性和精度;
    至少一位熟知业务规则的认;
    至少一位熟知在实际中如何使用系统的认;
    1.7
    用例的读者和编写者

    有两组不同的认阅读和使用用例:(1)最终用户或业务专家;(2)程序员。
    用例编写组必须包括:
    至少一位具有编程背景的认,以获得描述所要求的准确性和精度;
    至少一位熟知业务规则的认;
    至少一位熟知在实际中如何使用系统的认;
    第二章 团队
    2.1 SmallWritingTeam

    原因:
    用例要求具有不同观点和专业知识的人编写;
    将一大组人聚集在一起是困难的;
    理论上,在用例上投入的人越多,就能越快的完成用例编写工作;
    大的团队会变得低效;
    大型编写团队可能会通过集体讨论的形式开发用例,添加许多不必要的特性;
    所以:
    一个由2人或3人组成的团队足够小,容易交流和达成一致;

    可以使用几个SmallWritingTeam,但应当制定一位用例设计师,以保证所有用例与愿景一致。
    最终目的是使过程保持在可管理状态,大的团队将在管理上投入更多的精力。
    2.2 ParticipatingAudience
    没有涉众提供的信息和反馈,就不能满足他们的需要;尽可能使客户和内部涉众积极参与用例开发过程。
    2.3 BalancedTeam
    由一些个性相似、意见相同的个人组成的团队开发用例,可能会得到一组缺乏创见、范围狭窄的用例,这种用例不能满足每个人的需要。
    因此,为小组配备具有不同专长的人员,以维护开发过程中涉众的利益,确保团队中包括开发人员和最终用户。
    最大好处是使编写人员在用例中使用常见的、可理解的术语。
    第三章 过程
    编写好的用例是极其个性化的,每个人都有他自己的风格,每个组织都有根据自己的文化和业务需要做事情的方式,因此,没有创建用例的通用过程。

    3.1 BreadthBeforeDepth
    原因:
    需求收集是一个发现过程,用例编写是一个迭代过程;
    人们很早就开始编写用例的细节;
    人们浪费了精力或陷入了太多的细节,通常都会失去重点,无法描述所有可能的扩展条件;

    从早期获得概述是有益的;
    最初编写的细节越多,在了解系统后必须进行的改变也就越多;
    所以:
    通过首先开发用例的概述来保存精力,然后逐步增加细节,并行开发一组相关用例。

    完成概述用例后,随着对系统了解的增多,不断提高用例精度,避免突然开发完所有用例或一次只开发一个用例的倾向。
    3.2 SpiralDevelopment
    (螺旋式开发)

    原因:
    理解系统的行为可能会花掉大量时间,要求渐进式分析;
    拖延是昂贵的。要尽快完成用例的编写;
    对需求进行分析后,需求很可能会发生变化;
    需求成本的错误是昂贵的;
    所以:
    以一种迭代的,宽度优先的方式开发用例,每次迭代都会提高用例集的准确性和精度。
    基本过程:
    从简单的东西开始,如一个参与者/用例列表;
    简要描述用力主场景,即高层用例,以包含用例的主要范围;
    扩展摘要的子集,并填充细节;
    评审并调整;
    3.3 MultipleForms
    不同的项目需要不同程度的形式化,每个人对模板都有不同的偏好,要求每个人都使用相同的用例模板只会起到相反的作用。
    原因:
    每个人的个性、经验和经受的锻炼不同,每个开发组织都有其特有的人员、历史和文化;
    不同的项目有不同的需要;
    不同的编写团队需要不同程度的规范和严格度;
    在组织中使用公共的编写形式有助于交流;
    在同一个项目上使用不同的模板不是一个好主意;
    因此:根据项目相关的风险性、项目特点,和所涉及到的人员选择用例的编写格式,并在该项目的开发过程中的组织内部使用。
    3.4 TowTireReview
    (评审)

    许多人都可能需要评审用例,这是一件昂贵耗时的事情。
    原因:
    对于验证和确认编写及内容来说,评审是必要的;
    涉众在用例上有一种既得利益;
    使每个人参与编写过程非常昂贵、麻烦并且缓慢;
    如果仅由一个小的编写组进行评审,就不会考虑所有涉众的利益;
    评审可能是昂贵的、乏味的、耗时的。
    所以:

    进行两种类型的评审:第一种是由较小的内部小组进行的评审,可能要重复进行很多次;第二种是由整个团队进行的评审,可能只进行一次。

    3.5 QuittingTime
    开发一个超出了涉众和开发人员需要的用例模型不仅浪费资源,而且会拖延项目进度。
    原因:
    忽视重要需求的巨大恐惧使构建人员和涉众延长了需求收集活动;
    大多数人可以用一种合理的模糊性工作,即不言自明;
    详细讲述谎言并不能使他们更为精确;
    所以:
    在用例完整并且符合参与者的需要后,停止开发用例;
    用例模型完整性的检验:完整、可读、逻辑上正确、对开发人员足够详细。
    是否识别了所有的参与者和目标并将其编成了文档?
    客户及其代表是否承认用例集是完整的,而且每个用例都是可读的和正确的?
    设计人员是否能够实现这些用例?
    3.6 WriterLicense
    小的格式差别并不重要,解决了所有系统问题后,及时还存在一些格式问题,也可以停止编写;

     

Open Toolbar