简介：《zzu数据库实验报告书》是一份面向计算机科学与技术及软件工程专业学生的数据库系统原理实验完整记录，覆盖实验一至实验九，可帮助读者系统掌握数据库管理、SQL 语句操作以及数据安全、完整性、并发与恢复等核心技能。资源为单个 docx 文档，3.23MB，由作者 weixin_52030647 整理共享。报告紧密围绕 openGauss 数据库环境展开，从认识 DBMS 系统、安装与使用 gsql 工具，到创建数据库、表与索引，再到交互式 SQL、视图创建、完整性控制、安全性权限管理、事务与并发控制（含锁机制与死锁处理）、数据库备份与恢复，以及使用 JDBC 连接数据库的编程实践，逐项记录了实验目的、操作步骤、常见问题与结果分析，内容完整且结构清晰。目前已有 1522 人学习下载，尤其适合数据库原理课程期末复习、课程设计参考以及希望快速上手数据库管理开发的初学者使用。

1. 认识 DBMS 之前：为什么这份实验从头到尾都是 openGauss

拿到这份《数据库系统原理实验》报告书，我第一反应是先翻它用的什么数据库环境，结果九个实验清一色 openGauss，默认端口还不是熟知的 5432，而是 26000。这个差异让不少人在最开始就翻车：明明装完了，一条gsql -d postgres连上去却直接报错，原因多半是没切到 omm 用户，或者服务压根没起来。数据库课程实验十有八九走“认识 DBMS → 建库建表 → SQL 查询 → 完整性/安全性 → 备份恢复 → JDBC 编程”这条线，openGauss 恰好把每一环都覆盖了，从命令行工具 gsql 到运维命令 gs_om，再到 JDBC 驱动一应俱全。这份报告书把九个实验全流程走了一遍，适合正要装 openGauss、又不想在环境上耗两天的开发者照着抄，能少踩一半坑。

2. 安装 openGauss：三种模式怎么选，手动装最稳的流程

报告实验一里明确列了三种安装模式：云服务器上安装、虚拟机一键安装、虚拟机先装 openEuler 再装 openGauss。三种我都实际装过，结论是：想快速跑通选一键安装，想要一个和自己报告截图一致、后续能排查问题的环境，老老实实选第三种。原因很简单，openEuler 是 openGauss 官方适配的操作系统，数据库的依赖、内核参数、字符集都按它的习惯来，出问题时网上能搜到的报错也最全；而且虚拟机可以拍快照，装坏了回滚等于吃了颗后悔药，这是云服务器上不敢随便做的操作。

2.1 三种安装模式：云上、一键、手动

一键安装听着省事，实际翻车时最难受：你只知道装好了，但不知道装在哪个目录、日志写在哪、参数写在哪。手动安装虽然多花半小时，但后面九个实验全靠这套环境，把家底摸清楚比什么都值。云服务器方案适合实验做完后想放到公网演示的人，安全组里 26000 端口不放行，JDBC 远程直连怎么调都是超时。

2.2 手动安装：从 openEuler 到 gs_install 的完整命令

先准备一台 openEuler 虚拟机，内存建议不低于 4G，磁盘 20G 以上，网络用 NAT 或桥接都行，只要虚拟机自己能上网。系统装好后，第一步不是解压安装包，而是创建数据库安装用户。openGauss 的管理员用户默认叫 omm，报告里所有操作都要先su - omm，所以这个用户必须提前建好：

groupadd dbgrp useradd -g dbgrp -m -s /bin/bash omm passwd omm

第一行创建用户组 dbgrp，第二行创建用户 omm 并把它放进 dbgrp 组，第三行设置 omm 的登录密码。这里有个血泪经验：密码尽量设成大小写字母加数字的复杂组合，openGauss 安装时的密码策略检查比想象中严，纯数字纯字母都可能直接卡在初始化那一步。

接着把 openGauss 安装包解压，用 root 执行预安装命令：

tar -zxvf openGauss-*.tar.gz cd openGauss gs_preinstall -U omm -G dbgrp -X clusterconfig.xml

clusterconfig.xml 是从安装包自带模板复制出来的，必改三处：nodeNames填主节点主机名；dataNode填数据目录，这个目录要提前建好并把属主改成 omm；port填 26000。gs_preinstall负责检查操作系统依赖、创建目录、配置内核参数，这一步报错九成是权限和路径问题，日志会直接打印在终端上，照着改完重跑即可。

