Database SOS – 第28页 – Professional Database Recovery Support@+8617813235971

ORA-12518 ORA-27302: 错误发生在: ssthrddcr

标题：ORA-12518 ORA-27302: 错误发生在: ssthrddcr

11.2.0.1数据库运行在win 2008机器上,进程数配置为1000,但是数据库连接数到了170多之后,就开始报ORA-12518 TNS:监听程序无法分发客户机连接

检查alert日志发现后台日志报ORA-27300 ORA-27301 ORA-27302错误

Fri May 06 11:57:14 2022
Process startup failed, error stack:
Errors in file c:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_psp0_3052.trc:
ORA-27300: 操作系统系统相关操作: CreateThread 失败, 状态为: 8
ORA-27301: 操作系统故障消息: 存储空间不足，无法处理此命令。
ORA-27302: 错误发生在: ssthrddcr
Process J002 died, see its trace file
kkjcre1p: unable to spawn jobq slave process 
Errors in file c:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_cjq0_3808.trc:

通过mos分析确认问题为IRPStackSize参数值问题

参考:Ora-27300: OS System Dependent Operation:Createthread Failed With Status: 8 (Doc ID1310453.1)

plsql 插入blob

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：plsql 插入blob

plsql 插入blob

SQL> create bigfile tablespace t_xifenfei datafile 'e:/oradata/orcl/t_blob.dbf' size 128M autoextend on;

表空间已创建。


SQL> create table u0425.t_blob(a int, b varchar(10), c blob) tablespace t_xifenfei ;

表已创建。


SQL> create or replace directory expdp_dir as 'e:/';

目录已创建。


SQL> declare
  2  b_file bfile;
  3  b_lob blob;
  4  begin
  5  insert into u0425.t_blob(a,b,c) values(1,'xifenfei', empty_blob()) return c into b_lob;
  6  b_file:=bfilename('EXPDP_DIR','0430.DMP');
  7  dbms_lob.open(b_file,dbms_lob.file_readonly);
  8  dbms_lob.loadfromfile(b_lob,b_file,dbms_lob.getlength(b_file));
  9  dbms_lob.close(b_file);
 10  commit;
 11  end;
 12  /

PL/SQL 过程已成功完成。

SQL> select * from u0425.t_blob where rownum<2;

         A B
---------- ----------
C
--------------------------------------------------------------------------------
         1 xifenfei
0301914E3B98006780BC00019FC70146A1A3633DBC4B089DCF3DFCD951D559000000010000100003
6907E6041E0D3037000000020200000077D10000000000FA1A880022535953222E225359535F4558


SQL> select a,b,dbms_lob.getlength(c) from u0425.t_blob where rownum<2;

         A B          DBMS_LOB.GETLENGTH(C)
---------- ---------- ---------------------
         1 xifenfei               142024704

插入的blob字段和实际文件大小，内容一致,插入是成功的

分享运气超级好的一次drop tablespace 数据恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：分享运气超级好的一次drop tablespace 数据恢复

分享一次运气超级好的恢复,本身是一个测试库,应用厂商今天准备把应用正式上线,操作流程是:先删除用户,然后删除表空间,在创建表空间导入数据正式上线,不知何种原因最终客户在测试业务中做了一些正式数据,结果是无情的被删除了,通过alert日志找到应用厂商的一些操作记录
2021年8月份创建了业务表空间

Wed Aug 18 09:49:03 2021
create tablespace xifenfei datafile 'D:\app\Administrator\oradata\xifenfei\xifenfei.dbf' size 10g
Wed Aug 18 09:52:28 2021
Completed: create tablespace xifenfei datafile 'D:\app\Administrator\oradata\xifenfei\xifenfei.dbf' size 10g

今天删除表空间

Tue Apr 12 11:15:02 2022
drop tablespace xifenfei including contents and datafiles
WARNING: Cannot delete file D:\APP\ADMINISTRATOR\ORADATA\xifenfei\xifenfei.DBF
Errors in file d:\app\administrator\diag\rdbms\xifenfei\xifenfei\trace\xifenfei_ora_4296.trc:
ORA-01265: 鏃犳硶鍒犻櫎 DATA D:\APP\ADMINISTRATOR\ORADATA\xifenfei\xifenfei.DBF
ORA-27056: 鏃犳硶鍒犻櫎鏂囦欢
OSD-04024: 无法删除文件。
O/S-Error: (OS 32) 另一个程序正在使用此文件，进程无法访问。
Completed: drop tablespace xifenfei including contents and datafiles

然后客户创建新表空间提示ORA-01119,然后人工删除掉该数据文件

Tue Apr 12 11:49:02 2022
create tablespace xifenfei datafile'D:\oracle\oradata\xifenfei\xifenfei.dbf'size 20480m
ORA-1119 signalled during: create tablespace xifenfei datafile'D:\oracle\oradata\xifenfei\xifenfei.dbf'size 20480m...
Tue Apr 12 11:49:16 2022
create tablespace xifenfei datafile'D:\oracle\oradata\xifenfei\xifenfei.dbf'size 20480m
ORA-1119 signalled during: create tablespace xifenfei datafile'D:\oracle\oradata\xifenfei\xifenfei.dbf'size 20480m...

创建新表空间成功，并增加数据文件

Tue Apr 12 12:08:43 2022
create tablespace xifenfei datafile'D:\app\Administrator\oradata\xifenfei\xifenfei.dbf'size 5120m
Tue Apr 12 12:10:25 2022
Completed: create tablespace xifenfei datafile'D:\app\Administrator\oradata\xifenfei\xifenfei.dbf'size 5120m
Tue Apr 12 12:11:19 2022
alter tablespace xifenfei add datafile'D:\app\Administrator\oradata\xifenfei\xifenfei1.dbf'size 5120m
Tue Apr 12 12:13:02 2022
Completed: alter tablespace xifenfei add datafile'D:\app\Administrator\oradata\xifenfei\xifenfei1.dbf'size 5120m
alter tablespace xifenfei add datafile'D:\app\Administrator\oradata\xifenfei\xifenfei2.dbf'size 5120m
Tue Apr 12 12:14:52 2022
Completed: alter tablespace xifenfei add datafile'D:\app\Administrator\oradata\xifenfei\xifenfei2.dbf'size 5120m

