一个密码修改引起的故障

昨天客户在QQ联系我，说数据库的归档目录满了，业务无法操作，需要马上处理。本来周末准备出去的我就灰溜溜的打开电脑开始处理了。

---

登上去之后首先查看下归档目录，由于之前登陆过改系统，知道归档目录是放在BACK磁盘组里。
果然归档磁盘组BACK已经满了，日志无法写入，业务肯定受到影响了。

---

首要任务是需要先恢复业务使用，二话不说直接使用asmcmd进入归档目录里手工删除（从这里可以看到最早的归档为15号），
直接RM掉15号的归档日志，删除后业务恢复正常，再开始分析。

---

再上面删除的时候发现，15号的归档还在。而我之前看过这一套环境，是有部署备份脚本的，一周做一次全备，备份完成之后会清理归档。而我却看到了7天之前的归档，说明可能与备份有关系，
我先查看归档的相关信息，每天的归档量都很平稳，可以排除是突发的暴增引起的故障。可以判定就是因为长期未清理归档所导致的。

---

那么刚才也说了，备份完之后会清理归档。也就是说可能是备份的环节出现了问题，我们先来看一下备份的一些信息。

查询备份信息发现，从15号开始之后就没有做过备份，这套环境是在crontab里部署备份脚本，备份的策略是1-6做增量，周日做全量的备份。
这里可以说明15号之后备份就出现问题了。

---

下一步就是去检查备份的日志了，日志里出现了ORA-01017的用户名/密码报错。

由于报错是提示的账号相关的，那么我们直接去查看在备份脚本里关于登陆信息的语句。

---

既然是无效的用户密码，那么我们就测一测。发现第一个连接到CATALOG的RMAN用户的连接没有问题，
但是连接到本地SYS用户，尝试了几次之后才登陆成功，而且只会分配到节点1上。

---

之后我单独对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/