MRP0启动失败但无报错，先查alert.log中ORA-04030或ORA-27102；主因是内存不足致静默终止，需检查large_pool_size未显式设置、transparent_hugepage未禁用及pga_aggregate_limit过低。
MRP0启动失败但没报错，先查alert日志里有没有ORA-04030或ORA-27102
备库上mrp0进程起不来，往往不是配置写错了，而是oracle在startup mount后尝试启动mrp时因内存分配失败被静默kill。最直接证据就是alert_<instance_name>.log</instance_name>里反复出现ora-04030: out of process memory或ora-27102: out of memory，且ps -ef | grep mrp查不到进程。别急着改standby_file_management或重传归档——先确认是不是内存卡死。
SGA_target设太小？重点不是总量，而是large_pool_size必须显式设够
SGA_target调低反而让MRP0更易崩，因为Oracle动态分配时会把large pool压到极小值（甚至0），而MRP解析重做记录、处理ASM元数据、做RMAN备份恢复都强依赖large pool。实操中必须显式设置：
-
ALTER SYSTEM SET large_pool_size = 512M SCOPE=SPFILE;（8GB内存机器最低要求） -
ALTER SYSTEM SET shared_pool_size = 512M SCOPE=SPFILE;（避免重做字典硬解析抖动） -
ALTER SYSTEM SET sga_target = 2G SCOPE=SPFILE;（不建议低于1.5G，否则shared pool和large pool争资源） -
ALTER SYSTEM SET memory_target = 0 SCOPE=SPFILE;（禁用AMM，DG备库上它只会加剧内存碎片）
Linux内核参数没关THP，MRP0可能被OOM Killer干掉
即使Oracle参数调对了，transparent_hugepage开启状态下，MRP0这类短时高内存申请的进程极易被Linux OOM Killer误杀——系统日志/var/log/messages里会出现Out of memory: Kill process <pid> (oracle)</pid>。这不是Oracle报错，所以alert日志里找不到线索。
永久禁用方法：
- 执行
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 在
/etc/rc.local里加这行，或写进/etc/default/grub的GRUB_CMDLINE_LINUX参数中（加transparent_hugepage=never） - 运行
hugepages_settings.sh脚本计算nr_hugepages值，并写入/etc/sysctl.conf（如vm.nr_hugepages = 1200）
PGA吃爆了也会连带搞垮MRP0，尤其ARCn在压缩归档时
MRP0本身不大量用PGA，但ARCn进程在写归档（尤其启用LOG_ARCHIVE_DEST_n压缩或写入ASM时）会猛吃PGA。如果pga_aggregate_limit设得太低，ARCn被kill后归档中断，MRP0因收不到新归档而卡在WAIT_FOR_GAP状态，看起来像“启动不了”。
检查和调整：
- 查
V$PGASTAT里的total PGA allocated和aggregate PGA auto target是否接近pga_aggregate_limit - 临时放宽限制：
ALTER SYSTEM SET pga_aggregate_limit = 4G SCOPE=SPFILE;（16GB物理内存机器建议值） - 确认
archive_lag_target没设过小（如60秒），否则ARCn压力剧增
真正卡住MRP0的，往往不是单点参数，而是large_pool_size未显式设置 + transparent_hugepage开着 + pga_aggregate_limit偏低这三者叠加。改完任何一个，都得重启实例才生效，不能只ALTER SYSTEM就以为完事。
