Turk的专栏

post by osdba / 2011-8-13 22:05 Saturday 情况一： 当一台segment机器坏了，然后机器又恢复了，或某一个segment数据库停了 只需要运行gprecoverseg，就可以把segment恢复过来： gprecoverseg 运行gprecoverseg之后，需要运行gpstate -m查看同步是否都完成了。

1、GreenPlum这种share nothing的架构：       良好的发挥了廉价PC的作用。自此I/O不在是DW的瓶颈，相反网络的压力会大很多。但是greenplum的查询优化策略能够避免尽量少的网络交换。对于初次接触greenplum的人来说，肯定耳目一新。   2、greenplum的查询优化器        greenplum的查询优化器

虽然GREENPLUM可以降低对优化的要求，但是它也是关系型数据库。所以也需要进行优化。这里主要列出与GP优化的一些建议-PTA(PERFORMANCE TUNNING ADVICE) PTA RULE No1        在完成大批量数据装载之后，针对目标表总是进行vacuum analyze操作。一方面是如果批处理操作失败，会浪费很多空间，这个操作可以回收这些空间，另一方面，GP

最近搭建GP20台节点环境时，发生初始化总是出现几个节点实例无法启动的问题。折腾两天，才找到问题。 初始化时，设置了最大连接数为100，每台机器运行12个实例，主备就是24个实例，初始化后有一部分实例正常启动，一部分失败。 根据日志找到失败节点目录下的日志，发现失败原因是由于硬件资源问题导致，提示是初始化最大连接数过大。机器的配置都是很高的，会出现这样的问题，很奇怪。

1- 设定工作量管理服务配置参数 1) 使资源计划默认可用； 2) 可以设置如下资源限制参数： max_resource_queues：设置最资源队列数目 max_resource_portals_per_transaction：设置在一个事物中最大打开游标的数量； resource_select_only：如果设置成ON状态，则只有select /select in

1、每台节点创建文件目录 主实例 镜像实例都需要创建目录 例如 两个主 两个镜像 mkdir -p /data/seg1/pg_pri_cdr mkdir -p /data/seg2/pg_pri_cdr mkdir -p /data/seg1/pg_mir_cdr mkdir -p /data/seg2/pg_mir_cdr 以上内容每台节点都需要执行 主实例建

GP数据库集群，偶尔隔两天就会发生节点的切换，镜像实例变为主实例，主实例中断。检查主实例的日志发现出现一个错误后，镜像就启动了。 错误：receive close on connection: Success (cdbfilerepconnserver.c:334) 对这个错误分析了很长时间，为什么会偶尔有一次这样的问题出现。现在集群入库量很大，每个节点上的实例数也不少，就开始

"Recovery (bring GPDB up) from "FATAL:Global sequence number 1131954 less than maximum value 1131958 found in scan ('gp_persistent_relation_node')"" GPDB is down due to crash recovery failure with