SAP

问题解决之 HANA数据库行表访问性能下降

2021-07-16  本文已影响0人  syjf1976_abap

点击蓝字 关注我们

问题描述

运行一段时间后,生产系统每天上午都很卡,表现为:

过2-3个小时后,系统趋于正常.

一般情况下,上述系统无响应的原因可以通过查看系统是否有空闲进程来判断原因.实际检查时发现(TCODE:SM50/SM66),系统还有大量空闲进程.

那基本上问题可以确定在数据库服务的响应上.因为所有无响应的事务都有一个共同点, 需要查询数据库.

问题分析-进程概览

系统进程大量卡在访问队列或后台作业相关的表(TCODE:SM66),如图一

图一

问题分析-归纳

这些表都是与后台作业或队列相关的表.

发现系统响应很慢. 尤其时队列情况. 入站队列只有2000个左右, 但是SMQ2查询需要10分钟或更久.

DB02中查看表的情况: 索引占用空间远大于表占用空间(考虑删除索引后重建索引). 如图二

这些表还有如下共性

注意到这些表是行存储的表. 基于从前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 根据版本不同, 有多种方式处理

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

约定

上一篇 下一篇

猜你喜欢

热点阅读