数据库运维不缺命令，常见的问题是没有把关键动作固定下来。参数改了却没留记录，备份任务一直显示成功却没做过恢复，监控里只有当前 CPU 使用率。等故障发生，再临时翻日志，往往已经错过了最有价值的现场。

本文内容重点放在日常管理中需要长期执行的事项，不做参数手册式罗列。

一、排查前先核对版本和环境

开始排查前先看数据库版本。不同版本的参数名称、插件支持范围和兼容行为可能有差异，其他环境里的配置不能直接照搬。

SELECTversion();

日常连接可以准备一条固定模板，减少临时填写主机、端口和数据库名时出错的概率：

ksql-h192.168.10.20-p54321-Usystem-dprod

连接后先确认当前实例和配置文件位置：

SELECTcurrent_database(),current_user;SHOWdata_directory;SHOWconfig_file;SHOWhba_file;SHOWlisten_addresses;SHOWport;SHOWssl;

生产环境还要明确参数、安全策略和审计分别由谁负责。业务账号不要兼任管理账号，应用也不应长期使用管理员账号连接数据库。这类问题平时不明显，一旦账号泄露或发生误操作，影响范围会很大。

每次变更至少记录以下内容：

• 变更原因和负责人
• 修改前后的参数值
• 是否需要 reload 或重启
• 回退方法
• 验证结果

配置文件、部署脚本和巡检脚本建议纳入版本管理。密码、密钥和证书不要提交到代码仓库。

二、判断参数是否生效，要看实例当前值

KingbaseES 的参数可能来自kingbase.conf、kingbase.auto.conf、数据库级设置、角色级设置、启动参数或当前会话。只查看配置文件，无法确认实例最后采用了哪个值。

调整参数前，先弄清当前值、默认值、参数作用范围和生效方式，同时检查数据库级或角色级设置是否覆盖了全局配置。

支持在线修改的参数也应先在测试环境验证。生产变更尽量安排在低峰期，完成后继续观察日志、连接数和核心业务 SQL。

下面的查询可以集中查看常用参数的当前值和单位：

SELECTname,setting,unitFROMsys_settingsWHEREnameIN('max_connections','shared_buffers','work_mem','maintenance_work_mem','wal_level','archive_mode','archive_command')ORDERBYname;

以下命令会修改全局配置，不要放进只读巡检脚本：

ALTERSYSTEMSETwork_mem='8MB';SELECTsys_reload_conf();SHOWwork_mem;

也可以从操作系统侧重新加载配置：

sys_ctl reload-D/home/kingbase/KingbaseES/V9/data

需要重启才能生效的参数，应安排维护窗口。常用启停命令如下：

sys_ctl start-D/home/kingbase/KingbaseES/V9/data sys_ctl stop-D/home/kingbase/KingbaseES/V9/data sys_ctl restart-D/home/kingbase/KingbaseES/V9/data

启动后除了检查命令返回码，还要确认进程状态和控制文件信息：

ps-ef|grep'[k]ingbase'sys_controldata-D/home/kingbase/KingbaseES/V9/data

连接和认证配置也属于运行基线。监听地址和端口按实际需要开放，认证规则按来源地址、数据库和用户分别设置。跨网络访问建议启用 SSL，并把证书有效期纳入日常检查。

三、内存和存储按实际负载规划

内存配置需要结合共享内存、单会话内存、并发连接、后台进程和操作系统预留空间一起计算。某个参数单独看并不大，但在高并发场景下会被成倍放大。

调整内存前，先收集这些数据：

• 物理内存和 Swap 使用情况
• 当前活跃连接数和历史峰值
• 排序、哈希及维护操作的并发量
• 自动清理进程可能占用的内存
• 操作系统页缓存和其他进程所需空间

数据库侧先查询相关参数：

SHOWshared_buffers;SHOWwal_buffers;SHOWwork_mem;SHOWmaintenance_work_mem;SHOWtemp_buffers;SHOWmax_connections;

操作系统侧同时采集内存、Swap 和进程占用情况：

free-mswapon-spsauxc--sort=-%mem|head-20ipcs--human-a

