标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 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-600 kcratr_nab_less_than_odr 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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,883)
- DB2 (22)
- MySQL (82)
- Oracle (1,708)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (662)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- aix平台Oracle数据库由于断电无法启动故障处理
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
分类目录归档:数据库
ORA-12547: TNS:lost contact故障一例
一个朋友安装好aix平台11.2.0.4 rac,dbca创建库报ORA-12547错误.

尝试sqlplus 登录数据库
$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Thu Nov 17 11:45:33 2022 Copyright (c) 1982, 2013, Oracle. All rights reserved. ERROR: ORA-12547: TNS:lost contact Enter user-name: ERROR: ORA-12547: TNS:lost contact Enter user-name: ERROR: ORA-12547: TNS:lost contact SP2-0157: unable to CONNECT to ORACLE after 3 attempts, exiting SQL*Plus
使用truss跟踪sqlplus 执行过程,卡在kfork上面

检查oracle二进制文件权限,正常
$ ls -l $ORACLE_HOME/bin/oracle -rwsr-s--x 1 oracle oinstall 309671362 Nov 17 03:13 /u01/app/oracle/product/11.2.0/db/bin/oracle
经过分析确认是oracle home权限异常
$ ls -ld $ORACLE_HOME drwxrwxr-x 74 grid oinstall 4096 Nov 17 02:59 /u01/app/oracle/product/11.2.0/db $ exit # chown oracle:oinstall /u01/app/oracle/product/11.2.0/db
sqlplus和dbca都正常
$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Thu Nov 17 11:46:32 2022 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to an idle instance. SQL> exit Disconnected
rac kill 大事物后回滚慢,smon等待DFS lock handle和enq: TX – contention
Customer killed a large DELETE statement of a large table in instance 1 in high workload period in RAC environment of 2 instances.
Transaction recovery did not yet complete for more than 1 hour by querying V$FAST_START_TRANSACTIONS.
Update on the same table on instance 2 hung more than 1 hour.
Transaction recovery complete quickly after shutdown instance 2.
ASH shows high waiting on “enq: TX – row lock contention” and “transaction” without blocking session until instance 2 shutdown after DELETE session killed in instance 1
SQL> select instance_number,program,event,BLOCKING_INST_ID b_inst,count(session_id) session_cnt,
count(BLOCKING_SESSION) b_session_cnt,min(sample_time) start_time,max(sample_time) end_time,count(*) cnt
2 from DBA_HIST_ACTIVE_SESS_HISTORY where sql_id='d1xg4v7rqx3kt' and instance_number=2
group by instance_number,program,event,BLOCKING_INST_ID
order by instance_number,start_time
3 4 5 ;
INSTANCE_NUMBER PROGRAM EVENT B_INST SESSION_CNT B_SESSION_CNT START_TIME END_TIME CNT
--------------- ------------------ ----------------------------- ------ ----------- ------------- ---------- ---------- -------
2 JDBC Thin Client enq: TX - row lock contention 728939 0 19:20:34 21:04:25 728939
2 JDBC Thin Client transaction 489837 0 20:12:44 21:04:25 489837
ASH shows that all sessions of the “enq: TX – row lock contention” without blocking session on instance 2 were waiting for the transaction of the Killed DELETE on instance 1
SQL> select instance_number,event,trunc(p2/65536) XIDUSN, trunc(mod(p2,65536)) XIDSLOT,
p3 XIDSQN,count(session_id) session_cnt,count(BLOCKING_SESSION) b_session_cnt,min(sample_time) start_time,max(sample_time) end_time,count(*) cnt
from DBA_HIST_ACTIVE_SESS_HISTORY where sql_id='d1xg4v7rqx3kt' and instance_number=2 and
to_char(sample_time,'HH24:MI') >= '20:12' AND BLOCKING_SESSION IS NULL AND EVENT='enq: TX - row lock contention'
group by instance_number,event,trunc(p2/65536) , trunc(mod(p2,65536)) , p3
order by start_time
;
2 3 4 5
INSTANCE_NUMBER EVENT XIDUSN XIDSLOT XIDSQN SESSION_CNT B_SESSION_CNT START_TIME END_TIME CNT
--------------- ------------------------------ -------- -------- -------- ----------- ------------- ---------- ---------- ------
2 enq: TX - row lock contention 932 15 623055 717850 0 20:12:55 21:04:25 717850
SQL>
ASH shows that SMON of instance 1 was waiting for “DFS lock handle” and “enq: TX – contention” among DELETE session killed in instance 1 and instance 2 shutdown.
SQL> select instance_number,session_id,session_serial#,program,event,BLOCKING_SESSION b_sid,
BLOCKING_SESSION_SERIAL# b_serial,BLOCKING_INST_ID b_inst,min(sample_time) start_time,
max(sample_time) end_time,count(*) cnt
from DBA_HIST_ACTIVE_SESS_HISTORY where upper(program) like '%SMON%'
group by instance_number,session_id,session_serial#,program,event,BLOCKING_SESSION ,BLOCKING_SESSION_SERIAL# ,BLOCKING_INST_ID
order by instance_number,start_time
;
INSTANCE_NUMBER SESSION_ID SESSION_SERIAL# PROGRAM EVENT B_SID B_SERIAL B_INST START_TIME END_TIME CNT
--------------- ---------- --------------- ----------------------------- --------------------- ----- --------- ------ ---------- ---------- ---
1 3761 1 oracle@<instance_name> (SMON) DFS lock handle 19:05:24 21:05:07 128
1 3761 1 oracle@<instance_name> (SMON) enq: TX - contention 20:14:31 21:04:47 50
The P1 of “DFS lock handle” shows that SMON was requesting TA enqueue through cross instance calls which is used for serializing operations on undo segments and undo tablespaces
SQL> col event for a20
select instance_number,sample_time,session_id,session_serial#,program,event,p1,p2,p3
from DBA_HIST_ACTIVE_SESS_HISTORY where upper(program) like '%SMON%' AND EVENT='DFS lock handle' ;
SQL> 2
INSTANCE_NUMBER SAMPLE_TIME SESSION_ID SESSION_SERIAL# PROGRAM EVENT P1 P2 P3
--------------- --------------- ---------- --------------- ----------------------------- ---------------- ------------ ------ ------
1 19:05:24 3761 1 oracle@<instance_name> (SMON) DFS lock handle 1413545989 3 4722
1 20:12:27 3761 1 oracle@<instance_name> (SMON) DFS lock handle 1413545989 3 6668
1 20:13:40 3761 1 oracle@<instance_name> (SMON) DFS lock handle 1413545989 3 5787
1 20:13:50 3761 1 oracle@<instance_name> (SMON) DFS lock handle 1413545989 3 5580
1 20:14:00 3761 1 oracle@<instance_name> (SMON) DFS lock handle 1413545989 3 5826
... ...
1 21:04:57 3761 1 oracle@<instance_name> (SMON) DFS lock handle 1413545989 3 1347
1 21:05:07 3761 1 oracle@<instance_name> (SMON) DFS lock handle 1413545989 3 4582
144 rows selected.
* All of P1 is 1413545989, converted to hexadecimal: 54410005, 54 ASCII code: T, 41 ASCII code: A => TA enqueue
The P2,P3 of “enq: TX – row lock contention” shows that SMON process was requesting TX enqueue of the UNDO block of the transaction of the Killed DELETE on instance 1.
SQL> select instance_number,session_id,session_serial#,program,event,trunc(p2/65536) XIDUSN, trunc(mod(p2,65536)) XIDSLOT, p3 XIDSQN,COUNT(1) CNT,min(sample_time) start_time,max(sample_time) end_time
from DBA_HIST_ACTIVE_SESS_HISTORY WHERE session_id =3761 and SESSION_SERIAL# = 1 and instance_number=1 AND event like 'enq: TX - contention%'
group by instance_number,session_id,session_serial#,program,event,trunc(p2/65536) , trunc(mod(p2,65536)) , p3
;
2 3 4
INSTANCE_NUMBER SESSION_ID SESSION_SERIAL# PROGRAM EVENT XIDUSN XIDSLOT XIDSQN CNT START_TIME END_TIME
--------------- ---------- --------------- ------------------------------ -------------------- -------- -------- -------- --- ---------- ----------
1 3761 1 oracle@<instance_name> (SMON) enq: TX - contention 932 15 623055 50 20:14:31 21:04:47
SQL>
SQL> select instance_number,session_id,session_serial#,program,event,CURRENT_OBJ#, CURRENT_FILE#, CURRENT_BLOCK#,CURRENT_ROW#,COUNT(1) CNT,min(sample_time) start_time,max(sample_time) end_time
2 from DBA_HIST_ACTIVE_SESS_HISTORY WHERE session_id =3761 and SESSION_SERIAL# = 1 and instance_number=1 AND event like 'enq: TX - contention%'
group by instance_number,session_id,session_serial#,program,event,CURRENT_OBJ#, CURRENT_FILE#, CURRENT_BLOCK#,CURRENT_ROW#
order by start_time
;
3 4 5
INSTANCE_NUMBER SESSION_ID SESSION_SERIAL# PROGRAM EVENT CURRENT_OBJ# CURRENT_FILE# CURRENT_BLOCK# CURRENT_ROW# CNT START_TIME END_TIME
--------------- ---------- --------------- ----------------------------- -------------------- ------------ ------------- -------------- ------------ ----- ---------- ----------
1 3761 1 oracle@<instance_name> (SMON) enq: TX - contention 1 42 4 0 1 20:14:31 20:14:31
1 3761 1 oracle@<instance_name> (SMON) enq: TX - contention 1 3 3 0 1 20:16:22 20:16:22 <<<<CURRENT_FILE#:3 ==>UNDO
1 3761 1 oracle@<instance_name> (SMON) enq: TX - contention 1 3 5 0 4 20:22:17 20:25:49 <<<<CURRENT_FILE#:3 ==>UNDO
1 3761 1 oracle@<instance_name> (SMON) enq: TX - contention 0 3 1920 0 3 20:30:13 20:30:33 <<<<CURRENT_FILE#:3 ==>UNDO
1 3761 1 oracle@<instance_name> (SMON) enq: TX - contention 0 3 15728 0 23 20:37:58 20:52:39 <<<<CURRENT_FILE#:3 ==>UNDO
1 3761 1 oracle@<instance_name> (SMON) enq: TX - contention 1 1002 2 0 18 20:53:09 21:04:47
6 rows selected.
SQL>
解决方案
Please avoid to kill large transaction during high workload period.
If has to kill large transaction, shutdown all remote instances can speed up the transaction recovery.
参考:Transaction Recovery Slow And High Row Lock Contention After Killed Large Transaction in RAC (Doc ID 2668617.1)
最近两种加密oracle数据库文件勒索病毒可以实现直接open数据库恢复
最近接触到两种被加密的oracle数据库,可以实现数据库层面直接open库,通过oracle exp/expdp导出数据,业务直接使用,而不是通过类似dul方式恢复数据,然后业务整合花费大量时间的恢复
.DBF.[DAF1737E].[helprequest@techmail.info].mkp(被加密破坏32个block,对于11g+版本数据库,可以实现完美恢复,所有写入数据文件数据0丢失)

.DBF.id[B482CBD6-2815].[tsai_shen@zohomail.eu].eight(被加密192个block,对于11g+版本数据库,可以实现每个文件丢失数据1M左右的恢复)

以上两种勒索病毒加密的oracle数据库都可以通过Oracle数据文件加密勒索恢复工具实现快速恢复并且顺利open数据导出数据

如果有oracle数据库被加密,希望快速恢复业务(基本上和数据库exp/expdp导出数据效果一样),可以联系我们,提供最大限度数据恢复,数据库层面最完美的恢复效果

加我微信(17813235971)
加我QQ(107644445)