基本情况就是客户删除了一个10G的业务数据文件，然后创建了3个5G的业务数据文件,现在要恢复被以前的两个表的核心数据，需要做的就是把以前的10G的数据文件找出来,但是由于删除10G文件之后又写入了15G的数据文件(而且这里面有文件的file#和删除的文件一致),理论上无法直接做block层面扫描恢复,对于此类情况,尝试文件系统层面直接反删除恢复,不过没有任何记录,文件目录被覆盖,这条路走不通.通过block扫描,发现2个file# 5文件的起始位置（分别是block 2和block 0）,而且结束位置文件大小分别是10G和5G,根据经验这两个连续的磁盘分配空间很可能就是这两个file# 5的文件

通过winhex把数据拷贝出来,使用工具检测

除损坏的block 1之外（block 0 不统计在内）,其他block都正常,也就是说这个10G的被删除的数据文件,只是丢失一个文件头,业务数据全部再,后续通过dul恢复客户需要数据,完成这次数据恢复,类似这种文件丢失,文件系统损坏,文件大小为0kb等类似恢复,参见以前类似blog:
win文件系统损坏oracle恢复
dbca删除库和rm删库恢复
文件系统重新分区oracle恢复
restore database误操作恢复
文件系统损坏导致数据文件异常恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
rm -rf 删除数据文件恢复方法—文件系统反删除+oracle碎片重组

segment header异常对象删除处理

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：segment header异常对象删除处理

对于某些极端情况下，segment header出现损坏的对象该如何处理,这里通过一个实验来说明这类情况该如何处理,创建表并查询相关segment信息

SQL> create tablespace t_xff datafile '/u01/app/oracle/oradata/orcl/t_xifenfei01.dbf' size 128M autoextend on;

Tablespace created.

SQL> create table t_xifenfei tablespace t_xff as select * from dba_objects;

Table created.

SQL> select header_file,header_block from dba_SEGMENTS where segment_name='T_XIFENFEI'  and owner='SYS';

HEADER_FILE HEADER_BLOCK
----------- ------------
          5          130
----segment header 为 file 5，block 130

SQL> select   EXTENT_ID , FILE_ID ,BLOCK_ID  from dba_extents where segment_name='T_XIFENFEI'  and owner='SYS';

 EXTENT_ID    FILE_ID   BLOCK_ID
---------- ---------- ----------
         0          5        128
         1          5        136
         2          5        144
         3          5        152
         4          5        160
         5          5        168
         6          5        176
         7          5        184
         8          5        192
         9          5        200
        10          5        208
        11          5        216
        12          5        224
        13          5        232
        14          5        240
        15          5        248
        16          5        256
        17          5        384
        18          5        512
        19          5        640
        20          5        768
        21          5        896
        22          5       1024
        23          5       1152
        24          5       1280

25 rows selected.

---有25个extent信息

SQL> select * from dba_free_space where file_id=5;

TABLESPACE_NAME                   FILE_ID   BLOCK_ID      BYTES     BLOCKS
------------------------------ ---------- ---------- ---------- ----------
RELATIVE_FNO
------------
T_XFF                                   5       1408  122683392      14976
           5
--空闲block是从1408开始

模拟segment header损坏(通过dd破坏block)

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> 
SQL> 
SQL> 
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@xifenfei ~]$ 
[oracle@xifenfei ~]$ 
[oracle@xifenfei ~]$echo xifenfei.com|dd of=/u01/app/oracle/oradata/orcl/t_xifenfei01.dbf bs=8192 conv=notrunc seek=130
0+1 records in
0+1 records out
17 bytes (17 B) copied, 5.4389e-05 s, 313 kB/s
[oracle@xifenfei ~]$ dbv file=/u01/app/oracle/oradata/orcl/t_xifenfei01.dbf

DBVERIFY: Release 11.2.0.4.0 - Production on Wed Apr 13 20:29:41 2022

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - Verification starting : FILE = /u01/app/oracle/oradata/orcl/t_xifenfei01.dbf
Page 130 is marked corrupt
Corrupt block relative dba: 0x01400082 (file 5, block 130)
Bad header found during dbv: 
Data in bad block:
 type: 119 format: 7 rdba: 0x65666978
 last change scn: 0x632e.6965666e seq: 0x6f flg: 0x6d
 spare1: 0x77 spare2: 0x2e spare3: 0x0
 consistency value in tail: 0xada72301
 check value in block header: 0xf30a
 computed block checksum: 0x5eb9



DBVERIFY - Verification complete

Total Pages Examined         : 16384
Total Pages Processed (Data) : 1234
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 154
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 14995
Total Pages Marked Corrupt   : 1
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 6466979 (0.6466979)

查询表数据报错

