标签云
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故障恢复
分类目录归档:数据库
使用DBMS_PDB.RECOVER抢救单个pdb
尝试recover datafile 1 报ORA-600 kdBlkCheckError错误
Wed Jan 07 14:31:17 2026 Decreasing number of real time LMS from 5 to 0 ALTER DATABASE RECOVER datafile 1 Wed Jan 07 14:31:21 2026 Media Recovery Start Wed Jan 07 14:31:21 2026 Serial Media Recovery started Wed Jan 07 14:31:21 2026 Recovery of Online Redo Log: Thread 2 Group 24 Seq 2584 Reading mem 0 Mem# 0: +DATA/CDBDG/ONLINELOG/group_24.393.1122613933 Mem# 1: +ARCH/CDBDG/ONLINELOG/group_24.276.1122613933 Wed Jan 07 14:31:21 2026 Recovery of Online Redo Log: Thread 1 Group 18 Seq 13823 Reading mem 0 Mem# 0: +DATA/CDBDG/ONLINELOG/group_18.387.1122613923 Mem# 1: +ARCH/CDBDG/ONLINELOG/group_18.270.1122613925 Wed Jan 07 14:31:22 2026 Recovery of Online Redo Log: Thread 1 Group 19 Seq 13824 Reading mem 0 Mem# 0: +DATA/CDBDG/ONLINELOG/group_19.388.1122613925 Mem# 1: +ARCH/CDBDG/ONLINELOG/group_19.271.1122613925 Errors in file /u01/app/oracle/diag/rdbms/cdbdg/cdb1/trace/cdb1_ora_2753010.trc (incident=806358) (PDBNAME=CDB$ROOT): ORA-00600: internal error code, arguments: [kdBlkCheckError], [1], [105538], [6401], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/cdbdg/cdb1/incident/incdir_806358/cdb1_ora_2753010_i806358.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Wed Jan 07 14:31:25 2026 Media Recovery failed with error 10562 ORA-283 signalled during: ALTER DATABASE RECOVER datafile 1 ...
通过dbv检查file 1(system)数据文件,发现大量坏块
bash-4.2$ dbv file=system.271.1122584815 DBVERIFY: Release 12.1.0.2.0 - Production on Wed Jan 7 20:15:26 2026 Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved. DBVERIFY - Verification starting : FILE = /data/bak/system.271.1122584815 DBV-00200: Block, DBA 4195214, already marked corrupt DBV-00200: Block, DBA 4210332, already marked corrupt DBV-00200: Block, DBA 4210333, already marked corrupt …………………… DBV-00200: Block, DBA 4312889, already marked corrupt DBV-00200: Block, DBA 4313119, already marked corrupt DBV-00200: Block, DBA 4313122, already marked corrupt DBVERIFY - Verification complete Total Pages Examined : 524288 Total Pages Processed (Data) : 79989 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 20781 Total Pages Failing (Index): 0 Total Pages Processed (Other): 408840 Total Pages Processed (Seg) : 1 Total Pages Failing (Seg) : 0 Total Pages Empty : 14678 Total Pages Marked Corrupt : 33 Total Pages Influx : 0 Total Pages Encrypted : 0 Highest block SCN : 3135037281 (4374.3135037281)
分析发现这个库是包含了多个pdb,客户的业务主要在con_id=3的pdb中
bash-4.2$ sqlplus / as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Wed Jan 7 20:27:42 2026
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED MOUNTED
3 XFF MOUNTED
4 DYCW MOUNTED
SQL>
尝试对除cdb的system/sysaux之外的文件进行recover操作均成功

