这段时间一直在出差中，所以发文时间可能会不确定，如果早上有空，我尽量写点东西，如果一大早就有会或者在交通工具上，我就偷个懒了。

大多数做数据库优化的DBA在阅读AWR报告的时候，都是从TOP EVENT开始阅读的，或者把TOP EVENTS当成重点来阅读，所有的分析都是围绕着TOP EVENTS的，我刚刚开始学习阅读STATSPACK报告的时候，也是如此。不过随着对Oracle数据库优化与诊断的经验的深入，这个习惯逐渐被改变了。如果你让我看一份Oracle报告，我会围绕着Load profile来分析。因为大多数数据库的性能问题与故障都是与数据库负载相关的，经常有朋友说，为什么这套系统会出问题，另外一套不出问题，或者说为什么RAC的一个节点出问题，另外一个节点为什么不出问题。要回答这样的问题，大多数情况也都可以从负载的不同里去找答案。

Oracle的LOAD PROFILE是AWR报告中十分重要的一个章节，包含了大量的关于数据库负载的有价值的信息。LOAD PROFILE报告了数据库系统在一段时间内的平均负载情况，其中包括了许多性能关键指标，如每秒钟的逻辑读（logical reads per second）、物理读（physical reads per second）、执行的SQL语句数（SQL执行数）、每秒REDO量、每秒事务数、用户连接数（user calls per second）等。通过分析LOAD PROFILE，可以帮助DBA评估数据库系统的负载情况，并作出相应的优化决策。例如，如果LOAD PROFILE报告物理读非常高，那么可以尝试增加内存缓存，减少物理读取的次数，以提高数据库的性能，或者优化后端存储的IO性能。

我们该如何阅读LOAD PROFILE呢？今天我把我对LOAD PROFILE的阅读经验分享给大家。

         

大家能从LOAD PROFILE上看到些什么呢？我们先从指标的含义来简单地看看这份LOAD PROFILE。

1.DB Time(s): 这个指标表示数据库系统用了多长时间来完成所有的操作，单位为秒。每秒平均处理时间为1,345.4秒，这是一个非常高的数值，表明数据库系统正在经历一定的压力和负载，或者存在某种异常的等待或者阻塞，需要查看和优化数据库的配置和性能，以提高系统的响应时间。

2.DB CPU(s): 这个指标表示在数据库系统中使用的 CPU 时间，单位为秒。每秒平均使用 CPU 时间为165.1秒，这也是一个较高的数字，表明数据库系统的 CPU 使用率较高。这可能意味着需要进一步优化查询和应用程序的性能，以减少 CPU 的负载。

3.Redo size (bytes): 这个指标表示在数据库中记录事务日志的大小，单位为字节。每秒平均 redo 日志大小为14,425,930.7字节，这是一个相对较高的数字。如果系统的 redo 日志缓冲经常写满或者需要经常进行日志切换，这可能会影响系统的性能，需要进一步查看相关的指标来确定REDO性能是否存在问题。如果该指标较高，则要通过LOG FILE SYNC，LOG FILE PARALLEL WRITE，LOG FILE SWITCH COMPLETE等等待事件的延时来分析REDO负载是否已经对数据库的性能造成了较为严重的影响。并通过分析REDO相关的LATCH的丢失率分析是否存在过高的争用。

4.Logical read (blocks): 这个指标表示数据库系统每秒平均进行的逻辑读取次数，单位为块。每秒平均逻辑读取次数为9,643,527.6次，这是一个相对较高的数字，表示系统正在经历相当大的CPU压力。可以通过优化SQL来减少逻辑读取次数，从而提高系统的性能。

5.Block changes: 这个指标表示每秒平均进行的块更改次数。每秒平均块更改次数为108,760.0次，这个数字也比较高，可能表明数据库中的更新操作较为频繁。需要查看更新操作是否可以进行批量处理或者调整更新策略。

6.Physical read (blocks): 这个指标表示每秒平均进行的物理读取次数，单位为块。每秒平均物理读取次数为75,738.2次，这个数值比较高，可能表示系统需要从磁盘上读取数据的次数较多，可能需要考虑加快磁盘 I/O 的速度或者优化查询以减少物理读取次数。

7.Physical write (blocks): 这个指标表示每秒平均进行的物理写入次数，单位为块。每秒平均物理写入次数为2,561.1次，这个数字与读相比不算太高，表明数据库系统的写入操作较少。

8.Read IO requests: 每秒25,547.9，这个是数据库读IO对OS产生的读IOPS的数量，如果该数量较高，则说明数据库对底层IO子系统的压力较大。

9.Write IO requests: 每秒434.9，这个是数据库写IO对OS产生的写IOPS的数量，如果该数量较高，则说明数据库对底层IO子系统的写IO压力较大。本系统的写IOPS不算太高。