准备调整时，应按并发规模估算总量。下面的数值只用于展示语法，不代表推荐配置。其中shared_buffers一类参数通常需要重启后生效。

ALTERSYSTEMSETshared_buffers='8GB';ALTERSYSTEMSETwork_mem='8MB';ALTERSYSTEMSETmaintenance_work_mem='512MB';

存储规划不能只看数据目录总容量。数据文件、WAL、归档、备份和日志的增长速度不同，分开监控更容易判断风险。有条件时，可以把高 I/O 路径放到独立存储。

表空间主要用于容量和 I/O 隔离。创建前应明确用途、容量上限、备份方式和恢复路径，避免为了目录拆分而增加管理复杂度。

日常存储检查至少包括容量、inode、WAL 目录和 I/O 延迟：

df-mdf-idu-sh/home/kingbase/KingbaseES/V9/datadu-sh/home/kingbase/KingbaseES/V9/data/sys_wal iostat22iotop-b-k-P-n4

如果文件系统容量正常，但数据库仍有大量 I/O 等待，可以继续检查多路径、挂载参数和块设备信息：

multipath-llmountls-l/dev/disk/by-uuid

四、备份是否可用，需要通过恢复确认

备份任务显示成功，只能说明任务执行完成，不能直接说明数据可以恢复。一套可用的备份方案通常包括基础备份、连续 WAL 归档、保留策略、异地副本和定期恢复演练。

先查看归档参数的实际值：

SHOWwal_level;SHOWarchive_mode;SHOWarchive_command;

启用归档时，archive_mode应为on或always，archive_command需要把 WAL 实际写入可靠存储。如果命令只返回成功而文件没有落盘，问题通常要到恢复时才会暴露。

检查备份时，不要只确认文件是否存在，还要核对：

• 最近一次全量和增量备份是否完成
• WAL 是否持续归档
• 备份集和归档的保留周期是否匹配
• 备份存储是否有足够容量
• 恢复所需的配置、密钥和工具是否齐全
• 是否在隔离环境完成过恢复验证

手动切换一次 WAL，可以检查归档链路是否正常：

SELECTsys_switch_wal();

执行后检查数据库日志和归档目录。使用sys_rman的环境，还可以执行只读检查：

sys_rman-config=/home/kingbase/kbbr_repo/sys_rman.conf\--stanza=kingbase info sys_rman-config=/home/kingbase/kbbr_repo/sys_rman.conf\--stanza=kingbase checkgrep-rn"archive-push"/home/kingbase/KingbaseES/V9/data/sys_log sys_controldata-D/home/kingbase/KingbaseES/V9/data

恢复演练前保存当前环境信息，恢复后使用同一组查询核对数据库、对象数量和关键业务数据：

SELECTversion();SELECTcurrent_database();SHOWdata_directory;SHOWarchive_mode;SHOWarchive_command;

演练时要记录实际 RPO 和 RTO。业务要求 RPO 接近 0，需要确认 WAL 链完整；业务要求快速恢复，则要记录从发现故障到服务恢复的真实耗时。文档中的目标值需要用演练结果验证。

五、主备检查不能漏掉复制槽

检查主备环境时，只看节点是否在线不够。流复制可能仍在运行，但延迟已经超过业务可接受范围。备库异常后，复制槽也可能长期保留 WAL，最终占满磁盘。

复制状态可以按分钟采集：

SELECT*FROMsys_stat_replication;

将差距换算成字节后，更方便接入监控系统：

SELECTapplication_name,client_addr,state,sync_state,replay_lsn,sys_wal_lsn_diff(sys_current_wal_flush_lsn(),replay_lsn)ASlag_bytesFROMsys_stat_replication;

主要关注state、sync_state、发送与回放位置，以及主备之间的 LSN 差距。告警阈值应按业务允许的数据延迟设置，不同环境不必共用同一个数值。

复制槽可以每 10 分钟检查一次：

SELECT*FROMsys_replication_slots;

检查复制槽数量、类型和active状态。发现预期外的复制槽时先确认来源；失效复制槽也应评估后再删除，不能仅凭 WAL 增长就直接清理。

