阅读和翻译 Oracle Documentation: Oracle8i Designing and Tuning for Performance

1. Understanding Oracle Performance Tunning
包括以下内容：
什么是性能优化？
谁进行性能优化？
确定性能目标
确定用户的期望
评估性能
1.1 什么是性能优化？
1.1.1 响应时间和数据吞吐量的均衡考虑
优化的目标是和应用的要求密切相关的。对OLTP应用来说，数据的吞吐量比较重要，这些应用每天要处理成千上万的小事务。相反，对DSS应用来说，响应时间就比较重要，在某一时刻，它可能只获取很少的记录，但在下一个时刻，可能会需要获取大量的记录。当很多用户需要进行DSS查询，那么吞吐量也就比较重要了。
响应时间：响应时间＝服务时间 ＋ 等待时间 
将一个任务分解成一系列的独立的小任务，每个小任务的执行时间为服务时间，小任务在等待其他小任务执行结果的时间为等待时间。所以在并行处理的过程中，可以减少等待时间。
系统吞吐量：系统吞吐量等于在给定的时间内完成工作的数量。以下两种技术可以增加吞吐量：
※用相同的资源作更多的工作，即减少服务时间；
※通过减少总的响应时间来使工作做的更快。例如，如果 CPU 成了系统的瓶颈，那么就增加更多的cpu。
等待时间：一个相同任务的等待时间应该是相同的，但是当争用增加，等待时间也随之增加。
1.1.2 关键性的资源
CPU，内存，I/O能力和网络带宽等资源对降低服务时间时非常关键的。增加资源对提高系统的吞吐量和降低系统的响应时间都是十分有用的。系统的性能取决于以下几个方面：
※有多少可用的资源
※有多少需要资源的客户端
※需要长时间来等待资源
※需要占用资源多长时间
1.1.3 过度需求的影响
会导致：
※大大增加响应时间
※减少吞吐量
1.1.4 解决问题的调整措施
※ 调整单元消耗：即降低每个事务所使用的资源、降低服务时间、减少I/O次数
※ 调整功能需要：即调整处理工作的时间表或分布，例如在系统不忙的时候执行job等
※调整容量：增加或者重新分配资源
1.2 谁来优化？
    每个参与系统的人都有优化的角色。当人们对系统的特点进行互相交流沟通并形成文档后，优化就会变得简单和迅速。
    商务经理必须定义商务规则和过程，以提供一个清晰的和完成的模型用来做应用设计。他们必须指出那些对整个系统性能有影响的特定的规则和过程。
    应用设计者必须设计出隐含的性能瓶颈，他们必须和系统设计者进行充分的沟通，以使每个人都能了解应用的数据流。
    应用开发者必须交流他们所选择的策略，以使模型和sql语句在语句优化的过程中能快速地和简单地确定。
    DBA必须仔细地监视和记录系统的状况，以使能够识别和纠正不正常的性能表现。系统管理员和网络管理员必须记录和交流系统的配置情况，以使能够有效地设计和管理系统。
1.3 确定性能优化的目标
   当你正准备设计或者维护一个系统，你必须明确优化的目标，这样你才能知道什么时候去优化。当你没有一个明确的目标，就去修改系统的初始化参数或者sql语句，你将会浪费你的时间。
   当你开始设计你的系统，设定一个诸如"使得定购项目的90%的事务的响应时间在3秒钟内"。如果应用不能达到这个目标，那么就要确定瓶颈，并且要解决这个问题（比如I/O争用）。在开发的过程中和部署应用之前，要对应用进行不断地测试以判断是否符合设计性能指标。
   性能的优化通常是一个权衡考虑的过程。当你已经确定了系统的瓶颈，你可能需要牺牲资源来达到期望的目标。例如，如果I/O是一个性能瓶颈的话，你就需要花钱去买更多的内存或者磁盘；如果不可能进行购买，那么为了达到设计的性能，你就需要限制系统的连接点数。当然，在明确定义系统目标的情况下，决定什么资源被放弃以改善性能是比较简单的，因为你已经确定了最重要的领域。
   【注意】决不要为了性能牺牲恢复数据的能力。性能是非常重要的，当数据的可恢复能力是关键的。
