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。
对于/opt/gnode/server/bin及/opt/gcuster/server/bin路径下的程序文件，通过-V或--version选项可以查询到该组件的版本信息；
[root@zhfx1 /]# rpm -qa | grep gcware
gcwarelib-1.2.9-14.el6.x86_64
gcware-1.2.9-14.el6.x86_64[root@zhfx1 /]# gccli -uroot
gbase> show variables like '%version%';
+-------------------------+-------------------+
| Variable_name | Value |
+-------------------------+-------------------+
| gcluster_hash_version | 1 |
| protocol_version | 10 |
| version | 8.5.1.2 |
| version_comment | 24466 |
| version_compile_machine | x86_64 |
| version_compile_os | unknown-linux-gnu |
+-------------------------+-------------------+[root@zhfx1 /]# gncli -uroot
gbase> show variables like '%version%';
+-------------------------+-------------------+
| Variable_name | Value |
+-------------------------+-------------------+
| protocol_version | 10 |
| version | 8.5.1.1 |
| version_comment | 1.5.8.24010 |
| version_compile_machine | x86_64 |
| version_compile_os | unknown-linux-gnu |
+-------------------------+-------------------+[root@zhfx1 /]# /opt/gnode/server/bin/gc_sync_server --version
[root@zhfx1 /]# /opt/gnode/server/bin/gc_sync_client --version
VERSION
8.5.1.2.4.4.22341.17099[root@zhfx1 /]# /opt/gcluster/server/bin/gcdatarecover --version
/opt/gcluster/server/bin/gcdatarecover Ver 8.5.1.2 for unknown-linux-gnu on x86_64 (24466)
[root@zhfx1 /]# /opt/gcluster/server/bin/gcmetarecover --version
/opt/gcluster/server/bin/gcmetarecover Ver 8.5.1.2 for unknown-linux-gnu on x86_64 (24466)[root@zhfx6 dispatch_server]# ./dispserver --version
version: 1.1
svn revision: 22340
zeromq version: 2.1.4[root@localhost ~]# /opt/gnode/server/bin/gbloader -V
/opt/gnode/server/bin/gbloader Ver 8.5.1.2.build26588 for unknown-linux-gnu on x86_64init表示SQL进入准备执行阶段，也就是执行计划开始 deleting from main table/updating main table准备对表做delete或update操作end/query endSQL进入结束阶段，准备清理资源Creating tmp table查询过程中，正在创建临时表Sending data正在向客户端发送查询结果closing tables关闭打开的表Evaluating执行计划评估Executing by step逐个执行计划的每个StepPreparing metadata取得本查询所涉及表的可用节点信息Creating tmp tables创建临时表Sending task to gnodes发送task 给gnodeClear 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字段。