LMT+ASSM是Oracle 9i后唯一合理选择，必须显式启用本地管理表空间和自动段空间管理，禁用字典管理与手工管理，严格遵循表空间隔离、分区物理分离、LOB独立存储及阈值预扩容等规范。
用 LMT + ASSM 是当前唯一合理选择
Oracle 9i 之后所有生产环境必须启用本地管理表空间（LMT）和自动段空间管理（ASSM），字典管理表空间（DMT）和手工段管理（MSSM）已彻底淘汰。强行沿用会引发高并发下的争用、位图锁、区分配延迟等隐性故障。
创建表空间时必须显式指定：EXTENT MANAGEMENT LOCAL 和 SEGMENT SPACE MANAGEMENT AUTO。缺省行为虽已是 ASSM，但显式声明可避免因版本差异或脚本复用导致的误配置。
-
UNIFORM SIZE仅在极少数场景适用（如固定大小 LOB 段批量写入），绝大多数业务表应使用AUTOALLOCATE，由 Oracle 自动按 64K → 1M → 8M → 64M 递增分配区，兼顾小对象紧凑性和大对象扩展效率 - 不要在
CREATE TABLE或ALTER TABLE中指定INITIAL/NEXT参数——这些参数在LMT+ASSM下已被忽略，只会在 DDL 日志里埋下误导线索 - 数据文件大小需为区大小整数倍 + 64K（例如用
UNIFORM SIZE 4M，则文件大小应为4M * N + 64K），否则尾部空间无法被利用
SYSTEM 表空间绝不能存业务对象
哪怕只是临时建个测试表，也绝对禁止在 SYSTEM 表空间上创建任何用户段。它只承载数据字典、回滚段头、系统包等不可删除对象。一旦业务表意外落入 SYSTEM，后续迁移成本极高，且可能触发 ORA-01652（无法扩展临时段）等连锁错误。
检查方式：SELECT owner, segment_name, tablespace_name FROM dba_segments WHERE tablespace_name = 'SYSTEM' AND owner NOT IN ('SYS','SYSTEM','OUTLN','XDB');
- 新建用户时必须显式指定
DEFAULT TABLESPACE和TEMPORARY TABLESPACE，不能依赖数据库默认值 - 临时表空间必须用
CREATE TEMPORARY TABLESPACE创建，而非普通表空间加TEMPORARY属性；否则排序操作失败时不会报错，而是静默降级为磁盘排序，拖垮性能 - 回滚表空间（
UNDO TABLESPACE）必须独立，且禁用OPTIMAL参数；现代 Oracle 依赖自动调优，硬编码OPTIMAL反而会引发频繁 shrink/extend
分区表的表空间要物理隔离
分区不是逻辑技巧，而是物理布局策略。每个高频访问的分区（尤其是按时间滚动的分区）应落在独立表空间，且该表空间只放这一个分区段。这样做的核心目的是：避免 HWM（高水位线）污染、控制备份粒度、隔离 IO 热点、防止某一分区异常膨胀拖垮整个表空间。
例如日志表按月分区，PARTITION p_202607 应专属 TBS_LOG_202607，而不是塞进通用 TBS_LOG。
- 分区表的索引必须用
LOCAL，且每个分区索引放在对应的数据表空间（或镜像命名的索引表空间），避免全局索引维护开销和单点失效 - 不要为每个分区单独建数据文件——一个表空间配 1～3 个数据文件足够；过多文件会加剧 checkpoint 和 backup 负载
- LOB 字段必须单独指定
LOB (col) STORE AS (TABLESPACE tbs_lob)，否则默认跟主表挤在同一表空间，极易因大对象碎片化拉低整体空间利用率
监控阈值和扩容动作必须绑定
表空间不是“满了再扩”，而是“达到阈值就触发预扩容”。生产库中，USED_PCT > 85% 就必须启动扩容流程，不能等告警邮件才响应。
关键监控 SQL 必须固化进巡检脚本：SELECT tablespace_name, ROUND((bytes_used / GREATEST(bytes_used + bytes_free, 1)) * 100, 2) AS pct_used FROM v$tablespace ts JOIN dba_data_files df ON ts.ts# = df.ts# GROUP BY tablespace_name, bytes_used, bytes_free;
- 临时表空间监控不能只看
v$temp_space_header，还要查v$sort_segment的CURRENT_USERS和USED_EXTENTS，突发排序高峰可能瞬间耗尽空间 - 发现单个段（
dba_segments）占表空间超 40%，且持续增长，应立即分析其访问模式——大概率是未分区的大表或归档逻辑缺陷 - 扩容不是简单
ALTER DATABASE DATAFILE ... RESIZE；对已存在大量小区（extents）的旧表空间，优先ALTER TABLESPACE ... ADD DATAFILE新文件，再迁移段，避免区合并引发的锁等待
实际部署中最容易被跳过的环节，是验证新表空间是否真正被业务会话使用——很多 DBA 扩容后没重连应用连接池，或没刷新 JDBC 连接字符串中的 default schema 配置，结果新对象仍在旧表空间里悄悄生长。
