KES 数据库开辟运维手记：摆设、安全、备份与监控实战

KES 数据库开辟运维手记：摆设、安全、备份与监控实战

写在开头

干数据库这行有些年初了，从最早用贸易库到厥后折腾各种国产库，踩过的坑说多了都是泪。这两年信创项目越来越多，KES 数据库在政企、金融、能源范畴铺得挺广，身边不少朋侪开始打仗它。说实话，刚上手的时间我也摸不着头脑——文档固然有，但许多细节得靠自己踩坑才气搞明白。有些设置参数改了之后要重启才见效，有些不消；有些功能要装扩展才气用，有些默认就开着。这些东西文档里都有写，但散落在各个章节里，找起来费劲。
这篇文章算是一个阶段性的总结，把摆设设置、安全管理、备份规复、一样平常监控这几个方面的心得记下来。恰当有肯定命据库根本、刚开始打仗 KingbaseES 的开辟和运维职员。内容偏实操，理论部分点到为止，重点照旧那些下令和设置。如果你是正在做信创项目选型大概刚接办一个 KES 数据库的运维工作，这篇文章应该能帮你少走一些弯路。
安装摆设与环境初始化

装库这事自己不难，但有些细节不留意背面会受苦头。KES 支持主流国产利用体系，麒麟、统信、中科方德都没标题，x86 和 ARM 架构也都能跑。我一样平常在 CentOS 和麒麟 V10 上装得比力多，流程差不多。有一点要提前确认：利用体系的内核参数和网络设置要符合数据库的安装要求，特别是大页内存（hugepages）的设置，生产环境下开启大页对性能有资助。
安装包获取与准备
安装介质从电科金仓官方渠道获取，一样平常是 ISO 大概 tar.gz 格式。拿到之后先校验一下 MD5，别由于下载不完备浪费时间。解压之后目次结构大抵是如许的：

1. tar -xzf KingbaseES_V9_xxx.tar.gz
2. cd KingbaseES_V9_xxx
4. # 看一下目录结构
5. ls -l
6. # setup.sh 是安装脚本
7. # license.dat 是授权文件，没这个装不了

复制代码

装之前确认体系用户和环境变量。发起用专门的 kingbase 用户来安装和运行数据库服务，别用 root。

1. # 创建专用用户
2. useradd -m kingbase
3. passwd kingbase
5. # 设置目录权限
6. chown -R kingbase:kingbase /opt/Kingbase

复制代码

实行安装
KES 提供图形界面安装和静默安装两种方式。服务器环境下我保举用静默安装，快且不容易堕落。图形界面谁人在长途终端里跑起来卡得很，没须要。

1. # 静默安装示例
2. ./setup.sh -i console \
3.   -d /opt/Kingbase/ES/V9 \
4.   -p server \
5.   -U system \
6.   -W "YourPassword123" \
7.   --license /opt/license.dat

复制代码

安装过程中会让你选择兼容模式，这个比力关键。KingbaseES 支持 Oracle 兼容、MySQL 兼容和尺度模式三种。选哪种取决于你的业务原来用的是什么库。如果是新开辟的项目，尺度模式就挺好，SQL 举动最规范；如果是从 Oracle 迁过来的，选 Oracle 兼容模式会省许多事，存储过程、包、自界说范例根本上不消怎么改就能跑。MySQL 兼容模式同理，对 MySQL 的方言和函数做了适配。不外要留意，兼容模式选定之后不能任意切换，发起在项目初期就确定好。
初始化与启动
装完之后初始化数据库实例，这个过程跟其他关系型数据库雷同：

1. # 切到 kingbase 用户
2. su - kingbase
4. # 初始化数据目录
5. initdb -D /data/kingbase/data \
6.   -U system \
7.   -W \
8.   --encoding=UTF8 \
9.   --locale=zh_CN.UTF-8
11. # 启动服务
12. sys_ctl -D /data/kingbase/data start
14. # 确认服务状态
15. sys_ctl -D /data/kingbase/data status

