本身，还要关注集群中各 硬件的状况，及时发现及时处理。硬盘状态、阵列卡状态、硬件告警、 操作系统告警、空间使用率等都是应关注的重点。这些都可通过厂商 提供的工具，编写监控程序，SNMP 协议对接企业监控平台等手段提 升日常巡检和监控的效率。 针对 Greenplum，DBA 需要关注重点： ·Greenplum 的状态：Standby master 的同步状态往往容易被忽略。 通过监控平台或者脚本程序，能够及时告警则最好。 如遇个别表对象元数据不一致的情况，通常只会影响该对象的 使用，不会影响到整个集群。如果只是个别实例中存在问题，可 以通过 Utility 模式连接到问题实例中处理。处理原则是尽量不要 直接更改系统表的数据，而是采用数据库的手段去解决，如：drop table/alter table 等。 3) persistent table 问题，这类问题往往比较棘手，影响也比较大。 依据 gpcheckcat 的检查结果，必须把

存储的表来说，这个范围还可以再放大10倍甚至更高，因为列存储的表是按照每 个字段一个数据文件来存储的。  对目前的性能不满意？作为一种调优方案，应该在查询性能低于预期时再考虑对 表进行分区。分区不是万能的优化手段，GP已经是MPP架构，对于很多不是很大 的表，不分区的性能已经完全满足预期的情况下，分区是多余的。  查询条件是否能匹配分区条件？检查查询语句的WHERE条件是否与考虑分区的 COL 。 GP 数据库高可用概述 要获得一个高可用的GP数据库集群，涉及多方面的因素，除了GP数据库本身提供 的，软件层面的冗余设置外，磁盘Raid，网络冗余，双集群等，也是重要的手段。同 时，还需要配合日常监控和维护，及时发现故障并解决，才能确保GP数据库集群长期 稳定运行。 硬件设备总是无法绝对避免出故障，尤其是一些比较低端或者价格低廉的X86设备， 根据编者的经验来 注意：从上述流程可以看出，配置Mirror非常重要，Mirror是保证实例故障能快速 恢复的最有效的保障。对于没有Mirror的GP集群来说，一旦出现不可恢复的数据丢失 故障，就必须通过备份等其他手段来恢复数据，否则，数据就无法找回了。 主机故障，通常可能会导致很多个Instance故障，故障主机上的所有Primary 和Mirror都会发生故障并在系统表中被标记为Down状态(仅当集群还可以继续服务