10.Read IO (MB): 每秒591.7MB,这是读IO的吞吐量，本系统双节点RAC，一个节点在半小时平均值中的每秒就高达591MB，说明本系统的IO负载还是很大的。

11.Write IO (MB): 每秒磁盘写入量为20.0MB，这个指标不算高，如果要分析是否对数据库造成了较大影响。

12.Global Cache blocks received: 每秒894.7个BLOCK，这个指标表示从远程实例每秒获取的数据块数量，如果存在异常则说明RAC集群的GCS服务存在性能问题。

13.Global Cache blocks served: 每秒657.7块，这个指标表示每秒发送给远程实例的数据块数量，如果存在异常则说明RAC集群的GCS服务存在性能问题。

14.User calls: 每秒25,408.0，这个数值对于这样的系统来说并不算高。每秒用户调用数量包含SQL语句执行的数量。该指标越高说明数据库的并发负载越高。

15.Parses (SQL): 每秒解析数量1,784.8，对于这个系统来说并不算高。

16.Hard parses (SQL): 每秒硬解析344.0，对于每秒只有2万5 USER CALL的系统来说，这个硬解析数量是相当高了。不过硬解析是否造成了性能影响，还要看后面的等待事件里的SHARED POOL，CURSOR相关的等待是否比较严重，或者延时过高。

17.SQL Work Area (MB): SQL工作区的大小为361.8MB，这个指标实际上是很容易被忽略的。对当前150GB的共享池的系统来说，这个数据并不算高，因为这个系统的特点是单个SQL的开销过大，而并发量并不算大。如果这个区域很大，并且增长异常，那么大概率是遇到了某些BUG了，或者说你需要关注它，避免因为SQL AREA扩展太大，引发一些问题。

18.Logons: 每秒登录3.3个会话，这说明系统存在一些短链接应用。

19.Executes (SQL): 每秒SQL执行3,094.0次，对于256 CPU线程的8路服务器来说，算是比较低的了。

20.Rollbacks: 每秒4.5个，如果这个指标异常高就需要查查了，不过有些数据库应用获取了连接后，会先执行一个ROLLBACK，以避免应用BUG导致的问题，这种系统中，这个指标会比较高。可以以此为基线来观察，严重超出此基线才说明系统有问题。

21.Transactions: 每秒44.5个事务。

         

似乎看上去，上面的这21个指标都不难看懂，实际上我们似乎看懂了，但是似乎什么也没看见，因为我们无法直接从这些指标中获得到分析系统问题所需要的线索。看LOAD PROFILE，首先要把LOAD PROFILE中的各个指标串起来看，而不是单一地去看某个指标。比如本系统硬解析比较高，达到344次每秒，那么会不会对共享池或者CURSOR产生较大争用呢？这时候我们要看USER CALL和Executes这两个指标了，如果这两个指标也很高，那么硬解析如此高肯定会带来性能问题，幸运的是这个系统中的这些指标都不高。

我们从TOP EVENTS和等待事件总体分析上，都看出共享池相关的而等待并不严重，concurrency相关的等待也占比很低。这样就可以排除这个负载指标可能引发性能问题了。

现在我们的国产数据库大多数也有LOAD PROFILE，不过看这些LOAD PROFILE我们更是一头雾水，因为缺少后面可以进一步分析某个负载指标异常的相关数据了。而Oracle这方面就十分丰富。比如我们发现IO负载很高，那么IO到底有没有问题呢？AWR报告中我们可以从很多角度去验证。

比如上面的wait Class的汇总分析，USER IO平均延时3毫秒，占比18.9%，SYSTEM IO平均延时1毫秒，占比0.1%。这说明IO问题并未对数据库造成较大影响。再看具体等待事件。

前台等待事件中的io相关等待延时均较为正常。

后台进程的IO也很正常。从上面我们就基本上可以确定，虽然IO很高，但是后端存储很给力，IO性能目前没有问题。

如果你还不放心，你可以继续分析IO stats去查看更详细的信息。甚至通过FILE IO的章节去看是不是存在整体IO性能不错，单个文件存在问题的情况。这种情况在以前使用裸设备的时候十分常见。或者说你使用ASM的时候，存在多个ASM磁盘组，而这些磁盘组的磁盘来源于不同的存储，或者不同类型的存储。那么可能总体IO性能指标很好，但是存在某些盘的IO存在性能问题。

为了分析清如此复杂的情况，必须以LOAD PROFILE为纲，以此为起点去做综合分析才可以得到更为精准的分析结论。这也给我们的国产数据库的可观测性能力提供了一个样板，我们提供了LOAD PROFILE，是否也提供了足以分析LOAD PROFILE的指标呢？