[oracle@xifenfei ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Wed Apr 13 20:29:48 2022

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area  734892032 bytes
Fixed Size                  2256872 bytes
Variable Size             452984856 bytes
Database Buffers          276824064 bytes
Redo Buffers                2826240 bytes
Database mounted.
Database opened.
SQL> select count(1) from t_xifenfei;
select count(1) from t_xifenfei
                     *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 5, block # 130)
ORA-01110: data file 5: '/u01/app/oracle/oradata/orcl/t_xifenfei01.dbf'

查询extent信息为空

SQL> select   EXTENT_ID   , FILE_ID   ,BLOCK_ID  from dba_extents where segment_name='T_XIFENFEI'  and owner='SYS';

no rows selected

SQL> select header_file,header_block from dba_SEGMENTS where segment_name='T_XIFENFEI'  and owner='SYS';

HEADER_FILE HEADER_BLOCK
----------- ------------
          5          130

SQL> select * from dba_free_space where file_id=5;

TABLESPACE_NAME                   FILE_ID   BLOCK_ID      BYTES     BLOCKS
------------------------------ ---------- ---------- ---------- ----------
RELATIVE_FNO
------------
T_XFF                                   5       1408  122683392      14976
           5

尝试删除表报错

SQL> drop table t_xifenfei;
drop table t_xifenfei
           *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 5, block # 130)
ORA-01110: data file 5: '/u01/app/oracle/oradata/orcl/t_xifenfei01.dbf'

通过加purge删除成功

SQL> drop table t_xifenfei purge;

Table dropped.

删除表成功，但是磁盘空间未释放，通过查询确认变为一个临时段

SQL> select * from dba_free_space where file_id=5;

TABLESPACE_NAME                   FILE_ID   BLOCK_ID      BYTES     BLOCKS
------------------------------ ---------- ---------- ---------- ----------
RELATIVE_FNO
------------
T_XFF                                   5       1408  122683392      14976
           5


SQL> select segment_name,segment_type,owner from dba_segments where header_file=5;

SEGMENT_NAME
--------------------------------------------------------------------------------
SEGMENT_TYPE       OWNER
------------------ ------------------------------
5.130
TEMPORARY          SYS

清理临时段,彻底删除segment header异常对象删除后遗症

SQL> exec dbms_space_admin.segment_corrupt('T_XFF',5,130); 

PL/SQL procedure successfully completed.

SQL> exec dbms_space_admin.segment_drop_corrupt('T_XFF',5,130);

PL/SQL procedure successfully completed.

SQL> exec DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_BITMAPS ('T_XFF');

PL/SQL procedure successfully completed.

SQL> select segment_name,segment_type,owner from dba_segments where header_file=5;

no rows selected

SQL> select * from dba_free_space where file_id=5;

TABLESPACE_NAME                   FILE_ID   BLOCK_ID      BYTES     BLOCKS
------------------------------ ---------- ---------- ---------- ----------
RELATIVE_FNO
------------
T_XFF                                   5        128  133169152      16256
           5

Oracle 数据库（RDBMS）的版本支持状态摘要 (Doc ID 1674382.1)

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：Oracle 数据库（RDBMS）的版本支持状态摘要 (Doc ID 1674382.1)

Oracle 数据库发布状态摘要

大版本 (点击查看详情)	当前补丁集或年度发布版 (点击查看可用性和已知问题)	当前支持类别	标准服务结束日期	扩展服务结束日期	注释
21c	21c (Innovation Release)	标准服务	2024 年 4 月 30 日	不符合扩展支持的条件。错误更正时间将于 2024 年 4 月 30 日结束。	关于未来版本的发布时间参见 Note 742060.1
19c	19c 参见 Note 2285040.1 19 Long Term Release- 可用性和已知问题 Note 2527930.1	标准服务	2024年4月	2027年4月 19c 的补丁结束时间是2027年4月(包括付费扩展服务或者具有扩展服务的 ULA)	关于未来版本的发布时间参见 Note 742060.1
18c	18c 参见 Note 2285040.1 18 Innovation Release – 可用性和已知问题 Note 2387295.1	延伸服务	2021年6月	不符合扩展支持的条件。错误更正时间将于 2021 年 6 月 30 日结束。 18c的补丁结束时间是2021年6月	19c是12.2集合中的长期版本(最终版本) 关于未来版本的发布时间参见 Note 742060.1
12.2	12.2.0.1 see NOTE 2285040.1 12.2.0.1 基本版 – 可用性和已知问题 Note 2239820.1	标准服务	2020年11月(有限错误更正支持到 2022 年 3 月)	Oracle 12.2.0.1¹ 标准服务错误更正支持结束日期是 2020 年 11 月 30 日。Oracle 12.2.0.1 没有扩展服务。但是，作为一次性的例外，Oracle 将在标准服务错误更正支持结束后的 16 个月内免费提供有限的错误更正支持。对于那些需要额外时间来完成 19c 升级的，从 2020 年 12 月 1 日到 2022 年 3 月 31 日将会有有限的错误更正支持。在有限的错误更正支持期间，Oracle 将采取商业上合理的措施²来提供：一级严重程度代码修复，包括对生产环境一级严重程度问题提供补丁和/或变通方案安全修复只包含一级严重程度问题修复和安全修复的季度发布更新 (RU) 限制和例外：不会提供 P2 或 P3 问题的修补补丁所有当前支持的平台都包括在内。包括的平台有：Fujitsu BS2000, Linux x86-64, Solaris x86-64, Solaris SPARC, IBM AIX on Power Systems, IBM Linux on System Z (ZLinux), HP-UX Itanium 和 Microsoft Windows x64。不会提供任何功能升级，不会提供第三方软件相关问题以及新版本操作系统的认证。 Oracle 数据库中依赖 de-supported Java 产品版本的嵌入式组件，对任何加密相关功能的更新（包括但不限于传输层安全性 (TLS)，网络加密和其他形式的安全通信）都不包括在内。不包括具有自己的生存期支持策略的集成 Oracle 产品。 ¹ Oracle 数据库 12.2.0.1 包括 on-premises, Database/Exadata Cloud Services, 和 Exadata Cloud at Customer (包括 Gen1 和 Gen2) ² 商业上合理的措施意味着 Oracle 将提供可以完成的修复，并提供合理数量的资源和时间。	基本版为 12.2.0.1 19c是12.2集合中的长期版本(最终版本) 关于未来版本的发布时间参见 Note 742060.1 更多信息参见 Note 2665835.1
12.1.0.X	12.1.0.2	扩展服务	2018年7月	2022年7月扩展服务时间延长了 1 年，从2021年7月31日到2022年7月31日。例外：Microsoft Windows 和 Apple Macintosh 平台不包含在这延长的 1 年范围之中，对于这两个平台扩展服务的结束时间仍然是2021年7月31日。 2018年8月 – 2019年7月期间扩展服务费用免除. E-Business 客户扩展服务费用免除. 参见 Oracle Software Technical Support Policies - Section 3 – Lifetime Support Policy 中的 “Exceptions”. 12.1.0.1的补丁结束时间是2016年8月31日	基本版是 12.1.0.1 . 12.1.0.2 是 12.1 的最终补丁集并且只有 Enterprise Edition 和 Standard Edition 2 – 参见 Note 2027072.1
11.2.0.X	11.2.0.4	扩展服务	2015年1月(Market Driven Support 到 2022 年 12 月)	2020年12月付费的 Market Driven Support (1 级问题修复) 到 2022 年 12 月. 2015年1月 – 2018年12月31日期间扩展服务费用免除. 参见 Oracle Software Technical Support Policies - Section 3 – Lifetime Support Policy 中的 “Exceptions”. 11.2.0.1的补丁结束时间是2011年9月13日 11.2.0.2的补丁结束时间是2013年10月31日 11.2.0.3的补丁结束时间是2015年8月27日 – 参见 Note 742060.1	基本版是 11.2.0.1. 11.2.0.4 是 11.2 的最终补丁集 11.2 补丁集是完整的发布版 – 参见 Note 1189783.1

无错误更正支持的其他历史版本

大版本 (Click to see Details)	最终补丁集	错误更正支持结束日期 (点击日期查看停止提供支持的信息)	扩展维护支持停止日期 (点击日期查看停止提供支持的信息)	注释
11.1.0.X	11.1.0.7	2015年8月	2015年8月对于大多数平台来说 11.1.0.7 的补丁结束时间是2015年8月31日. 对 HPUX-Itanium 平台提供有限扩展服务 – 参见 Note 1307745.1	基本版是 11.1.0.6 . 11.1.0.7 是 11.1 的最终补丁集
10.2.0.X	10.2.0.5	MDS 结束于2019年7月	2013年7月大多数平台的有限扩展服务在2015年7月31日结束.(平台特例参见 “Oracle Software Technical Support Policies” 的 Extended Support 章节. 例如, z/OS 上的 10.2 有很多特例, 参阅 NOTE 461234.1.) Oracle Database (10gR2) 的 Market Driven Support (MDS) 延长至2019年7月. 10.2.0.5 现处于延伸服务阶段。	10.2.0.5 是 10.2 的最终补丁集. 免费扩展服务在2011年7月31日结束. 有限扩展服务在2015年7月31日结束.
10.1.0.X	10.1.0.5	2012年1月	2012年1月	10.1.0.5 是 10.1 的最终补丁集. 10.1 的扩展服务已经结束 – 参见 Note 761713.1
9.2.0.X	9.2.0.8	2012年7月	2010年7月某些平台从2010年7月到2012年7月具有有限扩展服务. 参见 9.2 Extended Support details here	9.2.0.8 是 9.2的最终补丁集. 免费扩展服务在2008年7月31日结束. 参见 Note 392222.1
9.0.1.X	9.0.1.4 (对 *iAS来说是9.0.1.5* )	2003年12月31日	无扩展维护支持.	9.0.1.4 是 “通用版” 9.0 的最终补丁集. 9.0.1.5 是针对 iAS 的特定版.
8.1.7.X	8.1.7.4	战略平台2004年12月31日其它平台2003年12月31日 (Novell NetWare 截止到2003年1月31日)	战略平台2006年12月31日其它平台2005年12月31日 (或更早) (Novell NetWare无扩展维护支持)	8.1.7.4 是 8.1.7 的最终补丁集. 扩展维护支持已结束. 以下例外可继续提供修复.
8.1.6.X	8.1.6.3	对于 E-Business Suite 用户从2001年10月31日延伸至2002年6月1日.	无扩展维护支持	无扩展维护支持.
8.1.5.X	8.1.5.1	2001年1月1日	无扩展维护支持	8.1.5.1 只存在于 Solaris / NT / SNI / SGI 平台
8.0.6.X	8.0.6.3	2001年9月30日	扩展维护支持结束于2003年9月30日	扩展维护支持结束后对于运行 E-Business Suite (服务器分区模式), 8.0.6.3 的用户可继续提供补丁修复.
8.0.5.X	8.0.5.2	OpenVMS 2001年3月31日 HPUX 64 bit 2001年1月1日 AIX 64 bit 2001年1月1日 Other platforms 2000年6月30日	无扩展维护支持
8.0.4.X	8.0.4.4	2000年3月31日	无扩展维护支持	OS/390 自2000年11月1日停止支持
8.0.3.X	8.0.3.2	1999年3月31日	无扩展维护支持
7.3.4.X	7.3.4.5	2000年12月31日	扩展维护支持结束于2002年12月31日	扩展服务支持已结束
7.3.3.X	7.3.3.6	1998年12月31日	扩展维护支持结束于2000年12月31日	扩展服务支持已结束
7.3.2.X	7.3.2.3	1998年1月31日	无扩展维护支持	7.3.2版本无扩展服务支持

互操作性支持

对于不同的 Oracle 版本之间的互操作性支持, 参见Note 207303.1

本文档使用的术语

大版本

这是 Oracle 数据库（ RDBMS ）的前 3 位。单击此列中的链接，请参见大版本的支持状态，最近的服务器警报和最新补丁集信息。对于 8.1.7 及以后的版本，这些链接还包括可用补丁集的信息。

补丁集

补丁集是 Oracle 公司定期提供的经全面测试和集成的产品修复机制。补丁集只提供错误修正;它们可能包括有限的新功能，但不改变现有的正确的功能，并且不需要在目标系统上重新认证。一个补丁集的应用会改变 Oracle 数据库版本号的第 4 位。
补丁集分别针对各个平台发布，除了包含各平台无关的通用缺陷修复以外，它还包含平台特定的缺陷修复。例如：AIX上的 11.2.0.4 和 Solaris 上的 11.2.0.4 包含相同的平台无关的通用缺陷修复.
补丁集是累积的。例如，11.2.0.4 除了包含了 11.2.0.3 中所有缺陷修复以外，还包含 11.2.0.4 的新缺陷的修复.
每个平台上目前的补丁集的发行日期详见 Note 742060.1

下一补丁集

此列显示下一个预计的补丁集的版本。请注意，这不保证列出的补丁集将被发布，如果发布也可能不会适用于所有平台。
“无”表示没有更多的补丁集计划。

最终补丁集

这是这个版本的最后的补丁集。（一些平台可能有一个较低的补丁集）

Patch Set Exception (PSE) / Interim Patch

术语 “Interim Patch” 和 “Patch Set Exception” 是同义的。如果客户遇到需要在下一个补丁集发布之前修复一个关键的问题，那么他们可以要求最新补丁集上的的一次性的修补程序。这样的要求在被处理前需提供适当的技术和商业理由，而且由此产生的修补程序不经过回归测试。Patch Set Exception 只可能在以下情况提供：

版本处于标准服务周期内或客户购买了扩展服务
版本是给定大版本/平台的最终补丁集
有合适的技术和业务的理由
技术可行性允许

有限扩展服务

购买了扩展服务但仅限于一级问题修复的扩展服务；不包括 critical path update。

错误更正支持 (ECS)

本术语只适用于服务器 9.0 以前的版本。
可以提供新的漏洞和问题的修复。客户需运行在最新的补丁集以得到Patch Set Exception (单个bug的修复).过期后进入扩展维护支持.

扩展维护支持 (EMS)

本术语只适用于服务器 9.0 以前的版本
这是一个可以购买的支持选项，该支持允许对关键问题提供单个的补丁修复(Patch Set Exceptions). 客户如果没有购买扩展维护支持不能获得新问题的修复。客户必须在给定版本的最终补丁集上获取扩展维护支持.

扩展协助支持 (EAS)

本术语只适用于服务器 9.0 以前的版本。
更多的关于扩展协助支持的细节可在 desupport 文档里查看。最重要的是扩展协助支持不包括:

新缺陷的修复和已知缺陷的补丁开发
升级支持或响应时间保证

Change history

2021-06-29 把一些旧的版本移动到底部的表格，去掉了 12.2 系列来避免和 18c 混淆(之前把它归类于 12.2 系列，但现在把它移除是因为 18c 没有扩展服务)
2019-12-13 12.1.0.2 扩展服务时间延长了 1 年
2019-02-28 添加了 19c 条目
2018-06-13 根据Oracle 管理部门要求恢复了颜色标注. 10.2的 MDS 延长至2019
2018-05-25 新owner. 实现了很多未确定的项目, 包括移除了 non-508 compliant shading 并且添加了18c. 移除了失效的链接, 添加了原始材料的直接链接.
2017-03-03 添加了12.2 支持状态的文档和警报文档，以及12.2.0.1已知问题的文档
2017-01-26 添加了12.2, 添加了 12.1 扩展服务费用免除, 跟新了 11.2 扩展服务费用免除结束日期.
2016-09-13 12.1.0.1 补丁结束日期是2016年8月31日. 添加了 12.1.0.2 的补丁结束日期.
2016-06-10 MDS 结束日期已经从2016年7月延长到2017年7月
2016-02-10 更正了修改历史的日期. 无其他改变
2015-10-20 11.2.0.4 扩展支持将从现在开始到2020年12月
2015-09-02 12.1.0.2 SE2 发布了.
2015-09-01 11.1 进入延伸服务(无新bug修复) 除了 HPUX Itanium (有限扩展服务), 11.2.0.3 过了补丁结束日期.
2015-08-01 10.2 在大部分平台的有限扩展服务结束. MDS 可用
2015-04-08 11.2 进入免费扩展服务
2014-11-14 12.1.0.2 是 12.1 的最终补丁集
2014-07-22 添加了 12.1.0.2 补丁集
2014-04-30 添加了 11.2.0.3 补丁结束日期让其更清楚
2013-09-12 补丁集可能包含有限的新功能不同于”有限”扩展服务.
2013-09-02 由于 11.2.0.4 已经发布，更新了 11.2 的信息
2013-06-28 添加了 12.1
2013-03-13 更新了扩展服务的信息
2012-09-01 11.1.0.7 标准服务结束, 扩展服务开始
2012-08-01 9.2.0.8 有限扩展服务已经结束.
2012-02-01 10.1.0.5 扩展服务已经结束.
2011-12-20 修正了 9.2 的有限扩展服务信息
2011-10-13 11.2 扩展服务第一年费用免除，10.2 扩展服务 – 添加了大多数平台只允许 10.2.0.5 上的补丁
2011-09-26 11.2.0.3 在2011年9月23日发布
2011-08-05 10.2 免费扩展服务已经在2011年7月结束.
2011-06-14 将剩下的 “Lifetime Support Policy” 链接到 note 971415.1
2011-03-17 “Lifetime Support Policy” 被移到 note 971415.1
2010-09-14 第一个补丁集 11.2.0.2 发布了
2010-08-19 10.2 现在处于扩展服务 (第一年免费)
2010-05-21 9.2有限扩展服务可用
2010-05-02 10.2.0.5 发布了
2010-03-31 为 11.2 添加了支持的日期，并且调整了 10.2.0.4 在 patching 中的位置
2010-02-08 将标题 “Server” 修改成 “Database”
2009-11-26 作为最可能的下一个补丁集，添加了 10.2.0.5 和 11.2.0.2
2009-09-23 添加了 11.2
2009-05-11 10.1 处于扩展服务, 10.2 第一年的扩展服务免费
2008-11-10 为 9.2 添加了 note 39222.1
2008-10-20 添加了新 note 742060.1 的链接
2008-09-24 一些 Lifetime Support Policy 的链接是旧的URL
2008-09-19 添加了 11.1.0.7
2008-08-01 9.2 免费扩展服务现在结束了
2008-07-08 将”TBD” 修改成 “To Be Decided”
2008-04-23 修改了 Lifetime Support Policy 的链接, 添加了 11g 的日期
2007-08-17 添加了 11g
2007-08-10 9.2 现在进入扩展服务
2007-05-10 10.1.0.5 是最终补丁集。

参考：Oracle 数据库（RDBMS）的版本支持状态摘要 (Doc ID 1674382.1)

[back2023@proxy.tg].eking勒索数据库恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：[back2023@proxy.tg].eking勒索数据库恢复

有客户文件系统被勒索加密,被加密扩展名为.id[F494A52E-3009].[back2023@proxy.tg].eking

通过分析损坏情况,确认每个文件被加密破坏192个block

通过自研的数据库恢复工具对于损坏的数据进行修复

实现数据库直接open,并顺利导出数据,实现业务完美恢复

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

ORA-600 ktbsdp2 处理

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ORA-600 ktbsdp2 处理

客户反馈数据库异常:两个节点rac,两个节点都启动,其中一个节点无法正常open,另外一个节点一段时间后也会挂。以下是无法正常open节点报错信息(正常open节点最终挂掉报错信息也是类似)

2022-03-30T19:19:12.870813+08:00
[84321] Successfully onlined Undo Tablespace 4.
Undo initialization finished serial:0 start:1728252021 end:1728256302 diff:4281 ms (4.3 seconds)
Verifying minimum file header compatibility for tablespace encryption..
Verifying file header compatibility for tablespace encryption completed for pdb 0
2022-03-30T19:19:13.953252+08:00
Database Characterset is ZHS16GBK
2022-03-30T19:19:14.538155+08:00
Errors in file /oracle/app/oracle/diag/rdbms/xff/xff2/trace/xff2_p02o_85718.trc  (incident=1093927):
ORA-00600: internal error code, arguments: [ktbsdp2], [18446744073709551615], [], [], [], [], [], [], [], [], [], []
Incident details in: /oracle/app/oracle/diag/rdbms/xff/xff2/incident/incdir_1093927/xff2_p02o_85718_i1093927.trc
2022-03-30T19:19:15.536582+08:00
ORACLE Instance xff2 (pid = 57) - Error 607 encountered while recovering transaction (73, 12) on object 112841.
2022-03-30T19:19:33.699944+08:00
Errors in file /oracle/app/oracle/diag/rdbms/xff/xff2/trace/xff2_smon_84007.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [ktbsdp2], [18446744073709551615], [], [], [], [], [], [], [], [], [], []
2022-03-30T19:19:34.673840+08:00
Errors in file /oracle/app/oracle/diag/rdbms/xff/xff2/trace/xff2_smon_84007.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [ktbsdp2], [18446744073709551615], [], [], [], [], [], [], [], [], [], []
2022-03-30T19:19:34.673954+08:00
Errors in file /oracle/app/oracle/diag/rdbms/xff/xff2/trace/xff2_smon_84007.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [ktbsdp2], [18446744073709551615], [], [], [], [], [], [], [], [], [], []
Errors in file /oracle/app/oracle/diag/rdbms/xff/xff2/trace/xff2_smon_84007.trc  (incident=1092704):
ORA-607 [] [] [] [] [] [] [] [] [] [] [] []
Incident details in: /oracle/app/oracle/diag/rdbms/xff/xff2/incident/incdir_1092704/xff2_smon_84007_i1092704.trc
2022-03-30T19:19:35.422779+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.
*****************************************************************
2022-03-30T19:19:36.154689+08:00
Starting background process GTX0
2022-03-30T19:19:36.169007+08:00
GTX0 started with pid=370, OS id=87409 
2022-03-30T19:19:36.645876+08:00
USER (ospid: 84007): terminating the instance due to error 607
2022-03-30T19:19:36.680109+08:00
opiodr aborting process unknown ospid (87439) as a result of ORA-1092
2022-03-30T19:19:36.681091+08:00
ORA-1092 : opitsk aborting process
2022-03-30T19:19:36.740357+08:00
System state dump requested by (instance=2, osid=84007 (SMON)), summary=[abnormal instance termination].
System State dumped to trace file /oracle/app/oracle/diag/rdbms/xff/xff2/trace/xff2_diag_83895_20220330191936.trc
2022-03-30T19:19:40.135579+08:00
Instance terminated by USER, pid = 84007

对于上述报错信息分析,初步判断是由于事务异常导致,查询mos发现类似报错Bug 32208691 – After upgrade from 12.1 to 19.3 drop columns fails ORA-600[ktbsdp2] ORA-600[4512] (Doc ID 32208691.8),通过咨询客户,确认他们这边是通过plsql dev工具对id为112841表进行增加列的时候网络中断导致增加失败,后续我尝试对该表进行查询发现也报该错误,基本上可以确认由于该表事务异常导致,通过dul把该表数据恢复,然后drop 该表,数据库启动正常,未见其他报错,通过hcheck检查,数据库字典基本一致(除一些统计信息异常,原则上不影响数据库运行)

[oracle@xifenfei2 ~]$ sqlplus / as sysdba @hcheck.sql

SQL*Plus: Release 12.2.0.1.0 Production on Thu Mar 31 00:38:32 2022

Copyright (c) 1982, 2016, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

HCheck Version 07MAY18 on 31-MAR-2022 00:38:34
----------------------------------------------
Catalog Version 12.2.0.1.0 (1202000100)
db_name: xff
Is CDB?: NO

                                   Catalog       Fixed
Procedure Name                     Version    Vs Release    Timestamp
Result
------------------------------ ... ---------- -- ---------- --------------
------
.- LobNotInObj                 ... 1202000100 <=  *All Rel* 03/31 00:38:34 PASS
.- MissingOIDOnObjCol          ... 1202000100 <=  *All Rel* 03/31 00:38:34 PASS
.- SourceNotInObj              ... 1202000100 <=  *All Rel* 03/31 00:38:34 PASS
.- OversizedFiles              ... 1202000100 <=  *All Rel* 03/31 00:38:38 PASS
.- PoorDefaultStorage          ... 1202000100 <=  *All Rel* 03/31 00:38:38 PASS
.- PoorStorage                 ... 1202000100 <=  *All Rel* 03/31 00:38:38 PASS
.- TabPartCountMismatch        ... 1202000100 <=  *All Rel* 03/31 00:38:38 PASS
.- OrphanedTabComPart          ... 1202000100 <=  *All Rel* 03/31 00:38:38 PASS
.- MissingSum$                 ... 1202000100 <=  *All Rel* 03/31 00:38:38 PASS
.- MissingDir$                 ... 1202000100 <=  *All Rel* 03/31 00:38:38 PASS
.- DuplicateDataobj            ... 1202000100 <=  *All Rel* 03/31 00:38:40 PASS
.- ObjSynMissing               ... 1202000100 <=  *All Rel* 03/31 00:38:42 PASS
.- ObjSeqMissing               ... 1202000100 <=  *All Rel* 03/31 00:38:42 PASS
.- OrphanedUndo                ... 1202000100 <=  *All Rel* 03/31 00:38:44 PASS
.- OrphanedIndex               ... 1202000100 <=  *All Rel* 03/31 00:38:44 PASS
.- OrphanedIndexPartition      ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- OrphanedIndexSubPartition   ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- OrphanedTable               ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- OrphanedTablePartition      ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- OrphanedTableSubPartition   ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- MissingPartCol              ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- OrphanedSeg$                ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- OrphanedIndPartObj#         ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- DuplicateBlockUse           ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- FetUet                      ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- Uet0Check                   ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- SeglessUET                  ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- BadInd$                     ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- BadTab$                     ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- BadIcolDepCnt               ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- ObjIndDobj                  ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- TrgAfterUpgrade             ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- ObjType0                    ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- BadOwner                    ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- StmtAuditOnCommit           ... 1202000100 <=  *All Rel* 03/31 00:38:45 PASS
.- BadPublicObjects            ... 1202000100 <=  *All Rel* 03/31 00:38:46 PASS
.- BadSegFreelist              ... 1202000100 <=  *All Rel* 03/31 00:38:50 PASS
.- BadDepends                  ... 1202000100 <=  *All Rel* 03/31 00:38:50 PASS
.- CheckDual                   ... 1202000100 <=  *All Rel* 03/31 00:38:57 PASS
.- ObjectNames                 ... 1202000100 <=  *All Rel* 03/31 00:38:57 WARN

HCKW-0018: OBJECT name clashes with SCHEMA name (Doc ID 2363142.1)
Schema=MHWZ PACKAGE=MHWZ.MHWZ
Schema=MHWZ PACKAGE BODY=MHWZ.MHWZ

.- BadCboHiLo                  ... 1202000100 <=  *All Rel* 03/31 00:39:01 WARN

HCKW-0019: HIST_HEAD$.LOWVAL > HIVAL (Doc ID 1361047.1)
OBJ# 324163 INTCOL#=22
OBJ# 482668 INTCOL#=4
OBJ# 442865 INTCOL#=31
OBJ# 436924 INTCOL#=31
OBJ# 580529 INTCOL#=8
OBJ# 459432 INTCOL#=31
OBJ# 451260 INTCOL#=31
OBJ# 530980 INTCOL#=21
OBJ# 498442 INTCOL#=5
OBJ# 652114 INTCOL#=8
OBJ# 701695 INTCOL#=21
OBJ# 831961 INTCOL#=31
OBJ# 831962 INTCOL#=31
OBJ# 831963 INTCOL#=31

.- ChkIotTs                    ... 1202000100 <=  *All Rel* 03/31 00:39:09 PASS
.- NoSegmentIndex              ... 1202000100 <=  *All Rel* 03/31 00:39:09 PASS
.- BadNextObject               ... 1202000100 <=  *All Rel* 03/31 00:39:09 PASS
.- DroppedROTS                 ... 1202000100 <=  *All Rel* 03/31 00:39:09 PASS
.- FilBlkZero                  ... 1202000100 <=  *All Rel* 03/31 00:39:09 PASS
.- DbmsSchemaCopy              ... 1202000100 <=  *All Rel* 03/31 00:39:09 PASS
.- OrphanedIdnseqObj           ... 1202000100 >  1201000000 03/31 00:39:09 PASS
.- OrphanedIdnseqSeq           ... 1202000100 >  1201000000 03/31 00:39:09 PASS
.- OrphanedObjError            ... 1202000100 >  1102000000 03/31 00:39:09 PASS
.- ObjNotLob                   ... 1202000100 <=  *All Rel* 03/31 00:39:09 PASS
.- MaxControlfSeq              ... 1202000100 <=  *All Rel* 03/31 00:39:09 PASS
.- SegNotInDeferredStg         ... 1202000100 >  1102000000 03/31 00:39:13 PASS
.- SystemNotRfile1             ... 1202000100 >   902000000 03/31 00:39:13 PASS
.- DictOwnNonDefaultSYSTEM     ... 1202000100 <=  *All Rel* 03/31 00:39:13 PASS
.- OrphanTrigger               ... 1202000100 <=  *All Rel* 03/31 00:39:13 PASS
.- ObjNotTrigger               ... 1202000100 <=  *All Rel* 03/31 00:39:13 PASS
---------------------------------------
31-MAR-2022 00:39:13  Elapsed: 39 secs
---------------------------------------
Found 0 potential problem(s) and 16 warning(s)
Contact Oracle Support with the output and trace file
to check if the above needs attention or not

PL/SQL procedure successfully completed.

Statement processed.

Complete output is in trace file:
/oracle/app/oracle/diag/rdbms/xff/xff2/trace/xff2_ora_26887_HCHECK.trc

win文件系统损坏oracle恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：win文件系统损坏oracle恢复

有客户反馈数据文件无法拷贝也无法正常操作,通过查看系统日志发现ntfs文件系统异常

在文件系统中看数据文件状态正常,但是拷贝文件报错

通过恢复工具查看文件发现文件大小为0kb

通过文件系统层面扫描,然后进行相关数据恢复,依旧报错(恢复文件大小错误)

经过进一步人工修复文件系统目录,实现数据完整恢复,实现数据0丢失

基于这种情况如果通过文件系统层面无法恢复,对于此类oracle block级别进行处理,类似以前恢复case:
dbca删除库和rm删库恢复
文件系统损坏导致数据文件异常恢复
Oracle 数据文件大小为0kb或者文件丢失恢复

asm disk 磁盘部分被清空恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：asm disk 磁盘部分被清空恢复

由于未知原因导致磁盘组的一个磁盘前面1G被置空(data磁盘组一共5个1T磁盘,第一个盘未知原因置空了1G数据)

[root@oradb1 ~]#kfed read /dev/mapper/asm-disk1
kfbh.endian:                          0 ; 0x000: 0x00
kfbh.hard:                            0 ; 0x001: 0x00
kfbh.type:                            0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt:                          0 ; 0x003: 0x00
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:                       0 ; 0x008: file=0
kfbh.check:                           0 ; 0x00c: 0x00000000
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
7F539088C400 00000000 00000000 00000000 00000000  [................]
  Repeat 255 times
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
…………
[root@oradb1 ~]#kfed read /dev/mapper/asm-disk1 aun=999
kfbh.endian:                          0 ; 0x000: 0x00
kfbh.hard:                            0 ; 0x001: 0x00
kfbh.type:                            0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt:                          0 ; 0x003: 0x00
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:                       0 ; 0x008: file=0
kfbh.check:                           0 ; 0x00c: 0x00000000
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
7F8FEB795400 00000000 00000000 00000000 00000000  [................]
  Repeat 255 times
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]

