分类目录归档：Oracle

expdp dmp被加密破坏恢复

发表于 2020 年 3 月 20 日 由 惜分飞

有朋友oracle数据库dmp备份被加密,后缀为:.DMP.voyager,通过分析发现文件加密2M左右
20200320134933

这里可以看出来dmp文件为expdp方式导出(expdp本质上xml方式存储,exp使用直接二进制方式存储),通过工具分析可恢复表情况.
通过工具对该dmp文件进行分析

CPFL> OPEN F:\BaiduNetdisk\KINGDEE85GH_2020-03-17.DMP.voyager
TABLE_NAME                                         START_POS       DATA_BYTE     
-------------------------------------------------- --------------- --------------- 
KINGDEE85GH.T_WFD_PROCESSDEF                       116300288       648396035       
KINGDEE85GH.T_DYN_DYNAMICCONFIGURE                 864710656       181453794       
KINGDEE85GH.T_RPTS_STORAGEFILEDATA                 1078767616      21548951        
KINGDEE85GH.T_BOT_RULESEGMENT                      1100324864      10372516        
KINGDEE85GH.T_LOG_APP                              1110712320      12603573        
KINGDEE85GH.T_PM_PERMITEM                          1123336192      7282412         
KINGDEE85GH.T_PM_USERORGPERM                       1130635264      6692320         
KINGDEE85GH.T_DYN_APPSOLUTION                      1137336320      801697          
KINGDEE85GH.T_PM_MAINMENUITEM                      1138155520      3573943         
KINGDEE85GH.T_PM_PERMUIGROUP                       1141751808      2159245         
KINGDEE85GH.T_SYS_ENTITYREF                        1143922688      4183869         
KINGDEE85GH.T_PM_ROLEPERM                          1148116992      2758960         
KINGDEE85GH.T_BAS_SYSMENUITEM                      1150885888      3304627         
KINGDEE85GH.T_JP_PAGE                              1154211840      3019174  
…………      
KINGDEE85GH.T_XT_CHECKTIME                         1212776448      41              
KINGDEE85GH.T_XT_SYNCHTIME                         1212784640      41              
SYSTEM.SYS_EXPORT_SCHEMA_02                        1212792832      215423380    
-------------------------------------------------- --------------- --------------- 
Scanned Find 895 segments.

通过这个基本上可以确定丢失了100多M数据，其他数据理论上可以恢复.
创建用户

SQL> create user KINGDEE85GHidentified by oracle;

User created.

SQL> grant dba to KINGDEE85GH;

Grant succeeded.

unexpdp数据(自动创建表和导入数据)

CPFL> unexpdp table KINGDEE85GH.T_WFD_PROCESSDEF

unexpdp table: KINGDEE85GH.T_WFD_PROCESSDEF storage(START_POSITION:116300288 DATA_BYTE:748396035)
824 rows unexpdp

查看恢复结果
20200320142445
20200320142034

如果你有oracle expdp dmp被加密或者破坏,无法正常导入数据库,可以联系我们对其进行恢复处理:提供(ORACLE数据库恢复技术支持)：
Phone:17813235971    Q Q:107644445    E-Mail:dba@xifenfei.com
如果你的oracle dmp是exp方式导出,也可以联系我们对其进行处理,参见:
exp dmp文件损坏恢复
oracle dmp被加密恢复

发表在 非常规恢复 | 标签为 , , , , | 评论关闭

又一例system大量坏块恢复

发表于 2020 年 3 月 12 日 由 惜分飞

有朋友找到我们,说数据库服务可以启动,但是无法登陆,类似报错

C:\Users\XIFENFEI>D:\app\XIFENFEI\product\11.2.0.1\dbhome_2\bin\sqlplus / as sys
dba

SQL*Plus: Release 11.2.0.1.0 Production on 星期四 3月 12 15:04:32 2020

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

ERROR:
ORA-01075: 您现在已登录


请输入用户名:
ERROR:
ORA-01017: 用户名/口令无效; 登录被拒绝


请输入用户名:
ERROR:
ORA-01017: 用户名/口令无效; 登录被拒绝


SP2-0157: 在 3 次尝试之后无法连接到 ORACLE, 退出 SQL*Plus

通过分析发现数据库启动报错（未正常open成功）

C:\Users\XIFENFEI>D:\app\XIFENFEI\product\11.2.0.1\dbhome_2\bin\sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on 星期四 3月 12 14:58:28 2020

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

已连接到空闲例程。

SQL> startup mount pfile='F:\pfile.txt';
ORACLE 例程已经启动。

