点击蓝字 关注我们
一
问题描述
运行一段时间后,生产系统每天上午都很卡,表现为:
执行简单显示事务系统无响应
登陆无响应
简单查询语句无响应
过2-3个小时后,系统趋于正常.
一般情况下,上述系统无响应的原因可以通过查看系统是否有空闲进程来判断原因.实际检查时发现(TCODE:SM50/SM66),系统还有大量空闲进程.
那基本上问题可以确定在数据库服务的响应上.因为所有无响应的事务都有一个共同点, 需要查询数据库.
二
问题分析-进程概览
系统进程大量卡在访问队列或后台作业相关的表(TCODE:SM66),如图一
TRFCQIN
TRFCQOUT
ARFCSSTATE
ARFCSDATA
ARFCRSTATE
QREFTID
TRFCQDATA
TRFCQSTATE
TSTCS
TSTCY
TSTCP
图一
三
问题分析-归纳
这些表都是与后台作业或队列相关的表.
进一步查询队列情况(TCODE:SMQ1/SMQ2)
进一步查询后台作业情况 (TCODE: SM37)
发现系统响应很慢. 尤其时队列情况. 入站队列只有2000个左右, 但是SMQ2查询需要10分钟或更久.
DB02中查看表的情况: 索引占用空间远大于表占用空间(考虑删除索引后重建索引). 如图二
这些表还有如下共性
行表存储(通过TCODE SE11->技术设置可以看到如图三
表里的当前记录不大(使用完就会被删除)
注意到这些表是行存储的表. 基于从前ORACLE数据库的经验,行存储的表删除的条目还是会占用磁盘空间. 需要通过重组(类似于从前机械硬盘年代的磁盘重组)释放空间.HANA中的行表是否也可以通过 REORGANIZATION 来优化?
图二
图三
四
问题分析-一个优化方案
查询NOTES 发现了一个优化上述相关表访问的NOTES
查询到NOTES: 2700051 - Delivery of Statement Hints (SAP HANA >= 1.00.122.03)这个NOTES中提到对一些查询指定索引.
目前TRFCQIN等表中的记录不大, 但是查询很慢.
NOTES 2700051实际上是指定一些查询语句使用特定的索引来优化查询结果. 使用后没有效果.
五
问题分析-重组行表
带着这个问题通过关键字 REORGANIZATION查询了NOTES
查询到NOTES 1813245 - SAP HANA Row Store Reorganization
通过NOTES 1813245 得知
HANA行表的reorganization 根据版本不同, 有多种方式处理
重启数据库会触发离线重组
在线重组 HAHA2 SPS00->SPS03
在线重组 HANA2 >=SPS04
HANA数据库的版本可以通过GUI菜单->系统->状态查看
六
问题分析-检查HANA状态
参考下面这个NOTES 检查表 CALL CHECK_TABLE_CONSISTENCY('CHECK', 'SAPABAP1', 'TRFCQIN'); 返回空信息
1977584 - Technical Consistency Checks for SAP HANA Databases
七
问题的解决
重启数据库自动触发
offline row store reorganization 解决问题
同时表的索引问题也得以解决
八
总结
特定版本的HANA系统(不确定最新版本的是否还有这个问题)对于频繁删除的行表 (比如后台作业相关表或队列相关表),没有定时重组表.
导致该表占用过大的空间(删除后的记录任然占用了空间),同时影响了表的查询性能并且占用了大量的数据库服务器资源.
生产系统每天早上都有大量的接口传递到S4系统处理, 这些处理同时启用队列及后台作业. 导致大量数据库资源被占用,无法响应一些新的简单查询. 导致系统异常卡顿.
重启数据库后,触发了系统的重组行表机制,解决了问题.
但是因为生产系统数据库不能总是通过重启解决问题,所以最终解决办法还是需要通过升级数据库, 或者定时通过脚本在线重组行表实现.
参考NOTES: 1813245
THE
END
约定
