Monthly Archives: 三月 2025

ORA-600 krhpfh_03-1208

Posted on by

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：ORA-600 krhpfh_03-1208

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

最近一个客户咨询一个问题,他正常的drop tbs,结果触发ORA-600 krhpfh_03-1208 错误,导致数据库crash

Wed Mar 26 14:33:20 2025
Thread 1 cannot allocate new log, sequence 478485
Checkpoint not complete
  Current log# 2 seq# 478484 mem# 0: /apps/data/oracle/orcl/redo02.log
Thread 1 advanced to log sequence 478485 (LGWR switch)
  Current log# 3 seq# 478485 mem# 0: /apps/data/oracle/orcl/redo03.log
Wed Mar 26 14:35:06 2025
Wed Mar 26 14:35:06 2025
drop tablespace XFF_MON_2016 including contents and datafiles cascade constraint
Read of datafile '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf' (fno 17) header failed with ORA-01208
Rereading datafile 17 header failed with ORA-01208
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_188213.trc  (incident=7677):
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: 数据库文件 17 验证失败
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: 数据文件是旧的版本 - 不能访问当前版本
Incident details in: /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_7677/orcl_ora_188213_i7677.trc
Wed Mar 26 14:35:07 2025
Trace dumping is performing id=[cdmp_20250326143507]
ORA-600 signalled during: drop tablespace XFF_MON_2016 including contents and datafiles cascade constraint...
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_188213.trc  (incident=7678):
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: 数据库文件 17 验证失败
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: 数据文件是旧的版本 - 不能访问当前版本
Incident details in: /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_7678/orcl_ora_188213_i7678.trc
Wed Mar 26 14:35:08 2025
Sweep [inc][7678]: completed
Sweep [inc][7677]: completed
Sweep [inc2][7677]: completed
Wed Mar 26 14:35:09 2025
Thread 1 cannot allocate new log, sequence 478486
Checkpoint not complete
  Current log# 3 seq# 478485 mem# 0: /apps/data/oracle/orcl/redo03.log
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_188213.trc  (incident=7679):
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: 数据库文件 17 验证失败
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: 数据文件是旧的版本 - 不能访问当前版本
Incident details in: /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_7679/orcl_ora_188213_i7679.trc
Trace dumping is performing id=[cdmp_20250326143511]
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_188213.trc:
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: 数据库文件 17 验证失败
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: 数据文件是旧的版本 - 不能访问当前版本
Thread 1 advanced to log sequence 478486 (LGWR switch)
  Current log# 1 seq# 478486 mem# 0: /apps/data/oracle/orcl/redo01.log
Wed Mar 26 14:35:13 2025
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_188213.trc  (incident=15551):
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: database file 17 failed verification check
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: data file is an old version - not accessing current version
Incident details in: /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_15551/orcl_ora_188213_i15551.trc
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_15551/orcl_ora_188213_i15551.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: database file 17 failed verification check
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: data file is an old version - not accessing current version
Trace dumping is performing id=[cdmp_20250326143514]
Wed Mar 26 14:35:15 2025
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_pmon_139367.trc  (incident=7224):
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
Incident details in: /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_7224/orcl_pmon_139367_i7224.trc
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_pmon_139367.trc:
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
Wed Mar 26 14:35:19 2025
drop tablespace XFF_MON_2016 including contents and datafiles cascade constraint
Wed Mar 26 14:35:20 2025
DBW0 (ospid: 139390): terminating the instance due to error 472
Instance terminated by DBW0, pid = 139390

这个报错信息看,但是发起drop tbs之后,数据库应该是检查file 17号文件的状态,发现这个版本状态过旧(ORA-01208: 数据文件是旧的版本),由于某种原因报出来了krhpfh_03-1208,导致数据库crash了,然后他尝试启动数据库报ORA-01113: file 17 needs media recovery

