标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,682)
- DB2 (22)
- MySQL (73)
- Oracle (1,544)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (67)
- Oracle Bug (8)
- Oracle RAC (53)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (565)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (79)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理
- ORA-00227: corrupt block detected in control file
- 手工删除19c rac
- 解决oracle数据文件路径有回车故障
- .wstop扩展名勒索数据库恢复
- Oracle Recovery Tools工具一键解决ORA-00376 ORA-01110故障(文件offline)
- OGG-02771 Input trail file format RELEASE 19.1 is different from previous trail file form at RELEASE 11.2.
- OGG-02246 Source redo compatibility level 19.0.0 requires trail FORMAT 12.2 or higher
- GoldenGate 19安装和打patch
- dd破坏asm磁盘头恢复
- 删除asmlib磁盘导致磁盘组故障恢复
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
标签归档:ORA-600 13013
记录一次system表空间坏块(ORA-01578)数据库恢复
半夜朋友打来求救电话,说xx医院his系统因为存储异常导致system坏块无法正常启动,因为是win平台无法使用bbed,无法修复system 坏块,请求技术支持
dbv检查system文件报坏块
对应具体地址为:file 1 block 39041和66738
判断控制文件异常
通过数据库恢复检查脚本(Oracle Database Recovery Check)脚本检测数据库发现控制文件明显异常(checkpoint scn
尝试恢复数据库
因此对该库进行了不完全恢复,然后尝试resetlogs打开数据库,数据库报ORA-600 2662错误
Fri Aug 29 02:35:08 2014 alter database open resetlogs Fri Aug 29 02:35:11 2014 RESETLOGS after complete recovery through change 451371288 Resetting resetlogs activation ID 1232269761 (0x4972f1c1) Fri Aug 29 02:35:15 2014 Setting recovery target incarnation to 3 Fri Aug 29 02:35:15 2014 Assigning activation ID 1384652231 (0x52881dc7) LGWR: STARTING ARCH PROCESSES ARC0 started with pid=17, OS id=1084 Fri Aug 29 02:35:15 2014 ARC0: Archival started ARC1: Archival started LGWR: STARTING ARCH PROCESSES COMPLETE ARC1 started with pid=18, OS id=2836 Fri Aug 29 02:35:15 2014 Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: Z:\ORACLE\PRODUCT\10.2.0\ORCL\REDO01.LOG Successful open of redo thread 1 Fri Aug 29 02:35:15 2014 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Fri Aug 29 02:35:15 2014 ARC1: Becoming the 'no FAL' ARCH ARC1: Becoming the 'no SRL' ARCH Fri Aug 29 02:35:15 2014 ARC0: Becoming the heartbeat ARCH Fri Aug 29 02:35:15 2014 SMON: enabling cache recovery Fri Aug 29 02:35:16 2014 Errors in file d:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4824.trc: ORA-00600: 内部错误代码, 参数: [2662], [0], [451371311], [0], [451374534], [8388977], [], [] Fri Aug 29 02:35:16 2014 Errors in file d:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4824.trc: ORA-00600: 内部错误代码, 参数: [2662], [0], [451371311], [0], [451374534], [8388977], [], [] Fri Aug 29 02:35:16 2014 Error 600 happened during db open, shutting down database USER: terminating instance due to error 600 Fri Aug 29 02:35:17 2014 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_2928.trc: ORA-00600: ??????, ??: [], [], [], [], [], [], [], [] Instance terminated by USER, pid = 4824 ORA-1092 signalled during: alter database open resetlogs...
ORA-600 2662 该错误解决思路很明显,推进scn,数据库报ORA-01578
Fri Aug 29 02:42:47 2014 SMON: enabling cache recovery Fri Aug 29 02:42:47 2014 Successfully onlined Undo Tablespace 1. Dictionary check beginning Dictionary check complete Fri Aug 29 02:42:49 2014 SMON: enabling tx recovery Fri Aug 29 02:42:49 2014 Database Characterset is ZHS16GBK Opening with internal Resource Manager plan where NUMA PG = 1, CPUs = 16 replication_dependency_tracking turned off (no async multimaster replication found) Fri Aug 29 02:42:50 2014 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_4804.trc: ORA-00604: 递归 SQL 级别 1 出现错误 ORA-01578: ORACLE 数据块损坏 (文件号 1, 块号 39041) ORA-01110: 数据文件 1: 'Z:\ORACLE\PRODUCT\10.2.0\ORCL\SYSTEM01.DBF' Fri Aug 29 02:42:50 2014 LOGSTDBY: Validating controlfile with logical metadata Fri Aug 29 02:42:51 2014 LOGSTDBY: Validation complete ORA-604 signalled during: alter database open...
对坏块进行处理,启动数据库成功
Fri Aug 29 02:48:59 2014 SMON: enabling cache recovery Fri Aug 29 02:49:00 2014 Successfully onlined Undo Tablespace 1. Fri Aug 29 02:49:00 2014 SMON: enabling tx recovery Fri Aug 29 02:49:00 2014 Database Characterset is ZHS16GBK Opening with internal Resource Manager plan where NUMA PG = 1, CPUs = 16 replication_dependency_tracking turned off (no async multimaster replication found) Starting background process QMNC QMNC started with pid=34, OS id=3096 Fri Aug 29 02:49:01 2014 db_recovery_file_dest_size of 4096 MB is 0.00% used. This is a user-specified limit on the amount of space that will be used by this database for recovery-related files, and does not reflect the amount of space available in the underlying filesystem or ASM diskgroup. Fri Aug 29 02:49:01 2014 Completed: alter database open
查询坏块对象
因为这些对象均不是核心对象,直接进行truncate然后插入老数据
后续还有大量错误修复
ORA-12012: error on auto execute of job 1 ORA-08102: index key not found, obj# 239, file 1, block 1674 (2) ORA-00600: 内部错误代码, 参数: [kcbz_check_objd_typ], [0], [0], [1], [], [], [], [] ORA-00600: internal error code, arguments: [6749], [3], [12606796], [173], [], [], [], [] ORA-00600: 内部错误代码, 参数: [13013], [52898], [52895], [38288618], [44], [38288618], [17], [] ORA-00600: 内部错误代码, 参数: [13013], [5001], [52895], [38286476], [5], [38286476], [17], []
再次说明,很多时候数据库恢复不要看成多神秘,就是几个参数搞定,更加不要神化有坏块就bbed修复,当然非常极端,使用N中工具,N种尝试的也存在.做好备份重于一切
发表在 Oracle备份恢复
标签为 ORA-01578, ORA-600 13011, ORA-600 13013, ORA-600 2662, ORA-600 6749, ORACLE恢复, system坏块
评论关闭
记录另一起ORA-00600[13013]处理
发现ORA-00600[13013]错误
During the execution of an UPDATE statement, after several attempts (Arg [a] passcount) we are unable to get a stable set of rows that conform to the WHERE clause.
Fri Jun 1 03:00:33 2012 Errors in file /opt/oracle/admin/oraapp/bdump/oraapp_m000_12104.trc: ORA-00600: internal error code, arguments: [13013], [5001], [8943], [12596577], [25], [12596578], [17], [] Sat Jun 2 03:01:05 2012 Errors in file /opt/oracle/admin/oraapp/bdump/oraapp_m000_1052.trc: ORA-00600: internal error code, arguments: [13013], [5001], [8943], [12596577], [25], [12596578], [17], [] Sun Jun 3 15:00:50 2012 Errors in file /opt/oracle/admin/oraapp/bdump/oraapp_m000_13876.trc: ORA-00600: internal error code, arguments: [13013], [5001], [8943], [12596577], [25], [12603219], [17], [] Mon Jun 4 03:01:05 2012 Errors in file /opt/oracle/admin/oraapp/bdump/oraapp_m000_7704.trc: ORA-00600: internal error code, arguments: [13013], [5001], [8943], [12596577], [25], [12596578], [17], [] Tue Jun 5 03:00:35 2012 Errors in file /opt/oracle/admin/oraapp/bdump/oraapp_m000_27983.trc: ORA-00600: internal error code, arguments: [13013], [5001], [8943], [12596577], [25], [12596578], [17], [] Wed Jun 6 03:01:07 2012 Errors in file /opt/oracle/admin/oraapp/bdump/oraapp_m000_19204.trc: ORA-00600: internal error code, arguments: [13013], [5001], [8943], [12596577], [25], [12596578], [17], [] Thu Jun 7 03:00:37 2012 Errors in file /opt/oracle/admin/oraapp/bdump/oraapp_m000_7273.trc: ORA-00600: internal error code, arguments: [13013], [5001], [8943], [12596577], [25], [12605556], [17], []
以前处理过一次ORA-600[13013],里面包含了各参数含义,这次也按照常规方法处理,分析如下:
1.通过trace文件找出对应表
*** 2012-06-01 03:00:33.325 ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [13013], [5001], [8943], [12596577], [25], [12596578], [17], [] Current SQL statement for this session: UPDATE WRH$_SQL_BIND_METADATA SET snap_id = :lah_snap_id WHERE dbid = :dbid AND (SQL_ID) IN (SELECT STR1_KEWRATTR FROM X$KEWRATTRSTALE)
2.通过ORA-600[13013]中表示rdba参数找出表
SQL> select DBMS_UTILITY.data_block_address_file (12596577) "file#", 2 DBMS_UTILITY.data_block_address_block (12596577) "block#" 3 from dual; file# block# ---------- ---------- 3 13665 SQL> select * from dba_extents where 13665 between block_id and block_id + blocks and file_id=3; OWNER SEGMENT_NAME SEGMENT_TYPE EXTENT_ID FILE_ID BLOCK_ID BLOCKS ---------- -------------------- --------------- --------------- ---------- ------- ------ SYS SYS_LOB0000008933C00 LOBSEGMENT 7 3 13657 8 SYS WRH$_SQL_BIND_METADA TABLE 1 3 13665 8
检查对象WRH$_SQL_BIND_METADA是否有坏块或者表和index不一致
SQL> analyze table SYS.WRH$_SQL_BIND_METADATA validate structure cascade online; Table analyzed.
这里分析WRH$_SQL_BIND_METADA表正常,但是通过上面的查询证明WRH$_SQL_BIND_METADA的第一个extent的第一个数据块上可能出现问题,使得analyze未检查(自己猜猜,未做深入验证).针对这个问题,直接备份WRH$_SQL_BIND_METADATA表,truncate掉该表,然后重新插入数据(注意操作时间避开awr插入数据时间段)
create table SQL_BIND_METADATA_BAK AS SELECT * FROM SYS.WRH$_SQL_BIND_METADATA; TRUNCATE TABLE SYS.WRH$_SQL_BIND_METADATA; INSERT INTO SYS.WRH$_SQL_BIND_METADATA SELECT * FROM SQL_BIND_METADATA_BAK; DROP TABBLE SQL_BIND_METADATA_BAK PURGE;
记录一次ORA-600[13013]处理过程
在一次数据库的异常处理完成后,发现alert日志中出现ORA-600[13013]错误
Thu Mar 08 23:29:37 2012 Errors in file /opt/oracle/diag/rdbms/chf/chf/trace/chf_smon_24137.trc (incident=38681): ORA-00600: internal error code, arguments: [13013], [5001], [518], [4198427], [170], [4198427], [17], [], [], [], [], [] Incident details in: /opt/oracle/diag/rdbms/chf/chf/incident/incdir_38681/chf_smon_24137_i38681.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Non-fatal internal error happenned while SMON was doing flushing of monitored table stats. SMON encountered 1 out of maximum 100 non-fatal internal errors.
trace文件中信息
从这里可以看出是对sys.col_usage$表进行update操作导致该错误发生
Dump continued from file: /opt/oracle/diag/rdbms/chf/chf/trace/chf_smon_24137.trc ORA-00600: internal error code, arguments: [13013], [5001], [518], [4198427], [170], [4198427], [17], [], [], [], [], [] ========= Dump for incident 38681 (ORA 600 [13013]) ======== *** 2012-03-08 23:29:37.400 dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0) ----- Current SQL Statement for this session (sql_id=3c1kubcdjnppq) ----- update sys.col_usage$ set equality_preds = equality_preds + decode(bitand(:flag,1),0,0,1), equijoin_preds = equijoin_preds + decode(bitand(:flag,2),0,0 ,1), nonequijoin_preds = nonequijoin_preds + decode(bitand(:flag,4),0,0,1), range_preds = range_preds + decode(bitand(:flag,8),0,0,1), like_preds = like_preds + decode(bitand(:flag,16),0,0,1), null_preds = null_preds + decode(bitand(:flag,32),0,0,1), timestamp = :time where obj# = :ob jn and intcol# = :coln
MOS中关于ORA-600 [13013]描述
Format: ORA-600 [13013] [a] [b] {c} [d] [e] [f] Arg [a] Passcount Arg [b] Data Object number Arg {c} Tablespace Decimal Relative DBA (RDBA) of block containing the row to be updated Arg [d] Row Slot number Arg [e] Decimal RDBA of block being updated (Typically same as {c}) Arg [f] Code
验证MOS中描述
SQL> select dbms_utility.data_block_address_file(4198427) rfile, 2 dbms_utility.data_block_address_block(4198427) blocks 3 from dual; RFILE BLOCKS ---------- ---------- 1 4123 SQL> SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME 2 FROM DBA_EXTENTS A 3 WHERE FILE_ID = &FILE_ID 4 AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1; Enter value for file_id: 1 old 3: WHERE FILE_ID = &FILE_ID new 3: WHERE FILE_ID = 1 Enter value for block_id: 4123 old 4: AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 new 4: AND 4123 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 OWNER SEGMENT_NAME SEGMENT_TY TABLESPACE PARTI ----- ------------ ---------- ---------- ----- SYS COL_USAGE$ TABLE SYSTEM --和trace文件中异常表一致 SQL> select object_type,object_name from dba_objects where object_id=518; OBJECT_TYPE OBJECT_NAME ------------------- ------------------------------ TABLE COL_USAGE$ --也和trace文件中异常表一致
分析异常表
SQL> ANALYZE TABLE sys.COL_USAGE$ VALIDATE STRUCTURE CASCADE; ANALYZE TABLE sys.COL_USAGE$ VALIDATE STRUCTURE CASCADE * ERROR at line 1: ORA-01499: table/index cross reference failure - see trace file SQL> select index_name,COLUMN_NAME,COLUMN_POSITION FROM DBA_IND_COLUMNS 2 WHERE TABLE_NAME='COL_USAGE$'; INDEX_NAME COLUMN_NAM COLUMN_POSITION --------------- ---------- --------------- I_COL_USAGE$ OBJ# 1 I_COL_USAGE$ INTCOL# 2 SQL> set autot trace exp SQL> SELECT /*+ FULL(t1) */ OBJ#,INTCOL# 2 FROM sys.COL_USAGE$ t1 3 MINUS 4 SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL# 5 FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null; no rows selected --无记录返回 Execution Plan ---------------------------------------------------------- Plan hash value: 399371572 ------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 4262 | 76716 | 27 (71)| 00:00:01 | | 1 | MINUS | | | | | | | 2 | SORT UNIQUE | | 4262 | 38358 | 9 (12)| 00:00:01 | | 3 | TABLE ACCESS FULL| COL_USAGE$ | 4262 | 38358 | 8 (0)| 00:00:01 | | 4 | SORT UNIQUE NOSORT| | 4262 | 38358 | 18 (6)| 00:00:01 | |* 5 | INDEX FULL SCAN | I_COL_USAGE$ | 4262 | 38358 | 17 (0)| 00:00:01 | ------------------------------------------------------------------------------------ --验证表两个sql是否正确(一个全表扫描,另个index 快速扫描) SQL> SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL# 2 FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null 3 MINUS 4 SELECT /*+ FULL(t1) */ OBJ#,INTCOL# 5 FROM sys.COL_USAGE$ t1; OBJ# INTCOL# ---------- ---------- 4294951004 2 4294951004 3 4294951004 4 4294951004 26 4294951004 27 4294951037 4 4294951037 5 4294951037 6 4294951037 9 4294951037 10 4294951840 11 OBJ# INTCOL# ---------- ---------- 4294951840 12 4294951906 4 4294952709 3 4294952867 4 4294952867 9 16 rows selected. --证明index中的记录比表中多了16条
解决问题并验证
SQL> alter index sys.I_COL_USAGE$ rebuild online; Index altered. SQL> SELECT /*+ FULL(t1) */ OBJ#,INTCOL# FROM sys.COL_USAGE$ t1 2 3 MINUS 4 SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL# 5 FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null 6 ; no rows selected SQL> SELECT /*+ index(t I_COL_USAGE$) */ OBJ#,INTCOL# 2 FROM sys.COL_USAGE$ t where OBJ# is not null or INTCOL# is not null 3 MINUS 4 SELECT /*+ FULL(t1) */ OBJ#,INTCOL# 5 FROM sys.COL_USAGE$ t1; no rows selected
这次出现此问题的原因是因为在更新语句中使用索引找到一条记录,然后到表中去查询时该记录不存在,出现此错误,一般解决方法是重建索引
官方关于ORA-600[13013]说明