Total System Global Area 3307048960 bytes
Fixed Size                  2180264 bytes
Variable Size            1811942232 bytes
Database Buffers         1476395008 bytes
Redo Buffers               16531456 bytes
数据库装载完毕。

SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01578: ORACLE 数据块损坏 (文件号 1, 块号 48396)
ORA-01110: 数据文件 1: 'F:\ORADATA\SYSTEM01.DBF'

数据库没有正常启动成功的原因是由于system文件有坏块导致,通过dbv检查system文件发现有大量连续坏块

DBVERIFY: Release 11.2.0.1.0 - Production on 星期四 3月 12 19:12:34 2020

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.


DBVERIFY - 开始验证: FILE = F:\ORADATA\SYSTEM01.DBF
页 48064 流入 - 很可能是介质损坏
Corrupt block relative dba: 0x0040bbc0 (file 1, block 48064)
Fractured block found during dbv: 
Data in bad block:
 type: 6 format: 2 rdba: 0x0040bbc0
 last change scn: 0x0000.0006f69c seq: 0x1 flg: 0x06
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x43455474
 check value in block header: 0x3893
 computed block checksum: 0xadfa

…………

页 48412 标记为损坏
Corrupt block relative dba: 0x0040bd1c (file 1, block 48412)
Bad header found during dbv: 
Data in bad block:
 type: 36 format: 2 rdba: 0x6dce856d
 last change scn: 0xfc44.d24c936f seq: 0xdc flg: 0x3b
 spare1: 0x9c spare2: 0x92 spare3: 0xcf67
 consistency value in tail: 0x43455474
 check value in block header: 0x2598
 block checksum disabled


DBVERIFY - 验证完成

检查的页总数: 249600
处理的页总数 (数据): 209467
失败的页总数 (数据): 0
处理的页总数 (索引): 13616
失败的页总数 (索引): 0
处理的页总数 (其他): 3369
处理的总页数 (段)  : 1
失败的总页数 (段)  : 0
空的页总数: 22799
标记为损坏的总页数: 349
流入的页总数: 1
加密的总页数        : 0
最高块 SCN            : 84123103 (0.84123103)

数据库alert日志信息

Thu Mar 12 14:52:20 2020
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
Hex dump of (file 1, block 48403) in trace file d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc
Corrupt block relative dba: 0x0040bd13 (file 1, block 48403)
Bad header found during multiblock buffer read
Data in bad block:
 type: 36 format: 2 rdba: 0x6dce856d
 last change scn: 0xfc44.d24c936f seq: 0xdc flg: 0x3b
 spare1: 0x9c spare2: 0x92 spare3: 0xcf67
 consistency value in tail: 0x43455474
 check value in block header: 0x2598
 block checksum disabled
Reading datafile 'F:\ORADATA\SYSTEM01.DBF' for corruption at rdba: 0x0040bd13 (file 1, block 48403)
Reread (file 1, block 48403) found same corrupt data
Hex dump of (file 1, block 48404) in trace file d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc
Corrupt block relative dba: 0x0040bd14 (file 1, block 48404)
Corrupt Block Found
Bad header found during multiblock buffer read
         TSN = 0, TSNAME = SYSTEM
Data in bad block:
         RFN = 1, BLK = 48403, RDBA = 4242707
 type: 36 format: 2 rdba: 0x6dce856d
 last change scn: 0xfc44.d24c936f seq: 0xdc flg: 0x3b
 spare1: 0x9c spare2: 0x92 spare3: 0xcf67
 consistency value in tail: 0x43455474
 check value in block header: 0x2598
 block checksum disabled
Reading datafile 'F:\ORADATA\SYSTEM01.DBF' for corruption at rdba: 0x0040bd14 (file 1, block 48404)
Reread (file 1, block 48404) found same corrupt data
Errors in file d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc  (incident=3784):
ORA-01578: ORACLE 数据块损坏 (文件号 1, 块号 48404)
ORA-01110: 数据文件 1: 'F:\ORADATA\SYSTEM01.DBF'
Incident details in: d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\incident\incdir_3784\o11201gbk_ora_9480_i3784.trc
         OBJN = 36, OBJD = 36, OBJECT = I_OBJ1, SUBOBJECT = 
         SEGMENT OWNER = SYS, SEGMENT TYPE = Index Segment
Corrupt Block Found
         TSN = 0, TSNAME = SYSTEM
         RFN = 1, BLK = 48404, RDBA = 4242708
         OBJN = 36, OBJD = 36, OBJECT = I_OBJ1, SUBOBJECT = 
         SEGMENT OWNER = SYS, SEGMENT TYPE = Index Segment
