记一次Oracle定时器调用存储过程的坑

本文详细记录了一次在预发布环境中,Oracle定时器未按预期执行存储过程的问题排查过程。从检查定时器状态、job_queue_processes参数到发现可能的Oracle 497天bug,最终发现问题是由于时区设置导致的。解决方案是重新配置定时器,确保其启动时间在正确的时区下。此案例强调了排查问题时对细节的关注和理解Oracle时区问题的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

背景

Oracle用scheduler写了一个定时器调用存储过程,每个月创建一次表。结果到定时器的执行时间了表却没有创建(预发布环境)。
本地环境正常,模拟环境正常,开发环境正常,测试环境正常
预发布环境异常没创建表
(此时心中:万马奔腾,不得不提一句,docker真香)

排查问题

刚发现这个问题的时候,一脸懵逼。特么本地环境,模拟环境,开发环境,测试环境都ok了,咋个预发布环境就出问题了??
在这里插入图片描述
带着一脸懵逼,还是默默打开了oracle,查看了下定时器

select job_name,start_date,next_run_date,repeat_interval from user_scheduler_jobs;

一打开(由于预发布环境没有权限动,现在查不了异常环境的图。下图是正常情况的,这里展示一下字段。异常信息由下面写出。):

查询后第一映入眼帘的是,我设置定时器每个月28号 09:15:05执行一次。咋到点了还没有表创建,NEXT_RUN_DATE字段下一次执行时间也没有更新

异常信息:

JOB_NAME:CREATE_TABLE_BY_MONTH

START_DATE:2020-09-27 18:13:05.046910 PST8PDT

NEXT_RUN_DATE:2020-09-28 09:15:05.000000 PST8PDT

REPEAT_INTERVAL:FREQ=MONTHLY; INTERVAL=1; BYMONTHDAY=28; BYHOUR=9; BYMINUTE=15
在这里插入图片描述

之后一顿百度操作猛如虎,查看各路大佬是否遇到这类问题

在这里插入图片描述
总结可能导致的原因如下:

  • oracle定时器job长时间执行无法结束。意思就是执行的时候,出于某种原因,数据库崩了之类的。job卡死。
  • 查询job_queue_processes参数
  • 系统uptime超过497天100%bug

尝试定位问题方式一:oracle定时器job长时间执行无法结束

参考学习博文:oracle定时器job长时间执行无法结束
之后一顿操作:

-- 描述正在运行的Job的相关信息
select * from dba_scheduler_running_jobs;

-- 描述已经完成的Job是否成功,记录相关日志的视图,这里记录着所有已经执行完毕的日程
select * from  user_scheduler_job_run_details;

select * from user_scheduler_job_log ;

-- 描述当前数据库所有已知的日程。
select
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值