Oracle Database 23ai未引入表空间新机制，仍沿用CDB/PDB架构，表空间为PDB级逻辑单元；Free版有12GB用户数据硬限制，TEMP/UNDOTBS1不计入；PDB表空间须独立管理；强制ASSM，禁用MANUAL；AI特性不改变存储逻辑。
Oracle Database 23c（现名 Oracle Database 23ai）在表空间管理上**没有引入颠覆性新机制**，它延续了自 12c 多租户架构以来的逻辑模型，仍以容器数据库（CDB）和可插拔数据库（PDB）为组织基础。表空间本身仍是 PDB 级别的逻辑存储单元，不跨 PDB 共享——这点和 12c–19c 一致。
但有几个实际使用中容易被忽略、却影响运维判断的关键点，值得你动手前就确认：
表空间自动扩展行为在 Free 版有隐式限制
即使你显式设置了 DATAFILE ... AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED，Oracle Database Free（含 23ai Free）仍会强制拦截超出 12 GB 用户数据量 的增长，报错 ORA-122592。这不是表空间配置失效，而是实例级硬限制。此时 DBA_TABLESPACES 里看到的 MAX_SIZE 仍是 UNLIMITED，但实际扩展会在写入时被截断。
- 检查当前用户数据用量：
SELECT SUM(bytes)/1024/1024/1024 gb FROM dba_segments WHERE tablespace_name = 'USERS'; - Free 版不区分 SYSTEM/SYSAUX/USERS，所有用户对象都计入 12 GB 总配额
- 临时表空间（
TEMP）和撤销表空间（UNDOTBS1）不计入该限制，但它们的物理文件仍受主机磁盘约束
PDB 级表空间无法在 CDB$ROOT 中直接创建或管理
你在 CDB$ROOT 下执行 CREATE TABLESPACE，只会作用于根容器自身（极少这么做），不会自动传播到任何 PDB。每个 PDB 必须独立管理自己的表空间——包括创建、扩缩容、设置默认表空间等。
- 切勿在
CDB$ROOT中用ALTER DATABASE DEFAULT TABLESPACE试图影响 PDB；该语句只对根库生效 - 批量为多个 PDB 设置默认表空间？必须逐个
ALTER PLUGGABLE DATABASE后，在各自会话中执行OPEN ALTER DATABASE DEFAULT TABLESPACE users; -
DBA_TABLESPACES视图在 CDB$ROOT 中只显示根库的表空间；要查某个 PDB 的，需连接到该 PDB 或查CDB_TABLESPACES
自动段空间管理（ASSM）仍是默认且不可关闭
Oracle 23ai 继续强制使用 ASSM（SEGMENT SPACE MANAGEMENT AUTO），手动段空间管理（MANUAL）在建表空间时已被拒绝。这不是 bug，是明确的废弃行为。
- 尝试执行
CREATE TABLESPACE tbs1 DATAFILE '/u01/oradata/tbs1.dbf' SIZE 100M SEGMENT SPACE MANAGEMENT MANUAL;会报错ORA-600 [ktspsm_1]（内部错误码） - ASSM 对 OLTP 和混合负载更友好，但如果你依赖
FREELISTS或FREELIST GROUPS做精细并发控制，这些参数在 23ai 中已完全失效 - 高水位线（
HWM）调整逻辑未变，但SHRINK SPACE COMPACT在 23ai 中对分区表支持更稳，建议优先用它替代ALTER TABLE ... MOVE
真正需要警惕的是：**别把“AI”特性误读成“自动化运维”**。向量索引、JSON 表函数、TEXT2SQL 这些新能力，全运行在现有表空间结构之上，不改变底层存储逻辑。你依然得亲手规划 SYSTEM、SYSAUX、USERS、TEMP、UNDOTBS1 的初始大小与增长策略——尤其在 Free 版里，12 GB 用完就是用完，不会因为开了 AI 功能就多给一兆。
