1. 死锁数量异常
判断方法：
select sum(deadlocks) as deadlocks from dbe_perf.GLOBAL_STAT_DATABASE
异常分析：
1.请求与保持条件：获取资源的进程可以同时申请新的资源
2.非剥夺条件：已经分配的资源不能从该进程剥夺
3.循环等待条件：多个进程构成环路，并且每个进程都在等待相邻进程正占用的资源
4.互斥条件：资源只能被一个进程使用
解决方案
1.检索出死锁进程的ID（select oid,relname from pg_class where relname=‘all_date’;），检索出来的字段中，waiting字段数据为t的那条就是死锁进程，找到对应的procpid列的值
2.将进程杀掉，select pg_cancel_backend(‘死锁那条数据的procpid值’)，运行之后再次更新这个表，sql顺利执行
3.如果pg_stat_activity没有记录，则查询pg_locks是否有这个对象的锁，select pid_locks where relation=‘上面查询出来的oid’;然后杀掉进程
运维建议
1.在所有事务中都以相同的次序使用资源
2.使事务尽可能简单并在一个批处理中
3.为死锁超时参数设置一个合理范围
4.避免在事务内和用户进行交互，减少资源锁定时间
5.使用较低的隔离级别
2.主备复制状态异常
判断方法
gs_om -t status|grep cluster_state|grep Normal|wc -l
异常分析
1.可能存在批量处理大量数据导致主从节点宕机，主节点重启后从节点WAL同步信息不完整
2.主库宕机或者失联
3.备库宕机或者失联
解决方案
1.通过查看主备状态判断是主节点还是备节点故障
2.主节点故障可以尝试重启主节点，若不生效，可以再备节点使用gs_ctl failover -D “备节点的数据目录”，然后刷新机器（gs_om -t refreshconf），这时如果主机好了，直接启动出现两主，这时使用gs_ctl build -D “主节点的数据目录” -b incremental
3.-b参数为指定重建备机的模式，incremental为取主备差异的数据增量修复备机
3.备机回放gap使用空间异常
判断方法
select read_ptr-last_replayed_read_ptr as replay_gap from dbe_perf.GLOBAL_REDO_STATUS
异常分析
1.开启了数据文件的checksum，因为回放时需要大量的CPU资源，在进行checksum时会消耗startup进程的资源
2.主库频繁的离散IO操作，如大量的索引变更，大量的vacuum操作
3.频繁和大量的系统调用
解决方案
1.关闭checksum，除非要防御物理篡改
2.删除没有必要的索引
3.根据业务调整垃圾回收的调度
4.检查点拉长，可以减少full page的量
5.加大备库的shared buffer
6.关闭IO时间的跟踪
7.备库使用IOPS能力更强，IO延迟更低的机器
8.调整内核参数，使用并行apply
9.如果有多个备库，备库可以关闭fsync
10.将冻结年龄加大，可以减少冻结产生的redo
11.增加单个进程可打开的文件数
4.长查询时间异常
判断方法
select EXTRACT (epoch from max(current_timestamp - query_start)) from dbe_perf.SESSION_STAT_SCTIVITY where query_start is not null and state=‘active’ and application_name not like ‘dn_%’;
异常分析
1.SQL未经过优化，没有走合适的索引
2.可能存在锁争用问题
3.可能存在全表扫描问题
解决方案
1.查看对应语句的执行计划并作出相应的优化
2.创建合适的索引
