[转帖]人大金仓- KWR 报告初体验

【本文正在参与炫"库"行动-人大金仓有奖征文】

开发者请集结丨炫“库”行动——2021人大金仓征文大赛悬赏万元等你来！

最近一直在研究 Oracle 的 AWR 报告，觉得它功能很强大，尤其是 DB Time 模型和等待事件能够让性问题的分析变得十分方便，再也不需要依赖大量的运维脚本去分析和定位问题了。

偶然之间，发现人大金仓的 Kingbase ES 也提供了一个类似的功能，叫 KWR 报告，深感意外。下面我们就来一起来探索一下吧。

1. 什么是AWR

首先我们先了解一下什么是AWR。它是Oracle 10g 版本推出的一个特性，全称叫Automatic Workload Repository（自动负载信息库）。AWR自动采集性能统计相关的指标，存储为性能快照（Snapshots），通过对比两次快照收集到的统计信息，来生成性能报告，帮助DBA对数据库进行性能调优。

AWR 的基本原理：数据库实例运行过程中不断产生一些统计数据，比如对某个表的访问次数，数据页的内存命中次数，某个等待事件发生的次数和总时间，SQL 语句的解析时间等，这些统计数据被一个叫做 MMON 的后台性能监控进程周期性地（默认每小时）自动采集，存储到 AWR 快照库里面，默认保留 8 天。

当出现性能问题的时候，DBA 执行 awrrpt.sql 脚本，指定快照范围，就可以生产相应时间范围内的 AWR 报告，定位性能问题的根本原因。

以下是一个 AWR 报告的示例：

2. 安装人大金仓 KES

去人大金仓公司网站上下载数据库的试用版：

人大金仓-KingbaseES V8 R6

我们选择的 KingbaseES V8 R6，下载一个单机版，以及开发版本的 License（后面安装时会用到）：

下载完成后，将安装包拷贝到 X86-64 平台的 Linux 虚拟机上，可以将 ISO 文件 mount 到文件系统，或者在 Windows 上用 winrar 解压后再拷贝过去也行。

安装程序是 SETUP/INSTALL.BIN，chmod +x 添加执行权限，运行后一路下一步，中间输入刚才下载的 license-开发版.dat，按照提示初始化数据库实例即完成安装过程。

在此我们将 KES 数据库安装到 kes_svr 目录，数据在 kes_data 目录：

3. 生成 KWR 报告

因为 KWR 依赖数据库内部的统计数据，所以最好通过配置文件 kes_data/kingbase.conf 开启全部的统计开关：

编辑 ~/.bash_profile 配置环境变量，将 KES 的 bin 目录添加到 PATH，并添加 2个快捷命令：

启动 KES 数据库，ksql 连接进去，创建 sys_kwr 插件：

创建性能快照 - 1，随便执行一些SQL语句，然后再次创建快照 - 2：

用刚才创建的 2 个快照产生 KWR 报告：

如果，我是说如果，这个报告是中文的，就太好了。据说中国的空间站上的显示屏上都是中文的菜单，希望下次看到这个报告时，它是中文的！

4. 管理KWR快照

快照是 KWR 的核心数据，整个 KWR 报告就是对采集到的快照数据进行挖掘，找出可能的性能问题的根本原因。

快照默认每个小时采集一次，保留八天，也可以通过参数去设置采集频率和保留时长。这样当发现过去某个时间段有性能问题的时候，可以通过KWR快照产生那段时间范围内的性能报告，回溯性能问题。

快照查询

快照的查询通过 perf.kwr_snapshots 即可：

自动快照

创建快照有2种不同的方式，自动快照和手工快照。

自动快照由后台进程周期性的生成快照，需要配置 kingbase.conf 参数：

sys_kwr.nable 参数默认是关闭的。

sys_kwr.interval是自动快照间隔，默认 60 分钟一次，这里设置为 10 分钟一次。

修改参数后，重启 KES 服务器，后台进程 kwr_collector 就会自动每 10 分钟采集一次快照。从 14:17 到 15:47 一共产生了 10 个快照：

这些快照以表的形式存在于当前库，可以通过 SELECT 去查看里面的内容，不过其内容比较基础，分析起来有一定难度。建议还是通过 KWR 报告去查看各性能指标。

手动快照

手动快照则是由 DBA 通过 SQL 语句执行生成快照，执行 perf.create_snapshot() 函数，返回快照编号：

手动快照不受自动快照间隔配置参数的影响，随时可以产生。

快照清理

