core文件是进程由于各种原因导致crash而产生。
core文件的大小由当时程序占用的内存空间决定，因为他要dump程序的整个内存空间的内容。
core文件可以删除。但在删除之前，需要确认这些crash的原因、状况是否已经记录。

查看方法：
以查看gclusterd的core文件的方式为例（其他程序crash的查看方式类似）：
gdb /opt/gcluster/server/bin/gclusterd /opt/gcluster/userdata/gcluster/core文件
然后执行：thread apply all bt得到宕机堆栈。
同时查看/opt/gcluster/log/gcluster/system.log文件，这里面一般情况下都能记录到宕机堆栈以及宕机SQL。

init表示SQL进入准备执行阶段，也就是执行计划开始
deleting from main table/updating main table准备对表做delete或update操作
end/query endSQL进入结束阶段，准备清理资源
Creating tmp table查询过程中，正在创建临时表
Sending data正在向客户端发送查询结果
closing tables关闭打开的表
Evaluating执行计划评估
Executing by step逐个执行计划的每个Step
Preparing metadata取得本查询所涉及表的可用节点信息
Creating tmp tables创建临时表
Sending task to gnodes发送task 给gnode
Clear tmp tables查询完成，清除临时表

GBase8a产品在设计时定义为“不支持字段定义的修改”，因此无法通过alter table … modify … 语句修改字段的定义。
但可以通过如下替代方案实现（以tds表字段id1由varchar(50)修改为varchar(100)为例）：
（1）alter table tds add id2 varchar(100);
（2）update tds set id2=id1;
（3）alter table tds drop id1;
（4）alter table tds change id2 id1 varchar(100)。
GBase8a产品支持针对varchar数据类型的长度修改，允许将varchar类型的数据长度扩大。

数据分布均匀是保证GBase 8a MPP Cluster高效并行处理能力的基础。
因此定义表时，如何选用HASH分布策略，保证数据分布均匀是获取高性能的关键所在。
选择的依据遵从四大原则：
第一，首先保证所有节点数据存放是均匀的，避免出现节点出现数据分布过多或过少情况；
第二，如果经常进行大表连接，尽量把连接字段定义成hash分布字段，这样尽量减少无效的节点间拉表操作；
第三，尽量保证where条件产生的结果集的存储也尽量是均匀的，避免在做查询的时候，出现某些节点过于繁忙或清闲的情况；
第四，选择使用频率高的group by字段作为hash字段。

SCN(System Change Number)是操作的序列号，引起数据变动的操作（DDL，DML等）都会引起SCN的变动。rename table后SCN会增加。SCN可以通过information_schema.tables的scn列查询，最大值也可以查到（使用max函数）。
目前的主要作用：不同节点间同步数据时判断数据是否不一致的一个依据。