通过分析disk 1和disk 2的前面1001MB数据,以及asm的数据分布特性,可以确认丢失的1000MB数据为39号文件的数据(和客户当时这个库是通过rman还原过来的操作有关系)

对于这样的情况,通过底层扫描,可以很好的恢复数据,参考以前类似文章
asm disk被加入vg恢复
asm disk header 彻底损坏恢复
asm磁盘dd破坏恢复
通过底层恢复,恢复结果如下

dbv检查数据文件

然后把数据库恢复出来数据文件中的数据恢复到新库中,至此完成该case恢复

File #xxx found in data dictionary but not in controlfile. Creating OFFLINE file ‘MISSING00XXX’ in the controlfile

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：File #xxx found in data dictionary but not in controlfile. Creating OFFLINE file ‘MISSING00XXX’ in the controlfile

接手客户的库,已经被强制resetlogs 报ORA-600 2662错误

Sat Mar 19 20:07:48 2022
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 26228222518
Clearing online redo logfile 1 /u2/oradb/oradata/xff/redo01.log
Clearing online log 1 of thread 1 sequence number 0
Clearing online redo logfile 1 complete
Online log /u2/oradb/oradata/xff/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u2/oradb/oradata/xff/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u2/oradb/oradata/xff/redo03.log: Thread 1 Group 3 was previously cleared
Sat Mar 19 20:08:02 2022
Setting recovery target incarnation to 2
Sat Mar 19 20:08:07 2022
Assigning activation ID 2327373166 (0x8ab8e56e)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /u2/oradb/oradata/xff/redo01.log
Successful open of redo thread 1
Sat Mar 19 20:08:14 2022
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Mar 19 20:08:14 2022
SMON: enabling cache recovery
ORA-00600: internal error code, arguments: [2662], [6], [458447781], [6], [458448180], [12583056]
ORA-00600: internal error code, arguments: [2662], [6], [458447780], [6], [458448180], [12583056]
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [6], [458447778], [6], [458448180], [12583056]
Incident details in: /u2/oradb/diag/rdbms/xifenfei/xifenfei/incident/incdir_1181122/xifenfei_ora_19893_i1181122.trc
Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/incident/incdir_1181122/xifenfei_ora_19893_i1181122.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [6], [458447781], [6], [458448180], [12583056]
ORA-00600: internal error code, arguments: [2662], [6], [458447780], [6], [458448180], [12583056]
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [6], [458447778], [6], [458448180], [12583056]

