简介《VASTDATA Vastbase G100 V2.2用户手册》面向数据库管理员、开发人员及信创项目技术人员系统讲解基于openGauss开发的国产数据库Vastbase G100的使用方法帮助读者快速建立从概念到实操的完整认知。资源包共1个PDF文件约8.76MB内容涵盖数据库逻辑结构图、数据查询请求处理过程、事务管理及相关概念并详细说明连接数据库的多种方式配置服务端远程连接、使用vsql连接、应用程序接口、关闭数据库、创建和管理数据库、规划存储模型、列存数据压缩以及表空间管理等操作要点。手册目录层级清晰从概述逐步深入到具体操作指导便于按模块查阅与对照实践。目前已有198人学习适合需要了解国产化数据库解决方案、开展信创数据库部署与日常管理工作的技术人员参考使用。1. 拿到一份 700 多页的国产库手册先别急着从头翻信创项目里被问到“这个库到底怎么连、怎么建表、怎么迁”手边只有一份 Vastbase G100 V2.2 用户手册很多人第一反应是从第 1 页读到最后一页结果读到第 3 章已经忘了第 2 章讲的事务隔离级别。这份手册的真实用法不是通读而是当字典查先立住逻辑结构、连接方式、存储模型这三根柱子剩下的建表、分区、权限、备份按需翻。它面向的是正在做信创数据库选型和落地的从业者——已经会用某一种关系型库现在要在一个基于 openGauss 路线的国产库上把活干完。手册覆盖了从 vsql 连接、JDBC/ODBC 开发、表空间与分区表管理到客户端认证、SSL、三权分立的完整链路够你把一个业务库从零搭到能跑。下面按我实际拆这份文档的顺序讲哪些章节值得精读、哪些命令能直接抄、哪些参数改错会翻车。2. 先把逻辑结构和连接链路立住vsql、JDBC、ODBC 三条路怎么选2.1 逻辑结构决定了你后面所有操作的边界手册第 2 章给的数据库逻辑结构图本质上是把“实例—数据库—schema—表/索引/视图”这四层摊开给你看。Vastbase G100 沿的是 openGauss 那套多数据库实例模型一个实例下可以挂多个数据库数据库之间默认不互通跨库访问要么走 schema 映射要么走外部表。这一点和某些单库多 schema 的库不一样新手最容易在这里翻车——以为建了库就能直接select另一库的表结果报对象不存在。我一般会先确认三件事再动手当前连的是哪个库select current_database();、默认 schema 是不是public、以及search_path里挂了哪些 schema。手册 3.11.1 讲 schema 管理时提到 schema 是表的命名空间权限也是按 schema 授的所以规划阶段就要把“业务 schema / 公共 schema / 临时 schema”分开别全塞 public。数据查询请求的处理过程那一节讲的是解析、优化、执行三段实际排障时有用一条 SQL 慢先看是解析阶段被规则改写拖住还是执行阶段扫描量太大手册里对执行计划的入口有交代配合explain能定位。2.2 三条连接路径的适用场景和最小可用配置手册 3.2 把连接分成服务端远程连接配置、vsql 命令行、应用程序接口三类。选型上我的经验是运维和排障走 vsqlJava 业务走 JDBCC/C 或老系统对接走 ODBC 或 libpq。三条路的服务端前置条件是一样的——pg_hba.conf里放行客户端网段、postgresql.conf里listen_addresses不能只绑 localhost。手册 5.1.1 配置客户端接入认证那节把 hba 的认证方式列全了trust、md5、sha256、cert 都有生产环境别用 trust这是血泪经验。vsql 连接的最小命令长这样参数含义我标在注释里# -h 服务端地址-p 端口默认 5432 视部署而定-d 目标库-U 用户名 vsql -h 192.168.10.21 -p 5432 -d business_db -U app_user -W # -W 表示交互式输入密码避免密码进 shell history连上之后先跑一遍环境自检确认字符集、时区、版本对得上-- 确认版本与字符集迁移前必查 select version(); show server_encoding; show timezone; -- 确认当前 search_path避免建表建错 schema show search_path;JDBC 这边手册 4.2 给了驱动版本与 JDK 兼容性对照加载驱动的写法是标准的Class.forName连接串里currentSchema参数建议显式指定别依赖默认。连接池那节提到要配prepareThreshold和defaultRowFetchSize前者影响预编译语句缓存后者影响大结果集的分批拉取两个都不配的话批量查询容易把客户端内存顶爆。ODBC 的坑在驱动替换手册 4.3.2 要求先装 unixODBC 再替换客户端驱动odbcinst.ini和odbc.ini两个文件分别管驱动和数据源配完用isql -v 数据源名测通再上业务别跳过这步直接联调。2.3 关库和参数配置别在业务高峰动手册 3.3 给了两种关库方式SQL 语句关和vb_ctl工具关。区别在于vb_ctl stop支持-m模式参数smart 等现有连接断完、fast 回滚未提交事务后关、immediate 直接杀。生产上我一般用 fastsmart 在长连接场景下可能等半小时都关不掉。3.10 配置数据库参数那节强调部分参数要重启生效、部分 reload 即可改之前先用show 参数名看当前值改完用select * from pg_settings where namexxx;确认pending_restart字段别改完以为生效了其实还挂在待重启状态。3. 建表、分区、压缩存储模型选错后面全是补丁3.1 行存还是列存先看查询模式再定手册 3.5 规划存储模型这节是整份文档里最该精读的部分之一。行存适合 OLTP 那种按行增删改、点查多的场景列存适合宽表聚合、大批量扫描的分析场景。Vastbase G100 的列存表在 3.6 还专门讲了压缩列存加压缩对历史数据归档类业务很划算但列存表的更新代价高频繁 update 的表别选列存这是选型阶段就要定死的后期改存储模型等于重建表加迁数据。建表时几个关键子句我一般会显式写全不靠默认值-- 行存表指定填充因子和表空间避免默认值带来的意外 create table t_order ( order_id bigint primary key, customer_id bigint not null, amount numeric(18,2), create_time timestamp default now() ) with (fillfactor80) tablespace tbs_business; -- 列存表开启压缩适合分析型宽表 create table t_order_archive ( order_id bigint, customer_id bigint, amount numeric(18,2), create_time timestamp ) with (orientationcolumn, compressionlow) tablespace tbs_archive;fillfactor80是给行存表留更新空间页内预留 20% 减少行迁移orientationcolumn切列存compression取 low/middle/high压缩比越高 CPU 开销越大归档表用 low 到 middle 就够。表空间要先建好再引用手册 3.7 的表空间管理里提到表空间对应物理目录建之前确认目录权限归数据库运行用户否则建表直接报权限错。3.2 分区表default 分区是兜底不是万能手册 3.8.8 分区表那节篇幅不小支持 range、list、hash 几种3.8.8.1 还专门讲了 default 分区。default 分区的作用是接住所有不落在已定义分区里的数据好处是不会因为插入越界值报错坏处是数据悄悄进了兜底分区你都不知道。我的做法是default 分区建上但配一个定时任务查 default 分区的行数超过阈值就告警然后补建对应分区再把数据挪过去。-- 按范围分区带 default 兜底 create table t_log ( log_id bigint, log_time timestamp not null, content text ) partition by range (log_time) ( partition p202401 values less than (2024-02-01), partition p202402 values less than (2024-03-01), partition p_default values less than (maxvalue) ); -- 查兜底分区积压情况定期跑 select count(*) from t_log partition (p_default);分区键的选择有个硬约束分区键必须是主键或唯一约束的一部分否则建表直接失败。很多人从别的库迁过来习惯用自增 id 做主键、用时间做分区键到这儿就卡住解决办法是把分区键并进主键或者放弃该表的主键约束改用唯一索引。手册里对分区表的局部索引和全局索引也有区分分区表上的唯一索引如果没带分区键只能是全局索引维护代价更高这点在 3.11.2 索引管理里能对上。3.3 闪回表和全局临时表两个容易被忽略的后悔药手册 3.8.6 闪回表和 3.8.7 全局临时表是实际运维里救过命的两个特性。闪回表依赖表的删除记录保留误删数据后在一定时间窗口内能把表恢复到删除前状态前提是回收站机制没被清。全局临时表的会话隔离性要搞清楚on commit preserve rows和on commit delete rows两种行为差别很大前者会话内一直保留、后者提交即清用错会导致“数据莫名其妙没了”或者“临时表越积越大”。-- 全局临时表会话级保留适合中间结果集 create global temporary table tmp_calc ( id bigint, val numeric ) on commit preserve rows; -- 闪回误删的表需回收站内对象仍存在 flashback table t_order to before drop;闪回不是万能的表被 drop 之后如果回收站被清或者过了保留期就只能走备份恢复。所以 3.11.6 的vb_basebackup备份和 3.11.7 的表空间备份该配还得配闪回当第一道防线备份当最后一道。4. 权限、认证与 SSL安全章节不是选读是上线前必过4.1 三权分立和行级访问控制怎么落地手册 5.2 管理用户及权限这章5.2.3 三权分立是信创场景里经常被审计点名的一项把系统管理员、安全管理员、审计管理员分开互相制约。落地时不是建三个用户就完事要确认审计功能真的开了、审计日志有独立存放路径、安全管理员不能自己改自己的权限。5.2.8 行级访问控制RLS适合多租户或者按部门隔离数据的场景策略写在表上查询时自动加过滤条件比在应用层拼 where 靠谱但要注意 RLS 对性能有影响策略表达式别写太复杂。-- 开启行级访问控制并建策略只允许看到本部门数据 alter table t_order enable row level security; create policy p_dept on t_order using (dept_id current_setting(app.dept_id)::bigint); -- 会话里设置当前部门上下文 set app.dept_id 1001;current_setting读的是会话变量应用连接建立后先set再查这个模式在连接池场景下要小心连接复用时会话变量可能残留最好在每次借出连接时重置。4.2 SSL 连接和连接数监控手册 5.1.3 的 SSL 证书管理和 5.1.4 用 SSL 做安全 TCP/IP 连接是跨网段部署时的必配项。证书生成那节给了自签流程生产环境建议用内部 CA 签发服务端配sslon、ssl_cert_file、ssl_key_file客户端 JDBC 连接串加ssltruesslmodeverify-fullODBC 在数据源里勾 SSL 选项。配完一定要用vsql sslmodeverify-full ...验证一次别只看配置文件以为成了。连接数监控在 5.1.5核心是查pg_stat_activity-- 按用户和状态统计连接数定位连接泄漏 select usename, state, count(*) from pg_stat_activity group by usename, state order by count(*) desc; -- 查长时间 idle in transaction 的连接这类最占资源 select pid, usename, state, now()-state_change as idle_time from pg_stat_activity where state idle in transaction order by idle_time desc;idle in transaction是连接池配置不当的典型症状事务开了没提交、连接又被还回池里时间一长把连接数占满。解决办法是连接池配maxLifetime和事务超时数据库侧配idle_in_transaction_session_timeout兜底。5. 避坑与排查这五条是我在真实环境里踩出来的5.1 远程连不上先查 hba 再查防火墙现象本地 vsql 能连另一台机器连报“no pg_hba.conf entry”。原因pg_hba.conf只放行了 127.0.0.1没加客户端网段。解决在 hba 里加一行host all all 192.168.10.0/24 sha256然后vb_ctl reload让配置生效不用重启。改完用vsql -h 目标IP从客户端侧验证别在服务端本机测本机走的是 local 规则。5.2 建表报“tablespace does not exist”目录权限是根因现象create table ... tablespace tbs_xxx报表空间不存在或权限拒绝。原因表空间目录建了但属主不是数据库运行用户或者建表空间时路径写错。解决先\db列出已有表空间确认名字再检查目录ls -ld属主用create tablespace tbs_xxx location /data/tbs_xxx;重建路径必须是绝对路径且目录为空。5.3 JDBC 批量插入慢得离谱reWriteBatchedInserts没开现象同样的批量 insert别的库几秒跑完这边几分钟。原因驱动默认把批量语句逐条发没合并成多值插入。解决连接串加reWriteBatchedInsertstrue配合prepareThreshold5让驱动在第五次执行后转预编译。改完用explain看执行计划确认是批量形态别只看耗时下降就以为对了。5.4 分区表插入报“no partition for tuple”default 分区没建或没生效现象插入一条时间超出已定义分区范围的数据直接报错。原因建分区表时没加 default 分区或者 default 分区建了但maxvalue写法不对。解决补建partition p_default values less than (maxvalue)注意 maxvalue 是关键字不是字符串。补建后历史越界数据不会自动迁移要手动insert into ... select挪过去再删原数据。5.5 改完参数没生效pending_restart是黑匣子现象alter system set改了参数show看还是旧值。原因该参数属于 postmaster 级别必须重启才生效reload 只对 sighup 级别参数有效。解决改完查select name, setting, pending_restart from pg_settings where name参数名;pending_restart为 t 就说明要重启挑维护窗口执行vb_ctl restart别在业务高峰赌运气。6. 进阶把手册当查询字典配一套自己的验证脚本手册 700 多页真正高频用到的其实集中在几个入口连接与认证3.2、5.1、存储与分区3.5、3.8、权限5.2、备份3.11.6。我的习惯是给每个入口配一段可重复执行的验证 SQL部署完新环境先跑一遍比翻文档逐条核对快得多。下面这套自检脚本覆盖了版本、字符集、连接数、表空间、分区兜底、参数待重启六个维度跑完输出一张体检表-- 环境体检一次性输出关键状态 select version as item, version() as val union all select encoding, current_setting(server_encoding) union all select connections, count(*)::text from pg_stat_activity union all select tablespaces, count(*)::text from pg_tablespace union all select pending_restart, count(*)::text from pg_settings where pending_restart union all select idle_in_txn, count(*)::text from pg_stat_activity where state idle in transaction;这段脚本的价值在于把分散在手册各章的检查点收拢成一次执行新环境上线前跑一遍pending_restart不为 0 就说明有参数改了没重启idle_in_txn偏高就说明连接池配置有问题。配合前面 5.1 的 hba 检查、5.4 的 default 分区积压查询基本能覆盖部署阶段八成以上的低级故障。再往深一层手册 4.2.9 连接池和 4.4 基于 libpq 开发这两节适合做中间件或自研网关的团队精读。libpq 那套接口在国产化替代里经常被用来对接老 C 系统手册给的连接参数和错误码处理是排障依据。JDBC 的ResultSet游标用法4.2.6.2在处理百万行导出时比一次性 fetch 稳得多配fetchSize分批拉内存曲线是平的而不是锯齿。从那以后我每次接手一个新库环境都强制先跑一遍这套体检脚本再谈业务迁移翻车次数明显下来了。手册本身不会告诉你哪条参数在你这套部署里会咬人但把它的章节入口和自检脚本绑在一起用至少能把“改完没生效”“连不上”“分区越界”这几类问题挡在上线之前。希望帮到你。本文还有配套的精品资源点击获取