1.4 引导用户的期望
   应用程序开发者和数据库管理员都要小心谨慎地给用户设置合适的性能预期。当系统执行一个特别复杂操作，响应时间会比一个简单操作要慢，在这种情况下，比较慢的响应时间不是没有理由的。
   如果一个DBA承诺1秒钟的响应时间，那么就应该考虑一些影响响应时间的其他因素。DBA要表达的意思是数据库中的操作会在1妙钟内完成，数据库确实也能达到这个性能。但是由于网络阻塞等原因导致查询延迟了几秒，这样就达不到响应时间为1妙的预期。
1.5 评估性能
  有了明确定义的系统优化目标，你就可以容易地判断什么时候优化才是成功的。成功取决于和用户进行沟通而建立起来的可操作的目标，取决于客观地度量遇到的准则的能力，取决于为了克服异常而采取的正确措施的能力。在这本优化手册中的剩余部分，将会详细地描述优化的方法，诊断的工具和你可以采取的正确措施。
  负责解决性能问题的DBA必须知道影响响应时间的所有因素。有时候，一个问题咋一看起来很明显就是这个原因，但却很可能不是。遇到问题的用户可能说是数据库的问题，但实际上却是网络的问题。一个DBA必须检测网络、磁盘、cpu、应用设计等等，以确定问题的根源所在，而不是简单地将所有的性能问题都归结于数据库。
  进行性能监视可以使你可以维护一个优化的很好的系统。你可以比较系统性能的历史数据以获得有用的信息。一定负载水平下的资源消耗的数据显示会帮助你进行客观地和可测量地学习。从这些历史性能数据中，你可以预期未来一段时间的资源需求。

2.系统优化方法
  一个计划好的方法是进行成功优化的关键。不同的优化策略会有不同的效果，不同的系统（oltp 或者 dss）需要不同的优化方法。
  这一章包括以下几个部分：
  什么时候优化最有效果？
  优化的优先次序步骤
  优化的方法
  2.1 什么时候优化最有效果？
  2.1.1 在应用设计和开发阶段进行"抢先"(proactive)优化
    长远来说, 最有效的优化途径是"抢先"优化.
    商务主管必须和应用设计者建立一个性能的目标, 并设置现实的性能预期. 这样应用设计者就可以决定使用什么的系统资源和数据库特性来完成这些需求.
    好的应用设计, 可以减少它的实现和管理的代价.
 2.1.2 反方向优化生产系统
    当用户抱怨系统响应时间时, 优化往往还没有开始. 当感觉到响应时间太长时, 就已经错过了优化策略中的最有利时机. 在这个时候,如果你不愿意重新设计, 那么你只可能用分配更多的内容和优化 I/O 来提高系统的性能了.
    举一个例子来说, 一个银行, 有一个出纳和一个经理, 每一笔超过20元的提款必须得到经理的批准是一个商业规定. 当你发现客户们在排着长长的对时, 你决定增加10个出纳. 这样你会发现瓶颈会转移到经理身上. 而雇佣一个经理的代价是相当昂贵的. 在这个例子中, 如果你遵守这个商业规定, 不管如何地小心翼翼, 都将会花费非常大的代价.
    作为另外的选择, 改变商业规则将会更有利. 如果你将商业规则改变成这样: 超过150元的提款必须得到经理的批准, 这样问题就得到很好的解决. 在这个解决方案中, 有效的优化是在更高层次的设计阶段做的, 而不是在这个过程之后.
    对在线的生产系统进行反方向的优化也是可能的. 从系统的底部开始, 找到并且弥补任何瓶颈. 一个通常的目标就是使Oracle运行的更快一些. 然而, 你会发现Oracle服务器和操作系统都工作得很好. 为了获得更好得性能, 你需要去优化应用或者增加更多得系统资源. 在一个很好设计得系统中, 你才可以充分地使用Oracle提供得可以提高性能的特性去对系统进行优化.
    当然, 即使在设计的很好的系统中, 系统也会随着不断地使用而逐渐地降低性能. 在系统维护中, 不断进行的优化也是非常重要的.
