企业官网建设流程全解析

简介：VASTDATA Vastbase G100 V2.2用户手册是一份面向信创数据库运维与开发人员的官方操作指南，旨在帮助用户快速掌握基于openGauss打造的国产化数据库Vastbase G100的体系架构与日常管理。手册从数据库逻辑结构、数据查询请求处理过程、事务管理讲起，并系统说明配置服务端远程连接、使用vsql连接、调用应用程序接口、关闭数据库、创建和管理数据库、规划存储模型、列存数据压缩、创建和管理表空间等核心操作，适合需要部署或维护Vastbase G100的DBA、运维工程师及后端开发人员参考。压缩包仅含1个PDF文档，大小8.76MB，内容为完整手册目录与正文。目前已有198人学习下载。读者通过手册可清晰了解产品版权与服务声明，同时获得从零开始连接、建库、存储规划到关闭数据库的完整操作路径，目录结构从概述逐步深入，查阅便捷，是上手国产信创数据库的一线资料。

1. Vastbase G100 用户手册：不是拿来读的，是拿来照着连库建表的

这份 Vastbase G100 V2.2 用户手册，很多人下载后第一反应是翻目录、看功能介绍，然后搁在文件夹里吃灰。实际上它是一本不折不扣的操作手册，核心章节全是「怎么做」：怎么配置服务端远程连接、怎么用 vsql 连库、怎么规划存储模型、怎么建分区表和 default 分区、怎么用 vb_basebackup 做 tar 格式备份、怎么配 JDBC/ODBC、怎么生成 SSL 证书、怎么落地三权分立和行级访问控制。Vastbase G100 是典型的信创数据库，基于 openGauss 内核，语法和运维习惯对 PostgreSQL 系用户非常友好，把它当成一份能照着敲的数据库解决方案，比按章节通读一遍价值高得多。适合三类人：刚接手 Vastbase 的 DBA、要对接 JDBC/ODBC 的应用开发，以及正在做国产数据库选型评估的架构师。手册是扫描版，个别字有 OCR 识别错误，读的时候结合上下文即可，不影响照做。

2. 从连接到建表：vsql 实操与库表生命周期

2.1 连接数据库：远程连接配置、vsql 与关闭数据库

手册把「连接数据库」放在数据库使用章节的第一位，这个顺序不是随便排的——后面所有建库、建表、备份操作，前提都是能稳定连上。Vastbase 的服务端远程连接配置沿用了 openGauss 那一套：先改监听地址，再改客户端认证文件，最后重启服务生效。常见做法是修改配置文件里的 listen_addresses，把默认的本地监听改成实际 IP 或整段网卡；端口默认是初始化时定好的，常见有 5432 和 26000 两档，具体以部署参数为准。

认证文件的行格式和 PostgreSQL 的 pg_hba.conf 基本一致，每一行是一条规则：

# TYPE DATABASE USER ADDRESS METHOD host all all 192.168.1.0/24 sha256 host all all 0.0.0.0/0 sha256

TYPE 写 host 表示 TCP/IP 连接，ADDRESS 是客户端网段，METHOD 是认证方式。信创环境里一般要求 sha256 或证书认证，不建议用 trust，否则任意来源都能直连，第五章会专门展开认证与 SSL 的坑。改完监听和认证文件，远程主机才能连进来，记得重启实例或 reload 配置。

服务端就绪后，命令行连接用 vsql，它和 psql 的用法几乎一一对应：

vsql -h 192.168.1.10 -p 5432 -U vastbase -d postgres -W

-h 是数据库主机地址，-p 是端口，-U 指定用户，-d 指定数据库，-W 表示连接时提示输入密码。首次连上后我一般先执行select version();确认连的确实是 Vastbase 实例，顺便核对版本号，这个习惯在排查「连错库」时非常有用。vsql 也支持一次性传入连接串，vsql "host=192.168.1.10 port=5432 user=vastbase dbname=postgres"，适合在脚本里复用。

提示：vsql 还有一批交互命令，比如 \l 列数据库、\d 看表结构、\x 切换扩展显示。手册里虽没有逐条列全，但凡是 psql 用惯的快捷键，在 vsql 里基本都能照用。