如果之前产生的快照不想要了，可以执行 perf.reset_snapshots() 函数清理全部的快照：

也可以 drop extension sys_kwr 删除插件后再重新创建插件的方式清理全部的快照。

5. 生成 KWR 报告

有了 KWR 快照后，就可以随时生成 KWR 报告了。

生成 TEXT 格式报告

调用 perf.kwr_report(snap_1, snap_2) 来生成 text 报告：

报告的内容很长，这里不显示了，需要的朋友可以自己去实践一下。

生成 HTML 格式报告

TEXT 报告的可读性稍微差一些，可以调用 perf.kwr_report(snap_1, snap_2, ‘html’) 来生成 html 报告，它是网页形式的，可读性非常好：

用 Firefox 打开 KWR_1_2.html：

感觉还是 HTML 格式的报告更便于阅读一些。不过 TEXT 格式的报告直接在ksql里就能看，看自己实际的需求吧。

将报告存为磁盘文件

也通过 perf.kwr_report_to_file() 函数可以将生成的 KWR 报告保存到磁盘上：

感觉这功能还挺方便的，不需要使用 Linux 的管道符操作了。这个功能 Oracle 好像没有。

6. 分析 KWR 报告

为了后面的演示更有针对性，我们在KES数据库不进行任何优化的情况下，运行 TPCC 测试 2 分钟以便让数据库产生一些负载，在此期间生成两个快照，最后生成 KWR 报告，结合该报告来分析重要的一些性能指标。

报告结构

人大金仓的 KWR 报告主要分 3 部分：

1）报告头

这部分主要是列出数据库实例的版本、运行环境和快照信息。

2）报告摘要

这是整个报告的精华所在，大部分的性能问题都能够从这部分报告里看到。看这部分内容的时候，如果有必要，还可以结合后面的详细报告具体分析问题。

这部分最重要的几个报告是：负载统计表（Load Profile）、实例效率百分比（Instance Efficiency Percentages）、前台等待事件（Top 10 Foreground Wait Events）、主机环境统计（Host CPU、Host IO、Host Memory、Host Network）。

3）报告主体

报告主体提供了更加全面的性能指标，主要包括：DB Time 模型、等待事件、SQL 报文统计、TOP SQL 统计、后台写统计、数据库对象统计和配置参数。

分析 DB Time

DB Time，就是数据库时间，它用来衡量数据库的繁忙程度，DB Time 越高，说明数据库业务越繁忙。

如报告所示，在 2.92 分钟的快照时间内，只有 0.16 分钟在执行数据库任务，说明数据库业务非常空闲。

在满负荷的情况下，DB time 会等于 Elapsed Time（快照时间）* CPU 个数，说明每一个 CPU 都在执行数据库业务。

可以从详细报告的 Time Model Statistics 里看 DB time 的各组成部分：

分析负载统计

分析 Load Profile 报告，能够从总体上了解数据库系统的负载情况。主要分为5个部分：

DB Time 统计
IO 统计
解析和执行次数统计
元组统计
事务统计

IO 方面需要重点关注的指标有 WAL Size - WAL 日志 IO 大小，和 Blocks Read/Write Size - 数据页读和写的大小，这应该是物理读写的大小。

解析方面需要关注解析次数和执行次数的比例情况，如果硬解析过多，则必然 Parser Calls 跟Execute Calls 更接近，说明解析效率不高。如果今后能够提供软解析和硬解析次数，就跟完美了。

元组方面感觉可以大概看一下增删改查的比例就好，了解一下大概的业务类型。

事务方面看看回滚的事务是不是比例高，如果比例高是不是需要分析一下业务逻辑。

这个报告非常的有用，我比较喜欢的一点是这里提供了每秒（Per Second）、每事务（Per Transaction）的统计功能，可以比较直观的知道每秒写了多少WAL日志，每秒执行了多少元组的插入和删除等。

分析实例效率百分比

这个报告功能比较少，这里面出现的每一项，最佳情况是都为 100%，至少应该是 90% 以上。如果低于 90%，说明数据页缓存不够（Buffer Hit），需要加大 Shared_buffers，让更多的数据页通过缓存级能命中，较少 IO；或者说明解析和计划效率不高，发生了大量的硬解析的，需要从业务端把 Simple Query（select * from t1 where id = 5）通过扩展 SQL 协议来执行，即绑定变量的方式来执行。

如果能再多提供一些跟效率百分比相关的统计更好了，比如 LWLock 命中率，全部在内存上发生的排序比例等。