接手之后尝试获取创建控制文件脚本,报ORA-16433

Mon Mar 21 15:20:37 2022
alter database backup controlfile to trace as '/tmp/ctl'
ORA-16433 signalled during: alter database backup controlfile to trace as '/tmp/ctl'...

经过一些处理之后resetlogs 成功,但是悲剧产生了(客户之前自己重建过ctl,遗漏大量数据文件,然后我参照客户的ctl进行处理)使得新的ctl中遗漏的很多数据文件,库被resetlogs打开，导致部分文件的resetlog scn不一致,另外数据库还有ORA-600 4137错误需要处理

Mon Mar 21 15:35:01 2022
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 26228222522
Clearing online redo logfile 1 /u2/oradb/oradata/xff/redo01.log
Clearing online redo logfile 1 complete
Resetting resetlogs activation ID 2327373166 (0x8ab8e56e)
Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_4029.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: '/u2/oradb/oradata/xff/redo01.log'
Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_4029.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 2 of thread 1 is not current copy
ORA-00312: online log 2 thread 1: '/u2/oradb/oradata/xff/redo02.log'
Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_4029.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 3 of thread 1 is not current copy
ORA-00312: online log 3 thread 1: '/u2/oradb/oradata/xff/redo03.log'
Mon Mar 21 15:35:16 2022
Setting recovery target incarnation to 2
Mon Mar 21 15:35:23 2022
Assigning activation ID 2327514749 (0x8abb0e7d)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /u2/oradb/oradata/xff/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Mar 21 15:35:30 2022
SMON: enabling cache recovery
Undo initialization finished serial:0 start:191905344 end:191905754 diff:410 (4 seconds)
Dictionary check beginning
Tablespace 'TEMP' #3 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'DS_POS' #9 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Mon Mar 21 15:36:00 2022
File #498 found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00498' in the controlfile.
…………
File #567 found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00567' in the controlfile.
This file can no longer be recovered so it must be dropped.
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
Mon Mar 21 15:36:08 2022
SMON: enabling tx recovery
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
         This condition can occur when a backup controlfile has
         been restored.  It may be necessary to add files to these
         tablespaces.  That can be done using the SQL statement:
 
         ALTER TABLESPACE <tablespace_name> ADD TEMPFILE
 
         Alternatively, if these temporary tablespaces are no longer
         needed, then they can be dropped.
           Empty temporary tablespace: TEMP
