区块链表强制使用ASSM且不支持手动段管理、STORAGE子句、MOVE或SHRINK；必须置于本地管理且启用RETENTION GUARANTEE的表空间中，隐藏列导致存储开销剧增，PURGE_EXPIRED_ROWS需定时主动调用。
区块链表不支持手动段管理
Oracle 21c 的区块链表（BLOCKCHAIN TABLE）强制使用自动段空间管理（ASSM），且不允许指定 SEGMENT CREATION IMMEDIATE 或 DEFERRED。建表时若显式写入 STORAGE 子句（如 INITIAL、NEXT、PCTINCREASE），会直接报错 ORA-02205: only SELECT and ALTER privileges are allowed —— 实际上是语法拒绝，而非权限问题。
这是因为区块链表的物理结构由 Oracle 内部严格控制：每行附加哈希链元数据、隐式系统列（如 ORABCTAB_HASH$）、固定大小的块内对齐方式，导致段分配逻辑与普通堆表完全不同。
- 不能在
CREATE BLOCKCHAIN TABLE语句中使用STORAGE、TABLESPACE以外的存储子句 -
TABLESPACE可指定，但该表空间必须为本地管理（LOCAL）、自动段空间管理（AUTO） - 尝试
ALTER TABLE ... MOVE TABLESPACE会失败，报ORA-05721: Cannot move blockchain table
表空间选择直接影响保留策略生效
区块链表的保留时间（NO DELETE UNTIL ...）依赖于底层段的清理机制，而该机制与表空间的属性强绑定。如果表空间启用了 SEGMENT SPACE MANAGEMENT AUTO（必须），但未启用 RETENTION GUARANTEE，则过期行可能无法被及时标记为可回收，导致 DBMS_BLOCKCHAIN_TABLE.PURGE_EXPIRED_ROWS 执行时返回 0 行被清理。
典型错误现象：SELECT COUNT(*) FROM USER_TAB_MODIFICATIONS 显示有大量已过期行，但 PURGE_EXPIRED_ROWS 不起作用。
- 建表前确认表空间开启保留保证：
ALTER TABLESPACE users RETENTION GUARANTEE - 不可对 SYSTEM、SYSAUX 表空间启用
RETENTION GUARANTEE，否则创建区块链表会失败 - 临时表空间、撤销表空间不能用于区块链表
隐藏列与实际存储开销远超预期
每个区块链表自动包含至少 5 个隐藏系统列（如 ORABCTAB_CREATION_TIME$、ORABCTAB_USER_NUMBER$、ORABCTAB_HASH$、ORABCTAB_SIGNATURE$、ORABCTAB_SEQ_NUM$），其中 ORABCTAB_HASH$ 是 RAW(64)（SHA2-512 输出），ORABCTAB_SIGNATURE$ 默认为 RAW(512)（ECDSA 签名）。这意味着即使业务列只占 20 字节，单行物理存储至少增加 600+ 字节。
这直接影响你对“能存多少行”的预估 —— 尤其当设置 NO DELETE UNTIL 1000 DAYS AFTER INSERT 时，历史数据堆积速度比普通表快一个数量级。
- 用
DBMS_SPACE.OBJECT_SPACE_USAGE查看真实空间占用，别信USER_SEGMENTS.BYTES的粗略值 - 避免在高插入频次场景下设置过长的保留期；测试时先用
NO DELETE UNTIL 16 DAYS AFTER INSERT（最小合法值）验证空间增长节奏 - 没有
COMPRESS选项可用，区块链表不支持任何行压缩或高级压缩
PURGE_EXPIRED_ROWS 的执行时机很关键
DBMS_BLOCKCHAIN_TABLE.PURGE_EXPIRED_ROWS 不是后台自动任务，也不响应 DML 触发器。它必须由 DBA 主动调用，且仅清理“已明确过期 + 当前行所在区（extent）已无活跃事务引用”的数据。若刚插入一批数据就立刻执行，几乎不会删掉任何行 —— 因为 Oracle 需要等待延迟清理窗口（通常为 1 小时）后才将过期标记固化。
常见误操作：在应用层插入后立即调用 purge，发现没效果，就反复重试，反而引发大量递归 SQL 和闩锁争用。
- 建议在维护窗口定期调度，例如每天凌晨 2 点：
EXEC DBMS_BLOCKCHAIN_TABLE.PURGE_EXPIRED_ROWS('SCOTT', 'BCT_LOG'); - 该过程不释放文件空间，只将块标记为可重用；后续需配合
ALTER TABLE ... SHRINK SPACE COMPACT（但区块链表不支持 shrink）→ 实际上只能靠段自动重用或重建表 - 注意：
PURGE_EXPIRED_ROWS会持有TX锁，长时间运行可能阻塞新插入