手册还专门讲了关闭数据库的两种方式：一种是在会话里执行 SQL 语句关闭，一种是用 vb_ctl 工具。vb_ctl 的用法和 pg_ctl 类似，日常维护我用得最多的是vb_ctl stop -m fast和vb_ctl status。这里有个容易混淆的点：用 SQL 关闭数据库是「管理员主动把实例停下来」，不是断开当前连接，别在业务高峰期手滑执行。

2.2 创建数据库、表空间与存储模型规划

连接就绪后，第一步通常是建库。Vastbase 的 CREATE DATABASE 语法和标准 SQL 一致，但有几个参数建议建库时就定好，后面很难改：

CREATE DATABASE appdb OWNER app_user ENCODING 'UTF8' LC_COLLATE 'C' LC_CTYPE 'C' TEMPLATE template0;

OWNER 指定库属主，ENCODING、LC_COLLATE、LC_CTYPE 决定字符集与排序规则。信创项目里字符集是踩坑重灾区：如果用了默认模板库，后续发现排序不一致，迁移成本很高。我的一般规范是业务库统一 UTF8、Collate 用 C，避免不同节点排序结果不一致，也方便跨平台迁移。

手册 3.5 节「规划存储模型」是 Vastbase 和传统单一行存数据库差异最大的地方。Vastbase 支持行存和列存两种表格式，选型逻辑很简单：OLTP 高并发点查用行存，OLAP 大范围聚合分析用列存。列存表的优势主要体现在压缩比和扫描效率上，第三章会详细展开。表空间的作用是控制数据和索引的物理存放位置，典型做法是把数据文件、索引分别放到不同的磁盘路径，降低 I/O 竞争：

CREATE TABLESPACE ts_data LOCATION '/data/vastbase/datafiles'; CREATE TABLESPACE ts_index LOCATION '/data/vastbase/indexfiles'; CREATE TABLE orders (...) TABLESPACE ts_data; CREATE INDEX idx_orders_id ON orders(id) TABLESPACE ts_index;

表空间路径必须是实例有权限读写、且已存在的目录，创建前用df -h确认磁盘余量。手册把表空间放在存储模型之后讲，意图很明显——先想清楚数据放哪，再动手建表，这是数据库生命周期里最容易跳过、也最影响后期维护的一步。

2.3 表操作全流程：插入、更新、查看、删除

手册 3.8 节给了完整的表生命周期操作。建表时除了常规列定义，Vastbase 还允许显式指定行存或列存：

CREATE TABLE t_row ( id bigint PRIMARY KEY, name varchar(64) ) WITH (ORIENTATION = ROW); CREATE TABLE t_col ( area_code varchar(8), cnt bigint ) WITH (ORIENTATION = COLUMN);

WITH (ORIENTATION = ...) 是存储格式的关键参数，不写默认行存。列存表建表后不能直接切换存储格式，相当于选型要提前定，所以我一般把「先确认读写模型、再定 ORIENTATION」写进开发规范，避免上线后才发现表格式和业务负载不匹配。

增删改查基本都是标准 SQL，但 Vastbase 支持 RETURNING 子句，可以在 DML 后直接拿到被影响的行：

INSERT INTO orders(order_no, amount) VALUES ('SO2024001', 199.00) RETURNING id, order_no; UPDATE orders SET amount = 219.00 WHERE order_no = 'SO2024001' RETURNING id, amount; DELETE FROM orders WHERE order_no = 'SO2024001' RETURNING id;

RETURNING 的实际价值是省一次查询。比如插入后要拿自增主键，不用再单独 select；批量更新后要审计，直接返回新旧值做对比。注意 DELETE 的 RETURNING 返回的是被删除的行快照，不是删除前的全表状态，逻辑上别搞反。

删除数据时还有一个容易被忽略的兜底手段：闪回表。手册 3.8.6 节专门讲了这个功能，它相当于误删数据的后悔药，第六章我会给出完整的操作流程和验证方法，那也是我日常运维里最常用的一招。

2.4 分区表与 default 分区

分区表是手册里篇幅不小的一块，3.8.8 节覆盖了范围分区、列表分区、哈希分区三种主要形式，以及 Vastbase 额外支持的 default 分区。对日志类、订单类大表，分区是治理的起点：

