可以设置 gp_resource_group_queuing_timeout 参数来指定事务排队的时 间长度，超时之后，数据库将 cancel 该事务，该参数缺省值为 0，意思是排队时间长 度没有限制，编者认为，这个参数可能一般也不会用到，因为编者想不出在生产环境中， 什么情况下，需要把排队的事务因等待时长的原因而自动 cancel 掉。 CPU 配额 通过 对聚集索引字段的单条件查询的性能会更高效。 在 GP 中使用聚集索引 对于大表来说，使用CLUSTER(该命令只可以作用于Heap表)命令来排序物理记录 以创建聚集索引可能需要耗费极长的时间。要快速达到同样的效果，可以通过创建一张 中间表的方式来手动排序数据，由于CLUSTER命令只能用于Heap表，对于AO表，要达 到聚集索引的效果，也只能通过数据排序插入的方式实现。例如： 最大值，得到一个不大于1的浮点数，值越大倾斜越严重。不过，在获取表的信息 时与gp_toolkit.gp_skew_coefficients视图是一模一样的，所以，没有性 能优势。 编者来说说自己的实现，不去轮询查询每张表的信息，因为这些系统视图性能极差 的根本原因是，都要循环获取每张表的信息，尤其是表的数量很大的时候，每个表的信 息获取都会变慢，Heap表的 count(*)操作更是致命的。我们的目的是检查倾斜情况，

航线 分析 结算 系统 呼叫 中心 其他 航线 分析 结算 系统 呼叫 中心 BO报表响应速度 BO报表响应速度测试： 报表名 Oracle查 询时长 Greenplu m查询时 长 GP提升倍数 备注 报表一： 查询09年1月份数据 无法响应 查询 30秒 N 基于查询 语句 SQL1 报表一： 查询09年5月份数据 49秒 N 同上 报表二： 查询09年1月份数据 40秒 算的响应 速度。 测试方法：针对数据加载测试中的三张大表，模拟生产业务需求进行复杂SQL语句查 询(参看附录)。 测试结果如下面两表： 语句名 Oracle查 询时长 Greenplu m查询时 长 GP提升倍数 备注 SQL1 1800秒+ 33.16秒 54X+ SQL2 A 1800秒+ 17.49秒 105X+ SQL2 B 1800秒+ 15.97秒 112X+ 案例分享：深发展银行

greenplum会变成只读，不能写了。如果模式是 “continue”模式时，一个segment坏了的时候，数据 库仍然可以继续工作。但由于segment的primary与 mirror端的数据不同步了，所以恢复的时候需要花比较 长的时间。对于Greenplum 3.X的版本，恢复时，需要 把好的节点上的所有数据都copy到坏的机器上。而 Greenplum4.0版本增加了功能，当备份节点坏的时 候，主节点可以把增量数据记下来，这样当备份节点的

Center，是否有报警信息  检查standby同步状态 – 执行gpstate -f  检查Primary、mirror同步状态 – 执行gpstate -e  检查运行时间长的SQL – select*from pg_stat_activity order by query_start，检查是否有3~6个小时以上的SQL仍在运行  检查空间使用情况 – gpssh