2 12, 2009
ORA-07445: exception encountered: core dump [kksIsNLSEqual()+72] [SIGSEGV] [Address not mapped to object] [0x00000003C] [] []
这个报错其实跟上一篇的ORA-00600是连在一起的，当时只顾着看600了，等7445再次报出来才发现这也是一个BUG。这个错误的 ML:462440.1，是一个未公开的BUG，BUG ID:4085252。这样的错误也没太多可分析和学习的，转贴下ML的文档玩完吧。 查看全文
1 12, 2009
ORA-00600: internal error code, arguments: [729], [2101416], [space leak]
一个数据库最近每天会报一个600的错，查了下ML，说这个错是因为申请UGA的时候内存不够造成的，需要申请的内存的大小就是第二个参数那里的值，那么
这里就应该是因为要申请2101416，将近2M内存的时候报的错。而这个报错不会引起数据的问题，只是在进程结束的时候产生的进程失败，所以其实是没什
么影响的。如果申请的是4000字节以下的，可以通过设置10262参数来避免这个问题，显然这个CASE不能通过这个来实现。而且跟这个错误相关的
BUG一大堆，查下来发现是跟我们每天晚上有一个EXP的逻辑备份有关。既然没啥关系，过滤掉就是了。
详细信息请查看ML：31056.1
查看全文9 10, 2009
Switch to short timeout for ipc polling
在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 查看全文
23 06, 2009
要命的MERGE JOIN CARTESIAN
一个应用，突然出现响应缓慢，查看一下等待时间，发现有很多的数据读取的等待，而且每次执行读取的BLOCK数量明显比之前多，看看SQL的执行计划，发 现跟之前的执行计划不一样，多了一个MERGE JOIN CARTESIAN 的过程，把这些进程杀掉，刷新下SHARED POOL，然后等SQL重新请求进来被解析，执行计划已经正确了，下面来看看这个MERGE JOIN CARTESIAN 是何方神圣 查看全文
8 05, 2009
PLS-00123:程序太大，是否是ORACLE潜伏多年的小BUG呢？
一哥们给我提了个问题，说一个PACKAGE，通过PL/SQL DEVELOPER进行编写和调试的，大概超过5000行左右，编译的时候会报错，报错的信息是“PLS-00123:程序太大”，才5000行就太大，ORACLE不至于这么弱吧？首先想到的就是PL/SQL DEVELOPER上有什么限制，把菜单栏=》TOOLS=>PERFERENCES中所有选项挖地三尺，没地方限制啊。GOOGLE了一下，解决的办法很简单：在TOOLS=>PERFERENCES=>ORACLE=>DEBUGGER=>ADD DEBUG INFORMAION WHEN COMPILING，在这个地方把这个勾取消，然后就可以编译通过了。那么下面来仔细看看这个东东是干啥的呢？
查看全文2 03, 2009
ORA-00600: internal error code, arguments: [ktspgetmyb-1]，ORACLE的超级连环大BUG
12 02, 2009
一个特殊的ORA-00600: internal error code, arguments: [6302], [20], [], [], [], [], [], []
16 01, 2009
碰到一个latch free相关的BUG
一台DB今天负载一直很高，而且主要资源是消耗在CPU，其中有几个进程，对CPU资源的使用一直是100％。查看等待情况，基本都是在等待latch free事件。看看SHARED_POOL，还有很多空闲的空间，根据V$SESSION_WAIT的P2参数去V$LATCHNAME中查询，发现是一个simulator lru latch的LATCH，这抓瞎了，没思路了。拿这咚咚去搜索下吧，到METALINK上就发现一个很明显的BUG－－5918642。
查看全文29 12, 2008
BUG:ORA-00600: internal error code, arguments: [kmgs_pre_process_request_6], [6], [2873], [2560], [3], [0xC58BE88E0], [], []
又碰见一个BUG，为什么要说又呢？因为BUG实在是太多了，做DBA感觉就像在伊拉克穿行，到处都是暗枪、流弹、地雷、陷坑......起因是看见一个RAC库的其中一个节点的DB_CACHE_SIZE有点小，怎么办呢?改大点呗，这个参数支持动态修改的，所以就不准备重启DB了，直接改了就OK了。于是一个ALTER SYSTEM命令下去，告诉我ORA-03113: end-of-file on communication channel，感觉坏了，于是退出来再SQLPLUS进去，发现INSTANCE已经是IDLE的了，完完了，PS -EF|GREP ORA一看，只剩下ASM的进程还在，ORACLE的进程都没了，查看ALERT文件，发现ORA-00600: internal error code, arguments: [kmgs_pre_process_request_6], [6], [2873], [2560], [3], [0xC58BE88E0], [], []，看来是够背的了，于是先把库起来，还好，顺利起来了，到METALINK查查看，具体解释如下
查看全文10 12, 2008
打补丁打出新的BUG来了
ORACLE 10.2.0.2版本的RAC环境下，因为拿标准的TPC-C进行压力测试，发现后台ALERT日志中报有很多DEADLOCK，或许是TPC-C压力测试软件的问题，也或许是ORACLE的BUG，于是找到BUG相对应的补丁，OPATCH打上去，结果三个节点只有一个节点能起的来了，其他两个节点不能OPEN了，最后把新打的PATCH删掉，错误依旧。
查看全文9 09, 2008
逻辑STANDBY上的ORA-00600: internal error code, arguments: [krvtadc], [], [], [], [], []
下午收到报警，说逻辑STANDBY有很大数据同步延迟，于是登陆上来，首先检查ALERT文件，发现了标题所示的ORA-00600错误。首先尝试重启一下数据库试试吧，重启后，开启APPLY进程，结果同步到相同的地方，相同的600错误重新报出来了，看来重启是过不去了。只好去翻翻METALINK了，结果翻到了有一个相似的BUG，说是操作压缩表的时候，日志同步到逻辑STANDBY库或者STREAM进行日志挖掘的时候，有可能报这个错误，可是ORACLE说的版本跟我这里不一致，他那里提到的是10.2.0.3，而我的是10.2.0.2的版本的。询问下同事，确实在生产上对压缩表做了些操作，看来基本就是这个BUG了，于是找到一个4061534的PATCH，里面有10.2.0.2版本的64位LINUX的PATCH，看来我这个版本确实也存在这样的问题，不然怎么会有对应版本的PTACH呢。下下来，看看PATCH中的README，然后把库宕下来，打补丁，然后起来，就这样问题就过去了。
这个案例不值得一写，也没有多少值得学习的地方，只不过是因为这个是自己第一次打PATCH，记录一下
31 05, 2008
碰见一个BLOCKING_SESSION显示不正确的BUG
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杀掉之后，原先被BLOCK的SESSION还是处于BLOCK的状态，看来是杀错SESSION了。
感觉不可思议，ORACLE BUG碰见的多，碰见这种鬼问题首先想到的就是METALINK了，查了下，果然是个BUG，看看上面是怎么说的吧。
查看全文26 05, 2008
SHARED POOL中KGH: NOACCESS占用大量内存的问题分析
接上篇的ORA-04031错误，知道整个SHARED POOL的组件中，ASM extent pointer array占用很大的内存是显示的一个BUG后，继续分析各个组件占用的内存大小，结果发现KGH: NO ACCESS组件也占用了400多M，这个又是个什么鬼东西呢？还是看看METALINK上怎么说的吧。
查看全文25 05, 2008
shared pool中的ASM extent pointer array组件大小显示异常的BUG
数据库报告0RA-04031错误，这个是个很常见的错误了，十之八九是因为SHARED POOL不够大了，导致新的对SHARED POOL的申请需求失败而报错。于是登陆数据库查看V$SGA_STAT视图，看看整个shared pool分配中，各个组件占用多少内存，是否是真的shared pool不够了，还是某些组件发生异常导致。结果发现一个很奇怪的现象，整个shared pool设置为600M,但是ASM extent pointer array组件占用的内存却已经有1500M了，见鬼，这个是个啥东西，居然占用1500M的空间啊？？
查看全文14 05, 2008
在逻辑STANDBY上使用EXPDP进行数据导出备份的问题，ORA-39004，ORA-39091，ORA-16103
因为在逻辑STANDBY上建了另外的SCHEMA来做报表，而且报表库很小，所以打算每天使用EXPDP把报表库备份一下，可是使用EXPDP进行备份的时候，却出现错误提示：
ORA-39004: invalid state
ORA-39091: unable to determine logical standby and streams status
ORA-16103: Logical Standby apply must be stopped to allow this operation
提示很清楚，执行这个操作的时候，必须停止STANDBY APPLY，于是把APPLY停，见鬼的是居然还是不行，这咋回事呢？
13 05, 2008
遭遇ORA-00600: internal error code, arguments: [kcrrrfswda.11], [4], [368], [], [], [], [], []
Errors in file /u01/app/oracle/admin/billdb/bdump/billdb1_lns1_28689.trc:
ORA-00272: error writing archive log
Thu May 8 22:23:26 2008
LGWR: I/O error 272 archiving log 2 to 'dgp'
DGP是PHYSICAL DATAGUARD，看来是往物理DATAGUARD上写日志的时候出现问题，于是登陆物理DATAGUARD机器检查，却发现DATAGUARD机器出现如标题所示的600错误，查看TRACE文件，一堆二进制的天书。咋办呢？ 查看全文
18 04, 2008
为分区表添加分区后，通过view的查询报ORA-00600: internal error code, arguments: [kksfbc-reparse-infinite-loop]
接近中午的时候，收到数据库报警，alert日志中出现了ORA-00600错误，于是登陆数据库检查，还没看明白呢，有人过来报告，前台某些查询功能不能使用了。查看trace文件，发现里面有导致这个错误的sql，而且就是查询的sql。这东西基本没治，只有开始metalink了。结果查到跟这个错误相关的问题N多，而且基本每个版本都有，都是跟分区表修改分区相关的，看来oracle的分区虽然很强悍，问题也是不少啊。后来了解到是有同事在为某些表增加分区，问题基本明确了。下面来看几个疑似的bug的介绍
查看全文12 03, 2008
LOGSTDBY status: ORA-16227: DDL skipped due to missing object
29 02, 2008
物理DATAGUARD库上的KSVCREATE: PROCESS(M000)
29 02, 2008
rman备份的时候读取v$session_longops失败导致备份失败
一个redhat as4下的oracle 10.2.0.2的库使用的是基于物理dataguard的备份，每天晚上自动使用rman对数据库进行备份，但是今天却发现昨天晚上的备份失败！因为数据要保证能恢复到任何的时间点，所以备份脚本中是先对数据库进行增量备份，然后进行日志的备份。结果发现增量备份成功，但日志却没有被备份。错误提示如下：
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00601: fatal error in recovery manager
RMAN-03004: fatal error during execution of command
RMAN-10006: error running SQL statement: select sofar, context, start_time from v$session_longops where (start_time > nvl(:1,
sysdate-100) or start_time = nvl(:2, sysdate+100)) and sid = :3 and serial# = :4 and opname
like 'RMAN:%' order by start_time desc, context desc
RMAN-10002: ORACLE error: ORA-00000: normal, successful completion