CREATE TABLE orders_part ( order_no varchar(32), order_date date, amount numeric ) WITH (ORIENTATION = ROW) PARTITION BY RANGE (order_date) ( PARTITION p2024q1 VALUES LESS THAN ('2024-04-01'), PARTITION p2024q2 VALUES LESS THAN ('2024-07-01'), PARTITION p2024q3 VALUES LESS THAN ('2024-10-01'), PARTITION p_default DEFAULT );

default 分区的作用是接住所有没匹配上明确边界的数据。没有 default 分区时，插入一条边界外的数据会直接报错；有了它，数据先进兜底分区，后面再通过分区拆分补上。手册里明确写了「支持 default 分区」，这是 Vastbase 比很多开源分支更实用的点。管理上有两个注意：default 分区在一个分区表中只能有一个，且分区边界的调整要在低峰期执行，否则大分区重组织会吃满 I/O，影响在线业务。

2.5 查看系统表与配置数据库参数

手册 3.9 节「查看系统表」和 3.10 节「配置数据库参数」看着短，实际上运维里处处要用。系统表的典型用途是验证表结构、查连接数、查表大小。比如分区表建完，用系统表确认分区是否都创建成功：

SELECT schemaname, tablename, partitionname FROM pg_partition WHERE tablename = 'orders_part' ORDER BY partitionname;

参数配置方面，Vastbase 支持 SQL 方式在线修改，常见做法是先看当前值和单位，再谨慎调整：

SHOW max_connections; SHOW shared_buffers; ALTER SYSTEM SET max_connections = 500;

ALTER SYSTEM 会把参数写入配置文件，重启后生效；有些参数支持 reload 热加载。我的习惯是每次改参数前先SHOW记录旧值，改完再SHOW确认新值，避免「改了没生效」的假象。数据库参数是个黑匣子，改了不做验证，等于没改。

3. 列存压缩与 vb_basebackup：存储效率和数据安全

3.1 列存下的数据压缩

手册 3.6 节「列存下的数据压缩」篇幅不大，但信息密度很高。列存表的本质是同一列的数据连续存放，同一列类型一致、取值范围有限，重复值天然集中，所以压缩比远高于行存。Vastbase 在列存表上可以按列指定压缩策略，常见做法是对低基数列（如状态码、地区码）用高压缩级别，对高基数列（如时间戳、流水号）用低压缩级别：

CREATE TABLE t_col_test ( area_code varchar(8) COMPRESS HIGH, event_time timestamp COMPRESS LOW, payload text COMPRESS HIGH ) WITH (ORIENTATION = COLUMN);

COMPRESS 关键字指定压缩级别，HIGH 适合重复率高的列，LOW 适合几乎无重复的列。压缩并不是越高越好——高压缩级别在写入时要付出更多 CPU 代价，查询时解压也有开销，所以压缩级别的选择要和读写比例绑定。我把选型逻辑归纳成一张表，放进运维手册里：

压缩比的验证不要只看建表时的直觉，要在真实数据量下用系统表对比。我一般用类似select relname, pg_size_pretty(pg_total_relation_size(oid)) from pg_class where relname like 't_col%';的方式，把压缩前后的表大小记录成基线。注意 pg_total_relation_size 包含索引和 TOAST，如果只想看主表，用 pg_relation_size 更干净。

3.2 vb_basebackup：tar 格式备份与表空间级恢复

手册 3.11.6 和 3.11.7 两节讲的是 vb_basebackup，这是 Vastbase 的物理备份工具，逻辑上相当于 PostgreSQL 生态的 pg_basebackup。它做的是在线基础备份，不阻塞业务写入，输出可以是目录格式，也可以是 tar 格式。tar 格式的优点是文件单一、便于归档传输，缺点是不能直接作为数据目录启动，必须先解包。

常见做法是把它和 WAL 归档结合，形成「基础备份 + 持续归档」的恢复方案：

vb_basebackup -h 127.0.0.1 -p 5432 -U backup_user \ -Ft -D /backup/vastbase/base_$(date +%Y%m%d) -z

-Ft 表示输出 tar 格式，-z 表示压缩，-D 指定备份输出目录。-U 指定的备份用户需要有对应权限。我一般会单独建一个 backup 账号，不用超级管理员跑备份，权限最小化。备份完成后，用ls -lh确认 tar 包大小合理，再把这个大小记录进备份台账，和下次备份对比，异常膨胀能提前发现。

