ORACLE 11G RAC重建EM问题

hb_sz

　　前段时间出现了一个问题，就是重启一个RAC节点时突然报恢复区大小不足的问题，查了一下应该没有问题，已经修改为500G了，应该还有200多G的剩余空间的，怎么一下就没了，而且删除了里面不少文件，并且用RMAN里的crosscheck同步了控制文件，还是不行。后来检查了一下，发现是该节点重启后忘记了原来修改的参数了，直接变成了初始参数，怪不得一直报空间不够，初始参数才那么一点！
　　重新设置参数后，该节点起来了，但问题也来了！EM进不去了，查看EM状态后，决定重启下EM，EMCTL STOP DBCONSOLE 没问题，但EMCTL START DBCONSOLE就有问题了，一直是failed.
　　查看EM日志也没有看出什么问题，决定重建EM。
　　使用命令：emca -deconfig dbcontrol db -repos drop -cluster 来删除EM，陆续输入了数据库名，服务名，端口号，集群名，SYS密码，SYSMAN密码等信息后，DBCONTROL删除了，但是删除资料库时挂在那里不动了，等了大半天也没有动静只好停掉。
　　这时尴尬了，我也不知道EM算不算删除了，但是重建地时候，提示说资料库已经存在，应该是没删除，至少是没删除干净。
　　在网上查了一个删除资料库的命令，要在RAC的两个节点上分别执行，/sysman/admin/emdrep/bin/RepManager    -action drop，结果两个节点都继续挂在那里不动了！
　　后来查了一下，决定既然是没删干净，那就删的彻底点。
　　首先检查目录是否还有残余相关目录，到/oc4j/j2ee/目录下查看是否还有OC4J_DBConsole__文件，结果在节点一没有残余，但是在节点2确含有sid为节点1sid的问题，凶残的删掉（移走）！
　　再次删除emca -deconfig dbcontrol db -repos drop，这回不挂住了，但是仍然报错，看起来像是监听没有启动起来，而且感觉输入的密码也有问题，而且也重建不了，仍然报资料库已存在的错误。查看监听没有任何问题，果然还是EM本身有问题。
　　再次查找资料，看到一段话：“重新配置DBCONSOLE，需要输入DBSNMP密码，但任何密码都会显示错误，需要预先修改!",感觉像是造成一切问题的源头！

　　每次重建时都事先改一下DBSNMP的密码：sql>alter user dbsnmp>　　然后手工删除数据库里创建EM的一些对象：
　　SQL> DROP public synonym SETEMVIEWUSERCONTEXT;
　　同义词已删除。
　　SQL> DROP PUBLIC SYNONYM MGMT_TARGET_BLACKOUTS;
　　同义词已删除。
　　SQL> drop role MGMT_USER;
　　角色已删除。
　　SQL> DROP USER SYSMAN CASCADE;
　　用户已删除。
　　SQL> DROP USER MGMT_VIEW CASCADE;
　　用户已删除。
　　删除SYSMAN时还有些问题，删除时报错，说不能删除当前已连接用户，使用V$session视图查了一下，发现还真有三个sysman的连接，可能是重建时连上的，为防止意外，先把sysman用户锁上，在杀掉三个进程，过一会就可以删除！
　　这回应该删除感觉了，使用命令emca -config dbcontrol db -repos create -cluster重建EM吧，但结果是凶残的，居然说我的语句有问题，使用-help查了一遍，没感觉有什么问题啊。难道还有什么问题吗？
　　这时使用DBCA打开配置数据库产品时，原来EM的选项变为可选了，那就没问题，既然命令行说我有错误，我用图形界面总行了吧，一路填过去，静等结构！
　　但结果再次告诉了我不要想的太想当然，在创建资料库末期，弹出了错误 job_queue_processes产生应该大于等于1，这是怎么回事，查看参数，发现该参数居然为0. 修改该产生:alteer system set job_queue_processes=5 scope=both sid='*';
　　修改完后，为安全起见又重新使用命令删除了一遍：emca -deconfig dbcontrol db -repos drop -cluster。
　　这次删除的很快，再次使用DBCA选择创建EM，大概半个多小时后，EM正确创建成功。
　　进入EM界面后，发现上次通过EM创建的备份作业在这几天都没有执行，而且作业也没有了，果然需要重新配置！