ITPub博客

一个redhat as4下的oracle 10.2.0.2的库使用的是基于物理dataguard的备份，每天晚上自动使用rman对数据库进行备份，但是今天却发现昨天晚上的备份失败！因为数据要保证能恢复到任何的时间点，所以备份脚本中是先对数据库进行增量备份，然后进行日志的备份。结果发现增量备份成功，但日志却没有被备份。错误提示如下：RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ====================================================

接上篇的ORA-04031错误，知道整个SHARED POOL的组件中，ASM extent pointer array占用很大的内存是显示的一个BUG后，继续分析各个组件占用的内存大小，结果发现KGH: NO ACCESS组件也占用了400多M，这个又是个什么鬼东西呢？还是看看METALINK上怎么说的吧。[@more@]首先找到了下面一篇文章：https://metalink.oracle.com/metalink/plsql/f?p=130:14:4157546628394209832::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,461160.1,1,0,1,helveticaApplies to:Oracle Server - Enterprise Edition

ORACLE 10.2.0.2版本的RAC环境下，因为拿标准的TPC-C进行压力测试，发现后台ALERT日志中报有很多DEADLOCK，或许是TPC-C压力测试软件的问题，也或许是ORACLE的BUG，于是找到BUG相对应的补丁，OPATCH打上去，结果三个节点只有一个节点能起的来了，其他两个节点不能OPEN了，最后把新打的PATCH删掉，错误依旧。[@more@]手工启动会报ORA-03113: end-of-file on communication channel,尝试了一步步的来启动，结果发现是最后库OPEN的时候出现的问题，同时后台ALERT日志中报错：ORA-07445: exception encountered: core dump [kkxsyn()+584] [SIG

CREATION FAILED 问题天天有，没有今天多，RMAN备份的问题没搞定的时候，想着把数据库打开会不会这个错误就没了呢，于是就把dataguard open read only了，结果错误依旧，而且后台日志还有新的错误报出来了：ksvcreate: Process(m000) creation failed，之前已经碰到过因为归档日志把磁盘写满导致MMON进程挂掉，然后awr报表不能自动收集的情况：http://zhang41082.itpub.net/post/7167/369161，这次看来还是这个awr的问题了。[@more@]google了半天，发现很多都是说因为process参数设置太小导致不能创建新的进程，此数据库是一个dataguard，

一个应用，突然出现响应缓慢，查看一下等待时间，发现有很多的数据读取的等待，而且每次执行读取的BLOCK数量明显比之前多，看看SQL的执行计划，发 现跟之前的执行计划不一样，多了一个MERGE JOIN CARTESIAN 的过程，把这些进程杀掉，刷新下SHARED POOL，然后等SQL重新请求进来被解析，执行计划已经正确了，下面来看看这个MERGE JOIN CARTESIAN 是何方神圣[@more@]先来看看SQL：SELECT /*+ USE_NL(store) INDEX(store EI_ATTRSTORE) INDEX(dn EP_DN) FIRST_ROWS */ STORE.ENTRYID, STORE.ATTRNAME, NVL(STORE.ATTRVAL, ' '), NVL(STOR

一台DB今天负载一直很高，而且主要资源是消耗在CPU，其中有几个进程，对CPU资源的使用一直是100％。查看等待情况，基本都是在等待latch free事件。看看SHARED_POOL，还有很多空闲的空间，根据V$SESSION_WAIT的P2参数去V$LATCHNAME中查询，发现是一个simulator lru latch的LATCH，这抓瞎了，没思路了。拿这咚咚去搜索下吧，到METALINK上就发现一个很明显的BUG－－5918642。[@more@]大意思就是说，如果打开了DB_CACHE_ADVICE参数，就可能撞上这个BUG：DescriptionHigh simulator lru latch contention can occur when db_cache_advice isset

这个报错其实跟上一篇的ORA-00600是连在一起的，当时只顾着看600了，等7445再次报出来才发现这也是一个BUG。这个错误的 ML:462440.1，是一个未公开的BUG，BUG ID:4085252。这样的错误也没太多可分析和学习的，转贴下ML的文档玩完吧。[@more@]Applies to:Oracle Server - Enterprise Edition - Version: 10.2.0.3.0This problem can occur on any platform.SymptomsThe following errors are encountered:ORA-07445: exception encountered: core dump [kksIsNLSEqual()+72] [SIGSEGV] [Address not mapped to obj

一个逻辑standby的库，当在主库上创建索引的时候，standby的库就会报一个LOGSTDBY status: ORA-16227: DDL skipped due to missing object错误出来，按照错误的提示，仔细核对了主库和standby库上的表，发现这个表明明存在的，怎么会报missing object的错误呢？？看看dba_logstdby_skip视图，也没有过滤掉这个建索引的语句啊，它怎么就会莫名奇妙的被skip了呢？google了半天，没有结果，看来还是metalink吧，结果找到了答案，一个bug，前几天整天看见大家叫，说10Gbug满天飞，唉，我也碰上了一大堆，不过还好，没有碰上很棘手的！下面来看

在RAC系统的DIAG TRACE文件中发现了标题中的信息，全部的日志信息如下： Switch to short timeout for ipc polling a session (kjzha) is registered session (kjzha) is about to end Registered session (kjzha)[11][4][0][1] is cleaned up Switch to long timeout for ipc polling[@more@]在GOOGLE中找到一遍有头没尾的文章，中间提到说因为ORACLE的心跳之前通信是通过UDP方式实现的，而UDP就是使用IPC方式来实现的，所以应该查看IPC相关的设置，不过是个太监贴。跑到METALINK，找了半天也没有很吻合的，只找到了ML:750773.1

因为清理历史数据需要，所以对一列老的RANGE分区直接做DROP操作，因为这些分区表上还有GLOBAL索引，而业务又不能停，所以DROP的时候使用了UPDATE GLOBAL INDEX参数，使得DROP分区的时候索引不会失效。在处理最大的一个1.7亿的表（每个分区大概有4千万数据）的时候，DROP第一个分区，没问题，清除第二个分区过程中，收到系统监控的报警：Errors in file /u01/app/oracle/admin/billdb/bdump/billdb1_lns1_28689.trc:ORA-00272: error writing archive logThu May 8 22:23:26 2008LGWR: I/O error 272 archiving log 2 to 'dgp'DGP是PHYSIC

系统出现ORA-00600错误，看看了TRACE文件，发现是一个插入的SQL语句导致的，看看这个SQL没有任何异常，而且第一次碰见这样的问题，这种问题基本只有METALINK能够解决，到METALINK上搜索了一把，发现有三个相关的BUG。第一个说：corrupt index creating functional index from existing local index；第二个说：when creating index on table containing a NULL REF column；第三个说：ALTER TABLE MOVE corrupts an IOT (OERI:6302 or silent corruption)。三个都是DDL操作出现的问题，都跟我们的情况不一致，导致问题的这个SQL相关的表不

最近和bug干上了，每过十天半个月总会碰上一两个bug，郁闷。今天碰到的是DELETE或者TRUNCATE表时速度很慢的bug。[@more@]因为需要对一些无用的表空间进行清理，腾出系统空间，表空间大概有100G。首先想到的是把几个10多G的大表先truncate，然后再drop所有的表，最后再删除表空间。可是TRUNCATE一个表慢的要死，干脆cancel了，然后直接drop这个表，这次倒很快，可是想想，表肯定放在了recyclebin中了，一看，果然在那里，那就接着purge recyclebin吧，结果等了半个小时，还不见结果，慢的要死，看着表空间已使用空间一分钟才减少了100M，这

REDHAT LINUX AS4U4上运行的3个节点的ORACLE 10.2.0.2系统，因为前台应用的原因，会导致某些事务一直不提交也不回滚，所以这个事务影响的记录就会出于加锁状态，从而导致后来的事务需要操作相同记录的就会出现一个锁等待事件，为了确定是哪个SESSION BLOCK其他事务，于是根据锁等待时间最长的SESSION的SID去V$SESSION视图中查找BLOCKING_SESSION的值，得到是谁BLOCK了这个SESSION，以便找到问题的根源，然后奇怪的问题发生了，找到的这个BLOCKING_SESSION的值去V$LOCK中查找，却发现这个session根本没有LOCK任何资源，而且，把这个SESSION