前几天写到在客户现场处理了一个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-