Oracle 19c DG备库所谓“LNS崩溃”实为MRP或ARCn因内存不足被静默终止，根本原因是未禁用transparent_hugepage、hugepages配置错误及SGA内存参数不合理，需永久禁用THP、用hugepages_settings.sh计算并设置nr_hugepages、large_pool_size≥512M、禁用AMM。
oracle 19c dg备库的 lns 进程崩溃，十有八九不是网络或归档配置问题，而是内存资源被挤爆后触发的静默退出——lns 本身不报错，但 alter database open read only 后日志里反复出现 ora-04030: out of process memory 或 ora-27102: out of memory，ps -ef | grep lns 查不到进程，crsctl stat res -t 显示 ora.<db_name>.dg</db_name> 资源反复 restart，这才是典型症状。
为什么SGA调小了LNS还是崩？
因为DG备库的 LNS 进程（Log Network Server）在物理备库上其实不启动；它只存在于主库。你看到的“LNS崩溃”，大概率是误判——真正出问题的是备库上的 MRP（Managed Recovery Process）或 ARCn（Archiver），它们在应用归档日志时因内存不足触发 ORA-04030，进而被 Oracle 自动 kill，看起来像“LNS挂了”。
验证方式：tail -100f $ORACLE_BASE/diag/rdbms/<db_unique_name>/<instance_name>/trace/alert_<instance_name>.log</instance_name></instance_name></db_unique_name>，搜 MRP0 或 ARC0 关键字，看是否伴随 pga_aggregate_limit 超限或 shared pool 分配失败。
- 别被
ps输出误导：备库上查不到LNS是正常的，它本就不该存在 -
MRP对 SGA 中的shared pool和large pool敏感，尤其在大量 DML 的归档流中解析重做记录时 -
ARCn在压缩归档或写入 ASM 时会猛吃 PGA，pga_aggregate_limit设得太低会直接 kill 进程
SGA_target 改多少才安全？
不能按主库比例照搬。备库不跑业务 SQL，shared pool 和 buffer cache 可大幅压低。重点不是“总 SGA 多大”，而是保证 large pool 足够支撑 RMAN/归档/ASM 操作，且 shared pool 不低于 512MB（否则 MRP 解析重做字典会频繁硬解析+内存抖动）。
- 先停备库：
SHUTDOWN IMMEDIATE - 进
sqlplus / as sysdba，执行：ALTER SYSTEM SET sga_target = 2G SCOPE=SPFILE;（8GB 内存机器建议值） - 强制预留 large pool：
ALTER SYSTEM SET large_pool_size = 512M SCOPE=SPFILE;（不设则由 Oracle 动态分配，易碎片） - 禁用自动内存管理（AMM）：
ALTER SYSTEM SET memory_target = 0 SCOPE=SPFILE;（AMM 在 DG 备库上反而增加内存争用） - 重启生效：
STARTUP MOUNT→ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
内核参数不调，SGA 再小也白搭
Linux 上若未禁用 transparent_hugepage，或 vm.nr_hugepages 设得过小，Oracle 进程申请内存时 fallback 到普通页，MRP 在高吞吐归档场景下极易触发 TLB miss 飙升、CPU 软中断暴涨，最终表现为进程卡死或被 OOM killer 杀掉——此时 ORA-04030 日志可能根本没写全就断了。
- 永久禁用 THP：
echo 'transparent_hugepage=never' >> /etc/default/grub，然后grub2-mkconfig -o /boot/grub2/grub.cfg并重启 - 确认禁用生效：
cat /sys/kernel/mm/transparent_hugepage/enabled输出必须是[never] - 运行官方脚本算大页：
$ORACLE_HOME/rdbms/install/hugepages_settings.sh，取输出值 +5% 后填入/etc/sysctl.conf的vm.nr_hugepages - 补全三项：
vm.hugetlb_shm_group（设为oinstall组 ID）、kernel.shmall（≥vm.nr_hugepages × 2048）、kernel.shmmax（≥sga_max_size）
最常被跳过的一步：改完 /etc/sysctl.conf 后忘了 sysctl -p，或者没检查 sysctl -p 输出有没有 error: "vm.nr_hugepages" is an unknown key ——这说明内核压根不支持大页，得换 kernel 或确认架构（ARM64 下某些 OL8 镜像默认关了 CONFIG_HUGETLB_PAGE）。