备库还要检查standby.signal、连接配置和时间线状态。主备发生过切换或脑裂后，应先判断数据是否分叉，再决定旧主库如何重新加入集群。

集群和备库侧可使用以下只读命令：

repmgr cluster show repmgrservicestatusls-l/home/kingbase/KingbaseES/V9/data/standby.signal sys_controldata-D/home/kingbase/KingbaseES/V9/data

查询当前 WAL 位置：

SELECTsys_current_wal_lsn();

六、监控数据要能回看

单个时间点的指标只能说明当前状态，无法判断异常从何时开始，也不容易找到触发因素。监控数据至少保留一周，核心系统可以保留更长时间，便于与正常时段对比。

查询连接数：

SELECTcount(*)ASconnsFROMsys_stat_activityWHEREbackend_typeIN('client backend','walsender');

按用户、客户端和应用拆分连接来源：

SELECTusename,client_addr,application_name,state,count(*)ASconnectionsFROMsys_stat_activityWHEREbackend_type='client backend'GROUPBYusename,client_addr,application_name,stateORDERBYconnectionsDESC;

查询未获取到的锁：

SELECTcount(*)FROMsys_locksWHEREgranted=false;

继续查看具体等待会话：

SELECTa.pid,a.usename,a.client_addr,a.wait_event_type,a.wait_event,l.locktype,l.mode,a.queryFROMsys_locks lJOINsys_stat_activity aONa.pid=l.pidWHEREl.granted=falseORDERBYa.query_start;

长事务需要单独监控：

SELECTpid,datname,query,age(backend_xmin)ASageFROMsys_stat_activityWHEREbackend_xminISNOTNULL;

查找长时间执行的 SQL：

SELECTpid,usename,client_addr,now()-query_startASrunning_time,wait_event_type,wait_event,queryFROMsys_stat_activityWHEREstate='active'ANDquery_start<now()-interval'5 minutes'ORDERBYquery_start;

查找长时间未提交的事务：

SELECTpid,usename,client_addr,now()-xact_startAStransaction_time,state,queryFROMsys_stat_activityWHERExact_startISNOTNULLORDERBYxact_start;

事务号年龄和许可证有效期也可以加入巡检：

SELECTdatname,age(datfrozenxid),mxid_age(datminmxid)FROMsys_databaseORDERBYage(datfrozenxid)DESC;SELECTget_license_validdays()ASvalid_days;

数据库级事务、缓存、临时文件和死锁统计：

SELECTdatname,numbackends,xact_commit,xact_rollback,blks_read,blks_hit,temp_files,temp_bytes,deadlocksFROMsys_stat_databaseORDERBYdatname;

sys_stat_activity 中的等待事件是瞬时状态。要分析等待趋势，需要周期采样，或结合 KWR、KSH、日志和操作系统监控一起判断。

管理员指南给出的 CPU、I/O、内存和等待事件阈值可以作为初始参考。实际告警值最好根据本系统的业务基线调整，重点关注持续偏离正常区间的情况。

出现问题时，操作系统侧先保存一组短时采样：

sar-u25sar-r25sar-nDEV25iostat25top-o%CPU-i-b-n4df-mdf-i

需要保留一段时间的性能数据时，可以使用 nmon：

./nmon-f-t-s10-c360-m/home/kingbase/nmon/

七、性能变慢时先排除基础问题

用户反馈“数据库变慢”时，原因不一定在 SQL。连接耗尽、长事务、锁等待、WAL 堆积、自动清理滞后、磁盘空间不足或网络抖动，都可能表现为响应时间上升。

自动清理不要随意关闭。日常应关注长事务、表膨胀、事务年龄、清理日志和 worker 使用情况。大表可以按对象设置单独阈值，不宜用一组参数覆盖所有表。

查看死元组较多或长期未清理的表：

SELECTschemaname,relname,n_live_tup,n_dead_tup,last_vacuum,last_autovacuum,last_analyze,last_autoanalyzeFROMsys_stat_user_tablesORDERBYn_dead_tupDESCLIMIT20;

查看正在执行的清理任务：

SELECT*FROMsys_stat_progress_vacuum;

统计信息过旧时，可以先对单表执行分析：

ANALYZEVERBOSE app.orders;

