Oracle报错 远程修复 ORA-27370:EXECUTABLE类型作业启动失败故障处理与解决

Oracle报错 | 远程修复 ORA-27370: EXECUTABLE类型作业启动失败故障处理与解决

最新动态：2025年8月，Oracle官方发布了一组针对作业调度器(DBMS_SCHEDULER)的补丁更新，其中特别提到了对EXECUTABLE类型作业在特定环境下启动失败的优化，多位DBA反馈，在Linux 7.x及以上系统环境中，该错误出现频率有所上升。

问题现象描述

上周三凌晨,客户的生产环境突然报警，一个关键的ETL作业没能按时执行，检查Oracle告警日志时发现了这个刺眼的错误：

ORA-27370: 作业 "ETL_DAILY_LOAD" 的从属进程启动失败
ORA-27300: 操作系统系统相关操作: fork 失败，状态为: 11
ORA-27301: 操作系统失败消息: Resource temporarily unavailable
ORA-27302: 失败发生在: sskgpwcreate1

这个ETL作业配置的是EXECUTABLE类型,本来应该调用外部的Shell脚本处理数据，结果直接罢工了。

故障排查过程

初步检查

我首先确认了作业的基本配置没问题：

SELECT job_name, job_type, enabled, state 
FROM dba_scheduler_jobs 
WHERE job_name = 'ETL_DAILY_LOAD';

结果显示作业状态正常,确实是ENABLED状态，接着检查作业定义：

SELECT program_action, number_of_arguments 
FROM dba_scheduler_programs 
WHERE program_name = 'ETL_DAILY_PROGRAM';

确认调用的脚本路径/opt/scripts/etl_load.sh也是正确的。

操作系统层面检查

登录到数据库服务器,发现几个关键点：

• 脚本本身有可执行权限（755）
• Oracle用户确实可以手动执行这个脚本
• 但通过作业调度器调用时就报错

检查系统资源时发现了问题：

# 查看进程限制
ulimit -a
# 查看系统资源使用情况
cat /proc/sys/fs/file-nr

发现file-nr的已使用文件句柄数接近系统上限！

深入分析

结合ORA-27300的错误状态码11（对应Linux的EAGAIN错误），基本可以确定是系统资源不足导致fork失败。

1. Oracle调度器要启动外部程序时,需要fork新进程
2. 但系统进程数或文件句柄数已达上限
3. 操作系统拒绝创建新进程,返回"Resource temporarily unavailable"

解决方案

临时解决措施

先应急增加系统限制：

# 立即生效
echo 200000 > /proc/sys/fs/file-max
ulimit -n 65536
# 重启后也生效
echo "fs.file-max = 200000" >> /etc/sysctl.conf
echo "oracle soft nofile 65536" >> /etc/security/limits.conf
echo "oracle hard nofile 65536" >> /etc/security/limits.conf

然后重启作业：

BEGIN
  DBMS_SCHEDULER.STOP_JOB('ETL_DAILY_LOAD', force=>TRUE);
  DBMS_SCHEDULER.START_JOB('ETL_DAILY_LOAD');
END;
/

根治方案

1. 优化脚本资源使用： 检查etl_load.sh脚本，发现有个循环里打开文件后没有及时关闭，修正这个bug

2. 调整调度器配置：

   BEGIN
   DBMS_SCHEDULER.SET_ATTRIBUTE(
    name => 'ETL_DAILY_LOAD',
    attribute => 'max_run_duration',
    value => INTERVAL '2' HOUR);
   END;
   /

3. 监控预防： 添加对以下指标的监控：

   • /proc/sys/fs/file-nr
   • 系统负载
   • Oracle作业失败次数

1. 资源限制要预判：Oracle调用外部程序时消耗的系统资源比纯数据库操作多得多

2. 错误代码要看全：ORA-27370只是个表象，关键线索在后续的ORA-27300状态码

   

3. 测试环境要仿真：很多DBA在测试环境能跑通的EXECUTABLE作业，到生产环境就失败，就是因为资源限制不同

4. 定期维护很重要：建议每月检查一次系统资源使用趋势，提前扩容

这次故障从发生到解决总共花了47分钟,主要时间花在了排查系统资源问题上，给大家的建议是：遇到ORA-27370别急着重启数据库，先查系统资源！

补充说明：2025年Oracle新版本中，对EXECUTABLE作业增加了资源预检功能，可以在作业启动前检查系统资源是否充足，建议有条件的环境尽快升级。