*********************************************************************
Database Characterset is AL32UTF8
No Resource Manager plan active
Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_smon_4017.trc  (incident=1325274):
ORA-00600: internal error code, arguments: [4137], [28.27.4413199], [0], [0], [], [], [], [], [], [], [], []
Incident details in: /u2/oradb/diag/rdbms/xifenfei/xifenfei/incident/incdir_1325274/xifenfei_smon_4017_i1325274.trc
Use ADRCI or Support Workbench to package the incident.
Mon Mar 21 15:36:10 2022
db_recovery_file_dest_size of 49770 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Mon Mar 21 15:36:10 2022
Starting background process CJQ0
Mon Mar 21 15:36:10 2022
CJQ0 started with pid=27, OS id=4155 
Mon Mar 21 15:36:10 2022
Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_smon_4017.trc  (incident=1325275):
ORA-00600: internal error code, arguments: [4137], [36.20.1072031], [0], [0], [], [], [], [], [], [], [], []
Incident details in: /u2/oradb/diag/rdbms/xifenfei/xifenfei/incident/incdir_1325275/xifenfei_smon_4017_i1325275.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Mar 21 15:36:10 2022
Completed: alter database open resetlogs

对于类似：File #567 found in data dictionary but not in controlfile.Creating OFFLINE file ‘MISSING00567′ in the controlfile.
错误处理方法:(参照bbed解决ORA-01190
1. 从操作系统中找出来所有遗漏的文件
2. 通过bbed修改文件头信息
3. 重建ctl
4. 重新打开库

Mon Mar 21 16:06:39 2022
alter database open resetlogs
RESETLOGS after complete recovery through change 28991030095
Clearing online redo logfile 1 /u2/oradb/oradata/xff/redo01.log
Clearing online log 1 of thread 1 sequence number 0
Clearing online redo logfile 1 complete
Resetting resetlogs activation ID 2327514749 (0x8abb0e7d)
Online log /u2/oradb/oradata/xff/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u2/oradb/oradata/xff/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u2/oradb/oradata/xff/redo03.log: Thread 1 Group 3 was previously cleared
Mon Mar 21 16:06:53 2022
Setting recovery target incarnation to 2
Mon Mar 21 16:07:00 2022
Assigning activation ID 2327541328 (0x8abb7650)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /u2/oradb/oradata/xff/redo01.log
Successful open of redo thread 1
Mon Mar 21 16:07:07 2022
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Mar 21 16:07:07 2022
SMON: enabling cache recovery
Undo initialization finished serial:0 start:193802264 end:193802294 diff:30 (0 seconds)
Dictionary check beginning
Tablespace 'TEMP' #3 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Mon Mar 21 16:07:38 2022
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
Mon Mar 21 16:07:38 2022
SMON: enabling tx recovery
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
         This condition can occur when a backup controlfile has
         been restored.  It may be necessary to add files to these
         tablespaces.  That can be done using the SQL statement:
 
         ALTER TABLESPACE <tablespace_name> ADD TEMPFILE
 
         Alternatively, if these temporary tablespaces are no longer
         needed, then they can be dropped.
           Empty temporary tablespace: TEMP
*********************************************************************
Database Characterset is AL32UTF8
No Resource Manager plan active
**********************************************************
WARNING: Files may exists in db_recovery_file_dest
that are not known to the database. Use the RMAN command
CATALOG RECOVERY AREA to re-catalog any such files.
If files cannot be cataloged, then manually delete them
using OS command.
One of the following events caused this:
1. A backup controlfile was restored.
2. A standby controlfile was restored.
3. The controlfile was re-created.
4. db_recovery_file_dest had previously been enabled and
   then disabled.
**********************************************************
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Mon Mar 21 16:07:40 2022
QMNC started with pid=23, OS id=5476 
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Mon Mar 21 16:07:41 2022
db_recovery_file_dest_size of 49770 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Completed: alter database open resetlogs

至此数据库open成功,增加temp文件,然后逻辑迁移库