现象描述：
综合办公平台近两周出现响应慢，部分用户 WPS文件无法打开等情况。从数据库层面分析，发现有慢 SQL，并且这些都是 INSERT/UDPATE 语句，这类语句执行时间很长有 2 种原因，一是事务提交延时，二是磁盘性能低导致写入慢。

通过与应用人员沟通，用户登录需要等待发送短信，需要发送完短信后才能执行提交，INSERT 是存在延迟提交的；针对 UPDATE 语句执行时间长的问题，通过检查执行计划和缓存中行计划对比，都没有问题，不会因为计划异常导致SQL 执行慢，只有磁盘写入慢或者未及时提交才会出现这种情况。通过 DEM 监控发现有大量 UPDATE 语句阻塞存在。
继续查询 V$SYSTEM_EVENT 视图发现，存在大量数据文件扩展事件等待。当数据落盘并且表空间不足时才会发生数据文件扩展，这样就会导致 update、insert 执行慢。

继续分析，观察表空间使用率，发现 EKP 和 KK 表空间均已达到 99%以上。
并且表空间创建语句中，数据文件自动扩展为缺省值 1MB。

数据文件文件开启自动扩展缺省值为 1MB，当业务高峰期有大量数据插入更新时，一次扩展的 1MB 无法满足写入的空间要求，这样就会出现连续扩展的情况，每一次扩展都需要向操作系统申请系统资源，在这期间 INSERT,UPDATE需要等待。

解决方案：
将数据文件自动扩展改为 2048M，这样会大大降低自动扩展频次，在业务高峰触发自动扩展几率会大大降低。
新加一个 100GB 大小的表空间，开启自动扩展 2048M，把前面两个数据文件的自动扩展关闭；
alter tablespace “EKP” datafile ‘ekp1.dbf’ autoextend on next 2048 maxsize 67108863;
alter tablespace “EKP” datafile ‘ekp2.dbf’ autoextend on next 2048 maxsize 67108863;
alter tablespace “KK” datafile ‘kk1.dbf’ autoextend on next 2048 maxsize 67108863;
alter tablespace “KK” datafile ‘kk2.dbf’ autoextend on next 2048 maxsize 67108863;
之后该系统阻塞问题再没有发生过。