Tag Archives: Tuning

新的Oracle性能神话?

很多 DBA 应该都记得这篇文章吧 ? Myths & Folklore About Oracle8i Performance Tuning. 这篇文章的出现, 粉碎了当时的不少图书中标榜的实际上没有什么作用的优化”技巧”.

来自 OraPub 的 Craig A. Shallahamer 在一篇新的论文 Modern Performance Myths 试图定义新的 Oracle 性能神话.包括如下四条:

Myth #1. Decreasing wait event time will always decrease Oracle response time.
Myth #2. Decreasing wait event time will always decrease end-to-end response time.
Myth #3. Profiling sessions is the best way to diagnose performance problems.
Myth #4. Focusing on where most of the time is spent is always the best approach.

老实说, Craig 这篇论文写的非常”绕”.完全看明白要费点时间.因为第一条和第二条 Myth, 说的都是”always”, 只需要举出一个反面例子即可. 非常有趣的是第三条, Profiling sessions , 因为这是 Hotsos 的 Cary Millsap 在 Optimizing Oracle Performance 一书中 Method R 方法(参见:Oracle 数据库优化的R方法)所提倡的手段. 要反驳第三条 Myth 倒也不难, Profiling sessions 只能做到针对特定 Session(or User) 进行优化,这个优化能从全局的角度上看是否是成功的? 就不能简单的下判断. Craig 的建议是在系统级和会话级进行响应时间分析(RTA).

那么如何避免这些所谓的 Myth 呢? Craig 的答案是 The Holistic Problem Isolation Method (整体问题隔离方法,HPIM), 识别 Oracle,Application,OS (三环法)每个子系统的瓶颈,并且理解各个子系统之间的关系.

Cary Millsap 在Oracle 性能优化一书中提出的 Method R 的时候应该是自信满满, 但是 Craig 的这篇文档无疑也说明了 Method R 的一些遗漏之处.方法论是一个不断进化的过程, 没有所谓完美的方法,随着对Oracle优化认识的不断深入,相信也会有号称更为优秀的方法出现.但是能否更有效用在实践中,这是一个主要问题.

—-
BTW:
小道消息:Craig A. Shallahamer 将在 07 年推出一本名为 Forecasting Oracle Performance 的 Oracle 图书.期待.

Oracle 数据库优化的R方法(Method R)

好长时间没怎么看 Oracle 技术文档了，今天阅读了一篇 Oracle Response Time Optimization with Method R. 这是 Optimizing Oracle Performance 经典图书这本经典图书的主旨方法。R 代表响应时间(response time).具体的定义如下：

1. Target the tasks that are critical to the business.
2. Collect properly scoped, un-aggregated profile data for each task
while the task is exhibiting the behavior you want to record.
3. React with the candidate repair that will have the greatest net
payoff to the business.

a. Stop if the cost of the repair exceeds the cost of the problem.
4. Go to step 1.

这里面的核心元素是 Profile .Profile 要提供应用程序到最终用户的响应时间的详细描述.体现到 Oracle 数据库这一层，就是要得到扩展的 SQL Trace 数据。
是不是感觉有些”虚”, R 方法和一些我们已知的数据库优化方法颇一些相似之处，但是 Cary Millsap 宣称 R 方法是目前已知 Oracle 优化方法中的最优秀的、最全面的。我们来看看一些简单比较：

继续阅读 →

用 Statspack 收集 SQL 执行计划历史信息

小技巧一个:在一个开发环境中,可以考虑把用户的SQL执行计划历史也收集进来.很简单,但是对开发 DBA 会很有帮助, 根据 HASH_VALUE 查询相关过去某个时间段内的 SQL 执行计划.一共两步:
1 Statspack 的 level 6 收集所有的统计和执行计划. 用 level 6 收集快照(Snap)信息:

SQL> execute statspack.snap (i_snap_level=>6);

2 运行 $ORACLE_HOME/rdbms/admin/sprepsql.sql 脚本抽取特定 HASH_VALUE 的 SQL 信息:

继续阅读 →

