昨天客户在QQ联系我,说数据库的归档目录满了,业务无法操作,需要马上处理。本来周末准备出去的我就灰溜溜的打开电脑开始处理了。
登上去之后首先查看下归档目录,由于之前登陆过改系统,知道归档目录是放在BACK磁盘组里。
果然归档磁盘组BACK已经满了,日志无法写入,业务肯定受到影响了。
![](https://i-blog.csdnimg.cn/blog_migrate/c3bcecf9504f229531f48696ead6c256.png)
首要任务是需要先恢复业务使用,二话不说直接使用asmcmd进入归档目录里手工删除(从这里可以看到最早的归档为15号),
直接RM掉15号的归档日志,删除后业务恢复正常,再开始分析。
![](https://i-blog.csdnimg.cn/blog_migrate/f96eaaf11f42a260757fe7de81a64fbd.png)
![](https://i-blog.csdnimg.cn/blog_migrate/a0df6d32d6062040053703cd60b8f3c3.png)
再上面删除的时候发现,15号的归档还在。而我之前看过这一套环境,是有部署备份脚本的,一周做一次全备,备份完成之后会清理归档。而我却看到了7天之前的归档,说明可能与备份有关系,
我先查看归档的相关信息,每天的归档量都很平稳,可以排除是突发的暴增引起的故障。可以判定就是因为长期未清理归档所导致的。
![](https://i-blog.csdnimg.cn/blog_migrate/6ae2b7b476db2e1507abaf796ccde27d.png)
那么刚才也说了,备份完之后会清理归档。也就是说可能是备份的环节出现了问题,我们先来看一下备份的一些信息。
![](https://i-blog.csdnimg.cn/blog_migrate/1d22a0c6d0fcdd2fc9354a5d22fcbcc6.png)
查询备份信息发现,从15号开始之后就没有做过备份,这套环境是在crontab里部署备份脚本,备份的策略是1-6做增量,周日做全量的备份。
这里可以说明15号之后备份就出现问题了。
下一步就是去检查备份的日志了,日志里出现了ORA-01017的用户名/密码报错。
![](https://i-blog.csdnimg.cn/blog_migrate/05595666e03d8d2976e6d71be2dbbbd5.png)
由于报错是提示的账号相关的,那么我们直接去查看在备份脚本里关于登陆信息的语句。
![](https://i-blog.csdnimg.cn/blog_migrate/ce9535f304c58fb2a5c0cb010ca28e5a.png)
既然是无效的用户密码,那么我们就测一测。发现第一个连接到CATALOG的RMAN用户的连接没有问题,
但是连接到本地SYS用户,尝试了几次之后才登陆成功,而且只会分配到节点1上。
![](https://i-blog.csdnimg.cn/blog_migrate/da5fe15179554e099984b4a57fe72e4f.png)
之后我单独对2节点建立了一个TNS连接,发现无论测试几次都是失败,而如果修改成节点1之后就没有任何问题。
这里我就向朋友了解了下,说之前遇到过在RAC环境下修改SYS用户的密码,只修改了一个节点的,后续导致连接到节点二的会话全部失败。
等我把2节点与1节点的SYS用户密码同步之后,在手工执行备份脚本进行测试,之后就没有出现过报错了,归档日志也自动清理了。
故障分析:
判断由于之前修改过SYS用户密码,只在一个节点上进行修改,所以导致使用SCAN IP连接时分配实例到2节点上就会产生ORA-01017的密码错误信息。
而使TNS连接执行RMAN备份的脚本无法调用(脚本里包含备份后清理归档),从而导致归档目录爆满,引起故障。
解决:
修改2节点SYS密码与1节点一致,手工调用备份脚本进行测试,备份完成并自动清理过期备份及归档。
建议:
1.
后续如需对SYS用户修改密码时,需要所有节点一并修改。
2.
由于归档时再备份后再进行清理,建议部署自动监控归档目录清理脚本,使归档目录使用率若超过阈值后强制清理旧归档。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29123031/viewspace-2122465/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/29123031/viewspace-2122465/