Oracle数据库数据恢复、性能优化»论坛 › Oracle › Oracle数据库管理 › ORA-00600: internal error code, arguments: [k2vpci_2 ...

94 积分	0 好友	1 主题

发消息

ORA-00600: internal error code, arguments: [k2vpci_2],

1^#

发表于 2012-4-28 16:33:40 | 查看: 13908| 回复: 32

Errors in file /oracle/diag/rdbms/jhyktdb/jhyktdb1/trace/jhyktdb1_ora_7340264.trc  (incident=44338):
ORA-00600: internal error code, arguments: [k2vpci_2], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /oracle/diag/rdbms/jhyktdb/jhyktdb1/incident/incdir_44338/jhyktdb1_ora_7340264_i44338.trc
Thread 1 advanced to log sequence 10425 (LGWR switch)
  Current log# 5 seq# 10425 mem# 0: +DG01/jhyktdb/onlinelog/group_5.269.758663851
  Current log# 5 seq# 10425 mem# 1: +DGFRA/jhyktdb/onlinelog/group_5.263.758663853
Archived Log entry 14150 added for thread 1 sequence 10424 ID 0x56606825 dest 1:
Sat Apr 28 15:59:53 2012
Dumping diagnostic data in directory=[cdmp_20120428155953], requested by (instance=1, osid=7340264), summary=[incident=44338].
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /oracle/diag/rdbms/jhyktdb/jhyktdb1/trace/jhyktdb1_ora_7340264.trc:
ORA-00600: internal error code, arguments: [k2vpci_2], [], [], [], [], [], [], [], [], [], [], []
Errors in file /oracle/diag/rdbms/jhyktdb/jhyktdb1/trace/jhyktdb1_ora_7340264.trc:
ORA-00600: internal error code, arguments: [k2vpci_2], [], [], [], [], [], [], [], [], [], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 7340264): terminating the instance due to error 600
Instance terminated by USER, pid = 7340264
ORA-1092 signalled during: ALTER DATABASE OPEN...
opiodr aborting process unknown ospid (7340264) as a result of ORA-1092
Sat Apr 28 15:59:54 2012
ORA-1092 : opitsk aborting process
~
数据库无法启动，请刘大帮忙看下。有没临时处理办法

[ 本帖最后由 lixz_2008 于 2012-4-28 16:44 编辑 ]

jhyktdb1_ora_7340264.rar

1.34 KB, 下载次数: 1124

收藏0 回复只看该作者道具举报

