一、 排查经验总结
过去Sybase数据库问题的整体思路是从整体到局部，从宏观到微观的排查。
第一步，梳理数据库架构和应用部署情况，确定数据库上各个应用连接的情况。
第二步，排查数据库物理实体机器情况，确定系统负载、CPU使用率、内存交换、IO吞吐量、网络吞吐量情况
第三步，排查数据库服务配置情况，确定最大内存和各缓存配置，连接数、锁、最大对象数等重要参数的配置
第四步，排查热点对象及其缓存使用情况
第五步，排查慢SQL和占用CPU高的SQL及全表扫描SQL
第六步，排查锁阻塞和死锁
二、Sybase监控体系总结
在Sybase时代，使用系统存储过程、系统表、MDA表、及慢SQL分析相结合方式排查分析数据库问题。
存储过程：
- sp_sysmon sybase各方面的系统监控报告
- sp_monitorconfig sybase配置参数报告
- sp_reportstats sybase各用户资源使用报告
- sp_lock 查看锁
- sp_who 查看连接情况
- sp_dba 系列自定义监控存储过程（超大表、锁阻塞、缺失索引、设备空间等）
系统表：
- sysprocesses 数据库连接情况
- syslocks 数据库锁情况
- sysqueryplans 执行计划情况
- sysobjects 数据库对象情况
MDA表：
- monOpenObjectActivity 监控数据库对象（表、索引）使用情况
- monProcessStatement 进程正在占用系统资源情况（CPU）
- monProcessSQLText 进程正在执行的SQL语句
SQLFX平台：
- 分析慢SQL
- 分析不符合标准的SQL
- 分析SQL分布及压力
三、PostgreSQL监控体系现状
PostgreSQL数据库提供了系统表和监控表用来检测数据库的运行,通过监控参数控制是否收集监控信息，监控表分为动态和历史统计。
系统表：
- pg_class
- pg_locks
- pg_stats
- 等等
监控表：
动态监控
- pg_stat_activity
- pg_stat_repliccation
- pg_stat_ssl
- 等等
历史统计
- pg_stat_all_tables
- pg_stat_user_tables
- pg_stat_sys_tables
- 等等
四、PostgreSQL监控脚本规划
ABase数据库监控脚本的规划思路是补充、改造、和简化。
补充
通过数据库服务端语言，收集监控操作系统层面各服务进程的CPU利用率、当前的IO使用率、任务切换等改造
主题思想，动态试图历史化，历史视图动态化。
比如pg_stat_activity 能看到当前的连接情况和SQL，单不能查看历史某个时段的连接情况和SQL。pg_stat_all_tables能看到表的累积访问情况和IO，但是不能方便看到几分钟内的访问情况和IO简化
通过输入简单的方法名或者查询简单的视图能够快速查看监控信息，不用输入复杂的SQL
规划ABase监控脚本分类：
连接情况
pg_stat_all_activity 历史的连接情况
pg_stat_longtime_sql 长时间运行的SQL情况
pg_stat_seqscan_sql 全表扫描的SQL情况系统负载情况(pid,cpu,io,task switch)
pg_stat_all_sysload 历史负载
pg_stat_current_sysload 当前负载热点对象及缓存情况
pg_stat_hotobject
pg_stat_cacheobject锁阻塞情况
pg_stat_lockblock空间情况
pg_stat_objectsize