AWR 报告的“Load profile”节，如下图所示，包含很多极为有用，却被经常忽视的信息。通常更倾向使用“instance efficiency percentages”节，虽然可读性好，但很容易产生误解。
| Per Second | Per Transaction | Per Exec | Per Call | |
| DB Time(s): | 0.1 | 0.2 | 0.01 | 0.08 |
| DB CPU(s): | 0.0 | 0.1 | 0.01 | 0.05 |
| Redo size: | 2,650.2 | 9,391.1 | ||
| Logical reads: | 863.7 | 3,060.4 | ||
| Block changes: | 31.6 | 112.1 | ||
| Physical reads: | 220.2 | 780.2 | ||
| Physical writes: | 0.7 | 2.3 | ||
| User calls: | 0.9 | 3.1 | ||
| Parses: | 2.4 | 8.4 | ||
| Hard parses: | 0.2 | 0.8 | ||
| W/A MB processed: | 356,098.6 | 1,261,849.5 | ||
| Logons: | 0.0 | 0.2 | ||
| Executes: | 5.3 | 18.9 | ||
| Rollbacks: | 0.0 | 0.0 | ||
| Transactions: | 0.3 |
Redo size
你在数据库所做的一切都被redo（重做）保护。重做是所谓“change vectors（变化向量）”的集合，告诉 Oracle 如何在数据上重复操作，如果需要的话。尽管 SELECT 也可以产生一些 redo，但是 redo 的主要来源（在大约降序排序）：INSERT，UPDATE 和 DELETE。对 INSERT 和 UPDATE，redo 大小接近创建或修改数据的数量。对与 DELETE，你只需要知道已删除行的rowid，以便重复操作，因此，如果数据行是“fat”，那么redo大小可能远小于已删除数据的大小。
高redo数值意味着，大量新的数据被保存到数据库中，或现有的数据发生很多的变化，即DML操作很频繁。
多高算高？数据库不一样，所以不存在通用的标准。不过，我发现每秒 redo 乘以 86,400 秒（24*60*60=86,400，一天的秒数）会很有用，并且把它与数据库的大小相比——如果数字是在同一量级（magnitude），那么这就让我很奇怪了。数据库的大小每隔几天增加一倍？或者几乎每天修改每一行吗？也许，有些正在发生的我不知道的事情？
如果发现 redo 代过高你会怎么做。留意任何可疑的DML活动。此外，务必看下“segments statistics”小结（physical writes 段、DB block changes 段等），看是否有任何线索。
Logical reads, block changes, physical reads/writes
简单来说，Logical reads 是数据库读取数据块的数量，包括 physical（例如，磁盘）reads，block changes 是自我描述。这些统计告诉我们报告时数据库活动的性质（多数在写，多数在读，读写都有一点）和规模。它也给出一个想法，缓存的数据如何在数据库更好地工作（但你也在“instance efficiencies”小节从buffer cache hit ratio直接看到）。
如果你发现该数值比预期（基于平时的数值，当前应用程序负载等）的高，那么你可以下钻到“SQL by logical reads” 和“SQL by physical reads”，看下是什么SQL语句造成的。
User calls
当一个数据库客户端要求服务器做某些事时，像logon、parse、execute、fetch 等，就叫 user call。这是相当有用的信息，因为它为其他统计设置了规模（如 commits、hard parses 等）。
特别是，当数据库正在执行很多次时，每个user call，这可能是一个迹象，过多的上下文切换（例如，由于不好的执行计划，SQL语句中的PL / SQL函数在过于频繁地被调用，因为一个糟糕的计划）。在这种情况下，看下“SQL ordered by executions”将是合乎逻辑的下一步。
Parses and hard parses
Parse是分析查询的文本（可选），优化执行计划。如果涉及优化执行计划，那么它是一个hard parse，否则soft parse。
正如我们都知道，Parse是昂贵的（性能明智）。过多Parse会导致非常讨厌的性能问题（一个时刻，你的数据库似乎很好，下一刻，就变成完全停顿）。过度Parse的另一个坏事是，它使故障排除性能较差的SQL 更 困难。
多糟的hard parse是可以接受的？这取决于很多东西，像CPU数量，执行次数，执行计划对SQL参数有多敏感等等，但是，一个经验法则，低于每秒1个hard parse可能是好的，每秒100个以上就有问题了（如果数据库中有很多CPU，比如100个以上，这些数字会相应地扩大）。它还有助于看数量的硬盘解析％执行（the number of hard parses as % of executions）（特别是如果你在灰色地带）。
如果你怀疑过度Parse正在损害你数据库的性能：
1) 检查“time model statistics”小节（hard parse elapsed time、parse time elapsed 等等）
2) 看是否在在top-5 events有library cache 竞争的迹象
3) 看是否CPU有问题
如果证实你的怀疑，那么找到过度Parse源（对soft parse，使用“SQL by parse calls”；对hard parse，使用force_matching_signature），看是否可以修复它。
Sorts
排序操作消耗资源。此外，高昂的排序由于运行超出 TEMP 空间可能导致SQL失败。所以，很显然，排序越少越好（当你需要时，应该在内存中排序）。不过，我个人很少发现排序统计特别有用：通常情况下，如果高昂的排序正在损害你的SQL性能，那么你会首先发现它。
Logons
建立一个新的数据库连接是高昂的(在audit 或 trigger 情况下更高昂)。“Logon storms”被认为会产生非常严重的 性能问题。如果你怀疑 logons 高数量正在降低性能，那么检查“Time model statistics”中“connection management elapsed time”。
Executes
Executes 对分析性能很重要，但是我在上面“user calls”和“parses and hard parses”中已经说明。
Transactions
在一般（比如，创建理解报告其余部分的上下文）和特定（排除有关事务控制的性能问题）层次上，这是另一个非常重要的统计数据。AWR 报告提供了有关事务和回滚的信息，比如，计算两者之间提交数量的差异。回滚是昂贵的操作，并且，如果使用不当（即在测试的时候，测试后将数据库恢复到原来的状态），可能会导致性能问题，它可以通过控制数量减少回滚或调整回滚段。回滚也可以表明的一个分支代码失败，从而被迫回滚的结果（如果结果错误没有被适当处理或重新抛出的话，这可以被监控）。
过多的提交可以导致性能问题，通过 log file sync waits。
多少算过多？这完全依赖于数据库。显然，OLTP 数据库的提交要超过 DWH，并且在 OLTP 数据库之间，数量可以改变几个数量级。对于我曾参与的数据库，每秒低于 10-20，不会有任何问题，超过 100-200 就会有问题了（当不确定时，看下“top timed events”节：如果没有“log file sync“等待，那么可能就没关系！）。