简介《VASTDATA Vastbase G100 V2.2用户手册》面向国产化数据库Vastbase G100的初学者、开发与运维人员提供从产品概况到日常操作的完整指引帮助读者理解信创数据库的逻辑结构图、数据查询请求处理过程以及管理事务等核心概念适合作为上手与查阅的基础资料。压缩包内仅有1个PDF文件大小约8.76MB内容集中、便于离线检索和按目录跳读。手册围绕数据库使用展开具体涵盖配置服务端远程连接、使用vsql连接、通过应用程序接口操作数据库使用SQL语句或vb_ctl工具关闭数据库以及创建和管理数据库、规划存储模型、列存下的数据压缩、创建和管理表空间等操作要点文中还提示OCR扫描可能存在个别字识别错误或漏识别需要结合上下文理解。目前已有199人学习适合需要快速熟悉Vastbase G100基础使用、连接方式与运维流程的读者收藏参考。1. 拿到一份 400 页的国产数据库手册先别急着从头翻信创数据库选型走到落地这一步绕不开的场景是文档拿到了人也到位了库却起不来。Vastbase G100 V2.2 用户手册这类资料目录从逻辑结构一路铺到 SSL 证书和行级访问控制看着像一本什么都写了的说明书真干活时被翻烂的其实就那么几页——连库、建表、配参数、备份恢复。它解决的是没有专职 DBA 兜底的小团队怎么把国产数据库跑起来这件事开发照着 JDBC、ODBC 章节接驱动运维照着 vsql、vb_ctl、vb_basebackup 章节做启停和对账。适合正在做数据库替换、需要自己动手装库建表的人只想看概念科普的读者翻两章就会觉得枯燥。2. 查询是怎么跑起来的逻辑结构、事务与 vsql 第一条链路2.1 库、schema、表、表空间四层怎么对上手册第 2 章开头那张逻辑结构图很多人扫一眼就翻过去了结果建表时CREATE SCHEMA和CREATE TABLESPACE分不清。这套层次是一个实例数据目录下挂多个 database一个 database 下挂多个 schemaschema 下才是表、索引、视图、序列表空间横切在物理层是表落到哪个目录的映射。分清楚这四层权限规划和备份规划才好做——业务隔离用 schema冷热数据分离用表空间跨库访问只能靠应用层拼装或外部表别指望一条 SQL 跨 database 做 join。层次实际作用常见误用实例 / 数据目录一个运行中的服务进程及其文件集合把实例当库重启前不问清是哪套实例database逻辑隔离与连接入口试图一条 SQL 跨库 joinschema业务模块隔离、权限边界全塞进 public后期权限收不回来tablespace物理落盘位置的映射把表空间当分区表用越分越乱建库这一步有个参数值得提前定死兼容模式。手册 3.4 节列了创建和管理数据库的完整语法其中DBCOMPATIBILITY决定了很多内置函数和类型的行为PG偏 PostgreSQL 习惯A偏 Oracle 习惯。这个值建库时定了就不太好改后面迁移存量 SQL 时函数名、空串与 NULL 的处理差异全从这里冒出来。-- 建业务库编码和兼容模式一次定好别等上线再改 CREATE DATABASE appdb WITH ENCODING UTF8 DBCOMPATIBILITY PG LC_COLLATE zh_CN.utf8 LC_CTYPE zh_CN.utf8 CONNECTION LIMIT 200; -- 建业务 schema避免所有对象堆在 public 下 CREATE SCHEMA app AUTHORIZATION appuser; -- 独立表空间物理目录提前规划到数据盘 CREATE TABLESPACE tbs_app_data LOCATION /data/vastbase/tbs_app;逻辑说明CONNECTION LIMIT是库级连接上限配合后面第 5 章要讲的连接数排查一起用AUTHORIZATION把 schema 的属主直接给业务账号省掉后续一串 GRANT表空间LOCATION必须是服务进程有读写权限的绝对路径且该目录要预先建好并改属主这一条翻车率极高。2.2 一条 SQL 在库里走了几步手册 2.2 节那张数据查询请求处理过程图价值不在背流程而在定位问题。链路大致是客户端发起连接 → 监听线程接收 → 分配工作线程 → 词法语法解析生成查询树 → 查询重写展开视图、处理规则→ 优化器基于统计信息生成执行计划 → 执行器调用存储引擎取数据 → 结果集回传。知道这条链慢查询就不再是玄学解析慢多半是 SQL 太长或嵌套视图太深优化器选错计划十有八九是统计信息过期执行阶段慢才是真缺索引或者数据倾斜。我一般排查的顺序是先EXPLAIN看计划有没有走索引再看ANALYZE有没有跑过最后才怀疑硬件。手册 3.9 节查看系统表那部分配合pg_stat_activity使用能直接看到当前哪条语句在跑、跑了多久、卡在等锁还是等 IO。统计信息这件事没有后悔药批量导数之后不ANALYZE优化器就是睁眼瞎。2.3 事务管理BEGIN 之后到底锁了什么手册 2.3 节讲管理事务2.4 节补了相关概念两节要连起来读。默认隔离级别是读已提交READ COMMITTED底层靠多版本并发控制读不阻塞写、写不阻塞读但两个事务同时更新同一行时后到的那个会等前一个提交。这条机制解释了两类现场问题一是昨天晚上批量更新卡了四十分钟往往是长事务持有行锁二是磁盘怎么涨得比数据快往往是长事务让旧版本迟迟不能回收。-- 显式事务把批量更新切成可控的小块 BEGIN; UPDATE app.t_order SET status PAID WHERE order_id 1001; SAVEPOINT sp1; UPDATE app.t_order SET status SHIPPED WHERE order_id 1002; -- 出问题只回滚这一段前面的操作保留 ROLLBACK TO SAVEPOINT sp1; COMMIT;逻辑说明SAVEPOINT在批量脚本里很实用一段失败不必整批重来。参数层面没什么可调的真正要守的是纪律——事务里不要夹带人工确认、不要夹带远程调用、不要在事务里等前端回传。事务开得越久锁持有时间越长旧版本堆积越多最后表现为锁等待和磁盘告警一起到。2.4 用 vsql 连上去远程连接的三个开关手册 3.2.1 到 3.2.3 节是新手最容易卡住的地方。服务端远程连接其实就三个开关监听地址、认证规则、网络可达。监听地址在postgresql.conf的listen_addresses默认常常只监听本地回环认证规则在pg_hba.conf决定哪个网段用什么认证方式最后才是防火墙和端口。# 1) 确认监听地址先看当前值再决定改不改 grep -n ^listen_addresses $PGDATA/postgresql.conf # 2) 追加一条主机认证规则按实际网段改不要图省事写 0.0.0.0/0 echo host appdb appuser 192.168.10.0/24 sha256 $PGDATA/pg_hba.conf # 3) 让配置生效然后从客户端侧连一次 vb_ctl reload -D $PGDATA vsql -h 192.168.10.21 -p 5432 -d appdb -U appuser -W逻辑说明vb_ctl reload只重载配置不重启改pg_hba.conf和部分参数用它就够vsql的参数里-h主机、-p端口、-d库名、-U用户、-W交互输入密码脚本化时用-f 文件名跑 SQL 文件、-c 语句跑单条、-o 文件把输出重定向到文件做留档。进了 vsql 之后\l看库、\dn看 schema、\dt看表、\d 表名看结构这几条元命令比查系统表快得多。提示pg_hba.conf的规则是从上往下匹配、命中即停。新加的规则如果放在host all all 127.0.0.1/32 trust这类宽规则后面会一直不生效加之前先看文件顺序。3. 存储模型怎么定行存列存、分区表与索引的落地顺序3.1 行存还是列存按访问模式选而不是按新不新选手册 3.5 节规划存储模型把选择依据写得很直白行存适合按行读写、点查、频繁更新的 OLTP 场景列存适合宽表、按少数列做聚合扫描的 OLAP 场景。判断标准不是表大不大而是一条 SQL 要读多少列。一张两百列的表业务只查其中五列做汇总行存要把整行读进来列存只读那五列差距就出来了。但列存不是万能钥匙代价在写入侧。手册 3.6 节专门讲了列存下的数据压缩压缩比好看可一旦涉及单行更新、频繁小批量插入列存的合并开销就会体现出来。我的经验是贴源层宽表、日志明细、报表汇总用列存订单、账户、配置这类高频点更新用行存混合负载就拆表用视图或物化视图对上不要指望一张表两头讨好。-- 明细宽表走列存压缩级别按磁盘预算选 CREATE TABLE dw.sales_detail ( stat_date date, region_id int, sku_id bigint, channel varchar(32), qty numeric(18,2), amount numeric(18,2) ) WITH (ORIENTATION COLUMN, COMPRESSION MIDDLE) TABLESPACE tbs_app_data; -- 高频点更新的业务表走行存分区键放时间 CREATE TABLE app.t_order ( order_id bigint, cust_id bigint, amount numeric(18,2), status varchar(16), create_time timestamp ) WITH (ORIENTATION ROW, COMPRESSION NO);逻辑说明ORIENTATION是存储朝向建表时定死后期改只能靠重建表迁数据COMPRESSION在列存下可选不同级别级别越高 CPU 开销越大压缩收益递减一般明细表取中间档、归档表才拉满。TABLESPACE跟前面的表空间规划对上冷热分离在这里第一次体现。3.2 列存压缩与表空间磁盘预算先算清楚列存压缩比因数据特征差异极大重复度高的枚举列、时间列、编码类字段压得狠随机字符串、UUID、浮点小数压得一般。做容量规划时别拿演示数据的压缩比往生产上套我一般的做法是抽一周真实数据做一次小批量导入看目录实际增长再乘系数估全量。表空间规划要落到目录层级数据盘、索引盘、归档盘分开挂表空间分别指过去。手册 3.7 节讲创建和管理表空间注意两点——目录必须预先建好并授权表空间不能跨实例共用。做备份恢复时表空间目录路径会跟着走路径不一致就需要做目录映射这个坑在第 5 章会单列一条。3.3 表的生命周期插入、更新、闪回、全局临时表手册 3.8 节把表的增删改查铺了很长其中三个功能容易被忽略但很实用。一是闪回表3.8.6误删数据后不用翻备份前提是回收站开着、且操作在参数控制的时间窗内二是全局临时表3.8.7会话级或事务级临时数据放这里比在业务库里堆tmp_前缀的物理表干净得多三是删除与更新的批量写法UPDATE ... FROM在 openGauss 系里支持做数据订正比游标循环快一个数量级。-- 全局临时表会话内可见提交时按需保留或清空 CREATE GLOBAL TEMPORARY TABLE tmp_import_batch ( seq_no bigint, raw_line text ) ON COMMIT PRESERVE ROWS; -- 批量订正用 FROM 关联源表避免逐行更新 UPDATE app.t_order o SET status s.new_status FROM stage.order_fix s WHERE o.order_id s.order_id AND o.status s.new_status;逻辑说明ON COMMIT PRESERVE ROWS表示提交后数据还在只在会话结束时清理改成DELETE ROWS就是提交即清空。批量UPDATE ... FROM要注意两件事一是关联列上最好有索引否则就是两张表全扫二是大事务拆批每批几千行提交一次避免长事务锁表。3.4 分区表和 default 分区范围分区的正确姿势手册 3.8.8 节讲分区表3.8.8.1 专门提了支持 default 分区。这条其实解决了一个真实痛点按时间做范围分区最怕的是数据迟到——今天的任务导进来一条下个月的数据分区不存在直接报错整个批次回滚。有了 default 分区兜底异常数据先落进去事后ALTER TABLE ... EXCHANGE PARTITION或单独搬迁都行。CREATE TABLE app.t_order_p ( order_id bigint, create_time timestamp, status varchar(16), amount numeric(18,2) ) PARTITION BY RANGE (create_time) ( PARTITION p202401 VALUES LESS THAN (2024-02-01), PARTITION p202402 VALUES LESS THAN (2024-03-01), PARTITION p_default VALUES LESS THAN (MAXVALUE) );逻辑说明分区键要选过滤条件里最常出现的那一列通常是时间每个分区的边界是小于别写成小于等于p_default兜住越界数据但日常要监控它的行数一直涨说明分区预建脚本没跑或者数据源有问题。分区表的索引建在分区上查询不带分区键时就是全分区扫这条比什么调优技巧都重要。3.5 索引、序列、约束的落地顺序手册 3.11 节把 schema、索引、视图、序列、约束归在其他操作里容易被跳读但这里恰恰是建模质量的分水岭。落地顺序我一般按建表含主键→ 建唯一约束 → 建普通索引 → 建序列或自增列 → 建外键。先把约束落稳再补索引是因为唯一约束本身就带索引重复建就是浪费外键放在最后是因为大批量初始化数据时外键检查会拖慢导入导入期间可以先禁用再启用。-- 序列单独建业务侧可控缓存避免高并发下取号成瓶颈 CREATE SEQUENCE app.seq_order_id START 1000000 INCREMENT 1 CACHE 50; -- 索引分区表上建本地索引等值 范围组合列按最左前缀排 CREATE INDEX idx_order_p_cust ON app.t_order_p (cust_id, create_time); -- 约束启用禁用导数窗口短时关闭导完再打开并校验 ALTER TABLE app.t_order_p DISABLE CONSTRAINT fk_order_cust; ALTER TABLE app.t_order_p ENABLE CONSTRAINT fk_order_cust;逻辑说明CACHE 50表示一次预取 50 个序列值到会话内存并发高时能少抢一次锁代价是实例重启会跳号业务侧不能把订单号连续性当硬要求。DISABLE CONSTRAINT之后历史数据不会自动校验重新ENABLE时要确认存量数据合法否则约束起不来。4. 应用侧怎么接JDBC、ODBC、libpq 三条路的参数与边界4.1 JDBC驱动加载与连接串里的隐藏参数手册 4.2 节把 JDBC 从版本兼容、类与接口、类路径设置一路写到连接、游标、存储过程、大对象和连接池是整本手册里开发同学翻得最多的一节。第一个坑在驱动类名拿到 jar 包先解压看一眼META-INF里的驱动声明按实际类名写Class.forName别照抄网上博客的类名不同封装版本会不一样。第二个坑在连接串参数currentSchema决定不写 schema 前缀时落到哪个 schemaconnectTimeout和socketTimeout决定网络抖动时挂多久这两个值不设应用线程池会被拖死。import java.sql.*; import java.math.BigDecimal; public class OrderWriteDemo { public static void main(String[] args) throws Exception { // 驱动类名以 jar 包内实际声明为准先解压核对再写死 Class.forName(org.postgresql.Driver); String url jdbc:postgresql://192.168.10.21:5432/appdb ?currentSchemaapp connectTimeout5 socketTimeout60 ApplicationNameorder-writer; try (Connection conn DriverManager.getConnection(url, appuser, ******)) { conn.setAutoCommit(false); try (PreparedStatement ps conn.prepareStatement( INSERT INTO app.t_order(order_id, cust_id, amount, status) VALUES (?,?,?,?))) { ps.setLong(1, 1001L); ps.setLong(2, 9001L); ps.setBigDecimal(3, new BigDecimal(19.90)); ps.setString(4, NEW); ps.executeUpdate(); } conn.commit(); } } }逻辑说明connectTimeout单位是秒管的是建连阶段socketTimeout管的是读写阶段没有响应多久断开长事务场景要放大。ApplicationName非常值钱——出问题时在pg_stat_activity里能直接看到是哪个应用连过来的比逐个 IP 猜快得多。PreparedStatement除了防注入还能让同结构 SQL 复用执行计划。4.2 游标、结果集与大数据类型手册 4.2.6.2 讲使用游标获取结果这里有个真经验setFetchSize在自动提交模式下不生效必须setAutoCommit(false)才会按批拉取。导几十万行报表数据时不开游标就是一次性全塞进内存堆直接爆还看不出是哪行代码的问题。// 游标分批取数关自动提交否则 fetchSize 被忽略 conn.setAutoCommit(false); try (Statement st conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY)) { st.setFetchSize(1000); try (ResultSet rs st.executeQuery(SELECT order_id, amount FROM app.t_order WHERE create_time 2024-01-01)) { while (rs.next()) { long id rs.getLong(order_id); BigDecimal amt rs.getBigDecimal(amount); // 这里做流式处理不要往集合里堆 } } } conn.commit();逻辑说明TYPE_FORWARD_ONLY是只前进游标开销最小CONCUR_READ_ONLY表示不通过结果集反向更新表。二进制大对象用setBytes/getBytes长文本用setCharacterStream手册 4.2.8 节分了两类写实际用起来注意流要关闭否则连接会被占住不还。4.3 ODBC 与 libpq不是同一类需求的替代品手册 4.3 节整节讲 ODBC配置步骤是 unixODBC 装好、驱动替换、odbc.ini配数据源、环境变量配好、再用isql测通。这条链路主要服务 C/C 或老系统走的是标准 ODBC 接口。命令里最容易出错的是ODBCINI和LD_LIBRARY_PATH两个环境变量没传给应用进程——你在 shell 里isql通了服务一跑就报驱动找不到原因就是服务启动脚本没继承环境变量。; /etc/odbc.ini 数据源配置片段 [appdb] Driver /opt/vastbase/odbc/lib/vbodbc.so Servername 192.168.10.21 Port 5432 Database appdb Username appuser Password ******# 环境变量必须跟着服务进程走不能只在交互式 shell 里 export export ODBCINI/etc/odbc.ini export LD_LIBRARY_PATH/opt/vastbase/odbc/lib:$LD_LIBRARY_PATH isql -v appdb appuser ******逻辑说明Driver指向实际的驱动动态库路径写错报data source name not foundisql -v的-v打开详细输出连不上时能看到具体卡在哪一步。手册 4.4 节讲基于 libpq 开发那是 C 语言直连路线性能开销比 ODBC 少一层封装适合对延迟敏感的自研组件代价是要自己管连接和结果集释放。4.4 接口选型与连接池的边界三条路怎么选按使用者分Java 应用走 JDBC这是最成熟的一条C/C 存量系统走 ODBC改动最小自研高性能组件走 libpq。连接池是另一个维度的事手册 4.2.9 节给了基本用法。池子大小不是越大越好库端的连接数是硬上限池子总和超过上限表现就是应用侧随机报too many clients而且报错时机飘忽特别像玄学问题。我的做法是先按库端max_connections的七成反推再按应用实例数平分。5. 避坑手册里没写透的五个排查现场5.1 远程连不上配置都改了还是超时现象pg_hba.conf加了规则、listen_addresses改成*、vb_ctl reload也执行了客户端还是报连接超时。原因九成是规则顺序问题或根本没重载成功。pg_hba.conf从上往下匹配宽的trust规则排在前面后面加的精确规则永远轮不到另一部分是reload没真正生效或者改的是另一套实例的配置文件。解决先ps -ef | grep vastbase确认实例的数据目录再确认改的是那个目录下的文件用vsql在服务器本地连一次排除网络因素再检查规则顺序把精确规则提到宽规则之前。防火墙和端口用telnet 主机 端口验一遍别靠猜。5.2 列存表更新报错或极慢现象把明细表建成列存后业务侧的按行更新脚本要么报错要么跑得比行存慢十倍。原因列存的物理组织按列聚合单行更新需要定位并重写多列的数据块开销天然高于行存部分版本对列存上的某些更新形态还有限制。解决把表按访问模式重新归类高频更新的表回行存确实要保留列存的改成批量更新加定期合并的写法别做逐行UPDATE。建表前先问一句这张表一天更新几次、每次几行答案超过几百行的就别选列存。5.3 JDBC 取数中文乱码或时间偏八小时现象同一张表vsql里查出来中文正常Java 应用里是问号时间字段比预期少八小时。原因前者是客户端编码和库编码不一致连接串没带编码参数后者是 JDBC 驱动把时间戳按 UTC 解释而服务端会话时区是东八区两边没对齐。解决连接串显式带上charSet或客户端编码参数服务端client_encoding与会话时区一并确认时间字段统一用带时区类型或在应用层做显式转换不要依赖默认行为。这类问题排查时先比对同一条 SQL 在 vsql 和 JDBC 里的输出差异立刻收敛到驱动配置上。5.4 表空间备份恢复到新环境起不来现象vb_basebackup备份 tar 格式拿到了恢复到另一台机器实例起不来日志里全是目录找不到。原因表空间记录的是绝对路径源端/data/vastbase/tbs_app在目标端不存在恢复时没有做目录映射。解决恢复时把表空间路径映射到目标端实际目录提前把目录建好并赋权恢复完成后核对实例日志里的表空间列表和实际目录是否一一对上。血泪经验是恢复演练必须换机器做一次同机恢复成功说明不了任何问题。5.5 管理员分权后业务账号看不到表现象按手册 5.2 节的权限模型做了管理员分离业务账号连上去执行查询报表不存在。原因对象属主是建表账号业务账号只有库级连接权限schema 的USAGE和表的SELECT都没给权限模型收紧之后默认的 public 权限不再兜底。解决按schema 给 USAGE、表给 SELECT/INSERT/UPDATE、序列给 USAGE逐层授权并且把新对象的默认权限也配好否则每次建表都要手动补授。建议把授权脚本固化进建表流程而不是出事后再补。6. 备份与权限的进阶验证SSL、行级控制加一次真恢复手册第 5 章讲安全、3.11 节末尾讲备份两处内容分开看都不难合在一起才构成一套可验证的运维闭环。我的习惯是每个季度做一次三件套演练加密连接跑通、行级策略生效、备份能真恢复到另一套实例。SSL 这块手册 5.1.3.1 给了证书生成流程5.1.4 讲用 SSL 做安全连接。要点不在于生成证书而在于客户端验证模式的选择——sslmodeverify-ca只校验证书链verify-full还要校验主机名生产环境建议后者前提是证书的 CN 和连接串里的主机名对得上。生成证书之后把服务端参数打开、重启生效再用 vsql 带sslmoderequire连一次从pg_stat_ssl里确认这条连接确实是加密的别只看配置文件写了什么。行级访问控制按手册 5.2.8 节的思路做本质是给表挂一条策略把USING条件绑定到当前用户或会话变量上。多租户系统里比视图方案干净因为策略对应用透明不需要改 SQL。演练项验证动作通过标准加密连接vsql 带 sslmode 连接查会话 SSL 视图会话显示加密非加密连接被拒行级策略用两个租户账号查同一张表各自只看到本租户行备份恢复恢复到另一实例并端口错开启动关键表行数与源端一致备份这条我踩过最深的坑是备份成功不等于能恢复。vb_basebackup用 tar 格式加流式 WAL 只是把文件搬走恢复时要校验的东西一样不少# 全量备份tar 格式 流式 WAL 压缩标签写清楚便于追溯 vb_basebackup -D /backup/base_20240301 \ -h 192.168.10.21 -p 5432 -U vbadmin \ -F t -X stream -Z 5 -l full_20240301 # 恢复演练换目录、换端口绝不覆盖生产实例 vb_basebackup -D /backup/restore_test -F t \ -T /data/vastbase/tbs_app/data/restore/tbs_app逻辑说明-F t输出 tar 包便于归档搬运-X stream备份期间同步收 WAL保证备份集自洽-Z 5是压缩级别权衡 CPU 和体积-l打标签出问题时能一眼看出是哪次备份恢复时的-T做表空间目录映射这正是 5.4 那条坑的正解。恢复完先做行数比对和关键字段校验和比对再让业务接入别恢复完就宣布成功。从那以后我每次做完备份都强制走一遍异机恢复加对账宁可多花一小时也不要在真出事那天才发现备份是空的。希望帮到你。本文还有配套的精品资源点击获取