Wed Mar 26 17:11:00 2025
Starting ORACLE instance (normal)
Wed Mar 26 17:11:17 2025
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Wed Mar 26 17:11:28 2025
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =168
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options.
Using parameter settings in server-side spfile /apps/svr/oracle/product/11.2.0/dbhome_1/dbs/spfileorcl.ora
System parameters with non-default values:
  processes                = 1000
  sga_target               = 0
  memory_target            = 66048M
  memory_max_target        = 66048M
  control_files            = "/apps/data/oracle/orcl/control01.ctl"
  control_files            = "/apps/svr/oracle/flash_recovery_area/orcl/control02.ctl"
  db_block_size            = 8192
  compatible               = "11.2.0.0.0"
  db_recovery_file_dest    = "/apps/svr/oracle/flash_recovery_area"
  db_recovery_file_dest_size= 3882M
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
  audit_file_dest          = "/apps/svr/oracle/admin/orcl/adump"
  audit_trail              = "DB"
  db_name                  = "orcl"
  open_cursors             = 300
  pga_aggregate_target     = 0
  diagnostic_dest          = "/apps/svr/oracle"
Wed Mar 26 17:11:29 2025
PMON started with pid=2, OS id=28315 
Wed Mar 26 17:11:29 2025
VKTM started with pid=3, OS id=28317 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Wed Mar 26 17:11:29 2025
GEN0 started with pid=4, OS id=28324 
Wed Mar 26 17:11:29 2025
DIAG started with pid=5, OS id=28326 
Wed Mar 26 17:11:29 2025
DBRM started with pid=6, OS id=28328 
Wed Mar 26 17:11:29 2025
PSP0 started with pid=7, OS id=28330 
Wed Mar 26 17:11:29 2025
DIA0 started with pid=9, OS id=28334 
Wed Mar 26 17:11:29 2025
MMAN started with pid=8, OS id=28336 
Wed Mar 26 17:11:29 2025
DBW0 started with pid=10, OS id=28338 
Wed Mar 26 17:11:29 2025
DBW1 started with pid=11, OS id=28340 
Wed Mar 26 17:11:29 2025
DBW2 started with pid=12, OS id=28342 
Wed Mar 26 17:11:29 2025
DBW3 started with pid=13, OS id=28344 
Wed Mar 26 17:11:29 2025
LGWR started with pid=14, OS id=28346 
Wed Mar 26 17:11:29 2025
CKPT started with pid=15, OS id=28348 
Wed Mar 26 17:11:29 2025
SMON started with pid=16, OS id=28350 
Wed Mar 26 17:11:29 2025
RECO started with pid=17, OS id=28352 
Wed Mar 26 17:11:29 2025
MMON started with pid=18, OS id=28354 
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Wed Mar 26 17:11:29 2025
MMNL started with pid=19, OS id=28356 
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /apps/svr/oracle
Wed Mar 26 17:11:29 2025
ALTER DATABASE   MOUNT
Wed Mar 26 17:11:32 2025
Sweep [inc][7679]: completed
Sweep [inc][7224]: completed
Sweep [inc][15551]: completed
Sweep [inc2][7679]: completed
Sweep [inc2][7678]: completed
Sweep [inc2][7224]: completed
Sweep [inc2][15551]: completed
Successful mount of redo thread 1, with mount id 1724539585
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Wed Mar 26 17:11:34 2025
ALTER DATABASE OPEN
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_28406.trc:
ORA-01113: file 17 needs media recovery
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-1113 signalled during: ALTER DATABASE OPEN...

由于现场已经破坏,无法分析当时库的情况和17号文件的具体情况做进一步判断,只能通过日志记录下这个类型的错误.
在oracle中关于ORA-600 krhpfh_03的bug也比较多
ORA-600-krhpfh_03

VMware勒索加密恢复(vmdk勒索恢复)

Posted on by

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：VMware勒索加密恢复(vmdk勒索恢复)

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

客户运行VMware Esxi由于被黑客攻破,导致所有的vmdk文件均被加密,其中包含大量的数据库虚拟机,这段时间,客户找了不少人进行分析恢复,要不就是恢复效果不好,要不就是要加太高,通过底层分析,确认可以比较完美的恢复,包括虚拟机直接运行的mysql、oracle数据库,docker中运行的mysql数据库,那其中一个恢复case来说明,被加密的虚拟机文件是一个500G的vmkd文件(.vmdk.{74C1B740-FEC0-01BD-914B-5F2CBAAA094E}.tianrui)
通过工具对其扫描,该磁盘采用的是lvm方式管理
lvm1
lvm2