Statspack使用中存在的几个误区

Statspack 是 Oracle 提供的一个实例级的Tuning工具。很多DBA都喜欢用这个工具来进行数据库的优化调
整。不过在交流中发现很多朋友对这个工具的的运用还有一些问题。下面就其中比较容易出问题的几个方面进
行一下简单的分析。

快照的采样时间间隔问题

我们知道，Statspack的report实际上也就是对比两个快照 (Snapshot，也就是数据库当前状态 ) 得出的结
果。

一般情况下，专家建议生成Statspack报告的快照时间间隔为15-30分钟。

试想，一个人去医院看病，医生对其测量体温，一般也就是5-10分钟左右就可以了，为什么是这麽长的时间？
因为5-10分钟这段时间基本可以近似的得到你的体温。如果时间过短，可能达不到既定的目的，测到的体温会
偏低，时间过长，甚至长达几个小时的话(假设有这种情况)，病人可能都昏迷几次了 ;) 。

对生成Statspack报告的快照时间间隔也是这样，如果两个Snap Time时间过短，数据库的一些主要周期性
事务可能还没有运行，信息收集不完全。如果间隔过长，数据一样会有偏差。

假设如下的情况：系统一直正常，但是最近几天有用户反映，在A时间段应用程序执行很慢。B时间段正常，而
A时间段有一个主要的事务X运行（也是用户使用到的事务）。 B时间段有另外一个比较消耗资源的事务Y在运
行。A和B时间段的跨度比较大。本来你的快照如果覆盖A时间段内就已经能够的收集到比较准确的数据了，但
不巧的是，你的Report 所用的两个Snap ID的时间跨度太长，从而把B时间段内的统计数据也收集了进来。
Statspack 经过比较，“认为”事务Y是对系统有主要影响(这也会在Report上体现出来)，而你，经过分析，认
为Y才是罪魁祸首，接下来，你不遗余力的对Y进行了tuning……

问题出现了！调整了B之后，用户继续报告，A时间段内系统不但没有变快，反而变得更慢，甚至不可忍受。这
种情况是很危险的，可能会对系统造成不同程序的损害。在比较严格的环境中，这已经构成了一次比较严重的
事故。

或许你也要承认，Statspack的快照的采样时间间隔还真需要重视呢……

这是一个Oracle　8.1.7.0.1　版本下的Statspack报告：

                      Snap Id          Snap Time Sessions
------- ------------------ --------
Begin Snap:            637 04-Aug-03 11:59:33       25
End Snap:              646 04-Aug-03 16:29:06       25
Elapsed:                        269.55 (mins)

从中可以看到快照637和快照646之间为269.55 (mins)。这么长的时间跨度，即使数据库在一定时间间隔内
有问题，在这里的体现也会有偏差。
下面的这个Statspack 报告的时间有点不靠谱了：

	                                                                Snap Length
Start Id  End Id              Start Time  End Time                (Minutes)
--------  --------  --------------------  --------------------  -----------
314  1053        11-Dec-03 18:07:13  19-Dec-03 10:53:02      11,085.82

11,085.82分钟? 这么长时间内的数据采集分析，怕是绝大部分内容都是不能相信的了。

还要注意的是，我们说的时间间隔，是Begin Snap和End Snap之间的间隔，而不是相邻两个Snap 之间的
间隔。对于Snap收集的间隔，建议以不要影响性能为准，收集的太过于频繁，会对性能和存储都造成压力。
对于所谓的15-30分钟，不能墨守成规。具体的环境下应该加以调整。

以偏概全

Statspack从本质上说，是对系统的性能统计数据进行采样，然后进行分析，采样，就会有偏差。如何消除偏
差？统计学指出差值随样品个数的增加而降低。所以，只凭借一个Report文档就断定数据库的性能问题出
在某处，是比较武断的做法（个别情况除外）。需要DBA创建多个Report，包括不同时间段，对比进行分析，
这样才会起到很好的效果。在寻求技术支持的时候也最好能够多提交几份Report，便于支持人员迅速帮助解决问题。

继续阅读 →