标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 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-600 kdsgrp1 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)
- 操作系统 (112)
- 数据库 (1,851)
- DB2 (22)
- MySQL (81)
- Oracle (1,679)
- 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 (70)
- Oracle Bug (8)
- Oracle RAC (55)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (638)
- Oracle安装升级 (106)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (90)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (4)
- 达梦恢复 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (48)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (31)
-
最近发表
- Oracle 19c 202604补丁(RUs+OJVM)-19.31
- Oracle故障第一现场被恢复混乱的数据库恢复
- impdp报ORA-39083 ORA-14102错误处理
- 一次断电引起的Oracle故障恢复-ora-600 2662故障
- OraScan(Oracle 碎片扫描工具) 使用说明
- .[xueyuanjie@onionmail.org].AIR勒索加密数据库恢复
- oracleasm createdisk破坏的acfs文件系统恢复
- 先offline数据文件,再resetlogs导致恢复复杂的故障处理
- exp dmp导入报IMP-00098: INTERNAL ERROR: impgst2故障处理
- Oracle 19c Grid Infrastructure Release Update-202604(19.31)
- Oracle Database 19c Release Update-202604(19.31)
- aix环境rac 私网直连导致haip启动异常
- 又一例TRIM导致asm磁盘数据丢失的故障
- 一次运气好的ORA-600 kcratr_nab_less_than_odr故障处理
- OraFHR快速open被勒索加密破坏的Oracle数据库
- obet一键恢复offline数据文件
- 记录一次win删除数据文件完美恢复案例
- Oracle典型故障:The controlfile header block returned by the OS has a sequence number that is too old
- 国产信创库fio破坏主备库以及备份故障处理
- .wman扩展名勒索mysql数据库恢复
作者归档:惜分飞
Oracle 19c 202604补丁(RUs+OJVM)-19.31
| Release | Database Update | GI Update | Windows Bundle Patch |
| APR2026 (19.31.0.0.0) | 39034528 | - | 38818049 |
| JAN2026 (19.31.0.0.0) | - | 39036936 | - |
| JAN2026 (19.30.0.0.0) | 38632161 | 38629535 | 38597735 |
| OCT2025 (19.29.0.0.0) | 38291812 | 38298204 | 38111211 |
| JUL2025 (19.28.0.0.0) | 37960098 | 37957391 | 37962957 |
| APR2025 (19.27.0.0.0) | 37642901 | 37641958 | 37532350 |
| JAN2025 (19.26.0.0.0) | 37260974 | 37257886 | 37486199 |
| OCT2024 (19.25.0.0.0) | 36912597 | 36916690 | 36878821 |
| JUL2024 (19.24.0.0.0) | 36582781 | 36582629 | 36521936 |
| APR2024 (19.23.0.0.0) | 36233263 | 36233126 | 36219938 |
| JAN2024 (19.22.0.0.0) | 35943157 | 35940989 | 35962832 |
| OCT2023 (19.21.0.0.0) | 35643107 | 35642822 | 35681552 |
| JUL2023 (19.20.0.0.0) | 35320081 | 35319490 | 35348034 |
| APR2023 (19.19.0.0.0) | 35042068 | 35037840 | 35046439 |
| JAN2023 (19.18.0.0.0) | 34765931 | 34762026 | 34750795 |
| Oct2022 (19.17.0.0.0) | 34419443 | 34416665 | 34468114 |
| JUL2022 (19.16.0.0.0) | 34133642 | 34130714 | 34110685 |
| APR2022 (19.15.0.0.0) | 33806152 | 33803476 | 33829175 |
| JAN2022 (19.14.0.0.0) | 33515361 | 33509923 | 33575656 |
| OCT2021(19.13.0.0.0) | 33192793 | 33182768 | 33155330 |
| JUL2021 (19.12.0.0.0) | 32904851 | 32895426 | 32832237 |
| APR2021 (19.11.0.0.0) | 32545013 | 32545008 | 32409154 |
| JAN2021 (19.10.0.0.0) | 32218454 | 32226239 | 32062765 |
| OCT2020 (19.9.0.0.0) | 31771877 | 31750108 | 31719903 |
| JUL2020 (19.8.0.0.0) | 31281355 | 31305339 | 31247621 |
| APR2020 (19.7.0.0.0) | 30869156 | 30899722 | 30901317 |
| JAN2020 (19.6.0.0.0) | 30557433 | 30501910 | 30445947 |
| OCT2019 (19.5.0.0.0) | 30125133 | 30116789 | 30151705 |
| JUL2019 (19.4.0.0.0) | 29834717 | 29708769 | - |
| APR2019 (19.3.0.0.0) | 29517242 | 29517302 | - |
| Release | OJVM Update | OJVM + DB Update | OJVM + GI Update |
| APR2026 (19.31.0.0.260421) | 38906621 | 39062931 | 39062956 |
| JAN2026 (19.30.0.0.260120) | 38523609 | 38658587 | 38658588 |
| OCT2025 (19.29.0.0.251021) | 38194382 | 38273545 | 38273558 |
| JUL2025 (19.28.0.0.250715) | 37847857 | 37952354 | 37952382 |
| APR2025 (19.27.0.0.250415) | 37499406 | 37591483 | 37591516 |
| JAN2025 (19.26.0.0.250121) | 37102264 | 37262172 | 37262208 |
| OCT2024 (19.25.0.0.241015) | 36878697 | 36866623 | 36866740 |
| JUL2024 (19.24.0.0.240716) | 36414915 | 36522340 | 36522439 |
| APR2024 (19.23.0.0.240416) | 36199232 | 36209492 | 36209493 |
| JAN2024 (19.22.0.0.240116) | 35926646 | 36031426 | 36031453 |
| OCT2023 (19.21.0.0.231017) | 35648110 | 35742413 | 35742441 |
| JUL2023 (19.20.0.0.230718) | 35354406 | 35370174 | 35370167 |
| APR2023 (19.19.0.0.230418) | 35050341 | 35058163 | 35058172 |
| JAN2023 (19.18.0.0.230117) | 34786990 | 34773489 | 34773504 |
| OCT2022 (19.17.0.0.221018) | 34411846 | 34449114 | 34449117 |
| JUL2022 (19.16.0.0.220719) | 34086870 | 34160831 | 34160854 |
| APR2022 (19.15.0.0.220419) | 33808367 | 33859194 | 33859214 |
| JAN2022 (19.14.0.0.220118) | 33561310 | 33567270 | 33567274 |
| OCT2021 (19.13.0.0.211019) | 33192694 | 33248420 | 33248471 |
| JUL2021 (19.12.0.0.210720) | 32876380 | 32900021 | 32900083 |
| APR2021 (19.11.0.0.210420) | 32399816 | 32578972 | 32578973 |
| JAN2021 (19.10.0.0.210119) | 32067171 | 32126828 | 32126842 |
| OCT2020 (19.9.0.0.201020) | 31668882 | 31720396 | 31720429 |
| JUL2020 (19.8.0.0.200714) | 31219897 | 31326362 | 31326369 |
| APR2020 (19.7.0.0.200414) | 30805684 | 30783543 | 30783556 |
| JAN2020 (19.6.0.0.200114) | 30484981 | 30463595 | 30463609 |
| OCT2019 (19.5.0.0.191015) | 30128191 | 30133124 | 30133178 |
| JUL2019 (19.4.0.0.190716) | 29774421 | 29699079 | 29699097 |
| APR2019 (19.3.0.0.190416) | 29548437 | 29621253 | 29621299 |
参考:Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases KA958
Oracle故障第一现场被恢复混乱的数据库恢复
有客户数据库断电异常之后,由于第三方进行了一系列的恢复,现场比较混乱,无法判断最初情况,通过Oracle Database Recovery Check收集的结果进行初步判断
1. 有三个文件处于丢失状态,并且数据库在故障之后被人强制resetlogs拉过库

