系统变慢，竟然与数据库的这个设置有关！

我有个朋友，公司有套业务系统之前出了点小情况，驻场分析认为是研发代码存在问题。

但这两天问题反复出现，驻场进一步分析后，发现坑还是在最开始项目投产时埋下来的。

在征得我朋友的同意后，我把相关内容发出来。

问题分析

从数据库层面分析，发现有慢SQL，并且这些都是INSERT/UDPATE语句。

这类语句执行时间很长一般有两种原因，一是事务提交延时，二是磁盘性能低导致写入慢。

通过与研发人员沟通，用户登录需要等待发送短信，发送完短信后才会提交，因此INSERT语句是存在延迟提交的，这块没有问题。

针对UPDATE语句执行时间长的问题，通过检查执行计划和缓存中执行计划对比，都没有问题，即执行计划并没有出现异常导致SQL执行变慢。

那么，只有磁盘写入慢或者未及时提交才会出现这种情况。

但磁盘写入并不慢，研发也确认了没有不及时提交的代码。

问题究竟在哪？

问题定位

查询V$SYSTEM_EVENT视图发现，存在大量数据文件扩展事件等待。

观察表空间使用率，发现其中两个表空间均已达到99%以上。 并且表空间创建语句中，数据文件设置了自动扩展，但缺省值为1MB。

当业务高峰期有大量数据插入更新时，一次扩展的1MB无法满足写入的空间要求，这样就会出现连续扩展的情况，

每一次扩展都需要向操作系统申请系统资源，在这期间insert、update语句需要等待扩容完成才能进行提交。

解决方案

将数据文件自动扩展改为2048M，这样会大大降低自动扩展频次，在业务高峰触发自动扩展几率会大大降低。

在之前的监控过程中，工程师还发现了另外一个问题，也有可能会导致延迟提交。

应用端的驱动版本与数据库版本不符。

这个问题也已通知研发去更换应用端的数据库驱动包了。

注意

❝

在使用达梦数据库时应创建单独的表空间给应用端，否则默认会使用系统表空间，而系统表空间自动扩展就是1M，无法更改。