预安装通过后，切换到 omm 用户执行正式安装：

su - omm gs_install -X clusterconfig.xml

gs_install会按 clusterconfig.xml 的配置初始化数据目录、生成 postgres 默认数据库、写入端口配置。安装成功的标志是最后一行输出Successfully installed.，看到这个再往下走，不然数据目录都是残缺的，后面连接报什么错都不奇怪。整个过程少则十分钟多则半小时，取决于虚拟机磁盘速度。

2.3 安装后的检查：进程、端口、日志

安装完成别急着连，先做三个检查，确认服务真起来了：

ps -ef | grep gaussdb ss -lntp | grep 26000 gs_om -t status

第一条看数据库进程是否存在，第二条确认 26000 端口在监听，第三条用 gs_om 查看集群状态，正常应显示normal。三条里任意一条不符合预期，都说明安装过程有残留问题。这时候最有效的办法不是重新装一遍，而是去 clusterconfig.xml 里gaussdbLogDirectory配置的目录翻日志，openGauss 把安装日志和运行日志都写在那个目录下，报错原因写得比终端输出详细得多，比自己瞎猜快。

3. 启动与连接：从 root 切到 omm，再让 gsql 说上话

环境装好后，实验一的核心就是“启动数据库服务 + 用 gsql 连上 postgres 默认库”。这一步看似简单，实际上拦截了很多人。我在帮人排查时见过最多的情况是：明明服务开着，一条gsql -d postgres输入进去，却报类似FATAL: password authentication failed的错。原因十有八九是当前登录用户不是 omm，环境变量没加载，导致 gsql 用了错误的身份去认证。

3.1 启动服务：gs_om 的状态和日志

gs_om 是 openGauss 的运维管理工具，启动集群用-t start，查看状态用-t status。注意顺序：先启动，再确认状态，最后才连接：

su - omm gs_om -t start gs_om -t status

第一行切换到 omm 用户，这一步不能省。openGauss 安装时把数据目录、环境变量、密钥文件都绑在 omm 用户下，用 root 或其他用户执行 gs_om，大概率会撞上权限拒绝。第二行启动数据库服务，启动过程会检查数据目录完整性和端口占用。第三行确认状态，输出里带normal才是健康状态；如果显示Degraded或Unknown，说明有节点没起来。

启动失败时，我一般先看gs_om -t status的报错里有没有提示具体节点和日志路径，然后去配置的日志目录翻om开头的日志文件。常见原因无非三种：端口被占、数据目录属主不对、上一次异常退出没清理干净。这些在第 5 章会逐个展开。

3.2 gsql 连接参数和元命令

服务起来后，用 gsql 连接默认数据库 postgres：

gsql -d postgres -p 26000 -U omm

-d指定数据库名，postgres 是 openGauss 安装后自动生成的默认库，也是实验一里指定要连的库；-p指定端口，26000 是主节点端口，写错成 5432 会直接连接超时；-U指定连接用户，第一次就用 omm。报告里还带着-r参数，它开启的是 gsql 的交互特性开关，不写不影响正常使用。

连上之后，gsql 提供一组以反斜杠开头的元命令，实验一专门让读者逐个试一遍。我把它们整理成一张表，照着敲就行：

除了元命令，实验一还让通过系统表查信息，这两条 SQL 也是后面排查问题的基础：

SELECT datname FROM pg_database; SELECT spcname FROM pg_tablespace; SELECT * FROM pg_user;

pg_database存数据库列表，pg_tablespace存表空间列表，pg_user存用户信息。openGauss 沿用了 PostgreSQL 的系统表架构，很多管理信息都能从这些表里直接查出来，比图形工具还直观。

3.3 创建用户和第一次切换

实验一最后要求创建一个新的数据库用户账号。用 omm 连上 postgres 后执行：

CREATE USER lab_user WITH PASSWORD 'Lab@123456';

这条命令创建了一个叫 lab_user 的普通用户。WITH PASSWORD指定密码，openGauss 默认密码策略要求长度不低于 8 位且包含大小写和数字，设得太简单会直接报错。创建完成后可以切换到这个用户：