Errors in file d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc:
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01578: ORACLE 数据块损坏 (文件号 1, 块号 48404)
ORA-01110: 数据文件 1: 'F:\ORADATA\SYSTEM01.DBF'
Errors in file d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc:
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01578: ORACLE 数据块损坏 (文件号 1, 块号 48404)
ORA-01110: 数据文件 1: 'F:\ORADATA\SYSTEM01.DBF'
Error 604 happened during db open, shutting down database
USER (ospid: 9480): terminating the instance due to error 604

这里可以看出来数据库不能正常启动的原因,主要是由于I_OBJ1(obj$表的index)刚好被损坏,导致数据库无法,通过分析定位确定是如下sql导致启动失败

Dump continued from file: d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc
ORA-01578: ORACLE 数据块损坏 (文件号 1, 块号 48404)
ORA-01110: 数据文件 1: 'F:\ORADATA\SYSTEM01.DBF'

========= Dump for incident 3784 (ORA 1578) ========

*** 2020-03-12 14:52:20.614
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=cq514nkrp38hv) -----
select distinct d.p_obj#,d.p_timestamp from sys.dependency$ d, obj$ o where d.p_obj#>=:1 and 
d.d_obj#=o.obj# and o.status not in (5,6)

通过对其i_obj1损坏block进行修复,数据库正启动成功

C:\Users\XIFENFEI>D:\app\XIFENFEI\product\11.2.0.1\dbhome_2\bin\sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on 星期四 3月 12 15:05:48 2020

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

已连接到空闲例程。

SQL> startup pfile='f:/pfile.txt' mount;
ORACLE 例程已经启动。

Total System Global Area 3307048960 bytes
Fixed Size                  2180264 bytes
Variable Size            1811942232 bytes
Database Buffers         1476395008 bytes
Redo Buffers               16531456 bytes
数据库装载完毕。
SQL> alter database open;

数据库已更改。

尝试导出数据

C:\Windows\system32>exp system/oracle owner=gis_sys file=f:/gis_sys.dmp FEEDBACK
=10000  COMPRESS=NO BUFFER=102400000 STATISTICS=none

Export: Release 11.2.0.1.0 - Production on 星期四 3月 12 15:46:19 2020

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.


连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
已导出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集

即将导出指定的用户...
. 正在导出 pre-schema 过程对象和操作
. 正在导出用户 GIS_SYS 的外部函数库名
. 导出 PUBLIC 类型同义词
EXP-00008: 遇到 ORACLE 错误 604
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01410: 无效的 ROWID
EXP-00000: 导出终止失败

分析trace文件

*** SESSION ID:(192.3) 2020-03-12 15:05:36.132
OBJD MISMATCH typ=6, seg.obj=18, diskobj=224, dsflg=100100, dsobj=18, tid=18, cls=1
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01410: 无效的 ROWID
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01410: 无效的 ROWID

由于obj id为18(obj$)的对象和对应的数据库中实际block存储的表的block为224(aud$)不匹配,从而出现该错误,通过分析是由于i_obj1记录错误导致该问题,通过修复该记录之后,数据实现完美导出.
20200312202743

类似system文件坏块案例有:
通过拷贝block实现system文件大量坏块恢复
记录一次system表空间坏块(ORA-01578)数据库恢复
SYSTEM表空间坏块恢复—C_TS#对象坏块恢复(file 1 block 60)
file 1 block 128 corrupted/坏块恢复—system rollback坏块修复

发表在 非常规恢复 | 标签为 , , , | 评论关闭

Oracle 19c故障恢复

发表于 2020 年 3 月 10 日 由 惜分飞

有客户找到我们,他们的oracle 19c数据库由于异常断电,导致启动异常,经过一系列恢复之后,依旧无法解决问题,请求我们给予支持.通过我们的Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check),获取数据库当前信息如下:
数据库版本为19C并且安装了19.5.0.0.191015 (30125133)补丁
20200310220453
20200310220748

数据库使用pdb
20200310220610
数据库启动成功后,一会就crash掉