复制代码

启动之后第一件事是改默认暗码和设置 ksql 的访问权限。ksql 是 KES 自带的下令行交互工具，跟其他数据库的 CLI 工具用法差不多，SQL 语句直接敲进去就能实行。

1. -- 通过 ksql 连接
2. -- ksql -U system -d test -p 54321
4. -- 改掉默认密码
5. ALTER USER system WITH PASSWORD 'NewStrongP@ss2026';
7. -- 看一下当前数据库列表
8. SELECT datname, datowner, encoding FROM sys_database;

复制代码

设置文件调解
初始化完成后的默认设置只能跑跑测试，生产环境得改几个关键参数。设置文件在数据目次下的 kingbase.conf：

1. -- 这几个参数改完需要重启
2. shared_buffers = 4GB
3. work_mem = 64MB
4. maintenance_work_mem = 512MB
5. effective_cache_size = 12GB
7. -- 连接数根据实际并发来定
8. max_connections = 200
10. -- 日志相关
11. logging_collector = on
12. log_directory = 'sys_log'
13. log_filename = 'kingbase-%Y-%m-%d.log'
14. log_min_duration_statement = 1000
15. log_rotation_age = 1d

复制代码

shared_buffers 一样平常设成物理内存的 25% 左右，不要贪大。我有次设到 60% 结果体系缓存不敷用，IO 反而变高了。work_mem 留意它是每个排序利用各自分配的，并发高的话别设太猛，否则内存会被吃光。
网络访问设置
默认只答应本机毗连，要让其他呆板访问得改两个地方。一个是 kingbase.conf 里的 listen_addresses，另一个是 sys_hba.conf 里的访问控制规则：

1. # kingbase.conf
2. listen_addresses = '*'
3. port = 54321
5. # sys_hba.conf
6. # 允许内网段访问
7. host  all  all  192.168.1.0/24  scram-sha-256

复制代码

改完这两个文件要 reload 一下设置，不消重启：

1. sys_ctl -D /data/kingbase/data reload

复制代码

sys_hba.conf 这个文件相当于数据库的防火墙规则，格式是"毗连范例 数据库 用户 地点 认证方式"。scram-sha-256 是如今保举的暗码认证方式，比老的 md5 更安全。如果涉及跨公网的访问，发起走 SSL 毗连，在 sys_hba.conf 里用 hostssl 代替 host，欺压走加密通道。KES 默认支持 SSL，只必要把证书和密钥放到数据目次下并在 kingbase.conf 里开启 ssl = on 就行。
SQL 开辟与一样平常利用

KES 的 SQL 语法对尺度 SQL 的支持很完备，一样平常开辟用到的 DDL、DML、事件控制都没什么标题。这部分不计划写教科书式的内容，重点记一些现实项目中容易忽略的点。
建表与数据范例选择

建表的时间数据范例选择挺有讲求的。我见过不少项目清一色 VARCHAR + INT + TIMESTAMP，把数据库当 Excel 用了。KES 支持的范例比大多数人用得到的要多不少。

1. CREATE TABLE device_info (
2.     id          BIGSERIAL PRIMARY KEY,
3.     device_code VARCHAR(64) NOT NULL UNIQUE,
4.     device_name VARCHAR(200) NOT NULL,
5.     category    SMALLINT DEFAULT 1,
6.     specs       JSONB,
7.     tags        TEXT[],
8.     location    POINT,
9.     status      SMALLINT DEFAULT 1,
10.     created_at  TIMESTAMP DEFAULT now(),
11.     updated_at  TIMESTAMP DEFAULT now()
12. );
14. -- JSONB 类型特别适合存半结构化的配置信息
15. INSERT INTO device_info (device_code, device_name, specs)
16. VALUES (
17.     'DEV-20260101-001',
18.     '温湿度传感器-A3',
19.     '{"protocol": "MQTT", "interval": 30, "unit": "celsius"}'::jsonb
20. );
22. -- 查询 JSONB 里的字段
23. SELECT device_code,
24.        specs->>'protocol' AS protocol,
25.        (specs->>'interval')::int AS report_interval
26. FROM device_info
27. WHERE specs ? 'protocol';

