ORA-07445: 出现异常错误: 核心转储

上海_Jeff

大家帮看看这个错误怎么解决，附件是10046做的跟踪。

上海_Jeff

估计是那个表的问题，我把那个表重建了。
上次对那个做了下重定义，有可能是忘了做结束操作，或者是其他问题。
需要再观察看看。

Maclean Liu(刘相兵

ODM Data:
11.1.0.7.0 x64 on Windows


Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0xFFFFFFFFFFFFFFFF] [PC:0x46F80D7, qesltcFastRowOperandsEvaluateSingle()+187]
Incident 21073 created, dump file: d:\app\administrator\diag\rdbms\orc92i\orc92i\incident\incdir_21073\orc92i_ora_11880_i21073.trc
ORA-07445: 出现异常错误: 核心转储 [qesltcFastRowOperandsEvaluateSingle()+187] [ACCESS_VIOLATION] [ADDR:0xFFFFFFFFFFFFFFFF] [PC:0x46F80D7] [UNABLE_TO_READ] []


可能是一个bug ，但是目前找不到 qesltcFastRowOperandsEvaluateSingle 函数相关的bug note, 唯一的一点信息：

1. Bind Variables Passed By Pro*C Wrongly set to NULL with 11g Client
   
2. 
   
3. Applies to:
   
4. Precompilers - Version: 11.1.0.6 to 11.1.0.7 - Release: 11.1 to 11.1
   
5. Information in this document applies to any platform.
   
6. Checked for relevance on 01-Feb-2011
   
7. Symptoms
   
8. 
   
9. Pro*C application intermittently fails with ORA-01400 when executing using 11g client client. The application is binding the data correctly but 10046 trace shows data is missing(NULL) and thus the error
   
10. 
    
11. ORA-01400: cannot insert NULL into ("ORA_TEST"."RTNS_CFQ"."SECT_ENABLE_MASK")
    
12. 
    
13. Error occurs only when using 11g client and doesn't occur with 10.2 client. Database version doesn't seem to matter.
    
14. 
    
15. IF 'Not Null' constraint is not enabled on the column then NULL data is silently inserted/updated leading to data corruption
    
16. 
    
17. Cause
    
18. 
    
19. The cause of this problem has been identified and verified in an unpublished Bug 6957408
    
20. 
    
21. The problem observed in oracle sqllib layer where the bind mode was not properly set.
    
22. 
    
23. 
    
24. Possible Symptoms to check if you are hitting Bug6957408
    
25. 1) Add debugging statements to your proc application to make sure the bind variables are set correctly
    
26. 
    
27. 2) Generate 10046 trace(level 4) for the pro*C sessions and check what is the value passed to the bind variables
    
28. 
    
29. For ex:-
    
30. Bind#1
    
31. oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
    
32. oacflg=00 fl2=1000000 frm=00 csi=00 siz=0 off=128
    
33. kxsbbbfp=2a96c3dd20 bln=22 avl=02 flg=01
    
34. value=3
    
35. Bind#2
    
36. oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
    
37. oacflg=00 fl2=1000000 frm=00 csi=00 siz=0 off=152
    
38. kxsbbbfp=2a96c3dd38 bln=22 avl=00 flg=01
    
39. EXEC #10:c=0,e=328,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1023083737,tim=1226523922263343
    
40. ERROR #10:err=1400 tim=1226523922263373
    
41. 
    
42. Note:- For bind2 value is missing/NULL
    
43. 
    
44. 3) Generate error stack level 3 of ORA-01400 error
    
45. 
    
46. With bug6957408 it is always either one of following
    
47. qesltcFastRowOperandsEvaluateSingle or qesltcFastRowOperandsEvaluate that is calling kxcsnn() and signalling ORA-01400...
    
48. 
    
49. 4) Build the failing application with HOLD_CURSOR=YES and see if it fixes the error
    
50. 
    
51. 5) Bug 6957408 also occurs with Returning clause on the DML operation
    
52. Solution
    
53. 
    
54. Options to resolve the Error
    
55. 
    
56. 1) Use workaround of HOLD_CURSOR=YES for precompiling the application
    
57. 
    
58. Note.2055810.6 Ext/Pub Precompiler HOLD_CURSOR and RELEASE_CURSOR Options
    
59. Note.51018.1 Ext/Pub Using ORACA to Monitor Effects of HOLD_CURSOR / RELEASE_CURSOR
    
60. 
    
61. OR
    
62. 
    
63. 2) Apply one-off patch for Bug 6957408
    
64. 
    
65. Note:- Since the bug lies at the programmatic interface layer, the bug could affect other API / applications. Recommendation is to apply the patch to circumvent other manifestations in place of the work around when feasible.
    
66. References
    
67. BUG:7565718 - 11G PROC APPLICATION FAILS WITH ORA-01400 ERROR EVEN WITH VALID BINDS
    
68. NOTE:2055810.6 - Precompiler HOLD_CURSOR and RELEASE_CURSOR Options
    
69. NOTE:51018.1 - Using ORACA to Monitor Effects of HOLD_CURSOR / RELEASE_CURSOR

复制代码

上海_Jeff

问题补充：
我是通过ROWID对表做在线重定义，重定义完了，会产生一个隐藏的列，我把列直接删除了，就回出现这个问题。又做了次测试，问题重现。
select col#,name,type# from SYS.COL$ WHERE OBJ# IN
(select object_id from dba_objects where owner='SEDAS_2' AND object_name='TEST_1');

ALTER TABLE TEST_1 DROP COLUMN "SYS_C00004_12030909:39:31$"

如果先对隐藏的列做一个无用的操作，再删除，就不会出现这个情况：
ALTER TABLE TEST_1 SET UNUSED ("SYS_C00004_12030909:50:15$");
ALTER TABLE TEST_1 DROP UNUSED COLUMNS;

这样操作原表就可以正常使用。

数据库版本 11.1.0.7

Maclean Liu(刘相兵

如想进一步诊断的话 请上传
d:\app\administrator\diag\rdbms\orc92i\orc92i\incident\incdir_21073\orc92i_ora_11880_i21073.trc

这个trace文件