2020-03-10T01:44:41.018032+08:00
Pluggable database RACBAK opened read write
2020-03-10T01:44:41.018996+08:00
Pluggable database RAC opened read write
2020-03-10T01:44:51.244050+08:00
Completed: ALTER PLUGGABLE DATABASE ALL OPEN
Starting background process CJQ0
Completed: ALTER DATABASE OPEN
2020-03-10T01:44:51.317085+08:00
CJQ0 started with pid=224, OS id=32581 
2020-03-10T01:44:56.067043+08:00
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_j001_32588.trc  (incident=1095281) (PDBNAME=RAC):
ORA-00600: internal error code, arguments: [4193], [27733], [27754], [], [], [], [], [], [], [], [], []
RAC(4):Incident details in: /opt/oracle/diag/rdbms/XFF/XFF/incident/incdir_1095281/XFF_j001_32588_i1095281.trc
RAC(4):Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2020-03-10T01:44:56.073112+08:00
RAC(4):*****************************************************************
RAC(4):An internal routine has requested a dump of selected redo.
RAC(4):This usually happens following a specific internal error, when
RAC(4):analysis of the redo logs will help Oracle Support with the
RAC(4):diagnosis.
RAC(4):It is recommended that you retain all the redo logs generated (by
RAC(4):all the instances) during the past 12 hours, in case additional
RAC(4):redo dumps are required to help with the diagnosis.
RAC(4):*****************************************************************
2020-03-10T01:44:56.079228+08:00
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_j002_32590.trc  (incident=1095289) (PDBNAME=RAC):
ORA-00600: internal error code, arguments: [4193], [2633], [2638], [], [], [], [], [], [], [], [], []
RAC(4):Incident details in: /opt/oracle/diag/rdbms/XFF/XFF/incident/incdir_1095289/XFF_j002_32590_i1095289.trc
RAC(4):Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2020-03-10T01:44:56.085068+08:00
RAC(4):*****************************************************************
RAC(4):An internal routine has requested a dump of selected redo.
RAC(4):This usually happens following a specific internal error, when
RAC(4):analysis of the redo logs will help Oracle Support with the
RAC(4):diagnosis.
RAC(4):It is recommended that you retain all the redo logs generated (by
RAC(4):all the instances) during the past 12 hours, in case additional
RAC(4):redo dumps are required to help with the diagnosis.
RAC(4):*****************************************************************
2020-03-10T01:44:56.115765+08:00
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_j004_32594.trc  (incident=1095305) (PDBNAME=RAC):
ORA-00600: internal error code, arguments: [4193], [63532], [63537], [], [], [], [], [], [], [], [], []
RAC(4):Incident details in: /opt/oracle/diag/rdbms/XFF/XFF/incident/incdir_1095305/XFF_j004_32594_i1095305.trc
RAC(4):Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2020-03-10T01:46:48.202213+08:00
RAC(4):Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
RAC(4):  Mem# 0: /opt/oracle/oradata/XFF/redo02.log
RAC(4):Block recovery completed at rba 0.0.0, scn 0x0000000d3675e48e
RAC(4):DDE: Problem Key 'ORA 600 [4193]' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
2020-03-10T01:46:48.384040+08:00
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_clmn_31741.trc:
ORA-00600: internal error code, arguments: [4193], [27733], [27754], [], [], [], [], [], [], [], [], []
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_clmn_31741.trc  (incident=1093505) (PDBNAME=CDB$ROOT):
ORA-501 [] [] [] [] [] [] [] [] [] [] [] []
Incident details in: /opt/oracle/diag/rdbms/XFF/XFF/incident/incdir_1093505/XFF_clmn_31741_i1093505.trc
2020-03-10T01:46:49.264624+08:00
USER (ospid: 31741): terminating the instance due to ORA error 501
2020-03-10T01:46:49.280664+08:00
System state dump requested by (instance=1, osid=31741 (CLMN)), summary=[abnormal instance termination].
System State dumped to trace file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_diag_31759.trc
2020-03-10T01:46:53.156926+08:00
ORA-00501: CLMN process terminated with error
2020-03-10T01:46:53.157103+08:00
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_diag_31759.trc:
ORA-00501: CLMN process terminated with error
2020-03-10T01:46:53.157211+08:00
Dumping diagnostic data in directory=[cdmp_20200310014649], requested by (instance=1, osid=31741 (CLMN)), 
summary=[abnormal instance termination].

通过报错信息判断,数据库open之后(特别是pdb 4 open之后),开始报ORA-600 4193错误.然后由于CLMN进程异常,最后数据库crash.对于这类故障,因为使用的pdb,而且是由于pdb的undo异常导致数据库启动之后crash,可以通过对于pdb进行特殊处理,从而实现数据库启动之后不再crash.

发表在 ORACLE 19C, Oracle备份恢复 | 标签为 , , , | 评论关闭