标签云
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,671)
- DB2 (22)
- MySQL (73)
- Oracle (1,533)
- Data Guard (52)
- 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备份恢复 (560)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (78)
- 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)
-
最近发表
- 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-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恢复
分类目录归档:Oracle
数据库打patch建议设置nls_language为英文
昨晚给客户11.2.0.4打比较新的psu和ojvm patch(主要为了修复安全扫描漏洞)
结果今天早上客户那边反馈应用有报ORA-29548错
该错误比较明显应该是和java有关系,在本次变更中最大可能就是ojvm有关系,查看ojvm的postinstall.sql执行日志,发现如下问题
34 -- Check the validity of JAVAVM and let the registry be updated accordingly. 35 36 initjvmaux.validate_javavm; 37 38 -- Add a row in registry$history to indicate this script was run. 39 40 EXECUTE IMMEDIATE 'insert into registry$history 41 (action_time, action, namespace, version, id, comments) 42 values(SYSTIMESTAMP, ''jvmpsu.sql'', ''SERVER'', 43 ''11.2.0.4.221018OJVMPSU'', 0, ''RAN jvmpsu.sql'')'; 44 45 END IF; 46 47 EXECUTE IMMEDIATE 'alter system set java_jit_enabled = ' || :jitstate; 48 49 END; 50 / BEGIN * 第 1 行出现错误: ORA-01843: 无效的月份 ORA-06512: 在 line 8
查询组件有效性
SQL> select comp_name,version,status from dba_registry order by 1; COMP_NAME -------------------------------------------------------------------------------- VERSION STATUS ------------------------------ ---------------------- JServer JAVA Virtual Machine 11.2.0.4.0 INVALID OLAP Analytic Workspace 11.2.0.4.0 VALID OLAP Catalog 11.2.0.4.0 VALID COMP_NAME -------------------------------------------------------------------------------- VERSION STATUS ------------------------------ ---------------------- OWB 11.2.0.1.0 VALID Oracle Application Express 3.2.1.00.10 VALID Oracle Database Catalog Views 11.2.0.4.0 VALID COMP_NAME -------------------------------------------------------------------------------- VERSION STATUS ------------------------------ ---------------------- Oracle Database Java Packages 11.2.0.4.0 VALID Oracle Database Packages and Types 11.2.0.4.0 VALID Oracle Enterprise Manager 11.2.0.4.0 VALID COMP_NAME -------------------------------------------------------------------------------- VERSION STATUS ------------------------------ ---------------------- Oracle Expression Filter 11.2.0.4.0 VALID Oracle Multimedia 11.2.0.4.0 VALID Oracle OLAP API 11.2.0.4.0 VALID COMP_NAME -------------------------------------------------------------------------------- VERSION STATUS ------------------------------ ---------------------- Oracle Rules Manager 11.2.0.4.0 VALID Oracle Text 11.2.0.4.0 VALID Oracle Workspace Manager 11.2.0.4.0 VALID COMP_NAME -------------------------------------------------------------------------------- VERSION STATUS ------------------------------ ---------------------- Oracle XDK 11.2.0.4.0 VALID Oracle XML Database 11.2.0.4.0 VALID Spatial 11.2.0.4.0 VALID 已选择18行。
确认JServer JAVA Virtual Machine组件无效,很可能是ojvm的postinstall.sql执行失败有关系,而引起这个失败的原因是由于“ORA-01843: 无效的月份”,根据经验,引起这个问题的可能是由于win汉语环境中日期/时间的显示格式导致
SQL> select sysdate from dual; SYSDATE -------------- 03-12月-23
设置为英文格式显示
SQL> alter session set nls_language='American'; Session altered. SQL> select sysdate from dual; SYSDATE ------------ 03-DEC-23
重新执行postdeinstall和postinstall脚本之后,组件状态恢复正常,软件功能也恢复正常
SQL> select comp_name,version,status from dba_registry order by 1; JServer JAVA Virtual Machine 11.2.0.4.0 VALID OLAP Analytic Workspace 11.2.0.4.0 VALID OLAP Catalog 11.2.0.4.0 VALID OWB 11.2.0.1.0 VALID Oracle Application Express 3.2.1.00.10 VALID Oracle Database Catalog Views 11.2.0.4.0 VALID Oracle Database Java Packages 11.2.0.4.0 VALID Oracle Database Packages and Types 11.2.0.4.0 VALID Oracle Enterprise Manager 11.2.0.4.0 VALID Oracle Expression Filter 11.2.0.4.0 VALID Oracle Multimedia 11.2.0.4.0 VALID Oracle OLAP API 11.2.0.4.0 VALID Oracle Rules Manager 11.2.0.4.0 VALID Oracle Text 11.2.0.4.0 VALID Oracle Workspace Manager 11.2.0.4.0 VALID Oracle XDK 11.2.0.4.0 VALID Oracle XML Database 11.2.0.4.0 VALID Spatial 11.2.0.4.0 VALID 18 rows selected.
自此提醒由于oracle 环境语言默认显示的问题导致某些patch不能正常打成功,建议在执行数据库patch或者升级之时,把数据库语言环境调整为英文nls_language=’American’,以避免本次出现的不必要的麻烦(以前由于大部分客户没有是使用jvm这个功能组件因此没有暴露该问题)
DBV-00107: Unknown header format 故障处理
客户linux平台被勒索病毒加密,其中有oracle数据库.客户联系黑客进行解密【勒索解密oracle失败】,但是数据库无法正常启动,dbv检查数据库文件报错
[oracle@hisdb ~]$ dbv file=system01.dbf DBVERIFY: Release 11.2.0.1.0 - Production on 星期一 11月 27 21:49:17 2023 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. DBV-00107: 未知标头格式 (31) (287942924)
对应的英文为:DBV-00107: Unknown header format (31) (287942924),检查数据文件信息发现提示为 FILE NOT FOUND,使用脚本为:Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)检测结果
通过分区确认是文件头损坏
修复正确的文件头
再次dbv检查数据文件
[oracle@hisdb ~]$ dbv file=system01.dbf DBVERIFY: Release 11.2.0.1.0 - Production on 星期一 11月 27 22:05:41 2023 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = /u01/app/oracle/oradata/system01.dbf 页 12800 标记为损坏 Corrupt block relative dba: 0x00403200 (file 1, block 12800) Bad header found during dbv: Data in bad block: type: 88 format: 1 rdba: 0x33877808 last change scn: 0x257a.7b3a44e3 seq: 0xe8 flg: 0xe6 spare1: 0x4e spare2: 0x73 spare3: 0x0 consistency value in tail: 0x65251001 check value in block header: 0xc3b4 computed block checksum: 0x4ca7 DBVERIFY - 验证完成 检查的页总数: 13440 处理的页总数 (数据): 3297 失败的页总数 (数据): 0 处理的页总数 (索引): 2097 失败的页总数 (索引): 0 处理的页总数 (其他): 1441 处理的总页数 (段) : 1 失败的总页数 (段) : 0 空的页总数: 6604 标记为损坏的总页数: 1 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 1667927064 (12.1667927064)
修复其他文件头,并dbv检查,发现均在12800位置损坏.尝试recover database恢复数据库,报ORA-00742 ORA-00312之类错误.【由于redo损坏,报出来数据文件更多坏块】
Sat Nov 25 17:03:39 2023 ALTER DATABASE RECOVER database Media Recovery Start started logmerger process Parallel Media Recovery started with 40 slaves Sat Nov 25 17:03:40 2023 Recovery of Online Redo Log: Thread 1 Group 7 Seq 27220 Reading mem 0 Mem# 0: /u01/app/oracle/oradata/redo07.log Sat Nov 25 17:03:41 2023 Hex dump of (file 3, block 7) in trace file /u01/app/oracle/diag/rdbms/his/his/trace/his_pr0l_52669.trc Corrupt block relative dba: 0x00c00007 (file 3, block 7) Bad header found during media recovery Data in bad block: type: 124 format: 7 rdba: 0x1698b845 last change scn: 0x4fa1.3eaa638f seq: 0x6 flg: 0x24 spare1: 0x26 spare2: 0x42 spare3: 0x0 consistency value in tail: 0xa39e1e01 check value in block header: 0x2ca4 computed block checksum: 0x3b25 Reading datafile '/u01/app/oracle/oradata/undotbs01.dbf' for corruption at rdba: 0x00c00007 (file 3, block 7) Reread (file 3, block 7) found same corrupt data (no logical check) Sat Nov 25 17:03:41 2023 Hex dump of (file 46, block 3) in trace file /u01/app/oracle/diag/rdbms/his/his/trace/his_pr0w_52691.trc Corrupt block relative dba: 0x0b800003 (file 46, block 3) Bad header found during media recovery Data in bad block: type: 7 format: 7 rdba: 0x77922022 last change scn: 0xdff3.c40df5b6 seq: 0x6f flg: 0xe5 spare1: 0xcd spare2: 0x6d spare3: 0x83d7 consistency value in tail: 0x63c63d2c check value in block header: 0xf662 computed block checksum: 0xec49 Data in bad block: type: 135 format: 4 rdba: 0x45ad2864 last change scn: 0x9d7e.34949c73 seq: 0x32 flg: 0x3e spare1: 0x89 spare2: 0x0 spare3: 0x9f9f consistency value in tail: 0xa5807800 check value in block header: 0xb2c9 computed block checksum: 0x3aea Reread (file 5, block 11259) found same corrupt data (no logical check) type: 214 format: 1 rdba: 0x0228dbe9 Bad header found during media recovery last change scn: 0xed57.ca4f7559 seq: 0x9b flg: 0x4a Data in bad block: spare1: 0x97 spare2: 0x77 spare3: 0x2bab type: 33 format: 6 rdba: 0x018d584a consistency value in tail: 0x359f90d6 last change scn: 0xaeb8.2fa361eb seq: 0x60 flg: 0x92 check value in block header: 0x6b26 spare1: 0xea spare2: 0xe spare3: 0xb405 block checksum disabled Reread (file 3, block 4) found same corrupt data (no logical check) Corrupt block relative dba: 0x0b800e61 (file 46, block 3681) Bad header found during media recovery Data in bad block: type: 131 format: 6 rdba: 0xc7edd0fc last change scn: 0xd319.d0e54941 seq: 0x6f flg: 0x6d spare1: 0xe7 spare2: 0x82 spare3: 0x439f consistency value in tail: 0x18dc47b6 check value in block header: 0xe9c8 computed block checksum: 0x204d Reread (file 46, block 3681) found same corrupt data (no logical check) Hex dump of (file 1, block 2017) in trace file /u01/app/oracle/diag/rdbms/his/his/trace/his_pr10_52699.trc Corrupt block relative dba: 0x004007e1 (file 1, block 2017) Bad header found during media recovery Data in bad block: type: 159 format: 2 rdba: 0x52c5b2b0 last change scn: 0x2ed8.e0bc5af9 seq: 0x62 flg: 0xe9 spare1: 0x81 spare2: 0x1e spare3: 0xda98 consistency value in tail: 0xc5753dd3 check value in block header: 0x2bba block checksum disabled Reading datafile '/u01/app/oracle/oradata/system01.dbf' for corruption at rdba: 0x004007e1 (file 1, block 2017) Reread (file 1, block 2017) found same corrupt data (no logical check) Media Recovery failed with error 742 Errors in file /u01/app/oracle/diag/rdbms/his/his/trace/his_pr00_52622.trc: ORA-00283: recovery session canceled due to errors ORA-00742: Log read detects lost write in thread %d sequence %d block %d ORA-00312: online log 7 thread 1: '/u01/app/oracle/oradata/redo07.log' ORA-10877 signalled during: ALTER DATABASE RECOVER database ...
尝试强制打开数据库报ORA-600 krsi_al_hdr_update.15,参考:Oracle断电故障处理中有类似报错
SQL> alter database open resetlogs; alter database open resetlogs * ERROR at line 1: ORA-00600: internal error code, arguments: [krsi_al_hdr_update.15], [4294967295], [], [], [], [], [], [], [], [], [], []
由于redo问题无法resetlogs成功,解决异常redo,再次尝试open库,由于undo坏块无法open成功,报ORA-01092 ORA-01578等错误
SQL> alter database open resetlogs; alter database open resetlogs * ERROR at line 1: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-01578: ORACLE data block corrupted (file # 3, block # 1848) ORA-01110: data file 3: '/u01/app/oracle/oradata/undotbs01.dbf' Process ID: 55655 Session ID: 2623 Serial number: 5
解决undo异常,数据库open成功.导出客户需要数据,完成此次恢复工作
ORA-1200/ORA-1207数据库恢复
由于系统性能问题或者底层io问题,数据库alert日志报一下控制文件损坏错误然后crash掉
Mon Nov 13 08:06:44 2023 Thread 1 advanced to log sequence 12100 (LGWR switch) Current log# 1 seq# 12100 mem# 0: /u01/oracle/oradata/xifenfei/redo01.log Mon Nov 13 09:23:59 2023 ********************* ATTENTION: ******************** The controlfile header block returned by the OS has a sequence number that is too old. The controlfile might be corrupted. PLEASE DO NOT ATTEMPT TO START UP THE INSTANCE without following the steps below. RE-STARTING THE INSTANCE CAN CAUSE SERIOUS DAMAGE TO THE DATABASE, if the controlfile is truly corrupted. In order to re-start the instance safely, please do the following: (1) Save all copies of the controlfile for later analysis and contact your OS vendor and Oracle support. (2) Mount the instance and issue: ALTER DATABASE BACKUP CONTROLFILE TO TRACE; (3) Unmount the instance. (4) Use the script in the trace file to RE-CREATE THE CONTROLFILE and open the database. ***************************************************** USER (ospid: 17064): terminating the instance Mon Nov 13 09:24:00 2023 System state dump requested by (instance=1, osid=17064), summary=[abnormal instance termination].
重启数据库报ORA-01122 ORA-01110 ORA-01207错误
Mon Nov 13 10:11:21 2023 ALTER DATABASE OPEN Errors in file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_25824.trc: ORA-01122: database file 1 failed verification check ORA-01110: data file 1: '/u01/oracle/oradata/xifenfei/system01.dbf' ORA-01207: file is more recent than control file - old control file ORA-1122 signalled during: ALTER DATABASE OPEN...
处理好上述错误之后遭遇ORA-01122 ORA-01110 ORA-01200,类似文章:
bbed处理ORA-01200故障
ORA-01122 ORA-01200故障处理
Mon Nov 13 10:51:48 2023 alter database open Read of datafile '/u01/oracle/oradata/xifenfei/sysaux01.dbf' (fno 2) header failed with ORA-01200 Rereading datafile 2 header failed with ORA-01200 Errors in file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_24148.trc: ORA-01122: database file 2 failed verification check ORA-01110: data file 2: '/u01/oracle/oradata/xifenfei/sysaux01.dbf' ORA-01200: actual file size of 2860800 is smaller than correct size of 2867200 blocks ORA-1122 signalled during: alter database open...
解决上述错误之后,尝试open库报ORA-00314 ORA-00312之类错误
Mon Nov 13 18:00:43 2023 alter database open Beginning crash recovery of 1 threads parallel recovery started with 15 processes Started redo scan Completed redo scan read 61894 KB redo, 589 data blocks need recovery Started redo application at Thread 1: logseq 12100, block 112760 Recovery of Online Redo Log: Thread 1 Group 1 Seq 12100 Reading mem 0 Mem# 0: /u01/oracle/oradata/xifenfei/redo01.log Completed redo application of 1.20MB Mon Nov 13 18:00:44 2023 Hex dump of (file 2, block 39078) in trace file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p011_27469.trc Reading datafile '/u01/oracle/oradata/xifenfei/sysaux01.dbf' for corruption at rdba: 0x008098a6 (file 2, block 39078) Reread (file 2, block 39078) found same corrupt data (logically corrupt) RECOVERY OF THREAD 1 STUCK AT BLOCK 39078 OF FILE 2 Mon Nov 13 18:00:44 2023 Exception [type: SIGSEGV, Address not mapped to object][ADDR:0xC][PC:0x95FB838, kdxlin()+4946][flags: 0x0, count: 1] Mon Nov 13 18:00:44 2023 Exception [type: SIGSEGV, Address not mapped to object][ADDR:0xC][PC:0x95FB4DE, kdxlin()+4088][flags: 0x0, count: 1] Errors in file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p011_27469.trc: ORA-00314: log 2 of thread 1, expected sequence# 12093 doesn't match 12085 ORA-00312: online log 2 thread 1: '/u01/oracle/oradata/xifenfei/redo02.log' Errors in file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p011_27469.trc: ORA-00314: log 3 of thread 1, expected sequence# 12096 doesn't match 12080 ORA-00312: online log 3 thread 1: '/u01/oracle/oradata/xifenfei/redo03.log' ORA-00314: log 2 of thread 1, expected sequence# 12093 doesn't match 12085 ORA-00312: online log 2 thread 1: '/u01/oracle/oradata/xifenfei/redo02.log'
后面继续处理遇到类似这样错误
ALTER DATABASE RECOVER CANCEL Errors in file /u01/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_pr00_31110.trc: ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '/u01/oracle/oradata/xifenfei/system01.dbf' ORA-1547 signalled during: ALTER DATABASE RECOVER CANCEL ... ALTER DATABASE RECOVER CANCEL ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ... Mon Nov 13 19:06:28 2023 alter database open resetlogs ORA-1194 signalled during: alter database open resetlogs...
最后确认其他数据文件均可recover 成功,只有file 2 无法正常recover
SQL> recover datafile 1; Media recovery complete. SQL> recover datafile 2; ORA-00283: recovery session canceled due to errors ORA-00600: internal error code, arguments: [3020], [2], [950840], [9339448], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 2, block# 950840, file offset is 3494313984 bytes) ORA-10564: tablespace SYSAUX ORA-01110: data file 2: '/u01/oracle/oradata/xifenfei/sysaux01.dbf' ORA-10560: block type 'FIRST LEVEL BITMAP BLOCK' SQL> recover datafile 3; Media recovery complete. SQL> recover datafile 4; Media recovery complete. SQL> recover datafile 5; Media recovery complete. SQL> recover datafile 6; Media recovery complete. SQL> recover datafile 7; Media recovery complete. SQL> recover datafile 2 allow 1 corruption; ORA-00283: recovery session canceled due to errors ORA-00600: internal error code, arguments: [3020], [2], [2410240], [10798848], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 2, block# 2410240, file offset is 2564816896 bytes) ORA-10564: tablespace SYSAUX ORA-01110: data file 2: '/u01/oracle/oradata/xifenfei/sysaux01.dbf' ORA-10560: block type 'FIRST LEVEL BITMAP BLOCK'
通过bbed修改文件头,直接open数据库成功,并协助客户顺利导出数据
参考类似文章:
使用bbed修复损坏datafile header
使用bbed让rac中的sysaux数据文件online