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的SQL优化器分为两种，基于规则优化（Rule based optimization）和基于成本优化（Cost based optimization）。先执行基于规则优化，然后执行基于成本优化。 规则优化是一个串行的优化过程，而成本优化是在规则优化之后，并发多种可能并记录最优的那个。基于规则优化是宏观层面的，容易预测到的。而基于成本优化更像是微观层面，会充满变化。基于规则的优化将会基于HANA内置的优化规则重写整个执行树，比较经典的比如：上提select -> 移除多余列 -> 下

在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

HANA SQL的执行过程与其他关系型数据库大同小异，区别不大，记录如下。过程如图：Session第一层为会话层，新的事务和工作线程在这一层创建。SQL FrontendSQL前端层，SQL语句在这一层进行检查和解析。这时SQL语句会被解析成编译器能理解的语句，并进行语法检查。同时也能检查到用户是否有权限执行此语句。这一层会生成语句优化器对象。Query Optimizer语句优化器层处理上一层生成的语句优化器对象，也称作QO tree。...

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

HANA关于数据传输这一块可选的工具还是比较多的，有点乱，基于自己的理解做个记录。比较容易搞混的两个：Smart Data Access：本质上类似于快捷方式，在目标库中创建virtual table，指向源库的表。没有数据拷贝。Smart Data Integration：本质上是复制，将源库中的表复制到目标库。有数据拷贝。这两个技术是hana自带的，也只是HANA数据库才有的概念。而不只限于HANA的通用技术还有SAP DS和SAP SLT。DS：通用的ETL工具，主要实现的就是ETL的功能了

最近在做集成的管理服务器，目标是将所有应用的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系统的