2. 数据文件头scn不一致,而且相差的日志序列还比较大(该数据库为非归档模式)

3. 该库多次重建ctl(alert日志中也有相关记录)

现在恢复这个库需要做的几件事情:
1. 由于没有任何原始故障之后的控制文件,需要从服务器上找出来所有故障之时的数据文件,担心被人重建ctl使用了错误的数据文件
2. 对于三个file missing的进行分析,并确认磁盘上是否存在,是否是好的,如果是好的需要和现在的文件一起作为一个整体进行恢复,并打开库
3. 打开数据库过程可能遇到的错误处理
通过obet中近期增加的get_dbinfo功能来解析所有可能的数据文件头(obet官方说明),结合文件头的信息判断,发现磁盘上名称dbf结尾的文件号重复

这样的情况下,我们取filesize大,(scn大不一定正确,可能由于被强制resetlogs导致scn比正确的文件大),同时也结合这个收集的信息,确认三个丢失的文件中两个为undotbs1表空间文件,另外一个为112k的数据文件,这里让我学习到了新知识,oracle的数据文件最小可以多少个block(通过试验测试,最小可以16个block,文件大小即为:16+1(block 0)*block_size)
C:\Users\XFF>sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on 星期三 5月 13 22:05:52 2026 Copyright (c) 1982, 2013, Oracle. 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 SQL> create tablespace tbs datafile 'e:/tbs01.dbf' size 8k; create tablespace tbs datafile 'e:/tbs01.dbf' size 8k * 第 1 行出现错误: ORA-03214: 指定的文件大小小于所需的最小值 SQL> create tablespace tbs datafile 'e:/tbs01.dbf' size 80k; create tablespace tbs datafile 'e:/tbs01.dbf' size 80k * 第 1 行出现错误: ORA-03214: 指定的文件大小小于所需的最小值 SQL> create tablespace tbs datafile 'e:/tbs01.dbf' size 96k; 表空间已创建。
确认好相关信息之后,然后对于三个file missing状态的文件进行dbv检测确认undotbs01.dbf(file 3)基本上全部损坏(大量全0块),另外两个文件正常

