今天现场的兄弟打电话来说，在开发库上（win7 64bit）刚安装11.2.0.1.0后,先是用数据泵导数据有问题，好不容易解决，接着执行SQL报错，简单的SQL不报错，只要几张表关联的就会报错，于是把现场的日志拿回来分享。对于这种ORA-00600的错误，都是Oracle的bug，只有求助于metalink。
*** 2014-11-25 11:14:06.444
ORA-00600: 内部错误代码, 参数: [kqlInvObj:user], [90], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kqlInvObj:user], [90], [], [], [], [], [], [], [], [], [], []
CREATE GLOBAL TEMPORARY TABLE "SYS"."SYS_TEMP_0FD9D6606_37915C" ("C0" DATE,"C1" VARCHAR2(20),"C2" VARCHAR2(50),"C3" NUMBER(15,3),"C4" NUMBER(15,3),"C5" NUMBER,"C6" NUMBER ) IN_MEMORY_METADATA CURSOR_SPECIFIC_SEGMENT STORAGE (OBJNO 4254950918 ) CACHE
----- Current SQL Statement for this session (sql_id=86bx9jarmy2hq) -----
SELECT DISTINCT DR.NAME REGION_NAME,
D.ENERGY_ID,
M.INSTALL_POINT_NO ANLAGE,
LTRIM(U.VKONT, '0') AS VKONT,
U.CNAME,
NVL(M.CT_RATIO, 1) CT_RATIO,
NVL(M.PT_RATIO, 1) AS PT_RATIO,
M.HANGCARDNO,
T.CAPACITY,
D.ASSET_NO,
D.METER_ID,
TO_CHAR(D.DT, 'YYYY-MM-DD') AS TIME,
D.ACTIVE_TOTAL,
D.TOTAL_START_CODE,
D.TOTAL_END_CODE,
TO_CHAR(D.START_CODE_TIME, 'YYYY-MM-DD HH24:MI:SS') AS START_CODE_TIME,
TO_CHAR(D.END_CODE_TIME, 'YYYY-MM-DD HH24:MI:SS') AS END_CODE_TIME,
D.LINE_ID,
D.LINE_NAME,
DFR.In_Energy,
DFR.Out_Energy,
DFR.Loss_Energy,
DFR.Loss_Rate,
NVL(DECODE(TER.TERM_ASSET_NO,
NULL,
TRIM(M.METER_ID),
TER.METER_ID),
'7783') AS METERCODE
FROM DTL_LL_MTERGY_DAY D,
DTL_LL_FD_RATE_DAY DFR,
MD_CCSMETERS M,
MD_INSTALL_POINT P,
MD_CONTRACT C,
MD_USER U,
MD_TERMINAL TER,
MD_TRANSFORMER T,
SA_LL_EXP_METER_DAY EMD,
DIM_REGION DR
WHERE D.Line_Id = DFR.Line_Id
AND DFR.DT(+) = D.DT
AND DFR.REGION = DR.CODE
AND (M.BUREAU_NO = D.ASSET_NO OR M.BUREAU_NO = LPAD(D.ASSET_NO, 18, '0'))
AND P.INSTALL_POINT_NO(+) = M.INSTALL_POINT_NO
AND P.INSTALL_POINT_NO = C.INSTALL_POINT_NO(+)
AND C.VKONT = U.VKONT(+)
AND T.HANGCARDNO(+) = M.HANGCARDNO
AND M.TERMINAL_BUREAU_NO = TER.TERM_ASSET_NO(+)
AND EMD.ENERGY_ID = D.ENERGY_ID
AND EMD.DT = D.DT
AND D.DT BETWEEN TO_DATE('2013-7-8', 'YYYY-MM-DD') AND TO_DATE('2013-8-6', 'YYYY-MM-DD');
在matelink查询，显示有几个bug匹配。
类型
B - Defect
已在产品版本中修复
-
严重性
2 - Severe Loss of Service
产品版本
11.2.0.1.0
状态
33 - Suspended, Req'd Info not Avail
平台
23 - Oracle Solaris on SPARC (64-bit)
创建时间
02-Nov-2010
平台版本
10
更新时间
14-Jan-2011
基本 Bug
-
数据库版本
11.2.0.1
影响平台
Generic
产品源
Oracle
SHAPE * MERGEFORMAT 相关产品
产品线
Oracle Database Products
系列
Oracle Database
区域
Oracle Database
产品
5 - Oracle Server - Enterprise Edition
Hdr: 10256218 11.2.0.1 RDBMS 11.2.0.1.0 DICTIONARY PRODID-5 PORTID-23 ORA-600
Abstract: IMPDP FAILS WITH ORA-600[KQLINVOBJ:USER], [94]
BUG TYPE CHOSEN
===============
Code
SubComponent: Dictionary
========================
DETAILED PROBLEM DESCRIPTION
============================
Impdp fails with ORA-600: internal error code, arguments:
[kqlInvObj:user], [94]
Failing statement is CREATE TABLE "SYSTEM"."SYS_IMPORT_FULL_01
DIAGNOSTIC ANALYSIS
===================
We tried to patch data dictionary using this procedure:
1. SHUTDOWN IMMEDIATE or NORMAL
2. STARTUP RESTRICT
3. Create a new user called PATCH_USER:
create user PATCH_USER identified by p;
4. Update obj$
update sys.obj$
set owner# = (select user#
from sys.user$
where name = 'PATCH_USER')
where owner# in (88,94);
5. COMMIT;
6. Shutdown abort;
7. STARTUP
8. Drop user created in step 3:
drop user PATCH_USER cascade;
After this is completed impdp works no errors, however hcheck.full shows a
new inexistant user with objects in OBJ$.
We repeated the procedure again and same results, please see output3.txt.
Looks like drop PATCH_USER cascade, drops the user but doesn't remove the
objects from OBJ$.
WORKAROUND?
===========
No
TECHNICAL IMPACT
================
Now no errors anymore, but customer is afarid of future issues because of
this data dictionary inconsistency.
RELATED ISSUES (bugs, forums, RFAs)
===================================
Few bugs for the ora-600:
10161293 91 ORA-600 [KQLINVOBJ:USER] CREATING NEW OBJECTS
10062629 92 ORA-600: INTERNAL ERROR CODE, ARGUMENTS: [KQLINVOBJ:USER],
[93]
9859357 31 ORA-600 [KQLINVOBJ:USER] DURING CATUPGRD.SQL
9832889 91 [KQLINVOBJ:USER WHILE CREATING A TABLE
9664287 92 [KQLINVOBJ:USER WHILE CREATING A TABLE
HOW OFTEN DOES THE ISSUE REPRODUCE AT CUSTOMER SITE?
====================================================
Always
DOES THE ISSUE REPRODUCE INTERNALLY?
====================================
Not attempted
EXPLAIN WHY THE ISSUE WAS NOT TESTED INTERNALLY.
================================================
I don't have ct env
IS A TESTCASE AVAILABLE?
========================
No
Link to IPS Package:
====================
We have incident tracefile
处理步骤：
delete from sys.obj$ where owner# in (90);--90是[kqlInvObj:user],
commit;
：