表空间备份是 vb_basebackup 的一个特色场景。当业务把数据、索引分散在多个表空间时，可以用 -T 参数做表空间级的备份映射：

# 备份时指定表空间映射：原路径 -> 备份目标文件 vb_basebackup -h 127.0.0.1 -U backup_user -Ft \ -T /data/vastbase/index_ts=/backup/ts_index.tar \ -D /backup/vastbase/base_with_ts

-T 的格式是「源=目标」，恢复时要把方向反过来。这里最容易翻车的是路径不匹配：恢复机的表空间目录如果和原机不一样，必须显式映射，否则实例启动会找不到表空间文件。

注意：tar 格式恢复时，一定要先停掉目标实例再解包，绝不能在实例运行状态下去覆盖数据目录。这是物理备份恢复里最常见的翻车操作，我见过不止一次因为没停实例导致恢复后数据目录损坏。

4. JDBC 与 ODBC 接入：连接参数、游标与大数据类型

4.1 JDBC：驱动加载、连接参数与结果集处理

手册第 4 章是应用开发教程，JDBC 是其中着墨最多的部分。Vastbase 提供独立的 JDBC 驱动，版本选择和 JDK 兼容性在手册 4.2.1、4.2.2 节有对照表。接入的第一步是设置类路径，把驱动 jar 放进应用的 classpath，然后标准的三步：导入、加载驱动、建立连接：

import java.sql.Connection; import java.sql.DriverManager; Class.forName("com.vastbase.jdbc.Driver"); String url = "jdbc:vastbase://192.168.1.10:5432/appdb?useSSL=true&currentSchema=public"; Connection conn = DriverManager.getConnection(url, "app_user", "your_password");

Class.forName 加载驱动类，getConnection 建立连接。URL 里 useSSL 和 currentSchema 是最常用的两个参数：useSSL 控制是否启用 SSL 加密，信创环境默认建议开启；currentSchema 指定会话默认 schema，省得每条 SQL 都带前缀。手册 4.2.5.4 节给了完整的连接参数表，我一般在生产环境固定connectTimeout=5&loginTimeout=5，让应用在数据库异常时快速失败，而不是长时间卡在连接阶段拖垮线程池。

查询和结果集处理是开发最高频的操作。Vastbase JDBC 兼容标准 JDBC API，但有个值得注意的点：大结果集要用游标方式分段获取，手册 4.2.6.2 节专门讲了这块：

Statement stmt = conn.createStatement(); // 设置每次从服务端取回的行数，避免大结果集撑爆内存 stmt.setFetchSize(500); ResultSet rs = stmt.executeQuery("select * from orders_log"); while (rs.next()) { long id = rs.getLong("id"); String orderNo = rs.getString("order_no"); // 逐批处理 } rs.close(); stmt.close();

setFetchSize 是游标模式的关键参数，500 是一个常见起点。如果不设置，驱动可能一次性拉回全部结果，百万行级别的表直接把堆内存打满。我在实际项目里遇到过几次应用端 OOM，最后都是靠设 fetchSize 解决的。注意游标模式下连接要处于非自动提交状态或保持连接不关闭，否则结果集取到一半连接断了，会报「连接已关闭」的异常。

PreparedStatement 比 Statement 多一层参数化，既能防 SQL 注入，又能复用执行计划：

PreparedStatement pstmt = conn.prepareStatement( "update orders set amount = ? where order_no = ?"); pstmt.setBigDecimal(1, new BigDecimal("219.00")); pstmt.setString(2, "SO2024001"); int rows = pstmt.executeUpdate();

setBigDecimal 对应 numeric 类型，setString 对应 varchar。注意金额字段不要用 setDouble，浮点精度问题在数据库里最容易埋雷，宁可多写两行转 BigDecimal，也不要用 double 传金额。

4.2 ODBC：unixODBC 与数据源配置

ODBC 在国产化环境里主要服务两类场景：一类是老旧的 C/C++ 应用，另一类是报表工具通过 ODBC 对接数据库。手册 4.3.2 节的步骤很直接：先安装 openGauss 或 Vastbase 客户端，再装 unixODBC，然后替换客户端驱动程序、配置数据源、配置环境变量，最后测试数据源。

unixODBC 装好后，手工配置 odbc.ini 是绕不开的一步：