lvm中的文件采用的是xfs格式文件系统,对其进行解析,并直接看到oracle数据库文件
lvm_oracle111
lvm_oracle
把相关oracle数据库相关文件恢复出来,然后使用工具检测无坏块,直接上传到服务器中,直接open库,实现oracle数据库完美恢复
对于类似这种被加密的勒索的虚拟机,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持，请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
系统安全防护措施建议：
1.多台机器，不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性，并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制，并进行定期备份
4.定期检测系统和软件中的安全漏洞，及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件，并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。
9.保存良好的备份习惯，尽量做到每日备份，异地备份。

ORA-39773: parse of metadata stream failed故障处理

Posted on by

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：ORA-39773: parse of metadata stream failed故障处理

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

客户expdp导出数据,在写入生成SYS_EXPORT_SCHEMA表所在的users表空间不足,导致expdp报部分异常

Export: Release 11.2.0.4.0 - Production on Thu Feb 27 15:12:36 2025

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
;;; 
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
FLASHBACK automatically enabled to preserve database integrity.
Starting "XFF"."SYS_EXPORT_SCHEMA_95":XFF/**** directory=DUMP dumpfile=20250227.dmp logfile=20250227.log schemas=XFF 
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
Total estimation using BLOCKS method: 481.9 GB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TYPE/TYPE_SPEC
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/PACKAGE/PACKAGE_SPEC
Processing object type SCHEMA_EXPORT/FUNCTION/FUNCTION
Processing object type SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Processing object type SCHEMA_EXPORT/PACKAGE/COMPILE_PACKAGE/PACKAGE_SPEC/ALTER_PACKAGE_SPEC
Processing object type SCHEMA_EXPORT/FUNCTION/ALTER_FUNCTION
Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/INDEX/FUNCTIONAL_INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/FUNCTIONAL_INDEX/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/VIEW/VIEW
Processing object type SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY
Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
. . exported "XFF"."PUB_WORKINGTASKLOG"              88.09 GB  112681 rows
. . exported "XFF"."SM_BUSILOG_DEFAULT"              51.94 GB 3149092 rows
. . exported "XFF"."FFW_DISTRIBUTESUBTASK"           46.47 GB  552214 rows
. . exported "XFF"."GL_DETAIL"                       11.32 GB 16214805 rows
…………
. . exported "XFF"."ZDP_10000000RR8NKX"                  0 KB       0 rows
. . exported "XFF"."ZDP_10000000RTB1GI"                  0 KB       0 rows
. . exported "XFF"."ZDP_10000000RTB1GK"                  0 KB       0 rows
Master table "XFF"."SYS_EXPORT_SCHEMA_95" successfully loaded/unloaded
******************************************************************************
Dump file set for XFF.SYS_EXPORT_SCHEMA_95 is:
  /rman_bak/dump/20200227.dmp
Job "XFF"."SYS_EXPORT_SCHEMA_95" completed with 10 error(s) at Thu Feb 27 19:32:22 2025 elapsed 0 04:16:28

尝试把该dmp导入数据库,报ORA-31694/ORA-02354/ORA-39773错误

Import: Release 11.2.0.4.0 - Production on 星期日 3月 16 02:38:14 2025

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
ORA-31694: 加载/卸载主表 "XFF"."SYS_IMPORT_FULL_01" 失败
ORA-02354: 导出/导入数据时出错
ORA-39773: parse of metadata stream failed

客户需要恢复其中的GL_DETAIL表数据,通过dul实现expdp dump文件转换sqlldr格式方法进行恢复,实现数据完美恢复
QQ20250322-211130

对于dmp(exp/expdp)文件,我们可以实现比较完美的恢复,最后限度抢救数据.如果你有oracle expdp/exp dmp被加密或者破坏,无法正常导入数据库,可以联系我们对其进行恢复处理:提供(ORACLE数据库恢复技术支持)：
Phone:17813235971    Q Q:107644445    E-Mail:dba@xifenfei.com

sql数据库备份失败—失败: 23(数据错误(循环冗余检查)

Posted on by

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：sql数据库备份失败—失败: 23(数据错误(循环冗余检查)

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户sql server数据库备份失败,提示如下
bk-fail

从这个报错看,比较明显是由于底层(文件系统损坏或者扇区访问异常导致),进一步查看系统事件确认是由于扇区异常导致(设备\Device\HarddiskO\DR0有一个不正确的区块)
disk-error
对于这种情况,当访问到文件所在的损坏扇区位置,就会报io错误,终止访问,文件也无法直接拷贝.通过专业工具对文件进行拷贝恢复确认一些扇区损坏而且被跳过(这部分数据肯定丢失)
sq
由于文件本身跳过了损坏的扇区,需要确认损坏的部分影响哪些对象和哪些类型的损坏,通过DBCC检测出来异常信息如下

消息 8976，级别 16，状态 1，第 1 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)。在扫描过程中未发现页 (1:1577857)，但该页的父级 (1:87825) 和上一页 (1:1576364) 都引用了它。请检查以前的错误消息。
消息 8978，级别 16，状态 1，第 1 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)。页 (1:1577859) 缺少上一页 (1:1577857) 对它的引用。可能是链链接有问题。
消息 8939，级别 16，状态 98，第 1 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)，页 (1:1577857)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 133129 和 -4。
消息 8928，级别 16，状态 1，第 1 行
对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data): 无法处理页 (1:1577857)。有关详细信息，请参阅其他错误消息。


消息 8939，级别 16，状态 98，第 1 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)，页 (1:385339)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 133129 和 -4。
消息 8928，级别 16，状态 1，第 1 行
对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data): 无法处理页 (1:385339)。有关详细信息，请参阅其他错误消息。
消息 8976，级别 16，状态 1，第 1 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)。在扫描过程中未发现页 (1:385339)，但该页的父级 (1:127857) 和上一页 (1:385338) 都引用了它。请检查以前的错误消息。
消息 8978，级别 16，状态 1，第 1 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)。页 (1:1682744) 缺少上一页 (1:385339) 对它的引用。可能是链链接有问题。

然后通过DBCC进行修复,修复成功提示如下

修复: 已为数据库 'myhis' 中的对象 'dbo.h_xxxxx, idx_xxxxx_ckdmx_id' 成功地重新生成了 Nonclustered 索引。
修复: 页 (1:1577857) 已从对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)释放。
消息 8945，级别 16，状态 1，第 6 行
表错误: 将重新生成对象 ID 1478296326，索引 ID 70。
        该错误已修复。
消息 8928，级别 16，状态 1，第 6 行
对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data): 无法处理页 (1:1577857)。有关详细信息，请参阅其他错误消息。
        该错误已修复。
消息 8939，级别 16，状态 98，第 6 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)，页 (1:1577857)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 2057 和 -4。
        该错误已修复。
消息 8976，级别 16，状态 1，第 6 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)。在扫描过程中未发现页 (1:1577857)，但该页的父级 (1:87825) 和上一页 (1:1576364) 都引用了它。请检查以前的错误消息。
        该错误已修复。
消息 8978，级别 16，状态 1，第 6 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)。页 (1:1577859) 缺少上一页 (1:1577857) 对它的引用。可能是链链接有问题。
        该错误已修复。
对象 'h_zysfdmx' 的 365541 页中有 2705291 行。
CHECKDB 在表 'h_xxxxx' (对象 ID 1478296326)中发现 0 个分配错误和 4 个一致性错误。
CHECKDB 在表 'h_xxxxx' (对象 ID 1478296326)中修复了 0 个分配错误和 4 个一致性错误。

修复: 已为数据库 'myhis' 中的对象 'dbo.h_xxx, idx_xxx_ckdmx_id' 成功地重新生成了 Nonclustered 索引。
修复: 页 (1:385339) 已从对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)释放。
消息 8945，级别 16，状态 1，第 6 行
表错误: 将重新生成对象 ID 2005582183，索引 ID 66。
        该错误已修复。
消息 8928，级别 16，状态 1，第 6 行
对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data): 无法处理页 (1:385339)。有关详细信息，请参阅其他错误消息。
        该错误已修复。
消息 8939，级别 16，状态 98，第 6 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)，页 (1:385339)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 2057 和 -4。
        该错误已修复。
消息 8976，级别 16，状态 1，第 6 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)。在扫描过程中未发现页 (1:385339)，但该页的父级 (1:127857) 和上一页 (1:385338) 都引用了它。请检查以前的错误消息。
        该错误已修复。
消息 8978，级别 16，状态 1，第 6 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)。页 (1:1682744) 缺少上一页 (1:385339) 对它的引用。可能是链链接有问题。
        该错误已修复。
对象 'h_sfdmx' 的 1226 页中有 10928 行。
CHECKDB 在表 'h_xxx' (对象 ID 2005582183)中发现 0 个分配错误和 4 个一致性错误。
CHECKDB 在表 'h_xxx' (对象 ID 2005582183)中修复了 0 个分配错误和 4 个一致性错误。

QQ20250320-220759

再次使用DBCC检查数据库,一切正常,没有其他报错.然后在恢复过程中ldf文件也有大量扇区异常,对ldf文件进行截断处理

ALTER DATABASE MYHIS SET RECOVERY SIMPLE;
DBCC SHRINKFILE (MYHIS_log, 0);
ALTER DATABASE MYHIS SET RECOVERY FULL;

vmdk文件被加密恢复(虚拟机文件加密)

Posted on by

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：vmdk文件被加密恢复(虚拟机文件加密)

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户的vm虚拟化平台被勒索病毒加密,扩展名为:.{110DCD0A-295C-27A4-914B-5F2CBAAA094E}.tianrui
tainrui

README.TXT文件内容如下,预留邮箱为:tianrui@mailum.com

I'll try to be brief: 1. It is beneficial for us that your files are decrypted no less than you, 
we don't want to harm you, we just want to get a ransom for our work.
2. Its only takes for us at list 20 minutes after payment to completely decrypt you,
to its original state, it's very simple for us!
3.If you contact decryption companies, you are automatically exposed to publicity,also, 
these companies do not care about your files at all, they only think about their own benefit!
4.They also contact the police. Again, only you suffer from this treatment!
5. We have developed a scheme for your secure decryption without any problems, unlike the above companies,
who just as definitely come to us to decipher you and simply make a profit from you as intermediaries, 
preventing a quick resolution of this issue!

6. In case of refusal to pay, we transfer all your personal data such as (emails, link to panel, 
   payment documents , certificates , personal information of you staff, SQL,ERP,
financial information for other hacker groups) and they will come to you again for sure!

We will also publicize this attack using social networks and other media,
   which will significantly affect your reputation

7. If you contact us no more than 12 hours after the attack, the price is only 50% of the price afterwards!

8. Do not under any circumstances try to decrypt the files yourself; you will simply break them!
         YOU MUST UNDERSTAND THAT THIS IS BIG MARKET AND DATA RECOVERY NEED MONEY ONLY !!!
9.IF YOU CHOOSE TO USE DATA RECOVERY COMPANY ASK THEM 
   FOR DECRYPT TEST FILE FOR YOU IF THEY CANT DO IT DO NOT BELIEVE THEM

10.Do not give data recovery companies acces to your network they make your data cant be decrypted by us - 
for make more money from you !!!!! DO NOT TELL THEM YOUR COMPANY NAME BEFORE THEY GIVE YOU TEST FILE !!!!!! 



Contacts :

Download the (Session) messenger (https://getsession.org)  
You fined me "0585ae8a3c3a688c78cf2e2b2b7df760630377f29c0b36d999862861bdbf93380d"

MAIL:tianrui@mailum.com

通过底层分析,确认vmdk文件可以通过找出来分区信息,确认当时运行的是一个win操作系统
QQ20250320-231317

查看对应分区中数据情况
QQ20250320-231716
对于类似这种被加密的勒索的虚拟机,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持，请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
系统安全防护措施建议：
1.多台机器，不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性，并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制，并进行定期备份
4.定期检测系统和软件中的安全漏洞，及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件，并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。
9.保存良好的备份习惯，尽量做到每日备份，异地备份。