HANA运维讨论
伴随着SAP进一步强调HANA，CRM/ERP for HANA，suite on hana势头看上去还是很猛烈的。但与之而来的HANA的运维及优化成了BASIS的一大拦路虎，SAP support其实是很不给力的，90%以上的message基本上都是泥牛入海（因为我们不是XX计划的成员之一，也不是超级大企业，所以一般都不怎么重视），为此，我们也很恼火，特开个帖子讨论一下，看看大家都是如何来做HANA运维的。
我先说说我这边的基本情况：
CRM for HANA，ECC for ORACLE，OLTP业务，7*24小时提供不间断服务。
1.5T HANA，双机热备。
常见故障/难点：
1.无故宕机，服务器直接被重启；
2.hana无故hung住，服务直接挂起；
3.CPU突然飙升，近100%；
4.HA切换时间较长（10分钟左右），业务延续性不好。
5.程序性能优化点寻找较难，不易定位；
6.大表增长较快，SAP标准清理方案难于执行，例如CDPOS，CRM_JCDS
总之，相比较ORACLE而言，成熟度差距较大，目前可能更适合OLAP等对业务延续性要求不太高的业务。
问题1,2经过1年的线上磨合，不断的升级HANA版本，SUSE内核，各种硬件微码后，已陆续解决。
问题3一般是由于程序引起的，与问题5合并，我们目前的解决方案是打开hana的expensive statements trace后进行跟踪，辅以sdat，sm66等信息对效率低下的程序进行定位并优化，目前已进入良性循环。
问题4,6暂时无解。message sap 也基本无解，期待同行们提供解决方案。
4同行回答
问题4：这个是ha的配置方式问题，目前除了oracle的rac外，其他的ha切换均存在这个问题，有些甚至达到了十分钟的切换时间；
问题6：这些表是日志表，要根据你的业务配置日志级别，并且要在job中定义归档job进行处理
收起HANA HA可用hana的集群方式，0切换时间的，不过就是需要的机器比较多，顾问说要3台，我觉得至少要4台（gpfs方式），3台hana数据库+1台gpfs的仲裁节点。
收起HA用的suse的hae吗？还是直接system replication？如果只是replication可以调整两个参数来加快接管性能，1.delta data sysc间隔设置小于10min 2.日志的量可以小，保证接管的时候redo的量越少越好。
cpu的飘红的问题，可以设置并发参数，比如num cores 或者max concurenc等，来避免单个sql引起的hang机情况 或者设置cpu affinity来保证index不会全部使用cpu。
无辜宕机，估计是crash，除了指望sap在下一版本解决，只能workaroud。
性能优化可以expensive，但是记住hana会定期清理。还有就是plan cache里面保留了大量的性能指标性能。至于优化，，可视化执行计划，performance trace，kernol profiletrace，sql trace多的很。建议使用performance trace 搭配HDBAdmin分析。
收起