Oracle 9i 和 10g 高性能调优

Oracle 9i 和10g 高性能调优
介绍
让我们从安装所需要的检查的事物开始来讨论oracle的优化。

调优环境
调优的环境是什么？是一个你的调优努力能起作用的一种环境。

调整oralce数据库的所必需的东西
⏹好多软件工具
⏹训练有素的人
⏹分段的测试环境
⏹生产环境的一个副本
○真实的和期望的生产环境。

在成长快速或者需求改变时，这些环境是经常不同的。

○经可能的使得数据库的大小/内容一致。

在不能完全满足这样的要求时，至少开发和测试数据库应该同生产数据库成比例
○统计表是一样的吗？统计表可以拷贝，或者同生产数据库使用同样的时间间隔执行
可用工具
调整和监控数据库的优秀软件很多。

OEM有很多非常有用的小组件。

Spotlight擅长于对繁忙系统的视频和信息进行实时监控。

两者对调整数据库物理和SQL代码的性能分析都是非常有用的。

也有许多其他的工具可用。

在调整过程中最重要的工具是developer和administrators。

那是为什么你读这本书的原因。

最好的软件工具也意味着是最昂贵的，当然这也不是说较为便宜的工具是无用的了。

通常，越贵的软件为你所做的事情越多。

然而，有时候自动为你做了某些工作，你不理解其内部机制。

你的工具集未必比经过良好训练，经验丰富的数据库管理员和开发人员作得更好。

训练有素的人
好的训练有其恰当的地方。

作为系统管理员或者开发者，数据库管理员趋向于有root权限。

每一种训练都有其优缺点。

开发者除了编码SQL，创建数据模块之外，所了解的知识越来越多。

系统管理员对unix之类的操作系统知识具有广泛的了解，关注的是oracle数据库的物理存储的调优。

开发者关注的是数据库模型和创建更为高效的SQL代码方面的优化。

幸
的是，事情不总是如此。

有时候开发者趋向于把调优SQL代码和数据模型负担看着是数据库管理的负责范围。

这样就会导致混乱。

分段的环境
你需要尽可能多的实验环境。

作为DBA，你不能期望在一个在线的生产数据库上进行调优工作。

这些数据库一般要求24*7*365可用。

在这种情况下，在生产数据库上进行的调优局限于一定的范围，并且代价高昂。

不论怎么样，坚持有一台机器来测试你所做的工作。

这是生产与开发的最大不同。

有效的调优需要复制生产数据库
为了调优，得到最新最真实的生产数据库拷贝是绝对有必要的。

对生产数据库调优是危险的，使用开发数据库调优完全无效。

一般情况下，生产数据库和开发数据库差别巨大。

这时进行有效调优只能依赖于测试数据库。

统计表也非常重要。

在一个类似于在线事物处理数据库的环境中，数据频繁变化。

即使你的数据库数据变化不太频繁，统计数据也会发生改变，很快就会过时。

越是动态的数据库，其统计数据就更为频繁的刷新。

SQL代码优化器利用统计数据来发现执行SQL语句最有效的方式。

统计是数据本身度量，比如一个表多大，一个索引怎么使用等。

当一个SQL语句访问一个表时，表和索引是重要的。

数据库对象，比如表和索引，也包含在统计之中。

如果统计数据过时了，优化器就不会起作用。

过时的统计数据对所有类型的数据库有同样的影响。

从生产数据库复制统计数据到调优环境同生产数据库保持一致是非常重要的（或者拷贝，或者在调优数据库上执行统计数据收集）。

生产数据库较小时，把生产数据库拷贝到一个开发数据库不是一个问题。

当生产数据库比较大时，到开发数据库的连续数据拷贝是非常耗时的。

即使使用数据库导入工具对一个小数据库采用单个模式的导入，也比生产数据库的导出花费的时间多得多。

DBMS_STATS包可以在两个数据库之间拷贝统计数据。

调优的时机
你什么时候进行调优工作呢？在贯穿你的产品的整个生命周期，调优工作会经常进行。

有时也许只是性能有点问题就需要进行。

另一方面，在开始实施时应该把数据库进行适当的配置和组织，避免经常出现性能问题。

先知先觉总比事后忙乱好。

在开发期间优化数据库会比在开发完成后的生成数据库上进行好得多。

在开发期间调优将会延长任何系统的生命周期。

为什么出现这种情况呢？把一个复杂的任务分解到项目的不同阶段来进行，并且这些阶段不相互重叠。

这样就会做出一个更好的产品。

例如，任何开发者都知道调优SQL代码时会对代码进行改动。

在开发完成之后，这些工作会影响代码的完整性和整洁性。

这些看起来可能不是太重要。

然而，一块代码改变的次数越多，情况可能越糟。

