Oracle 19c容灾端实例不自动启动的典型表现是srvctl status database显示实例未运行，根本原因是ADG备库未注册进CRS或AUTO_START设为never；必须用srvctl add database -f -r PHYSICAL_STANDBY -s MOUNT -y never显式注册，并确保数据库处于MOUNT状态。
Oracle 19c容灾端实例不自动启动的典型表现
容灾端（如adg备库）数据库服务常处于offline状态，即使主库已正常切换、网络连通、监听就绪，srvctl status database -d orcl仍显示instance orcl1 is not running。这不是数据库坏了，而是grid infrastructure默认没把它当“要管”的资源——它压根没注册进crs资源栈，或者注册了但auto_start值是never或restore。
srvctl add database必须带-force参数才能注册ADG实例
ADG备库在物理复制模式下，数据库软件和数据文件结构与主库一致，但CRS并不自动识别它为可管理资源。必须手动用srvctl显式注册，且不能省略-force：
srvctl add database -d orcl -o /u01/app/oracle/product/19.3.0.0/dbhome_1 -r PHYSICAL_STANDBY -s MOUNT -n orcl -y never -f-
-r PHYSICAL_STANDBY告诉CRS这是ADG角色，避免后续srvctl start误触发OPEN -
-s MOUNT强制初始状态为MOUNT，符合ADG常规运行态 -
-y never表示不参与集群failover（容灾端本就不该被集群主动拉起），但不影响AUTO_START控制 - 必须加
-f（即-force），否则srvctl会因检测到数据库未OPEN而拒绝注册
AUTO_START=always不等于“一开机就OPEN”
设成always只是让CRS在自身启动后尝试srvctl start database，而ADG的启动行为由-s参数和数据库内部状态共同决定：
- 若注册时指定
-s MOUNT，则crsctl start crs后，实例会自动STARTUP MOUNT，不会OPEN - 若误设为
-s OPEN，CRS会强行执行STARTUP，但ADG在未激活前执行OPEN会直接报ORA-16139: media recovery required并失败 - 验证是否生效：
crsctl stat res ora.orcl.db -p | grep AUTO_START应返回AUTO_START=always - 检查实际状态：
srvctl status database -d orcl应在CRS启动后几秒内显示Instance orcl1 is running on node1（MOUNT态）
按需开启的关键：靠srvctl stop/start控制启停节奏
所谓“按需”，不是靠CRS定时器或外部脚本轮询，而是人在主库切换后，手动触发一次srvctl start即可。此时CRS已就位，所有依赖（监听、ASM、网络）都ready，启动延迟极低：
- 主库故障后，先在容灾端执行
srvctl start database -d orcl，实例立刻MOUNT - 再执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT开始日志应用 - 最后
ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE完成切换（如需） - 整个过程无需重启CRS、不依赖
ohasd状态、不碰/etc/oracle/olr.loc等底层配置
真正容易被忽略的是：ADG实例的CRS注册必须在数据库处于MOUNT状态时完成。如果数据库当前是NOMOUNT或CLOSED，srvctl add database会静默失败或注册不全，后续start必然报CRS-2566资源不存在错误。