复制代码

数组范例存标签、脚色列表这类东西很方便，省得建额外的关联表。JSONB 用来存设置项、扩展属性这种半结构化数据，比搞一堆 VARCHAR 列强多了。
事件与并发控制

KES 的事件管理跟尺度 SQL 划一，BEGIN / COMMIT / ROLLBACK 这套东西没什么好说的。说一个现实遇到的标题。
有个项目上线后发现频仍出现死锁。排查下来是由于两个业务模块同时更新同一批数据，但更新序次不一样——模块 A 先更新订单表再更新库存表，模块 B 反过来先更新库存表再更新订单表，并发一高就死锁了。办理方法是包管全部涉及多行更新的业务逻辑按固定序次利用，开辟团队约定了一个同一的表利用优先级规范。
别的，KES 支持 NOWAIT 和 SKIP LOCKED 语法，在高并发抢锁的场景下很有用：

1. -- 抢不到锁就立即返回错误，不傻等
2. SELECT * FROM task_queue
3. WHERE status = 0
4. FOR UPDATE NOWAIT;
6. -- 跳过已被其他事务锁定的行，处理下一批
7. SELECT * FROM task_queue
8. WHERE status = 0
9. FOR UPDATE SKIP LOCKED
10. LIMIT 10;

复制代码

SKIP LOCKED 特别恰当做使命队列这种场景，多个斲丧者同时取使命，各自拿到不重复的使命行止理，不会相互壅闭。之前有个项目用一张表做消息队列，没有 SKIP LOCKED 之前常常由于锁等候导致使命分发延伸，加上之后吞吐量直接翻了两倍多。以是如果你的业务有雷同的并发模子，这两个语法肯定要用起来。
批量利用性能

批量插入数据的时间别一条一条 INSERT，用 COPY 下令会快几个数目级。这个履历实用于大多数关系型数据库。COPY 走的是二进制协议，跳过了 SQL 分析和优化的开销，百万级数据的导入通常在十几秒内就能完成：

1. -- 从 CSV 文件批量导入，速度比 INSERT 快得多
2. COPY device_info (device_code, device_name, category)
3. FROM '/data/import/devices.csv'
4. WITH (FORMAT csv, HEADER true, DELIMITER ',');
6. -- 如果是程序里拼接批量 INSERT，至少用多值语法
7. INSERT INTO device_info (device_code, device_name, category)
8. VALUES
9.     ('DEV-001', '温度传感器', 1),
10.     ('DEV-002', '压力传感器', 2),
11.     ('DEV-003', '流量计', 3);

复制代码

更新和删除大量数据的时间也有讲求。一次性 DELETE 几万万行会长时间持有大量锁，影响线上业务。发起分批利用，每次处理处罚一小批，中心让出锁：

1. -- 分批删除过期数据
2. DO $$
3. DECLARE
4.     batch_size INT := 5000;
5.     deleted INT;
6. BEGIN
7.     LOOP
8.         DELETE FROM sensor_data
9.         WHERE ctid IN (
10.             SELECT ctid FROM sensor_data
11.             WHERE record_time < '2024-01-01'
12.             LIMIT batch_size
13.         );
14.         GET DIAGNOSTICS deleted = ROW_COUNT;
15.         COMMIT;
16.         EXIT WHEN deleted < batch_size;
17.         -- 暂停一下，给其他事务让路
18.         PERFORM pg_sleep(0.5);
19.     END LOOP;
20. END $$;

复制代码

安全管理：三权分立与数据加密