清理操作会消耗 I/O，也可能与业务争用资源。生产执行前应确认表大小、锁影响和维护窗口：

VACUUM(VERBOSE,ANALYZE)app.orders;

慢 SQL 分析可以按以下顺序进行：

1. 确认问题发生的时间段和业务影响。
2. 收集 SQL、执行计划、等待事件和资源数据。
3. 对比正常时段的 KWR、KSH 或 nmon 数据。
4. 判断瓶颈位于 SQL、锁、CPU、I/O、内存还是网络。
5. 调整后使用相同场景复测。

分析执行计划时，建议同时查看实际耗时和缓冲区使用。ANALYZE会真实执行 SQL，写操作应放在测试环境，或者在事务保护下分析。

EXPLAIN(ANALYZE,BUFFERS)SELECT*FROMapp.ordersWHEREcustomer_id=10001;

需要长期统计 SQL 时，可以启用sys_stat_statements。这项配置涉及参数修改和重启：

shared_preload_libraries = 'sys_stat_statements' sys_stat_statements.track = 'top'

CREATEEXTENSIONIFNOTEXISTSsys_stat_statements;

详细日志会增加磁盘和性能开销。问题定位完成后，应关闭临时启用的高强度跟踪，避免长期占用资源。

八、发生故障后先保留现场

故障发生后，直接重启、删除文件或修改控制信息，可能会丢失定位原因所需的证据。只要业务条件允许，应先保存数据库和操作系统现场，再进行恢复处理。

保存数据库会话状态：

SELECTpid,usename,client_addr,application_name,state,xact_start,query_start,wait_event_type,wait_event,queryFROMsys_stat_activityORDERBYxact_start NULLSLAST,query_start NULLSLAST;

取消 SQL 对业务的影响通常小于终止整个会话，可以优先尝试。以下两条命令都会改变运行状态，执行前必须核对 PID。

SELECTsys_cancel_backend(26212);SELECTsys_terminate_backend(26212);

操作系统侧同时保存进程、磁盘和日志信息：

ps-ef|grep'[k]ingbase'top-b-n1iostat25df-mdf-isystemctl--failedls-lh/home/kingbase/KingbaseES/V9/data/sys_log

故障处理可以按以下顺序记录：

1. 确认影响范围，是单会话、单库、单节点还是整个集群。
2. 保存数据库日志、集群日志、系统日志、进程状态和资源数据。
3. 判断问题属于连接、锁、复制、存储、内存、CPU、网络还是数据损坏。
4. 分别记录直接原因、间接原因和根本原因。
5. 评估影响是否会扩大，以及是否存在数据丢失风险。
6. 区分紧急止损措施和后续完整修复方案。
7. 重新采样指标，确认业务、复制、归档和备份恢复正常。
8. 根据结果补充监控、参数、脚本或演练安排。

涉及数据文件、控制文件、WAL 和时间线的操作风险较高。没有完整备份和明确回退方法时，不应直接在生产环境尝试。

九、巡检清单

每日

• 检查实例、集群和守护进程状态
• 检查主备复制延迟和复制槽状态
• 检查数据、WAL、归档、备份和日志空间
• 检查备份任务与 WAL 归档结果
• 检查连接数、长事务、锁等待和错误日志

每周

• 查看 KWR、KSH 或其他性能趋势报告
• 检查表膨胀、统计信息和自动清理状态
• 核对备份保留策略和备份存储容量
• 检查账号、权限和异常登录
• 复查近期配置变更及回退记录

每月或每季度

• 在隔离环境执行恢复演练
• 验证 RPO、RTO 是否达到业务要求
• 复核容量增长和扩容时间点
• 检查证书、许可证和软件维护周期
• 更新故障手册、联系人和应急流程

结语

这些事项本身并不复杂，难点在于持续执行。比较稳妥的做法，是把重复检查做成脚本和监控项，把变更与演练结果留档，减少对个人记忆和临场经验的依赖。

故障无法完全避免，但完善的监控和记录可以让问题更早暴露，也能为恢复和复盘保留足够依据。

不同补丁版本和部署架构可能存在差异，生产变更前请核对对应版本文档并完成验证。