仓酷云
标题:
MYSQL教程之Oracle诊断案例-Job义务中断实行
[打印本页]
作者:
若相依
时间:
2015-1-16 22:28
标题:
MYSQL教程之Oracle诊断案例-Job义务中断实行
你不用花费很多时间和金钱来培训现有的职工,或者去花大价钱雇用那些拥有各种证书的开发者。因为MySQL的维护和管理在很大程度上是“傻瓜型”的。oracle|实行
Oracle诊断案例-Job义务中断实行
LastUpdated:Saturday,2004-11-2012:47Eygle
今天接到研发职员呈报,数据库准时义务未一般实行,招致某些操纵失利。
入手下手参与处置该变乱.
体系情况:
SunOSDB5.8Generic_108528-21sun4usparcSUNW,Ultra-4
Oracle9iEnterpriseEditionRelease9.2.0.3.0-Production
1.起首参与反省数据库义务
$sqlplus"/assysdba"SQL*Plus:Release9.2.0.3.0-ProductiononWedNov1720:23:532004Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.Connectedto:Oracle9iEnterpriseEditionRelease9.2.0.3.0-ProductionWiththePartitioning,OLAPandOracleDataMiningoptionsJServerRelease9.2.0.3.0-ProductionSQL>selectjob,last_date,last_sec,next_date,next_sec,broken,failuresfromdba_jobs;JOBLAST_DATELAST_SECNEXT_DATENEXT_SECBFAILURESINTERVAL---------------------------------------------------------------------------------------------------3116-NOV-0401:00:0217-NOV-0401:00:00N0trunc(sysdate+1)+1/242716-NOV-0400:00:0417-NOV-0400:00:00N0TRUNC(SYSDATE)+13516-NOV-0401:00:0217-NOV-0401:00:00N0trunc(sysdate+1)+1/242916-NOV-0400:00:0417-NOV-0400:00:00N0TRUNC(SYSDATE)+13001-NOV-0406:00:0101-DEC-0406:00:00N0trunc(add_months(sysdate,1),MM)+6/246516-NOV-0404:00:0317-NOV-0404:00:00N0trunc(sysdate+1)+4/244616-NOV-0402:14:2717-NOV-0402:14:27N0sysdate+16616-NOV-0403:00:0217-NOV-0418:14:49N0trunc(sysdate+1)+3/248rowsselected.
发明JOB义务是都没有一般实行,最早一个应当在17-NOV-0401:00:00实行。可是没有实行。
2.创建测试JOB
createorreplacePROCEDUREpiningISBEGINNULL;END;/variablejobnonumber;variableinstnonumber;beginselectinstance_numberinto:instnofromv$instance;dbms_job.submit(:jobno,pining;,trunc(sysdate+1/288,MI),trunc(SYSDATE+1/288,MI),TRUE,:instno);end;/
发明一样的,不实行。
可是经由过程dbms_job.run(<job>)实行没有任何成绩。
3.举行恢复实验
嫌疑是CJQ0历程生效,起首设置JOB_QUEUE_PROCESSES为0,Oracle会杀失落CJQ0及响应job历程
SQL>ALTERSYSTEMSETJOB_QUEUE_PROCESSES=0;
等2~3分钟,从头设置
SQL>ALTERSYSTEMSETJOB_QUEUE_PROCESSES=5;
此时PMON会重起CJQ0历程
在警报日记中能够看到以下信息:
ThuNov1811:59:502004ALTERSYSTEMSETjob_queue_processes=0SCOPE=MEMORY;ThuNov1812:01:302004ALTERSYSTEMSETjob_queue_processes=10SCOPE=MEMORY;ThuNov1812:01:302004RestartingdeadbackgroundprocessCJQ0CJQ0startedwithpid=8
可是Job仍旧不实行,并且在再次修正的时分,CJQ0间接逝世失落了。
ThuNov1813:52:052004ALTERSYSTEMSETjob_queue_processes=0SCOPE=MEMORY;ThuNov1814:09:302004ALTERSYSTEMSETjob_queue_processes=10SCOPE=MEMORY;ThuNov1814:10:272004ALTERSYSTEMSETjob_queue_processes=0SCOPE=MEMORY;ThuNov1814:10:422004ALTERSYSTEMSETjob_queue_processes=10SCOPE=MEMORY;ThuNov1814:31:072004ALTERSYSTEMSETjob_queue_processes=0SCOPE=MEMORY;ThuNov1814:40:142004ALTERSYSTEMSETjob_queue_processes=10SCOPE=MEMORY;ThuNov1814:40:282004ALTERSYSTEMSETjob_queue_processes=0SCOPE=MEMORY;ThuNov1814:40:332004ALTERSYSTEMSETjob_queue_processes=1SCOPE=MEMORY;ThuNov1814:40:402004ALTERSYSTEMSETjob_queue_processes=10SCOPE=MEMORY;ThuNov1815:00:422004ALTERSYSTEMSETjob_queue_processes=0SCOPE=MEMORY;ThuNov1815:01:362004ALTERSYSTEMSETjob_queue_processes=15SCOPE=MEMORY;
4.实验重起数据库
这个必需在早晨举行
PMONstartedwithpid=2DBW0startedwithpid=3LGWRstartedwithpid=4CKPTstartedwithpid=5SMONstartedwithpid=6RECOstartedwithpid=7CJQ0startedwithpid=8QMN0startedwithpid=9....
CJQ0一般启动,可是Job仍旧不实行。
5.没举措了...
持续研讨...竟然发明Oralce有如许一个bug
1.Cleardescriptionoftheproblemencountered:
slgcsf()/slgcs()onSolariswillstopincrementingafter
497days2hrs28mins(approx)machineuptime.
2.Pertinentconfigurationinformation
Nospecialconfigurationotherthanlongmachineuptime..
3.Indicationofthefrequencyandpredictabilityoftheproblem
100%butonlyafter497days.
4.Sequenceofeventsleadingtotheproblem
Ifthegethrtime()OScallreturnsavalue>42949672950000000
nanosecondsthenslgcs()staysat0xffffffff.Thiscan
causesomeproblemsinpartsofthecodewhichrelyon
slgcs()tokeepmoving.
eg:Inkkjssrh()does"now=slgcs(&se)"andcomparesthat
toaprevioustimestamp.After497daysuptimeslgcs()
keepsreturning0xffffffffso"now-kkjlsrt"will
alwaysreturn0..
5.Technicalimpactonthecustomer.Includepersistentaftereffects.
InthiscaseDBMSJOBSstoppedrunningafter497daysuptime.
Othersymptomscouldoccurinvariousplacesinthecode.
好么,本来是计时器溢出了,一反省我的主机:
bash-2.03$uptime10:00pmup500day(s),14:57,1user,loadaverage:1.31,1.09,1.08bash-2.03$dateFriNov1922:00:14CST2004
恰好到事发时是497天多一点.ft.
6.布置重起主机体系..
这个成绩够忧郁的,NND,谁曾想Oracle这都成...
Oracle最初宣称:
fixmadeitinto9.2.0.6patchset
在Solaris上的9206还没有公布...晕.
好了,就当是个履历吧,假如有成绩十分难以想象的话,那末勇敢嫌疑Oracle吧,是Bug,大概就是Bug。
7.FAQ
一些伴侣在Pub上问的成绩
Q:关于分歧平台,是不是存在一样的成绩?
A:关于分歧平台,存在一样的成绩
由于Oracle利用了尺度C函数gethrtime
参考:
http://www.eygle.com/unix/Man.Page.Of.gethrtime.htm
利用了该函数的代码城市存在成绩.
在MetalinkNote:3427424.8文档中,Oracle界说的平台影响为:Generic(all/mostplatformsaffected)
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@jumperoracle]$catunsign.c#includeintmain(void){unsignedintnum=0xffffffff;printf("numis%dbitslong
",sizeof(num)*8);printf("num=0x%x
",num);printf("num+1=0x%x
",num+1);return0;}[oracle@jumperoracle]$gcc-ounsign.shunsign.c[oracle@jumperoracle]$./unsign.shnumis32bitslongnum=0xffffffffnum+1=0x0[oracle@jumperoracle]$
本文作者:
eygle,Oracle手艺存眷者,来自中国最年夜的Oracle手艺论坛itpub.
www.eygle.com是作者的团体站点.你可经由过程Guoqiang.Gai@gmail.com来接洽作者.接待手艺切磋交换和链接互换.
原文出处:
http://www.eygle.com/case/Job.Can.Not.Execute.Auto.htm
DBaaS解决方案既可以解决这些问题,又能为客户节约资金。相反作为解决方案提供商,采用DBaaS模式似乎就并不那么有吸引力了,因为与企业内部署软件的解决方案相比,DBaaS意味着更低的利润。
作者:
不帅
时间:
2015-1-18 18:53
我是一个ERP初学者,对于前台运用基本熟悉,但对于后台SQLServer的运用一点也不懂,特想学习下相关资料。至少懂得一些基本的运用。希望各位能给于建议,小弟再谢过!
作者:
分手快乐
时间:
2015-1-22 23:58
大侠们有推荐的书籍和学习方法写下吧。
作者:
蒙在股里
时间:
2015-1-31 14:17
varchar(max)\\\\nvarchar(max)类型的引入大大的提高了编程的效率,可以使用字符串函数对CLOB类型进行操作,这是一个亮点。
作者:
再见西城
时间:
2015-2-6 19:42
学习SQL语言的话如果要学会去做网站就不是很难!但是要做数据库管理的话就有难度了!
作者:
仓酷云
时间:
2015-2-18 11:22
但是随着数据量的增大,这种成本差距会逐渐减小,趋于相等。(500万数量级只相差10%左右)
作者:
小妖女
时间:
2015-3-6 04:55
where子句的作用是在对查询结果进行分组前,将不符合where条件的行去掉,即在分组之前过滤数据,条件中不能包含聚组函数,使用where条件显示特定的行。
作者:
只想知道
时间:
2015-3-12 21:13
这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。
作者:
活着的死人
时间:
2015-3-20 03:25
也可谈一下你是怎么优化存储过程的?
欢迎光临 仓酷云 (http://ckuyun.com/)
Powered by Discuz! X3.2