Flyway 管理 Oracle 需手动引入 ojdbc11、flyway-core 10.22.0 和 flyway-oracle 10.22.0 三依赖；application.yml 必配 oracle.sqlplus: true、locations 分库路径等；建表须用 IDENTITY、CURRENT_DATE、VARCHAR2(n BYTE) 且禁用分号；baseline-on-migrate 在 PDB 中不校验结构，易致冲突。
Flyway 能管 Oracle，但默认配置会直接启动失败——因为 Spring Boot 3.x 不再自动引入 JDBC 驱动和方言支持，Oracle 的 ojdbc 和 flyway-oracle 必须手动显式声明，且版本必须对齐。
Spring Boot 3.x 必须补全的三个依赖缺一不可
Spring Boot 3.2+ 移除了所有数据库驱动的自动拉取逻辑，只保留抽象层。Oracle 场景下，光靠 spring-boot-starter-jdbc 连不上库，更别说 Flyway 自动发现方言了。
-
com.oracle.database.jdbc:ojdbc11（JDK 17+ 必选，ojdbc8在 JDK 17 下会报java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter） -
org.flywaydb:flyway-core:10.22.0（与 Spring Boot 3.2.x 兼容的最新稳定版） -
org.flywaydb:flyway-oracle:10.22.0（关键！没有它，Flyway 启动时会报Unable to instantiate JDBC driver或静默跳过迁移）
application.yml 中 Oracle 专属配置项
Oracle 对大小写、对象名引号、SQL 终止符敏感，Flyway 默认行为在 Oracle 上容易出错。以下配置不是可选项，而是上线前必须核对的底线：
-
spring.flyway.locations: classpath:db/migration/oracle（建议按数据库类型分目录，避免 MySQL 脚本误跑进 Oracle 环境） -
spring.flyway.oracle.sqlplus: true（启用 SQL*Plus 模式，支持CREATE OR REPLACE PROCEDURE等块语句；不加会导致 PL/SQL 块解析失败） -
spring.flyway.placeholders.oracle-schema: MYAPP（用于脚本中占位符替换，如CREATE TABLE ${oracle-schema}.users） -
spring.flyway.validate-on-migrate: true（Oracle DDL 执行不可逆，校验哈希能防止脚本被本地误改后上线）
V1__create_user_table.sql 在 Oracle 中必须注意的语法细节
Oracle 不支持 MySQL 风格的反引号、AUTO_INCREMENT、DEFAULT CURRENT_TIMESTAMP。一个看似简单的建表脚本，在 Oracle 上若不调整，会在 flyway_schema_history 表里留下 FAILED 记录，后续所有迁移全部阻塞。
- 主键自增要用
SEQUENCE + TRIGGER或 Oracle 12c+ 的IDENTITY列（推荐后者）：id NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY - 时间字段用
DATE或TIMESTAMP，默认值写成CURRENT_DATE或CURRENT_TIMESTAMP，不能用NOW() - 字符串长度必须带单位：
VARCHAR2(64 BYTE)而非VARCHAR2(64)（否则可能因字符集导致实际存储不足） - 每条 DDL 末尾不要加分号（
;），Flyway 会把分号当语句分隔符，导致 ORA-00911 错误
baseline-on-migrate 在 Oracle 多租户环境中的风险
如果你的 Oracle 实例启用了 PDB（Pluggable Database），而目标 Schema 已存在且非空，baseline-on-migrate: true 会自动创建 flyway_schema_history 表并标记当前为 V1，但它**不会检查该 Schema 下是否已有同名表或约束冲突**。上线前最常被忽略的一点是：Flyway 基线化只看表是否存在，不校验结构一致性。
真实踩坑场景：某次上线前 DBA 手工在生产 PDB 中执行了部分 DDL，但没走 Flyway；启用 baseline-on-migrate 后，Flyway 认为“一切从 V1 开始”，后续 V2 脚本里的 ALTER TABLE users ADD COLUMN phone VARCHAR2(20) 直接报 ORA-01430: column being added already exists——错误不在 Flyway，而在基线假设和现实的错位。
