Xdb的重装问题 ,ORA-04098, ORA-00257 archiver error.， library cache lock

Oracle version：Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Prod
OS version:：Microsoft Windows Server2003 sp2

1、 这是一个用Oracle导出xml文档的问题，从周三持续到今天周日才fix，而且是这个周末都过来加班。
2、 本来在fftest上测试没有问题。Xdb是在数据库安装时默认装上的。
doc := dbms_xmldom.newDOMDocument;
3、 但是一直到ffdw上，出现问题，但是也可能是没有看清，没有用脚本查询是否xdb正常
select * from dba_registry;
结果仓促执行了catqm.sql，出问题了。
4、 执行catqm.sql过程中就发现报了很多错。后来第二天早晨又发现每天7点执行的job24出了问题，报错：
ORA-04098: 触发器 'XDB.XDB_PI_TRIG' 无效且未通过重新验证
是一个trigger出了问题。
但是不够冷静，没有细看系统自带脚本的具体内容（其实比较简单）。直接在fftest上做了测试，执行了catproc.sql的脚本，结果导致fftest连test 过程都报错。
都有重新装db的打算。
5、 因为第二天要测试分货系统，正好那几天老大出差，无奈，在晚上火速重装了自己机器上的fftest，还算顺利，而且赶上了21点的末班车回家。
6、 第二天上班，发现fftest可以用了，勉强完成了分货表的测试。那几天job都有问题，但是好像sale数据还对的上，只是links的出了问题，因为trigger出问题了，一执行Drop和Truncate就报错，导致links的job里的prc报错。每天发给店铺的邮件库存balance也不为0了。为了保证BI报表查询的正常使用，准备周末解决。
7、 昨天周六，执行catqm和catnoqm.sql不能顺利执行，尤其是drop user xdb cascade；时会hang住；弄了一下午未解，就把hang住的放在那里了，看看第二天来会不会跑过去；
8、 今天早晨过来，发现仍旧hang着，而且job也出了问题。导致dim_customer表锁了，而且大量的执行，导致achivelog爆满，用ffdw登陆时报错
ORA-00257 archiver error. Connect internal only, until freed
还好，用sys可以登录。
查询得知是，archive log的dest目录慢了，一查询果然慢了，
select * from v$recovery_file_dest;
select * from v$flash_recovery_area_usage;
select * from v$log;
只能采取不断加大的方法，可是后来发现加到13g仍旧也灌满的危险。
SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=13g;

9、 问题出在job上，不断地自动执行，杀不掉。采用
SQL> ALTER SYSTEM KILL SESSION '111, 473';
也不行，一会就又起来，锁表。
查询锁表：

select *
from v$locked_object vl, dba_objects do
where do.object_id = vl.OBJECT_ID;

10、 中午吃晚饭回来干脆把job broken了，这下子好了，起码archivelog不增加了，ffdw用户能正常用了。

SQL> EXEC
DBMS_JOB.BROKEN(24, TRUE);
PL/SQL procedure successfully completed
SQL> commit;
Commit complete
----------------

--标记job的broken
SQL>EXEC DBMS_JOB.BROKEN(JOB#, TRUE);
SQL>COMMIT;
--杀掉session
>ALTER SYSTEM KILL SESSION 'SID, SERIAL#';
--KILL THE OS SESSION
在DOS下，orakill sid spid
(sid和spid从v$process中获得，p.addr=s.paddr)

-----------------

11、 中间一度想把archive log改成非归档。但是后来没动，保险起见，毕竟归档还是有可能恢复的。
12、 还发现了个问题就是，plsql dev不能执行archive log list;必须要到dos用sqlplus。
13、 后来看catnoqm.sql的脚本，单步拿出来一个一个执行，仍旧挂在drop xdb上，上网找到了根源，是library cache lock的问题，这是问题的关键所在。按照方法杀掉了相应的session。成功drop掉xdb用户。
14、 后面比较顺利，catnoqm.sql成功执行，按照Oracle的官方文档，又执行了catqm.sql安装xdb。
15、 检查status是否为valid，有6个仍旧为invalid，手动alter trigger xxx compile；就OK了。
16、 总结：：：：
17、 遇事不能慌、沉着要相信凭自己能力可以解决，虽然过程有可能是痛苦的煎熬与无助、多总结，很多问题可以依据自己以前的积累找到突破口。不要轻易有重装db的想法，在db又冷备的情况下，大胆有理的执行脚本。

2011-3-20 18:00

关键部分在于解决library cache lock的问题，参考：
http://itspace.javaeye.com/blog/963124