Maclean Liu(刘相兵

2^#

发表于 2012-4-28 16:35:10

请压缩打包上传/oracle/diag/rdbms/jhyktdb/jhyktdb1/trace/jhyktdb1_ora_7340264.trc

回复只看该作者道具举报

3^#

发表于 2012-4-28 16:44:36

回复 2# 的帖子

trace日志已经上传。

回复只看该作者道具举报

Maclean Liu(刘相兵

4^#

发表于 2012-4-28 20:22:46

Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 + AIX

2012-04-28 15:59:35.510000 : Start recovery for domain=0, valid=0, flags=0x4

*** 2012-04-28 15:59:42.374
Successfully allocated 32 recovery slaves
Using 3 overflow buffers per recovery slave

*** 2012-04-28 15:59:42.969
Thread 2 checkpoint: logseq 3741, block 2, scn 12158435448068
on-disk rba: logseq 3741, block 3, scn 12158435448070
  start recovery at logseq 3741, block 3, scn 12158435448070

*** 2012-04-28 15:59:43.104
Started writing zeroblks thread 2 seq 3741 blocks 3-10

*** 2012-04-28 15:59:43.111
Completed writing zeroblks thread 2 seq 3741
==== Redo read statistics for thread 2 ====
Total physical reads (from disk and memory): 4096Kb
-- Redo read_disk statistics --
Read rate (ASYNC): 0Kb in 0.12s => 0.00 Mb/sec
----------------------------------------------
----- Recovery Hash Table Statistics ---------
Hash table buckets = 262144
Longest hash chain = 0
Average hash chain = 0/0 = 0.0
Max compares per lookup = 0
Avg compares per lookup = 0/0 = 0.0
----------------------------------------------

*** 2012-04-28 15:59:43.138
KCRA: start recovery claims for 0 data blocks

*** 2012-04-28 15:59:43.143
KCRA: blocks processed = 0/0, claimed = 0, eliminated = 0

*** 2012-04-28 15:59:43.149
Recovery of Online Redo Log: Thread 2 Group 6 Seq 3741 Reading mem 0

*** 2012-04-28 15:59:43.151
Completed redo application of 0.00MB

*** 2012-04-28 15:59:43.167
Completed recovery checkpoint
----- Recovery Hash Table Statistics ---------
Hash table buckets = 262144
Longest hash chain = 0
Average hash chain = 0/0 = 0.0
Max compares per lookup = 0
Avg compares per lookup = 0/0 = 0.0
----------------------------------------------

*** 2012-04-28 15:59:44.341
Recovery sets nab of thread 2 seq 3741 to 3 with 8 zeroblks

*** 2012-04-28 15:59:46.954
2012-04-28 15:59:46.954804 : Validate domain 0
2012-04-28 15:59:46.970282 : Validated domain 0, flags = 0x0

*** 2012-04-28 15:59:47.052
Pick closed redo thread 2 to enable my thread
Initial buffer sizes: read 1024K, overflow 832K, change 805K

*** 2012-04-28 15:59:49.600
Incident 44338 created, dump file: /oracle/diag/rdbms/jhyktdb/jhyktdb1/incident/incdir_44338/jhyktdb1_ora_7340264_i44338.trc
ORA-00600: internal error code, arguments: [k2vpci_2], [], [], [], [], [], [], [], [], [], [], []

ORA-00600: internal error code, arguments: [k2vpci_2], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [k2vpci_2], [], [], [], [], [], [], [], [], [], [], []

k2vpci_2  ==> k2v txn/disttx handles distributed recovery operation

k2v 意味着分布式恢复操作

A fatal ORA-600 [k2vpci_2] can occur if distributed transactions
with multiple branches are being used. This problem can crash
the instance and then prevent subsequent startup due to the same
error when attempting transaction recovery.

Rediscovery Notes:
  ORA-600 [k2vpci_2] in SMON then an instance crash
  SMON or a subsequent failing startup attempt has a stack of the form:
k2vProcessCollectingInfo()
k2vcbk()
kturRecoverTxn()
kturRecoverUndoSegment()
kturRecoverActiveTxns()
  Even if a system receives an ORA-600 [k2vpci_2] in other circumstances
  then this fix should help as the error scenario is changed to a user
  error rather than an ORA-600.

尝试 disable SMON recovery dead transaction

alter system set event= '10513 trace name context forever, level 2'  scope=spfile;

再次重启观察

可以的话也请打包上传 /oracle/diag/rdbms/jhyktdb/jhyktdb1/incident/incdir_44338/jhyktdb1_ora_7340264_i44338.trc

回复只看该作者道具举报

5^#

发表于 2012-4-28 21:14:45

今天下午我和他说用10513 禁止SMON恢复

网友说无效

杭州-碧海星空(249737741) 17:07:09
ORA-00600: internal error code, arguments: [k2vpci_2]
10513 禁用SMON恢复无效

回复只看该作者道具举报

6^#

发表于 2012-4-28 21:37:51

回复 5# 的帖子

alter system set event= '10513 trace name context forever, level 2' scope=spfile;
我下午设置过依然无法启动
/oracle/diag/rdbms/jhyktdb/jhyktdb1/incident/incdir_44338/jhyktdb1_ora_7340264_i44338.trc
上传

[ 本帖最后由 lixz_2008 于 2012-4-28 21:39 编辑 ]

jhyktdb1_ora_7340264.rar

1.34 KB, 下载次数: 1045

jhyktdb1_ora_7340264_i44338.rar

473.09 KB, 下载次数: 925

回复只看该作者道具举报

7^#

发表于 2012-4-28 22:00:17

可能需要借助BBED 修改事务的状态了

回复只看该作者道具举报

Maclean Liu(刘相兵

8^#

发表于 2012-4-28 22:00:28

Dump continued from file: /oracle/diag/rdbms/jhyktdb/jhyktdb1/trace/jhyktdb1_ora_7340264.trc
ORA-00600: internal error code, arguments: [k2vpci_2], [], [], [], [], [], [], [], [], [], [], []

========= Dump for incident 44338 (ORA 600 [k2vpci_2]) ========

*** 2012-04-28 15:59:49.686
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=1h50ks4ncswfn) -----
ALTER DATABASE OPEN

kgeasnmierr()+72    call    kgerinv()          000000000 ?
                                                FFFFFFFFFFFF0000 ?
                                                7000000000 ? 30000016D ?
                                                000000000 ? 000000000 ?
                                                000000000 ? 000000000 ?
k2vProcessCollectin  call    kgeasnmierr()       000000000 ? FFFFFFFFFFEC3E0 ?
gInfo()+552                                     FFFFFFFFFFEC340 ? 000000000 ?
                                                000000000 ? 110E53820 ?
                                                FFFFFFFFFFEC2B0 ? 00000023C ?
k2vcbk()+348       call    k2vProcessCollectin  000000000 ? 000000000 ?
                           gInfo()             7000003EC32A978 ?
                                                7000003EAAC0A70 ? 100000001 ?
                                                100000000 ? 000000000 ?
                                                000000000 ?
kturRecoverTxn()+62  call    k2vcbk()          53500000535 ?
72                                              A2000C0000038C ? 110000408 ?
                                                7000003F5FB31D8 ?
                                                FFFFFFFFFFEC630 ? 000000000 ?
                                                1011E2D14 ? 4F9A841E8 ?
kturRecoverUndoSegm  call    kturRecoverTxn()    FFFFFFFFFFECEA8 ?
ent()+5692                                        C000002420261 ? 022420241 ?
                                                00000000A ? 110101650 ?
                                                37FFFFFFF ? 10A630F28 ?
                                                109ECF39C ?
ktuiup()+1484       call    kturRecoverUndoSegm  A200000000 ? 000000000 ?
                           ent()             000000000 ? 147AE1400000000 ?
                                                FFFF000100000001 ?
                                                000000000 ? 300000000 ?
                                                7000003F5B9A378 ?
ktuini()+396       call    ktuiup()          7000003EB9DFB80 ?
                                                FFFFFFFFFFED800 ?
                                                FFFFFFFFFFEDC00 ?
                                                24628189000335C8 ?
                                                107D2C4F0 ? 10A083340 ?
                                                000000078 ? 10A083328 ?
adbdrv()+11916    call    ktuini()          0EA4E3E48 ? FFFFFFFFFFEDEE0 ?

stack call  kturRecoverTxn=>k2vcbk=> k2vProcessCollectingInfo

ODM FINDING:

Looking at : prd11_ora_2550_i745421.trc

Stack :
kgeasnmierr <- k2vProcessCollectingInfo <- k2vcbk
   <- kturrt <- kturec <- ktuiup <- ktuini <- adbdrv
      <- opiexe <- opiosq0 <- kpooprx <- kpoal8 <- opiodr
      <- ttcpip <- opitsk <- opiino <- opiodr <- opidrv
      <- sou2o <- main <- start

The error is raised from : k2v.c

k2vProcessCollectingInfo()

...
  if (colinfo->k2vciprp) /* found a recoverable session record; process it
*/
  {
k2isvec new_prepvec = (k2isvec)0;

for (slotnum = 1; slotnum <= 32; slotnum++)
   if (bit(colinfo->k2vciprp->k2lprses, k2isno(slotnum)))
   {
      KSEORAASSERTNM(bno_map[slotnum] != 0, OERINM("k2vpci_2"));  <<<<
...

k2v is called from the RECO process as part of 2 phase commit
transaction resolution.
Note: there is no reference to the insert of :
2. 43.33.203730  - 0x002b.021.00031bd2
into pending tables detailed in the alert.log file.

In order to get around this issue.
- The rollback segment contained was offlined, using
_offline_rollback_segment  and
- event 10513 / level 2 set to disable tranction recovery.

  usn: 162
  sp1:0x00000000 sp2:0x00000000 sp3:0x00000000 sp4:0x00000000
  sp5:0x00000000 sp6:0x00000000 sp7:0x00000000 sp8:0x00000000
  EXT TRN TBL::
  index  extflag extHash extSpare1 extSpare2

2012-04-28 15:59:49.451688 :8000BE82:db_trace:ksl2.c@13726:ksliwat(): [10005:38:761] KSL POST RCVD poster=36 num=2450 loc='kqr.h LINE:2207 ID:kqrbtm' id1=0 id2=0 name= type=0 fac#=3 posted=0x3 may_be_posted=1
2012-04-28 15:59:49.451787 :8000BE90:db_trace:ktu.c@15064:ktutrc(): [10444:38:761] Rec rbs _SYSSMU162_3889638824$
2012-04-28 15:59:49.454513 :8000BE91:KFNC:kfnc.c@2995:kfncFaultXPMap(): kfncFaultXPMap: gnum [2.1204521819], fnum [272.758663873] mapid 14, faultingXP:84
2012-04-28 15:59:49.454515 :8000BE92:KFNC:kfnc.c@4538:kfncNoSlavePriv(): kfncNoSlave at kfnc.c:3003
2012-04-28 15:59:49.454519 :8000BE93:KFNC:kfnc.c@7259:kfncSlaveMsgAllocInt(): kfncSlaveMsgAlloc [kfncFaultXPMap] usepga=0 workmsg=1 uga=0x110ce67e0 at kfnc.c:3011
2012-04-28 15:59:49.454521 :8000BE94:KFNC:kfnc.c@7292:kfncSlaveMsgAllocInt(): allocating work message
2012-04-28 15:59:49.454531 :8000BE95:KFNC:kfnc.c@4888:kfncSlaveSubmitReal(): submit slave job for opcode 33
2012-04-28 15:59:49.454596 :8000BE96:db_trace:ksl2.c@15159:ksl_update_post_stats(): [10005:38:761] KSL POST SENT postee=79 num=1210 loc='ksv2.h LINE:1646 ID:ksvpst: checkpool' id1=0 id2=0 name= type=0
2012-04-28 15:59:49.454629 :8000BE9A:db_trace:ksl2.c@13726:ksliwat(): [10005:38:761] KSL POST RCVD poster=79 num=17 loc='ksv2.h LINE:1670 ID:ksvpst: getwork' id1=0 id2=0 name= type=0 fac#=3 posted=0x3 may_be_posted=1
2012-04-28 15:59:49.458787 :8000BEA3:db_trace:ksl2.c@13726:ksliwat(): [10005:38:761] KSL POST RCVD poster=79 num=18 loc='ksv2.h LINE:1673 ID:ksvpst: workdone' id1=0 id2=0 name= type=0 fac#=3 posted=0x3 may_be_posted=1
2012-04-28 15:59:49.458793 :8000BEA4:KFNC:kfnc.c@4993:kfncSlaveSubmitReal(): slave submit returning status 0
2012-04-28 15:59:49.458794 :8000BEA5:KFNC:kfnc.c@7337:kfncSlaveMsgFree(): kfncSlaveMsgFree [kfncFaultXPMap] 0x7000003f9b55808 alloc=0x1 msgtyp=0x1
2012-04-28 15:59:49.459018 :8000BEA6:db_trace:ktur.c@1677:kturRecoverUndoSegment(): [10444:38:761] UNDO SEG (BEFORE RECOVERY): usn = 162
2012-04-28 15:59:49.459026 :8000BEA7:db_trace:ktur.c@1993:kturRecoverTxn(): [10444:38:761] Recovering transaction (162, 12)
2012-04-28 15:59:49.459237 :8000BEA8:db_trace:ktur.c@2080:kturRecoverTxn(): [10444:38:761] Recording indoubt transaction (162, 12)

相关的USN =162 Undo segment  _SYSSMU162_3889638824$

设置_offline_rollback_segments=_SYSSMU162_3889638824$
加上
alter system set event= '10513 trace name context forever, level 2'  scope=spfile;

之后

startup mount;
alter database open;

若仍无法解决问题，上传本次的600 TRACE

回复只看该作者道具举报

9^#

发表于 2012-4-28 22:18:42

回复 8# 的帖子

刘大，能说明白点吗？

回复只看该作者道具举报

Maclean Liu(刘相兵

10^#

发表于 2012-4-28 22:47:40

相关的USN =162 Undo segment _SYSSMU162_3889638824$

设置_offline_rollback_segments=_SYSSMU162_3889638824$
加上
alter system set event= '10513 trace name context forever, level 2' scope=spfile;

之后

startup mount;
alter database open;

若仍无法解决问题，上传本次的600 TRACE

回复只看该作者道具举报

11^#

发表于 2012-4-28 22:58:06

回复 10# 的帖子

数据库打开了接下午我怎么操作呢？

回复只看该作者道具举报

Maclean Liu(刘相兵

12^#

发表于 2012-4-28 23:02:13

打包上传压缩后的 alert.log 和最新的SMON 进程的TRACE

回复只看该作者道具举报

13^#

发表于 2012-4-28 23:15:18

回复 12# 的帖子

上传最新alert日志

14.27 KB, 下载次数: 982

回复只看该作者道具举报

Maclean Liu(刘相兵

14^#

发表于 2012-4-28 23:31:39

1.

建议首先执行全库的逻辑和物理备份

2.

检查 select * from dba_2pc_pending

尝试创建新的UNDO TABLESPACE ，并切换到该 undo tbs上

之后尝试取消 event 和 _offline_rollback_segments 参数

回复只看该作者道具举报

15^#

发表于 2012-4-28 23:38:49

回复 14# 的帖子

select * from dba_2pc_pending
这个我已经查看过没有内容

回复只看该作者道具举报

16^#

发表于 2012-4-28 23:49:21

回复 10# 的帖子

能否直接把SYSSMU162_3889638824$ drop掉？

回复只看该作者道具举报

Maclean Liu(刘相兵

17^#

发表于 2012-4-29 00:05:57

回复 16# 的帖子

实际测试发现 11gR2中使用 "_smu_debug_mode" 手动调试管理USN存在问题

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0    Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

SQL>  alter system set "_smu_debug_mode"=4;

System altered.

SQL>  select 'drop rollback segment "'||segment_name||'";' from dba_rollback_segs where segment_name!='SYSTEM';

'DROPROLLBACKSEGMENT"'||SEGMENT_NAME||'";'
-------------------------------------------------------
drop rollback segment "_SYSSMU10_3047102850$";
drop rollback segment "_SYSSMU9_4071341447$";
drop rollback segment "_SYSSMU8_1468850038$";
drop rollback segment "_SYSSMU7_369463319$";
drop rollback segment "_SYSSMU6_496991355$";
drop rollback segment "_SYSSMU5_3902106209$";
drop rollback segment "_SYSSMU4_2163031322$";
drop rollback segment "_SYSSMU3_1807489187$";
drop rollback segment "_SYSSMU2_167445430$";
drop rollback segment "_SYSSMU1_1017354285$";
drop rollback segment "_SYSSMU241$";

241 rows selected.

SQL> drop rollback segment "_SYSSMU241$";
drop rollback segment "_SYSSMU241$"
*
ERROR at line 1:
ORA-01545: rollback segment '_SYSSMU241$' specified not available

SQL> drop rollback segment "SYSSMU241$";

Rollback segment dropped.



SQL> select segment_name,status from dba_rollback_segs where segment_name='_SYSSMU241$';

SEGMENT_NAME                STATUS
------------------------------ ----------------
_SYSSMU241$                   ONLINE

所以建议你先尝试重建并切换 Undo tbs

回复只看该作者道具举报

18^#

发表于 2012-4-29 00:50:18

回复 17# 的帖子

真心感谢刘大！！对我的帮助很大！
现在还在备份数据库。这个数据库是否一定要升级？

回复只看该作者道具举报

19^#

发表于 2012-4-29 01:26:12

回复 18# 的帖子

重建UNDO后去掉2个参数错误还是存在

回复只看该作者道具举报

20^#

发表于 2012-4-29 08:25:02

回复 19# 的帖子

升级后还是会报错纠结了...，升级的时候因为必须要打开数据库，所以保持了*._offline_rollback_segments='_SYSSMU162_3889638824$'，是升级完后去掉这个参数错误依旧。

回复只看该作者道具举报

Maclean Liu(刘相兵

21^#

发表于 2012-4-29 10:25:20

把最近出错的 alert.log 和 incident TRACE (比较大的) 上传

回复只看该作者道具举报

22^#

发表于 2012-4-29 15:20:46

回复 21# 的帖子

刘大，我在添加 _offline_rollback_segments参数情况下，启动数据库，重建REDO并切换，然后将原来有的REDO offline掉，成功再drop了回滚段，恢复了正常，删掉参数后能正常启动。不知道强行drop回滚段，对数据库有没影响？

回复只看该作者道具举报

Maclean Liu(刘相兵

23^#

发表于 2012-4-29 18:09:03

"不知道强行drop回滚段，对数据库有没影响？"

可能造成与该 RBS 回滚段相关的数据块数据不一致(inconsistent)，这些块上今后的 CR 、cleanout等可能失败。

回复只看该作者道具举报

24^#

发表于 2012-4-29 18:42:56

回复 23# 的帖子

前面说错了是重建了undo.
这是否意味着要重新建库迁移数据才安全吗？
如果要迁移数据用expdp迁吧？

回复只看该作者道具举报

25^#

发表于 2012-4-30 18:37:26

回复 24# 的帖子

检查了以下数据字典出现了数据不一致：
SQL> execute hcheck.full
H.Check Version 9i+/hc3.45
---------------------------------------
Catalog Version 11.2.0.3.0 (1102000300)
---------------------------------------

                                 Catalog    Fixed
Procedure Name                   Version Vs Release    Run
------------------------------ ... ---------- -- ---------- ---
.- SynLastDDLTim             ... 1102000300 >  1001000200 : n/a
.- LobNotInObj                ... 1102000300 >  1000000200 : n/a
.- MissingOIDOnObjCol       ... 1102000300 <=  *All Rel* : Ok
.- SourceNotInObj             ... 1102000300 >  1002000100 : n/a
.- IndIndparMismatch          ... 1102000300 >  1102000100 : n/a
.- InvCorrAudit             ... 1102000300 >  1102000100 : n/a
.- OversizedFiles             ... 1102000300 <=  *All Rel* : Ok
.- TinyFiles                ... 1102000300 > 900010000 : n/a
.- PoorDefaultStorage       ... 1102000300 <=  *All Rel* : Ok
.- PoorStorage                ... 1102000300 <=  *All Rel* : Ok
.- MissTabSubPart             ... 1102000300 > 900010000 : n/a
.- PartSubPartMismatch       ... 1102000300 >  1102000100 : n/a
.- TabPartCountMismatch       ... 1102000300 <=  *All Rel* : Ok
.- OrphanedTabComPart       ... 1102000300 > 900010000 : n/a
.- ZeroTabSubPart             ... 1102000300 > 902000100 : n/a
.- MissingSum$                ... 1102000300 <=  *All Rel* : Ok
.- MissingDir$                ... 1102000300 <=  *All Rel* : Ok
.- DuplicateDataobj          ... 1102000300 <=  *All Rel* : Ok
.- ObjSynMissing             ... 1102000300 <=  *All Rel* : Ok
.- ObjSeqMissing             ... 1102000300 <=  *All Rel* : Ok
.- OrphanedUndo             ... 1102000300 <=  *All Rel* : Ok
.- OrphanedIndex             ... 1102000300 <=  *All Rel* : Ok
.- OrphanedIndexPartition    ... 1102000300 <=  *All Rel* : Ok
.- OrphanedIndexSubPartition ... 1102000300 <=  *All Rel* : Ok
.- OrphanedTable             ... 1102000300 <=  *All Rel* : Ok
.- OrphanedTablePartition    ... 1102000300 <=  *All Rel* : Ok
.- OrphanedTableSubPartition ... 1102000300 <=  *All Rel* : Ok
.- MissingPartCol             ... 1102000300 <=  *All Rel* : Ok
.- OrphanedSeg$             ... 1102000300 <=  *All Rel* : Ok
.- OrphanedIndPartObj#       ... 1102000300 >  1101000600 : n/a
.- DuplicateBlockUse          ... 1102000300 <=  *All Rel* : Ok
.- HighObjectIds             ... 1102000300 > 801060000 : n/a
.- PQsequence                ... 1102000300 > 800060000 : n/a
.- TruncatedCluster          ... 1102000300 > 801070000 : n/a
.- FetUet                   ... 1102000300 <=  *All Rel* : Ok
.- Uet0Check                ... 1102000300 <=  *All Rel* : Ok
.- ExtentlessSeg             ... 1102000300 <=  *All Rel* : Ok
.- SeglessUET                ... 1102000300 <=  *All Rel* : Ok
.- BadInd$                   ... 1102000300 <=  *All Rel* : Ok
.- BadTab$                   ... 1102000300 <=  *All Rel* : Ok
.- BadIcolDepCnt             ... 1102000300 >  1101000700 : n/a
.- WarnIcolDep                ... 1102000300 >  1101000700 : n/a
.- OnlineRebuild$             ... 1102000300 <=  *All Rel* : Ok
.- DropForceType             ... 1102000300 >  1001000200 : n/a
.- TrgAfterUpgrade          ... 1102000300 <=  *All Rel* : Ok
.- FailedInitJVMRun          ... 1102000300 <=  *All Rel* : Ok

HCKE-0036: Bad OBJ$ entry with TYPE#=0
OBJ$ OBJ#=109311 TYPE#=0 NAME=IF_WXAB01
OBJ$ OBJ#=74733 TYPE#=0 NAME=IF_WXAB01
OBJ$ OBJ#=88762 TYPE#=0 NAME=IF_WXAC01
OBJ$ OBJ#=108309 TYPE#=0 NAME=AC01

.- TypeReusedAfterDrop       ... 1102000300 > 900010000 : n/a
.- Idgen1$TTS                ... 1102000300 > 900010000 : n/a
.- DroppedFuncIdx             ... 1102000300 > 902000100 : n/a
.- BadOwner                   ... 1102000300 > 900010000 : n/a
.- UpgCheckc0801070          ... 1102000300 <=  *All Rel* : Ok
.- BadPublicObjects          ... 1102000300 <=  *All Rel* : Ok
.- BadSegFreelist             ... 1102000300 <=  *All Rel* : Ok
.- BadCol#                   ... 1102000300 >  1001000200 : n/a
.- BadDepends                ... 1102000300 <=  *All Rel* : Ok

HCKW-0016: Dependency$ p_timestamp mismatch for VALID objects
[W] - P_OBJ#=55476 D_OBJ#=55518
[W] - P_OBJ#=55477 D_OBJ#=55519
[W] - P_OBJ#=55478 D_OBJ#=55520
[W] - P_OBJ#=55479 D_OBJ#=55521
[W] - P_OBJ#=55480 D_OBJ#=55522
[W] - P_OBJ#=55481 D_OBJ#=55523
[W] - P_OBJ#=55482 D_OBJ#=55524
[W] - P_OBJ#=55483 D_OBJ#=55525
[W] - P_OBJ#=55484 D_OBJ#=55526
[W] - P_OBJ#=55485 D_OBJ#=55527
[W] - P_OBJ#=55487 D_OBJ#=55529
[W] - P_OBJ#=55489 D_OBJ#=55531
[W] - P_OBJ#=55491 D_OBJ#=55533
[W] - P_OBJ#=55496 D_OBJ#=55538
[W] - P_OBJ#=55497 D_OBJ#=55539
[W] - P_OBJ#=55498 D_OBJ#=55540
[W] - P_OBJ#=55500 D_OBJ#=55542
[W] - P_OBJ#=55504 D_OBJ#=55546

.- CheckDual                ... 1102000300 <=  *All Rel* : Ok
.- ObjectNames                ... 1102000300 <=  *All Rel* : Ok
.- BadCboHiLo                ... 1102000300 <=  *All Rel* : Ok
.- ChkIotTs                   ... 1102000300 <=  *All Rel* : Ok
.- NoSegmentIndex             ... 1102000300 <=  *All Rel* : Ok
.- BadNextObject             ... 1102000300 <=  *All Rel* : Ok
.- OrphanIndopt             ... 1102000300 > 902000800 : n/a
.- UpgFlgBitTmp             ... 1102000300 >  1001000100 : n/a
.- RenCharView                ... 1102000300 >  1001000100 : n/a
.- Upg9iTab$                ... 1102000300 > 902000400 : n/a
.- Upg9iTsInd                ... 1102000300 > 902000500 : n/a
.- Upg10gInd$                ... 1102000300 >  1002000000 : n/a
.- DroppedROTS                ... 1102000300 <=  *All Rel* : Ok
.- ChrLenSmtcs                ... 1102000300 >  1101000600 : n/a
.- FilBlkZero                ... 1102000300 <=  *All Rel* : Ok
.- DbmsSchemaCopy             ... 1102000300 <=  *All Rel* : Ok

Found 4 potential problem(s) and 18 warning(s)
Contact Oracle Support with the output
to check if the above needs attention or not

PL/SQL procedure successfully completed.

请刘大帮忙看下。谢谢！

回复只看该作者道具举报

26^#

发表于 2012-4-30 19:11:50

回复 25# 的帖子

HCKW-0016: Dependency$ p_timestamp mismatch for VALID objects
[W] - P_OBJ#=55476 D_OBJ#=55518
[W] - P_OBJ#=55477 D_OBJ#=55519
[W] - P_OBJ#=55478 D_OBJ#=55520
[W] - P_OBJ#=55479 D_OBJ#=55521
[W] - P_OBJ#=55480 D_OBJ#=55522
[W] - P_OBJ#=55481 D_OBJ#=55523
[W] - P_OBJ#=55482 D_OBJ#=55524
[W] - P_OBJ#=55483 D_OBJ#=55525
[W] - P_OBJ#=55484 D_OBJ#=55526
[W] - P_OBJ#=55485 D_OBJ#=55527
[W] - P_OBJ#=55487 D_OBJ#=55529
[W] - P_OBJ#=55489 D_OBJ#=55531
[W] - P_OBJ#=55491 D_OBJ#=55533
[W] - P_OBJ#=55496 D_OBJ#=55538
[W] - P_OBJ#=55497 D_OBJ#=55539
[W] - P_OBJ#=55498 D_OBJ#=55540
[W] - P_OBJ#=55500 D_OBJ#=55542
[W] - P_OBJ#=55504 D_OBJ#=55546
已经处理了！
HCKE-0036: Bad OBJ$ entry with TYPE#=0 是数据表。
该如何处理？

回复只看该作者道具举报

Maclean Liu(刘相兵

27^#

发表于 2012-4-30 20:35:41

请下载最新版的 hcheck.sql 脚本收集信息后上传结果

回复只看该作者道具举报

28^#

发表于 2012-4-30 20:53:16

回复 27# 的帖子

我下载的是hcheck3.sql

1.36 KB, 下载次数: 1016

回复只看该作者道具举报

Maclean Liu(刘相兵

29^#

发表于 2012-4-30 22:08:42

action plan:

conn / as sysdba

begin
dbms_hm.run_check('Dictionary Integrity Check', 'dic_check1');
end;
/

begin
dbms_hm.run_check('Undo Segment Integrity Check', 'undo_check1',input_params =>'USN_NUMBER=162');
end;
/

SET LONG 100000
SET LONGCHUNKSIZE 1000
SET PAGESIZE 1000
SET LINESIZE 512
SELECT DBMS_HM.GET_RUN_REPORT('dic_check1') from dual;
SELECT DBMS_HM.GET_RUN_REPORT('UNDO_CHECK1') from dual;

上传以上命令的输出

回复只看该作者道具举报

30^#

发表于 2012-4-30 22:29:15

回复 29# 的帖子

dbms_hm.run_check日志上传

1 KB, 下载次数: 912

回复只看该作者道具举报

Maclean Liu(刘相兵

31^#

发表于 2012-4-30 22:37:19

HCKE-0036: Bad OBJ$ entry with TYPE#=0
OBJ$ OBJ#=109311 TYPE#=0 NAME=IF_WXAB01
OBJ$ OBJ#=74733 TYPE#=0 NAME=IF_WXAB01
OBJ$ OBJ#=88762 TYPE#=0 NAME=IF_WXAC01
OBJ$ OBJ#=108309 TYPE#=0 NAME=AC01

这些对象是否重要？

SQL> SELECT DBMS_HM.GET_RUN_REPORT('dic_check1') from dual;

Basic Run Information
Run Name                   : dic_check1
Run Id                      : 212301
Check Name                : Dictionary Integrity Check
Mode                      : MANUAL
Status                      : COMPLETED
Start Time                : 2012-04-30 22:24:11.161815 +08:00
End Time                   : 2012-04-30 22:24:14.106175 +08:00
Error Encountered          : 0
Source Incident Id          : 0
Number of Incidents Created  : 0

Input Paramters for the Run
TABLE_NAME=ALL_CORE_TABLES
CHECK_MASK=ALL

Run Findings And Recommendations
Finding
Finding Name  : Dictionary Inconsistency
Finding ID : 212302
Type       : FAILURE
Status       : OPEN
Priority    : CRITICAL
Message    : SQL dictionary health check: file$ pk 42 on object FILE$
            failed
Message    : Damaged rowid is AAAAARAABAAAADpAAC - description: No further
            damage description available
Finding
Finding Name  : Dictionary Inconsistency
Finding ID : 212305
Type       : FAILURE
Status       : OPEN
Priority    : CRITICAL
Message    : SQL dictionary health check: file$ pk 42 on object FILE$
            failed
Message    : Damaged rowid is AAAAARAABAAAADpAAE - description: No further
            damage description available
Finding
Finding Name  : Dictionary Inconsistency
Finding ID : 212308
Type       : FAILURE
Status       : OPEN
Priority    : CRITICAL
Message    : SQL dictionary health check: file$ pk 42 on object FILE$
            failed
Message    : Damaged rowid is AAAAARAABAAAADpAAf - description: No further
            damage description available
Finding
Finding Name  : Dictionary Inconsistency
Finding ID : 212311
Type       : FAILURE
Status       : OPEN
Priority    : CRITICAL
Message    : SQL dictionary health check: syn$.owner fk 95 on object SYN$
            failed
Message    : Damaged rowid is AAAABEAABAAANoJACi - description: Synonymn
            REPREPORT is referenced
Finding
Finding Name  : Dictionary Inconsistency
Finding ID : 212314
Type       : FAILURE
Status       : OPEN
Priority    : CRITICAL
Message    : SQL dictionary health check: syn$.owner fk 95 on object SYN$
            failed
Message    : Damaged rowid is AAAABEAABAAANoJACk - description: Synonymn
            REPREPORT is referenced
Finding
Finding Name  : Dictionary Inconsistency
Finding ID : 212317
Type       : FAILURE
Status       : OPEN
Priority    : CRITICAL
Message    : SQL dictionary health check: syn$.owner fk 95 on object SYN$
            failed
Message    : Damaged rowid is AAAABEAABAAANoJACm - description: Synonymn
            REPREPORT is referenced

SQL> SELECT DBMS_HM.GET_RUN_REPORT('UNDO_CHECK1') from dual;

Basic Run Information
Run Name                   : undo_check1
Run Id                      : 212321
Check Name                : Undo Segment Integrity Check
Mode                      : MANUAL
Status                      : ERROR-NOT COMPLETED
Start Time                : 2012-04-30 22:24:14.131478 +08:00
End Time                   : 2012-04-30 22:24:14.151066 +08:00
Error Encountered          : 55565
Source Incident Id          : 0
Number of Incidents Created  : 0

Input Paramters for the Run
USN_NUMBER=162

Run Findings And Recommendations

dictionary health check 没有发现严重的数据字典讹误

回复只看该作者道具举报

32^#

发表于 2012-4-30 22:39:27

回复 31# 的帖子

针对于这种状况，如果不重建库严重吗？

回复只看该作者道具举报

33^#

发表于 2012-4-30 22:40:42

回复 32# 的帖子

HCKE-0036: Bad OBJ$ entry with TYPE#=0
OBJ$ OBJ#=109311 TYPE#=0 NAME=IF_WXAB01
OBJ$ OBJ#=74733 TYPE#=0 NAME=IF_WXAB01
OBJ$ OBJ#=88762 TYPE#=0 NAME=IF_WXAC01
OBJ$ OBJ#=108309 TYPE#=0 NAME=AC01

这些对象是否重要？
都是一些业务表，要问应用人员才知道

回复只看该作者道具举报

|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-15 14:26 , Processed in 0.060952 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部

TEL/電話+86 13764045638

Email service@parnassusdata.com

QQ 47079569