sap hana 大数据表的分区操作

       检查hana数据库时，发现存在几个警告， 提示CKIS/CKIT这2个表有大约15亿数据，mldocccs有14亿数据，都接近21亿的限制，需要进行分区处理。由于这几个表是sap应用的表，并非自开发的表。在询问sap之后，他们表示没有针对前2个表的分区建议；也很少遇到这2个表数据量如此之多的现象。相反针对mldocccs， 有明确的建议，使用hash在DOCREF上进行分区。sap应用层面没有分区建议，在数据库层面，sap给出了一些分区的文档，为了稳妥，我详细阅读了这些文档。同时从其他实施商那里了解了一些有关前2个表的处理经验。sap在接入系统，检查了一下ckis/ckit的数据， 给出了初步的建议。

       综合来看， sap建议是：

1.  检查为何ckis/ckit数据为何如此之多。

2.   执行数据的归档.

3.   执行数据分区。当然分区的具体方法和在什么列上分区， 没有给出明确建议。至于分区后性能受到的影响，有不确定因素。但从数据库的角度来说， 没有收到反馈分区之后性能受到影响的案例。

      而其他实施商表示，确实有客户有这个表数据量大， 采用分区之后， 没有明确反馈性能受到影响。

      结合sap同事对sap建议的态度， 最终我们决定使用分区来解决目前遇到的问题。通过复制这3个表的数据，设置同样的表结构，主键，索引等，建立实际测试。观测使用offline分区和online分区时，分区所需要的时间，分区时数据库行为，分区产生的日志，对备份的影响。试验中并发了少量修改，插入，删除操作，同时试验了大数据量插入操作，以便观测各种行为是否产生影响。以及分区时产生的锁定现象。

        经过试验之后，最终决定使用online分区来实现这3个表的处理。记录操作大致如下

alter table CKIT PARTITION BY HASH (KALNR) PARTITIONS 2 online;     耗时6000秒，产生日志大约240G。

alter table CKIS PARTITION BY HASH (KALNR) PARTITIONS 2 online;  耗时大约11000秒，产生日志大约1.3T

alter table MLDOCCCS PARTITION BY HASH (DOCREF) PARTITIONS 2 online; 耗时大约9600秒，产生日志大约200G。

可以观测到分区过程中使用复制来实现，同时可以观测到复制之后，触发了data merge现象。总体来说， 如同试验中的观测和sap手册中的描述，没有看到对生产的影响。仅有一个小插曲，在操作ckis时，由于其他因素导致putty终端断开，导致分区执行长时间之后失败，奇怪的是失败后在alert中的提示是某种内存分配失败。重新执行分区后，正常成功。

      总结和oracle分区操作的不同，大致有下面2点

1.  和oracle分区概念（或实现原理上）的差异， oracle分区之后，实际存在不同的segment,保存在不同空间管理结构中，同时也导致索引产生了global index 和local index的区分，但hana结构中这方面介绍不多，或许是我自身hana知识欠缺的原因。尤其是hana在分区之后，索引产生的相关变化，sap工程师也不了解，仅仅笼统的说，没有相关文档。由于索引是树形结构，用于在查询中快速定位符合条件的数据，或许在列式数据库的方式下， 索引已经有了一定的特殊性，与oracle的行式存储有较大不同。

2.  操作上的差异，在oracle中，如果需要分区，实际涉及了在线段重组。相比较而言，hana的分区操作相对简单，通过alter table中的分区子项操作。分区和取消分区，以及分区调整，操作相对简单。