安全这块是 KES 比力强的地方，毕竟过了等保四级认证的产物。许多政企项目对数据库安全有硬性要求，不达标验收都过不了。KingbaseES 在安全方面做了许多工作，从访问控制到数据加密到审计追踪，形成了一套比力完备的安全防护体系。
三权分立

KES 支持三权分立的安全管理模式，把数据库管理权限拆分成三个脚色：体系管理员（SYSSO）负责一样平常运维和对象管理，安全管理员（SECO）负责安全战略和审计设置，审计管理员（AUDSO）负责审计日记的检察和管理。三个脚色相互制约，任何一个人拿不到全部权限。

1. -- 启用三权分立需要修改配置
2. -- kingbase.conf 中设置
3. -- enable_sec_admin = on
4. -- 改完重启生效
6. -- 查看当前角色和权限分配
7. SELECT rolname, rolsuper, rolcreatedb, rolcreaterole, rolcanlogin
8. FROM sys_roles
9. ORDER BY rolname;

复制代码

三权分离这个计划思绪着实跟企业管理里的"不相容职务分离"是一个原理。体系管理员能建表建用户但看不到审计日记，审计管理员能看到全部人的利用记载但改不了数据和设置，安全管理员管战略但碰不到业务数据。
用户和权限管理

权限分配依照最小化原则，别图省事给平凡应用账号 SUPERUSER 权限。我见过好几个项目为了调试方便直接给 dba 权限上线的，背面审计的时间全被打了返来。

1. -- 创建只读用户
2. CREATE ROLE readonly_user WITH LOGIN PASSWORD 'Read@2026';
3. GRANT CONNECT ON DATABASE production TO readonly_user;
4. GRANT USAGE ON SCHEMA public TO readonly_user;
5. GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_user;
7. -- 设置默认权限，以后新建的表也自动有 SELECT 权限
8. ALTER DEFAULT PRIVILEGES IN SCHEMA public
9. GRANT SELECT ON TABLES TO readonly_user;
11. -- 创建应用用户，只给增删改查权限
12. CREATE ROLE app_user WITH LOGIN PASSWORD 'App@2026';
13. GRANT CONNECT ON DATABASE production TO app_user;
14. GRANT USAGE, CREATE ON SCHEMA public TO app_user;
15. GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;

复制代码

透明数据加密 TDE

KES 支持透明数据加密，也就是 TDE。开启之后数据在磁盘上是加密存储的，读写的时间由数据库引擎自动加解密，应用层完全无感知。对于存储敏感信息的场景，这个功能是刚需。

1. -- 创建加密表空间
2. CREATE TABLESPACE encrypted_ts
3. LOCATION '/data/kingbase/encrypted'
4. WITH (encrypt_type = 'SM4');
6. -- 在加密表空间上建表
7. CREATE TABLE user_identity (
8.     id          BIGSERIAL PRIMARY KEY,
9.     user_name   VARCHAR(100) NOT NULL,
10.     id_card     VARCHAR(18) NOT NULL,
11.     phone       VARCHAR(20),
12.     created_at  TIMESTAMP DEFAULT now()
13. ) TABLESPACE encrypted_ts;

复制代码

加密算法支持国密 SM4，也支持 AES。选型的时间根据合规要求来定，政务类项目一样平常要求国密算法。必要留意的是，加密表空间对性能有肯定影响，大概在 5% 到 10% 左右，详细看数据量和读写比例。
审计设置

审计功能可以记载指定用户或指定利用的访问日记，事后追溯谁在什么时间做了什么利用。开启方式不复杂：

1. -- 通过安全管理员配置审计策略
2. -- 记录所有 DDL 操作
3. SELECT audit_set_rule('audit_ddl', 'on');
5. -- 记录对敏感表的访问
6. SELECT audit_set_object('public.user_identity', 'select,insert,update,delete');
8. -- 查看审计日志
9. SELECT event_time, username, event_type, object_name, statement
10. FROM sys_audit_log
11. WHERE event_time > now() - INTERVAL '1 day'
12. ORDER BY event_time DESC
13. LIMIT 50;

