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