帮忙分析一下数据库AWR报告

renxiao2003

大家看看都有什么问题！

taoyoyo

不好意思啊，解释一下！
回6楼wxhfriend ：
刚才看了一下你的AWR报告，有一个感觉
你是否是在生成AWR报告的两个小时的时间里，只是做了很简单的测试性任务
我想问，你生成并分析AWR的目的是什么，是学习呢，还是发现什么样的问题，需要调优”

答：
1，这个是测试数据库，确实在采样期间没有什么负载
2，作这个的目的一个是学习怎么分析报告，第二也想优化一下这个DB，因为确实很慢，在PL/SQL中查询数据时就有明显的体现。
3，我确实不是忽悠大家，有时确实很慢，而且Library Hit %＝96%也不太正常吧，听说不应小于99%。

taoyoyo

谢谢你的回答！

taoyoyo

是不是看一个DB的性能，主要看下面这些内容：

nstance Efficiency Percentages (Target 100%)

Buffer Nowait %:         100.00        Redo NoWait %:         100.00
Buffer Hit %:         99.24        In-memory Sort %:         100.00
Library Hit %:         96.77        Soft Parse %:         90.56
Execute to Parse %:         46.37        Latch Hit %:         100.00
Parse CPU to Parse Elapsd %:         90.47        % Non-Parse CPU:         72.36

bigmoyo

1、接收到SQL语句后，将其转换成ASCII等效数字码；
——基本不耗时。
2、将ASCII等效数字码传递给一个散列（hash）算法，由该散列算法产生一个单独的散列（值）；
——哈希算法，整数运算，耗时极小。
3、搜索当前用户session缓存（在PGA中）中，是否存在相同散列（值）的版本，如果存在，就直接执行该语句。这就是fast parse。
——整数匹配，耗时极小，PGA才多大点儿呀。
4、如果在PGA中没有命中，查找其他的session中是否有相同的散列（值），这就需要到共享池的库缓存中对查找。如果在库缓存中找到相同的散列（值），也就是 Library 中 Hit 成功。这就是soft parse。
——整数匹配，猜测是B树查找（即使纯列表线性查找也极快）。
5、若在3和4中都没有找到相同散列值，用户进程进行语法检查过程（Syntax Check）。语法检查主要是检查语法是否符合SQL Reference Manual 中给出的 SQL 语法。
——其实1－4动作都特别快，整数运算或查找而已。这步会很慢，慢的原因可以回忆一下《编译原理》的前面部分。
6、语法检查通过后，再进行语义分析过程（Semantic Analysis）。这个过程检查对象的合法性。比方说是检查表是否存在，列是否存在，是否有权限访问等。
7、选择执行计划。准备从可用的执行计划中选择一个执行计划，其中包括存储大纲（srored outline）或物化视图（materialized view）相关的决定。
8、这一步才真正“编译”生成该语句的一个伪代码（p-code）。1-8的整个步骤就是hard parse。

[ 本帖最后由 bigmoyo 于 2009-12-4 14:47 编辑 ]

XQKA

没荷载谈什么优化。慢是机器慢。pIII是10年前的机器。