Oracle11g ORA-12005: 不能安排过去时间的自动刷新

本文分析了ORA-12005错误的原因,该错误与尝试为过去的时间安排自动刷新有关。详细解释了Oracle JOB的工作流程,并提供了解决方案,包括如何检查和调整相关设置。
Tue Aug 29 23:30:04 2017
Errors in file /oracle/app/oracle/diag/rdbms/gg/gg1/trace/gg1_j001_47778152.trc:
ORA-12012: 自动执行作业 1214 出错
ORA-12005: 不能安排过去时间的自动刷新
Errors in file /oracle/app/oracle/diag/rdbms/gg/gg1/trace/gg1_j001_47778152.trc:
ORA-12012: 自动执行作业 1204 出错
ORA-12005: 不能安排过去时间的自动刷新
Tue Aug 29 23:30:04 2017
Errors in file /oracle/app/oracle/diag/rdbms/gg/gg1/trace/gg1_j000_9505648.trc:
ORA-12012: 自动执行作业 1205 出错
ORA-12005: 不能安排过去时间的自动刷新
Errors in file /oracle/app/oracle/diag/rdbms/gg/gg1/trace/gg1_j001_47778152.trc:
ORA-12012: 自动执行作业 1208 出错
ORA-12005: 不能安排过去时间的自动刷新

Errors in file /oracle/app/oracle/diag/rdbms/gg/gg1/trace/gg1_j000_9505648.trc:


官方解释:

Error code: ORA-12005
Description: may not schedule automatic refresh for times in the past
Cause: An attempt was made to schedule an automated materialized view refresh for a time in the past.
Action: Choose a time in the future instead.

分析:INTERVAL的值+JOB开始运行的时间,算出下次执行时间在当前时间之前,所以报错ORA-12005: 不能安排过去时间的自动刷新。要想理解这个得知道JOB内部的工作。

JOB的工作流程:
    1.JOB在运行结束之后才会更新next_date,但是计算的方法是JOB刚开始的时间加上interval设定的间隔。
    2.如果在执行完JOB之后的时间比按照this_date+interval计算出的时间更晚一些,那么next_date就更新为当前时间,也就是几乎会立刻再重新执行JOB。
    3.如果一个job执行failure后,oracle会尝试重新执行,若16次尝试后还是failure,则oracle会将这个job的broken设为true,即停掉这个job。
    当job失败后,系统会在1分钟后重新运行这个JOB,如果还是失败,就在和第1次失败间隔2分钟的时候继续运行这个JOB,如果还是失败,就在和 第2次失败相隔4分钟后运行这个JOB,直到 失败间隔时间≥interval(JOB正常工作的时间设置参数)后,系统检测的时间间隔就为interval.直到第16次失败就会将这个job置为 broken。

    所以原因也许是interval设置的不合理,也许是JOB执行的时间太长。

解决方案是:

select job,
       log_user,
       schema_user,
       what,
       LAST_DATE,
       LAST_SEC,
       THIS_DATE,
       THIS_SEC,
       NEXT_DATE,
       NEXT_SEC,
       INTERVAL
  from dba_jobs
 where job in
       (1214,1204,1205,1208);

如查出来的1214的INTERVALTRUNC(SYSDATE) + 20/24 ,修改一下INTERVAL即可。

exec dbms_job.interval(1214,'TRUNC(SYSDATE+1) + 20/24');

### 解决 ORA-01034 和 ORA-27101 错误的方法 当遇到 `ORA-01034: ORACLE not available` 和 `ORA-27101: shared memory realm does not exist` 的错误时,通常意味着 Oracle 实例未能成功启动或未正常运行。以下是详细的排查和解决步骤: #### 1. 检查 Oracle 监听器和服务状态 确保 Oracle 监听器已启动并正在运行。可以通过命令行工具执行以下操作来启动监听器: ```bash lsnrctl start ``` 这一步骤可以确认监听器是否处于活动状态[^1]。 #### 2. 验证 Oracle SID 设置 确认环境变量中的 Oracle SID 是否正确指向目标数据库实例。如果不确定具体的 SID 名称,可以在安装目录下的配置文件中查找相关信息。 #### 3. 使用 OS 身份验证方式尝试启动数据库 有时即使服务看似已经开启,实际的数据库实例可能并未完全初始化。此时可尝试使用操作系统级别的权限来进行手动启动: ```bash sqlplus / as sysdba startup exit; ``` 上述 SQL*Plus 命令允许管理员绕过常规的身份认证流程直接访问并激活数据库引擎[^3]。 #### 4. 审阅日志文件获取更多信息 对于更深入的问题诊断,建议查阅位于 `$ORACLE_HOME/diag/rdbms/<dbname>/<instance_name>/trace/alert_<instance_name>.log` 下的日志条目。这些记录能够提供关于最近一次失败的具体原因说明[^4]。 #### 5. 排除资源竞争可能性 如果有其他应用程序占用了过多系统资源,则可能导致 Oracle 进程无法获得足够的内存空间完成加载过程。利用 Linux 自带的任务管理指令监控服务器上的活跃进程及其消耗情况可以帮助识别潜在冲突源: ```bash ps -eo user,pid,ppid,%mem,%cpu,comm --sort=-%mem | head ``` 这条命令会列出按内存占用量排序后的前十位程序列表[^5]。 通过遵循以上指南应该能有效处理大多数情况下由 ORA-01034 及其关联编号所引发的技术难题。不过需要注意的是,在实施任何更改之前最好先备份现有设置以防万一;另外针对特定版本特性也可能存在差异化的修复路径,请参照官方文档寻求最权威指导。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值