青岛日常巡检中的发现

最近一直在青岛某地做日常巡检工作常驻工程师，结果昨天数据库出现了问题。一般情况下早上八点半左右第一个到工作地点然后开始简单的看一下告警日志，没有发现问题就先吃点东西，然后开始巡检。巡检结束以后发现巡检结果完全正常，所以按照以往情况就锁上巡检的电脑忙其他的了。过了半个小时客户打来电话，发现人口库和资源库备份出现问题，一直没法完成备份，然后立马开始进行排查。反复的巡检后发现数据库正常，各种状态包括目录空间剩余表空间等也没有发现问题，资源库备份通过命令检查发现与以往的巡检状态相同，人口库发现备份截止到2月8号。资源库是一套rac，aix的10g，人口库是个单机9i的。查看告警日志，资源库完全正常，但是发现9i的人口库告警日志出现异常，具体是：
Created undo segment_syssmu23$
undo segment 21 onlined
mon feb 9 10:25:44 2015
Created undo segment_syssmu24$
undo segment 22 onlined
mon feb 9 10:44:07 2015                             
undo segment 23 onlined
mon feb 9 14:06:12 2015
同时，
smon offlining us=21
smon offlining us=22
smon offlining us=23
smon offlining us=24
结合客户反映的备份失败，发现可能与此相关，于是上网搜索相关答案（以前没接触过，新手)。通过上网搜的答案，发现以上告警日志信息是SMON进程把回滚段 14 给 offline 了。也就是ORACLE系统自行管理回滚表空间的体现。

 9i的库，没有v$RMAN_BACKUP_JOB_DETAILS，就立马询问公司类总相关问题，结果人口库的备份用的是commvault备份软件，所以立马给客户反馈，希望备份软件提供商前来看一下备份。昨天下午反映给客户后上网继续搜查相关资料，帖子里回复的有的说重启就应该回复，但是这里的数据库一般不让停。今天早上八点20到的，来的比较早，想看一下人口库到底有没有回复，发现告警日志依然告警，立马给客户反映请赶紧让备份软件提供商过来，今早报错：
ORA-000060:Deadlock detected.More info in file /oracle/admin/renko/udump/renko1_ora_26898.trc.
一共报了两次，一次是08:23，一次是09:19，上网搜索显示产生这个报错的情况有以下几中：
1.       两个Session形成循环的等待，这时Oracle会牺牲一方的事务来解行锁，同时一方报ora-000060错误。
2.       外键上没有索引，在操作主表时，可能引起死锁。报ora-000060。
3.       itl竞争引起死锁。报ora-0000060
4.       oracle bug。

然后根据以上可能进行排查，结果发现没有问题，进入到trc查看，同样没问题。向客户反应之后备份软件那边正在赶来，但是这时候

发现备份情况暂时恢复，随后又是
Created undo segment_syssmu23$
undo segment 21 onlined
mon feb 9 10:25:44 2015
Created undo segment_syssmu24$
undo segment 22 onlined
mon feb 9 10:44:07 2015                             
undo segment 23 onlined
mon feb 9 14:06:12 2015这种类似的情况报错。

9i的oracle查看备份情况：
rman target/

RMAN>list backup of database;
RMAN>list backup of archivelog all;

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

转载于:http://blog.itpub.net/30134661/viewspace-1432156/