assm 无法通过 alter tablespace 启用，必须重建表空间；新建时需同时指定 extent management local 和 segment space management auto；验证需检查 dba_tablespaces 及实际 dml 后的位图块使用情况。
ASSM 不能 ALTER TABLESPACE 修改
已存在的表空间无法通过 ALTER TABLESPACE 启用 ASSM。Oracle 11g 及后续版本中，SEGMENT SPACE MANAGEMENT AUTO 是创建时的固化属性，不是运行时开关。
常见错误操作包括：
- 执行
ALTER TABLESPACE users SEGMENT SPACE MANAGEMENT AUTO—— 直接报错ORA-12915: Cannot alter system tablespace to auto segment space management或静默忽略 - 对
SYSTEM、SYSAUX、TEMP表空间尝试指定AUTO—— 强制拒绝，这些表空间类型不支持 ASSM - 只写
SEGMENT SPACE MANAGEMENT AUTO却漏掉EXTENT MANAGEMENT LOCAL—— DDL 会成功，但实际启用的是 MSSM，因为 LOCAL 是 ASSM 的硬性前提
必须重建表空间才能迁移到 ASSM
真实迁移路径只有“导出 → 删除 → 新建 → 导入”四步，没有捷径。在线重定义（DBMS_REDEFINITION）只能换表的存储位置，不能改变底层段管理机制。
关键实操点：
- 新建表空间时必须同时声明：
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO，顺序不能颠倒 - 导出前确认所有对象（尤其 IOT 溢出段）都显式指定了
INCLUDING子句，否则溢出段仍落在 MSSM 表空间里 -
NEXT参数在 ASSM 下失效，迁移后应从表定义中移除，避免误导维护人员 - 临时表空间（
TEMP）无法使用 ASSM，迁移时需单独处理，不能混入同一脚本
怎么确认 ASSM 真正生效了
DBA_TABLESPACES.SEGMENT_SPACE_MANAGEMENT = 'AUTO' 只说明“设计上支持”，不代表数据段已实际使用位图管理。
验证要点：
- 对具体表执行
EXEC DBMS_SPACE.SPACE_USAGE('OWNER', 'TABLE_NAME', 'TABLE')，若返回的unformatted_blocks非空，才表示位图块已生成并介入管理 - 刚建完但没插入数据的表（
SEGMENT CREATION DEFERRED），DBA_SEGMENTS查不到记录，此时 ASSM 实际未激活 - 高并发小行插入时出现
enq: TX - allocate ITL entry等待事件，且 P2 解码指向 type#=20 的块，是 ASSM 位图块争用的直接证据
ASSM 生效的前提是真实 DML 行为
位图块不会因建表空间就自动铺开，它只在首次分配区段（ALLOCATE EXTENT）或第一次 INSERT 时生成。没数据、没并发，就看不到 ASSM 的优势，也暴露不出位图争用问题。
容易被忽略的细节：
-
ALTER TABLE ... MOVE TABLESPACE不触发 ASSM 位图初始化，只是物理移动数据块；新表空间是 ASSM，但原段头结构不变，需后续 DML 才真正切换 -
SHRINK SPACE命令仅对 ASSM 表空间有效，执行前务必确认表所在表空间确为AUTO，否则报ORA-10635 - IOT 主表启用了 ASSM，其溢出段默认仍是 MANUAL，必须显式加
OVERFLOW TABLESPACE assm_ts INCLUDING
