联系：手机/微信(+86 17813235971) QQ(107644445)
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
前段时间恢复了一个近40T的被勒索加密的oracle数据库,这个是对勒索病毒加密数据库恢复以来,处理最大的单个勒索加密oracle数据库,对此做一个记录
其中一个分区表的lob字段20T
40T勒索加密Oracle数据库恢复
其中一个分区表的lob字段20T
其中一个分区表的lob字段20T
recover database 报kcbs_dump_adv_state恢复
联系：手机/微信(+86 17813235971) QQ(107644445)
标题：recover database 报kcbs_dump_adv_state恢复
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
数据库recover database报ORA-600 kcbrsearchflist_2,kcbs_dump_adv_state,ORA-600 kdBlkCheckError等错
Thu Dec 16 23:57:39 2021 ALTER DATABASE RECOVER database Media Recovery Start started logmerger process Parallel Media Recovery started with 8 slaves Thu Dec 16 23:57:40 2021 Recovery of Online Redo Log: Thread 1 Group 3 Seq 82476 Reading mem 0 Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG Thu Dec 16 23:57:41 2021 Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr02_5628.trc (incident=85419): ORA-00600: internal error code, arguments: [kcbrsearchflist_2], [], [], [], [], [], [], [], [], [], [], [] Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85419\orcl_pr02_5628_i85419.trc Thu Dec 16 23:57:42 2021 Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr04_668.trc (incident=85435): ORA-00353: log corruption near block 9889 change 997219782 time 12/15/2021 17:48:50 ORA-00312: online log 2 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG' Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85435\orcl_pr04_668_i85435.trc Thu Dec 16 23:57:42 2021 Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr03_5972.trc (incident=85427): ORA-00353: log corruption near block 9889 change 997219782 time 12/15/2021 17:48:50 ORA-00312: online log 2 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG' ORA-10567: Redo is inconsistent with data block (file# 1, block# 2296, file offset is 18808832 bytes) ORA-10564: tablespace SYSTEM ORA-01110: data file 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM01.DBF' ORA-10560: block type 'DATA SEGMENT HEADER - UNLIMITED' Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85427\orcl_pr03_5972_i85427.trc Thu Dec 16 23:57:43 2021 Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr05_5280.trc (incident=85443): ORA-00353: log corruption near block 9889 change 997219782 time 12/15/2021 17:48:50 ORA-00312: online log 2 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG' ORA-10567: Redo is inconsistent with data block (file# 3, block# 128, file offset is 1048576 bytes) ORA-10564: tablespace UNDOTBS1 ORA-01110: data file 3: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\UNDOTBS01.DBF' ORA-10560: block type 'KTU SMU HEADER BLOCK' Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85443\orcl_pr05_5280_i85443.trc Exception[type: ACCESS_VIOLATION, UNABLE_TO_READ][ADDR:0xFFFFFFFFFFFFFFFF][PC:0x1351BB9, kcbs_dump_adv_state()+1529] Exception[type: ACCESS_VIOLATION, UNABLE_TO_READ][ADDR:0xFFFFFFFFFFFFFFFF][PC:0x1351BB9, kcbs_dump_adv_state()+1529] ERROR: Unable to normalize symbol name for the following short stack (at offset 199): dbgexProcessError()+193<-dbgeExecuteForError()+65<-dbgePostErrorKGE()+1726<-dbkePostKGE_kgsf()+75<-kgeade()+560 <-kgerev()+125<-kgerec5()+60<-sss_xcpt_EvalFilterEx()+1869<-sss_xcpt_EvalFilter()+174<-.1.4_5+59<-0000000077867958 <-000000007787812D<-000000007786855F<-000000007789BCB8<-kcbs_dump_adv_state()+1529<-kcbs_advice_dump()+214 <-dbkedDefDump()+16379<-ksedmp()+43<-ksfdmp()+87<-dbgexPhaseII()+1819<-dbgexProcessError()+2563 <-dbgeExecuteForError()+65<-dbgePostErrorKGE()+1726<-dbkePostKGE_kgsf()+75<-kgeade()+560<-kgerev()+125 <-kserec3()+111<-kcrcrl()+262<-krr_thread_read()+2718<-krr_read_buffer()+30<-krr_parse_redo()+2228 <-kcra_scan_redo()+10061<-kcra_dump_redo()+2246<-kcra_dump_redo_internal()+1752<-kcbr_mapply_change()+5953 <-kcbrapply()+2251<-kcbr_apply_pending()+2931<-kcbr_media_apply()+6901<-krp_slave_apply()+313<-krp_slave_main()+2545 <-ksvrdp()+2506<-opirip()+965<-opidrv()+909<-sou2o()+98<-opimai_real()+299<-opimai()+191 <-BackgroundThreadStart()+693<-00000000776459CD<-000000007787A561 Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr03_5972.trc (incident=85428): ORA-07445: exception encountered: core dump [kcbs_dump_adv_state()+1529] [ACCESS_VIOLATION][ADDR:0xFFFFFFFFFFFFFFFF] ORA-00353: log corruption near block 9889 change 997219782 time 12/15/2021 17:48:50 ORA-00312: online log 2 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG' ORA-10567: Redo is inconsistent with data block (file# 1, block# 2296, file offset is 18808832 bytes) ORA-10564: tablespace SYSTEM ORA-01110: data file 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM01.DBF' ORA-10560: block type 'DATA SEGMENT HEADER - UNLIMITED' Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85428\orcl_pr03_5972_i85428.trc Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0xFFFFFFFFFFFFFFFF] [PC:0x1351BB9, kcbs_dump_adv_state()+1529] Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0xFFFFFFFFFFFFFFFF] [PC:0x1351BB9, kcbs_dump_adv_state()+1529] Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr04_668.trc (incident=85436): ORA-07445: exception encountered:core dump [kcbs_dump_adv_state()+1529][ACCESS_VIOLATION][ADDR:0xFFFFFFFFFFFFFFFF] ORA-00353: log corruption near block 9889 change 997219782 time 12/15/2021 17:48:50 ORA-00312: online log 2 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG' Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85436\orcl_pr04_668_i85436.trc Thu Dec 16 23:57:44 2021 Trace dumping is performing id=[cdmp_20211216235744] Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr02_5628.trc (incident=85420): ORA-07445: exception encountered: core dump [kcbs_dump_adv_state()+1529] [ACCESS_VIOLATION] [ADDR:0xFFFFFFFFFFFFFFFF] ORA-00600: internal error code, arguments: [kcbrsearchflist_2], [], [], [], [], [], [], [], [], [], [], [] Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85420\orcl_pr02_5628_i85420.trc Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr05_5280.trc (incident=85444): ORA-07445: exception encountered: core dump [kcbs_dump_adv_state()+1529] [ACCESS_VIOLATION] [ADDR:0xFFFFFFFFFFFFFFFF] ORA-00353: log corruption near block 9889 change 997219782 time 12/15/2021 17:48:50 ORA-00312: online log 2 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG' ORA-10567: Redo is inconsistent with data block (file# 3, block# 128, file offset is 1048576 bytes) ORA-10564: tablespace UNDOTBS1 ORA-01110: data file 3: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\UNDOTBS01.DBF' ORA-10560: block type 'KTU SMU HEADER BLOCK' Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85444\orcl_pr05_5280_i85444.trc Thu Dec 16 23:57:45 2021 Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x29FFFFFFE] [PC:0x7473E40B, 000000007473E40B] Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr06_4268.trc (incident=85451): ORA-07445: exception encountered: core dump [PC:0x7473E40B] [ACCESS_VIOLATION] [ADDR:0x29FFFFFFE] [PC:0x7473E40B] Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85451\orcl_pr06_4268_i85451.trc Trace dumping is performing id=[cdmp_20211216235745] Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85451\orcl_pr06_4268_i85451.trc: ORA-00607: Internal error occurred while making a change to a data block ORA-00602: internal programming exception ORA-07445: exception encountered: core dump [PC:0x7473E40B] [ACCESS_VIOLATION] [ADDR:0x29FFFFFFE] [PC:0x7473E40B] Process debug not enabled via parameter _debug_enable Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr04_668.trc: ORA-00354: corrupt redo log block header ORA-00353: log corruption near block 9889 change 997219782 time 12/15/2021 17:48:50 ORA-00312: online log 2 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG' Trace dumping is performing id=[cdmp_20211216235747] Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr04_668.trc (incident=85437): ORA-00600: internal error code, arguments: [kdBlkCheckError], [1], [2025], [6401], [], [], [], [], [], [], [], [] Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85437\orcl_pr04_668_i85437.trc Recovery Slave PR02 died Trace dumping is performing id=[cdmp_20211216235748] Slave exiting with ORA-10562 exception Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr04_668.trc: ORA-10562: Error occurred while applying redo to data block (file# 1, block# 2025) ORA-10564: tablespace SYSTEM ORA-01110: data file 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM01.DBF' ORA-00600: internal error code, arguments: [kdBlkCheckError], [1], [2025], [6401], [], [], [], [], [], [], [], [] Thu Dec 16 23:57:48 2021 Sweep [inc][85451]: completed Sweep [inc][85444]: completed Media Recovery failed with error 448 Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr00_3528.trc: ORA-00283: recovery session canceled due to errors ORA-00448: normal completion of background process Slave exiting with ORA-283 exception Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr00_3528.trc: ORA-00283: recovery session canceled due to errors ORA-00448: normal completion of background process ORA-10878 signalled during: ALTER DATABASE RECOVER database ...
尝试recover datafile报ORA-07445 kcbsacc错
ALTER DATABASE RECOVER datafile 5 Media Recovery Start Serial Media Recovery started Recovery of Online Redo Log: Thread 1 Group 3 Seq 82476 Reading mem 0 Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0xFFFFFFFFFFFFFFFF] [PC:0x13467BB, kcbsacc()+5913] Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_6180.trc (incident=85398): ORA-07445: 出现异常错误: 核心转储 [kcbsacc()+5913] [ACCESS_VIOLATION] [ADDR:0xFFFFFFFFFFFFFFFF] [PC:0x13467BB] Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_85398\orcl_ora_6180_i85398.trc
通过上述报错分析,基本上确认是由于异常断电导致redo和数据文件的block不一致引起,尝试强制open库,数据库报ORA-600 2662错误
Fri Dec 17 11:41:40 2021 alter database open resetlogs RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated. RESETLOGS after incomplete recovery UNTIL CHANGE 997234250 Resetting resetlogs activation ID 1489370600 (0x58c5fde8) Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_7112.trc: ORA-00367: 日志文件标头中的校验和错误 ORA-00322: 日志 1 (用于线程 1) 不是最新副本 ORA-00312: 联机日志 1 线程 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG' Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_7112.trc: ORA-00367: 日志文件标头中的校验和错误 ORA-00322: 日志 2 (用于线程 1) 不是最新副本 ORA-00312: 联机日志 2 线程 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG' Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_7112.trc: ORA-00367: 日志文件标头中的校验和错误 ORA-00322: 日志 3 (用于线程 1) 不是最新副本 ORA-00312: 联机日志 3 线程 1: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG' Fri Dec 17 11:41:46 2021 Setting recovery target incarnation to 2 Fri Dec 17 11:41:46 2021 Assigning activation ID 1619342902 (0x60853636) Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG Successful open of redo thread 1 Fri Dec 17 11:41:46 2021 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Fri Dec 17 11:41:47 2021 SMON: enabling cache recovery Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_7112.trc (incident=89000): ORA-00600: 内部错误代码, 参数: [2662], [0], [997234264], [0], [997238345], [12583088], [] Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_89000\orcl_ora_7112_i89000.trc Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_7112.trc: ORA-00600: 内部错误代码, 参数: [2662], [0], [997234264], [0], [997238345], [12583088], [] Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_7112.trc: ORA-00600: 内部错误代码, 参数: [2662], [0], [997234264], [0], [997238345], [12583088], [] Error 600 happened during db open, shutting down database USER (ospid: 7112): terminating the instance due to error 600 Instance terminated by USER, pid = 7112 ORA-1092 signalled during: alter database open resetlogs... Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_7112.trc (incident=89001): ORA-00600: 内部错误代码, 参数: [2662], [0], [997234266], [0], [997238345], [12583088], [], [], [], [], [], [] ORA-01092: ORACLE 实例终止。强制断开连接 ORA-00600: 内部错误代码, 参数: [2662], [0], [997234264], [0], [997238345], [12583088], [], [], [], [], [], [] Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_89001\orcl_ora_7112_i89001.trc Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_7112.trc (incident=89002): ORA-00600: 内部错误代码, 参数: [2662], [0], [997234267], [0], [997238345], [12583088], [], [], [], [], [], [] ORA-00600: 内部错误代码, 参数: [2662], [0], [997234266], [0], [997238345], [12583088], [], [], [], [], [], [] ORA-01092: ORACLE 实例终止。强制断开连接 ORA-00600: 内部错误代码, 参数: [2662], [0], [997234264], [0], [997238345], [12583088], [], [], [], [], [], [] Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_89002\orcl_ora_7112_i89002.trc Fri Dec 17 11:41:57 2021 Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_7112.trc: ORA-00600: 内部错误代码, 参数: [2662], [0], [997234267], [0], [997238345], [12583088], [], [], [], [], [], [] ORA-00600: 内部错误代码, 参数: [2662], [0], [997234266], [0], [997238345], [12583088], [], [], [], [], [], [] ORA-01092: ORACLE 实例终止。强制断开连接 ORA-00600: 内部错误代码, 参数: [2662], [0], [997234264], [0], [997238345], [12583088], [], [], [], [], [], [] Fri Dec 17 11:41:59 2021 Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_7112.trc (incident=90048): ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [2662], [0], [997234267], [0], [997238345], [12583088], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [2662], [0], [997234266], [0], [997238345], [12583088], [], [], [], [], [], [] ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [2662], [0], [997234264], [0], [997238345], [12583088], [], [], [], [], [], [] Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_90048\orcl_ora_7112_i90048.trc Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_90048\orcl_ora_7112_i90048.trc: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [2662], [0], [997234267], [0], [997238345], [12583088], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [2662], [0], [997234266], [0], [997238345], [12583088], [], [], [], [], [], [] ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [2662], [0], [997234264], [0], [997238345], [12583088], [], [], [], [], [], []
通过修改scn数据库open正常
Fri Dec 17 11:48:37 2021 alter database open Fri Dec 17 11:48:38 2021 SMON: enabling cache recovery Database Characterset is ZHS16GBK No Resource Manager plan active Completed: alter database open
由于该库非一致性恢复,逻辑方式导出数据并导入新库,恢复完成
ORA-00603 ORA-01092 ORA-600 kcbzib_kcrsds_1
联系：手机/微信(+86 17813235971) QQ(107644445)
标题：ORA-00603 ORA-01092 ORA-600 kcbzib_kcrsds_1
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
接手客户故障数据库报错为:ORA-16433
[orauser@xifenfei check_db]$ sqlplus / as sysdba SQL*Plus: Release 12.2.0.1.0 Production on Tue Dec 14 02:36:24 2021 Copyright (c) 1982, 2016, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production SQL> alter database backup controlfile to trace as '/tmp/ctl'; alter database backup controlfile to trace as '/tmp/ctl' * ERROR at line 1: ORA-16433: The database or pluggable database must be opened in read/write mode. SQL> recover datafile 1; ORA-00283: recovery session canceled due to errors ORA-16433: The database or pluggable database must be opened in read/write mode.
这个错误一般是由于之前resetlogs未能正常打开库导致,通过rectl之后,尝试重新打开库,报错为:ORA-600 kcbzib_kcrsds_1
SQL> ALTER DATABASE OPEN; ALTER DATABASE OPEN * ERROR at line 1: ORA-00603: ORACLE server session terminated by fatal error ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], [] Process ID: 49304 Session ID: 4698 Serial number: 14852
这个错误一般是scn问题,对于之前版本直接使用隐含参数,event,oradebug进行调整scn即可,但是在12.2版本之后无法使用这些方法修改,处理起来相对麻烦一些，参考以前处理的相关文章:
ORA-600 kcbzib_kcrsds_1报错
12C数据库报ORA-600 kcbzib_kcrsds_1故障处理
oradebug poke ORA-32521/ORA-32519故障解决
impdp TRANSFORM参数
联系：手机/微信(+86 17813235971) QQ(107644445)
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
在impdp的参数中有一个transform参数,用来实现在创建对象的时候对一些存储参数进行修改,官方关于这个参数说明:
TRANSFORM 要应用于适用对象的元数据转换。 有效的关键字为: OID, PCTSPACE, SEGMENT_ATTRIBUTES 和 STORAGE。
对主要的SEGMENT_ATTRIBUTES和STORAGE参数进行测试
SQL> create user xff identified by oracle default tablespace users; 用户已创建。 SQL> grant dba to xff; 授权成功。 SQL> create table xff.t_1 as select * from dba_objects; 表已创建。 SQL> exit 从 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options 断开 C:\Users\XFF>expdp xff/oracle tables=t_1 dumpfile=t_1.dmp Export: Release 11.2.0.4.0 - Production on 星期四 12月 16 20:56:50 2021 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options 启动 "XFF"."SYS_EXPORT_TABLE_01": xff/******** tables=t_1 dumpfile=t_1.dmp 正在使用 BLOCKS 方法进行估计... 处理对象类型 TABLE_EXPORT/TABLE/TABLE_DATA 使用 BLOCKS 方法的总估计: 11 MB 处理对象类型 TABLE_EXPORT/TABLE/TABLE . . 导出了 "XFF"."T_1" 8.709 MB 89959 行 已成功加载/卸载了主表 "XFF"."SYS_EXPORT_TABLE_01" ****************************************************************************** XFF.SYS_EXPORT_TABLE_01 的转储文件集为: C:\APP\XFF\ADMIN\ORCL\DPDUMP\T_1.DMP 作业 "XFF"."SYS_EXPORT_TABLE_01" 已于 星期四 12月 16 20:56:53 2021 elapsed 0 00:00:02 成功完成
不使用TRANSFORM参数导入效果
C:\Users\XFF>impdp xff/oracle sqlfile=t_2.sql full=y dumpfile=t_1.dmp Import: Release 11.2.0.4.0 - Production on 星期四 12月 16 21:00:12 2021 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options 已成功加载/卸载了主表 "XFF"."SYS_SQL_FILE_FULL_01" 启动 "XFF"."SYS_SQL_FILE_FULL_01": xff/******** sqlfile=t_2.sql full=y dumpfile=t_1.dmp 处理对象类型 TABLE_EXPORT/TABLE/TABLE 作业 "XFF"."SYS_SQL_FILE_FULL_01" 已于 星期四 12月 16 21:00:12 2021 elapsed 0 00:00:00 成功完成
对应的t_2.sql文件内容
transform=storage:n参数导入效果
C:\Users\XFF>impdp xff/oracle sqlfile=t_1.sql full=y dumpfile=t_1.dmp transform=storage:n Import: Release 11.2.0.4.0 - Production on 星期四 12月 16 20:58:04 2021 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options 已成功加载/卸载了主表 "XFF"."SYS_SQL_FILE_FULL_01" 启动 "XFF"."SYS_SQL_FILE_FULL_01": xff/******** sqlfile=t_1.sql full=y dumpfile=t_1.dmp transform=storage:n 处理对象类型 TABLE_EXPORT/TABLE/TABLE 作业 "XFF"."SYS_SQL_FILE_FULL_01" 已于 星期四 12月 16 20:58:04 2021 elapsed 0 00:00:00 成功完成
对应的t_1.sql文件内容
transform=segment_attributes:n参数导入效果
C:\Users\XFF>impdp xff/oracle sqlfile=t_3.sql full=y dumpfile=t_1.dmp transform=segment_attributes:n Import: Release 11.2.0.4.0 - Production on 星期四 12月 16 21:00:36 2021 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options 已成功加载/卸载了主表 "XFF"."SYS_SQL_FILE_FULL_01" 启动 "XFF"."SYS_SQL_FILE_FULL_01": xff/******** sqlfile=t_3.sql full=y dumpfile=t_1.dmp transform=segment_attributes:n 处理对象类型 TABLE_EXPORT/TABLE/TABLE 作业 "XFF"."SYS_SQL_FILE_FULL_01" 已于 星期四 12月 16 21:00:36 2021 elapsed 0 00:00:00 成功完成
对应的t_3.sql文件内容
transform=segment_attributes:n除掉了所有存储相关信息，对象数据直接导入到用户默认表空间中
transform=storage:n导入的时候除掉了STORAGE部分,表空间信息依旧存在(也就是说导入到表原始表空间中)
Exception [type: SIGSEGV, Address not mapped to object] [] [ kgegpa()+36]
联系：手机/微信(+86 17813235971) QQ(107644445)
标题：Exception [type: SIGSEGV, Address not mapped to object] [] [ kgegpa()+36]
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
有朋友找我，由于客户硬件故障,导致控制文件损坏，重建控制文件的时候,由于失误依赖了100多个数据文件,并且进行了resetlogs操作,然后通过bbed修改文件头,再进行恢复,数据库在open过程中报ORA-03113错误
SQL> recover database; Media recovery complete. SQL> alter database Open ; ERROR: ORA-03113: end-of-file on communication channel Process ID: 11207284 Session ID: 4537 Serial number: 1
对应的alert日志信息
Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Sat Dec 04 23:17:02 2021 SMON: enabling cache recovery ARC3: Archival started ARC0: STARTING ARCH PROCESSES COMPLETE Sat Dec 04 23:17:03 2021 Exception [type: SIGSEGV, Address not mapped to object][ADDR:0x1604971A0][PC:0x1000E1764,kgegpa()+36][flags:0x0,count:1] Exception [type: SIGSEGV, Address not mapped to object][ADDR:0x1604971A0][PC:0x1000E1764,kgegpa()+36][flags:0x2,count:2] Exception [type: SIGSEGV, Address not mapped to object][ADDR:0x1604971A0][PC:0x1000E1764,kgegpa()+36][flags:0x2,count:2] Sat Dec 04 23:17:07 2021 PMON (ospid: 10879866): terminating the instance due to error 397 Sat Dec 04 23:17:08 2021 System state dump requested by (instance=1, osid=10879866 (PMON)), summary=[abnormal instance termination]. System State dumped to trace file /oracle/app/oracle/diag/rdbms/xff/xff1/trace/xff1_diag_11076320.trc Dumping diagnostic data in directory=[cdmp_20211204231708], requested by (instance=1, osid=10879866 (PMON)), summary=[abnormal instance termination]. Sat Dec 04 23:17:09 2021 ORA-1092 : opitsk aborting process
通过对其启动过程进行跟踪确认在update undo$ 语句中异常
PARSING IN CURSOR #11529215044940435280 len=148 dep=1 uid=0 oct=6 lid=0 tim=223080942765 hv=3540833987 ad='c000000d67a42778' sqlid='5ansr7r9htpq3' update undo$ set name=:2,file#=:3,block#=:4,status$=:5,user#=:6,undosqn=:7,xactsqn=:8, scnbas=:9,scnwrp=:10,inst#=:11,ts#=:12,spare1=:13 where us#=:1 END OF STMT PARSE #11529215044940435280:c=10000,e=8182,p=6,cr=55,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=223080942764 BINDS #11529215044940435280: Bind#0 oacdty=01 mxl=32(20) mxlc=00 mal=00 scl=00 pre=00 oacflg=18 fl2=0001 frm=01 csi=873 siz=32 off=0 kxsbbbfp=c000000d5fd299aa bln=32 avl=20 flg=09 value="_SYSSMU29_3935275865$" Bind#1 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6e078 bln=24 avl=02 flg=05 value=3 Bind#2 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6e048 bln=24 avl=03 flg=05 value=128 Bind#3 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6e010 bln=24 avl=02 flg=05 value=5 Bind#4 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6dfe0 bln=24 avl=02 flg=05 value=1 Bind#5 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6dfb0 bln=24 avl=04 flg=05 value=28921 Bind#6 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6df80 bln=24 avl=05 flg=05 value=1245262 Bind#7 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6df48 bln=24 avl=06 flg=05 value=1217986655 Bind#8 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6dc90 bln=24 avl=03 flg=05 value=3621 Bind#9 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6dc60 bln=24 avl=01 flg=05 value=0 Bind#10 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6dc30 bln=24 avl=02 flg=05 value=2 Bind#11 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6dc00 bln=24 avl=02 flg=05 value=2 Bind#12 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=9fffffffbcc6e0a8 bln=22 avl=02 flg=05 value=1 WAIT #4574659112: nam='db file sequential read' ela= 6835 file#=1 block#=842169 blocks=1 obj#=0 tim=90821816220340
通过分析,确认是由于undo事务异常,通过一系列处理之后,数据库启动报
SQL> alter database open; alter database open * ERROR at line 1: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], [] Process ID: 11206912 Session ID: 4537 Serial number: 1
对应alert日志报错
Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Sun Dec 05 02:42:02 2021 SMON: enabling cache recovery SUCCESS: diskgroup FRA was mounted Archived Log entry 1 added for thread 1 sequence 1 ID 0x14ba19ad dest 1: Sun Dec 05 02:42:03 2021 NOTE: dependency between database xff and diskgroup resource ora.FRA.dg is established Errors in file /oracle/app/oracle/diag/rdbms/xff/xff1/trace/xff1_ora_11206912.trc (incident=5681243): ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], [] Incident details in: /oracle/app/oracle/diag/rdbms/xff/xff1/incident/incdir_5681243/xff1_ora_11206912_i5681243.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. ARC3: Archival started ARC0: STARTING ARCH PROCESSES COMPLETE Sun Dec 05 02:42:05 2021 Dumping diagnostic data in directory=[cdmp_20211205024205], requested by (instance=1, osid=11206912), summary=[incident=5681243]. Sun Dec 05 02:42:05 2021 Block recovery from logseq 2, block 3 to scn 13867049493730 Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0 Mem# 0: +DATA/xff/onlinelog/group_2.log Block recovery stopped at EOT rba 2.5.16 Block recovery completed at rba 2.5.16, scn 3228.2895062240 Block recovery from logseq 2, block 3 to scn 13867049493727 Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0 Mem# 0: +DATA/xff/onlinelog/group_2.log Block recovery completed at rba 2.5.16, scn 3228.2895062240 Errors in file /oracle/app/oracle/diag/rdbms/xff/xff1/trace/xff1_ora_11206912.trc: ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], [] Errors in file /oracle/app/oracle/diag/rdbms/xff/xff1/trace/xff1_ora_11206912.trc: ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], [] Error 600 happened during db open, shutting down database USER (ospid: 11206912): terminating the instance due to error 600 Instance terminated by USER, pid = 11206912 ORA-1092 signalled during: alter database open... opiodr aborting process unknown ospid (11206912) as a result of ORA-1092 Sun Dec 05 02:42:07 2021 ORA-1092 : opitsk aborting process
trace中关键信息和bbed对看到结果对应,通过bbed清空,数据库启动正常
Version: 0x01
FREE BLOCK POOL::
uba: 0x004cd9b9.02fb.0c ext: 0x19 spc: 0x1462
uba: 0x00000000.02fb.02 ext: 0x19 spc: 0x1f06
uba: 0x00000000.02fb.0d ext: 0x19 spc: 0x1970
uba: 0x00000000.02fa.03 ext: 0x18 spc: 0x1e34
uba: 0x00000000.02fa.03 ext: 0x18 spc: 0x1e34
struct ktuxcfbp[0], 12 bytes @4192
struct ktufbuba, 8 bytes @4192
ub4 kubadba @4192 0x004cd9b9
ub2 kubaseq @4196 0x02fb
ub1 kubarec @4198 0x0c
sb2 ktufbext @4200 25
sb2 ktufbspc @4202 5218
以前有过类似恢复硬件恢复之后,数据库无法open故障恢复
校验代码为 6054 坏块故障修复
联系：手机/微信(+86 17813235971) QQ(107644445)
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
有客户反馈数据库操作报错,希望我们给予处理,报错信息如下:
通过对system01.dbf数据文件分析
C:\Users\XFF>dbv file=H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 12月 4 20:45:23 2021 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF DBV-00200: 块 DBA 4330012 已标记为损坏 csc(0x0000.1686df22) higher than block scn(0x0000.00000000) 页 135708 失败, 校验代码为 6054 DBVERIFY - 验证完成 检查的页总数: 184320 处理的页总数 (数据): 93105 失败的页总数 (数据): 0 处理的页总数 (索引): 31365 失败的页总数 (索引): 1 处理的页总数 (其他): 43622 处理的总页数 (段) : 1 失败的总页数 (段) : 0 空的页总数: 16228 标记为损坏的总页数: 1 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 378591519 (0.378591519)
确认block 135708 有问题,确认起对象为I_OBJ5
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;
输入 file_id 的值: 1
原值 3: WHERE FILE_ID = &FILE_ID
新值 3: WHERE FILE_ID = 1
输入 block_id 的值: 135708
原值 4: AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1
新值 4: AND 135708 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1
OWNER SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME PARTITION_NAME
------------------------------ --------------- ------------------ ------------------------------ -----------------
SYS I_OBJ5 INDEX
SYSTEM
这个对象为核心对象obj$的index,无法直接rebuild,当然可以通过参考以前blog文档进行重建:bootstrap$核心index(I_OBJ1,I_USER1,I_FILE#_BLOCK#,I_IND1,I_TS#,I_CDEF1等)异常恢复—ORA-00701错误解决,直接对该坏块进行修复.
BBED> p kcbh struct kcbh, 20 bytes @0 ub1 type_kcbh @0 0x06 ub1 frmt_kcbh @1 0xa2 ub1 spare1_kcbh @2 0x00 ub1 spare2_kcbh @3 0x00 ub4 rdba_kcbh @4 0x0042121c ub4 bas_kcbh @8 0x00000000 ub2 wrp_kcbh @12 0x0000 ub1 seq_kcbh @14 0xff ub1 flg_kcbh @15 0x04 (KCBHFCKV) ub2 chkval_kcbh @16 0xe8c4 ub2 spare3_kcbh @18 0x0000 BBED> m /x 23df8616 File: H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF (0) Block: 135709 Offsets: 8 to 519 Dba:0x00000000 ------------------------------------------------------------------------ 23df8616 00000104 44fe0000 02000000 28000000 22df8616 00000000 02000200 00000000 0a001800 f7dc1b00 8002c000 bdd80100 00e00000 f331b114 0a001f00 14081e00 4505c000 2c103b00 01200000 2adf8616 00008009 01000000 3f00a200 35074010 00000000 e1b24100 56694100 06000000 641f0000 57119211 cd11d208 97080812 43127e12 b912f412 2f130d09 e013bd09 1b14cc14 0715ab07 5c087d15 b715f215 a3167007 3507de16 19175417 21088f17 ca170518 4018330a 1f0b7b18 2c196719 a219dd19 181a531a 8e1a4709 031be607 f809791b b41bef1b 2a1c651c db1ce20d 8c1d310d c71d021e 3d1e781e b31e8209 291f291f 291f291f 291f291f 291f291f 291f0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <32 bytes per line>
然后dbv报以下错误
C:\Users\XFF>dbv file=H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 12月 4 22:06:49 2021 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF itl[2] has higher commit scn(0x0000.1686df2a) than block scn (0x0000.1686df23) 页 135708 失败, 校验代码为 6056 DBVERIFY - 验证完成 检查的页总数: 184320 处理的页总数 (数据): 95152 失败的页总数 (数据): 0 处理的页总数 (索引): 34569 失败的页总数 (索引): 1 处理的页总数 (其他): 38386 处理的总页数 (段) : 1 失败的总页数 (段) : 0 空的页总数: 16213 标记为损坏的总页数: 0 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 378683101 (0.378683101)
再次对其进行修复
BBED> m /x 22df8616 File: H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF (0) Block: 135709 Offsets: 88 to 599 Dba:0x00000000 ------------------------------------------------------------------------ 22df8616 00008009 01000000 3f00a200 35074010 00000000 e1b24100 56694100 06000000 641f0000 57119211 cd11d208 97080812 43127e12 b912f412 2f130d09 e013bd09 1b14cc14 0715ab07 5c087d15 b715f215 a3167007 3507de16 19175417 21088f17 ca170518 4018330a 1f0b7b18 2c196719 a219dd19 181a531a 8e1a4709 031be607 f809791b b41bef1b 2a1c651c db1ce20d 8c1d310d c71d021e 3d1e781e b31e8209 291f291f 291f291f 291f291f 291f291f 291f0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <32 bytes per line>
再次dbv检查修复成功
C:\Users\XFF>dbv file=H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 12月 4 22:30:14 2021 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF DBVERIFY - 验证完成 检查的页总数: 184320 处理的页总数 (数据): 95152 失败的页总数 (数据): 0 处理的页总数 (索引): 34569 失败的页总数 (索引): 0 处理的页总数 (其他): 38386 处理的总页数 (段) : 1 失败的总页数 (段) : 0 空的页总数: 16213 标记为损坏的总页数: 0 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 378683101 (0.378683101)
对于这类的坏块,也可以通过我们的Oracle recovery tools进行快速恢复
数据库文件被勒索改名数据库恢复
联系：手机/微信(+86 17813235971) QQ(107644445)
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
做一个oracle数据库被加密，所有数据文件名称全部被重命名,类似
分析文件破坏情况
通过分析文件头1278个block被加密破坏,在没有文件名正确文件名,而且文件头大量损坏的情况下,一般的恢复工具都无法正常进行恢复,基于这种情况,使用自己开发的小工具进行分析修复恢复
然后快速恢复客户要的相关核心表数据
对于这种加密破坏较多,而且数据文件被勒索病毒修改名称,无法使用一般工具进行恢复的，可以联系我们进行核心数据恢复
电话/微信:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com
.makop加密数据库恢复
联系：手机/微信(+86 17813235971) QQ(107644445)
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
接到一起sql server数据库被勒索病毒加密恢复请求
通过分析，数据库加密损坏部分较少,可以对其进行恢复
通过技术处理，表数据正常恢复
如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持，请联系我们:
电话/微信:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com
.eking加密数据库恢复
联系：手机/微信(+86 17813235971) QQ(107644445)
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
接到一个客户的oracle数据文件被加密的恢复请求,文件被加密为扩展名为:.id[76B8C076-3009].[decrypt20@firemail.cc].eking,通过底层分析,确认该文件被加密破坏较少
通过自研的工具对数据文件进行恢复
实现数据库正常open,并使用exp进行导出
如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持，请联系我们:
电话/微信:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com
19c sqlplus / as sysdba 登录慢分析
联系：手机/微信(+86 17813235971) QQ(107644445)
标题：19c sqlplus / as sysdba 登录慢分析
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
sqlplus / as sysdba登录非常慢
[oracle@xifenfei trace]$ date Fri Oct 29 00:04:27 CST 2021 [oracle@xifenfei trace]$ sqlplus / as sysdba<< EOF > exit; > EOF SQL*Plus: Release 19.0.0.0.0 - Production on Fri Oct 29 00:04:28 2021 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL> Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 [oracle@xifenfei trace]$ date Fri Oct 29 00:04:49 CST 2021
sqlpus 一个简单的登录+退出使用了22秒,严重的慢,通过strace分析发现访问以下两个ip，但是10.11.0.41非常慢,10.13.0.41很快，并且通过一些信息53端口,判断可能是dns服务器的ip
connect(9, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.13.0.41")}, 16) = 0
connect(12, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.11.0.41")}, 16) = 0
进一步确认,确认是该服务器配置的dns服务器
[root@xifenfei ~]# cat /etc/resolv.conf # Generated by NetworkManager nameserver 10.13.0.41 nameserver 10.11.0.41
对这两个ip的连通性进行测试
[root@xifenfei ~]# ping 10.13.0.41 PING 10.13.0.41 (10.13.0.41) 56(84) bytes of data. 64 bytes from 10.13.0.41: icmp_seq=1 ttl=126 time=0.616 ms ^C --- 10.13.0.41 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.616/0.616/0.616/0.000 ms [root@xifenfei ~]# ping 10.11.0.41 PING 10.11.0.41 (10.11.0.41) 56(84) bytes of data. ^C --- 10.11.0.41 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2063ms [root@xifenfei ~]#
确认10.11.0.41 ip不通,对于此类问题最快的解决方案就是除掉不可使用的dns服务器,然后测试登录和退出时间
[oracle@szd18dbts01 trace]$ date Fri Oct 29 00:21:12 CST 2021 [oracle@szd18dbts01 trace]$ sqlplus / as sysdba<< EOF > exit; > EOF SQL*Plus: Release 19.0.0.0.0 - Production on Fri Oct 29 00:21:12 2021 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. date Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 SQL> Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.3.0.0.0 [oracle@szd18dbts01 trace]$ date Fri Oct 29 00:21:13 CST 2021
通过除掉不可用的dns服务器ip之后,测试时间为1s,恢复正常