[VastbaseDSN] Description = Vastbase G100 datasource Driver = Vastbase ODBC driver Host = 192.168.1.10 Port = 5432 Database = appdb Username = app_user Password = your_password

DSN 名字写在方括号里，后续连接时引用这个名字。Driver 要填 odbcinst.ini 里注册的驱动名，两者必须对得上。配置完环境变量后，用 isql 做连通性测试：

export ODBCINI=/etc/odbc.ini isql -v VastbaseDSN

isql 能连上并返回 SQL> 提示符，说明 DSN、驱动、网络都通了。ODBC 的连接参数和 JDBC 大同小异，手册 4.3.3.2 节列了参数表，重点看 SSLMode、Database、Username 三项。ODBC 下执行 SQL 用 SQLExecDirect 或 SQLPrepare/SQLExecute，游标处理用 SQLFetch 配合 SQLBindCol 逐列绑定缓冲，和 JDBC 的 ResultSet 是两套心智模型，C 语言开发要提前规划好绑定缓冲区的生命周期，否则很容易内存越界。

4.3 存储过程调用与大数据类型处理

手册 4.2.7 和 4.3.5 分别讲了 JDBC、ODBC 调用存储过程。调用存储过程有个高频诉求——获取过程内部查询产生的结果集：

CallableStatement cs = conn.prepareCall("{call proc_query_orders(?)}"); cs.registerOutParameter(1, Types.REF_CURSOR); cs.execute(); ResultSet rs = (ResultSet) cs.getObject(1);

Types.REF_CURSOR 是关键，存储过程的输出参数声明成游标类型，应用才能把结果集当作 ResultSet 遍历。如果过程返回的是普通标量，用 registerOutParameter 注册对应类型即可。这里要注意的是，过程里的 SQL 如果涉及临时表，调用端连接断了临时数据就没了，排查时要先确认是过程逻辑问题还是连接生命周期问题。

大数据类型是另一个容易翻车的点。手册 4.2.8 节分了两类：二进制类型和字符串类型。二进制用 getBytes/setBytes，字符串用 getString/setString。真实场景里经常要处理文件流入库：

PreparedStatement ps = conn.prepareStatement( "insert into file_store(file_name, file_blob) values(?, ?)"); ps.setString(1, "report.pdf"); ps.setBinaryStream(2, inputStream, fileLength); ps.executeUpdate();

setBinaryStream 适合大文件流入库，第三个参数 fileLength 最好显式给出，驱动可以按长度分配缓冲区。字符串大对象则要小心字符集，Vastbase 默认 UTF8，应用端如果是 GBK 编码，写入前要做编码转换，否则中文乱码和长度校验错误会交替出现。我在对接报表平台时就吃过这个亏，最后统一在应用层强制 UTF8 才消停。

手册里还有一节是「基于 libpq 开发」，这是 C 语言的直连接口，适合对性能敏感、不想引入 ODBC 层的场景。libpq 的接入方式和 psql 同源，设置连接串和客户端编码是重点。C 系开发如果之前用过 PostgreSQL 的 libpq，迁移成本几乎为零，直接替换连接参数即可。

5. 安全与权限配置避坑：认证、SSL 与三权分立常见问题

5.1 客户端接入认证与连接数查看

手册第 5 章是管理数据库安全，第一节就是客户端接入认证。Vastbase 的认证配置文件和 PostgreSQL 一样是逐行规则，从上到下匹配，第一条命中的规则生效。这个「从上到下」的语义是排查认证问题的核心——很多人配了新规则没生效，一看才发现前面有一条更宽松的规则把请求接走了。

典型配置：

# TYPE DATABASE USER ADDRESS METHOD local all all trust host all all 127.0.0.1/32 trust host all all 192.168.1.0/24 sha256 hostssl all all 0.0.0.0/0 sha256

第一条 local 管本机 socket 连接，第二条管本机 TCP，第三条管内网，第四条 hostssl 强制 SSL。注意如果只想让远程走加密，就要写 hostssl 而不是 host，并且把不带 ssl 的 host 规则删掉或收紧，否则客户端可以绕过 SSL 直连，加密配置形同虚设。认证方式里 sha256 是新项目默认，md5 属于历史遗留，信创验收时基本都会被点名。