对于正常的文件通过obet修改相关scn信息

然后重建控制文件(丢弃undotbs01.dbf文件),由于确认undo已经异常,直接设置undo为manual管理方式并屏蔽回滚段,然后屏蔽一致性,强制打开数据库,结果报ORA-600 2662错误

使用Patch_SCN工具修改数据库scn(Patch_SCN工具说明)

然后数据库顺利打开,重建新undo,增加temp,删除老undo,导出数据完成本次恢复任务
impdp报ORA-39083 ORA-14102错误处理
最近两次遇到impdp 报 ORA-39083 ORA-14102错误
[oracle@localhost tmp]$ impdp "'/as sysdba'" directory=expdp_dir full=y dumpfile=1.dmp
Import: Release 11.2.0.1.0 - Production on Mon May 11 20:57:00 2026
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Master table "SYS"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYS"."SYS_IMPORT_FULL_01": "/******** AS SYSDBA" directory=expdp_dir full=y dumpfile=1.dmp
Processing object type TABLE_EXPORT/TABLE/TABLE
ORA-39083: Object type TABLE:"AAA"."XXXXX" failed to create with error:
ORA-14102: only one LOGGING or NOLOGGING clause may be specified
Failing sql is:
CREATE TABLE "AAA"."XXXX" ("OBJECT_ID" NUMBER(9,0) NOT NULL ENABLE, "OBJECT_TYPE" VARCHAR2(8 BYTE) NOT NULL ENABLE
……………………
这个错误比较明显由于AAA.XXXX表的创建语句中有多于一个LOGGING or NOLOGGING,从而导致该创建语句无法正常创建表.
[oracle@iZbp11c0qyuuo1gr7j98upZ ~]$ oerr ora 14102 14102, 00000, "only one LOGGING or NOLOGGING clause may be specified" // *Cause: LOGGING was specified more than once, NOLOGGING was specified // more than once, or both LOGGING and NOLOGGING were specified. // *Action: Remove all but one of the LOGGING or NOLOGGING clauses and // reissue the statement.
查看该表对应的expdp导出日志
[oracle@xff expdmp]$ expdp "'/as sysdba'" tables="AAA"."XXXX" dumpfile=1.dmp compression=all EXCLUDE=STATISTICS,AUDIT Export: Release 11.2.0.4.0 - Production on Mon May 11 21:01:06 2026 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, OLAP, Data Mining and Real Application Testing options Starting "SYS"."SYS_EXPORT_TABLE_01": tables=AAA.XXXX dumpfile=1.dmp compression=all EXCLUDE=STATISTICS,AUDIT Estimate in progress using BLOCKS method... Processing object type TABLE_EXPORT/TABLE/TABLE_DATA Total estimation using BLOCKS method: 3.207 GB Processing object type TABLE_EXPORT/TABLE/TABLE Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT . . exported "AAA"."XXXX":"F_GTG" 5.430 MB 968776 rows . . exported "AAA"."XXXX":"F_CONS" 4.734 MB 920007 rows …………
比较明显AAA.XXXX表是一个分区表,而且是从11.2.0.4中导出,然后准备导入到11.2.0.1版本数据库中.通过DBMS_METADATA.get_ddl来获取该表的ddl语句确实有多个LOGGING/NOLOGGING(主要是每个分区都有NOLOGGING)
SET ECHO OFF
SET PAGESIZE 0
SET LINES 3000
SET LONG 200000
SET FEEDBACK OFF
SET HEADING OFF
SET SERVEROUTPUT ON SIZE 1000000
COLUMN TXT FORMAT A3000 WORD_WRAPPED
SQL> SQL> SELECT DBMS_METADATA.GET_DDL('TABLE','XXXX','AAA') TXT FROM DUAL;
CREATE TABLE "AAA"."XXXX"
( "OBJECT_ID" NUMBER(9,0) NOT NULL ENABLE,
"OBJECT_TYPE" VARCHAR2(8) NOT NULL ENABLE,
"DL_TYPE" VARCHAR2(8) NOT NULL ENABLE,
………………
CONSTRAINT "PK_OBJECT_DL_DEF" PRIMARY KEY ("OBJECT_ID", "OBJECT_TYPE", "DL_TYPE")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS NOLOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS" ENABLE
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOLOGGING
STORAGE(
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS"
PARTITION BY LIST ("OBJECT_TYPE")
(PARTITION "F_SUBS" VALUES ('1') SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
NOCOMPRESS NOLOGGING
STORAGE(INITIAL 8388608 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS" ,
……………………
尝试在11.2.0.1环境中人工执行该sql创建表,直接报ORA-14020: 不能指定表分区的此物理属性错误

基于此基本上可以确认是由于11.2.0.1默认情况下不支持这样的语法,解决该问题的办法:
1. 重新导出来expdp dmp,加上version=11.2.0.1参数
2. impdp加上impdp TRANSFORM参数TRANSFORM=segment_attributes:n进行导入(impdp TRANSFORM参数)

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

