2.6 工作负载测试 建模 实施
这部分描述了工作负载评估,模型和实施测试。这部分涵盖了以下的主题:
数据尺寸
负载评估
应用模型
测试 调试 和设计生效
2.6.1数据尺寸
如果你在一个坏的标本集合中处理不同长度的数据,你可能要经历在尺寸大小估计上的错误。随着数据容量的增长,你的主要长度会有相当的增长,改变了你在列上的假设。
当系统变得越来越容易操作,那就越来越难预测数据库的增长,尤其是索引的增长。随着时间的推移,表和索引的增长会由于个别应用在键的产生,插入的类型以及删除的行的行为而增长。最坏的情况是你使用升序的键插入,然后删除了左侧的大部分行,而不是所有的行。那么叶节点出现空隙并且浪费了空间。如果你想这样使用索引,确保你要知道如何在线重建索引。
DBA应该监控每个对象的空间分配并寻在可能超出控制的对象。一个应用的好的理解是能够突出可能快速增长或者是超出预期的对象,这是任何系统的性能可可用性计划的重要部分。当实施产品数据库。在交互型用户使用应用的时候,应该尝试保证发生最小的空间管理。这应用于所有的数据段。临时段和回退段。
2.6.2 评估工作负载
对于评估工作负载的能力和测试目的经常被称作黑色艺术。当考虑大量变量加入的时候,就很容易看到为什么这个工作几乎不可能得到精确的结果。但是设计者需要使用cpu,内存和硬盘驱动甚至应用的输出来区分机器。有好多关于尺寸的技术,每种技术都有优点。当当设置尺寸的时候,最好使用如下两个方法去证实你决策的方法并且提供支持文档。
从一个相似系统推算
标杆学习
2.6.2.1 从一个相似系统推算
这是一个完全以实验为基础的方法,存在相似的字符集和一只的性能作为一个基本的系统。通过已知的区别,系统的详细说明被分级专家修改。这种方法对于相关的系统是有优点的,但是在处理不同点基本没有帮助。
这种方法在准备大的工程项目的资金。比如建筑,船只,桥梁和油井的类似工程中常常是大的工程原则。如果设计到的系统和预想的系统去背太大了,那么很多组建就会超出设计的限制。
2.6.2.2 标杆学习
标杆学习的方法是资源和时间的消耗,可能产生不到正确的结果。通过模拟一个应用在早期开发和雏形表,存在和实际生产模型不一致的风险。听起来很奇怪,但是经过数据库应用组织多年的客户应用标杆学习。oracle尚未看到标杆学习和实际产品系统的可靠联系。这主要是由于应用无效率实例在开发中被引进。
但是,标杆学习已经在可接受的一定程度的精确性上成功的细粒化系统。尤其,标杆学习在系统全负载的时候善于决定实际的IO徐诶uhe测试恢复过程。
标杆学习的特征是将所有组件压到最低限制。因为所有组件被置为最低限制,那么在这个过程中就可以清楚的显示应用设计和实施中的所有错误。标杆学习也测试数据库,操作系统,以及硬件组件,由于大多数标杆学习执行的很急促,总是在一个系统组件失败的时候出现障碍。标杆学习是一个有压力的行为,可以从练习中获得大部分的经验。
2.6.3 应用模型
应用的模型能够从复杂的数学模型的联系到经典的样例估计。两种方法都有优点,一个有非常精确的特点,另外一个就比较粗糙了。下限是这两种方法都不允许实施错误和无效。
估计和细粒度方法是精确的科学。但是,通过研究这个方法,可以使用一些智慧的估计。整个估计的过程不允许应用中引入坏的sql,索引设计或者游标管理。细粒度工程师应该为应用的无效预留余地。性能工程师应该发现无效性并且使得估计看起来很现实。发现应用无效性的方法在oracle性能方法中有介绍
2.6.4 测试 调试 设计生效
测试过程主要包括功能和稳定性测试。
以下列表描述了一些简单的应用测试规则。
--使用ADDM和sql tuning advisor
--测试真实数据容量和分布
所有的测试必须在全部使用的表上做。数据库的测试必须包含从表的数据容量和基数来说很有代表性的产品系统。所有的产品索引应该被建立,模式统计必须正确。
--使用正确的优化器模式
--测试单用户性能
需要使单用户达到可以接受的性能,如果单用户都没有办法达到,那么就更不可能使多用户达到好的性能。
--为所有的sql获得和记录计划
--试图进行多用户测试
--在正确的硬件配置上测试
尽量和生产环境一样的系统上测试。否则会导致错误的潜在性能问题分析。
--测量稳定的性能状态
2.7 部署新的应用
这部分描述了在应用开发中的以下设计决策
--展示策略
--性能列表
2.7.1 展示策略
当新的应用被首次展示出来,需要采用以下两个策略
--大爆炸方法 所有用户一次性迁移到新的系统
--细水长流方法 将用户一点一点迁移到存在的系统中
两种方法都有优点和缺点。大爆炸方法依赖于需要级别的测试,但是有最小数据转换和与旧的系统同步的有点,因为它切换简单。细水长流方法允许扩展性问题的调试,所以增加了工作负载,可能意味着随着转换的发生数据需要从原来的系统中迁移。
很难建议选择哪种方法,因为每种方法在转换发生的时候都有导致系统切断的风险。可以肯定的是,细水长流的方法允许新用户引入新系统的时候进行程序概要分析,并且允许系统重新配置迁移的用户。这个方法影响了早期使用者的工作,但是限制了支持服务的负载。这意味着不规律的切断影响了一定比例的用户数量。
如何实施一个新的应用的方法对于每个业务都是不同的。被采用的方法有它自己唯一的压力和重要性。来源于测试过程尝试和知识越多你你才会知道哪个是最好的方法。
2.7.2 性能列表
为了协助展示过程,建立一个任务列表 如果做得对的话,会增加产品性能优化的机会。如果有问题就可以快速调试应用。
1 当创建产品数据库的控制文件,允许设置MAXINSTANCES,MAXDATAFILES,MAXLOGFILES,MAXLOGMMEMBERS MAXLOGHISTORY的值高于初次使用的值。这导致了磁盘的空间使用率更高,控制文件的大小更大,但是在紧急的时候有扩展性能节省时间。
2 把块大小设置为开发应用时候的值。如果经测试,在不同的数据容量和目前的sql执行计划是正确的话,从开发或者测试环境中导出模
式统计数据到生产数据库中。
3设置初始化参数的最小值。理想情况下,大部分其它参数应该设置为默认值,如果更多的进行调优,会使系统在有负载的情况下变慢。第四章介绍了初始化参数文件中参数的设置信息。
4 通过设置数据库对象的存储选项来管理块的争用。经常对表和索引进行insert update 或者delete的操作的话,需要使用自动段空间管理。为了避免回退段的争用,需要使用自动的回退段空间的管理。
5所有的sql必须证明它的资源使用率是最佳的,并且是最优的。
6确认中间件和程序能够有效的链接到数据库上不能频繁的登入登出
7确定sql有效的使用了游标。,每一条sql都被解析了一次,但是执行了多次,没有做到的最一般的原因是 没有合适的使用绑定变量语句中的where条件使用了直接量。如果实用预编译去开发应用,要确定maxopencursors,hold_cursor release_cursor这个参数在预编译应用之前被重置。
8 确定所有的模式对象成功的从开发环境迁移到了产品环境下,这包括表,索引,学列,触发器,包,过程,函数,java对象,同义词。权限视图。确保测试环境的任何修改都在产品环境了。
9 随着系统被展示出来。为数据库和操作系统建立一个统计数据的基线的集合。第一个统计数据生纠正了在设计中以及展示过程所做的假设。
10 开始期望第一个瓶颈并且根据oracle优化方法开始进行性能改善,更多的信息可以查看第三章 性能优化方法。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24799772/viewspace-677973/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/24799772/viewspace-677973/