对于这种情况,比较好的处理思路就是通过对单独的pdb文件使用DBMS_PDB.RECOVER处理,然后插入到一个新的cdb中,第一步使用dbca创建一个和当前库字符集一样的cdb
dbca -silent -ignorePreReqs -createDatabase -templateName $ORACLE_HOME/assistants/dbca/templates/General_Purpose.dbc \ -responseFile NO_VALUE \ -gdbname oratest -sid oratest \ -createAsContainerDatabase TRUE \ -sysPassword oracle -systemPassword oracle -pdbAdminPassword oracle -dbsnmpPassword oracle \ -datafileDestination '/data/oradata' \ -redoLogFileSize 200 \ -characterset ZHS16GBK -nationalCharacterSet AL16UTF16 \ -totalMemory 4096 \ -databaseType MULTIPURPOSE \ -emConfiguration NONE
然后利用老的pdb生成需要的xml文件
BEGIN DBMS_PDB.RECOVER(PDB_DESCR_FILE=> '/tmp/XFF.xml', PDB_NAME=>'XFF', FILENAMES=> '/data/bak/system.268.1122584817, /data/bak/system.441.1125224053, /data/bak/sysaux.269.1122584817, ………… /data/bak/odin.312.1122593153, /data/bak/dsg.314.1122593223'); END; /
利用该xml文件,直接把这个pdb插入到新cdb中
Wed Jan 07 14:40:52 2026
create pluggable database XFF using '/tmp/XFF.xml' nocopy
Wed Jan 07 14:41:29 2026
Session (221,18860): EXTERNAL SCN ALERT: Advanced SCN by 3185580 minutes worth to 0x1116.bade672c,
by Pluggable Database plug-in
Session (221,18860): EXTERNAL SCN SOURCE: Inbound connection from client
Session (221,18860): EXTERNAL SCN SOURCE: DB Logon User: SYS, Remote Machine: p770a,
Program: sqlplus@p770a (TNS V1-V3),OS User: oracle
****************************************************************
Pluggable Database XFF with pdb id - 3 is created as UNUSABLE.
If any errors are encountered before the pdb is marked as NEW,
then the pdb must be dropped
****************************************************************
Database Characterset for XFF is ZHS16GBK
Deleting old file#8 from file$
Deleting old file#9 from file$
Deleting old file#10 from file$
…………
Deleting old file#148 from file$
Deleting old file#199 from file$
Deleting old file#200 from file$
Adding new file#9 to file$(old file#8)
Adding new file#8 to file$(old file#145)
Adding new file#10 to file$(old file#9)
…………
Adding new file#19 to file$(old file#148)
Adding new file#18 to file$(old file#199)
Adding new file#17 to file$(old file#200)
Marking tablespace #2 invalid since it is not present in the describe file
Successfully created internal service XFF at open
ALTER SYSTEM: Flushing buffer cache inst=0 container=3 local
Wed Jan 07 14:41:49 2026
****************************************************************
Post plug operations are now complete.
Pluggable database XFF with pdb id - 3 is now marked as NEW.
****************************************************************
Completed: create pluggable database XFF using '/tmp/XFF.xml' nocopy
alter database open
Wed Jan 07 14:43:21 2026
Pluggable database XFF dictionary check beginning
Tablespace 'TEMP' #2 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Pluggable Database XFF Dictionary check complete
Database Characterset for XFF is ZHS16GBK
*********************************************************************
WARNING: The following temporary tablespaces in container(XFF)
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
*********************************************************************
***************************************************************
WARNING: Pluggable Database XFF with pdb id - 3 is
altered with errors or warnings. Please look into
PDB_PLUG_IN_VIOLATIONS view for more details.
***************************************************************
Opening pdb XFF (3) with no Resource Manager plan active
Pluggable database XFF opened read write
Completed: alter database open
alter tablespace temp add tempfile '/data/bak/temp01.dbf' size 16m autoextend on
Completed: alter tablespace temp add tempfile '/data/bak/temp01.dbf' size 16m autoextend on
ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE
Wed Jan 07 14:46:08 2026
Immediate Kill Session#: 366, Serial#: 2995
Immediate Kill Session: sess: 7000100bafb5f58 OS pid: 5637924
ALTER SYSTEM: Flushing buffer cache inst=0 container=3 local
Wed Jan 07 14:46:22 2026
Pluggable database XFF closed
Completed: ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE
alter database open
Wed Jan 07 14:46:48 2026
Database Characterset for XFF is ZHS16GBK
***************************************************************
WARNING: Pluggable Database XFF with pdb id - 3 is
altered with errors or warnings. Please look into
PDB_PLUG_IN_VIOLATIONS view for more details.
***************************************************************
Opening pdb XFF (3) with no Resource Manager plan active
Pluggable database XFF opened read write
Completed: alter database open
这次4T多的aix环境rac数据库的单个pdb通过DBMS_PDB.RECOVER方法非常完美的恢复,DBMS_PDB.RECOVER是拯救单个pdb的神兵利器.
记录一次国产数据库被rm -rf /*删除的救援过程
有一套国产数据库运行在arm平台的Kylin Linux上
NAME=&quot;Kylin Linux Advanced Server&quot; VERSION=&quot;V10 (Lance)&quot; ID=&quot;kylin&quot; VERSION_ID=&quot;V10&quot; PRETTY_NAME=&quot;Kylin Linux Advanced Server V10 (Lance)&quot; ANSI_COLOR=&quot;0;31&quot;
由于数据库归档日志导致磁盘空间满,在清理归档日志的时候不慎执行了rm -rf /*命令

导致系统无法正常启动,客户尝试通过把磁盘挂载到其他机器上启动,但是无法恢复需要数据.由于客户这个是ssd盘的虚拟化环境,担心可能触发trim和进一步破坏的风险,建议客户尽快把虚拟磁盘下载到本地,然后通过工具分析,发现大量数据已经被删除,特别是数据库目录只剩下部分文件

通过分析data/global/1262文件(pg_database)的出来数据库名字对应关系,然后根据应用提供的需要恢复的数据库名称.在data目录中尝试恢复该目录中oid文件,发现最核心的几个字典文件全部异常(元数据异常)

pg_class 1259 存储数据库中所有关系(表、索引、视图、序列等)的元数据 pg_attribute 1249 存储表的列(属性)信息,每个字段对应一行 pg_namespace 2615 存储模式(Schema)信息 pg_type 1247 存储数据类型信息(内置类型、自定义类型)
对于这种问题,普通的恢复工具无法解决,协调专业的文件系统恢复专家对其进行处理,比较完美的恢复出来的该目录下面绝大部分文件(包括字典文件)

有了比较完美的恢复出来了需要的数据库文件,然后pdu专家进行该国产库的块结构分析和调整程序并恢复出来数据


完成数据恢复之后,把数据提供给客户,由客户那边安排厂商进行后续应用层面工作(比如和历史数据整合,应用调试等),总体算比较完美帮忙客户完成了本次rm -rf /* 故障救援
数据库启动报 maximum number of processes () exceeded分析
比较少遇到打开一个数据库报ORA-00020: maximum number of processes () exceeded,导致open数据库失败
SQL> alter database open; alter database open * 第 1 行出现错误: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00450: background process 'QMNC' did not start ORA-00444: background process "QMNC" failed while starting ORA-00020: maximum number of processes () exceeded 进程 ID: 6340 会话 ID: 109 序列号: 3
看这个报错应该是由于进程数达到了限制,导致在open数据库过程中启动后台进程QMNC失败,导致open过程失败,分析进程数不足的原因,查看启动时候的参数配置
Fri Dec 26 16:48:27 2025 Adjusting the default value of parameter parallel_max_servers from 2560 to 135 due to the value of parameter processes (150) Starting ORACLE instance (normal) LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 Picked latch-free SCN scheme 3 Fri Dec 26 16:48:38 2025 Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST Autotune of undo retention is turned on. IMODE=BR ILAT =28 LICENSE_MAX_USERS = 0 SYS auditing is disabled Starting up: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options. Windows NT Version V6.2 CPU : 64 - type 8664, 32 Physical Cores Process Affinity : 0x0x0000000000000000 Memory (Avail/Total): Ph:82501M/130752M, Ph+PgF:103658M/150208M Using parameter settings in client-side pfile D:\PFILE.TXT on machine HISSERVER System parameters with non-default values: processes = 150 sga_target = 39296M control_files = "D:\ORACLE64\ORADATA\ORA817\CONTROL01.CTL" control_files = "D:\ORACLE64\RECOVERY_AREA\ORA817\CONTROL02.CTL" db_block_size = 8192 compatible = "11.2.0.0.0" db_recovery_file_dest = "D:\ORACLE64\recovery_area" db_recovery_file_dest_size= 4122M undo_tablespace = "UNDOTBS1" remote_login_passwordfile= "EXCLUSIVE" db_domain = "" dispatchers = "(PROTOCOL=TCP) (SERVICE=ora817XDB)" audit_file_dest = "D:\ORACLE64\ADMIN\ORA817\ADUMP" audit_trail = "DB" db_name = "ora817" open_cursors = 300 pga_aggregate_target = 13075M diagnostic_dest = "D:\ORACLE64" Fri Dec 26 16:49:10 2025 PMON started with pid=2, OS id=1992 Fri Dec 26 16:49:10 2025 PSP0 started with pid=3, OS id=6744 Fri Dec 26 16:49:12 2025 VKTM started with pid=4, OS id=7592 at elevated priority Fri Dec 26 16:49:12 2025 GEN0 started with pid=5, OS id=7780 Fri Dec 26 16:49:12 2025 DBRM started with pid=7, OS id=5372 Fri Dec 26 16:49:12 2025 MMAN started with pid=9, OS id=6700 Fri Dec 26 16:49:12 2025 DBW0 started with pid=10, OS id=1920 Fri Dec 26 16:49:12 2025 DBW1 started with pid=11, OS id=4476 Fri Dec 26 16:49:12 2025 DBW2 started with pid=12, OS id=6788 Fri Dec 26 16:49:12 2025 DBW3 started with pid=13, OS id=4608 Fri Dec 26 16:49:12 2025 DBW4 started with pid=14, OS id=6716 Fri Dec 26 16:49:12 2025 DBW5 started with pid=15, OS id=6252 Fri Dec 26 16:49:12 2025 DBW6 started with pid=16, OS id=7948 Fri Dec 26 16:49:12 2025 DBW7 started with pid=17, OS id=5868 Fri Dec 26 16:49:12 2025 LGWR started with pid=18, OS id=1644 Fri Dec 26 16:49:12 2025 CKPT started with pid=19, OS id=5704 Fri Dec 26 16:49:12 2025 SMON started with pid=20, OS id=4532 Fri Dec 26 16:49:12 2025 RECO started with pid=21, OS id=380 Fri Dec 26 16:49:12 2025 MMON started with pid=22, OS id=1316 Fri Dec 26 16:49:12 2025 MMNL started with pid=23, OS id=6108 Fri Dec 26 16:49:12 2025 DIAG started with pid=6, OS id=7904 Fri Dec 26 16:49:12 2025 starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'... starting up 1 shared server(s) ... ORACLE_BASE from environment = D:\ORACLE64
这里可以看出来数据库版本是11.2.0.3,processes配置为默认值150.进一步查看启动报错时候的alert日志
ALTER DATABASE RECOVER database Media Recovery Start started logmerger process Fri Dec 26 17:03:44 2025 Media Recovery failed with error 264 Slave exiting with ORA-283 exception Errors in file D:\ORACLE64\diag\rdbms\ora817\ora817\trace\ora817_pr00_344.trc: ORA-00283: recovery session canceled due to errors ORA-00264: no recovery required Recovery Slave PR00 previously exited with exception 283 ORA-283 signalled during: ALTER DATABASE RECOVER database ... alter database open Fri Dec 26 17:03:48 2025 Thread 1 opened at log sequence 37301 Current log# 2 seq# 37301 mem# 0: D:\ORACLE64\ORADATA\ORA817\REDO02.LOG Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Fri Dec 26 17:03:49 2025 SMON: enabling cache recovery [6340] Successfully onlined Undo Tablespace 2. Undo initialization finished serial:0 start:5143437 end:5143718 diff:281 (2 seconds) Verifying file header compatibility for 11g tablespace encryption.. Verifying 11g file header compatibility for tablespace encryption completed SMON: enabling tx recovery Fri Dec 26 17:03:49 2025 Database Characterset is ZHS16GBK No Resource Manager plan active replication_dependency_tracking turned off (no async multimaster replication found) ORA-00020: maximum number of processes (150) exceeded ORA-20 errors will not be written to the alert log for the next minute. Please look at trace files to see all the ORA-20 errors. Process P123 submission failed with error = 20 Starting background process QMNC Process QMNC submission failed with error = 20 Errors in file D:\ORACLE64\diag\rdbms\ora817\ora817\trace\ora817_ora_6340.trc: ORA-00444: 后台进程 "QMNC" 启动失败 ORA-00020: 超出最大进程数 () Errors in file D:\ORACLE64\diag\rdbms\ora817\ora817\trace\ora817_ora_6340.trc: ORA-00450: 后台进程 'QMNC' 未启动 ORA-00444: 后台进程 "QMNC" 启动失败 ORA-00020: 超出最大进程数 () Errors in file D:\ORACLE64\diag\rdbms\ora817\ora817\trace\ora817_ora_6340.trc: ORA-00450: 后台进程 'QMNC' 未启动 ORA-00444: 后台进程 "QMNC" 启动失败 ORA-00020: 超出最大进程数 () Error 450 happened during db open, shutting down database USER (ospid: 6340): terminating the instance due to error 450 Fri Dec 26 17:03:50 2025 Errors in file D:\ORACLE64\diag\rdbms\ora817\ora817\trace\ora817_p036_8044.trc (incident=4105): ORA-01578: ORACLE data block corrupted (file # 9, block # 504643) ORA-01110: data file 9: 'D:\ORACLE64\ORADATA\ORA817\HRPRUN_DATA05.DBF' Incident details in: D:\ORACLE64\diag\rdbms\ora817\ora817\incident\incdir_4105\ora817_p036_8044_i4105.trc Fri Dec 26 17:03:50 2025 Process m000 submission failed with error = 20 Fri Dec 26 17:04:07 2025 Instance terminated by USER, pid = 6340 ORA-1092 signalled during: alter database open... opiodr aborting process unknown ospid (6340) as a result of ORA-1092 Fri Dec 26 17:04:09 2025 ORA-1092 : opitsk aborting process
看alert日志比较明显有Process P123 submission failed with error = 20提示,这里表示启动P123进程时候也遭遇到了进程数不足的限制导致该进程无法启动,而Pxxx进程是oracle的并行进程(而且在后面还报了由于坏块导致P036进程报错的信息),也就是说这个数据库在启动过程中启动了大量的并行进程(至少122个已经启动),这也就是说明了为什么150个进程不足的原因.在数据库完成实例恢复,完全open之前启动并行进程进行恢复的,很可能就是并行回滚操作.为了进一步验证猜想,把processes调整到1500,然后尝试启动库
Fri Dec 26 17:06:44 2025 alter database open Beginning crash recovery of 1 threads parallel recovery started with 32 processes Started redo scan Completed redo scan read 20 KB redo, 5 data blocks need recovery Started redo application at Thread 1: logseq 37301, block 18209 Recovery of Online Redo Log: Thread 1 Group 2 Seq 37301 Reading mem 0 Mem# 0: D:\ORACLE64\ORADATA\ORA817\REDO02.LOG Completed redo application of 0.02MB Completed crash recovery at Thread 1: logseq 37301, block 18249, scn 327081807 5 data blocks read, 5 data blocks written, 20 redo k-bytes read Fri Dec 26 17:06:46 2025 Thread 1 advanced to log sequence 37302 (thread open) Thread 1 opened at log sequence 37302 Current log# 3 seq# 37302 mem# 0: D:\ORACLE64\ORADATA\ORA817\REDO03.LOG Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Fri Dec 26 17:06:47 2025 SMON: enabling cache recovery [7104] Successfully onlined Undo Tablespace 2. Undo initialization finished serial:0 start:5321812 end:5322031 diff:219 (2 seconds) Verifying file header compatibility for 11g tablespace encryption.. Verifying 11g file header compatibility for tablespace encryption completed SMON: enabling tx recovery Database Characterset is ZHS16GBK No Resource Manager plan active replication_dependency_tracking turned off (no async multimaster replication found) Fri Dec 26 17:06:49 2025 Errors in file D:\ORACLE64\diag\rdbms\ora817\ora817\trace\ora817_p091_5924.trc (incident=5745): ORA-01578: ORACLE data block corrupted (file # 9, block # 504643) ORA-01110: data file 9: 'D:\ORACLE64\ORADATA\ORA817\HRPRUN_DATA05.DBF' Incident details in: D:\ORACLE64\diag\rdbms\ora817\ora817\incident\incdir_5745\ora817_p091_5924_i5745.trc Starting background process QMNC Fri Dec 26 17:06:49 2025 QMNC started with pid=156, OS id=8012 Errors in file D:\ORACLE64\diag\rdbms\ora817\ora817\trace\ora817_p091_5924.trc (incident=5746): ORA-01578: ORACLE data block corrupted (file # , block # ) Incident details in: D:\ORACLE64\diag\rdbms\ora817\ora817\incident\incdir_5746\ora817_p091_5924_i5746.trc Errors in file D:\ORACLE64\diag\rdbms\ora817\ora817\trace\ora817_smon_7424.trc (incident=4961): ORA-01578: ORACLE data block corrupted (file # 9, block # 504643) ORA-01110: data file 9: 'D:\ORACLE64\ORADATA\ORA817\HRPRUN_DATA05.DBF' Incident details in: D:\ORACLE64\diag\rdbms\ora817\ora817\incident\incdir_4961\ora817_smon_7424_i4961.trc Completed: alter database open SMON: Restarting fast_start parallel rollback Fri Dec 26 17:06:51 2025 Errors in file D:\ORACLE64\diag\rdbms\ora817\ora817\trace\ora817_p000_5472.trc (incident=5009): ORA-01578: ORACLE data block corrupted (file # 9, block # 504643) ORA-01110: data file 9: 'D:\ORACLE64\ORADATA\ORA817\HRPRUN_DATA05.DBF' Incident details in: D:\ORACLE64\diag\rdbms\ora817\ora817\incident\incdir_5009\ora817_p000_5472_i5009.trc Errors in file D:\ORACLE64\diag\rdbms\ora817\ora817\trace\ora817_p000_5472.trc (incident=5010): ORA-01578: ORACLE data block corrupted (file # , block # ) Errors in file D:\ORACLE64\diag\rdbms\ora817\ora817\trace\ora817_smon_7424.trc (incident=4962): ORA-01578: ORACLE data block corrupted (file # 9, block # 504643) ORA-01110: data file 9: 'D:\ORACLE64\ORADATA\ORA817\HRPRUN_DATA05.DBF' Incident details in: D:\ORACLE64\diag\rdbms\ora817\ora817\incident\incdir_5010\ora817_p000_5472_i5010.trc
这次就比较清晰了,数据库在open过程中由于smon启动了并行回滚并遇到了坏块,导致P091进程和smon进程错误。因为数据库已经open,这个坏块导致无法回滚,直接对这个对象进行处理即可解决掉这个回滚报错问题.



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

