能，但仅当配合COMPRESS FOR QUERY HIGH或INMEMORY时才显著；只读本身不压缩数据，省存儲源于减少更新空间预留、备份量及归档日志，需逐分区执行ALTER TABLE...MODIFY PARTITION...READ ONLY并满足事务、ROW MOVEMENT和权限前提。
只读分区表在23c中是否真能省存储？
能，但仅当配合COMPRESS FOR QUERY HIGH或INMEMORY压缩策略时才显著。Oracle 23c本身不因“只读”自动压缩数据；所谓“降本”本质是避免为历史分区预留更新空间、减少备份窗口和归档日志生成量，而非直接删减物理块。你得主动关掉ROW MOVEMENT、禁用UPDATE权限，并确认分区键设计能支撑长期只读——比如按CREATED_DATE做范围分区，且业务规则明确“三个月前数据不可改”。
如何把现有分区表转为只读分区？
不能全局设只读，只能逐个分区操作。核心命令是ALTER TABLE ... MODIFY PARTITION ... READ ONLY，但必须满足三个前提：
- 该分区当前没有未提交事务（否则报
ORA-14404） - 表未启用
ROW MOVEMENT（否则会隐式触发移动，破坏只读状态） - 用户有
ALTER ANY TABLE或表级ALTER权限，且目标分区属于其可访问schema
常见误操作是直接对整个表执行READ ONLY，这在分区表上不被支持——Oracle会报ORA-14501。正确做法是写脚本遍历DBA_TAB_PARTITIONS，筛选出HIGH_VALUE早于某时间点的分区，再批量执行修改。
只读分区对备份和归档的影响
这是最容易被忽略的成本节省点：只读分区不产生重做日志（NOLOGGING效果类似但更安全），意味着RMAN增量备份跳过它们，归档日志体积下降明显。实测某医疗系统将2022年前的患者档案分区设为只读后，日均归档日志从8.2GB降至3.7GB。
但注意两个边界条件：
- 即使分区只读，
DROP或TRUNCATE操作仍会产生归档日志（DDL不可逆） - 如果启用了
FORCE LOGGING数据库级设置，只读分区依然写重做——此时需评估是否真有必要全局强制
为什么23c的JSON Relational Duality让只读分区更实用？
因为你可以把频繁变更的JSON元数据（如表单配置、审批流）存在普通行存表里，而把固化的历史JSON文档（如已归档的检查报告）塞进只读分区。23c的JSON列天然支持分区裁剪，查询时WHERE doc.createtime 会自动跳过可写分区，既提速又降低IO压力。
不过别忘了：JSON字段本身不参与分区键计算，所以分区裁剪依赖的是你显式在WHERE中引用分区键列——哪怕只是AND 1=1这种恒真条件，也不能指望Oracle自动推导。
