标签云
asm 恢复 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 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)
- 操作系统 (100)
- 数据库 (1,598)
- DB2 (22)
- MySQL (70)
- Oracle (1,463)
- Data Guard (49)
- EXADATA (7)
- GoldenGate (21)
- ORA-xxxxx (158)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (13)
- ORACLE 21C (3)
- Oracle ASM (65)
- Oracle Bug (7)
- Oracle RAC (47)
- Oracle 安全 (6)
- Oracle 开发 (27)
- Oracle 监听 (27)
- Oracle备份恢复 (530)
- Oracle安装升级 (84)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (75)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (36)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (19)
-
最近发表
- PostgreSQL解析wal日志之—walminer
- Oracle 19c/21c最新patch信息-202404
- PostgreSQL恢复系列:pg_filedump批量处理
- PostgreSQL部分主要字典信息
- PostgreSQL恢复系列:pg_filedump恢复字典构造
- PostgreSQL 16 源码安装
- ORA-00742 ORA-00312 恢复
- 数据库open成功后报ORA-00353 ORA-00354错误引起的一系列问题(本质ntfs文件系统异常)
- ORA-600 ktsiseginfo1故障
- ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因
- 最近遇到几起ORA-600 16703故障(tab$被清空),请引起重视
- ORA-600 2662快速恢复之Patch scn工具
- TNS-12518: TNS:listener could not hand off client connection
- ora.storage无法启动报ORA-12514故障处理
- 断电引起文件scn异常数据库恢复
- ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
- .[hudsonL@cock.li].mkp勒索加密数据库完美恢复
- 模拟带库实现rman远程备份
- 又一例:ORA-600 kclchkblk_4和2662故障
- Oracle误删除数据文件恢复
月归档:七月 2014
记录一次ORA-600 3004 恢复过程和处理思路
10.1.0.2数据库在启动的时候报ORA-00600[3004]错误
SQL> startup ORACLE 例程已经启动。 Total System Global Area 1042254360 bytes Fixed Size 743960 bytes Variable Size 503316480 bytes Database Buffers 536870912 bytes Redo Buffers 1323008 bytes 数据库装载完毕。 ORA-00600: 内部错误代码,参数: [3004], [1], [0], [0], [], [], [], []
alert日志信息
Tue Jul 15 10:57:11 2014 Database mounted in Exclusive Mode. Completed: ALTER DATABASE MOUNT Tue Jul 15 10:57:12 2014 ALTER DATABASE OPEN Tue Jul 15 10:57:12 2014 Beginning crash recovery of 1 threads attempting to start a parallel recovery with 3 processes parallel recovery started with 3 processes Tue Jul 15 10:57:12 2014 Started first pass scan Tue Jul 15 10:57:12 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\udump\orcl_ora_1084.trc: ORA-00600: 内部错误代码, 参数: [3004], [1], [0], [0], [], [], [], [] Tue Jul 15 10:57:13 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\bdump\orcl_p000_3780.trc: ORA-10388: parallel query server interrupt (failure) Tue Jul 15 10:57:13 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\bdump\orcl_p002_3420.trc: ORA-10388: parallel query server interrupt (failure) Tue Jul 15 10:57:14 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\bdump\orcl_p001_3784.trc: ORA-10388: parallel query server interrupt (failure) Tue Jul 15 10:57:14 2014 Aborting crash recovery due to error 600 Tue Jul 15 10:57:14 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\udump\orcl_ora_1084.trc: ORA-00600: 内部错误代码, 参数: [3004], [1], [0], [0], [], [], [], [] ORA-600 signalled during: ALTER DATABASE OPEN...
根据老杨的blog,出现该问题,很可能是crontrolfile异常导致,所以这里可以考虑通过重建控制文件或者把当前控制文件当作备份控制文件来使用
Tue Jul 15 13:42:31 2014 ALTER DATABASE RECOVER database using backup controlfile Tue Jul 15 13:42:31 2014 Media Recovery Start WARNING! Recovering data file 1 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 2 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 3 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 4 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 5 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 6 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 7 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 8 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 9 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 10 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 11 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command. attempting to start a parallel recovery with 3 processes parallel recovery started with 3 processes Starting datafile 1 with incarnation depth 0 in thread 1 sequence 794 Datafile 1: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\SYSTEM01.DBF' Starting datafile 2 with incarnation depth 0 in thread 1 sequence 794 Datafile 2: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\UNDOTBS01.DBF' Starting datafile 3 with incarnation depth 0 in thread 1 sequence 794 Datafile 3: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\SYSAUX01.DBF' Starting datafile 4 with incarnation depth 0 in thread 1 sequence 794 Datafile 4: 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\USERS01.DBF' Starting datafile 5 with incarnation depth 0 in thread 1 sequence 794 Datafile 5: 'E:\ORADB\USER1_1.ORA' Starting datafile 6 with incarnation depth 0 in thread 1 sequence 794 Datafile 6: 'E:\ORADB\USER1_2.ORA' Starting datafile 7 with incarnation depth 0 in thread 1 sequence 794 Datafile 7: 'E:\ORADB\USER1_3.ORA' Starting datafile 8 with incarnation depth 0 in thread 1 sequence 794 Datafile 8: 'E:\ORADB\USER1_4.ORA' Starting datafile 9 with incarnation depth 0 in thread 1 sequence 794 Datafile 9: 'E:\ORADB\INDEX1_1.ORA' Starting datafile 10 with incarnation depth 0 in thread 1 sequence 794 Datafile 10: 'E:\ORADB\INDEX1_2.ORA' Starting datafile 11 with incarnation depth 0 in thread 1 sequence 794 Datafile 11: 'E:\ORADB\TEMP1_1.ORA' Media Recovery Log ORA-279 signalled during: ALTER DATABASE RECOVER database using backup cont... Tue Jul 15 13:43:03 2014 ALTER DATABASE RECOVER LOGFILE 'D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO01.LOG' Tue Jul 15 13:43:03 2014 Media Recovery Log D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO01.LOG Completed: ALTER DATABASE RECOVER LOGFILE 'D:\ORACLE\PRODU Tue Jul 15 13:43:17 2014 alter database open resetlogs RESETLOGS after complete recovery through change 3142208 Resetting resetlogs activation ID 1378452168 (0x522982c8) Setting recovery target incarnation to 3 Tue Jul 15 13:43:18 2014 Setting recovery target incarnation to 3 Tue Jul 15 13:43:18 2014 Flashback Database Disabled Tue Jul 15 13:43:19 2014 Assigning activation ID 1380750902 (0x524c9636) Maximum redo generation record size = 120832 bytes Maximum redo generation change vector size = 116476 bytes Private_strands 7 at log switch Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO01.LOG Successful open of redo thread 1 Tue Jul 15 13:43:19 2014 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Tue Jul 15 13:43:19 2014 SMON: enabling cache recovery Tue Jul 15 13:43:20 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\udump\orcl_ora_1484.trc: ORA-00600: 内部错误代码, 参数: [2662], [0], [3142214], [0], [3142438], [8388617], [], [] Tue Jul 15 13:43:21 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\udump\orcl_ora_1484.trc: ORA-00600: 内部错误代码, 参数: [2662], [0], [3142214], [0], [3142438], [8388617], [], [] Tue Jul 15 13:43:21 2014 Error 600 happened during db open, shutting down database USER: terminating instance due to error 600
这里出现ORA-600[2662]因为scn相差较小,直接重启几次,然后数据库出现如下启动正常但是出现ORA-01595和ORA-00600[4194]错误
Tue Jul 15 13:48:26 2014 Starting background process MMON Starting background process MMNL MMON started with pid=17, OS id=2896 MMNL started with pid=18, OS id=3828 Tue Jul 15 13:48:26 2014 Block recovery completed at rba 2.90.16, scn 0.3162303 Tue Jul 15 13:48:26 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\bdump\orcl_smon_3724.trc: ORA-01595: error freeing extent (3) of rollback segment (1)) ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [57], [6], [], [], [], [], [] Tue Jul 15 13:48:26 2014 Completed: alter database open Tue Jul 15 13:48:27 2014 Errors in file d:\oracle\product\10.1.0\admin\orcl\bdump\orcl_j000_2956.trc: ORA-00600: internal error code, arguments: [4193], [1375], [1379], [], [], [], [], []
通过设置undo_management=manual,重建undo表空间解决,至此本数据库恢复完成,建议对其进行逻辑方式重建
误drop tablespace后使用flashback database闪回异常处理
有朋友夜间打电话请求技术支持,数据库表空间被删除,然后使用flashback database 无法正常恢复。通过分析alert日志发现,创建表空间(xifenfei 别名),发现已经存在,就删除了该表空间(其实是业务核心表空间,误删除了,是否是连接错了数据库?)
Sat Jul 05 17:10:06 2014 create tablespace XIFENFEI datafile 'D:\Oracle\oradata\orcl\HANDBB.DBF' size 50M autoextend on next 50M maxsize 1536M extent management local Sat Jul 05 17:10:06 2014 ORA-1543 signalled during: create tablespace XIFENFEI datafile 'D:\Oracle\oradata\orcl\HANDBB.DBF' size 50M autoextend on next 50M maxsize 1536M extent management local ... Sat Jul 05 17:10:59 2014 drop tablespace XIFENFEI Sat Jul 05 17:10:59 2014 ORA-1549 signalled during: drop tablespace XIFENFEI ... Sat Jul 05 17:11:05 2014 drop tablespace XIFENFEI ORA-1549 signalled during: drop tablespace XIFENFEI ... Sat Jul 05 17:11:24 2014 drop tablespace XIFENFEI including contents Sat Jul 05 17:11:36 2014 Thread 1 advanced to log sequence 186895 (LGWR switch) Current log# 1 seq# 186895 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\GZSERVER\REDO01.LOG Sat Jul 05 17:11:36 2014 ARC3: Warning. Log sequence in archive filename wrapped to fix length as indicated by %S in LOG_ARCHIVE_FORMAT. Old log archive with same name might be overwritten. Sat Jul 05 17:11:43 2014 LNS: Standby redo logfile selected for thread 1 sequence 186895 for destination LOG_ARCHIVE_DEST_4 Sat Jul 05 17:11:49 2014 LNS: Standby redo logfile selected for thread 1 sequence 186895 for destination LOG_ARCHIVE_DEST_2 Sat Jul 05 17:12:09 2014 Starting control autobackup Control autobackup written to DISK device handle 'D:\FULLBACK\C-1342406147-20140705-00' Completed: drop tablespace XIFENFEI including contents
通过这里可以发现删除表空间时间点为2014年7月5日17:12:09
闪回数据库到删除之前时间点
Sat Jul 05 18:16:54 2014 Database mounted in Exclusive Mode Completed: ALTER DATABASE MOUNT Sat Jul 05 18:19:23 2014 FLASHBACK DATABASE TO TIMESTAMP TO_TIMESTAMP('2014-07-05 17:09:00','YYYY-MM-DD HH24:MI:SS') Sat Jul 05 18:19:25 2014 Flashback Restore Start Sat Jul 05 18:20:52 2014 --闪回时的控制文件中无表空间XIFENFEI信息(因为已经被删除), --但是由于闪回的system 数据字典里面有相关文件信息,因此数据库在控制文件里面创建相关文件信息 Flashback: created tablespace #6: 'XIFENFEI' in the controlfile. Flashback: created OFFLINE file 'UNNAMED00012' for tablespace #6 in the controlfile. Filename was: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\GZSERVER\XIFENFEI4.DBF' when dropped. File will have to be restored from a backup and recovered. Flashback: created OFFLINE file 'UNNAMED00010' for tablespace #6 in the controlfile. Filename was: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\GZSERVER\XIFENFEI3.DBF' when dropped. File will have to be restored from a backup and recovered. Flashback: created OFFLINE file 'UNNAMED00008' for tablespace #6 in the controlfile. Filename was: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\GZSERVER\XIFENFEI2.DBF' when dropped. File will have to be restored from a backup and recovered. Flashback: created OFFLINE file 'UNNAMED00005' for tablespace #6 in the controlfile. Filename was: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\GZSERVER\XIFENFEI.DBF' when dropped. File will have to be restored from a backup and recovered. Flashback Restore Complete Flashback Media Recovery Start parallel recovery started with 15 processes Flashback Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ORADATA\ARCHIVE\ARC\ARC86891_0766797318.001 Flashback Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ORADATA\ARCHIVE\ARC\ARC86892_0766797318.001 Sat Jul 05 18:21:40 2014 Flashback Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ORADATA\ARCHIVE\ARC\ARC86893_0766797318.001 Sat Jul 05 18:21:47 2014 WARNING: inbound connection timed out (ORA-3136) Sat Jul 05 18:22:11 2014 Recovery of Online Redo Log: Thread 1 Group 3 Seq 186894 Reading mem 0 Mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\GZSERVER\REDO03.LOG Sat Jul 05 18:22:39 2014 Incomplete Recovery applied until change 9078991241 Flashback Media Recovery Complete ORA-38795 signalled during: FLASHBACK DATABASE TO TIMESTAMP TO_TIMESTAMP('2014-07-05 17:09:00','YYYY-MM-DD HH24:MI:SS')... Sat Jul 05 18:30:11 2014 ALTER DATABASE OPEN RESETLOGS Sat Jul 05 18:30:11 2014 ORA-1245 signalled during: ALTER DATABASE OPEN RESETLOGS... --重命名相关UNNAMExxxxx文件名到硬盘上被删除表空间文件 Sat Jul 05 18:39:31 2014 alter database rename file 'D:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00005' to 'D:\oracle\product\10.2.0\oradata\gzserver\XIFENFEI.DBF' Sat Jul 05 18:39:31 2014 Completed: alter database rename file 'D:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00005' to 'D:\oracle\product\10.2.0\oradata\gzserver\XIFENFEI.DBF' Sat Jul 05 18:39:47 2014 alter database rename file 'D:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00008' to 'D:\oracle\product\10.2.0\oradata\gzserver\XIFENFEI2.DBF' Sat Jul 05 18:39:47 2014 Completed: alter database rename file 'D:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00008' to 'D:\oracle\product\10.2.0\oradata\gzserver\XIFENFEI2.DBF' Sat Jul 05 18:39:59 2014 alter database rename file 'D:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00010' to 'D:\oracle\product\10.2.0\oradata\gzserver\XIFENFEI3.DBF' Sat Jul 05 18:39:59 2014 Completed: alter database rename file 'D:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00010' to 'D:\oracle\product\10.2.0\oradata\gzserver\XIFENFEI3.DBF' Sat Jul 05 18:40:12 2014 alter database rename file 'D:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00012' to 'D:\oracle\product\10.2.0\oradata\gzserver\XIFENFEI4.DBF' Sat Jul 05 18:40:12 2014 Completed: alter database rename file 'D:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00012' to 'D:\oracle\product\10.2.0\oradata\gzserver\XIFENFEI4.DBF' Sat Jul 05 18:41:25 2014 ALTER DATABASE OPEN RESETLOGS Sat Jul 05 18:41:25 2014 ORA-1245 signalled during: ALTER DATABASE OPEN RESETLOGS...
到这里,可以看出来,因为数据库整体已经闪回,但是被drop 表空间的四个数据文件未被正常闪回,因此该四个文件的scn可能异常,通过数据库恢复检查脚本(Oracle Database Recovery Check)检查结果如下
这里很明显控制文件中的scn信息混乱不做过多参考,数据文件头信息看到只有ts# 6中的四个文件(就是被删除的表空间文件)scn过大,其他文件scn都处于正常状态(处于干净状态),到这里很明显,数据库闪回成功,但是被drop tablespace的数据文件未被闪回,因此该故障可以通过bbed修改四个文件头信息和其他文件相同即可使得数据库恢复正常
温馨提示:数据库操作需要慎重,备份重于一切