ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Oracle诊断案例-Job任务停止执行(转)

Oracle诊断案例-Job任务停止执行(转)

原创 Linux操作系统 作者:jcszjswkzhou 时间:2019-07-11 10:09:05 0 删除 编辑
Oracle诊断案例-Job任务停止执行

开始介入处理该事故.
系统环境:
SunOS DB 5.8 Generic_108528-21 sun4u sparc SUNW,Ultra-4
Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production

1.首先介入检查数据库任务



$ sqlplus "/ as sysdba"SQL*Plus: Release 9.2.0.3.0 - Production on Wed Nov 17 20:23:53 2004Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.Connected to:Oracle9i Enterprise Edition Release 9.2.0.3.0 - ProductionWith the Partitioning, OLAP and Oracle Data Mining optionsJServer Release 9.2.0.3.0 - ProductionSQL> select job,last_date,last_sec,next_date,next_sec,broken,failures from dba_jobs; JOB LAST_DATE LAST_SEC NEXT_DATE NEXT_SEC B FAILURES INTERVAL---------- --------- ---------------- --------- ---------------- - ---------- ---------------------------- 31 16-NOV-04 01:00:02 17-NOV-04 01:00:00 N 0 trunc(sysdate+1)+1/24 27 16-NOV-04 00:00:04 17-NOV-04 00:00:00 N 0 TRUNC(SYSDATE) + 1 35 16-NOV-04 01:00:02 17-NOV-04 01:00:00 N 0 trunc(sysdate+1)+1/24 29 16-NOV-04 00:00:04 17-NOV-04 00:00:00 N 0 TRUNC(SYSDATE) + 1 30 01-NOV-04 06:00:01 01-DEC-04 06:00:00 N 0 trunc(add_months(sysdate,1),'MM')+6/24 65 16-NOV-04 04:00:03 17-NOV-04 04:00:00 N 0 trunc(sysdate+1)+4/24 46 16-NOV-04 02:14:27 17-NOV-04 02:14:27 N 0 sysdate+1 66 16-NOV-04 03:00:02 17-NOV-04 18:14:49 N 0 trunc(sysdate+1)+3/248 rows selected.

发现JOB任务是都没有正常执行最早一个应该在17-NOV-04 01:00:00执行但是没有执行

2.建立测试JOB



create or replace PROCEDURE pining ISBEGIN NULL; END;/variable jobno number;variable instno number;begin select instance_number into :instno from v$instance; dbms_job.submit(:jobno, 'pining;', trunc(sysdate+1/288,'MI'), 'trunc(SYSDATE+1/288,''MI'')', TRUE, :instno);end;/

发现同样的不执行
但是通过dbms_job.run()执行没有任何问题

3.进行恢复尝试

怀疑是CJQ0进程失效首先设置JOB_QUEUE_PROCESSES为0Oracle会杀掉CJQ0及相应job进程
SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 0;

等2~3分钟重新设置

SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 5;

此时PMON会重起CJQ0进程

在警报日志中可以看到以下信息:



Thu Nov 18 11:59:50 2004ALTER SYSTEM SET job_queue_processes=0 SCOPE=MEMORY;Thu Nov 18 12:01:30 2004ALTER SYSTEM SET job_queue_processes=10 SCOPE=MEMORY;Thu Nov 18 12:01:30 2004Restarting dead background process CJQ0CJQ0 started with pid=8



但是Job仍然不执行而且在再次修改的时候CJQ0直接死掉了



Thu Nov 18 13:52:05 2004ALTER SYSTEM SET job_queue_processes=0 SCOPE=MEMORY;Thu Nov 18 14:09:30 2004ALTER SYSTEM SET job_queue_processes=10 SCOPE=MEMORY;Thu Nov 18 14:10:27 2004ALTER SYSTEM SET job_queue_processes=0 SCOPE=MEMORY;Thu Nov 18 14:10:42 2004ALTER SYSTEM SET job_queue_processes=10 SCOPE=MEMORY;Thu Nov 18 14:31:07 2004ALTER SYSTEM SET job_queue_processes=0 SCOPE=MEMORY;Thu Nov 18 14:40:14 2004ALTER SYSTEM SET job_queue_processes=10 SCOPE=MEMORY;Thu Nov 18 14:40:28 2004ALTER SYSTEM SET job_queue_processes=0 SCOPE=MEMORY;Thu Nov 18 14:40:33 2004ALTER SYSTEM SET job_queue_processes=1 SCOPE=MEMORY;Thu Nov 18 14:40:40 2004ALTER SYSTEM SET job_queue_processes=10 SCOPE=MEMORY;Thu Nov 18 15:00:42 2004ALTER SYSTEM SET job_queue_processes=0 SCOPE=MEMORY;Thu Nov 18 15:01:36 2004ALTER SYSTEM SET job_queue_processes=15 SCOPE=MEMORY;

4.尝试重起数据库
这个必须在晚上进行



PMON started with pid=2DBW0 started with pid=3LGWR started with pid=4CKPT started with pid=5SMON started with pid=6RECO started with pid=7CJQ0 started with pid=8QMN0 started with pid=9....

