标签云
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,879)
- DB2 (22)
- MySQL (82)
- Oracle (1,705)
- 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备份恢复 (659)
- 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)
-
最近发表
- 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故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
- 快速处理 ORA-01210: data file header is media corrupt 故障
TXChecker初试
当我们对数据库进行异常恢复,很多时候要选择屏蔽回滚段,但是我们有没有办法来评估屏蔽回滚段到底会对我们的数据库的数据产生多大影响呢?其实我们可以通过TXChecker工具来评估数据库undo异常时候受到影响的数据对象有哪些,从而进一步确定是否真的需要对其undo下手处理.
模拟数据异常事务为提交情况
[oracle@xifenfei ~]$ sqlplus / as sysdba SQL*Plus: Release 10.2.0.4.0 - Production on Thu Aug 30 20:32:27 2012 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Connected to an idle instance. SQL> startup; ORACLE instance started. Total System Global Area 318767104 bytes Fixed Size 1267236 bytes Variable Size 100665820 bytes Database Buffers 209715200 bytes Redo Buffers 7118848 bytes Database mounted. Database opened. SQL> create table t_xifenfei tablespace system 2 as 3 select * from dba_objects; Table created. SQL> create table chf.t_xifenfei tablespace users 2 as 3 select * from dba_objects; Table created. SQL> delete from t_xifenfei where rownum<10; 9 rows deleted. SQL> delete from chf.t_xifenfei where rownum<100; 99 rows deleted. SQL> alter system checkpoint; System altered. SQL> shutdow abort; ORACLE instance shut down.
在system和users表空间分别模拟了sys和chf的t_xifenfei表含事务未提交情况
TXChecker用法说明
[oracle@xifenfei txchecker]$ ./TXChecker
TXChecker - v1.4 by Center Of Expertise (COE), Oracle Corporation (build 10/16/07)
Usage is: TXChecker [options]
Options:
-a When scanning datafiles (with -d/-f/-l/-t options) report objects using any of the undo
segments (not just those with errors) (OPTIONAL)
-b For objects found, print the datablock addresses. See readme for further details (OPTIONAL)
-c<controlfile_name> Fully qualified controlfile name to read (MANDATORY)
-d Scan database for active TXs (use when undo not available) (OPTIONAL)
-f<filename> Scan the named datafile for active TXs (OPTIONAL)
-g Indicates you want to find all blocks taking part in transactions with
a USN > than the USN supplied in -x<XID> parameter (same constraints as -w) (OPTIONAL)
-l<listfile> Scan all the datafiles listed in the listfile for active TXs (OPTIONAL)
-m<minutes> Number of minutes used to consider a TX as active (1-120) (DEFAULTS TO 60 MINUTES)
-p Show the names and last known status of the UNDO segments (OPTIONAL)
-s Skip read-only or offline normal datafiles (OPTIONAL)
-t<tablespace> Scan all the datafiles for this tablespace (OPTIONAL)
-u Report ITL entries active if marked with an upper bound ('U' flag) fast commit SCN
instead if active transactions (OPTIONAL)
-w<wrap#> Wrap# for XID in ITL entry to report blocks where wrap# > this one (OPTIONAL)
Must use -x with this option. See the readme for details
-x<XID> XID for transaction wanting to search for (OPTIONAL)
Use format rrrr.ssss.wwwwwwww using Hexadecimal numbers
See the readme for full instructions on using -x, -w and -g options
NOTE: Options -d/-f/-l/-t are exclusive, and only one should be specified.
[/sql]
<strong>TXChecker初始</strong>
1
[oracle@xifenfei txchecker]$ ./TXChecker -c/u01/oracle/oradata/XFF/control01.ctl -d -a
TXChecker - v1.4 by Center Of Expertise (COE), Oracle Corporation (build 10/16/07)
Database Name: XFF Version: 10.2.0
*** Database last checkpointed at 08/30/2012 20:34:43 (SCN: 0xa.0x1e142)
*** Using 60 minutes to find most active transactions (-m60)
*** Undo Segments:
USN: 0 Name: SYSTEM TBS#: 0 File: 1 Block: 9 Instance: 0 SMU: N Status: 3 - Online
SCN: 0000.00000000 XactSQN: 0x00000000 UndoSQN: 0x00000000
USN: 1 Name: _SYSSMU1$ TBS#: 1 File: 2 Block: 9 Instance: 0 SMU: Y Status: 3 - Online
SCN: 000a.000191c3 XactSQN: 0x000000d2 UndoSQN: 0x0000013c
…………省略
USN: 9 Name: _SYSSMU9$ TBS#: 1 File: 2 Block: 137 Instance: 0 SMU: Y Status: 3 - Online
SCN: 000a.000191d8 XactSQN: 0x0000011a UndoSQN: 0x000000dc
USN: 10 Name: _SYSSMU10$ TBS#: 1 File: 2 Block: 153 Instance: 0 SMU: Y Status: 3 - Online
SCN: 000a.000191d7 XactSQN: 0x000000c1 UndoSQN: 0x000000d9
…………省略
USN: 20 Name: _SYSSMU20$ TBS#: 5 File: 5 Block: 153 Instance: 0 SMU: Y Status: 1 - Invalid / Dropped
SCN: 0000.00070ec6 XactSQN: 0x00000002 UndoSQN: 0x00000001
*** Active Transactions:
USN: 6 Name: _SYSSMU6$ File: 2 Block: 89 Instance: 0 Status: 3 - Online
* Active TX at slot 6 #undo blocks: 3 Last bk: 2.90
Obj#: 51938 Name: CHF.T_XIFENFEI Type: TABLE Undo recs: 99
Used undo segment IDs: 6
Obj#: 51937 Name: SYS.T_XIFENFEI Type: TABLE Undo recs: 9
Used undo segment IDs: 6
File (validate_objects.sql) being created for object validattion already exists
and will be overwritten!!!
Do you want to continue overwriting [Y/N]?y
*** Undo segments (headers) that encountered errors preventing Active TX scan:
USN: 11 Name: _SYSSMU11$ File: 5 Block: 9 Instance: 0 Error: 27 - Undo segment was dropped
…………省略
USN: 20 Name: _SYSSMU20$ File: 5 Block: 153 Instance: 0 Error: 27 - Undo segment was dropped
WARNING: Analyzing the full database for active transactions will take some time!
Are you sure you want to analyze the full database [Y/N]?
Are you sure you want to analyze the full database [Y/N]?y
*** Scanning database for datablocks that may require undo (PLEASE WAIT...):
*** Asterisk ('*') denotes blocks being updated since 08/08/2012 03:30:32 (SCN: 0x0.0x79607)
Scanning datafile: 3 - /u01/oracle/oradata/XFF/sysaux01.dbf (SYSAUX) - Active TX blocks: 147 *
Scanning datafile: 1 - /u01/oracle/oradata/XFF/system01.dbf (SYSTEM) - Active TX blocks: 11597 *
--undo表空间跳过
Undo datafile (/u01/oracle/oradata/XFF/undotbs01.dbf) - SKIPPING
Scanning datafile: 4 - /u01/oracle/oradata/XFF/users01.dbf (USERS) - Active TX blocks: 2 *
--因为数据文件丢失控制文件中offline的跳过(其实只要数据文件丢失就会跳过)
Cannot access datafile (/u01/oracle/oradata/XFF/xifenfei01.dbf) (error 2 - No such file or directory) - SKIPPING
Cannot access datafile (/u01/oracle/oradata/XFF/xifenfei02.dbf) (error 2 - No such file or directory) - SKIPPING
Scanning datafile: 7 - /u01/oracle/oradata/XFF/xifenfei03.dbf (XIFENFEI2) - Active TX blocks: 0
*** Objects that may require undo data:
*** Asterisk ('*') denotes blocks being updated since 08/08/2012 03:30:32 (SCN: 0x0.0x79607)
DataObj#: 51938 Name: CHF.T_XIFENFEI Type: TABLE Datablocks: 2 *
Used undo segment IDs: 6
DataObj#: 46434 Name: MDSYS.SYS_IL0000046432C00006$$ Type: INDEX Datablocks: 4
Used undo segment IDs: 2
DataObj#: 124 Name: SYS.I_ACCESS1 Type: INDEX Datablocks: 27
Used undo segment IDs: 1 2 3 4 5 6 7 8 9 10
…………省略
DataObj#: 8824 Name: SYS.SYS_IL0000008822C00008$$ Type: INDEX Datablocks: 1 *
Used undo segment IDs: 4
DataObj#: 51937 Name: SYS.T_XIFENFEI Type: TABLE Datablocks: 1 *
Used undo segment IDs: 6
DataObj#: 51557 Name: SYS.UTL_RECOMP_COMPILED Type: TABLE Datablocks: 1
Used undo segment IDs: 8
…………省略
DataObj#: 42131 Name: XDB.XDB$ELEMENT_PROPNUMBER Type: INDEX Datablocks: 1
Used undo segment IDs: 2
*** Use validate_objects.sql script file to validate the structure of possibly corrupt objects
if the undo required is not available.
Undo Segment Usage Summary
**************************
*** Undo segments identified in use by active transaction datablocks AFTER 08/08/2012 03:30:32 (SCN: 0x0.0x79607):
USN: 1 Name: _SYSSMU1$
USN: 2 Name: _SYSSMU2$
USN: 3 Name: _SYSSMU3$
USN: 4 Name: _SYSSMU4$
USN: 5 Name: _SYSSMU5$
USN: 6 Name: _SYSSMU6$
USN: 9 Name: _SYSSMU9$
*** Undo segments identified in use by active transacation datablocks BEFORE 08/08/2012 03:30:32 (SCN: 0x0.0x79607):
USN: 1 Name: _SYSSMU1$
USN: 2 Name: _SYSSMU2$
USN: 3 Name: _SYSSMU3$
USN: 4 Name: _SYSSMU4$
USN: 5 Name: _SYSSMU5$
USN: 7 Name: _SYSSMU7$
USN: 8 Name: _SYSSMU8$
USN: 9 Name: _SYSSMU9$
USN: 10 Name: _SYSSMU10$
NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!NOTE!
*************************************************************************************
Upload the logfile (TXChecker_083012_2042_XFF.log) to Oracle Support Services for analysis.
Do NOT attempt to force the database open until the logfile has been analyzed.
验证对象脚本
[oracle@xifenfei txchecker]$ more validate_objects.sql rem validate_objects.sql - checks strcuture of objects needing unavailable undo data rem Created by findtxns program, Oracle Corporation set echo on ANALYZE TABLE CHF.T_XIFENFEI VALIDATE STRUCTURE CASCADE; ANALYZE INDEX MDSYS.SYS_IL0000046432C00006$$ VALIDATE STRUCTURE; ANALYZE INDEX SYS.I_ACCESS1 VALIDATE STRUCTURE; …………省略 ANALYZE INDEX XDB.SYS_C003167 VALIDATE STRUCTURE; ANALYZE INDEX XDB.XDB$ELEMENT_PROPNAME VALIDATE STRUCTURE; ANALYZE INDEX XDB.XDB$ELEMENT_PROPNUMBER VALIDATE STRUCTURE;
发表在 Oracle备份恢复
2 条评论
dbca创建数据库报ORA-00443
今天早上一个朋友和我说他们RAC dbca创建库不成功提示ORA-00443错误,让我帮他们分析下是什么原因导致
提示错误如图

