标签云
asm 恢复 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 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)
- 操作系统 (100)
- 数据库 (1,597)
- DB2 (22)
- MySQL (70)
- Oracle (1,463)
- Data Guard (49)
- EXADATA (7)
- GoldenGate (21)
- ORA-xxxxx (158)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (13)
- ORACLE 21C (3)
- Oracle ASM (65)
- Oracle Bug (7)
- Oracle RAC (47)
- Oracle 安全 (6)
- Oracle 开发 (27)
- Oracle 监听 (27)
- Oracle备份恢复 (530)
- Oracle安装升级 (84)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (75)
- PostgreSQL (17)
- PostgreSQL恢复 (5)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (36)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (19)
-
最近发表
- Oracle 19c/21c最新patch信息-202404
- PostgreSQL恢复系列:pg_filedump批量处理
- PostgreSQL部分主要字典信息
- PostgreSQL恢复系列:pg_filedump恢复字典构造
- PostgreSQL 16 源码安装
- ORA-00742 ORA-00312 恢复
- 数据库open成功后报ORA-00353 ORA-00354错误引起的一系列问题(本质ntfs文件系统异常)
- ORA-600 ktsiseginfo1故障
- ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因
- 最近遇到几起ORA-600 16703故障(tab$被清空),请引起重视
- ORA-600 2662快速恢复之Patch scn工具
- TNS-12518: TNS:listener could not hand off client connection
- ora.storage无法启动报ORA-12514故障处理
- 断电引起文件scn异常数据库恢复
- ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
- .[hudsonL@cock.li].mkp勒索加密数据库完美恢复
- 模拟带库实现rman远程备份
- 又一例:ORA-600 kclchkblk_4和2662故障
- Oracle误删除数据文件恢复
- Oracle 19C 备库DML重定向—DML Redirection
月归档:五月 2020
12.2数据库启动报ORA-07445 lmebucp错误
有一个客户找到我们,说他们是数据库启动之时报的错误和数据库不能open 报ORA-7445 lmebucp错类似,让我们对其进行恢复支持,通过分析确定客户数据库版本为12.2.0.1
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Productio PL/SQL Release 12.2.0.1.0 - Production CORE 12.2.0.1.0 Production TNS for Linux: Version 12.2.0.1.0 - Production NLSRTL Version 12.2.0.1.0 - Production
alert日志报错
--最初报错 2020-05-11T03:43:06.787164+08:00 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m004_3253.trc (incident=639048): ORA-00600: 内部错误代码, 参数: [kkpo_rcinfo_defstg:delseg], [72280], [], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_639048/orcl_m004_3253_i639048.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2020-05-11T03:43:14.250993+08:00 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m004_3253.trc (incident=639049): ORA-00600: 内部错误代码, 参数: [kkpo_rcinfo_defstg:delseg], [72280], [], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_639049/orcl_m004_3253_i639049.trc 2020-05-11T03:43:21.286310+08:00 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m004_3253.trc (incident=639050): ORA-00600: 内部错误代码, 参数: [kkpo_rcinfo_defstg:delseg], [72280], [], [], [], [], [], [], [], [], [], [] ORA-06512: 在 line 2 Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_639050/orcl_m004_3253_i639050.trc 2020-05-11T03:43:28.059048+08:00 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2020-05-11T03:43:28.074681+08:00 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m004_3253.trc: ORA-00600: 内部错误代码, 参数: [kkpo_rcinfo_defstg:delseg], [72280], [], [], [], [], [], [], [], [], [], [] ORA-06512: 在 line 2 2020-05-11T08:31:22.416087+08:00 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j000_16511.trc: ORA-12012: 自动执行作业 141 出错 ORA-30732: 表中不包含用户可见的列 ORA-06512: 在 line 1 ---关闭数据库之后重启报错 2020-05-11T09:42:43.234769+08:00 ALTER DATABASE OPEN 2020-05-11T09:42:44.353085+08:00 Ping without log force is disabled: instance mounted in exclusive mode. Endian type of dictionary set to little 2020-05-11T09:42:44.660388+08:00 TT00: Gap Manager starting (PID:31134) 2020-05-11T09:42:45.180876+08:00 Thread 1 opened at log sequence 78596 Current log# 2 seq# 78596 mem# 0: /u01/app/oracle/oradata/orcl/redo02.log Successful open of redo thread 1 2020-05-11T09:42:45.181357+08:00 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Exception [type: SIGSEGV, Address not mapped to object][ADDR:0x0][PC:0x10F4C112, lmebucp()+34][flags: 0x0, count: 1] Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_31125.trc (incident=646445): ORA-07445: exception encountered:core dump[lmebucp()+34][SIGSEGV][ADDR:0x0][PC:0x10F4C112][Address not mapped to object] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_646445/orcl_ora_31125_i646445.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2020-05-11T09:42:46.070049+08:00 ***************************************************************** An internal routine has requested a dump of selected redo. This usually happens following a specific internal error, when analysis of the redo logs will help Oracle Support with the diagnosis. It is recommended that you retain all the redo logs generated (by all the instances) during the past 12 hours, in case additional redo dumps are required to help with the diagnosis. ***************************************************************** 2020-05-11T09:42:53.344955+08:00 Instance Critical Process (pid: 41, ospid: 31125) died unexpectedly PMON (ospid: 31026): terminating the instance due to error 12752 2020-05-11T09:42:53.377209+08:00 System state dump requested by (instance=1, osid=31026 (PMON)), summary=[abnormal instance termination]. System State dumped to trace file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_diag_31046_20200511094253.trc 2020-05-11T09:42:56.690224+08:00 Instance terminated by PMON, pid = 31026
对启动过程做10046跟踪
PARSING IN CURSOR #139821999713040 len=65 dep=1 uid=0 oct=3 lid=0 tim=2200910467 hv=1762642493 ad='1bfd79130'sqlid='aps3qh1nhzkjx' select line#, sql_text from bootstrap$ where obj# not in (:1, :2) END OF STMT PARSE #139821999713040:c=378,e=378,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=2200910467 BINDS #139821999713040: Bind#0 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=1000001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=7f2ad89fe6c8 bln=22 avl=02 flg=05 value=59 Bind#1 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=1000001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=7f2ad89fe698 bln=24 avl=06 flg=05 value=4294967295 EXEC #139821999713040:c=219,e=658,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=867914364,tim=2200911218 WAIT #139821999713040: nam='db file sequential read' ela= 9 file#=1 block#=520 blocks=1 obj#=59 tim=2200911300 WAIT #139821999713040: nam='db file scattered read' ela= 19 file#=1 block#=521 blocks=3 obj#=59 tim=2200911559 FETCH #139821999713040:c=404,e=404,p=4,cr=5,cu=0,mis=0,r=0,dep=1,og=4,plh=867914364,tim=2200911646 STAT #139821999713040 id=1 cnt=0 pid=0 pos=1 obj=59 op='TABLE ACCESS FULL BOOTSTRAP$ (cr=5 pr=4 pw=0 str=1 time=406 us)' *** 2020-05-11T12:25:30.977832+08:00 Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x10F4C112, lmebucp()+34] [flags: 0x0, count: 1] 2020-05-11T12:25:31.026914+08:00 Incident 718445 created, dump file:/u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_718445/orcl_ora_14324_i718445.trc ORA-07445: exception encountered:core dump [lmebucp()+34][SIGSEGV][ADDR:0x0][PC:0x10F4C112][Address not mapped to object]
根据该报错,可以大概定位数据库重启之后报ORA-07445 lmebucp()+34错误不能正常启动是由于bootstrap$表异常导致.
BBED> p kcvfhrdb ub4 kcvfhrdb @96 0x00400208 BBED> set block 523 BLOCK# 523 BBED> map File: F:\temp\12.2\1\system01.dbf (0) Block: 523 Dba:0x00000000 ------------------------------------------------------------ KTB Data Block (Table/Cluster) struct kcbh, 20 bytes @0 struct ktbbh, 48 bytes @20 struct kdbh, 14 bytes @68 struct kdbt[1], 4 bytes @82 sb2 kdbr[20] @86 ub1 freespace[1015] @126 ub1 rowdata[7047] @1141 ub4 tailchk @8188 BBED> p *kdbr[1] rowdata[6431] ------------- ub1 rowdata[6431] @7572 0x3c BBED> x /rnnc rowdata[6431] @7572 ------------- flag@7572: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH) lock@7573: 0x01 cols@7574: 0
通过bbed定位rootdba,然后dump相关block,随机找一条记录,确认bootstrap表无后效记录.但是该数据库在重启之前已经报了ORA-600 kkpo_rcinfo_defstg:delseg和ORA-30732错误,很可能还有其他的基表异常.通过先修复bootstrap$记录,然后根据该表中记录分析其他相关表记录,最终确定tab$中记录也异常,通过bbed 批量循环修复方法,对其进行恢复,open数据库,可以验证数据没有问题.至此该问题解决,但是没有找出来故障原因(是人为破坏【直接人工删除】,还是某种工具带入恶意脚本导致,类似:plsql dev引起的数据库被黑勒索比特币实现原理分析和解决方案,亦或者是数据库安装介质带有恶意程序,类似:警告:互联网中有oracle介质被注入恶意程序导致—ORA-600 16703)
又一起mysql rm删除数据库目录事故
有mysql用户直接使用rm命令删除了所在数据库目录文件夹(删除途中发现删除错误,直接强制终止使得部分删除,部分文件得以保留),如果数据库没有crash,这个问题不大,可以直接通过句柄进行恢复出来对应的ibd文件,然后进行一些特殊处理,数据理论上不会有丢失,参见:mysql 数据库目录被删除恢复.对于这次的情况,只能通过文件系统级别进行恢复,不过该数据库表比较多,大概删除了几千个文件,而且文件系统是ext4,导致大量文件目录被置空,而且该库还运行了一段时间
看来文件恢复删除这条路,基本上很难走得通,可以通过底层碎片技术恢复,通过底层扫描,找到不少碎片
由于涉及的库表多,一个个处理太费时间,通过批量脚本直接解析扫描出来的碎片,并且对其进行入库处理
DBLOGIN=”-uroot ”
DICT_DBNAME=test
RECOVER_DBNAME=xifenfei
WORK_PATH=”/nfs_share/mysql-xff”
cd $WORK_PATH
>/tmp/recover_table_list.$RECOVER_DBNAME
>/tmp/recover_table_parser.$RECOVER_DBNAME
>/tmp/recover_table_unload.$RECOVER_DBNAME
rm -rf /tmp/recover_table_unload_$RECOVER_DBNAME.tmp
echo “tee /tmp/recover_table_unload_$RECOVER_DBNAME.tmp” >/tmp/recover_table_unload.$RECOVER_DBNAME
echo “SET @enable_trigger = 0;”>>/tmp/recover_table_unload.$RECOVER_DBNAME
echo “SET FOREIGN_KEY_CHECKS=0;” >>/tmp/recover_table_unload.$RECOVER_DBNAME
for TABLE_NAME_ID in `mysql $DBLOGIN $DICT_DBNAME -NBe “SELECT SYS_TABLES.NAME FROM SYS_TABLES LEFT JOIN SYS_INDEXES ON SYS_TABLES.ID = SYS_INDEXES.TABLE_ID WHERE SYS_INDEXES.NAME IN (‘PRIMARY’, ‘GENERAL_CLUSTERED_INDEX’) AND SYS_TABLES.NAME LIKE ‘${RECOVER_DBNAME}/%’”`
do
PKEY=`mysql $DBLOGIN $DICT_DBNAME -NBe “SELECT SYS_INDEXES.ID FROM SYS_TABLES LEFT JOIN SYS_INDEXES ON SYS_TABLES.ID = SYS_INDEXES.TABLE_ID WHERE SYS_INDEXES.NAME IN (‘PRIMARY’, ‘GENERAL_CLUSTERED_INDEX’) AND SYS_TABLES.NAME=’$TABLE_NAME_ID’”`
echo $TABLE_NAME_ID’,’$PKEY >>/tmp/recover_table_list.$RECOVER_DBNAME
TABLE_NAME=$(echo `echo $TABLE_NAME_ID`|awk -F”/” ‘{print $2}’ )
#echo $TABLE_NAME
PAGE=”pages-ibdata1/FIL_PAGE_INDEX/`printf ‘%016u’ ${PKEY}`.page”
echo “./c_parser -5f $PAGE -b pages-ibdata1/FIL_PAGE_TYPE_BLOB -t dictionary/$TABLE_NAME.sql > dumps/default/$TABLE_NAME 2> dumps/default/$TABLE_NAME.sql” >>/tmp/recover_table_parser.$RECOVER_DBNAME
echo “source dumps/default/$TABLE_NAME.sql” >>/tmp/recover_table_unload.$RECOVER_DBNAME
echo “select ‘$TABLE_NAME.sql……done’;”>>/tmp/recover_table_unload.$RECOVER_DBNAME
done
echo /tmp/recover_table_parser.$RECOVER_DBNAME
echo /tmp/recover_table_unload.$RECOVER_DBNAME
恢复之后数据整体入库,查询部分没有覆盖表,效果尚可,最大限度抢救了数据
.SATANA加密数据文件恢复
有朋友win环境中运行oracle数据库文件被加密,扩展名为:.SATANA
对应的how_to_back_files.html文件内容如下:
通过分析此类文件,可以实现数据绝大部分恢复
如果你遇到类似加密病毒并加密的数据库(oracle,mysql,sql server),可以联系我们在不给黑客交款的情况下实现较好恢复效果(恢复不成功不收取任何费用)
Tel/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com提供专业的解密恢复服务.
防护建议:
1.多台机器,不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性,并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制,并进行定期备份
4.定期检测系统和软件中的安全漏洞,及时打上补丁。
5.定期到服务器检查是否存在异常。查看范围包括:
a)是否有新增账户
b) Guest是否被启用
c) Windows系统日志是否存在异常
d)杀毒软件是否存在异常拦截情况
6.安装安全防护软件,并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。