区块链表不支持传统表空间保留策略，其数据生命周期由建表时的no drop/no delete子句控制，且不可alter修改；表空间仅负责物理存储，需监控autoextend与空间余量，并考虑15–25%写入放大。
区块链表不支持传统表空间保留策略
Oracle 21c 的区块链表（BLOCKCHAIN TABLE）本身不走普通段管理路径，它的数据存储由专用结构控制，因此无法使用 ALTER TABLESPACE ... RETENTION 或类似针对普通表空间的保留策略命令。你查不到 dba_tablespaces 里有对应保留参数，也别试图对表空间执行 RETENTION GUARANTEE——它对区块链表无效。
真正起作用的是创建时指定的 NO DROP / NO DELETE 子句
区块链表的数据生命周期完全由建表语句中的保留子句控制，不是靠表空间配置。这些子句直接写在 CREATE BLOCKCHAIN TABLE 里，且一旦设定就不能 ALTER 修改（只能重建表）：
-
NO DROP：表不可删除，哪怕为空；误用会导致测试环境无法清理 -
NO DROP UNTIL 7 DAYS IDLE：连续 7 天无新插入才允许 DROP，适合灰度验证场景 -
NO DELETE：所有行永久保留，哈希链完整性强制保障 -
NO DELETE UNTIL 30 DAYS AFTER INSERT：30 天后才允许按条件删行，需配合LOCKED防篡改
注意：NO DELETE LOCKED 和 NO DELETE 效果一致，但后者更明确；若漏写 LOCKED，后续仍不能用 ALTER TABLE ... MODIFY NO DELETE 降级策略。
表空间本身仍需常规监控，但和保留逻辑无关
虽然区块链表的“保留”不由表空间控制，但它物理上仍存于某个表空间（比如 USERS），所以该表空间的 AUTOEXTEND、MAXBYTES、剩余空间仍必须监控。否则插入失败不是因为策略拒绝，而是 ORA-01653（无法扩展表）：
- 查区块链表所在表空间：
SELECT tablespace_name FROM dba_tables WHERE table_name = 'MY_BLOCKCHAIN_TAB' - 确认该表空间下每个数据文件是否启用自动扩展：
SELECT file_name, autoextensible, ROUND(maxbytes/1024/1024, 2) AS max_mb FROM dba_data_files WHERE tablespace_name = 'USERS' - 别只看
tablespace_name，一个表空间可能含多个文件，有的开AUTOEXTEND、有的没开
真正容易被忽略的是：区块链表写入放大比普通表高（因存哈希值+签名），相同数据量下实际占用空间可能多出 15–25%，预估容量时得留足余量。
