The Self-Managing Database: Automatic Performance Diagnosis（一）原文翻译

自管理数据库：自动性能诊断

An Oracle White Paper Nov. 2003

今天开始翻译这个文档，暂时还比较粗糙，有些东东觉得没有用就没翻，有些不知道怎么翻的，惭愧。

原文：http://www.oracle.com/technology/products/manageability/database/pdf/twp03/TWP_manage_automatic_performance_diagnosis.pdf

INTRODUCTION
企业数据库在大小和数量上持续增长，其结果就是系统管理和维护的复杂性增加。ORACLE 10g数据库集成了一系列自我管理的功能以简化管理，提高效率，降低和系统管理相关的消耗，且无论对哪种工作流都适用。
这个白皮书讨论了oracle新的性能怎段和监控技术的结构和元件，这些新的功能将集成到数据库服务器，并可以通过OEM实现。这个技术极大的简化了oracle数据库的诊断和调整。这个白皮书中主要讨论的元件包括Automatic Workload Repository (AWR), Automatic Database Diagnostic Monitor (ADDM), and Oracle Enterprise Manager (EM).这些元件的最根本的功能是检测oracle数据库，产生诊断统计。

PROBLEM OVERVIEW
数据库的性能优化是一个自然科学、艺术和巫术都一直在探讨的问题，通常认为是个非常复杂的工作，耗时且需要丰富的经验和解决问题的技巧。。。。。
调整数据库是否真的是非常困难的？是不是需要非常熟悉oracle数据库的将近200个参数和很多的函数？更多的调整经验是不是比更少的好？答案是 NO。
你是不是经常调整这些不可思议的参数以提高数据库的性能？现在有了一个好的消息，在oracle 10g，我们可以使你梦想成真，所有你需要做的就是设置：
_MAKE_SQL_RUN_FASTER = TRUE
在你的初始化文件中，这个参数设置将会你企业中的每个数据库运行的更快而不会出现下降趋势。真的，我们有没有告诉你，我们有一手好牌是你可以兴奋得工作而且拿到加薪。。。。。

ISSUES WITH ACCURATE PROBLEM DIAGNOSIS
在执行对系统的任何改变之前，一个至关重要的步骤是执行准确和及时地问题诊断。一些DBA经常发现一些征兆，然后立即修改系统设置以消除这些征兆。任何作过真正性能优化的人都会建议你正确的诊断问题可以更好的提高成功解决问题的可能性。
虽然如此，我们仍然发现很多DBA花费了大量的时间用来解决灾难系统的性能问题而不是努力去解决性能可能出现的问题。很多时候，隐患的派出结果可能就是性能的提高。通常情况下，隐患消除是因为DBA知道如何去消除隐患，他曾经遇到过类似的问题，并且认为这可能是问题的反复，但是很不幸的是，并不是每次都是这样。
这些相关的调整可能是冗余的，可能修复了一个问题，但是导致了系统另一个部分的瓶颈。通常情况下，为了诊断出问题所在，需要首先诊断出问题是工作流的哪个部分导致的，并且在打开更多的细节诊断后重复该工作流的工作。称为：workload replay.工作流的充做并不是每次都是可能的，基于以下的原因：
1、标示出的工作流其实只是导致问题的一个微不足道的部分。
2、大量的数据库不能在生产数据库上被重做。
这两个因素将会导致问题在数周甚至数月时间内都不能诊断出问题所在。

OVERVIEW OF ORACLE DATABASE 10G DIAGNOSTIC BENEFITS
自动数据库诊断监控（ADDM）提供以下好处：
1、每小时自动性能诊断报告
2、基于近十年的经验进行问题诊断
3、基于时间的量化问题的影响和推荐的好处
4、标示根本原因，而不是征兆
5、因为在自动工作流资料库（AWR）中已经完整记录了数据的变化，因此减少了重复工作流以细节分析需要

