不能在OPEN状态下执行ALTER DATABASE ARCHIVELOG，因Oracle硬性限制该命令必须在MOUNT状态运行，否则报ORA-01126；需先SHUTDOWN IMMEDIATE再STARTUP MOUNT，且须预设归档路径、格式等参数，否则虽可打开数据库但归档失败，导致Data Guard同步中断。
直接在主库执行 alter database archivelog 是可行的，但必须确保数据库已处于 mount 状态，且归档路径、日志格式等关键参数已就绪；否则会报错或导致后续 data guard 同步失败。
为什么不能在 OPEN 状态下直接执行？
Oracle 不允许在 OPEN 状态下切换归档模式。这是硬性限制：ALTER DATABASE ARCHIVELOG 必须在 MOUNT 状态执行，否则报 ORA-01126（database must be mounted in exclusive mode and not open）。常见误操作是刚连上就执行，没先关库或没正确启动到 mount。
- 必须先
SHUTDOWN IMMEDIATE，再STARTUP MOUNT - RAC 环境要所有实例都停掉，或用
srvctl stop database -d <db_name></db_name>统一管理 - 如果使用 ASM 存储，
STARTUP MOUNT依赖 ASM 实例已运行，否则卡在 “waiting for ASM”
归档路径未配置会导致什么？
即使成功执行了 ALTER DATABASE ARCHIVELOG，若 log_archive_dest_1 或 db_recovery_file_dest 为空或不可写，数据库能打开，但归档会失败，V$ARCHIVED_LOG 中无记录，备库收不到日志——Data Guard 同步从第一步就断了。
- 推荐显式设置：
ALTER SYSTEM SET log_archive_dest_1='LOCATION=/u01/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=primary' SCOPE=BOTH; - 若用 FRA（Flash Recovery Area），确保
db_recovery_file_dest指向有足够空间的本地文件系统或 ASM diskgroup - 路径权限必须为
oracle:oinstall可读写，尤其 NFS 挂载点容易因 no_root_squash 缺失写权限
log_archive_format 改动需要重启生效吗？
不需要重启，但必须在归档模式启用后、首次归档发生前设置，否则旧格式日志已生成，新参数只对后续归档生效。格式错误（如含非法字符或长度超限）会导致归档中断，报 ORA-16038 或 ORA-00312。
- 典型安全写法：
ALTER SYSTEM SET log_archive_format='arch_%t_%s_%r.arc' SCOPE=SPFILE; -
%t（thread#）、%s（sequence#）、%r（resetlogs ID）是必须保留的占位符，漏掉任一可能导致备库解析失败 - 修改后建议立即执行一次手动归档验证：
ALTER SYSTEM ARCHIVE LOG CURRENT;，然后查ls -l /u01/arch/确认文件名符合预期
开启归档后，备库同步仍失败的常见原因
归档模式只是前提，不是充分条件。很多故障实际卡在参数传递或网络层，比如主库 log_archive_dest_2 指向的 TNS 别名在备库 tnsnames.ora 里不存在，或者监听没注册服务名。
- 主库必须设
LOG_ARCHIVE_DEST_2指向备库，例如：LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby' - 该
SERVICE=standby必须在主库和备库的$ORACLE_HOME/network/admin/tnsnames.ora中双向可解析 - 执行
tnsping standby要返回 OK，且lsnrctl status显示对应 service 已注册（不是 “UNKNOWN”）
最容易被忽略的是：归档模式开启后，FORCE LOGGING 并未自动启用。而 Data Guard 要求主库开启 FORCE LOGGING，否则部分 DML 可能不生成完整 redo，导致备库应用时报 ORA-00319 或数据不一致。务必补上：ALTER DATABASE FORCE LOGGING;