复制代码

审计日记量大的话记得定期归档和清算，别让审计表把磁盘撑满了。我就遇到过这种事，审计开了半年没人管，某天磁盘报警才发现审计日记占了 200 多 G。
备份规复与高可用

数据备份这事不消多说了，没备份的数据库就是在裸奔。KES 自带的备份工具叫 sys_rman，功能跟 Oracle 的 RMAN 差不多，支持全量备份、增量备份和时间点规复。
物理备份

1. # 全量备份
2. sys_rman -F /data/kingbase/backup backup full
4. # 增量备份（基于上次全量或增量）
5. sys_rman -F /data/kingbase/backup backup incremental
7. # 查看备份集信息
8. sys_rman -F /data/kingbase/backup show
10. # 清理过期备份（保留最近 7 天）
11. sys_rman -F /data/kingbase/backup delete --older-than 7d

复制代码

发起的备份战略是每周一次全量，每天一次增量，备份保存周期根据业务必要和磁盘空间来定。备份完了别忘了验证，sys_rman 支持 validate 下令：

1. # 验证备份完整性
2. sys_rman -F /data/kingbase/backup validate

复制代码

不验证的备份跟没有备份区别不大。之前有个客户的数据库硬盘坏了，拿备份出来规复的时间才发现三个月前的某次备份文件就坏了，中心不停没验证过。末了只能规复到更早的时间点，丢了不少数据。
时间点规复 PITR

误删数据是 DBA 的噩梦。KES 支持 PITR（Point-In-Time Recovery），可以把数据库规复到已往恣意一个时间点，条件是归档日记要完备。

1. # 恢复步骤概要
2. # 1. 停库
3. sys_ctl -D /data/kingbase/data stop
5. # 2. 恢复基础备份
6. sys_rman -F /data/kingbase/backup restore --target-time "2026-06-04 15:30:00"
8. # 3. 配置恢复目标
9. # 在 kingbase.auto.conf 中设置
10. # recovery_target_time = '2026-06-04 15:30:00'
11. # recovery_target_action = 'promote'
13. # 4. 启动恢复
14. sys_ctl -D /data/kingbase/data start

复制代码

PITR 的条件是连续归档要正常。归档设置在 kingbase.conf 里：

1. archive_mode = on
2. archive_command = 'cp %p /data/kingbase/archive/%f'

复制代码

归档目次别跟数据目次放在同一块盘上，盘坏了就全没了。有条件的话用 NFS 大概对象存储做归档目标地。
高可用集群

生产环境的 KES 一样平常摆设成主备集群。主库处理处罚读写哀求，备库通过流复制实时同步数据。主库挂了可以手动切换也可以自动切换。KES 自带的高可用组件能实现自动故障检测和切换，RTO 通常控制在 30 秒以内。

1. # 备库搭建：基于主库做基础备份
2. sys_basebackup -h primary_host -p 54321 -U replication_user \
3.   -D /data/kingbase/standby \
4.   -Fp -Xs -P
6. # 备库配置 recovery 参数
7. # kingbase.auto.conf
8. primary_conninfo = 'host=primary_host port=54321 user=replication_user password=xxx'
9. hot_standby = on

复制代码

流复制有两种模式：同步复制包管 RPO 为零，每条事件至少在备库写了一份 WAL 才算提交乐成；异步复制性能更好但大概丢少量数据。关键业务用同步，非关键业务用异步，看详细弃取。

1. -- 查看复制状态
2. SELECT pid, usename, application_name, client_addr,
3.        state, sync_state, sent_lsn, write_lsn, flush_lsn, replay_lsn
4. FROM sys_stat_replication;

复制代码

这里有个要留意的地方：同步复制对网络延伸很敏感。如果主备之间网络延伸高出 5 毫秒，写入性能就会显着降落。跨机房摆设的时间测一下延伸再决定用同步照旧异步。
一样平常监控与性能诊断