REACTING TO AN ORACLE PERFORMANCE PROBLEM
为了证明新的oracle 10g的性能校正的作用，我们现在需要估计在10g之前解决一个性能问题需要的步骤，并且对比在10g中的方法。相同的问题将出现非常不同的诊断结论。你可能猜到了，在10g的版本中，这个工作将比以前简单很多。
降低了诊断工作将使DBA有更多的时间用来解决问题，这也是我们主张的DBA真正应该做的工作。

Pre-Oracle Database 10g – The Before Image
1、在这一节中，我们将看一个在10g之前的版本中诊断出存在性能问题例子：
2、一个DBA收到一个用户（或者报警日志）的有关系统很慢的抱怨
3、这个DBA检查服务器看到还有大量的资源可以使用，所以很明显，速度变慢的原因不是因为机器马力不够。
4、然后，他检查数据库，看到大量的进程在等待‘latch free’
5、钻取到latches中，他看到大部分的latch free在等待on ‘library cache’ 和 ‘shared pool’ latches.
6、从以往的经验和他曾经看到过的数据资料上，DBA知道这些latches经常和硬解析（hard parsing）相关。再次检查有关‘parse time elapsed’ 和 ‘parse time cpu’的统计，发现增长。It is also observed that the elapsed time is accumulating much faster than CPU time so the suspicion is confirmed.（最后一句没看懂，怎么就确定的之前的猜测呢）
7、到了这一步，DBA有很多的办法可以确定不均匀的数据分配。一个办法就是检查所有进程的‘parse count(hard)’统计察看是不是有一个或者多个进程是造成硬解析的主要原因。另一个可选的办法是检查shared pool判断是不是有很多统计是针对相同的SQL执行计划但是对应不同的sql脚本的。在我们的例子里，DBA将采用后一种方法发现只有少量的执行计划，每个对应很多不同的sql脚本。
8、重新察看这些SQL语句中的一部分发现这些SQL中包含字符串在where语句中所以每个语句必须被单独解析。
9、在看到这些情况之后DBA可以说导致问题的最根本的原因就是没有绑定变量导致的重新解析，下一步就可以解决这些问题了。
10、在执行了这些步骤之后DBA可以用他的经验诊断出问题所在，如果其中某一步出现错误的决定都将导致时间和精力的浪费。

Oracle Database 10g - The After Image
对于相同的例子，我们在oracle 10g中可以看到显而易见的不同：
1、一个DBA收到一个用户（或者报警日志）的有关系统很慢的抱怨
2、这个DBA检查了最后一次的ADDM报告（下面的附件中给出了完全的例子），首先推荐看这里：
=======================================================================
FINDING 3: 31% impact (7798 seconds)
------------------------------------
SQL statements were not shared due to the usage of
literals. This resulted in additional hard parses which
were consuming significant database time.

RECOMMENDATION 1: Application Analysis, 31% benefit (7798 seconds)
ACTION: Investigate application logic for possible use of
bind variables instead of literals. Alternatively, you may
set the parameter "cursor_sharing" to "force".

RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033
were found to be using literals. Look in V$SQL for examples
of such SQL statements.
===========================================================================
这时DBA立刻就可以知道数据库超过30%的时间用来解析，推荐如何做以解决这个问题。注意这里还包含了一个猜想的计划哈希值以快速的检查一些例子语法。另外DBA没有增加额外的管理费用。
这个例子很好的体现了10g自动诊断校正的作用。

INTELLIGENT INFRASTRUCTURE
oracle的性能诊断的能力不是偶然出现的。调整专家需要理解数据库的工作方式和他们可以做什么以影响数据库的方法。为了提供这个新的功能，oracle服务器的编码方式发生了显著的修改。

Database Statistics
数据库的每个新的版本都增加了新的性能统计以提供给我们在数据库中的诊断方式。10g中我们特别提供了用以提高自动诊断性能的功能。当问题不好诊断的时候我们就可以依赖于工具使问题简化。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/51862/viewspace-180612/，如需转载，请注明出处，否则将追究法律责任。