\c postgres lab_user

gsql 的\c命令后面跟数据库名和用户名，切换后提示符会变成postgres=>，说明当前身份已经变了。这时候你会发现，新用户默认什么都干不了，连建表权限都没有——这正是实验六安全性控制要解决的问题，也为后面的 GRANT 授权语句埋了个伏笔。

4. 建库建表与索引：实验二的完整 SQL 作业

实验二是整份报告书里 SQL 量最大的一节：建库、建 schema、建表、加约束、建索引、删索引一条龙。这里最容易出问题的不是 SQL 语法本身，而是执行顺序。openGauss 对对象依赖查得很严格，父表没建就去建子表，外键直接报错。

4.1 表空间与数据库的创建顺序

报告里创建数据库分三步走，第一步先建表空间：

CREATE TABLESPACE tpcds_local RELATIVE LOCATION 'tablespace/tablespace_1';

RELATIVE LOCATION表示相对路径，相对的是数据库数据目录。括号后面那段字符串指向一个子目录，这个子目录最好提前建好，不然第一次执行时可能报目录不存在。第二步创建数据库时指定表空间：

CREATE DATABASE db_sc WITH TABLESPACE = tpcds_local; ALTER DATABASE db_sc RENAME TO db_school; \c db_school

第二行把数据库改名成 db_school，第三行切换过去。这里有个容易被忽略的点：db_sc创建时指定了表空间，换名后表空间绑定关系不会变。如果一开始没建表空间就直接CREATE DATABASE db_school，数据会落在默认表空间里，后续想迁移就得用ALTER TABLESPACE或重建，很麻烦。

4.2 schema 和四张核心表的 DDL

进入 db_school 库后，先建 schema：

CREATE SCHEMA book_eg;

schema 在 openGauss 里是数据库下的命名空间，postgres 默认有一个 public schema，所有不指定 schema 建的表都进 public。报告里专门建了 book_eg，后续把教师、院系表放进这个 schema，目的是演示“一个库下面多个 schema 互相隔离”。如果后面建表时发现权限不足，先检查当前用户有没有该 schema 的 CREATE 权限。

建完 schema，开始建表。教师信息表是第一个：

CREATE TABLE book_eg.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) );

Tno CHAR(20) PRIMARY KEY是列级主键约束，直接写在列定义后面，不需要指定列名；Tname NOT NULL保证姓名不能为空；CHECK (Sex='男' OR Sex='女')是检查约束，写入非法性别会被数据库拒绝。注意这里Dno暂时没加外键，因为外键指向的Departments表还没建，这就是实验二刻意安排的顺序：先建骨架，再补约束。

接下来是院系信息表，它反过来引用了 Teachers 表的主键：

CREATE TABLE Departments ( Dno CHAR(20) PRIMARY KEY, Dname CHAR(20), Dheadno CHAR(20), FOREIGN KEY (Dheadno) REFERENCES Teachers(Tno) );

这里FOREIGN KEY (Dheadno) REFERENCES Teachers(Tno)是表级外键约束，写在整个表定义的末尾，必须明确指定列名。Departments的系主任编号引用Teachers的教师编号，所以 Teachers 必须先建。Student、Course 两张表逻辑一样，Students.Sno主键、Dno外键引用Departments.Dno；Courses里Period和Credit用SMALLINT，实验报告里特别辨析了 SMALLINT 和 INT 的范围差异，选 SMALLINT 就够用。

选课表 SC 是典型的多对多中间表：

CREATE TABLE SC ( Sno CHAR(20), Cno CHAR(20), Grade SMALLINT, PRIMARY KEY (Sno, Cno), FOREIGN KEY (Sno) REFERENCES Students(Sno), FOREIGN KEY (Cno) REFERENCES Courses(Cno) );

PRIMARY KEY (Sno, Cno)是联合主键，表示一个学生选一门课只对应一条记录。两个外键分别在 Students 和 Courses 的主键上，建表之前必须确保这两张表已存在。Teaches 教学信息表的结构和 SC 几乎一样，主键是 (Tno, Cno)，照着写就行。

4.3 修改表结构与外键约束

由于 Teachers 表的 Dno 在初始建表时没有加外键，实验二里专门用一条 ALTER 语句补上，这一步也是完整性控制实验五的前置操作：