2.2 合理的优化步骤顺序
  下面列出来的是优化数据库的推荐步骤顺序. 是按照对系统性能影响越大的排在越前面的顺序来排列的.
  步骤一: 优化商务规则
  步骤二: 优化数据设计
  步骤三: 优化应用设计
  步骤四: 优化数据库的逻辑结构
  步骤五: 优化数据操作
  步骤六: 优化数据获取路径
  步骤七: 优化内存分配
  步骤八: 优化I/O和物理结构
  步骤九: 优化资源竞争
  步骤十: 优化基础平台
  当完成了这些步骤, 再重新评估数据库的性能并决定是否要进行进一步的优化.
  优化是个重复进行的过程. 前面的步骤会为后面更进一步的优化铺平道路.
  步骤一: 优化商务规则
  为了优化性能, 你需要适应商业规则. 这涉及到对整个系统进行高级别的分析何设计. 配置就是要在这个级别进行考虑, 例如是否使用mts系统. 这样, 分析员要确保性能的需求能满足系统的商业要求.
  DBA们遇到的性能问题可能是在设计或者实现, 或者是不合适的商业规则引起的.
 
  步骤二: 优化数据库设计
  在数据设计阶段, 你必须确定你的应用需要什么数据. 你必须考虑那些重要的数据关系, 以及他们的属性. 最终, 你需要组织这些信息来满足性能目标.
   在数据库设计过程中当对数据进行分析以消除冗余, 经常会经历一个标准化的阶段. 因为是主键, 所有数据在数据库中必须只存储一次. 在数据标准化后, 你可能为了性能的因素而打乱这种标准化. 你可能需要数据库保留累计数据. 例如, 与其让应用程序每次都计算一个订单所有行的总价格, 你可能会考虑不如将每个订单的总价都保存在数据库中. 你还可以创建主键和外键索引来快速访问这些信息.
   另外一个考虑就是避免数据的争用. 考虑这样一个有1G数据量的数据库, 有1千个用户只访问其中的0.5%的数据, 那么这些"热点"数据就会导致性能问题.
  步骤三: 优化应用设计
  商务主管和应用开发者必须将商业目标转化为有效的系统设计. 商业过程关系到一个系统的一个特定应用, 或者一个应用的特定部分.
  一个很明智的过程设计的例子是战略地缓冲数据. 例如, 在零售应用中, 你可以在每天的一开始就选择税率, 并将它缓存在应用中. 这样, 在整个一天中, 你就不需要反复地获取同一个数据了.
  在这个层次中, 以可以考虑单个进程的配置. 例如, 一些pc用户可能会使用移动代理来访问中央系统, 而其他用户则直接相连. 虽然他们在使用相同的系统, 但每种类型用户的结构是不相同的. 他们可能需要不同的邮件服务器和不同版本的应用程序.
  步骤四: 优化数据库的逻辑结构
   当应用和系统的设计完成, 你就可以计划数据库的逻辑结构了. 主要要考虑好的索引设计以保证数据不致于被"过度索引"或者"缺乏索引". 在数据设计阶段, 你确定了主键和外键. 在逻辑结构设计中, 你就要创建更多的索引来支持应用.
   由于争用导致的性能问题一般包括将数据插入到同一个数据块中, 或者不正确的使用序列.
  步骤五: 优化数据库操作
    在优化数据服务器之间, 要确信你的应用已经充分使用了sql语句并使用了Oracle的那些用来加强应用的特性. 根据应用的需要, 尽量在你的应用中使用下面的特性和技术:
    Array processing
    The Oracle optimizer
    The low-lever lock manager
    PL/SQL
    理解Oracle的查询过程的机制对书写有效的sql语句是非常重要的.
    无论你是在写新的sql语句还是为一个应用优化有问题的sql语句, 优化数据库操作的正确方法应该是关注cpu和I/O资源.
    1. 找到消耗资源多的语句
    使用诸如 tkprof, the sql trace facility, sql analyze, Oracle trace, and the Enterprise Manager Tunning Pack 工具去查找sql语句或者存储过程中的问题. 做为另外一个选择, 你可以查询视图 v$sort_usage 来查看会话以及与临时段相关的sql语句.
    下面这些语句是最有潜力进行优化而提高性能的:
        那些总体消耗了大量的资源
        那些每一行都消耗了大量资源的
        那些执行的频率很高的
    在试视图v$sqlarea中, 你可以看到这些语句一直在缓存中, 有很多磁盘I/O和buffer gets (buffer gets 显示了使用cpu资源的大致状况)
    2. 优化这些语句使得它们使用更少的资源
    要记住应用的设计是性能的基础, 再怎么对sql语句进行优化也不能弥补再设计中的不足. 如果你遇到了sql语句优化问题, 那么可能你需要改变你的应用设计.
    你可以使用两种策略来降低特定语句的资源消耗:
      使这个语句消耗更少的资源
      使这个语句的执行频率更小一些
    语句使用了比较多的资源, 原因可能是他们做了更多的工作, 或者他们的工作效率比较低, 或者兼而有之. 当然, 每个工作单元使用越少的资源, 就越有可能你只可以通过改变应用设计来降低资源的使用. 也就是说, 与其改变sql语句, 不如使应用处理更少的数据行, 或者处理的频率小一些.
    这两个方面不是互相排斥的, 前面一个代价明显要小一些, 因为你可以在不改变程序(通过改变索引结构)或者仅仅改变sql语句就可以实现.   
  步骤六: 优化数据获取路径
    确保有效的数据获取路径. 考虑对 clusters, bash clusters, B-tree indexes, Bitmap indexes, 或者是 hints. 也要考虑对表进行分析和使用直方图去分析列, 以帮助优化器确定最好的执行计划.
    确保有效率的数据获取路径意味着增加索引或者为特定的应用增加索引, 然后将他们drop掉. 也意味着重新分析当初的数据库设计. 你可能想更进一步地规范你的数据或者创建替代索引. 通过测试应用, 你可能会发现你仍然没有得到你预期的响应时间, 如果这样的话, 那么你就需要寻找其他的方法来改进设计.
  步骤七: 优化内存分配
    Oracle 8i 的共享内存被动态分配给下面的结构中. 虽然你设置了共享内存的总的大小, 但系统为下面的这些结构动态地分配大小:
    data dictionary cache
    library cache
    Context areas (if running a multi-threaded server)
    你可以设置以下结构的内存分配:
    Buffer cache
    Log buffer
    Sequence caches
    合适的内存资源的分配会改善缓存的性能, 减少sql语句的分析, 减少内存的分页和交换.
    本地进程区域包括:
    Context areas (for systems not running a multi-threaded server)
    Sort area
    Hash areas
    要特别小心不要给SGA分配的内存在整个物理内存中占很大的比例.
  步骤八: 优化I/O和物理结构
    磁盘的I/O往往会降低很多软件的性能. 对I/O和物理结构的优化包括以下的方面:
    分布存储数据以避免磁盘的I/O争用;
    设置足够的 free list 与合适的pctfree, pctused 参数 ,以使块能被有效地访问;
    创建足够大的extents来存储数据, 以避免表的不断扩展. 如果不这样做, 会影响 OLTP 应用的性能;
    评估使用裸设备.
  步骤九: 优化资源竞争
    同时处理多个Oracle用户会导致对资源的争用. 争用会引起进程等待直到获取到资源. 特别要注意降低以下类型的争用:
    块争用, 共享池(Shared pool contention)争用, 锁争用, Pinging (在OPS环境中), 闩竞争.
  步骤十: 优化基础平台
    包括unix缓冲区的大小, 逻辑卷管理, 每个进程的内存分配.