UNION ALL导致的ORA-07445错误

前几天写到在客户现场处理了一个ORA-07445的oracle bug，当时采取的办法是修改隐含参数"_optimizer_cost_based_transformation"=off。

当时修改的时候由于没有仔细查阅这个参数的用途，只是凭着字面意思猜测感觉和执行、优化相关，当时还说怕怕的，怕又什么影响。

结果，非常杯具的事情在第2天发生了，一个日常的在凌晨执行的数据加工存储过程，平时只要15分钟，当时在周六早上一直到6、7点都没完成，就导致数据加工的ETL完成通知短信没有发出。客户在10点多给我电话的时候，已经把ETL停止掉，单独执行这个过程，结果还是无法完成（超过半个小时）。11点多赶到现场，初步看了下情况和日志，统计分析相关表的信息，大表，需要很长时间，吃完午饭回来，统计分析工作完成，开始重新执行过程，还是超过了20分钟无法完成。

看来和这个参数是有关系的啦，无奈，改回这个参数默认值=linear，看看时间，今天的升级计划无论如何都需要晚上加班完成了。然后关掉数据库，让客户重启机器，预计10分钟后可以开始重新执行和验证。结果10分钟过去了，机器还是ping不同，怪了，最怕机器没关机的时候运行好好的，重启就起不来了，这样类似的事情遇到过几次。于是，KVM连过去，发现竟然是因为机器有超过436天未重启，导致有436天未对EMC存储进行检测，现在机器正在强制对EMC存储进行检测，漫长的等待，大概25-30分钟后才完成。

接下来一切顺利，开始重新执行这个过程，果然，15分钟后就完成了，咳，这么杯具，没办法，只好重新将这个语句拿出来分析，看看到底是那个函数或者功能导致的这个bug，这个insert。。。select语句，嵌套了多层子查询，从后面开始往前删除条件，最后定为到union all所在的子查询。

为了确认，现场客户想朋友拿了个oracle support帐户，登陆后查询过程查询到因为union导致7445的bug记录。虽然我这个是union all，但是基本可以确认是同类似的bug。

Bug 4664788: QUERY WITH UNION FAILS WITH ORA-7445 KKQUDHUS

Bug 属性

类型B - Defect已在产品版本中修复11.1严重性2 - Severe Loss of Service产品版本10.2.0.1.0状态80 - Development to Q/A平台23 - Oracle Solaris on SPARC (64-bit)创建时间10-Oct-2005平台版本5.9更新时间04-Jan-2011基本 Bug-数据库版本10.2.0.1.0  影响平台Generic  产品源Oracle

相关产品

产品线Oracle Database Products系列Oracle Database区域Oracle Database产品5 - Oracle Server - Enterprise Edition

 Hdr: 4664788 10.2.0.1.0 RDBMS 10.2.0.1.0 QRY OPTIMIZER PRODID-5 PORTID-23 ORA-7445Abstract: QUERY WITH UNION FAILS WITH ORA-7445 KKQUDHUS*** 10/10/05 02:41 am ****** 10/10/05 03:32 am *** (CHG: Sta->16)*** 10/10/05 03:32 am ****** 10/11/05 11:07 pm *** (CHG: Asg->NEW OWNER OWNER)*** 10/11/05 11:25 pm ***Queryselect username    from dba_users u     where username in (select t.owner from  dba_tables t                        where table_name not in ( select e.table_name                                                  from dba_external_tables e                                                   where e.owner=t.owner))   union    select 't' from dual; *** 10/11/05 11:34 pm *** (CHG: Sta->11 Asg->NEW OWNER OWNER)*** 10/11/05 11:34 pm ****** 10/11/05 11:40 pm *** (CHG: Asg->NEW OWNER OWNER)*** 10/11/05 11:40 pm ****** 10/19/05 12:29 am ****** 10/21/05 12:56 pm ****** 10/21/05 01:27 pm ****** 12/01/05 05:51 pm *** (CHG: Asg->NEW OWNER OWNER)*** 12/02/05 04:30 pm *** (CHG: Fixed->11.1)*** 12/02/05 04:30 pm *** (CHG: Sta->80)*** 12/02/05 04:30 pm ***Rediscovery Information:Crash in kkqudhus with kkquhcus above it in the stack trace.Workaround:Set _optimizer_cbqt_no_size_restriction to false (disables two-pass unnest).*** 05/03/07 06:06 pm ****** 05/03/07 06:07 pm ****** 05/03/07 06:07 pm ****** 05/24/07 01:23 pm ****** 07/16/07 09:39 am ****** 01/03/11 10:48 pm ****** 01/04/11 01:01 am *** 

从查询07445过程方式可以看到，07445和00600同属与oracle bug，因为专门为这2类错误号提供的查询口径。从这个bug可以看到，一直到11.1才进行了修复，目前在用的10.2.0.3版本，要跨越这么大的升级是不可能的，只能修改SQL语句。

知道了这个bug就好办，接下来的工作就是修改SQL语句。

小结

修改任何参数都存在风险，更别说是隐含参数了。注意喽！

-The End-