ALTER TABLE Teachers ADD CONSTRAINT fk_teachers_dno FOREIGN KEY (Dno) REFERENCES Departments(Dno);

ADD CONSTRAINT给外键起名fk_teachers_dno，后面指定列和引用目标。为什么不用建表时直接写外键？因为 Teachers 和 Departments 互相引用：Teachers 的 Dno 要引用 Departments 的主键，Departments 的 Dheadno 又要引用 Teachers 的主键，这种循环依赖必须先建两张空表骨架，再用 ALTER 补外键，否则第二张表建的时候就会报第一张表不存在。这是实验二里最值得记下来的设计思路。

补完外键，可以顺手验证一下 CHECK 约束是否在生效：

INSERT INTO Teachers (Tno, Tname, Sex) VALUES ('T001', '测试教师', '未知');

正常情况这条 INSERT 会被数据库拒绝，报错信息会提示CHECK约束被违反。这一行失败记录恰好说明完整性控制在起作用，也是实验五“完整性控制”的实验素材。

4.4 索引和视图：建在哪个列上才有意义

创建索引是实验二后半段的重点。报告要求在 Students 表的 Dno 上创建索引：

CREATE INDEX Student_Dept ON Students(Dno);

索引能加快按系号查询学生信息的速度。需要注意，主键会自动建索引，不用重复给主键列建索引；外键列是高频查询条件，值得手动建。建完索引可以用\di查看当前库所有索引，确认是否创建成功。

实验四的视图创建也很简单，在已有表上定义一个虚拟表：

CREATE VIEW male_students AS SELECT Sno, Sname, Speciality FROM Students WHERE Sex='男';

视图不实际存储数据，查询时动态从 Students 表取数，好处是可以把常用查询条件封装起来，避免每次写一长串 WHERE。实验四里创建视图的核心目的正是理解抽象和封装，报告里还强调视图对权限控制的意义：可以只给用户开放视图，不开放原始表。

5. 避坑指南：安装、连接、SQL 三个阶段的翻车点

这一章把我反复踩过、也帮别人排查过的坑攒成清单，每个都按“现象 → 原因 → 解决”写清楚。数据库环境这东西，装坏了不可怕，可怕的是不知道去哪看日志、不知道从哪下手重来。

5.1 安装阶段：权限、目录、端口

坑一：gs_preinstall报Permission denied或No such file or directory。

现象：预安装脚本执行到一半退出，报错指向某个目录或文件无权限。原因：clusterconfig.xml 里的dataNode路径没有提前创建，或者创建后属主不是 omm。解决：执行mkdir -p /data/opengauss/data && chown -R omm:dbgrp /data/opengauss，再重跑预安装。注意 chown 必须递归到最深层目录，只给上层目录授权，数据目录下的子目录照样没权限。

坑二：装完后ss -lntp | grep 26000看不到监听，gs_om -t status显示异常。

现象：gsql 连接提示超时或拒绝连接。原因：安装时端口被占用，或 clusterconfig.xml 里 port 参数没改干净。解决：先用ss -lntp | grep 26000看有没有其他进程占着，有就换端口；没有就看日志目录下 om 开头的日志，里面会写明初始化到哪一步挂了。我遇到过的案例是前一次安装残留的 postgres 进程占着端口，kill掉后重新gs_om -t start就好。

5.2 连接阶段：omm、认证与安全

坑三：gsql -d postgres -p 26000报FATAL: password authentication failed。

现象：明明在数据库服务器本地执行，密码也对，就是连不上。原因：当前系统用户不是 omm，环境变量没加载，gsql 用错误身份发起认证。解决：先执行su - omm，再跑 gsql。su -的-很关键，它会完整加载 omm 用户的环境变量，少了这一步，你切了用户但环境变量还是旧的，有些版本会直接导致连接失败，这个坑拦住了不少初次接触 openGauss 的人。

坑四：远程 JDBC 连接报no pg_hba.conf entry for host。

现象：本地 gsql 没问题，换到另一台机器用 JDBC 或 gsql 远程连就报这个错。原因：pg_hba.conf 默认只放行了本地连接，远程 host 没有配置对应认证规则。解决：打开数据目录下的 pg_hba.conf，加一行host all all 192.168.1.0/24 sha256，重启数据库服务。这是 openGauss 的安全机制，不是 bug，实验六安全性控制里也会讲到类似场景。改这个文件前先备份，改错格式数据库会直接拒绝所有连接。

