真正隔离需收束数据流、临时流、回滚流：必须分离索引表空间与临时表空间，设置显式TABLESPACE、配额及专用undo，禁用UNLIMITED TABLESPACE。
CREATE TABLESPACE 和 ALTER USER 是实现应用级表空间隔离最直接有效的两个操作，但光建表空间、改默认值远远不够——配额没设、索引没分离、临时段没指定，照样会相互干扰。
为什么 DEFAULT TABLESPACE 不足以实现真正隔离
用户创建时指定了 default tablespace，只影响未显式指定表空间的 create table 或 create index 语句。但实际中常见三类漏网之鱼：
- 开发写 DDL 时习惯不加
TABLESPACE子句，依赖默认值——看似省事，实则把索引、LOB、分区子表全塞进同一数据文件，I/O 竞争加剧 -
CREATE INDEX若未指定TABLESPACE，默认落在用户默认表空间，而索引访问模式和表完全不同，混放会拖慢 OLTP 响应 - 大事务排序、哈希连接产生的临时数据，走的是用户的
TEMPORARY TABLESPACE，如果多个应用共用temp，容易因ORA-1652: unable to extend temp segment报错中断
CREATE TABLESPACE 必须带的关键参数
本地管理 + 自动段空间管理是底线，否则无法支撑高并发写入和细粒度配额控制：
- 必须包含
EXTENT MANAGEMENT LOCAL：避免字典管理表空间在高并发下争用UET$/FET$表锁 - 必须指定
SEGMENT SPACE MANAGEMENT AUTO：手动管理（MANUAL）会导致INSERT性能随碎片恶化，且无法支持 ASSM 下的位图块管理 -
AUTOEXTEND ON NEXT要谨慎：生产环境建议NEXT值设为固定大小（如10M），避免每次扩展都触发系统调用；MAXSIZE必须设上限，否则可能撑爆文件系统
示例（安全可用）：
CREATE TABLESPACE ts_app1 DATAFILE '/u01/oradata/ts_app1.dbf' SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 1G EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
用户配额与对象显式落表空间的双重保险
只靠 DEFAULT TABLESPACE + QUOTA 仍不可靠，因为：
-
QUOTA 100M ON ts_app1只限制该用户在ts_app1的使用量，但如果他误执行CREATE TABLE t1 TABLESPACE users，就绕过了配额 - DBA 无法从 DDL 日志里快速识别哪个应用创建了跨表空间对象，排查成本陡增
正确做法是双约束：
- 对每个应用用户执行
ALTER USER app1_user QUOTA 0 ON users，强制其不能往系统默认表空间写数据 - 所有建表/建索引语句必须显式带
TABLESPACE，CI 流水线中加入 SQL 审计规则，拦截不含该子句的 DDL - 索引统一落到专用索引表空间（如
ts_app1_idx），与数据表空间物理分离，减少随机读写干扰
临时表空间和还原表空间不能“共享”
很多团队为省事让所有应用用户共用 temp 和 undotbs1，这是性能地雷：
-
temp共享时，大报表查询的排序可能挤占 OLTP 用户的临时段，触发ORA-01652；应为每类负载建独立临时表空间，如temp_oltp、temp_report -
undotbs1若被多个长事务应用争用，可能提前覆盖未提交事务的 undo 数据，导致ORA-01555快照过旧错误；RAC 环境下更需为每个实例配专属 undo 表空间（如undotbs2） - 不要给应用用户授予
UNLIMITED TABLESPACE权限——它会绕过所有表空间配额，等同于开放磁盘写入白名单
真正隔离不是建几个表空间就完事，而是让每个应用的数据流、临时流、回滚流，从路径到配额全部收束在可控边界内。最容易被跳过的其实是索引表空间分离和临时段隔离，这两点一旦忽略，业务高峰时的 I/O 毛刺几乎必然出现。