连接数管理是日常运维的高频操作。手册 5.1.5 节给了查看入口，常见做法是查系统视图统计各用户、各状态的连接分布：

SELECT usename, state, count(*) FROM pg_stat_activity GROUP BY usename, state ORDER BY count(*) DESC;

state 列的 active 表示正在执行，idle 表示空闲连接。连接池配置过大时，idle 会占满 max_connections，导致新业务连不进来。我一般会结合这个查询结果，把空闲连接占比超过 40% 的连接池参数调下来，同时把 idle_in_transaction_session_timeout 这类超时参数设上，防止挂起的空闲事务长期占着连接。

5.2 SSL 证书生成与加密连接

手册 5.1.3 节的 SSL 证书管理给了一套完整流程：证书生成、配置服务端、配置客户端。数据库 SSL 的证书体系和 Web 不一样，不需要去公共 CA 申请，常见做法是自建私有 CA，用 openssl 签发服务端证书：

# 生成 CA 私钥和自签名根证书 openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -subj "/CN=Vastbase-CA" # 生成服务端私钥和证书签名请求 openssl req -new -key server.key -out server.csr -subj "/CN=vastbase-server" openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -out server.crt -days 825

CN 字段要和服务端主机名或 IP 匹配，否则客户端校验时会报主机名不匹配。证书生成后，在数据库配置里打开 SSL，指定证书和私钥路径，并把认证文件里的远程规则改成 hostssl。客户端这边，JDBC 的 useSSL=true 配合证书校验参数，或者 ODBC 的 SSLMode=verify-full，都能强制加密。

证书这块的真正常见坑是私钥权限：server.key 权限如果过宽，数据库启动时会直接拒绝加载。规范是 server.key 权限 600、属主必须是实例用户。证书过期也要纳入巡检，SSL 证书一到期的表现很隐蔽——不是完全连不上，而是客户端偶发握手失败，排查半天才发现是证书链失效。我一般会在巡检脚本里加一条证书到期日检查，到期前 30 天就告警。

5.3 三权分立、行级访问控制与账户安全策略

手册 5.2.3 节的三权分立是信创数据库的特色设计，也是选型评估里经常被问到的点。三权分立把超级管理员的权限拆成三个角色：系统管理员管数据库运行，安全管理员管安全策略，审计管理员管审计日志，三者相互制约，任何一个单一角色都不能完整控制数据库。实际落地时，手册 5.2.2 节的管理员说明和默认权限机制要先读明白——开启三权分立后，原来「一个超级用户包打天下」的运维脚本会失效，排查问题时要分清是权限不够还是功能故障，别在错误的方向上浪费时间。

行级访问控制解决的是「同一张表，不同用户只能看到特定行」的问题，典型场景是数据按区域或按组织隔离。Vastbase 通过创建政策实现：

CREATE ROW LEVEL SECURITY POLICY rls_area ON t_customer USING (area_code = current_setting('app.area_code')); ALTER TABLE t_customer ENABLE ROW LEVEL SECURITY;

USING 子句是过滤条件，每次查询都会自动追加。current_setting 取应用设置的会话变量，实现按区域隔离。这里的典型坑是：表属主和超级管理员默认不受行级访问控制限制，如果业务账号恰好是表属主，政策就「失效」了，需要调整属主或换用非属主账号验证。账户安全策略方面，手册 5.2.9.1 节讲了密码复杂度、失败锁定、有效期这些参数。常见做法是设置连续登录失败若干次后锁定账户一段时间，配合密码复杂度策略，覆盖长度、字符类别和不得包含用户名这些规则。

5.4 高频踩坑记录

以下 5 条是我在部署和运维 Vastbase 过程中反复遇到的坑，按「现象、原因、解决」整理。

坑一：远程连接超时或拒绝。现象：应用服务器连数据库报 connection timed out 或 connection refused。 原因：八成不是数据库本身问题，而是监听地址没改、认证文件没有覆盖客户端网段，或者服务器防火墙没放行端口，三者经常同时存在。 解决：先vb_ctl status确认实例在跑，再用ss -lntp | grep 端口看监听是否绑定了对外网卡，接着检查认证文件里的 ADDRESS 是否含客户端网段，最后确认防火墙规则。按这个顺序排查，基本一轮就能定位。

