一次特别的library cache pin的解决过程
20101231 EDW 故障分析报告,今天异常的出现了大量library cache pin的等待,以下是分析及解决过程:[@more@]一、故障描述l 2010年12月31日早晨上班后接到运维组同事反馈,EMC全部程序都被HANG住,没有继续执行,也没有报错。l 紧接着,项目组尤欣星反应,无法DROP空表,王健反应无法查询表,没有任何明显报错,只是表象一直是执行,一个原本很简单的秒级查询已经运行半个小时。询问西南所有项目组同事,发现所有人都遇到了同样HANG死的问题,是一个大面积的事故。二、故障分析n 根据事件的表象,询问车廷曦近期数据库有何调整,据车廷
两个超大表做关联更新的优化
今天同事给了两个SQL,超级大,一个表8000多万,一个表7800万,原语句如下:[@more@]update CHANNEL_CHENGDU.o_user_CONS partition(p201011) A SET unuser_flag = (SELECT unuser_flag FROM CHANNEL_CHENGDU.o_user partition(p201011) B WHERE A.SERV_ID = B.SERV_ID) where EXISTS (SELECT 1 FROM CHANNEL_CHENGDU.o_user partition(p201011) B WHERE A.SERV_ID = B.SERV_ID);update CHANNEL_CHENGDU.o_user_CONS partition(p201011) A SET BILL_USER_FLAG = (SEL
ORA-12838的问题
今天写了一段PL/SQL代码,极其简单,却让我愣了一下[@more@]begin for i in 1 .. 24 loop insert /*+ APPDEND*/ into ttt_2 select t_seq_2.nextval, a.* from dba_objects a; end loop; commit;end;看似没什么错,对不?其实不是的,当你运行上面的逻辑时,就会出现ORA-12838的错误,原因是加了APPEND以后必须立刻提交,才可以对表进行第二次操作,操作包括SELECT和DML。在循环中,一次循环就是一次DML,24次循环实际上是要做24个DML操作,那么,COMMIT换一下位置就好了。begin for i in 1 .. 24 loop insert /*+ APPD