数据库监控做得好不好直接决定你能不能提前发现标题。等用户打电话说"体系怎么这么慢"再去查，每每已经晚了。我风俗把监控分成三层：第一层是利用体系级别的，CPU、内存、磁盘 IO、网络带宽；第二层是数据库实例级别的，毗连数、事件量、锁等候、缓存掷中率；第三层是 SQL 级别的，慢查询、实行操持、索引利用环境。这篇文章重点说后两层。
KWR 性能陈诉

KES 内置了一个叫 KWR（Kingbase Workload Repository）的性能收罗工具，功能跟 Oracle 的 AWR 陈诉很像。它会周期性地给数据库拍快照，记载各种性能指标的累积值。对比两个快照之间的差别就能看出这段时间数据库的负载环境。

1. -- 确认 KWR 扩展已安装
2. CREATE EXTENSION IF NOT EXISTS sys_kwr;
4. -- 手动创建一个快照
5. SELECT sys_kwr_snapshot();
7. -- 生成两个快照之间的性能报告
8. -- 先查看快照 ID
9. SELECT snap_id, snap_time FROM sys_kwr_snapshots ORDER BY snap_id DESC LIMIT 10;
11. -- 生成报告（输出到文件）
12. \o /tmp/kwr_report.html
13. SELECT sys_kwr_report(101, 105, 'html');
14. \o

复制代码

KWR 陈诉里的信息量很大，我一样平常重点看几个部分：等候变乱排名、TOP SQL（按总耗时和调用次数排序）、缓存掷中率、查抄点统计。如果某个等候变乱突然飙升，根本就能定位到瓶颈在哪。
活泼会话分析

KSH（Kingbase Session History）记载每个活泼会话在采样时间的等候变乱和实行信息，粒度比 KWR 更细。恰当排查某个时间点的性能抖动。

1. -- 启用 KSH
2. CREATE EXTENSION IF NOT EXISTS sys_ksh;
4. -- 查看最近 5 分钟最耗时的等待事件
5. SELECT wait_event_type, wait_event, count(*)
6. FROM sys_ksh
7. WHERE sample_time > now() - INTERVAL '5 minutes'
8. GROUP BY 1, 2
9. ORDER BY 3 DESC
10. LIMIT 10;
12. -- 查看某段时间内执行最慢的 SQL
13. SELECT query_id, query, calls, total_time, mean_time
14. FROM sys_ksh_statements
15. WHERE sample_time > now() - INTERVAL '1 hour'
16. ORDER BY mean_time DESC
17. LIMIT 10;

复制代码

实时会话与锁监控

一样平常巡检的时间常常要看当前有没有长时间运行的事件、有没有锁等候。几条常用查询：

1. -- 当前活跃会话
2. SELECT pid, usename, application_name, client_addr,
3.        state, wait_event_type, wait_event,
4.        now() - query_start AS duration, query
5. FROM sys_stat_activity
6. WHERE state != 'idle'
7. ORDER BY duration DESC;
9. -- 锁等待分析
10. SELECT blocked.pid AS blocked_pid,
11.        blocked.query AS blocked_query,
12.        blocking.pid AS blocking_pid,
13.        blocking.query AS blocking_query,
14.        now() - blocked.query_start AS wait_duration
15. FROM sys_stat_activity blocked
16. JOIN sys_locks l ON blocked.pid = l.pid AND NOT l.granted
17. JOIN sys_locks granted ON l.locktype = granted.locktype
18.     AND l.database IS NOT DISTINCT FROM granted.database
19.     AND l.relation IS NOT DISTINCT FROM granted.relation
20.     AND granted.granted = true
21. JOIN sys_stat_activity blocking ON granted.pid = blocking.pid
22. WHERE blocked.pid != blocking.pid;
24. -- 长时间未提交的事务（超过 5 分钟）
25. SELECT pid, usename, now() - xact_start AS xact_duration, query
26. FROM sys_stat_activity
27. WHERE state = 'idle in transaction'
28.   AND now() - xact_start > INTERVAL '5 minutes'
29. ORDER BY xact_duration DESC;

