psy7585的博客

今天查看expensive statement的时候发现了一些监控语句，执行时间大于1秒钟，语句如下：select count (*) from ME_WIP.ACTIVITY_LOGwhere DATE_TIME > add_seconds(localtoutc(now()), -1800)这条语句的目标是查看最近30分钟生成的日志条目数。重复试了几次，执行时间在800ms到1秒钟上下。这条语句不复杂，似乎没什么调优空间。先尝试直接执行 select count (*) from ME_W

在HANA中获得执行计划，可以选择在HANA Studio中通过右键语句选择获得执行计划的方式，但是这样有个问题，就是这个生成的执行计划是一次性的（无法重新访问，只能重新生成）。通过SQL plan cache，只要这个缓存还在，就随时可以重新访问。使用语句如下：SELECT "PLAN_ID"FROM "M_SQL_PLAN_CACHE"WHERE "STATEMENT_STRING" LIKE '%<part of the SQL statement string>%';EXPL

最近遇到了SQL plan Cache 相关的问题，整理分析思路与使用工具如下：在HANA Minicheck中，发现SQL cache相关的问题项：问题描述：从Minicheck报告中可以看到，retention time（一条SQL缓存在内存里保留的时间）远远小于标准值，同时有大量的缓存失效(eviction)。问题分析：首先要弄清楚缓存失效的原因，使用SELECT LAST_INVALIDATION_REASON ,COUNT(*) FROM SYS.M_SQL_PLAN_STATISTIC

最近在做集成的管理服务器，目标是将所有应用的cleanup脚本放在一起统一管理，避免当脚本有变动时需要一台一台去改cron job。本文覆盖的是HANA数据库相关的脚本。目前的脚本有两个功能，一是调用HANACleaner这个清理工具（非官方，需要额外下载该python程序），主要用来清理旧的trace文件；二是运行SQL语句，用来清理存放在数据库中旧的应用日志。有关HANACleaner：https://github.com/chriselswede/hanacleaner首先管理服务器上要安装好H

在对HANA做troubleshooting的时候，会遇到类似这样的问题：某个告警出现的频率比较低，出现几个小时之后会自动恢复，想要了解这几个小时之间发生了什么，SAP支持又要求提供在问题发生期间的runtime dump。这个就比较讨厌了。为了解决这个问题，写了个小脚本，通过在OS层面调用hdbsql实现，代码如下：#!/bin/bashhdbsql -U <hdbuserstore name> "select count(*) from "_SYS_STATISTICS"."STAT

关于SQL语句的性能分析，本文中仅从运维角度出发，并不包括SQL语句的优化分析，如执行计划，visualize plan的分析等（嗯，实在不敢献丑，再学习学习的。。。）首先是Performance页面里的两个tab，SQL cache 和 Expensive Statements。如性能分析的第一篇提到的，这个页面不太灵活，反应也很慢，还是直接用SQL语句查询具体视图比较好。当然，利用SAP NOTE 1969700中的SQL语句也可以获取相关信息。SQL Cache 分析先上参考Note:25

最近一直在做一些HANA性能分析的东西，觉得还是缺乏系统的指导，读一些文档，记一记笔记，翻译过来共同学习。主要记录一些用于分析的工具，或者是系统视图表的功能。整体来讲，Performance页面不是很好用，反应比较慢，而且可做的筛选和SQL语句没法比，还是看这些相关视图比较灵活。SAP还开发了一些语句来帮助判断系统运行状态，参考SAP Note 1969700。分析系统性能时，首先打开管理工具HANA Studio的Performance界面，查看如下几点：在thread页面，检查多少线程正在运行，他

文章目录前言6.12 HANA负载管理6.12.1 SAP HANA 上下文负载6.12.1.1 负载管理方式6.12.1.2 理解你的负载6.12.1.3 分析系统表现6.12.2 控制CPU消耗前言HANA的中文资料比较少，尝试总结一部分HANA相关的文档，过程中发现SAP的文档真的是废话连篇。。。写文章的大概率是按字数收稿费的，正好提炼一下吧。本文章内容基于help.sap.com中SAP HANA Administration Guide6.12 HANA负载管理SAP HANA系统的