环境状况
OS:LINUX REDHAT x86_64 5.7 kernel:2.6.18-194.el5 memory:100G CPU:ntel(R) Xeon(R) CPU E7- 8837 @ 2.67GHz * 64 ORACLE:10.2.0.4
查看alert日志错误
Wed Sep 5 01:32:33 2012 cluster interconnect IPC version:Oracle UDP/IP (generic) IPC Vendor 1 proto 2 PMON started with pid=2, OS id=17859 DIAG started with pid=7, OS id=17861 PSP0 started with pid=12, OS id=17863 LMON started with pid=17, OS id=17865 LMD0 started with pid=22, OS id=17867 MMAN started with pid=27, OS id=17869 DBW0 started with pid=32, OS id=17871 Wed Sep 5 01:32:33 2012 Errors in file /u01/app/oracle/admin/dtjcdb/bdump/dtjcdb1_ora_17873.trc: ORA-00600: internal error code, arguments: [ksbmoveme4], [], [], [], [], [], [], [] ORA-27300: OS system dependent operation:run on node failed with status: 2 ORA-27301: OS failure message: No such file or directory ORA-27302: failure occurred at: skgpmoveme:1 Wed Sep 5 01:32:34 2012 Trace dumping is performing id=[cdmp_20120905013234] Wed Sep 5 01:32:34 2012 Process DBW1 died, see its trace file USER: terminating instance due to error 443 Instance terminated by USER, pid = 17857
trace文件中内容
*** 2012-09-05 01:32:33.996
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [ksbmoveme4], [], [], [], [], [], [], []
ORA-27300: OS system dependent operation:run on node failed with status: 2
ORA-27301: OS failure message: No such file or directory
ORA-27302: failure occurred at: skgpmoveme:1
Current SQL information unavailable - no session.
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+31 call ksedst1() 000000000 ? 000000001 ?
7FFFC4ABA4C0 ? 7FFFC4ABA520 ?
7FFFC4ABA460 ? 000000000 ?
ksedmp()+610 call ksedst() 000000000 ? 000000001 ?
7FFFC4ABA4C0 ? 7FFFC4ABA520 ?
7FFFC4ABA460 ? 000000000 ?
ksfdmp()+21 call ksedmp() 000000003 ? 000000001 ?
7FFFC4ABA4C0 ? 7FFFC4ABA520 ?
7FFFC4ABA460 ? 000000000 ?
kgerinv()+161 call ksfdmp() 000000003 ? 000000001 ?
7FFFC4ABA4C0 ? 7FFFC4ABA520 ?
7FFFC4ABA460 ? 000000000 ?
kgesinv()+33 call kgerinv() 0068966E0 ? 000000000 ?
7FFFC4ABA520 ? 7FFFC4ABA460 ?
000000000 ? 000000000 ?
ksesin()+211 call kgesinv() 0068966E0 ? 000000000 ?
7FFFC4ABA520 ? 7FFFC4ABA460 ?
000000000 ? 000000000 ?
ksbmoveme()+350 call ksesin() 00533D5C8 ? 000000000 ?
006896FA3 ? 000000001 ?
000000001 ? 000000000 ?
ksosp_set_current() call ksbmoveme() 000000001 ? 000000000 ?
+117 006896FA3 ? 000000001 ?
000000001 ? 000000000 ?
kso_init()+161 call ksosp_set_current() 151056D10 ? 000000000 ?
006896FA3 ? 000000001 ?
000000001 ? 000000000 ?
opirip()+523 call kso_init() 151056D10 ? 000000000 ?
006896FA3 ? 000000001 ?
000000001 ? 000000000 ?
opidrv()+582 call opirip() 000000032 ? 000000004 ?
7FFFC4ABC128 ? 000000001 ?
000000001 ? 000000000 ?
sou2o()+114 call opidrv() 000000032 ? 000000004 ?
7FFFC4ABC128 ? 000000001 ?
000000001 ? 000000000 ?
opimai_real()+317 call sou2o() 7FFFC4ABC100 ? 000000032 ?
000000004 ? 7FFFC4ABC128 ?
000000001 ? 000000000 ?
main()+116 call opimai_real() 000000003 ? 7FFFC4ABC190 ?
000000004 ? 7FFFC4ABC128 ?
000000001 ? 000000000 ?
__libc_start_main() call main() 000000003 ? 7FFFC4ABC190 ?
+244 000000004 ? 7FFFC4ABC128 ?
000000001 ? 000000000 ?
_start()+41 call __libc_start_main() 000723088 ? 000000001 ?
7FFFC4ABC2E8 ? 000000000 ?
000000001 ? 000000003 ?
--------------------- Binary Stack Dump ---------------------
通过查询MOS发现[ID 422908.1]有类此的错误提示,但是该提示说是因为系统重新增加了过多CPU导致数据库crashed掉并且出现 ORA-27300 ORA-27301 ORA-27302 错误.在该案例中,起始就是64c,根据经验在win的10.2.0.4中如果cpu超过32c也是在dbcd创建数据库2%的地方hang住,所以怀疑该错误也是由于cpu太多导致.
处理方法
To solve the problem: 1) apply patch:6471079 - or - 2) apply the 10.2.0.5 (when available) - or - 3) upgrade to 11g
朋友打上patch:6471079,dbca正常建库

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