复制代码

idle in transaction 这种状态特别值得鉴戒。事件打开了但没有提交，不停挂着，持有的锁不开释。如果挂太久，VACUUM 都没法接纳死元组，表会越来越大。发起在 kingbase.conf 里设个超时：

1. idle_in_transaction_session_timeout = 300000  -- 5 分钟，单位毫秒

复制代码

磁盘和表空间监控

写个简朴的巡检脚本定期跑一下，把表空间利用环境、大表列表、索引膨胀率这些都收罗出来。不消搞得太复杂，shell 脚本加上 ksql 就够用：

1. #!/bin/bash
2. # db_check.sh - 简单巡检脚本
3. DATA_DIR="/data/kingbase/data"
4. KSQL="ksql -U system -d production -t -A -c"
6. echo "===== 磁盘使用 ====="
7. df -h $DATA_DIR
9. echo ""
10. echo "===== 数据库大小 ====="
11. $KSQL "SELECT datname, sys_size_pretty(sys_database_size(datname))
12.        FROM sys_database ORDER BY sys_database_size(datname) DESC;"
14. echo ""
15. echo "===== TOP 10 大表 ====="
16. $KSQL "SELECT schemaname||'.'||relname AS table_name,
17.        sys_size_pretty(sys_total_relation_size(relid)) AS total_size,
18.        n_live_tup AS row_count
19.        FROM sys_stat_user_tables
20.        ORDER BY sys_total_relation_size(relid) DESC LIMIT 10;"
22. echo ""
23. echo "===== 未使用的索引 ====="
24. $KSQL "SELECT schemaname||'.'||indexrelname AS index_name,
25.        sys_size_pretty(sys_relation_size(indexrelid)) AS size,
26.        idx_scan AS scan_count
27.        FROM sys_stat_user_indexes
28.        WHERE idx_scan = 0
29.        ORDER BY sys_relation_size(indexrelid) DESC LIMIT 10;"
31. echo ""
32. echo "===== 表膨胀估算 ====="
33. $KSQL "SELECT schemaname||'.'||relname AS table_name,
34.        n_dead_tup AS dead_tuples,
35.        round(100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0), 1) AS dead_ratio
36.        FROM sys_stat_user_tables
37.        WHERE n_dead_tup > 10000
38.        ORDER BY n_dead_tup DESC LIMIT 10;"

复制代码

这种脚本共同 crontab 每天跑一次，结果发个邮件大概写到共享目次里，巡检服从会高许多。
常见标题与排查思绪

最跋文几个现实遇到过的范例标题。
毗连数打满

应用突然连不上数据库，报错 “sorry, too many clients already”。第一反应是查 max_connections，但光加大这个参数治标不治本。

1. -- 看看到底是哪些连接占着
2. SELECT state, count(*) FROM sys_stat_activity GROUP BY state;
3. -- 看各个来源 IP 的连接数
4. SELECT client_addr, count(*) FROM sys_stat_activity
5. WHERE client_addr IS NOT NULL
6. GROUP BY client_addr ORDER BY 2 DESC;

复制代码

常见缘故原由有这么几种：应用端毗连池没配好，毗连走漏了没归还；idle in transaction 的毗连太多占着坑不干活；max_connections 自己设太小了。如果并发确实高，在前面挡一层毗连池中心件比直接加 max_connections 靠谱得多。
慢查询定位

用户反馈某个功能特别慢。先在日记里找慢 SQL——前面设置了 log_min_duration_statement = 1000，高出 1 秒的查询都会记到日记里。日记文件在数据目次下的 sys_log 子目次里，用 grep 搜 “duration” 关键字就能快速定位。固然，如果你的慢查询阈值设得比力低（比如 500 毫秒），日记量会比力大，发起只在排查标题标时间暂时调低，排查完了改返来。