坑二：SSL 开启后客户端反而连不上。现象：配置 SSL 后，部分客户端报 SSL off 或 no pg_hba.conf entry。 原因：认证文件里写的是 host 而不是 hostssl，客户端没走加密通道；或者证书私钥权限不对，服务端压根没加载证书。 解决：把远程规则改成 hostssl 并删除对应的 host 规则；检查 server.key 权限是否为 600；用日志确认证书实际加载路径，别指望配置文件里的相对路径在任何启动方式下都有效。

坑三：三权分立开启后，原管理员忽然「没权限」。现象：之前用超级用户能执行的建用户、查审计操作，开启后报 permission denied。 原因：三权分立把权限拆成了三个互不交叉的角色，原超级用户不再拥有安全管理和审计权限，这是设计行为，不是故障。 解决：先确认当前登录的角色属于哪个职责域，按职责换账号操作；部署脚本里把三个角色的连接信息分开维护，不要假设一个账号能做完所有事。

坑四：行级访问控制政策不生效。现象：普通用户查询还是能看到全部行。 原因：最常见的是执行查询的账号是表属主，属主默认绕过行级安全；其次是政策建了但没执行 ENABLE。 解决：先查系统表确认表已启用行级安全，再确认执行账号是否为属主。如果是属主，要么回调属主，要么用非属主账号验证。我习惯在测试环境用一个只读账号验证政策效果，而不是拿属主账号「试」。

坑五：列存表做批量更新特别慢，甚至报错。现象：列存表执行高频 update/delete 性能远低于行存，某些写法直接报错。 原因：列存表为批量分析优化，行级更新需要重组列数据，代价是行存的数倍；这是存储模型选型时就要预判的。 解决：OLTP 高频更新场景用行存表；日志分析场景用列存表加分区；混合负载拆成两张表，用异步同步保证一致性。选型阶段想清楚，比事后换表成本低一个量级。

6. 闪回表与全局临时表：误操作后悔药与会话级临时数据

6.1 闪回表：误删数据后的恢复路径

手册 3.8.6 节的闪回表是我最常用的兜底功能。它允许把表恢复到过去某个时间点的状态，本质上是利用数据库的回收站或 undo 保留机制。前提是相关表没有被物理清理、保留时间没超限。常见做法是三步走：

-- 第一步：确认目标表当前数据状态 SELECT count(*), max(id) FROM t_orders; -- 第二步：执行闪回，恢复到误删前的时间点 FLASHBACK TABLE t_orders TO TIMESTAMP ('2024-06-01 10:00:00'); -- 第三步：验证恢复结果 SELECT count(*), max(id) FROM t_orders;

执行前先查一下当前最大 id 和时间点，闪回后对比行数和 max(id) 是否回到预期值。注意闪回的时间点要在保留窗口内，超出窗口会直接失败。这也是为什么批量操作前要先确认备份策略和闪回保留参数，闪回不是万能的后悔药，保留窗口之外只能靠备份恢复。

6.2 全局临时表：会话级临时数据的正确打开方式

全局临时表在手册 3.8.7 节介绍，解决的是「多会话各自维护一份临时数据、互不干扰」的需求。Vastbase 支持 ON COMMIT PRESERVE ROWS 和 ON COMMIT DELETE ROWS 两种语义，前者保留到会话结束，后者事务提交即清空：

CREATE GLOBAL TEMPORARY TABLE gtt_etl_temp ( batch_id bigint, payload text ) ON COMMIT PRESERVE ROWS;

ETL 任务里我习惯用 PRESERVE ROWS：一个批次的数据写入临时表，跨事务查询，批次结束直接清空，比反复建表删表干净得多。全局临时表的定义是全库共享的，但数据是会话隔离的，并发任务之间不会串数据，这在多租户 ETL 场景里非常实用。

从那以后，我每次做批量 update 或 delete 之前都强制走一遍「先查基线 → 确认闪回窗口 → 操作 → 事后对比行数」的流程；接新环境时，第一件事就是确认闪回保留参数和备份策略，确保自己的后悔药还在。希望这份 Vastbase G100 V2.2 手册的经验整理能帮到你，尤其是刚接手信创数据库选型或迁移的同学，把手册当操作清单用，每敲一条命令前先想清楚执行后的数据状态，比什么都重要。

本文还有配套的精品资源，点击获取