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

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

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

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

SELECT version();

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

ksql -h 192.168.10.20 -p 54321 -U system -d prod

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

SELECT current_database(), current_user;SHOW data_directory;SHOW config_file;SHOW hba_file;SHOW listen_addresses;SHOW port;SHOW ssl;

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

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

• 变更原因和负责人

• 修改前后的参数值

• 是否需要 reload 或重启

• 回退方法

• 验证结果

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

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

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

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

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

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

SELECT name, setting, unitFROM sys_settingsWHERE name IN (    'max_connections',    'shared_buffers',    'work_mem',    'maintenance_work_mem',    'wal_level',    'archive_mode',    'archive_command')ORDER BY name;

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

ALTER SYSTEM SET work_mem = '8MB';SELECT sys_reload_conf();SHOW work_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 使用情况

• 当前活跃连接数和历史峰值

• 排序、哈希及维护操作的并发量

• 自动清理进程可能占用的内存

• 操作系统页缓存和其他进程所需空间

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

SHOW shared_buffers;SHOW wal_buffers;SHOW work_mem;SHOW maintenance_work_mem;SHOW temp_buffers;SHOW max_connections;

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

free -m
swapon -s
ps auxc --sort=-%mem | head -20
ipcs --human -a

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

ALTER SYSTEM SET shared_buffers = '8GB';ALTER SYSTEM SET work_mem = '8MB';ALTER SYSTEM SET maintenance_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
iostat 2 2
iotop -b -k -P -n 4

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

multipath -ll
mountls -l /dev/disk/by-uuid

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

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

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

SHOW wal_level;SHOW archive_mode;SHOW archive_command;

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

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

• 最近一次全量和增量备份是否完成

• WAL 是否持续归档

• 备份集和归档的保留周期是否匹配

• 备份存储是否有足够容量

• 恢复所需的配置、密钥和工具是否齐全

• 是否在隔离环境完成过恢复验证

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

SELECT sys_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 check
grep -rn "archive-push" /home/kingbase/KingbaseES/V9/data/sys_log
sys_controldata -D /home/kingbase/KingbaseES/V9/data

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

SELECT version();SELECT current_database();SHOW data_directory;SHOW archive_mode;SHOW archive_command;

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

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

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

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

SELECT * FROM sys_stat_replication;

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

SELECT
    application_name,
    client_addr,
    state,
    sync_state,
    replay_lsn,
    sys_wal_lsn_diff(sys_current_wal_flush_lsn(), replay_lsn) AS lag_bytesFROM sys_stat_replication;

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

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

SELECT * FROM sys_replication_slots;

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

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

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

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

查询当前 WAL 位置：

SELECT sys_current_wal_lsn();

六、监控数据要能回看

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

查询连接数：

SELECT count(*) AS connsFROM sys_stat_activityWHERE backend_type IN ('client backend', 'walsender');

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

SELECT
    usename,
    client_addr,
    application_name,
    state,    count(*) AS connectionsFROM sys_stat_activityWHERE backend_type = 'client backend'GROUP BY usename, client_addr, application_name, stateORDER BY connections DESC;

查询未获取到的锁：

SELECT count(*)FROM sys_locksWHERE granted = false;

继续查看具体等待会话：

SELECT
    a.pid,
    a.usename,
    a.client_addr,
    a.wait_event_type,
    a.wait_event,
    l.locktype,
    l.mode,
    a.queryFROM sys_locks lJOIN sys_stat_activity a ON a.pid = l.pidWHERE l.granted = falseORDER BY a.query_start;

长事务需要单独监控：

SELECT pid, datname, query, age(backend_xmin) AS ageFROM sys_stat_activityWHERE backend_xmin IS NOT NULL;

查找长时间执行的 SQL：

SELECT
    pid,
    usename,
    client_addr,
    now() - query_start AS running_time,
    wait_event_type,
    wait_event,
    queryFROM sys_stat_activityWHERE state = 'active'
  AND query_start < now() - interval &#x27;5 minutes&#x27;ORDER BY query_start;

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

SELECT
    pid,
    usename,
    client_addr,
    now() - xact_start AS transaction_time,
    state,
    queryFROM sys_stat_activityWHERE xact_start IS NOT NULLORDER BY xact_start;

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

SELECT datname, age(datfrozenxid), mxid_age(datminmxid)FROM sys_databaseORDER BY age(datfrozenxid) DESC;SELECT get_license_validdays() AS valid_days;

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

SELECT
    datname,
    numbackends,
    xact_commit,
    xact_rollback,
    blks_read,
    blks_hit,
    temp_files,
    temp_bytes,
    deadlocksFROM sys_stat_databaseORDER BY datname;

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

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

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

sar -u 2 5
sar -r 2 5
sar -n DEV 2 5
iostat 2 5
top -o %CPU -i -b -n 4df -mdf -i

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

./nmon -f -t -s 10 -c 360 -m /home/kingbase/nmon/

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

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

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

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

SELECT
    schemaname,
    relname,
    n_live_tup,
    n_dead_tup,
    last_vacuum,
    last_autovacuum,
    last_analyze,
    last_autoanalyzeFROM sys_stat_user_tablesORDER BY n_dead_tup DESCLIMIT 20;

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

SELECT * FROM sys_stat_progress_vacuum;

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

ANALYZE VERBOSE 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 *FROM app.ordersWHERE customer_id = 10001;

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

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

CREATE EXTENSION IF NOT EXISTS sys_stat_statements;

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

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

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

保存数据库会话状态：

SELECT
    pid,
    usename,
    client_addr,
    application_name,
    state,
    xact_start,
    query_start,
    wait_event_type,
    wait_event,
    queryFROM sys_stat_activityORDER BY xact_start NULLS LAST, query_start NULLS LAST;

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

SELECT sys_cancel_backend(26212);SELECT sys_terminate_backend(26212);

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

ps -ef | grep '[k]ingbase'top -b -n 1
iostat 2 5df -mdf -i
systemctl --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 是否达到业务要求

• 复核容量增长和扩容时间点

• 检查证书、许可证和软件维护周期

• 更新故障手册、联系人和应急流程

结语

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

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

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