force logging 不增加新日志，而是取消nologging豁免权，导致大批量操作redo激增；oltp日常dml不受影响，性能瓶颈集中在io与归档压力。
开启 Force Logging 本身不直接导致显著性能下降，但会强制所有本可跳过重做的操作（如 NOLOGGING DDL、/*+ append */ DML、SQL*Loader direct path）生成完整重做，实际开销取决于这些操作的频率和数据量。
Force Logging 不是“额外记日志”，而是“取消日志豁免权”
Oracle 的日志行为本质是分级控制：FORCE LOGGING 是最高优先级开关，它不增加新日志类型，也不改变单条语句的 redo 生成逻辑；它只是让所有下级设置（数据库级 NOLOGGING、表空间默认 NOLOGGING、对象级 NOLOGGING、SQL hint /*+ append */）全部失效。
换句话说：没开 FORCE LOGGING 时，一条 INSERT /*+ append */ INTO t SELECT ... 可能只写几 KB redo；开了之后，它就变成标准 INSERT，redo 量可能暴涨几十倍——这个增长不是 FORCE LOGGING 加的，而是它把原本被允许跳过的 redo 补上了。
- 真正产生开销的操作集中在：大批量数据加载、索引重建、分区维护（如
ALTER TABLE ... MOVE PARTITION）、物化视图快速刷新基表变更 - OLTP 场景日常
INSERT/UPDATE/DELETE基本不受影响，因为它们本来就是LOGGING模式 - 查当前是否启用：
SELECT force_logging FROM v$database；查哪些对象被强制了：SELECT tablespace_name, force_logging FROM dba_tablespaces
性能影响主要出现在 IO 和归档压力上
强制生成更多 redo，最直接后果是联机日志文件填满更快、归档速度必须跟上、备库应用延迟风险上升。尤其当系统本身存在以下情况时，问题会被放大：
- 联机日志组太小（如每组仅 100MB），导致频繁日志切换（
log file switch (archiving needed)等待） - 归档目标是 NFS 或慢速磁盘，
ARCH进程持续archiving log等待 - 使用 Data Guard 且备库网络带宽不足或 IO 能力弱，
LGWR ASYNC模式下主库可能因 LNS 阻塞而变慢 - 大量并行
CREATE INDEX /*+ parallel(8) */操作在FORCE LOGGING下同步写 redo，争用redo allocationlatch
实测案例：某批处理系统关闭 FORCE LOGGING 后，单次全量索引重建耗时从 23 分钟降至 6 分钟，归档日志日均体积减少 68%。
FORCE LOGGING 对物化视图日志没有额外加压
这是常被误解的一点：物化视图日志（MLOG$_xxx）的写入开销来自其自身事务同步机制，与 FORCE LOGGING 无关。无论是否开启，只要基表有 MLOG，每次 DML 就必须同步插入日志行，并等待该 INSERT 的 redo 落盘——这个过程早已是强日志行为。开启 FORCE LOGGING 并不会让 MLOG$_xxx 多写一行或改写方式。
真正拖慢 DML 的是日志表所在表空间的 IO 效率、冗余索引数量、以及是否启用 ROW MOVEMENT 或 COMPRESS（这两者反而加重 MLOG 维护负担）。
- 确认日志表位置：
SELECT table_name, tablespace_name FROM user_tables WHERE table_name LIKE 'MLOG$%' - 只保留 Oracle 默认两个索引：
I_MLOG$_xxx和I_SNAP$_xxx，其余冗余索引一律删除 - 避免将
MLOG$_xxx和业务表混放同一表空间，尤其是SYSTEM或USERS
最易被忽略的是：FORCE LOGGING 开启后，DBA 往往放松对批量操作的 redo 评估——比如仍习惯性加 /*+ append */，却忘了它已无效，结果执行计划没变、IO 压力翻倍、还误以为是存储问题。真实瓶颈不在开关本身，而在你是否重新审视了所有依赖 NOLOGGING 的流程。