1. -- 也可以直接从视图里查
2. SELECT query, calls, total_time, mean_time, rows
3. FROM sys_stat_statements
4. WHERE mean_time > 500
5. ORDER BY mean_time DESC
6. LIMIT 20;

复制代码

拿到慢 SQL 之后用 EXPLAIN ANALYZE 看实行操持，重点关注是不是走了全表扫描、Nested Loop 嵌套层数是不是太多、有没有暂时文件排序。大多数性能标题都是缺索引大概索引选错了导致的。

1. -- 看执行计划
2. EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
3. SELECT d.device_name, avg(s.temperature) AS avg_temp
4. FROM sensor_data s
5. JOIN device_info d ON s.device_id = d.id
6. WHERE s.record_time > now() - INTERVAL '7 days'
7. GROUP BY d.device_name
8. ORDER BY avg_temp DESC;

复制代码

VACUUM 相干标题

KES 用 MVCC 机制管理数据版本，删除和更新利用不会真正移除旧数据行，而是标志为死元组。VACUUM 负责接纳这些死元组占用的空间。如果 VACUUM 跟不上写入速率，表就会连续膨胀，查询性能也会降落——由于扫描的时间要跳过大量的死元组，白白浪费 IO。
这个标题平常不容易发现，比及表膨胀得很锋利了才会袒暴露来。我遇到过一个表，业务上每天大量更新，autovacuum 不停追不上写入速率，半年下来表的物理巨细涨了快要三倍，但现实有用数据行只多了 30%。

1. -- 查看哪些表需要 VACUUM
2. SELECT schemaname||'.'||relname AS table_name,
3.        n_dead_tup AS dead_tuples,
4.        n_live_tup AS live_tuples,
5.        last_vacuum, last_autovacuum
6. FROM sys_stat_user_tables
7. WHERE n_dead_tup > 10000
8.   AND n_dead_tup > n_live_tup * 0.1
9. ORDER BY n_dead_tup DESC;
11. -- 手动 VACUUM 某个表（带分析）
12. VACUUM ANALYZE sensor_data;
14. -- 看 autovacuum 是否正常工作
15. SELECT pid, query, now() - query_start AS duration
16. FROM sys_stat_activity
17. WHERE query LIKE 'autovacuum%'
18. ORDER BY duration DESC;

复制代码

autovacuum 一样平常不消手动干预，但对于写入量特别大的表，默认的 autovacuum 参数大概不敷激进，可以恰当调大 autovacuum_vacuum_scale_factor 和 autovacuum_analyze_scale_factor。
总结

这篇文章覆盖了 KES 数据库从安装到一样平常运维的重要利用环节。摆设环节的关键是环境初始化和参数调优，特别是内存参数和兼容模式的选择，这两项一旦定下来背面改动资本很高；安全方面三权分立和 TDE 是 KingbaseES 比力有特色的功能，政务和金融项目根本都要用上，审计日记的存储规划也要提前做好；备份规复要形成制度，全量加增量的组合战略加上定期验证，确保关键时间真的能规复出来；监控诊断靠 KWR 和 KSH 这两个内置工具就能搞定大部分场景，共同一个简朴的巡检脚本根本够用了。
KES 这几年迭代速率挺快，从 V8 到 V9 在性能和易用性上都有显着进步。用的过程中遇到标题多看官方文档，文档中心 help.kingbase.com.cn 上的内容照旧比力全的。别的社区里也有不少实践履历可以参考，遇到坑的时间搜一搜每每能找到雷同的办理思绪。
数据库运维这个活儿说到底就是"防备为主、治疗为辅"。备份做好、监控到位、定期巡检，大部分标题都能在变成变乱之前处理处罚掉。与其花三天时间规复一个本可以克制的故障，不如每天花非常钟看看监控数据。这话固然老生常谈，但真正做到的人确实不多。共勉。