标签云
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,666)
- DB2 (22)
- MySQL (73)
- Oracle (1,528)
- Data Guard (51)
- EXADATA (8)
- GoldenGate (21)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (14)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (65)
- Oracle Bug (8)
- Oracle RAC (52)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (559)
- Oracle安装升级 (90)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (77)
- 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)
-
最近发表
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
- ORA-01092 ORA-00604 ORA-01558故障处理
- ORA-65088: database open should be retried
- Oracle 19c异常恢复—ORA-01209/ORA-65088
- ORA-600 16703故障再现
- 数据库启动报ORA-27102 OSD-00026 O/S-Error: (OS 1455)
- .[metro777@cock.li].Elbie勒索病毒加密数据库恢复
- 应用连接错误,初始化mysql数据库恢复
- RAC默认服务配置优先节点
- Oracle 19c RAC 替换私网操作
- 监听报TNS-12541 TNS-12560 TNS-00511错误
- drop tablespace xxx including contents恢复
- Linux 8 修改网卡名称
- 如何修改集群的公网信息(包括 VIP) (Doc ID 1674442.1)
- 如何在 oracle 集群环境下修改私网信息 (Doc ID 2103317.1)
- ORA-600 [kcvfdb_pdb_set_clean_scn: cleanckpt] 相关bug
- ORA-600 krhpfh_03-1210故障处理
标签归档:ORA-00600[25025]
记录一次比较棘手数据库恢复要点
在最近的一次数据库异常恢复过程中遇到不少问题,把重点记录下
ORA-00704/ORA-01555错误
Fri May 4 21:04:21 2012 select ctime, mtime, stime from obj$ where obj# = :1 Fri May 4 21:04:21 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1286288.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 ORA-01555: snapshot too old: rollback segment number 40 with name "_SYSSMU40$" too small Error 704 happened during db open, shutting down database USER: terminating instance due to error 704 Instance terminated by USER, pid = 1286288 ORA-1092 signalled during: alter database open resetlogs... 这里的提示可以看出obj$基表中有事务存在,查询这个表的时候,要去找40号回滚段中相关数据;通过非常规方法, 查找到40号回滚段的状态是offliine了(这个查询出来的信息和是否使用隐含参数无关). 问题原因,为什么40号回滚段变得offline? Fri May 4 17:36:26 2012 alter tablespace undotbs offline Fri May 4 17:36:26 2012 ORA-1109 signalled during: alter tablespace undotbs offline... Fri May 4 17:37:29 2012 alter database datafile '/dev/rundodbs01' offline drop Fri May 4 17:37:29 2012 Completed: alter database datafile '/dev/rundodbs01' offline drop 因为强制offline 了file# 2文件导致(一个undo表空间文件) 解决方法: 1.bbed提交事务 因为现在生产的trace文件中未有关于obj$ 未提交事务的记录,做10046也为发现该记录,如果要使用bbed修改该事务, 那需要dump obj$相关的数据块(在mount状态下dump),然后找到相关事务,再修改 2.强制让file# 2 online 因为在resetlogs前file#2 已经offline掉了,所以要使得该文件能够成功online,需要先推进scn
ORA-00600[krhpfh_03-1209]
SQL> recover database until cancel; ORA-00283: recovery session canceled due to errors ORA-00600: internal error code, arguments: [krhpfh_03-1209], [2], [782415504], [782428968], [3987078030], [2379], [0], [0] ORA-01110: data file 2: '/dev/rundodbs01' 问题原因: 数据库处于非归档模式下,连续三次resetlogs,引起该bug 解决办法: 重建控制文件 但是这里问题出现了,因为file# 2的resetlogs scn和其他数据文件不一致,导致在file# 2 online的前提下,无法重建. 这样就处在了一个循环中(需要online file# 2 又要重建控制文件),这样的问题,可以通过bbed修改file# 2的resetlogs scn完成 或者先让file# 2 offline(没有加drop)掉,重建控制文件(除掉file# 2的文件记录)
ORA-00600[25025]
SMON: enabling cache recovery Fri May 4 22:36:36 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1167402.trc: ORA-00600: internal error code, arguments: [25025], [2], [], [], [], [], [], [] Fri May 4 22:36:38 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1167402.trc: ORA-00600: internal error code, arguments: [25025], [2], [], [], [], [], [], [] Fri May 4 22:36:38 2012 Error 600 happened during db open, shutting down database USER: terminating instance due to error 600 Instance terminated by USER, pid = 1167402 错误原因: 因为有undo文件不在undo对应的表空间中,而我们的file# 2文件确实是undo文件,而且重建控制文件时候未加入进来 解决办法: undo_management = AUTO undo_tablespace = UNDODBS(file# 2属于该表空间) 修改为 undo_management = MANUAL undo_tablespace = SYSTEM 或者bbed修改file# 2的header,然后重建控制文件
ORA-00600[4137]
Errors in file /oracle/admin/standdb/bdump/perfdb_smon_1290564.trc: ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], [] Fri May 4 23:20:52 2012 create undo tablespace undotbs3 datafile '/dev/rundodbs21' size 20400M Fri May 4 23:23:47 2012 Errors in file /oracle/admin/standdb/bdump/perfdb_smon_1290564.trc: ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], [] Fri May 4 23:23:48 2012 Errors in file /oracle/admin/standdb/bdump/perfdb_pmon_1520126.trc: ORA-00474: SMON process terminated with error Fri May 4 23:23:48 2012 PMON: terminating instance due to error 474 Instance terminated by PMON, pid = 1520126 错误原因: _smon_internal_errlimit(limit of SMON internal errors) SMON遇到了内部错误,最大允许100次, 不断计数增长,达到100的时候,数据库smon进程自动down掉,从而导致数据库down 解决办法: 1.临时解决办法:设置_smon_internal_errlimit一个较大值 3.根本解决办法:使用undo隐含参数,删除有问题undo 回滚段和undo表空间或者使用10513 事件