Oracle实例内实现真正物理隔离的核心是：为每个业务创建独立表空间并绑定专属数据文件路径，再创建绑定该表空间且配额受限的独立用户；三者（数据文件路径、用户默认表空间、对象实际存储位置）必须严格一致，否则隔离失效。
用独立表空间 + 独立用户实现物理隔离
oracle 实例内做到真正的物理隔离，核心就是让每个业务系统的数据文件落在不同的磁盘路径、归属不同的表空间，且用户只能访问自己名下的对象。这不是靠权限控制的“逻辑可见性”，而是数据块物理上不混存。
关键点在于：表空间是 Oracle 中唯一能绑定具体数据文件（.dbf）的逻辑容器；用户（USER）通过 DEFAULT TABLESPACE 和 QUOTA 被严格限定在某个表空间内建对象；只要不显式授权跨表空间访问（如 SELECT ANY TABLE），就无法触碰其他业务的数据文件。
- 创建表空间时必须指定绝对路径，例如：
CREATE TABLESPACE busi_a DATAFILE '/u01/oradata/orcl/busi_a01.dbf' SIZE 512M; - 创建用户时必须绑定该表空间，并限制配额：
CREATE USER app_busi_a IDENTIFIED BY 'pwd123' DEFAULT TABLESPACE busi_a QUOTA UNLIMITED ON busi_a; - 禁止授予
DBA、RESOURCE或SELECT ANY TABLE这类高危角色——哪怕只给CREATE SESSION和CREATE TABLE也够用，其余权限按需最小化授予
为什么不能只靠 Schema 名称隔离
仅靠不同用户名（即不同 Schema）但共用 USERS 表空间，数据文件仍是同一块物理磁盘上的同一个 users01.dbf。这意味着：备份恢复时无法单独导出/还原某业务系统；损坏一个数据文件可能导致多个业务同时不可用；审计或巡检时无法从文件系统层面确认某业务是否真正“独占”资源。
更隐蔽的风险是：DBA 执行 ALTER USER app_busi_a QUOTA 0 ON users; 后，该用户若未提前切换默认表空间，建表会直接报错 ORA-01950: no privileges on tablespace 'USERS' ——这种错误在上线前容易被忽略，导致应用启动失败。
检查物理隔离是否生效的三个命令
部署后必须验证，不能只信脚本执行成功。重点看数据文件路径、用户默认表空间、实际对象存储位置是否三者一致。
- 查用户默认表空间和配额：
SELECT username, default_tablespace, quota FROM dba_ts_quotas WHERE username = 'APP_BUSI_A'; - 查该用户下所有表实际所在的表空间：
SELECT table_name, tablespace_name FROM dba_tables WHERE owner = 'APP_BUSI_A'; - 查对应表空间的数据文件路径：
SELECT file_name, bytes/1024/1024 AS mb FROM dba_data_files WHERE tablespace_name = 'BUSI_A';
三者中任意一项不匹配，物理隔离就未成立。特别注意：dba_tables.tablespace_name 可能为 NULL，表示使用了用户默认表空间，此时要回溯确认 default_tablespace 是否确实指向你创建的专用表空间。
国产替代场景下要额外防的坑
迁移到金仓数据库（KingbaseES）等 Oracle 兼容库时，CREATE TABLESPACE 语法虽支持，但部分国产库对多路径、ASM 存储或裸设备的支持不完整。若沿用 Oracle 的 /u01/app/oracle/oradata/orcl/xxx.dbf 路径格式，可能因目录权限、SELinux 策略或 mount 选项报错 KSB-00102: cannot open datafile。
建议做法：
- 先用
mkdir -p /data/kingbase/busi_a创建明确归属的目录，属主设为kingbase用户 - 建表空间时用相对简洁路径：
CREATE TABLESPACE busi_a DATAFILE '/data/kingbase/busi_a/busi_a01.dat' SIZE 512M; - 避免在路径中出现空格、中文、特殊符号，国产库解析器对这些字符容忍度普遍低于 Oracle
物理隔离的边界，永远在数据文件路径和用户配额的交点上。路径错了，再细的权限控制也挡不住底层字节混写。
