简介zzu数据库实验报告书是一套面向计算机类与软件工程专业学生的数据库原理实验配套资料基于openGauss平台记录了数据库课程中从基础认知到应用开发的关键实践环节。资源为1个docx文档包体约3.23MB完整覆盖实验一至实验九认识DBMS、创建数据库/表/索引、交互式SQL语句、创建视图、完整性控制、安全性控制、事务与并发控制、数据库备份与恢复、使用JDBC连接数据库。各实验均设有明确目的、操作过程、问题记录与结果分析可帮助学习者快速理解概念模型与关系模型掌握SQL命令、openGauss安装启动、用户权限管理、事务隔离和并发控制等核心技能。对于正在完成课程报告或备战数据库实验考试的学生这套报告既能提供可参照的实验结构与排错思路也能作为实验报告范例参考。已有1522人学习下载适合数据库课程实践学习。1. 数据库实验从装环境开始openGauss 装不上后面都是空谈数据库系统原理实验看起来是 SQL 语句的活实际先把大多数人拦在门外的却是实验一的环境安装。openGauss 作为这门课的默认数据库管理系统一旦安装失败或者服务起不来后面的建表、查询、事务、备份根本无从上手。这份某高校的数据库实验报告书从认识 DBMS 一路做到 JDBC 连接数据库九个实验串成一条完整的数据库实践链路对正在做数据库实验或想拿 openGauss 练手的人来说是很好的操作参照。openGauss 和常见的单机数据库不同安装完成后默认会创建一个 postgres 数据库主节点端口默认走 26000日常操作依赖 gsql 这个命令行工具。安装模式有云主机、虚拟机一键安装、手工部署三种选错或者端口配置不对都会让后续实验全部停在第一步。本文就用实际装过的过程把安装、建库、建表、备份恢复和 JDBC 验证讲清楚。2. 安装 openGauss三种模式里先选虚拟机一键安装实验一的目标是认识 DBMS 并搭好实验平台很多人第一次装 openGauss 就把时间耗在环境上。装的时候觉得一路下一步就行结果一跑gs_om -t start就翻车。与其赌运气不如先看清三种安装模式分别适合什么场景。2.1 三种安装模式怎么选不要一上来就手工装openGauss 的安装方式大致可以分成三种在云主机上安装、虚拟机一键安装、先装 openEuler 虚拟机再手工安装 openGauss。云主机适合需要多人远程共用的场景但网络、安全组、监听地址都要额外处理一键安装适合本机做实验环境隔离坏了还能回滚快照手工安装则更偏运维方向适合想弄清楚底层依赖和初始化过程的人。安装模式前置条件适合谁我的选择建议云主机安装有可用的云服务器能配置安全组和远程访问多人共用、需要外网访问的场景成本高网络配置多单机实验不建议虚拟机一键安装本机装虚拟机软件下载 openGauss 一体化镜像刚接触 openGauss、只做课程实验首选隔离干净快照就是后悔药openEuler 手工安装openEuler 虚拟机下载安装包和集群配置文件想深入理解安装过程、做数据库运维实验进阶用出错概率高耗时长我一般会选虚拟机一键安装。原因是 openGauss 对操作系统和内核参数有要求手工装需要处理gs_preinstall、gs_install、集群配置、用户组这些环节少一个依赖都可能把环境搞坏。而一键安装模式把大部分初始化过程封装好了启动虚拟机、按提示配置密码之后就能直接进 gsql能把时间留给后面的实验。一键安装的常规流程是下载 openGauss 虚拟机镜像或一键安装包导入虚拟机软件磁盘建议给到 40GB 以上内存至少 4GB启动后按安装说明执行脚本等待安装完成。安装完成后系统一般会自动创建一个名为 omm 的数据库安装用户后续所有数据库操作都在这个用户下进行。这里有个容易被忽略的点安装过程中设置的 omm 密码同时也是数据库管理员密码务必记牢后面重建密码很麻烦。2.2 启动服务并连接默认数据库第一次连接决定环境是否可用安装完成后第一步不是急着建表而是先用管理员用户启动数据库服务并连上默认库。openGauss 默认生成的数据库叫 postgres如果你连 postgres 都进不去后面所有实验都无从谈起。切换用户和启动服务使用以下命令su - omm gs_om -t start gsql -d postgres -p 26000 -rsu - omm是从当前系统用户切换到数据库安装用户 omm注意中间有空格不是笔误。gs_om -t start是 openGauss 集群管理工具-t指定要执行的动作类型start 表示启动数据库服务。连接命令里-d postgres指定默认数据库-p 26000指定主节点端口如果安装时改过端口这里要同步改-r是让 gsql 输出更贴近数据库教材风格。执行成功后会出现postgres#提示符说明服务已就绪。进到 gsql 里先别急着建库用\l看一眼数据库列表用SELECT datname FROM pg_database;查询系统表这些操作在实验报告书里都会被要求截图。确认 postgres 库存在后建议先创建自己的实验用户和实验库避免一直拿管理员账号做实验。示例 SQL 如下CREATE USER lab_user PASSWORD Lab_12345; CREATE DATABASE lab_db OWNER lab_user; GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_user;openGauss 对密码有复杂度要求纯数字或过于简单的密码会被直接拒绝建议至少包含大小写字母和数字。CREATE DATABASE lab_db OWNER lab_user;创建库的同时指定属主相当于把库的控制权直接交给 lab_user。如果不指定 OWNER默认属主是当前执行命令的 omm。GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_user;是给用户在库一级的权限建表还需要 schema 权限这一步在后面很有用。2.3 离开默认库之前先分清用户、数据库和 schema实验一里有个高频考察点数据库、用户、schema 之间是什么关系。openGauss 里一个数据库可以包含多个 schema一个 schema 可以包含多张表、视图、存储过程用户登录后能不能看到某个 schema取决于权限和 search_path。很多人在实验报告里写不清这三个概念其实可以简单理解成数据库是磁盘上的存储空间schema 是这层空间里划分出的名字空间用户是能操作这些对象的人。在 gsql 里可以用这些命令快速体验\c dbname切换数据库\dn查看 schema\dt查看当前 schema 下的表\d tablename查看表结构\di查看索引。\c - username可以切换用户身份。实验报告书里要求用SELECT * FROM pg_user;查看用户列表用SELECT * FROM pg_roles;查看角色这两个查询结果要能看出来用户和角色的区别用户是登录数据库的个体角色是权限的集合。第 2 章到这就该停了。如果你在gs_om -t start或者第一次gsql连接时已经踩到坑直接看下一章的排查记录我已经把这些环境问题整理成了现象和原因对照。3. 常见问题与排查端口、角色权限和中文乱码openGauss 环境最常见的故障不是 SQL 写不出来而是连接不上、权限不够、中文乱码这类基础问题。这些问题在实验报告书里通常不会写太细但实际做完一遍基本都会碰到。下面四条是我在装环境和做实验过程中踩过的坑按现象、原因、解决三个角度记录。3.1 服务起不来或连接超时先看状态再查端口现象执行gsql -d postgres -p 26000 -r报could not connect to server: Connection refused或者gs_om -t start之后客户端仍然连不上。原因一般有三个服务根本没启动、端口写错、数据库没监听当前网卡地址。解决时先执行状态检查命令gs_om -t status gs_om -t startgs_om -t status会列出集群节点状态如果显示Down或UNKNOWN说明服务没有正常起来。需要先确认当前用户是 omm再用gs_om -t start拉起服务。如果状态正常但连接仍被拒绝检查是否用了同一个端口openGauss 默认端口是 26000但安装时如果指定过其他端口连接命令必须同步修改。远程连接场景还要看监听地址postgresql.conf里的listen_addresses如果只写了localhost外部 IP 自然连不上改成*后执行gs_om -t restart让配置生效。注意gs_om -t start是集群管理工具不是数据库内部命令必须退出 gsql 后在操作系统 shell 里执行。我曾经在postgres#提示符下敲gs_om -t start结果直接报语法错误这个操作位置要分清。3.2 角色不存在或建表权限被拒库权限给了schema 权限别忘了现象用新建用户登录时报role lab_user does not exist或者登录成功后执行CREATE TABLE提示permission denied for schema public。原因是有时候用户确实没创建成功有时候是只给了数据库权限没给 schema 权限。解决时先回到管理员身份确认用户存在SELECT * FROM pg_user;如果找不到就用 omm 登录后重新创建用户并补齐两类权限CREATE USER lab_user PASSWORD Lab_12345; GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_user; GRANT ALL PRIVILEGES ON SCHEMA public TO lab_user;第三个语句经常被漏掉。openGauss 沿用了 PostgreSQL 的权限模型数据库权限和 schema 权限是分开的只给数据库所有权并不能自动获得在 public schema 下建表的权利。实验报告书里要求填写“遇到的问题与更正”这类问题非常值得作为一条实验记录写进去。3.3 中文乱码或字符集不支持建库那一步就要定好编码现象往表里插入中文后查询显示成问号或乱码严重时直接报character with byte sequence ...错误。原因大多数是数据库初始化时没有使用 UTF8 编码或者客户端连接编码和库编码不一致。解决方法是建库时显式指定编码CREATE DATABASE lab_db ENCODING UTF8;连接后还要检查客户端编码SET client_encoding TO UTF8;如果库已经建错了编码最省事的做法是删掉重建不要试图在既有库上改字符集。openGauss 的数据库编码在建库时就确定了后期修改会牵涉全部数据的存储格式风险非常高。我现在的习惯是建库命令里永远带上ENCODING UTF8免得后面所有实验数据都变成乱码。3.4 表明明存在却提示 relation does not existsearch_path 没指对现象\dt能看到book_eg.teachers表但执行SELECT * FROM teachers;时报relation teachers does not exist。原因不是表不存在而是当前连接的 schema 搜索路径里没有包含 book_eg。解决方法是写全 schema 名或者临时切换 search_pathSELECT * FROM book_eg.teachers; SET search_path TO book_eg, public;第一种方式最直观适合实验报告截图第二种方式适合接下来要连续操作同一 schema 的场景。\dn可以查看当前的 schema 列表\d book_eg.teachers能查看该表结构。这个坑在实验二里最容易出现因为创建的表可能分散在不同 schema 下连接默认还在 public人和表就不在同一个“目录”里。4. 创建数据库、表和索引用 gsql 跑通实验二实验二的核心是创建数据库、基本表、索引并往表里填数据。建表本身不复杂但顺序和约束很容易写错。比如先建了引用其他表的子表外键还没地方挂再比如把列级约束和表级约束混用导致多列主键语法报错。下面按我实际执行的顺序来。4.1 先建表空间和数据库表的“文件夹”和“存储空间”openGauss 里表空间可以理解成数据文件的文件夹数据库则是按业务划分出的存储空间。实验报告书里先创建表空间再创建库顺序是合理的。SQL 如下CREATE TABLESPACE tpcds_local RELATIVE LOCATION tablespace/tablespace_1; CREATE DATABASE db_sc WITH TABLESPACE tpcds_local; ALTER DATABASE db_sc RENAME TO db_school; \c db_school CREATE SCHEMA book_eg;第一行的RELATIVE LOCATION tablespace/tablespace_1表示在数据目录的相对路径下创建表空间路径不需要提前手工创建openGauss 会按相对位置处理。WITH TABLESPACE tpcds_local指定新建数据库使用这个表空间。ALTER DATABASE db_sc RENAME TO db_school;是改名操作注意改名后如果当前还连着旧库名需要重新连接。\c db_school切到新库。最后创建 schema。schema 是逻辑命名空间实验里经常要求创建book_eg这样的模式来隔离对象。有了 schema后面建表就可以写成book_eg.Teachers不会和 public 下的同名表冲突。报告书里要求辨析 schema 的两层含义一层是 DDL 语句描述的数据库逻辑结构另一层是数据库里的实际命名空间考试时经常从概念题角度考。4.2 建表顺序先父表后子表外键才能挂上创建有外键依赖的表时一定要先建被引用的父表。比如 Departments 表的 Dheadno 外键引用 Teachers那 Teachers 必须先存在Students 表的 Dno 外键引用 DepartmentsDepartments 也得先建好。推荐按 Teachers、Departments、Students、Courses、SC 的顺序执行CREATE TABLE Teachers( Tno CHAR(20) PRIMARY KEY, Tname CHAR(20) NOT NULL, Sex CHAR(20) CHECK (Sex 男 OR Sex 女), Birthday DATE, Title CHAR(20), Dno CHAR(20) ); CREATE TABLE Departments( Dno CHAR(20) PRIMARY KEY, Dname CHAR(20), Dheadno CHAR(20), FOREIGN KEY (Dheadno) REFERENCES Teachers(Tno) ); CREATE TABLE Students( Sno CHAR(20) PRIMARY KEY, Sname CHAR(20) NOT NULL, Sex CHAR(20) CHECK (Sex 男 OR Sex 女), Birthday DATE, Enrollyear CHAR(20), Speciality CHAR(20), Dno CHAR(20), FOREIGN KEY (Dno) REFERENCES Departments(Dno) ); CREATE TABLE Courses( Cno CHAR(20) PRIMARY KEY, Cname CHAR(20) NOT NULL, Period SMALLINT, Credit SMALLINT ); CREATE TABLE SC( Sno CHAR(20), Cno CHAR(20), Score SMALLINT, PRIMARY KEY (Sno, Cno), FOREIGN KEY (Sno) REFERENCES Students(Sno), FOREIGN KEY (Cno) REFERENCES Courses(Cno) );Teachers 表里Tno CHAR(20) PRIMARY KEY是列级主键约束只约束单列SC 表里最后一行PRIMARY KEY (Sno, Cno)是表级约束因为主键由两列联合构成。这就是实验报告书里辨析列级约束和表级约束的关键如果约束涉及多个列必须写在所有列定义之后并且要写明列名。Sex CHAR(20) CHECK (Sex 男 OR Sex 女)是检查约束openGauss 完全支持这个写法。需要注意的是Period SMALLINT用了 SMALLINT它比 INT 占空间小取值范围也小对课程学时这种小整数足够。如果写成 INT 也不算错但实验报告里要能解释为什么选 SMALLINT通常说法是“数值范围足够且节省存储”。到这里只建了核心表。剩下还有一张 Teaches 教学信息表字段要根据你自己的设计补上建表语法和上面完全一致。建完所有表后执行\dt检查应该能看到每个表都出现在当前 schema 下。4.3 用 \d 查看表结构再按需修改表建表完成后用\d Teachers查看完整表结构输出会包含列名、类型、是否可空、默认值、约束信息。这个命令比单纯的\d Teachers多显示存储参数和更完整的约束信息实验截图建议优先用\d。如果建表之后发现字段不够用ALTER TABLE补充比如给教师表增加邮箱列或补上外键ALTER TABLE Teachers ADD COLUMN Email VARCHAR(50); ALTER TABLE Teachers ADD CONSTRAINT fk_teacher_dno FOREIGN KEY (Dno) REFERENCES Departments(Dno);第一条是加列第二条是给已有列添加外键约束。注意这里要求 Departments 表已经存在否则外键引用会失败。ADD CONSTRAINT fk_teacher_dno给约束起了名字以后要删除这个约束可以执行ALTER TABLE Teachers DROP CONSTRAINT fk_teacher_dno;。表结构修改是交互式 SQL 实验里常考的操作报告书里通常要求写清修改前后的结构对比。4.4 索引主键自动建普通索引手动建索引的目的是加快查询速度但不会自动出现在每个列上。openGauss 会在主键和唯一约束上自动创建索引其他列需要手动CREATE INDEX。实验二要求在 Students 的 Dno 上创建索引SQL 如下CREATE INDEX Student_Dept ON Students(Dno);Student_Dept是索引名ON Students(Dno)表示在 Students 表的 Dno 列上建 B-tree 索引。创建后用\di查看索引列表可以看到手动创建的索引和主键自动生成的索引同时存在。删除索引使用DROP INDEX Student_Dept;索引不是越多越好。Dno 这种经常出现在 WHERE 条件或连接条件里的列适合建索引但如果表频繁插入、更新索引过多反而会拖慢写入速度。实验报告里如果能写一句“索引建多了会降低写入性能”会比单纯贴命令显得更有理解深度。5. 视图、安全性、事务与备份把实验四到八串成一条线实验四到实验八分别指向视图、完整性、安全性、事务并发和备份恢复。这些内容在实验报告书里是分开的但在真实运维场景里是一条链视图控制查询范围约束保证数据完整权限决定谁能访问事务和备份决定数据出问题时能不能救回来。5.1 视图与完整性约束查询逻辑的封装层视图可以理解成一张“虚拟表”它不占用独立的数据存储空间每次查询时按定义好的 SELECT 语句实时取数。创建视图的典型语句CREATE VIEW stu_dept_view AS SELECT s.Sno, s.Sname, d.Dname FROM Students s JOIN Departments d ON s.Dno d.Dno;这里给 Students 和 Departments 分别起了别名 s、d通过 Dno 做连接最终暴露给使用者的只有学号、姓名、院系名三个字段。视图很适合做权限管控不想让普通用户看到 Students 表里的生日字段就只建一个不包含 Birthday 的视图把视图的查询权限授出去。视图是否能更新有严格要求视图中必须包含基表的主键不能带 DISTINCT、聚合函数、GROUP BY也不能来自多表连接的复杂结果。所以在实验报告里写“对视图执行 INSERT 或 UPDATE”之前先确认这个视图满足可更新条件否则实验报告会扣理解分。删除视图用DROP VIEW stu_dept_view;。完整性控制更多是体现在建表时的约束上主键保证非空且唯一外键保证引用关系CHECK 保证数据取值合法DEFAULT 保证缺省值。实验五会要求在事务中观察外键约束的生效时机可以这样写BEGIN; SET CONSTRAINTS ALL IMMEDIATE; INSERT INTO Students(Sno, Sname, Dno) VALUES (S001, 示例学生, D01); COMMIT;SET CONSTRAINTS ALL IMMEDIATE让外键检查在语句执行时立刻生效。如果改成SET CONSTRAINTS ALL DEFERRED检查会推迟到事务提交时但前提是外键定义成 DEFERRABLE。openGauss 默认外键是即时检查要推迟需要在定义外键时写明约束属性。5.2 安全性控制最小权限原则就是这么落地的实验六的安全性控制重点在用户、角色和权限分配。用户是登录数据库的凭证角色是权限的集合把角色授给用户用户就拥有对应权限。创建只读用户并授权的套路如下CREATE USER lab_reader PASSWORD Read_123; GRANT SELECT ON Teachers, Students, Courses TO lab_reader; REVOKE SELECT ON Teachers FROM lab_reader;第一行创建用户第二行授予对三门课的查询权限第三行再收回对 Teachers 的查询权限。实际使用时建议先定义角色再把角色授予用户这样新用户加入时只需要一次性赋角色不用逐个表授权。SELECT * FROM pg_user;可以查看用户SELECT * FROM pg_roles;可以查看角色两者对比就能理解“用户是具体个体角色是权限集合”。安全性控制还要考虑视图的作用。前面创建的stu_dept_view如果只授予普通用户他们只能通过视图看到三个字段无法直接访问底表。这种“通过视图屏蔽敏感列”的做法在实验报告里是很加分的点。实验六的截图至少要能覆盖创建用户、授予权限、验证普通用户能查询、收回权限后查询失败。5.3 事务、并发控制与备份恢复实验七到八的安全网事务实验最容易理解的是原子性一组操作要么全部成功要么全部回滚。在 gsql 里可以这样演示BEGIN; UPDATE Courses SET Credit Credit - 1 WHERE Cno C001; ROLLBACK;BEGIN开启事务UPDATE执行到一半发现条件写错了ROLLBACK让数据回到事务开启前。如果执行COMMIT修改才会真正落盘。实验报告里要求观察事务过程中另一个连接能否看到未提交的数据这就引出隔离级别和并发控制。并发控制可以使用行锁演示SET TRANSACTION ISOLATION LEVEL READ COMMITTED; BEGIN; SELECT * FROM SC WHERE Sno S001 FOR UPDATE; COMMIT;FOR UPDATE会给查到的行加锁其他事务再对同一行做更新时会被阻塞直到当前事务提交或回滚。死锁在实验环境里不常出现但要会排查多个事务互相持有对方需要的锁openGauss 检测到死锁会回滚其中一个事务。避免死锁的习惯是事务内固定顺序访问表不要交叉访问。实验八是备份与恢复openGauss 下最常用的逻辑备份工具是gs_dump和gs_restore。备份示例命令gs_dump -U omm -f /home/omm/db_school_backup.sql -p 26000 db_school gs_restore -U omm -d db_school_restore -p 26000 /home/omm/db_school_backup.sqlgs_dump的-f指定备份文件路径-p指定端口最后接要备份的库名。gs_restore用-d指定目标库恢复前需要先建好一个空库。如果只备份数据不备份表结构可以在 gs_dump 后面加-a参数如果希望恢复时先清理旧对象再加-c参数。备份是环境里最便宜的后悔药。我一般会在做破坏性实验之前先gs_dump一次事务实验里把数据改乱了直接恢复一份干净的备份比手工一条条改回来快得多。6. 用 JDBC 连接数据库用一次真实连接验证全套环境实验九把前面所有环境工作收拢到一个点程序能不能通过 JDBC 连上 openGauss。这一步通过说明服务启动正常、用户权限正常、数据库对象可见整条链路才算真正跑通。JDBC 连接 openGauss 时URL 格式沿用了 PostgreSQL 协议写法本地实验通常写成jdbc:postgresql://127.0.0.1:26000/db_school。用户用实验里创建的 lab_user密码对应用户密码。一个最简验证程序如下import java.sql.*; public class CheckDB { public static void main(String[] args) { String url jdbc:postgresql://127.0.0.1:26000/db_school; String user lab_user; String password Lab_12345; try (Connection conn DriverManager.getConnection(url, user, password); Statement st conn.createStatement(); ResultSet rs st.executeQuery(SELECT version();)) { rs.next(); System.out.println(rs.getString(1)); } catch (Exception e) { e.printStackTrace(); } } }编译运行命令javac -encoding UTF-8 CheckDB.java java -cp .:opengauss-jdbc.jar CheckDB-encoding UTF-8是为了避免源码里的中文注释乱码-cp .:opengauss-jdbc.jar表示把当前目录和驱动 jar 加入 classpath。程序运行后能打印出 openGauss 的版本信息就证明 JDBC 这条链路没问题。如果报 SSL 相关错误可以在 URL 末尾追加?sslmodedisable再试不过要注意这只是测试环境的办法生产环境不建议关。最后可以按这张表做一次完整验证验证项命令或操作预期结果数据库服务状态gs_om -t status节点状态正常默认数据库连接gsql -d postgres -p 26000 -r进入 SQL 提示符实验库列表\l能看到 db_school表结构\d Students输出完整字段和约束JDBC 查询java CheckDB打印 openGauss 版本从那以后我每次搭完一套数据库实验环境都会强制走一遍这张清单最后再跑一次 JDBC 查询才敢说环境真的没问题。环境不靠玄学能用一个标准程序验证过的环境才是可信的。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/19 2:24:02 · 阅读 1.2k openGauss数据库实验环境搭建与JDBC连接实践
简介zzu数据库实验报告书是一套面向计算机类与软件工程专业学生的数据库原理实验配套资料基于openGauss平台记录了数据库课程中从基础认知到应用开发的关键实践环节。资源为1个docx文档包体约3.23MB完整覆盖实验一至实验九认识DBMS、创建数据库/表/索引、交互式SQL语句、创建视图、完整性控制、安全性控制、事务与并发控制、数据库备份与恢复、使用JDBC连接数据库。各实验均设有明确目的、操作过程、问题记录与结果分析可帮助学习者快速理解概念模型与关系模型掌握SQL命令、openGauss安装启动、用户权限管理、事务隔离和并发控制等核心技能。对于正在完成课程报告或备战数据库实验考试的学生这套报告既能提供可参照的实验结构与排错思路也能作为实验报告范例参考。已有1522人学习下载适合数据库课程实践学习。1. 数据库实验从装环境开始openGauss 装不上后面都是空谈数据库系统原理实验看起来是 SQL 语句的活实际先把大多数人拦在门外的却是实验一的环境安装。openGauss 作为这门课的默认数据库管理系统一旦安装失败或者服务起不来后面的建表、查询、事务、备份根本无从上手。这份某高校的数据库实验报告书从认识 DBMS 一路做到 JDBC 连接数据库九个实验串成一条完整的数据库实践链路对正在做数据库实验或想拿 openGauss 练手的人来说是很好的操作参照。openGauss 和常见的单机数据库不同安装完成后默认会创建一个 postgres 数据库主节点端口默认走 26000日常操作依赖 gsql 这个命令行工具。安装模式有云主机、虚拟机一键安装、手工部署三种选错或者端口配置不对都会让后续实验全部停在第一步。本文就用实际装过的过程把安装、建库、建表、备份恢复和 JDBC 验证讲清楚。2. 安装 openGauss三种模式里先选虚拟机一键安装实验一的目标是认识 DBMS 并搭好实验平台很多人第一次装 openGauss 就把时间耗在环境上。装的时候觉得一路下一步就行结果一跑gs_om -t start就翻车。与其赌运气不如先看清三种安装模式分别适合什么场景。2.1 三种安装模式怎么选不要一上来就手工装openGauss 的安装方式大致可以分成三种在云主机上安装、虚拟机一键安装、先装 openEuler 虚拟机再手工安装 openGauss。云主机适合需要多人远程共用的场景但网络、安全组、监听地址都要额外处理一键安装适合本机做实验环境隔离坏了还能回滚快照手工安装则更偏运维方向适合想弄清楚底层依赖和初始化过程的人。安装模式前置条件适合谁我的选择建议云主机安装有可用的云服务器能配置安全组和远程访问多人共用、需要外网访问的场景成本高网络配置多单机实验不建议虚拟机一键安装本机装虚拟机软件下载 openGauss 一体化镜像刚接触 openGauss、只做课程实验首选隔离干净快照就是后悔药openEuler 手工安装openEuler 虚拟机下载安装包和集群配置文件想深入理解安装过程、做数据库运维实验进阶用出错概率高耗时长我一般会选虚拟机一键安装。原因是 openGauss 对操作系统和内核参数有要求手工装需要处理gs_preinstall、gs_install、集群配置、用户组这些环节少一个依赖都可能把环境搞坏。而一键安装模式把大部分初始化过程封装好了启动虚拟机、按提示配置密码之后就能直接进 gsql能把时间留给后面的实验。一键安装的常规流程是下载 openGauss 虚拟机镜像或一键安装包导入虚拟机软件磁盘建议给到 40GB 以上内存至少 4GB启动后按安装说明执行脚本等待安装完成。安装完成后系统一般会自动创建一个名为 omm 的数据库安装用户后续所有数据库操作都在这个用户下进行。这里有个容易被忽略的点安装过程中设置的 omm 密码同时也是数据库管理员密码务必记牢后面重建密码很麻烦。2.2 启动服务并连接默认数据库第一次连接决定环境是否可用安装完成后第一步不是急着建表而是先用管理员用户启动数据库服务并连上默认库。openGauss 默认生成的数据库叫 postgres如果你连 postgres 都进不去后面所有实验都无从谈起。切换用户和启动服务使用以下命令su - omm gs_om -t start gsql -d postgres -p 26000 -rsu - omm是从当前系统用户切换到数据库安装用户 omm注意中间有空格不是笔误。gs_om -t start是 openGauss 集群管理工具-t指定要执行的动作类型start 表示启动数据库服务。连接命令里-d postgres指定默认数据库-p 26000指定主节点端口如果安装时改过端口这里要同步改-r是让 gsql 输出更贴近数据库教材风格。执行成功后会出现postgres#提示符说明服务已就绪。进到 gsql 里先别急着建库用\l看一眼数据库列表用SELECT datname FROM pg_database;查询系统表这些操作在实验报告书里都会被要求截图。确认 postgres 库存在后建议先创建自己的实验用户和实验库避免一直拿管理员账号做实验。示例 SQL 如下CREATE USER lab_user PASSWORD Lab_12345; CREATE DATABASE lab_db OWNER lab_user; GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_user;openGauss 对密码有复杂度要求纯数字或过于简单的密码会被直接拒绝建议至少包含大小写字母和数字。CREATE DATABASE lab_db OWNER lab_user;创建库的同时指定属主相当于把库的控制权直接交给 lab_user。如果不指定 OWNER默认属主是当前执行命令的 omm。GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_user;是给用户在库一级的权限建表还需要 schema 权限这一步在后面很有用。2.3 离开默认库之前先分清用户、数据库和 schema实验一里有个高频考察点数据库、用户、schema 之间是什么关系。openGauss 里一个数据库可以包含多个 schema一个 schema 可以包含多张表、视图、存储过程用户登录后能不能看到某个 schema取决于权限和 search_path。很多人在实验报告里写不清这三个概念其实可以简单理解成数据库是磁盘上的存储空间schema 是这层空间里划分出的名字空间用户是能操作这些对象的人。在 gsql 里可以用这些命令快速体验\c dbname切换数据库\dn查看 schema\dt查看当前 schema 下的表\d tablename查看表结构\di查看索引。\c - username可以切换用户身份。实验报告书里要求用SELECT * FROM pg_user;查看用户列表用SELECT * FROM pg_roles;查看角色这两个查询结果要能看出来用户和角色的区别用户是登录数据库的个体角色是权限的集合。第 2 章到这就该停了。如果你在gs_om -t start或者第一次gsql连接时已经踩到坑直接看下一章的排查记录我已经把这些环境问题整理成了现象和原因对照。3. 常见问题与排查端口、角色权限和中文乱码openGauss 环境最常见的故障不是 SQL 写不出来而是连接不上、权限不够、中文乱码这类基础问题。这些问题在实验报告书里通常不会写太细但实际做完一遍基本都会碰到。下面四条是我在装环境和做实验过程中踩过的坑按现象、原因、解决三个角度记录。3.1 服务起不来或连接超时先看状态再查端口现象执行gsql -d postgres -p 26000 -r报could not connect to server: Connection refused或者gs_om -t start之后客户端仍然连不上。原因一般有三个服务根本没启动、端口写错、数据库没监听当前网卡地址。解决时先执行状态检查命令gs_om -t status gs_om -t startgs_om -t status会列出集群节点状态如果显示Down或UNKNOWN说明服务没有正常起来。需要先确认当前用户是 omm再用gs_om -t start拉起服务。如果状态正常但连接仍被拒绝检查是否用了同一个端口openGauss 默认端口是 26000但安装时如果指定过其他端口连接命令必须同步修改。远程连接场景还要看监听地址postgresql.conf里的listen_addresses如果只写了localhost外部 IP 自然连不上改成*后执行gs_om -t restart让配置生效。注意gs_om -t start是集群管理工具不是数据库内部命令必须退出 gsql 后在操作系统 shell 里执行。我曾经在postgres#提示符下敲gs_om -t start结果直接报语法错误这个操作位置要分清。3.2 角色不存在或建表权限被拒库权限给了schema 权限别忘了现象用新建用户登录时报role lab_user does not exist或者登录成功后执行CREATE TABLE提示permission denied for schema public。原因是有时候用户确实没创建成功有时候是只给了数据库权限没给 schema 权限。解决时先回到管理员身份确认用户存在SELECT * FROM pg_user;如果找不到就用 omm 登录后重新创建用户并补齐两类权限CREATE USER lab_user PASSWORD Lab_12345; GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_user; GRANT ALL PRIVILEGES ON SCHEMA public TO lab_user;第三个语句经常被漏掉。openGauss 沿用了 PostgreSQL 的权限模型数据库权限和 schema 权限是分开的只给数据库所有权并不能自动获得在 public schema 下建表的权利。实验报告书里要求填写“遇到的问题与更正”这类问题非常值得作为一条实验记录写进去。3.3 中文乱码或字符集不支持建库那一步就要定好编码现象往表里插入中文后查询显示成问号或乱码严重时直接报character with byte sequence ...错误。原因大多数是数据库初始化时没有使用 UTF8 编码或者客户端连接编码和库编码不一致。解决方法是建库时显式指定编码CREATE DATABASE lab_db ENCODING UTF8;连接后还要检查客户端编码SET client_encoding TO UTF8;如果库已经建错了编码最省事的做法是删掉重建不要试图在既有库上改字符集。openGauss 的数据库编码在建库时就确定了后期修改会牵涉全部数据的存储格式风险非常高。我现在的习惯是建库命令里永远带上ENCODING UTF8免得后面所有实验数据都变成乱码。3.4 表明明存在却提示 relation does not existsearch_path 没指对现象\dt能看到book_eg.teachers表但执行SELECT * FROM teachers;时报relation teachers does not exist。原因不是表不存在而是当前连接的 schema 搜索路径里没有包含 book_eg。解决方法是写全 schema 名或者临时切换 search_pathSELECT * FROM book_eg.teachers; SET search_path TO book_eg, public;第一种方式最直观适合实验报告截图第二种方式适合接下来要连续操作同一 schema 的场景。\dn可以查看当前的 schema 列表\d book_eg.teachers能查看该表结构。这个坑在实验二里最容易出现因为创建的表可能分散在不同 schema 下连接默认还在 public人和表就不在同一个“目录”里。4. 创建数据库、表和索引用 gsql 跑通实验二实验二的核心是创建数据库、基本表、索引并往表里填数据。建表本身不复杂但顺序和约束很容易写错。比如先建了引用其他表的子表外键还没地方挂再比如把列级约束和表级约束混用导致多列主键语法报错。下面按我实际执行的顺序来。4.1 先建表空间和数据库表的“文件夹”和“存储空间”openGauss 里表空间可以理解成数据文件的文件夹数据库则是按业务划分出的存储空间。实验报告书里先创建表空间再创建库顺序是合理的。SQL 如下CREATE TABLESPACE tpcds_local RELATIVE LOCATION tablespace/tablespace_1; CREATE DATABASE db_sc WITH TABLESPACE tpcds_local; ALTER DATABASE db_sc RENAME TO db_school; \c db_school CREATE SCHEMA book_eg;第一行的RELATIVE LOCATION tablespace/tablespace_1表示在数据目录的相对路径下创建表空间路径不需要提前手工创建openGauss 会按相对位置处理。WITH TABLESPACE tpcds_local指定新建数据库使用这个表空间。ALTER DATABASE db_sc RENAME TO db_school;是改名操作注意改名后如果当前还连着旧库名需要重新连接。\c db_school切到新库。最后创建 schema。schema 是逻辑命名空间实验里经常要求创建book_eg这样的模式来隔离对象。有了 schema后面建表就可以写成book_eg.Teachers不会和 public 下的同名表冲突。报告书里要求辨析 schema 的两层含义一层是 DDL 语句描述的数据库逻辑结构另一层是数据库里的实际命名空间考试时经常从概念题角度考。4.2 建表顺序先父表后子表外键才能挂上创建有外键依赖的表时一定要先建被引用的父表。比如 Departments 表的 Dheadno 外键引用 Teachers那 Teachers 必须先存在Students 表的 Dno 外键引用 DepartmentsDepartments 也得先建好。推荐按 Teachers、Departments、Students、Courses、SC 的顺序执行CREATE TABLE Teachers( Tno CHAR(20) PRIMARY KEY, Tname CHAR(20) NOT NULL, Sex CHAR(20) CHECK (Sex 男 OR Sex 女), Birthday DATE, Title CHAR(20), Dno CHAR(20) ); CREATE TABLE Departments( Dno CHAR(20) PRIMARY KEY, Dname CHAR(20), Dheadno CHAR(20), FOREIGN KEY (Dheadno) REFERENCES Teachers(Tno) ); CREATE TABLE Students( Sno CHAR(20) PRIMARY KEY, Sname CHAR(20) NOT NULL, Sex CHAR(20) CHECK (Sex 男 OR Sex 女), Birthday DATE, Enrollyear CHAR(20), Speciality CHAR(20), Dno CHAR(20), FOREIGN KEY (Dno) REFERENCES Departments(Dno) ); CREATE TABLE Courses( Cno CHAR(20) PRIMARY KEY, Cname CHAR(20) NOT NULL, Period SMALLINT, Credit SMALLINT ); CREATE TABLE SC( Sno CHAR(20), Cno CHAR(20), Score SMALLINT, PRIMARY KEY (Sno, Cno), FOREIGN KEY (Sno) REFERENCES Students(Sno), FOREIGN KEY (Cno) REFERENCES Courses(Cno) );Teachers 表里Tno CHAR(20) PRIMARY KEY是列级主键约束只约束单列SC 表里最后一行PRIMARY KEY (Sno, Cno)是表级约束因为主键由两列联合构成。这就是实验报告书里辨析列级约束和表级约束的关键如果约束涉及多个列必须写在所有列定义之后并且要写明列名。Sex CHAR(20) CHECK (Sex 男 OR Sex 女)是检查约束openGauss 完全支持这个写法。需要注意的是Period SMALLINT用了 SMALLINT它比 INT 占空间小取值范围也小对课程学时这种小整数足够。如果写成 INT 也不算错但实验报告里要能解释为什么选 SMALLINT通常说法是“数值范围足够且节省存储”。到这里只建了核心表。剩下还有一张 Teaches 教学信息表字段要根据你自己的设计补上建表语法和上面完全一致。建完所有表后执行\dt检查应该能看到每个表都出现在当前 schema 下。4.3 用 \d 查看表结构再按需修改表建表完成后用\d Teachers查看完整表结构输出会包含列名、类型、是否可空、默认值、约束信息。这个命令比单纯的\d Teachers多显示存储参数和更完整的约束信息实验截图建议优先用\d。如果建表之后发现字段不够用ALTER TABLE补充比如给教师表增加邮箱列或补上外键ALTER TABLE Teachers ADD COLUMN Email VARCHAR(50); ALTER TABLE Teachers ADD CONSTRAINT fk_teacher_dno FOREIGN KEY (Dno) REFERENCES Departments(Dno);第一条是加列第二条是给已有列添加外键约束。注意这里要求 Departments 表已经存在否则外键引用会失败。ADD CONSTRAINT fk_teacher_dno给约束起了名字以后要删除这个约束可以执行ALTER TABLE Teachers DROP CONSTRAINT fk_teacher_dno;。表结构修改是交互式 SQL 实验里常考的操作报告书里通常要求写清修改前后的结构对比。4.4 索引主键自动建普通索引手动建索引的目的是加快查询速度但不会自动出现在每个列上。openGauss 会在主键和唯一约束上自动创建索引其他列需要手动CREATE INDEX。实验二要求在 Students 的 Dno 上创建索引SQL 如下CREATE INDEX Student_Dept ON Students(Dno);Student_Dept是索引名ON Students(Dno)表示在 Students 表的 Dno 列上建 B-tree 索引。创建后用\di查看索引列表可以看到手动创建的索引和主键自动生成的索引同时存在。删除索引使用DROP INDEX Student_Dept;索引不是越多越好。Dno 这种经常出现在 WHERE 条件或连接条件里的列适合建索引但如果表频繁插入、更新索引过多反而会拖慢写入速度。实验报告里如果能写一句“索引建多了会降低写入性能”会比单纯贴命令显得更有理解深度。5. 视图、安全性、事务与备份把实验四到八串成一条线实验四到实验八分别指向视图、完整性、安全性、事务并发和备份恢复。这些内容在实验报告书里是分开的但在真实运维场景里是一条链视图控制查询范围约束保证数据完整权限决定谁能访问事务和备份决定数据出问题时能不能救回来。5.1 视图与完整性约束查询逻辑的封装层视图可以理解成一张“虚拟表”它不占用独立的数据存储空间每次查询时按定义好的 SELECT 语句实时取数。创建视图的典型语句CREATE VIEW stu_dept_view AS SELECT s.Sno, s.Sname, d.Dname FROM Students s JOIN Departments d ON s.Dno d.Dno;这里给 Students 和 Departments 分别起了别名 s、d通过 Dno 做连接最终暴露给使用者的只有学号、姓名、院系名三个字段。视图很适合做权限管控不想让普通用户看到 Students 表里的生日字段就只建一个不包含 Birthday 的视图把视图的查询权限授出去。视图是否能更新有严格要求视图中必须包含基表的主键不能带 DISTINCT、聚合函数、GROUP BY也不能来自多表连接的复杂结果。所以在实验报告里写“对视图执行 INSERT 或 UPDATE”之前先确认这个视图满足可更新条件否则实验报告会扣理解分。删除视图用DROP VIEW stu_dept_view;。完整性控制更多是体现在建表时的约束上主键保证非空且唯一外键保证引用关系CHECK 保证数据取值合法DEFAULT 保证缺省值。实验五会要求在事务中观察外键约束的生效时机可以这样写BEGIN; SET CONSTRAINTS ALL IMMEDIATE; INSERT INTO Students(Sno, Sname, Dno) VALUES (S001, 示例学生, D01); COMMIT;SET CONSTRAINTS ALL IMMEDIATE让外键检查在语句执行时立刻生效。如果改成SET CONSTRAINTS ALL DEFERRED检查会推迟到事务提交时但前提是外键定义成 DEFERRABLE。openGauss 默认外键是即时检查要推迟需要在定义外键时写明约束属性。5.2 安全性控制最小权限原则就是这么落地的实验六的安全性控制重点在用户、角色和权限分配。用户是登录数据库的凭证角色是权限的集合把角色授给用户用户就拥有对应权限。创建只读用户并授权的套路如下CREATE USER lab_reader PASSWORD Read_123; GRANT SELECT ON Teachers, Students, Courses TO lab_reader; REVOKE SELECT ON Teachers FROM lab_reader;第一行创建用户第二行授予对三门课的查询权限第三行再收回对 Teachers 的查询权限。实际使用时建议先定义角色再把角色授予用户这样新用户加入时只需要一次性赋角色不用逐个表授权。SELECT * FROM pg_user;可以查看用户SELECT * FROM pg_roles;可以查看角色两者对比就能理解“用户是具体个体角色是权限集合”。安全性控制还要考虑视图的作用。前面创建的stu_dept_view如果只授予普通用户他们只能通过视图看到三个字段无法直接访问底表。这种“通过视图屏蔽敏感列”的做法在实验报告里是很加分的点。实验六的截图至少要能覆盖创建用户、授予权限、验证普通用户能查询、收回权限后查询失败。5.3 事务、并发控制与备份恢复实验七到八的安全网事务实验最容易理解的是原子性一组操作要么全部成功要么全部回滚。在 gsql 里可以这样演示BEGIN; UPDATE Courses SET Credit Credit - 1 WHERE Cno C001; ROLLBACK;BEGIN开启事务UPDATE执行到一半发现条件写错了ROLLBACK让数据回到事务开启前。如果执行COMMIT修改才会真正落盘。实验报告里要求观察事务过程中另一个连接能否看到未提交的数据这就引出隔离级别和并发控制。并发控制可以使用行锁演示SET TRANSACTION ISOLATION LEVEL READ COMMITTED; BEGIN; SELECT * FROM SC WHERE Sno S001 FOR UPDATE; COMMIT;FOR UPDATE会给查到的行加锁其他事务再对同一行做更新时会被阻塞直到当前事务提交或回滚。死锁在实验环境里不常出现但要会排查多个事务互相持有对方需要的锁openGauss 检测到死锁会回滚其中一个事务。避免死锁的习惯是事务内固定顺序访问表不要交叉访问。实验八是备份与恢复openGauss 下最常用的逻辑备份工具是gs_dump和gs_restore。备份示例命令gs_dump -U omm -f /home/omm/db_school_backup.sql -p 26000 db_school gs_restore -U omm -d db_school_restore -p 26000 /home/omm/db_school_backup.sqlgs_dump的-f指定备份文件路径-p指定端口最后接要备份的库名。gs_restore用-d指定目标库恢复前需要先建好一个空库。如果只备份数据不备份表结构可以在 gs_dump 后面加-a参数如果希望恢复时先清理旧对象再加-c参数。备份是环境里最便宜的后悔药。我一般会在做破坏性实验之前先gs_dump一次事务实验里把数据改乱了直接恢复一份干净的备份比手工一条条改回来快得多。6. 用 JDBC 连接数据库用一次真实连接验证全套环境实验九把前面所有环境工作收拢到一个点程序能不能通过 JDBC 连上 openGauss。这一步通过说明服务启动正常、用户权限正常、数据库对象可见整条链路才算真正跑通。JDBC 连接 openGauss 时URL 格式沿用了 PostgreSQL 协议写法本地实验通常写成jdbc:postgresql://127.0.0.1:26000/db_school。用户用实验里创建的 lab_user密码对应用户密码。一个最简验证程序如下import java.sql.*; public class CheckDB { public static void main(String[] args) { String url jdbc:postgresql://127.0.0.1:26000/db_school; String user lab_user; String password Lab_12345; try (Connection conn DriverManager.getConnection(url, user, password); Statement st conn.createStatement(); ResultSet rs st.executeQuery(SELECT version();)) { rs.next(); System.out.println(rs.getString(1)); } catch (Exception e) { e.printStackTrace(); } } }编译运行命令javac -encoding UTF-8 CheckDB.java java -cp .:opengauss-jdbc.jar CheckDB-encoding UTF-8是为了避免源码里的中文注释乱码-cp .:opengauss-jdbc.jar表示把当前目录和驱动 jar 加入 classpath。程序运行后能打印出 openGauss 的版本信息就证明 JDBC 这条链路没问题。如果报 SSL 相关错误可以在 URL 末尾追加?sslmodedisable再试不过要注意这只是测试环境的办法生产环境不建议关。最后可以按这张表做一次完整验证验证项命令或操作预期结果数据库服务状态gs_om -t status节点状态正常默认数据库连接gsql -d postgres -p 26000 -r进入 SQL 提示符实验库列表\l能看到 db_school表结构\d Students输出完整字段和约束JDBC 查询java CheckDB打印 openGauss 版本从那以后我每次搭完一套数据库实验环境都会强制走一遍这张清单最后再跑一次 JDBC 查询才敢说环境真的没问题。环境不靠玄学能用一个标准程序验证过的环境才是可信的。希望帮到你。本文还有配套的精品资源点击获取