现象-系统突然运行缓慢 对于此类问题，问题原因可能是多方面的，定位比较困难，首先需要判断是硬件原因导致还是应用本身的原因导致，是某一SQL导致还是整体运 行变慢，找到具体的原因后，才能确定应对措施  检查當前所有设备IO,CPU使用情況： – CPU是否繁忙(gpssh –f allhosts -e“uptime”) – IO是否繁忙，Wait是否较高 – 是单一服务器繁忙还是所有服务器繁忙 – gdb（在support指导下使用） – dstat – vmstat – nmon – tcpdump 应急处理措施  数据库重启 当数据库出现异常，不能正常使用时，此时可以重启数据库 建议每次关闭数据库前，执行一次checkpoint，或者UTILITY进入到每一个实例，执行checkpoint;

企业数据集合：主要的优势 • 实体整合 • 提高服务器使用率 • 降低总硬件成本 • 降低能量成本 • 可以预估的服务等级 • 确保关键任务的可靠性 • 最出色的性能 • 高度灵活性 • 逐步扩展计算能力 • 动态措施 • 数据访问： • 在一个系统中协调所有企业数据的位置 • 可以通过任何语言（SQL、M/R等）进行分析 14 强大并且不断扩展的合作伙伴网络 硬件供应商 商务智能工具 15 服务供应商

Master 无法连接到 Primary 时，该 Primary 在 GP 的系统表中将被标记 为失败状态，Master 会激活/唤醒对应的 Mirror 取代原有的 Primary。在采取相应 的措施将失败的 Primary 恢复到健康状态之前，该 Primary 一直保持失败状态。失 败的 Primary 可以在系统处于运行状态下被恢复回来。恢复进程仅仅复制失败期间发 生变化的增量差异，当然，如果失败时间太久或者因失败的 记为Down状态。 Greenplum Database 管理员指南 V6.2.1 版权所有：Esena(陈淼 +86 18616691889) 编写：陈淼 - 318 - 直到采取恢复措施之前，被标记为Down状态的Instance将一直处于离线状态。恢复 Instance的具体流程取决于故障发生的原因和是否启用了镜像。Instance失败的原 因有很多种可能：  主机不 体信息来判断问题，并采取合 Greenplum Database 管理员指南 V6.2.1 版权所有：Esena(陈淼 +86 18616691889) 编写：陈淼 - 368 - 适的措施来解决故障。当然，如果升级失败，还可以考虑降回之前的版本。 大版本升级 要实施大版本升级，将是一个复杂的工程，编者建议，如果有可能，最好获得专业 技术支持的帮助。从4.3版本

通过这种方式改造后，达到了很好的效果。 ·预留一台硬件服务器作为整个集群的灾备机，提前装好操作系统和 数据库软件，并放在与现有集群相同的网络环境中，一旦硬件出现 故障，我们可以迅速采取相应的修复措施，如果底层 RAID 没有损坏， 在单台机器数据量过大比如接近 10T 的情况下，我们可以直接将磁 盘插入到灾备机，由于 RAID 信息写在磁盘上，对调磁盘后，所有 数据信息仍然保留，这样就能避免数据同步带来的性能损耗，这种