CJQ0正常启动但是Job仍然不执行

5.没办法了...

继续研究...居然发现Oralce有这样一个bug

1. Clear description of the problem encountered:
slgcsf() / slgcs() on Solaris will stop incrementing after
497 days 2 hrs 28 mins (approx) machine uptime.


2. Pertinent configuration information
No special configuration other than long machine uptime. .

3. Indication of the frequency and predictability of the problem
100% but only after 497 days.

4. Sequence of events leading to the problem
If the gethrtime() OS call returns a value > 42949672950000000
nanoseconds then slgcs() stays at 0xffffffff. This can
cause some problems in parts of the code which rely on
slgcs() to keep moving.
eg: In kkjssrh() does "now = slgcs(&se)" and compares that
to a previous timestamp. After 497 days uptime slgcs()
keeps returning 0xffffffff so "now - kkjlsrt" will
always return 0. .

5. Technical impact on the customer. Include persistent after effects.
In this case DBMS JOBS stopped running after 497 days uptime.
Other symptoms could occur in various places in the code.

好么原来是计时器溢出了一检查我的主机:

bash-2.03$ uptime 10:00pm up 500 day(s), 14:57, 1 user, load average: 1.31, 1.09, 1.08bash-2.03$ dateFri Nov 19 22:00:14 CST 2004



刚好到事发时是497天多一点.ft.

6.安排重起主机系统..

这个问题够郁闷的NND谁曾想Oracle这都成...

Oracle最后声称:

fix made it into 9.2.0.6 patchset

在Solaris上的9206尚未发布...晕.

好了就当是个经历吧如果有问题非常不可思议的话那么大胆怀疑Oracle吧是Bug可能就是Bug

重起以后问题解决状态如下:

$ sqlplus "/ as sysdba"SQL*Plus: Release 9.2.0.3.0 - Production on Fri Nov 26 09:21:21 2004Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.Connected to:Oracle9i Enterprise Edition Release 9.2.0.3.0 - ProductionWith the Partitioning, OLAP and Oracle Data Mining optionsJServer Release 9.2.0.3.0 - ProductionSQL> select job,last_date,last_sec,next_date,next_sec from user_jobs; JOB LAST_DATE LAST_SEC NEXT_DATE NEXT_SEC---------- --------- ---------------- --------- ---------------- 70 26-NOV-04 09:21:04 26-NOV-04 09:26:00SQL> / JOB LAST_DATE LAST_SEC NEXT_DATE NEXT_SEC---------- --------- ---------------- --------- ---------------- 70 26-NOV-04 09:26:01 26-NOV-04 09:31:00SQL> SQL> select * from v$timer; HSECS---------- 3388153SQL> select * from v$timer; HSECS---------- 3388319SQL>



7.FAQ

一些朋友在Pub上问的问题
Q:对于不同平台是否存在同样的问题?

A:对于不同平台存在同样的问题
因为Oracle使用了标准C函数gethrtime
参考:
http://www.eygle.com/unix/Man.Page.Of.gethrtime.htm

使用了该函数的代码都会存在问题.

在Metalink Note:3427424.8 文档中Oracle定义的平台影响为:Generic (all / most platforms affected)

Q.计数器溢出看了看job 中基本都是1天左右执行一次如果设置 3 天执行一次的 job , 是否出问题的uptime 应该是 497*3 之后呢 ?

A:不会

Oracle内部通过计时器来增进相对时间.
由于Oracle内部hrtime_t使用了32位计数

那么最大值也就是0xffffffff
0xffffffff = 4294967295

slgcs()是10亿分之一秒溢出在42949672950000000这个点上.

注意这里0xffffffff达到这个值时本来是无符号整型现在变成了-1那么这个值递增时+1 = 0了
时间就此停住了

我写了一小段代码来验证这个内容参考:

[oracle@jumper oracle]$ cat unsign.c#include int main(void){unsigned int num = 0xffffffff;printf("num is %d bits long ", sizeof(num) * 8);printf("num = 0x%x ", num);printf("num + 1 = 0x%x ", num + 1);return 0;}[oracle@jumper oracle]$ gcc -o unsign.sh unsign.c[oracle@jumper oracle]$ ./unsign.shnum is 32 bits longnum = 0xffffffffnum + 1 = 0x0[oracle@jumper oracle]$




Q:内部时钟之一应该就是这个吧: v$timer 精确到1/100 秒的数据

没错!

注意前面说的:

4. Sequence of events leading to the problem
If the gethrtime() OS call returns a value > 42949672950000000
nanoseconds then slgcs() stays at 0xffffffff. This can
cause some problems in parts of the code which rely on
slgcs() to keep moving.

也就是说如果gethrtime() 操作系统调用返回值大于42949672950000000(单位10亿分之一秒)

也就是说Oracle将得到一个cs值为4294967295的时间值

而4294967295值就是0xffffffff

所以当时v$timer的计时也就是:

SQL> select * from v$timer; HSECS----------4294967295SQL> / HSECS----------4294967295SQL> / HSECS----------4294967295SQL>

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10294527/viewspace-122293/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2007-08-29

  • 博文量
    3488
  • 访问量
    2621279