本文介绍在 oracle 数据库环境下，利用 oracle flashback table 特性，在 spring boot 集成测试中自动回滚 `data.sql` 脚本执行的 dml 修改，确保测试间数据隔离且不污染原始数据库。
在基于 Spring Boot 2.x 的集成测试中，当底层 Oracle 数据库已存在历史数据（如含 NULL 值的布尔字段），而测试又依赖特定数据状态时，直接通过 data.sql 执行 UPDATE 等语句虽能临时修复数据，但会永久修改数据库——这违反了“测试不可改变生产/共享环境”的基本原则。此时，Flashback Table 是 Oracle 提供的轻量级、事务级回滚机制，无需重启数据库或重建容器，即可将指定表精确恢复至某一时间点（或还原点）的状态，完美契合测试场景下的数据快照与还原需求。
✅ 实现步骤概览
整个方案分为三阶段：前置准备 → 测试前打点 → 测试后回滚，需结合 Spring 的测试生命周期钩子（如 @BeforeAll / @AfterAll 或 @BeforeEach / @AfterEach）实现自动化控制。
1. 启用行移动（一次性配置）
Flashback Table 要求目标表启用 ROW MOVEMENT。该操作仅需执行一次，且为无害元数据变更：
ALTER TABLE my_table1 ENABLE ROW MOVEMENT; ALTER TABLE my_table2 ENABLE ROW MOVEMENT; -- 注意：此操作不可逆，但实际影响极小（仅增加微量系统表空间占用）
⚠️ 提示：建议在测试专用数据库或 schema 中提前批量执行（可通过 Flyway/Liquibase 初始化脚本统一管理）。
2. 创建还原点（测试前）
在每个测试类或测试方法执行前，创建唯一命名的还原点，标记当前数据库一致状态：
CREATE RESTORE POINT test_restore_point_001;
Spring 中可借助 DataSourceUtils.getConnection() 获取原生连接并执行：
@BeforeAll
static void setUpRestorePoint() throws SQLException {
try (Connection con = DataSourceUtils.getConnection(dataSource);
Statement stmt = con.createStatement()) {
stmt.execute("CREATE RESTORE POINT test_restore_point_001");
}
}3. 执行 data.sql 并运行测试
此时 data.sql（含 UPDATE ... WHERE col IS NULL 等语句）正常加载，所有 DML 变更生效，但不会提交到长期状态——因为后续将被 Flashback 撤销。
4. 回滚至还原点（测试后）
测试结束后，对涉及的所有表执行 Flashback：
FLASHBACK TABLE my_table1, my_table2 TO RESTORE POINT test_restore_point_001;
对应 Java 代码示例（使用 @AfterAll）：
@AfterAll
static void tearDownFlashback() throws SQLException {
try (Connection con = DataSourceUtils.getConnection(dataSource);
Statement stmt = con.createStatement()) {
stmt.execute("FLASHBACK TABLE my_table1, my_table2 TO RESTORE POINT test_restore_point_001");
stmt.execute("DROP RESTORE POINT test_restore_point_001"); // 清理还原点（可选）
}
}⚠️ 关键注意事项
-
UNDO 保留期限制：Oracle 默认仅保留有限时间内的 UNDO 数据（由 UNDO_RETENTION 参数控制）。若测试执行周期长（如跨小时/天），需配置保证型还原点（Guaranteed Restore Point） 并增大 UNDO 表空间：
CREATE RESTORE POINT test_grant_point GUARANTEE FLASHBACK DATABASE;
- 仅支持 DML，不支持 DDL：Flashback Table 无法恢复 ALTER TABLE、DROP COLUMN 或序列值变更；若测试涉及结构修改，请改用 @Sql + @SqlConfig(transactionMode = ISOLATED) 或容器化 DB 方案。
- 权限要求：执行用户需具备 FLASHBACK ANY TABLE 或对目标表有 FLASHBACK 权限，并拥有 SELECT ANY DICTIONARY（用于查询还原点）。
- 事务边界：Flashback 是 DDL 级操作，会隐式提交当前事务，因此务必确保其在测试事务之外执行（即不在 @Transactional 测试方法内调用）。
? 替代方案对比（简要）
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Flashback Table | 零停机、低开销、精准回滚 | 依赖 Oracle、需 UNDO 空间管理 | 已有 Oracle 环境，无容器条件 |
| Testcontainer + Oracle XE | 完全隔离、状态可重现 | 启动慢、资源占用高 | 新项目、CI 环境、高一致性要求 |
| H2 内存数据库（兼容模式） | 极速、零依赖 | Oracle 特有语法/行为可能不兼容 | 单元测试为主，非严格 SQL 兼容场景 |
综上，对于已有 Oracle 集成测试环境且无法引入容器技术的团队，Flashback Table 是兼顾可行性、性能与数据安全的务实选择。只需少量数据库配置与 Spring 生命周期集成，即可实现 data.sql 的“临时生效 + 自动清理”，真正达成测试数据的按需治理。