5.3 SQL 执行阶段：建表顺序与表空间目录

坑五：建 SC 表或 Departments 表时报relation "students" does not exist。

现象：CREATE TABLE 语句里写了 FOREIGN KEY，执行时提示被引用的表不存在。原因：建表顺序错了，子表先于父表创建。解决：按依赖顺序建表，先 Teachers、Departments、Students、Courses，再建 SC 和 Teaches；遇到循环引用就按第 4 章的做法，先建表骨架，再 ALTER 补外键。这个坑在实验二里几乎是必踩的，报告里把建表顺序排好正是为了避开它。

坑六：CREATE TABLESPACE报目录不存在。

现象：执行CREATE TABLESPACE tpcds_local RELATIVE LOCATION 'tablespace/tablespace_1'提示路径有问题。原因：RELATIVE LOCATION 后面是相对路径，指向数据目录下的子目录，这个目录不会自动创建。解决：先mkdir -p $GAUSSDATA/tablespace/tablespace_1，再把目录属主改成 omm:dbgrp，最后执行建表空间命令。也可以直接写成绝对路径的 ABSOLUTE LOCATION，但报告里用的是 RELATIVE，按它的方式来环境更统一。

6. 验证跑通：备份恢复和 JDBC 直连

环境装好、表也建完，最后一步是验证整套系统真的能跑起来，而不是“看着像好的”。我习惯做两个验证：一个用 gs_dump 备份再恢复，确认数据能搬走也能搬回；一个用 JDBC 直连，确认从程序侧也能正常读写。这两步都过了，这套环境才算真正交付。

6.1 gs_dump 备份恢复验证

用 openGauss 自带的逻辑备份工具 gs_dump，把 db_school 全库导出：

gs_dump -U omm -W '你的密码' -p 26000 db_school -f /home/omm/db_school_$(date +%F).sql

-U指定用户，-W接密码，-p指定端口，-f指定导出文件路径，文件名里的$(date +%F)会让每次备份带日期。导出完成后，建一个空库再导入，验证备份文件完整可用：

gsql -d postgres -p 26000 -c "CREATE DATABASE db_school_restore" gsql -d db_school_restore -p 26000 -f /home/omm/db_school_$(date +%F).sql

第二条用 gsql 执行 SQL 文件把数据灌进新库。导入后\dt看表是否齐全，再SELECT COUNT(*)抽查数据量。这一套走通，实验八“备份与恢复”就算真正落地了。

6.2 JDBC 连接与授权验证

JDBC 直连是实验九的要求，也是数据库应用开发的起点。先用普通用户完成授权：

GRANT CONNECT ON DATABASE db_school TO lab_user; GRANT SELECT, INSERT, UPDATE ON Students TO lab_user;

然后用 Java 代码连接数据库，跑一条最简单的查询：

import java.sql.*; public class OpenGaussConnect { public static void main(String[] args) throws Exception { Class.forName("com.opengauss.jdbc.Driver"); String url = "jdbc:opengauss://127.0.0.1:26000/db_school"; try (Connection conn = DriverManager.getConnection(url, "lab_user", "Lab@123456")) { Statement st = conn.createStatement(); ResultSet rs = st.executeQuery("SELECT COUNT(*) FROM Students"); if (rs.next()) { System.out.println("total students: " + rs.getInt(1)); } } } }

Class.forName加载 openGauss 的 JDBC 驱动，URL 格式是jdbc:opengauss://主机IP:端口/数据库名，连接用户和密码用前面建的 lab_user。驱动 jar 包优先用 openGauss 安装包自带的版本，版本和数据库大版本不匹配会出现各种诡异连接错误，这个坑我踩过后就再也没换过别的来源。从那以后我每次帮人验收 openGauss 环境，都强制走一遍“起服务 → gsql 连一次 → 查一张表 → gs_dump 备份 → JDBC 跑一条 SQL”的完整链路，基本能在几分钟内暴露八成配置问题。这份实验报告书我放在资源位，照着它把九个实验完整走一遍，数据库这门课的环境部分就不会再拦你了。希望帮到你。

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