不仅仅是因为代码改变本身，而是因为不同的编码者都可能对它进行改变。

每一个编码者有不同的风格和方法，经常对代码进行改动会让其他的人产生混乱。

反之亦然。

在对代码进行改变时，错误有可能会引入应用中。

改变越多，潜在的错误也越多。

我们不是生活在一个完美的世界。

在开发和产品之间不能走两条完全不同的路。

在项目的不
同阶段，不同的改进需求造成了阶段直接的一个灰色区域。

在开发和生产数据库之间经常会出现重叠现象。

数据模型和SQL代码最好在开发阶段进行调整。

在开发完成后的后开发阶段，或者说是在生产阶段，调优工作应当谨慎进行，特别是需要改变应用代码时。

如果在开发周期中，不能进行充分的优化，在一个生产数据库中进行调优时，需要遵循以下方法：
⏹设置性能目标
⏹使用测试环境
⏹使测试环境尽可能匹配生产数据库的情况
⏹谨慎调优
在生产数据库中调优的对象
对oracle生产数据库进行调优时有五个阶段：
⏹解决明显的瓶颈
⏹开始的数据库和数据库创建通常会出现不恰当的配置。

检查基本配置
⏹物理空间会被浪费。

通常情况下，一个数据库可以更好的组织，变得更小，甚至是
当前大小的十分之一，有时甚至更少。

注意oracle 10g：oracle数据库的物理配置越来越自动化了。

⏹对于应用和数据库中代码编写的所引起的性能影响，通过物理和配置的调整只能部
分抵消。

SQL语言的调优对性能有很大的帮助，但是应该首先在开发和测试环境
中进行。

⏹如果SQL代码调优不能解决产品的性能问题，可能就需要进行数据模型的调整了。

同SQL语言的调优一样，数据模型的调优也应该在开发和测试环境下首先执行。

在生产数据库中进行调优的最为容易的方法是数据库的物理和配置调优。

总的来说，对数据模型进行调优的代价最大。

因为这需要改变应用代码、SQL代码和生产数据库本身。

如果你的SQL代码不可调优，那么你的数据模型可能是粒度太小或者没有进行适当的规格化。

对数据库服务器本身的物理和配置的调优不需要对SQL代码和数据模型进行改变。

然而，纯粹数据库导向的调优方面可能最终导致昂贵的硬件升级。

硬件升级通常是调优的最好选择。

然而，在硬件变得太复杂而需要经过专业训练，待遇高的管理员时，代价会更大。

硬件升级通常是一个短期的解决方案，如果软件生命周期较短或者资金紧缺，假设这些硬件是可以重复使用且可以再次卖出，他们的成本效率会很好。

什么时候停止产品的调优
什么时候停止产品的调优？这个问题一直具有争议性。

你可以在性能目标达到时停止。

明显的瓶颈消除是一个清楚的指示器，说明不需要进行进一步调优了。

这是物理调优时经常遇到的。

物理调优包括配置，物理数据库结构，物理和硬件瓶颈问题仅仅占整个有效调优活动的10％。

简单的途径是要求你的开发人员编写经过适当调优的代码，在做这些工作之前需要确保数据模型的可靠性。

这也许是不可能的。

但是在开发阶段对SQL编码调优工作做得越多，那么在后面遇到的问题就会越少。

许多软件因为在开发阶段花费了太多时间而遭到放弃。

然而，许多其他的项目因为没有满足预期的性能而遭到失败或者重写。

在开发完成之后，调整数据模型和SQL编码，有时代价太高。

什么时候停止调优取决于你的位置和你所受到的训练。

如果你的公司、你的数据库大小和活动在增长，你就会遇到性能问题。

但是你应该对这种情况做更好的准备。

瓶颈
对瓶颈的解决总是事后的反应，而不是实现预知的。

瓶颈是计算机方面的中的行话，通常涉及到你的环境中的一个特殊部分，这是部分可能在数据库中，或者在数据库外，并且处于超载状态。

在瓶颈消除后，停止调优。

配置
如果有大量的配置和物理问题，需要消耗掉一些当机时间。

配置问题比物理问题容易解决。

而这两种工作又比调优数据模型和SQL编码更为容易。

可以通过在oracle数据库配置参数文件和oracle网络软件配置文件对参数进行准确参数配置而简化配置工作。

在改进参数之前，确保对配置参数完全理解。

首先，对参数文件的错误配置会造成数据库起不来，也许会引起软件的崩溃。

第二，一些参数会有一些特殊的功能；错误的配置引起与预期不同的效果，可能是不期望出现的影响。

在配置参数处于正确状态时停止调优。

在一个运行的数据库上通过改变配置参数来进行实验是危险的；测试，测试，测试！
物理空间的使用
因为物理空间使用和增长。