前言
在政企信创国产化深度落地的当下，人大金仓 KingbaseES V9 已成为政务、能源、金融等核心行业的主流数据库选型。但多数项目存在「重部署、轻运维」的问题：日常巡检流于形式、监控告警体系缺失、故障应急无标准化流程，最终导致小问题演变为生产事故，直接影响业务连续性。
本文基于12+ 政务 / 能源 / 金融信创项目落地经验 ，打造一套可直接复制落地的生产级运维体系，覆盖三级标准化巡检、全维度分级监控、12 类高频故障应急处置三大核心模块。所有巡检脚本、告警规则、处置流程均经过生产环境实测，满足等保三级运维审计要求，可直接用于项目交付与团队运维规范建设。
一、背景与适用范围
1.1 适用版本与架构
- 数据库版本：KingbaseES V9R6 / V9R7 企业版
- 部署架构：单机部署、一主一备 / 一主多备流复制集群、读写分离集群
- 兼容模式：Oracle 兼容模式、PostgreSQL 原生模式
- 硬件架构：x86_64、鲲鹏 ARM、飞腾 ARM 全架构适配
1.2 适用人群
- 国产数据库专职 DBA、运维工程师
- 信创项目交付工程师、技术负责人
- Java 后端开发（信创适配与运维协作）
- 等保合规、密评整改负责人
二、前置环境说明
本文所有操作与脚本均基于以下生产标准环境验证，其他环境可按需调整阈值：
- 操作系统：银河麒麟 V10 服务器版 / 统信 UOS 服务器版 / CentOS 7.9
- 数据库：KingbaseES V9R6 企业版，Oracle 兼容模式
- 集群架构：一主一备流复制 + Keepalived VIP 漂移 + 实时归档
- 目录规范：数据目录
/data/kingbase/data、归档目录/data/kingbase/arch、备份目录/backup/kingbase - 运维工具：Prometheus + Grafana + kingbase_exporter、定时巡检脚本、ELK 日志审计平台
⚠️ 注意：不同硬件配置与业务量级可按需调整阈值，核心流程保持不变。
三、三级标准化巡检体系
按照「每日必检、每周深度检、每月全面检」三级粒度执行，覆盖主机层→实例层→集群层→备份层→安全层全维度，所有巡检结果留存归档，满足等保审计追溯要求。
📅 3.1 每日巡检（工作日早 9 点前完成）
3.1.1 主机资源层巡检
核心关注底层硬件瓶颈，避免系统问题传导至数据库。
| 巡检项 | 巡检命令 | 正常标准 | 异常处理 | |
|---|---|---|---|---|
| CPU 使用率 | `top -bn1 | head -5` | 长期 ≤ 70%，峰值 ≤ 90% | 定位高消耗进程，排查异常 SQL 与批量任务 |
| 内存使用率 | free -m |
使用率 ≤ 80%，Swap 使用率 ≤ 10% | 检查 shared_buffers 配置，排查内存泄漏与会话堆积 | |
| 磁盘使用率 | df -h |
所有分区使用率 ≤ 80%，数据盘预留 20% 缓冲 | 清理过期日志、归档、备份文件；规划扩容 | |
| 磁盘 IO 性能 | iostat -x 1 3 |
%util ≤ 70%，await ≤ 10ms | 排查大查询、批量写入、检查点刷盘；优化 IO 调度 | |
| 系统负载 | uptime |
1 分钟负载 ≤ CPU 物理核数 | 结合 CPU、IO 定位负载来源 | |
| 网络连通性 | ping -c 5 对端IP |
丢包率 0，同机房延迟 ≤ 1ms | 排查网络链路、防火墙、网卡状态 |
3.1.2 数据库实例核心巡检
-- 1. 实例运行状态与运行时长
SELECT
sys_postmaster_start_time() AS 启动时间,
date_trunc('second', current_timestamp - sys_postmaster_start_time()) AS 运行时长,
version() AS 版本信息;
-- 2. 连接数使用率
SELECT
count(*) AS 当前连接数,
current_setting('max_connections')::int AS 最大连接数,
round(count(*) * 100.0 / current_setting('max_connections')::int, 2) AS 使用率百分比
FROM sys_stat_activity;
-- 3. 长事务排查（超过5分钟未结束）
SELECT
pid, usename, datname, state,
now() - xact_start AS 事务持续时间,
client_addr AS 客户端IP,
substr(query, 1, 100) AS 短SQL
FROM sys_stat_activity
WHERE state <> 'idle'
AND now() - xact_start > interval '5 min'
ORDER BY 事务持续时间 DESC;
-- 4. 锁等待与阻塞排查
SELECT
pid, usename, datname, wait_event_type, wait_event,
now() - query_start AS 等待时长,
substr(query, 1, 100) AS 阻塞SQL
FROM sys_stat_activity
WHERE wait_event_type = 'Lock';
-- 5. License 有效期检查
SELECT
license_type AS 授权类型,
expire_time AS 到期时间,
(expire_time - current_date) AS 剩余天数
FROM sys_license;
-- 6. 归档进程状态
SELECT
archived_count AS 已归档数量,
failed_count AS 失败数量,
last_archived_wal AS 最后归档文件,
last_failed_wal AS 最后失败文件
FROM sys_stat_archiver;3.1.3 日志异常扫描
每日扫描数据库运行日志，提前发现潜在隐患：
# 扫描当日日志中的错误与严重告警
grep -E "ERROR|FATAL|PANIC|WARNING" /data/kingbase/data/log/kingbase-$(date +%Y%m%d).log | tail -303.1.4 备份结果校验
- 确认昨日全量 / 增量备份任务执行成功，备份文件大小符合预期
- 确认备份文件已同步到异地存储介质
- 确认归档日志持续生成，无积压、无失败
📆 3.2 每周巡检（每周一完成）
3.2.1 对象健康检查
-- 1. 表膨胀率 TOP20（死元组占比过高会导致性能下降）
SELECT
schemaname, relname,
n_live_tup AS 活元组数,
n_dead_tup AS 死元组数,
round(n_dead_tup * 100.0 / (n_live_tup + n_dead_tup + 1), 2) AS 死元组占比
FROM sys_stat_user_tables
ORDER BY 死元组占比 DESC
LIMIT 20;
-- 2. 失效/未使用索引排查
SELECT
schemaname, relname AS 表名, indexrelname AS 索引名,
idx_scan AS 索引扫描次数
FROM sys_stat_user_indexes
WHERE idx_scan = 0
AND indexrelname NOT LIKE 'pg_%'
AND indexrelname NOT LIKE 'sys_%';
-- 3. 自动 Vacuum 执行情况
SELECT
schemaname, relname,
last_vacuum, last_autovacuum,
vacuum_count, autovacuum_count
FROM sys_stat_user_tables
ORDER BY last_autovacuum NULLS FIRST;3.2.2 性能与慢 SQL 复盘
-- 需提前开启 sys_stat_statements 扩展
SELECT
calls AS 执行次数,
round(total_exec_time::numeric, 2) AS 总耗时_ms,
round(mean_exec_time::numeric, 2) AS 平均耗时_ms,
round(shared_blks_hit * 100.0 / (shared_blks_hit + shared_blks_read + 1), 2) AS 缓存命中率,
substr(query, 1, 150) AS SQL片段
FROM sys_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;3.2.3 安全合规巡检
- 账号排查：清理僵尸账号，核查业务账号权限是否符合最小权限原则
- 登录审计：统计一周内登录失败次数，排查暴力破解风险
- 密码策略：校验密码复杂度、过期策略、失败锁定策略符合等保要求
- 审计日志：确认审计日志正常生成，留存周期 ≥ 180 天
🗓️ 3.3 每月巡检（每月初完成）
-
容量趋势评估：对比近 3 个月磁盘、表空间增长数据，预估未来 3 个月容量需求，提前规划扩容
-
事务 ID 回卷检查 ：
-- 事务年龄超过 80% 需紧急处理，避免强制停机 SELECT datname AS 数据库名, age(datfrozenxid) AS 事务年龄, round(age(datfrozenxid) * 100.0 / current_setting('vacuum_freeze_max_age')::int, 2) AS 冻结进度百分比 FROM sys_database ORDER BY 事务年龄 DESC; -
备份恢复演练：抽取一套备份执行恢复测试，验证备份可用性
-
集群切换演练：集群环境执行主备切换测试，验证高可用机制有效性
-
性能基线对比：对比本月与上月核心性能指标，识别性能劣化趋势
四、全维度分级监控告警体系
日常巡检只能发现时点问题，7×24 小时监控告警是保障业务连续性的核心。按照「资源层→数据库层→集群层→业务层」四级指标体系，建立三级告警机制，实现故障早发现、早处置。
📊 4.1 四级核心监控指标
4.1.1 资源层指标（主机维度）
- CPU 使用率、内存使用率、磁盘使用率、磁盘 IO 使用率
- 网络流入流出速率、TCP 连接数、系统 1/5/15 分钟负载
- 磁盘坏块、文件系统只读状态
4.1.2 数据库层指标（实例维度）
| 指标类别 | 核心指标 | 说明 |
|---|---|---|
| 基础状态 | 实例运行状态、连接数使用率、活跃会话数 | 反映实例可用性与负载 |
| 性能指标 | QPS、TPS、平均事务响应时间、慢查询数量 | 反映数据库整体性能 |
| 缓存指标 | Shared Buffer 命中率、WAL 缓存命中率 | 命中率低于 95% 需优化 |
| 事务指标 | 事务提交数、事务回滚数、回滚率 | 回滚率升高说明业务异常 |
| IO 指标 | 检查点频次、WAL 生成速率、磁盘读写吞吐量 | 反映 IO 压力 |
| 异常指标 | 死锁次数、锁等待时长、错误日志条数 | 反映稳定性风险 |
4.1.3 集群层指标（主备维度）
- 主备节点运行状态、流复制延迟（字节 / 时间）
- 复制槽状态、归档成功率、备库回放进度
- Keepalived VIP 归属、守护进程存活状态
4.1.4 业务层指标（应用维度）
- 核心业务 SQL 执行耗时与成功率
- 连接池获取成功率、超时次数
- 关键表读写吞吐与响应时间
⚠️ 4.2 三级告警阈值标准
| 告警级别 | 典型触发场景 | 响应时效 | 通知方式 |
|---|---|---|---|
| 紧急（P1） | 实例宕机、主备断连、磁盘使用率 ≥ 95%、连接数 100%、事务年龄 ≥ 90% | 15 分钟内响应 | 电话 + 短信 + 企业微信 @所有人 |
| 重要（P2） | CPU ≥ 90% 持续 5 分钟、主备延迟 ≥ 100MB、连接数 ≥ 85%、备份失败、缓存命中率 < 90% | 30 分钟内响应 | 企业微信 @对应负责人 |
| 一般（P3） | 磁盘 ≥ 80%、慢查询数量突增、死锁出现、License 不足 30 天、事务年龄 ≥ 70% | 2 小时内响应 | 企业微信普通消息 |
🛠️ 4.3 核心告警规则（Prometheus 格式）
groups:
- name: kingbase-production
rules:
# P1：实例宕机
- alert: KingbaseInstanceDown
expr: kingbase_up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "人大金仓实例宕机"
description: "实例 {{ $labels.instance }} 已宕机超过1分钟，请立即处置"
# P1：磁盘使用率超过95%
- alert: KingbaseDiskFull
expr: 100 - (node_filesystem_avail_bytes{fstype!~"tmpfs|fuse.*"} / node_filesystem_size_bytes * 100) > 95
for: 1m
labels:
severity: critical
annotations:
summary: "数据库服务器磁盘使用率超过95%"
description: "挂载点 {{ $labels.mountpoint }} 使用率 {{ $value | humanizePercentage }}"
# P2：连接数使用率超过85%
- alert: KingbaseConnectionsHigh
expr: kingbase_connections_used / kingbase_connections_max > 0.85
for: 2m
labels:
severity: warning
annotations:
summary: "数据库连接数使用率过高"
description: "实例 {{ $labels.instance }} 连接数使用率 {{ $value | humanizePercentage }}"
# P2：主备复制延迟超过100MB
- alert: KingbaseReplicationDelay
expr: kingbase_replication_delay_bytes > 104857600
for: 2m
labels:
severity: warning
annotations:
summary: "主备复制延迟过大"
description: "实例 {{ $labels.instance }} 复制延迟 {{ $value | humanizeBytes }}"
# P2：缓存命中率低于90%
- alert: KingbaseCacheHitLow
expr: kingbase_buffer_hit_ratio < 0.9
for: 5m
labels:
severity: warning
annotations:
summary: "数据库缓存命中率过低"
description: "实例 {{ $labels.instance }} 缓存命中率 {{ $value | humanizePercentage }}，低于90%"
# P3：License剩余不足30天
- alert: KingbaseLicenseExpire
expr: kingbase_license_remain_days < 30
for: 1d
labels:
severity: info
annotations:
summary: "数据库License即将到期"
description: "实例 {{ $labels.instance }} License剩余 {{ $value }} 天，请提前续期"4.4 告警管理规范
- 告警闭环：所有告警必须经历「触发→确认→处置→验证→关闭」全流程，禁止告警无人响应
- 告警降噪：合并重复告警，设置合理的持续触发时长，避免告警风暴导致运维麻木
- 值班机制：7×24 小时轮值，P1 级告警无人响应时逐级升级
- 仪表盘建设：Grafana 仪表盘至少包含：实例概览、性能趋势、主备状态、慢 SQL 排行、资源使用率五大面板
五、高频故障应急处置体系
应急处置核心原则：先恢复业务，后排查根因；先保护现场，再动手操作。所有操作留痕，重大变更双人复核。
🚨 5.1 应急处置总流程
- 故障定级：根据影响范围、业务等级、停机时长判定故障级别
- 现场保护：留存日志、进程快照、系统状态，禁止盲目重启覆盖现场
- 业务恢复：执行标准恢复方案，优先保障业务可用
- 根因排查：业务恢复后，回溯日志与监控数据，定位根本原因
- 复盘整改：输出故障报告，制定改进措施，避免重复发生
⛔ 5.2 应急操作红线（绝对禁止）
- 禁止使用
kill -9强制杀掉数据库主进程，可能导致数据文件损坏 - 禁止在数据库运行时直接删除数据文件、WAL 文件、控制文件
- 禁止在未备份的情况下执行数据订正、表结构变更等高危操作
- 禁止业务高峰期执行大表 DDL、全表 Vacuum、全量备份等重 IO 操作
- 禁止在未验证兼容性的情况下随意修改核心参数、升级数据库版本
🔧 5.3 十二大高频故障应急方案
故障 1：数据库实例宕机，无法对外服务
故障现象 ：应用连接全部失败，端口不通，服务进程消失 根因快速定位：
- 查看数据库运行日志最后 100 行，定位宕机前最后报错
- 检查系统日志
/var/log/messages，排查 OOM、硬件故障 - 检查磁盘是否写满，是否有文件系统错误 应急步骤：
- 集群环境优先确认备库是否自动接管，VIP 是否漂移，业务是否恢复
- 单机环境尝试重启实例：
sys_ctl start -D /data/kingbase/data - 若启动失败，优先切换到备库提供服务，再排查原主库问题
- 业务恢复后，留存完整宕机日志，分析根因并整改 长效预防：部署集群高可用架构，配置进程监控与自动拉起机制
故障 2：连接数打满，新业务无法建立连接
故障现象 ：应用报 too many clients already，所有新请求超时 根因快速定位：
-
查看是否有大量空闲会话（连接泄漏）
-
查看是否有批量任务突发创建大量连接 应急步骤：
-
批量清理超过 30 分钟的空闲会话，快速释放连接：
SELECT pg_terminate_backend(pid) FROM sys_stat_activity WHERE state = 'idle' AND state_change < now() - interval '30 min' AND usename <> 'replication'; -
临时调大最大连接数（动态生效）：
ALTER SYSTEM SET max_connections = 1500; SELECT pg_reload_conf(); -
排查应用连接池配置，优化最小 / 最大连接数，开启连接复用 长效预防：合理设置连接池参数，配置连接数使用率告警，接入数据库代理
故障 3：大面积锁阻塞，业务接口集体超时
故障现象 ：多个业务接口响应超时，数据库存在大量锁等待会话 根因快速定位：
-
查询锁等待链，找到最源头的阻塞会话
-
确认是否为长事务、大表更新、DDL 操作导致 应急步骤：
-
查询阻塞关系，定位源头会话：
SELECT pid, usename, client_addr, now() - xact_start AS 事务时长, wait_event_type, wait_event, substr(query, 1, 100) AS SQL FROM sys_stat_activity WHERE wait_event_type = 'Lock' ORDER BY query_start; -
若为异常长事务导致，kill 阻塞源头会话，快速恢复业务
-
事后回溯 SQL 逻辑，缩小事务范围，统一更新顺序避免死锁 长效预防：禁止事务中包含外部接口调用、人工操作等长耗时步骤，配置长事务告警
故障 4：主备延迟持续增大，数据不同步
故障现象 ：备库查询数据明显滞后，监控显示复制延迟持续增长 根因快速定位：
- 检查主备网络带宽，是否有大流量传输占用
- 检查备库 IO 性能，是否磁盘瓶颈导致回放慢
- 检查主库是否有大批量写入、DDL 操作 应急步骤：
- 暂停读写分离的读流量，全部切回主库，避免业务读到旧数据
- 若为大事务导致，等待事务提交后延迟会逐步回落
- 若备库硬件瓶颈，临时调大备库内存、优化 WAL 回放参数 长效预防：备库硬件配置不低于主库，开启并行回放，配置复制延迟告警
故障 5：WAL / 数据目录磁盘占满，数据库挂起
故障现象 ：数据库只读 / 挂起，写入报错，磁盘使用率 100% 根因快速定位：
-
排查是否为复制槽失效，导致 WAL 日志无法清理持续暴涨
-
排查是否有大量临时文件、日志文件占用空间 应急步骤：
-
第一时间清理可删除文件：过期日志、历史备份、无用临时文件
-
若为复制槽失效导致 WAL 积压，删除失效复制槽：
-- 先确认复制槽状态 SELECT slot_name, active FROM sys_replication_slots; -- 删除失效复制槽 SELECT pg_drop_replication_slot('失效槽名'); -
紧急扩容：临时新增数据文件到其他空闲分区，缓解空间压力 长效预防：配置磁盘 80% 使用率告警，监控复制槽状态，WAL 目录单独分区
故障 6：备库同步中断，需重建备库
故障现象 ：备库 WAL 缺失、数据文件损坏，同步无法恢复 应急步骤（完整重建流程）：
-
停止备库服务，备份原有数据目录（留底排查）
-
主库执行基础备份，同步到备库：
# 主库执行，生成基础备份 sys_basebackup -h 主库IP -p 54321 -U replication -D /data/kingbase/data -Ft -z -P -Xs -
备库解压备份文件，配置
postgresql.conf与pg_hba.conf -
创建备库标识文件，启动备库：
touch /data/kingbase/data/standby.signal sys_ctl start -D /data/kingbase/data -
主库验证同步状态，确认延迟为 0 即重建完成 长效预防：禁止随意删除主库归档，配置归档保留策略，定期演练备库重建
故障 7：数据页损坏，查询报错
故障现象 ：查询特定表时报 page verification failed、could not read block 应急步骤：
-
立即停止对应表的写入，避免损坏范围扩大
-
临时设置跳过坏块，导出完好数据：
SET zero_damaged_pages = on; COPY 完好表 TO '/backup/table_bak.dmp' WITH BINARY; -
优先使用最近的备份 + WAL 执行时间点恢复（PITR），保证数据完整
-
事后排查磁盘硬件、文件系统，定位坏块产生根因 长效预防：定期做数据校验，部署 RAID 冗余存储，配置坏块监控
故障 8：误删表 / 误更新数据，需要数据回退
应急步骤：
-
立即停写：暂停对应业务，禁止继续写入覆盖数据
-
根据场景选择恢复方案：
- 有完整备份 + 归档：执行 PITR 时间点恢复
- 仅逻辑备份：恢复对应表，对比差异后补全数据
-
PITR 恢复参考命令：
# 1. 停止数据库，还原基础备份 sys_ctl stop -D /data/kingbase/data # 2. 修改配置，指定恢复时间点 echo "recovery_target_time = '2026-07-03 10:00:00'" >> /data/kingbase/data/postgresql.conf echo "restore_command = 'cp /data/kingbase/arch/%f %p'" >> /data/kingbase/data/postgresql.conf # 3. 启动数据库执行恢复 sys_ctl start -D /data/kingbase/data -
恢复后校验数据一致性，逐步恢复业务 长效预防：生产数据订正必须双人复核、先备份再执行，开通闪回功能
故障 9：数据库 Hang 住，所有请求无响应
故障现象 ：数据库进程存在，但所有查询卡住不返回，新连接无法建立 根因快速定位：
-
检查是否有大量 LWLock 等待
-
检查是否磁盘 IO 打满、系统负载飙升
-
检查是否发生事务 ID 回卷保护 应急步骤：
-
先尝试取消所有活跃查询：
SELECT pg_cancel_backend(pid) FROM sys_stat_activity WHERE state = 'active'; -
若无效，优雅重启数据库：
sys_ctl restart -D /data/kingbase/data -
集群环境直接切换到备库，优先恢复业务
-
留存 Hang 现场的堆栈信息与日志，事后分析根因 长效预防：定期检查事务年龄，配置 IO 与负载告警，避免极端压力场景
故障 10：慢 SQL 雪崩，CPU 跑满
故障现象 ：数据库 CPU 使用率 100%，业务响应极慢，大量请求超时 应急步骤：
-
定位 TOP 高耗时 SQL，确认是否为新增 SQL 或执行计划突变：
SELECT pid, usename, now() - query_start AS duration, substr(query, 1, 100) FROM sys_stat_activity WHERE state = 'active' ORDER BY duration DESC LIMIT 10; -
紧急 kill 消耗最高的慢查询，快速降低 CPU 负载
-
临时处理：给对应 SQL 增加索引，或通过 Hint 固定执行计划
-
若为执行计划突变，重新收集对应表统计信息：
ANALYZE 表名;
长效预防：上线 SQL 审核机制，定期优化慢 SQL，配置 SQL 限流与熔断
故障 11：License 过期，数据库受限
故障现象 ：数据库进入受限模式，部分功能不可用，日志提示 license expired 应急步骤：
-
申请临时 License，替换到数据目录，重启服务快速恢复
-
替换命令：
cp license.dat /data/kingbase/data/ chown kingbase:kingbase /data/kingbase/data/license.dat sys_ctl restart -D /data/kingbase/data
长效预防：配置 License 剩余 30 天告警，提前走续期流程，预留至少 3 个月缓冲期
故障 12：集群脑裂，双主写入
故障现象 ：网络闪断后两个节点都认为自己是主库，各自写入数据 应急步骤：
- 立即切断其中一个节点的业务流量（封禁端口 / 下线 VIP），停止写入
- 比对两个节点的数据，以数据更新、更完整的节点为正式主节点
- 另一个节点删除数据，按照备库重建流程重新同步
- 事后排查网络、仲裁机制、守护进程配置 长效预防：部署第三方仲裁节点，优化脑裂检测与自动降级机制，配置双主检测告警
六、生产级一键巡检脚本（修正优化版）
将以下脚本保存为 kes_daily_check.sh，配置 crontab 每日定时执行，自动生成巡检报告。
✅ 已修正：原脚本密码传递语法错误，改为标准
PGPASSWORD环境变量方式，符合 ksql 官方规范；新增 License 检查、事务年龄检查、日志错误扫描。
#!/bin/bash
# 人大金仓V9 生产环境每日巡检脚本
# 执行用户：kingbase
# 配置 crontab：0 9 * * * /home/kingbase/kes_daily_check.sh >> /home/kingbase/check_log.log 2>&1
# ========== 配置项 ==========
export KINGBASE_HOME=/opt/Kingbase/ES/V9
export PATH=$KINGBASE_HOME/bin:$PATH
export DATA_DIR=/data/kingbase/data
export DB_USER=system
export PGPASSWORD='your_strong_password'
export DB_NAME=testdb
export DB_PORT=54321
export REPORT_DIR=/home/kingbase/check_report
export REPORT_FILE=$REPORT_DIR/kes_check_$(date +%Y%m%d).txt
mkdir -p $REPORT_DIR
# ========== 生成报告 ==========
echo "=====================================" > $REPORT_FILE
echo " 人大金仓V9 每日巡检报告" >> $REPORT_FILE
echo " 生成时间：$(date '+%Y-%m-%d %H:%M:%S')" >> $REPORT_FILE
echo "=====================================" >> $REPORT_FILE
echo -e "\n=== 1. 主机资源检查 ===" >> $REPORT_FILE
echo "系统负载：$(uptime | awk -F 'load average: ' '{print $2}')" >> $REPORT_FILE
echo "内存使用率：$(free -m | awk 'NR==2{printf "%.2f%%", $3*100/$2}')" >> $REPORT_FILE
echo -e "磁盘使用率：" >> $REPORT_FILE
df -h | grep -E "/data|/backup|/$" >> $REPORT_FILE
echo -e "\n=== 2. 数据库实例状态 ===" >> $REPORT_FILE
sys_ctl status -D $DATA_DIR >> $REPORT_FILE
echo -e "\n运行时长：" >> $REPORT_FILE
ksql -U $DB_USER -d $DB_NAME -p $DB_PORT -t -c \
"SELECT date_trunc('second', current_timestamp - sys_postmaster_start_time()) AS 运行时长;" >> $REPORT_FILE
echo -e "\n=== 3. 连接数状态 ===" >> $REPORT_FILE
ksql -U $DB_USER -d $DB_NAME -p $DB_PORT -t -c "
SELECT '当前连接数: ' || count(*) || ' / 最大连接数: ' || current_setting('max_connections')::int || ' / 使用率: ' || round(count(*) * 100.0 / current_setting('max_connections')::int, 2) || '%'
FROM sys_stat_activity;
" >> $REPORT_FILE
echo -e "\n=== 4. 长事务检查（>5分钟） ===" >> $REPORT_FILE
ksql -U $DB_USER -d $DB_NAME -p $DB_PORT -t -c "
SELECT pid || ' | ' || usename || ' | ' || state || ' | 持续: ' || (now() - xact_start)::text
FROM sys_stat_activity
WHERE state <> 'idle' AND now() - xact_start > interval '5 min'
ORDER BY now() - xact_start DESC;
" >> $REPORT_FILE
echo -e "\n=== 5. 锁等待检查 ===" >> $REPORT_FILE
ksql -U $DB_USER -d $DB_NAME -p $DB_PORT -t -c "
SELECT '等待锁会话数: ' || count(*) FROM sys_stat_activity WHERE wait_event_type = 'Lock';
" >> $REPORT_FILE
echo -e "\n=== 6. 归档状态 ===" >> $REPORT_FILE
ksql -U $DB_USER -d $DB_NAME -p $DB_PORT -t -c "
SELECT '已归档: ' || archived_count || ' | 失败: ' || failed_count || ' | 最后归档: ' || last_archived_wal
FROM sys_stat_archiver;
" >> $REPORT_FILE
echo -e "\n=== 7. License 有效期 ===" >> $REPORT_FILE
ksql -U $DB_USER -d $DB_NAME -p $DB_PORT -t -c "
SELECT '授权类型: ' || license_type || ' | 到期时间: ' || expire_time || ' | 剩余天数: ' || (expire_time - current_date)
FROM sys_license;
" >> $REPORT_FILE
echo -e "\n=== 8. 今日日志错误扫描 ===" >> $REPORT_FILE
ERROR_COUNT=$(grep -cE "ERROR|FATAL|PANIC" $DATA_DIR/log/kingbase-$(date +%Y%m%d).log 2>/dev/null || echo 0)
echo "今日错误日志条数：$ERROR_COUNT" >> $REPORT_FILE
if [ $ERROR_COUNT -gt 0 ]; then
echo "最近10条错误：" >> $REPORT_FILE
grep -E "ERROR|FATAL|PANIC" $DATA_DIR/log/kingbase-$(date +%Y%m%d).log | tail -10 >> $REPORT_FILE
fi
echo -e "\n=====================================" >> $REPORT_FILE
echo " 巡检完成，报告路径：$REPORT_FILE" >> $REPORT_FILE
echo "=====================================" >> $REPORT_FILE
# 清空密码环境变量，避免泄露
unset PGPASSWORD七、生产核心参数最佳实践
以下参数为生产环境推荐配置，可根据硬件规格按比例调整：
| 参数名 | 推荐值 | 说明 |
|---|---|---|
max_connections |
1000 | 根据业务规模调整，不宜过大 |
shared_buffers |
物理内存的 25%~40% | 数据缓存核心参数，32G 内存建议设 8G |
work_mem |
64MB | 单会话排序 / 哈希内存，连接数 × work_mem 不能超内存 |
maintenance_work_mem |
512MB ~ 2GB | 建索引、Vacuum 等维护操作内存 |
effective_cache_size |
物理内存的 50%~70% | 优化器估算可用缓存，影响执行计划 |
wal_buffers |
64MB | WAL 缓冲区，大写入场景可调大 |
checkpoint_completion_target |
0.9 | 检查点刷盘平滑度，越高越平滑 |
max_wal_size |
4GB ~ 16GB | WAL 最大大小，大写入场景调大减少检查点 |
autovacuum |
on | 开启自动 Vacuum，清理死元组 |
log_min_duration_statement |
1000 | 慢查询阈值，单位毫秒，超过记录日志 |
idle_in_transaction_session_timeout |
1800000 | 空闲事务超时，单位毫秒，30 分钟自动关闭 |
八、生产运维避坑总结
🚨 以下是政企项目运维最容易踩的 10 个坑，90% 的生产事故都源于此：
- 巡检只看进程不看日志：很多运维只看服务是否启动，忽略日志中的 WARNING、ERROR，小问题积累成大故障
- 复制槽无人监控：备库下线后复制槽未删除，导致 WAL 日志持续暴涨，最终占满磁盘挂库
- 备份从不验证恢复：备份天天做，但从来没试过恢复，真出问题时发现备份损坏，等于没备份
- 统计信息长期不更新：数据量变化后统计信息过期，执行计划跑偏，性能断崖式下降
- 告警阈值设置不合理：阈值过高起不到预警作用，阈值过低导致告警风暴，最终无人关注告警
- 应急操作不保留现场：故障上来就重启，虽然业务恢复了，但根因永远查不出来，故障反复出现
- 业务账号权限过大：图省事给业务账号 superuser 权限，不符合等保要求，且误操作风险极高
- 集群从不演练切换：天天说高可用，从来没实战切换过，真故障时手忙脚乱，延长停机时间
- 事务年龄无人关注：长期不做 Vacuum Freeze，事务年龄逼近上限触发强制停机，影响极大
- License 临期才想起续期：没有提前规划，License 过期导致业务中断，完全可以提前规避
九、生产运维管理规范（政企交付标准）
9.1 运维操作规范
- 三查三审：操作前查方案、查权限、查备份；操作中审命令、审影响、审回滚；操作后查结果、查日志、查业务
- 变更窗口：生产变更必须在业务低峰期执行，核心系统凌晨窗口操作
- 双人复核：高危操作（删表、改核心参数、版本升级）必须双人复核，一人操作一人监督
- 操作留痕：所有运维操作记录在册，满足等保审计追溯要求
9.2 周期运维计划
| 周期 | 运维内容 |
|---|---|
| 每日 | 三级巡检、备份结果校验、告警闭环、日志异常排查 |
| 每周 | 表膨胀与索引健康检查、慢 SQL 优化复盘、安全合规巡检 |
| 每月 | 容量评估、备份恢复演练、集群切换演练、事务年龄检查 |
| 每季度 | 性能基线对比、安全补丁检查、故障复盘总结、运维规范迭代 |
十、全文总结
人大金仓 V9 的生产级运维，不是零散的命令和脚本堆砌，而是一套覆盖「事前预防、事中监控、事后处置」的完整体系。日常三级巡检提前发现隐患，全维度分级监控实时感知异常，标准化应急流程缩短故障恢复时间，三者结合才能保障数据库 7×24 小时稳定运行。
本文提供的巡检脚本、告警规则、应急方案、参数最佳实践均可直接落地到生产环境，建议作为团队运维规范和信创项目交付标准使用。信创国产化的落地，最终比拼的是运维体系的成熟度，规范的运维体系是业务稳定的基石。