中国光大银行信息科技部系统运维中心
数据库运行的同时，不断记录着相关的性能数据，这些数据默默地产生又默默地消逝。
但是，很多时候，我们同样渴望对话数据库运行的历史，来找到解决问题的答案。
现在我们可以做到对话数据库运行历史，因为我们将这些数据库数据汇集起来，建立性能数据库，称为TOPA：TrndsOfPrformancAnalyzing系统。
以下，我们向大家展示如何通过分析TOPA中历史性能数据，精确评估QNS数据库性能优化方案。
首先，我们通过TOPA来了解QNS数据库的整体压力情况。（为了全面反映系统压力，我们需要在TOPA中查看一段时间（几周甚至是几个月）的性能数据，来总结的规律性。由于本文篇幅所限，下文中只包括部分数据的截图。）
上图中，红色表示数据库CPU资源消耗，蓝色部分显示的数据库I/O资源消耗。通过TOPA报表视图，我们可以看到QNS数据库的主要消耗CPU和I/O资源。那么，图中显示的CPU和I/O压力究竟有多大？是否超出了系统容量？这时，我们可以使用TOPA中的对比功能。首先，使用视图评估CPU压力：
图中绿色表示服务器CPU的容量，即CPU的计算能力，蓝色表示数据库实际使用的CPU资源。可见，即便在峰值时段，数据库消耗的CPU也不超过40%。CPU的容量应该不是瓶颈。
我们再量化分析QNS数据库对I/O资源的使用：
根据TOPA中显示，峰值时段，QNS数据库I/O吞吐量为每秒70MB到MB之间。
或许，我们对这样的I/O吞吐量没有直观的概念。那么我们再次使用TOPA的横向对比功能，将QNS数据库和5A数据库交易时段的I/O吞吐量做一个对比。
QNS数据库I/O吞吐量（MBPS）：
5A数据库I/O吞吐量（MBPS）：
通过对比可以看到，QNS数据库交易时段的I/O吞吐量（70MB-MB）已经超过了5A数据库的日常交易时段（60MB）。
因此，我们基本可以得出这样的判断：QNS数据库业务高峰时的主要压力表现在CPU和I/O，其中I/O压力更加突出。
这将是我们进行数据库优化工作的方向！
确定了优化方案的方向之后，我们需要进一步确定优化方案的具体方法：
利用TOPA，我们对应用SQL进行排序，查看究竟是什么样的应用造成的业务压力，如下图：
上图可以看到：ID为“f9pc24px7r”的SQL在9月4日15：00到16：00和16：00到17：00的两个时段内所消耗的资源，占数据库整体资源消耗的45%和41%。其它日期的数据情况相似。
锁定了重点的应用SQL之后，针对我们关心的I/O资源，通过TOPA从历史数据来检查这个SQL对I/O资源的消耗：
可见，每天8：00-18：00的各个时段内，ID为“f9pc24px7r”的SQL消耗的I/O占整个数据库I/O的4%到84%，其中业务高峰时段，这个SQL消耗的I/O占整个数据库I/O的50%以上。
也就是说，如果能够很好的优化这个SQL，甚至理想状况下完全消除这个SQL的I/O请求，我们就可以在QNS的交易高峰时段，将数据库的I/O压力减少50%！
然而，SQL优化是降低I/O压力的唯一方法吗？
让我们利用TOPA换一个维度来分析这个问题：
TOPA提供了各个时段的物理I/O在每个数据库对象上的分布情况：
可见，各个时段的规律非常相似，物理I/O集中在一下的对象：
CHECK_RECORD
CHECK_RECORD
RCDA
UEBILL
NTRACT
访问以上5个对象所消耗物理I/O的占整个数据库I/O的50%左右。也就是说，如果我们能消除这些对象上的I/O，我们同样可以将数据库的I/O压力减少50%！
怎样消除特定对象的物理读取呢？方法也很简单：调整数据库参数，使用数据库缓存将特定对象完全缓存在BuffrCach中，自然就消除了物理读取。
截至到这里，我们的分析完全是使用TOPA完成的。尽管我们还没有登录过一次数据库，我们已经了解了QNS数据的资源消耗，确定了性能优化工作的方向和方法，甚至是对优化效果有了初步的预估。
连接到QNS数据库，我们可以获取以下信息：
ID为“f9pc24px7r”的SQL具体内容
SQL可以通过指定索引等方式进行优化，涉及项目组开发测试工作较多，我们在此不做具体讨论。但是可以看到，这个SQL仅涉及一个对象：BUSINESS_CONTRACT,和我们在TOPA中分析出的消耗物理I/O最多的对象匹配。
物理I/O最多的5个对象以目前的容量估算，需要3GB的内存空间，可以将以上对象完全缓存到BuffrCach中以消除I/O。
无论具体使用那种优化方案，我们都可以通过TOPA对实施效果进行量化预估：
首先，TOPA中可以看到SQL运行的历史状态：
根据TOPA记录，SQL的平均每次运行时间是16.75秒。
TOPA进一步显示了从历史运行的角度，SQL资源消耗的分布：
可以看到，这个平均每次SQL执行消耗的16.75秒中，83%是用来执行物理I/O操作的。
综合来看，如果我们扩展3GB的内存配置（或者比较好的优化SQL），可以预估到优化效果是：
业务高峰时段的物理I/O减少50%；
重点SQL的物理I/O减少%；
重点SQL的响应时间平均减少83%，即执行时间从16秒降低到3秒；
最后，我们一起回顾一下依据TOPA分析结果，制定数据库优化方案全过程：
根据历史压力信息，找出系统资源热点，确定优化方向。用到的TOPA功能：
分析资源热点与应用程序（SQL）和数据库对象的关系，确定优化方法。用到的TOPA功能:
对重点应用程序（SQL）和数据库对象的优化方案进行评估。用到的TOPA功能:
小D赞赏