READ ONLY表空间物理文件仍被写入，因其只限制SQL层DML/DDL，不禁止CKPT更新文件头SCN、DBWn刷旧脏块等后台元数据操作；这些写入属原子、幂等管理行为，不影响数据一致性与RMAN备份安全。
READ ONLY表空间的物理文件为何还在被写入？
Oracle里把表空间设为READ ONLY，不等于“物理上禁止任何写入”。这个状态只控制SQL层的数据修改行为（如INSERT、UPDATE、CREATE），但底层文件仍可能被后台进程以元数据或管理目的写入。
根本原因在于：READ ONLY是逻辑状态，不是文件系统级的只读锁。数据库仍需维护一致性、检查点、文件头信息等，这些操作绕过用户事务流程，直接触发物理写。
哪些后台进程会写READ ONLY表空间的文件？
-
CKPT进程：每次增量检查点都会更新数据文件头块（Block 0）中的Checkpoint SCN，无论该文件所属表空间是否只读 -
DBWn进程：若该表空间中仍有脏块（例如在设为只读前未刷完的缓冲区），DBWn仍会按LRU策略将其写出；不过一旦设为只读，后续不会产生新脏块 -
ARCn进程：归档日志本身不写数据文件，但若该表空间包含活动undo或临时段（极少见），可能间接触发关联写入 - 文件头/位图块更新：热备份开始/结束、
ALTER DATABASE BACKUP CONTROLFILE等操作，也会单块写入文件头
特别注意：db file single write等待事件在只读表空间上依然可能出现——它反映的就是CKPT对文件头的同步写，和表空间读写属性无关。
如何验证写入来源？
别只看dba_tablespaces.status，要结合等待事件和文件级I/O追踪：
- 查当前对该文件的写等待：
SELECT event, p1text, p1, p2text, p2 FROM v$session_wait WHERE event = 'db file single write' AND p1 = &file_id;
- 确认文件头是否被频繁更新：
SELECT file#, block#, status FROM v$database_block_corruption WHERE file# = &file_id AND block# = 0;
- 检查最近是否有检查点动作：
SELECT to_char(last_checkpoint_time, 'yyyy-mm-dd hh24:mi:ss') FROM v$datafile WHERE file# = &file_id;
如果last_checkpoint_time持续更新，基本可断定是CKPT在写文件头。
这会影响只读语义或备份一致性吗？
不影响。文件头更新是原子、幂等、受控的元数据操作，不改变用户数据块内容，也不破坏备份一致性。RMAN BACKUP 或 COPY 均能安全处理READ ONLY表空间——只要备份开始时表空间已置为只读，其所有数据块就处于稳定状态。
真正要警惕的是：有人误以为“只读=绝对静止”，从而跳过对这类文件的定期RMAN VALIDATE或DBV校验。而文件头损坏或存储层静默错误，恰恰最容易藏在这种“看似不动”的文件里。
