最可靠方法是查询v$database视图，执行select log_mode from v$database返回archivelog才表示真正开启归档模式；archive log list可能缓存旧信息，不可靠。
必须停库到 MOUNT 状态才能切换，没有在线开启归档模式这回事。
怎么确认当前真是 ARCHIVELOG 模式？
别信 ARCHIVE LOG LIST 的输出——它可能缓存旧状态，尤其在刚重启或参数改过但没生效时。最可靠的方式是查 V$DATABASE 视图：
- 执行
SELECT log_mode FROM V$DATABASE;，返回ARCHIVELOG才算真开了 - RAC 环境下每个实例都得单独查，不能只看一个节点
- 如果返回
NOARCHIVELOG，说明还没切，ARCHIVE LOG START这类命令在 12c+ 已废弃，执行了也没用
切换前必须做完的三件事
漏掉任意一项，ALTER DATABASE ARCHIVELOG 就会卡住或报错（比如 ORA-00265 或 ORA-01126）：
- 数据库必须处于
MOUNT状态：先SHUTDOWN IMMEDIATE，再STARTUP MOUNT；不能跳过MOUNT直接OPEN后操作 - 至少设好一个有效归档路径：
LOG_ARCHIVE_DEST_1必须配置，LOG_ARCHIVE_DEST（旧参数）在 10g+ 已失效 - 目标目录要存在、Oracle 用户有写权限；Linux/macOS 用正斜杠
/，Windows 用反斜杠\，写错会直接报ORA-16018
最小安全切换操作集
不加多余参数，不碰 RMAN，只做核心动作：
-
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u01/archivelog' SCOPE=BOTH;（Linux 示例；如用DB_RECOVERY_FILE_DEST，确保空间足够） -
ALTER DATABASE ARCHIVELOG;—— 成功后立刻再查一遍V$DATABASE.LOG_MODE -
ALTER DATABASE OPEN;—— 此时数据库才真正可用
切完必须验证归档是否真在写入
很多人以为 ALTER DATABASE ARCHIVELOG 成功就结束了，其实只是“允许归档”，ARCn 进程未必启动，归档日志也未必生成：
- 手动触发一次日志切换：
ALTER SYSTEM SWITCH LOGFILE; - 查
V$ARCHIVED_LOG是否有新记录：SELECT NAME, FIRST_TIME FROM V$ARCHIVED_LOG ORDER BY FIRST_TIME DESC FETCH FIRST 3 ROWS ONLY; - 去文件系统确认：
ls -lt /u01/archivelog，看到带时间戳的.dbf文件才算真正跑通 - 如果
V$ARCHIVE_DEST_STATUS.STATUS不是VALID，或ERROR列有内容（如ORA-19504），说明归档路径实际不可用
最容易被忽略的是：归档路径权限和 VALID_FOR 参数。单机环境不设 VALID_FOR 可能暂时没问题，但一旦未来加 Data Guard 或升级 RAC，归档就会静默失败——而错误日志里往往只有模糊的 ORA-16014，排查起来极耗时间。
