greenplum维护中的一些技巧

1.如果能用greenplum3.3.X，就不要使用greenplum4.X。
原因： a. greenplum4.x看起当primary节点出现问题时，可以切换到mirror节点，继续提供服务，当mirror节点恢复后，可以做增量同步。增量同步是一个大的亮点。
但实际上，greenplum4.x大量的的bug导致的的不稳定完全抵消了这个优点。当机器内存紧张时，mirror经常与主库不同步。而每次不同步后要做停库恢复，当数据库比较大的时候（如50T以上时），每次同步的时候经常需要2个小时以上。
同时greenplum4.x的primary节点与mirror节点是通过物理块同步的。如果因为软件bug把主库搞挂了，那么即使切换
到备库上，备库也一样起不来。而greenplum3.3.x是通过逻辑同步的，也就是把DML和DDL同时发到primary和mirror执行，这样即使软件有bug导致primary起不来，切换到mirror还是可以起来的。


2.当GP4.X 由于如内存耗尽等原因hang了之后，停数据库时，最好不好直接使用gpstop -af命令直接停整个数据库，按下面的步骤将安全很多：
a. 每一步，先停master:　gpstop -amf，或gpstop -am -M immediate
b. 再启动master: gpstart -am
c. 最后再gpstop -af
这个操作的核心是先把master给停掉。在greenplum异常hang住后，如果按标准的gpstop -af，很可能出现数据不一致，数据库无法启动的问题，这可能是greenplum的bug，我就遇到几次这样的问题，停库后，数据库无法启动，报一些xlog错误的问题，让EMC的专家上来也无法把数据库搞起来，还好我们在文件系统上有快照，最后把文件系统闪回到2个小时前的快照上，数据库才正常打开。后来使用这个操作步骤，这个问题就再也没有也现过。


3.关于GP的分区表
a. GP宣称支持无限级分区，但实际上使用中，最好只用一级分区。另对小表最好就不要做分区了。GP本身就是在机器间做了数据水平拆分了，所以使用一级分区后，单个表的大小就不会很大。在greenplum和ＰostgreSQL中，分区实际上并不是真正的分区，而是通过表继承来实现的。每个分区实际上是一个单独的表，而每个表都是一个单独的文件，当访问这个表时，即使只访问其中一个分区，但在生成执行计划过程，greenplum会这个分区表所有分区的文件，还会地每个分区表做pg_relation_size()操作，这样就会变得很慢。
b. 如果是一张包括几百个分区的分区表，如果业务逻辑可以直接查询分区表，那么直接查询分区表吧，这样会快很多，原因同上。
   例表：mytable，分区键为mydate，下面的SQL
   select * from mytable where mydate='2012-03-08'
   换成：
   select * from mytable_1_prt_p20120308;
   则性能会更好。
c.　尽量不要有空分区，原因同上。


4.关于GP的统计信息
由于greenplum执行SQL的方法是先在master上把执行计划生成好，
然后再发到底下的各个segment节点上执行，所以一般情况下统计信息只在master上有用，而在segment没有太大用处。
GP是由下面的两个参数为控制统计信息的收集的
gp_autostats_mode
gp_autostats_on_change_threshold
gp_autostats_mode参数可以取的值有三个：
none
on_change
on_no_stats
当设置为“none”为禁止收集统计信息，而设置为"on change"时，当一条DML执行后影响的行数超过gp_autostats_on_change_threshold参数
指定的值时，会执行完这条DML后再自动执行一个analyze 的操作来收集表的统计信息。
当设置为“no_no_stats“时，执行完DML语句后，发现这张表没有统计信息，会自动执行analyze 来收集这张表的统计信息。
greenplum4.x的analyze的执行方法与greenplum3.x的方法是完全不一样的。
greenplum3.x的方法是把analyze 语句直接发到各个segment上。
而greenplum4.x的analyze实际上是在master上直接执行很多个收集统计信息的SQL来收集统计信息的。
从实际的使用中看，greenplum3.x的方法的性能好，而greenplum4.x的性能比较差。原因是greenplum4.x在master上发SQL，
这些SQL由于有group，所以会发数据重分析，即使数据很小，重分布总是会需要更长的时间，而greenplum3.X是把analyze语句直接发到segment上，
没有重分布，因而性能要好很多。
所以对于greenplum4.x上，如果你有大量的运行时间在1分钟以下的SQL，你会发现大量的时间消耗在收集统计信息上。
为了降低这一部分的消耗，你可以需要在建表时就明确把一些不需要收集统计信息的更去除掉，如下所示：
create table test(id int, name text,note text);
上面是已知道表列note不需出现在join列上，也不会出现在where语句的过滤条件下，因为可以把这个列设置为不收集统计信息：


alter table test alter note SET STATISTICS 0;


由此可见greenplum4.X收集统计信息的方法也是一个看上下很美感，实际上很差的方法，