关键业务系统数据库优化小技巧

Posted 2021-07-02 白鳝的洞穴

关键业务系统的性能优化对于企业的业务发展来说至关重要，在十五年前，我们给某运营商做优化的时候，当时用户说，因为系统性能的问题，营业厅排队经常排长队。有一次中午午休的时候，还有十多名顾客没有办结，于是客户和营业员发生了冲突，把营业台上的电脑都砸了。这个例子虽然十分极端，不过也从另外一方面说明了高效运行的业务系统对企业核心业务的影响。前阵子去医院做核酸检测，发现现在医院已经没有了排长队的问题，大量的自助服务终端替代了以往排着长队的窗口。我发现了一处自助终端区没什么人，跑过去发现这组终端都关闭了，于是无奈只能去有人排队的终端办理挂号。虽然前面只是排了两个人，不过挂号的时间还是挺长，因为挂号应用十分慢。后来和医院的熟人聊起这个事，他告诉我因为系统很慢，所以只好再增加一组自助终端，业务忙的时候开起来。我当时就很奇怪，既然已经增加了一组终端，为什么平时不开。他说这也是无奈之举，那组终端开了，系统就更慢了，实际上总体来说也快不了多少，只是能让排队的每个队伍短一些而已，所以平时排队不是很长的时候，那组终端是关闭的。

事实上，对于核心业务系统的问题，企业都是十分关注的，只是解决问题采用的手段不同而已。对于大多数传统企业的核心业务系统的问题，很可能都与数据库的性能有关。特别是HIS之类的结构比较简单的系统，大多数HIS系统都是PowerBuilder开发的应用，后面连了一个Oracle或者sql server数据库。企业的核心系统的核心模块往往都是比较稳定的，只要确保这些核心模块的性能稳定，就能够保证核心系统数据库的性能稳定。对于核心系统的核心业务模块，花点功夫去保证其性能稳定还是十分有价值的。

回到我们今天的正题，如何才能确保核心业务系统数据库的性能稳定呢？我们能够通过哪些花费不多的小技巧来确保核心业务系统的数据库性能稳定呢？其实我们只要重点关注三方的要素，就可以基本上保证核心系统数据库的稳定了。这三方面分别是：1）关键业务模块SQL执行计划的稳定性；2）数据库服务器的IO延时稳定性；3）保证足够的物理内存。

首先，确保核心业务模块SQL执行计划的稳定性。数据库应用的突发性性能问题很多都是与执行计划的变化有关的。本来运行的很好的SQL突然变慢，大多数情况下是与执行计划的变化有关的。对于很多大企业的核心系统，在开发的时候，就对核心交易的SQL做了十分严格的代码走读，也规定了核心业务系统不能使用过于复杂的SQL，甚至在某些银行，规定关键业务系统的核心交易相关的SQL不允许使用多张表关联的语法。通过SQL语句的优化，可以解决大多数SQL执行计划突变的问题。

另外一个确保执行计划稳定的原则是针对核心业务相关的表的索引要做规范的设计，不允许这些表上的索引乱用，系统上线后不允许在核心业务表上随意建新索引。一张表上有多个相似的索引是引发错误执行计划的常见因素，我们也遇到过多次因为新建一个索引而导致核心业务系统性能受到影响的案例。

制定合理的数据归档计划，定期归档核心业务数据，确保核心业务数据表的容量缓慢线性增长是确保核心业务系统性能稳定的另外一个好的方法。在二十多年前，银行用户就看到了核心业务表数据增长对性能的重大影响，因此都设计了十分完备的核心业务数据转储与归档的方案。这三十年的实践表明，这个方法是十分有效的。

定期重建索引对于稳定核心业务模块的执行计划和提升关键业务模块的性能的效果也是十分好的。十多年前，我给一家银行做维保服务的时候，向他们的IT部门领导提出了这个观点。刚开始虽然他们不太相信，不过依然做了一次尝试。我们利用一个周末的晚上对所有核心业务相关的表上的索引做了一次rebuild，第二天统计出来的核心交易时间证明了，这次操作让第二天的平均核心交易时间缩短了20%，从此他们就把这项工作做成了一个定期任务，每隔三个月做一次。这十多年坚持下来，效果十分不错。

与第一个问题相比，确保IO延时稳定性的问题，大家可能考虑的并不多。现在大部分核心系统的存储系统较十多年前都有了巨大的性能提升，往往核心存储的能力是足以支撑核心业务的。不过持续监控核心业务系统的IO延时，确保其稳定维持在合理的范围内依然是十分重要的。从数据库角度、操作系统角度和后端存储角度三方面监控核心系统IO延时，一旦延时出现异常增长，则尽快找到原因，解决问题，对于确保核心系统性能也是十分关键的。十年前，一个银行客户升级存储系统，更换新存储的时候因为成本问题，把磁盘从老的3.5寸的15000rpm SAS盘换成了2.5寸的10000rpm的SAS盘。新系统上线那天，业务部门发现日结操作的时间下降了50%，最后经过分析，发现就是因为10K的SAS盘的IO延时比15K的高30%左右，导致了日结业务的问题。发现问题的根源后，解决问题的方法也就容易制定了，临时性的方案是扩大DB CACHE，减少IO的总量，最终的方案是在本存储上增加一组SSD盘，把和日结相关的数据放到新的磁盘组上。要确保IO延时的稳定性，一定要加强对IO延时的监控工作，从数据库、操作系统和存储端口三方面去监控IO延时，任何一方面出现问题都给予足够的重视，找出问题的原因，是确保核心数据库系统性能的又一个重要的工作。

确保操作系统有足够的物理内存，不会出现大规模，长时间的换页是确保核心系统性能稳定的另外一个十分重要的工作。很多用户只要配置了足够的物理内存就不太关注这个问题了。实际上，随着我们系统的变化，哪怕配备了足够的物理内存也不一定能保证我们的系统不换页。几年前遇到过一个银行客户，他们的系统经常在业务高峰期出现性能抖动，原本100毫秒以内完成的核心交易，在性能抖动时高达7/800毫秒。经过电话的沟通，我把问题定位到换页上，他们也觉得奇怪，系统有512G的内存，SGA配置了240G，会话数量也不多，怎么会出现这么严重的换页呢？后来我们发现最近他们做过一次优化，优化厂商建议他们对SGA的扩容，从200G扩充到了240G。于是我让他们用svmon分析下物理内存的使用情况。原来问题十分简单，他们设置了200G多点的LARGEPAGE，SGA从200G扩容到240G后，LARGEPAGE不够用了，于是SGA没有使用LARGEPAGE，而以前配置的200G LARGEPAGE又不能被普通的ORACLE进程使用，于是512G的物理内存被废了200G，当然就经常会出现换页了。