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-7445
Abstract: 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 ***

Query
select 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-