aix环境10g由于控制器异常导致ORA-600 4000故障处理

Posted on 2026 年 02 月 01 日 by 惜分飞

一台运行在aix环境下面的10.2.0.1的数据库

由于控制器异常导致数据库启动的时候报ORA-600 4000错误

Wed Jan 28 18:17:06 2026
Completed crash recovery at
 Thread 1: logseq 499321, block 14459, scn 17457591400427
 257 data blocks read, 41 data blocks written, 14457 redo blocks read
Wed Jan 28 18:17:06 2026
Thread 1 advanced to log sequence 499322
Thread 1 opened at log sequence 499322
  Current log# 2 seq# 499322 mem# 0: /dev/rrk_redo2
Successful open of redo thread 1
Wed Jan 28 18:17:06 2026
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Jan 28 18:17:06 2026
SMON: enabling cache recovery
Wed Jan 28 18:17:07 2026
Errors in file /u01/app/oracle/admin/orcl1/udump/orcl1_ora_16187632.trc:
ORA-00600: internal error code, arguments: [4000], [9], [], [], [], [], [], []
Wed Jan 28 18:17:08 2026
Errors in file /u01/app/oracle/admin/orcl1/udump/orcl1_ora_16187632.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [9], [], [], [], [], [], []
Wed Jan 28 18:17:08 2026
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 16187632
ORA-1092 signalled during: alter database open...

ORA-600 4000这个是在10g版本中非常常见的一个错误,一般是由于对应的block上面有事务没有提交或者scn过大导致,跟踪数据库启动过程发现在以下sql语句报错,而且报错为file 1 block 27527

EXEC #2:c=0,e=62,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=437860213380
WAIT #2: nam='db file sequential read' ela= 139 file#=1 block#=27527 blocks=1 obj#=-1 tim=437860213555
*** 2026-01-31 15:31:40.417
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [4000], [9], [], [], [], [], [], []
Current SQL statement for this session:
select rowcnt,blkcnt,empcnt,avgspc,chncnt,avgrln,nvl(degree,1), nvl(instances,1) from tab$ where obj# = :1

这里可以获取到两个有效信息:
1. 报错block为：file 1 block 27227
2. 报错sql为：select rowcnt,blkcnt,empcnt,avgspc,chncnt,avgrln,nvl(degree,1), nvl(instances,1) from tab$ where obj# = :1

进一步对报错数据块进行分析

Block header dump:  0x00406b87
 Object id on Block? Y
 seg/obj: 0x2  csc: 0xfe0.a99d3719  itc: 2  flg: -  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000b.014.00f1bb09  0x008027a5.eada.0e  C---    0  scn 0x0fda.f353b198
0x02   0x0009.01e.00212e2a  0x01400cdf.113e.01  --U-    1  fsc 0x0000.a99d371b

这里可以确认几个有效信息:
1. 该block的csc scn为:17457592743705
2. 一条已经提交的事务的scn为:17433059635608
3. 还有一条没有提交的事务,使用的回滚段为9,这个和我们报错的ORA-600[4000][9]这个回滚段名称匹配上

基于上述分析,我们需要确认两件事情:
1. 通过Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本检查结果,确认当前是数据库的文件头scn为:17457591420434小于该block的csc scn

2. itl操上面有一个锁需要提交,通过bbed工具对其进行提交,然后得出dump block信息

Block header dump:  0x00406b87
 Object id on Block? Y
 seg/obj: 0x2  csc: 0xfe0.a99d3719  itc: 2  flg: -  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x000b.014.00f1bb09  0x008027a5.eada.0e  C---    0  scn 0x0fda.f353b198
0x02   0x0009.01e.00212e2a  0x01400cdf.113e.01  C---    0  scn 0x0000.a99d371b

修改好itl之后,先尝试重启库,如果不出意外应该会报ORA-600 2662类似错误（因为前面分析了csc scn大于文件头scn的问题）

这里的ORA-600 2662中的4221831就是报错的rdba地址(10进制),通过dbms_utility.data_block_address_file转换

SQL> select dbms_utility.data_block_address_file(4221831) "file",
  2  dbms_utility.data_block_address_block(4221831) "block"
  3   from dual;

      file      block
---------- ----------
         1      27527

得出报错的ORA-600 2662的block就是我们之前分析和修复的itl块,通过修改该块scn或者修改数据库scn,该库均可open,后续就是安排导出数据导入新库的活

ORA-600 3716故障处理

Posted on 2026 年 01 月 31 日 by 惜分飞

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

标题：ORA-600 3716故障处理

数据库由于ORA-600 kcvent_intcic_zero_half错误导致实例重启

Reconfiguration started (old inc 8, new inc 10)
List of instances:
 1 2 (myinst: 2) 
 Nested reconfiguration detected. 
 Global Resource Directory frozen
 Communication channels reestablished
 * domain 0 valid = 1 according to instance 1 
 Master broadcasted resource hash value bitmaps
 Non-local Process blocks cleaned out
 LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
 LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
 Set master node info 
 Submitted all remote-enqueue requests
 Dwn-cvts replayed, VALBLKs dubious
 All grantable enqueues granted
Fri Jan 30 22:07:08 2026
minact-scn: Master returning as live inst:1 has inc# mismatch instinc:0 cur:10 errcnt:0
 Submitted all GCS remote-cache requests
 Fix write in gcs resources
Reconfiguration complete
Fri Jan 30 22:07:17 2026
Errors in file /u01/oracle11g/diag/rdbms/hisdb/hisdb2/trace/hisdb2_ckpt_1748.trc  (incident=228496):
ORA-00600: internal error code, arguments: [kcvent_intcic_zero_half], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/oracle11g/diag/rdbms/hisdb/hisdb2/incident/incdir_228496/hisdb2_ckpt_1748_i228496.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u01/oracle11g/diag/rdbms/hisdb/hisdb2/trace/hisdb2_ckpt_1748.trc:
ORA-00600: internal error code, arguments: [kcvent_intcic_zero_half], [], [], [], [], [], [], [], [], [], [], []
CKPT (ospid: 1748): terminating the instance due to error 469
Fri Jan 30 22:07:18 2026
ORA-1092 : opitsk aborting process
Fri Jan 30 22:07:19 2026
System state dump requested by (instance=2, osid=1748 (CKPT)), summary=[abnormal instance termination].

初步分析该错误是由于oracle bug引起,在11.2.0.4版本中比较少见,主要常见于19c版本中

正常情况下,实例重启即可,这个客户比较不幸,数据库重启遭遇ORA-600 3716错误

ALTER DATABASE OPEN /* db agent *//* {0:11:28647} */
This instance was first to open
Beginning crash recovery of 2 threads
 parallel recovery started with 15 processes
Started redo scan
Completed redo scan
 read 1120 KB redo, 386 data blocks need recovery
Started redo application at
 Thread 2: logseq 847, block 641786
Recovery of Online Redo Log: Thread 2 Group 3 Seq 847 Reading mem 0
  Mem# 0: +DATADISK/hisdb/onlinelog/group_3.267.1109863469
  Mem# 1: +ARCHIVEDISK/hisdb/onlinelog/group_3.261.1109863469
Completed redo application of 0.38MB
Completed crash recovery at
 Thread 2: logseq 847, block 644027, scn 20674490933
 386 data blocks read, 0 data blocks written, 1120 redo k-bytes read
ARCH: STARTING ARCH PROCESSES
Fri Jan 30 22:07:47 2026
ARC0 started with pid=53, OS id=332 
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Fri Jan 30 22:07:48 2026
ARC1 started with pid=54, OS id=364 
Fri Jan 30 22:07:48 2026
ARC2 started with pid=55, OS id=366 
Fri Jan 30 22:07:48 2026
ARC3 started with pid=56, OS id=368 
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Errors in file /u01/oracle11g/diag/rdbms/hisdb/hisdb2/trace/hisdb2_ora_29981.trc  (incident=240679):
ORA-00600: ??????, ??: [3716], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/oracle11g/diag/rdbms/hisdb/hisdb2/incident/incdir_240679/hisdb2_ora_29981_i240679.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Abort recovery for domain 0
Aborting crash recovery due to error 600
Errors in file /u01/oracle11g/diag/rdbms/hisdb/hisdb2/trace/hisdb2_ora_29981.trc:
ORA-00600: ??????, ??: [3716], [], [], [], [], [], [], [], [], [], [], []
Abort recovery for domain 0
Errors in file /u01/oracle11g/diag/rdbms/hisdb/hisdb2/trace/hisdb2_ora_29981.trc:
ORA-00600: ??????, ??: [3716], [], [], [], [], [], [], [], [], [], [], []
ORA-600 signalled during: ALTER DATABASE OPEN /* db agent *//* {0:11:28647} */...

接手客户故障尝试启动数据库也报ORA-600 3716错误

SQL> startup
ORACLE instance started.

Total System Global Area 2.0176E+10 bytes
Fixed Size                  2261928 bytes
Variable Size            3288337496 bytes
Database Buffers         1.6844E+10 bytes
Redo Buffers               41463808 bytes
Database mounted.
ORA-00600: internal error code, arguments: [3716], [], [], []

根据官方描述该问题

那解决该问题相对比较简单

SQL>@rectl.sql

Control file created.
SQL> recover database;
Media recovery complete.
SQL> alter database open;

Database altered.

完美恢复这次故障,实现数据0丢失,业务直接使用

不当恢复truncate数据导致数据库不能open处理

Posted on 2026 年 01 月 30 日 by 惜分飞

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

标题：不当恢复truncate数据导致数据库不能open处理

有客户误truncate操作干掉了数据库中的几张表,然后尝试通过FY_Recover_Data进行恢复,恢复到一半然后终止了,数据库结果就起不来了(具体什么原因不知道,肯定是各种不合适的操作引起的故障),我接手故障的时候,数据库被强制resetlogs,报ORA-600 2662错误

Fri Jan 30 10:24:16 2026
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 49708968810
Clearing online redo logfile 1 /u01/oracle/oradata/orcl/redo01.log
Clearing online log 1 of thread 1 sequence number 1069648
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 /u01/oracle/oradata/orcl/redo02.log
Clearing online log 2 of thread 1 sequence number 1069649
Clearing online redo logfile 2 complete
Clearing online redo logfile 3 /u01/oracle/oradata/orcl/redo03.log
Clearing online log 3 of thread 1 sequence number 1069647
Clearing online redo logfile 3 complete
Resetting resetlogs activation ID 1738690566 (0x67a25006)
Online log /u01/oracle/oradata/orcl/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u01/oracle/oradata/orcl/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u01/oracle/oradata/orcl/redo03.log: Thread 1 Group 3 was previously cleared
Fri Jan 30 10:24:17 2026
Setting recovery target incarnation to 3
Fri Jan 30 10:24:17 2026
Assigning activation ID 1751706121 (0x6868ea09)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /u01/oracle/oradata/orcl/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Jan 30 10:24:17 2026
SMON: enabling cache recovery
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_14707.trc  (incident=123363):
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328561], [11], [2464328917], [12583040], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/orcl/orcl/incident/incdir_123363/orcl_ora_14707_i123363.trc
Fri Jan 30 10:24:18 2026
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_14707.trc:
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328561], [11], [2464328917], [12583040], [], [], [], []
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_14707.trc:
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328561], [11], [2464328917], [12583040], [], [], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 14707): terminating the instance due to error 600
Instance terminated by USER, pid = 14707
ORA-1092 signalled during: alter database open resetlogs...
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_14707.trc:
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328564], [11], [2464328917], [12583040], [], [], [], []
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328563], [11], [2464328917], [12583040], [], [], [], []
ORA-01092: ORACLE 实例终止。强制断开连接
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328561], [11], [2464328917], [12583040], [], [], [], []
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_14707.trc:
ORA-27300: 操作系统系统相关操作: semctl 失败, 状态为: 22
ORA-27301: 操作系统故障消息: Invalid argument
ORA-27302: 错误发生在: sskgpwpost1
ORA-27303: 附加信息: semid = 32779
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328564], [11], [2464328917], [12583040], [], [], [], []
ORA-00600: 内部错误代码, 参数: [2662], [11], [2464328563], [11], [2464328917], [12583040], [], [], [], []
ORA-01092: ORACLE 实例终止。强制断开连接
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [11], [2464328564], [11], [2464328917], [12583040], []
ORA-00600: internal error code, arguments: [2662], [11], [2464328563], [11], [2464328917], [12583040], []
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [11], [2464328561], [11], [2464328917], [12583040], []

通过Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本检查发现有文件被offline,且resetlogs 信息不对

通过obet工具(Oracle数据块编辑工具( Oracle Block Editor Tool)-obet)对resetlogs相关信息进行修改

OBET> set mode edit
mode set to: edit

OBET> set file 18
filename set to: /tmp/FY_RST_DATA.DAT (file#18)

OBET> copy resetlogscn file 1 to file 18

Confirm Modify resetlogscn:
Source: file#1 (/u01/oracle/oradata/orcl/system01.dbf)
Target: file#18 (/tmp/FY_RST_DATA.DAT)
Proceed? (Y/YES to confirm): y
Successfully copied resetlog SCN information from file#1 to file#18.

OBET> copy chkscn file 1 to file 18

Confirm Modify chkscn:
Source: file#1 (/u01/oracle/oradata/orcl/system01.dbf)
Target: file#18 (/tmp/FY_RST_DATA.DAT)
Proceed? (Y/YES to confirm): y
Successfully copied checkpoint SCN information from file#1 to file#18.

OBET> sum
Check value for File /tmp/FY_RST_DATA.DAT, Block 1:
current = 0xF8EA, required = 0xFCEA

OBET> sum check
Warning: Unknown option 'check', ignored
Check value for File /tmp/FY_RST_DATA.DAT, Block 1:
current = 0xF8EA, required = 0xFCEA

OBET> sum apply

Confirm applying checksum:
File: /tmp/FY_RST_DATA.DAT
Block: 1
Offset in block: 16 (file offset: 0x00002010)
Original value: 0xF8EA
New value:      0xFCEA
Confirm? (Y/YES to proceed): y
Verification successful: Stored checksum matches calculated value (0xFCEA).
Checksum applied successfully.

然后尝试打开库,报ORA-600 kdourp_inorder2错误

Database Characterset is ZHS16GBK
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_9198.trc  (incident=159324):
ORA-00600: internal error code, arguments: [kdourp_inorder2], [16], [0], [146], [108], [], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/orcl/orcl/incident/incdir_159324/orcl_smon_9198_i159324.trc
Stopping background process MMNL
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Block recovery from logseq 2, block 39 to scn 49708988852
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0: /u01/oracle/oradata/orcl/redo02.log
Block recovery completed at rba 2.42.16, scn 11.2464348597
ORACLE Instance orcl (pid = 14) - Error 600 encountered while recovering transaction (14, 8) on object 14.
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_9198.trc:
ORA-00600: internal error code, arguments: [kdourp_inorder2], [16], [0], [146], [108], [], [], [], [], []
Stopping background process MMON
Fri Jan 30 11:42:26 2026
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_9198.trc  (incident=159325):
ORA-00600: internal error code, arguments: [kdourp_inorder2], [16], [0], [146], [108], [], [], [], [], []
Incident details in: /u01/oracle/diag/rdbms/orcl/orcl/incident/incdir_159325/orcl_smon_9198_i159325.trc
Starting background process MMON
Fri Jan 30 11:42:27 2026
MMON started with pid=49, OS id=10684
Starting background process MMNL
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Block recovery from logseq 2, block 39 to scn 49708988852
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0: /u01/oracle/oradata/orcl/redo02.log
Block recovery completed at rba 2.42.16, scn 11.2464348597
ORACLE Instance orcl (pid = 14) - Error 600 encountered while recovering transaction (14, 8) on object 14.
Errors in file /u01/oracle/diag/rdbms/orcl/orcl/trace/orcl_smon_9198.trc:
ORA-00600: internal error code, arguments: [kdourp_inorder2], [16], [0], [146], [108], [], [], [], [], []

该报错比较明显是由于undo回滚段异常导致,通过屏蔽回滚段,open库成功.后续对客户truncate的表进行分析,比较悲催由于没有第一时间保护现场而且对所在表空间进行了大量写入操作,导致truncate数据恢复较少.

Patch_SCN快速解决ORA-600 2663故障

Posted on 2026 年 01 月 16 日 by 惜分飞

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

标题：Patch_SCN快速解决ORA-600 2663故障

一个维保客户和我说他们测试库删除了日志文件导致库无法启动,让我帮忙看看
客户现场现况
1. 磁盘空间使用100%

[oracle@We1-db_Test ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           3.9G  880K  3.9G   1% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/vda1        40G   38G   92M 100% /
tmpfs           783M     0  783M   0% /run/user/0

2. 数据库redo被删除了部分,而且是active状态的被删除

[oracle@We1-db_Test ~]$ ls -l /opt/app/oracle/oradata/orcl/redo0*
-rw-r----- 1 oracle oinstall 52429312 Jan 15 15:29 /opt/app/oracle/oradata/orcl/redo04.log
-rw-r----- 1 oracle oinstall 52429312 Jan 15 16:26 /opt/app/oracle/oradata/orcl/redo05.log

SQL> select group#,SEQUENCE#,STATUS FROM V$lOG;

    GROUP#  SEQUENCE# STATUS
---------- ---------- ----------------
         1       8989 CURRENT
         2          0 UNUSED
         5          0 UNUSED
         4          0 UNUSED
         3       8988 ACTIVE

SQL> select member from v$logfile;

MEMBER
-----------------------------------------------------
/opt/app/oracle/oradata/orcl/redo03.log
/opt/app/oracle/oradata/orcl/redo02.log
/opt/app/oracle/oradata/orcl/redo01.log
/opt/app/oracle/oradata/orcl/redo04.log
/opt/app/oracle/oradata/orcl/redo05.log

基于当前情况,直接open库无望,但是空间不足问题需要先解决,不然恢复过程中创建redo空间不足依旧会报错卡死,所以先清理了监听和alert等日志,系统空闲了3G多空间,可以进行恢复操作

[oracle@We1-db_Test trace]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           3.9G  880K  3.9G   1% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/vda1        40G   34G  3.9G  90% /
tmpfs           783M     0  783M   0% /run/user/0

恢复数据库
1. 由于active redo丢失,毫无疑问,直接强制拉库,使用_allow_resetlogs_corruption参数开干

SQL> startup mount pfile='/tmp/pfile';
ORACLE instance started.

Total System Global Area 2455228416 bytes
Fixed Size                  2255712 bytes
Variable Size             905970848 bytes
Database Buffers         1526726656 bytes
Redo Buffers               20275200 bytes
Database mounted.
SQL> recover database until cancel;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done


SQL> recover database using backup controlfile;
ORA-00279: change 311982775 generated at 12/31/2025 17:35:11 needed for thread
1
ORA-00289: suggestion :
/opt/app/oracle/fast_recovery_area/ORCL/archivelog/2026_01_16/o1_mf_1_8988_%u_.a
rc
ORA-00280: change 311982775 for thread 1 is in sequence #8988


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0],
[311982833], [], [], [], [], [], [], []
Process ID: 11917
Session ID: 576 Serial number: 3

alert日志报错

Fri Jan 16 21:25:31 2026
Assigning activation ID 1750515127 (0x6856bdb7)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /opt/app/oracle/oradata/orcl/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Jan 16 21:25:31 2026
SMON: enabling cache recovery
Errors in file /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc  (incident=81753):
ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], []
Incident details in: /opt/app/oracle/diag/rdbms/orcl/we1db/incident/incdir_81753/we1db_ora_11917_i81753.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc:
ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], []
Errors in file /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc:
ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 11917): terminating the instance due to error 600
Instance terminated by USER, pid = 11917
ORA-1092 signalled during: alter database open resetlogs...
opiodr aborting process unknown ospid (11917) as a result of ORA-1092
Fri Jan 16 21:25:33 2026
ORA-1092 : opitsk aborting process

不幸数据库遇到ORA-600 2663错误,这个故障在以前的文章中描述过,基本上和ORA-600 2662的处理思路类似,这里直接使用:Patch_SCN for Linux进行恢复
2. 使用Patch_SCN处理数据库SCN

SQL> startup nomount pfile='/tmp/pfile';
ORACLE instance started.

Total System Global Area 2455228416 bytes
Fixed Size                  2255712 bytes
Variable Size             905970848 bytes
Database Buffers         1526726656 bytes
Redo Buffers               20275200 bytes
SQL>@rectl

Control file created.

SQL> recover database;
Media recovery complete.

SQL> alter database open;

Database altered.
SQL> SELECT CURRENT_SCN FROM V$DATABASE;

     CURRENT_SCN
----------------
       322002903

到这里完成数据库open操作,后续逻辑导出完成恢复任务

在生产环境错误执行dd命令破坏asm磁盘故障恢复

Posted on 2026 年 01 月 16 日 by 惜分飞

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

标题：在生产环境错误执行dd命令破坏asm磁盘故障恢复

由于ssh登录错误,客户对生产环境进行了误操作把系统的一块磁盘dd到另外两个磁盘上,由于及时发现立马进行了终止操作,但是还是分别破坏了一点数据(一块盘破坏了2G多,另外一块盘破坏了1G多)

通过分析udev的绑定关系确认被破坏的asm disk名称

再通过asm alert日志确认破坏磁盘在asm disk中情况

通过上述信息基本上可以确认,asmdisk13被分别dd到了asmdisk11和asmdisk26中了部分

基于这种情况,由于asm disk被破坏了1-2G多,直接修复然后正常mount磁盘组基本上没有希望,经过分析以及与客户沟通,确认他们改系统是4节点组成的集群,1/2节点上面跑2套库,3/4节点上跑2套库,数据整体放在data_dg磁盘组中,需要恢复的库是第二个顺序创建的1套库(4套库中只需恢复一套即可),由于破坏的数据本身不多,而且需要恢复的数据不是最初写入asm磁盘组,基于这样的情况,需要恢复的数据库机会比较大.

由于现在三个磁盘头信息一致(一个磁盘被dd到另外两个磁盘上),因此第一步先把损坏的两个磁盘头进行简单修复,为了便于amdu(找回ASM中数据文件)等之类数据可以识别到正确的磁盘头信息,然后进行后续的数据文件提取恢复.使用工具对数据文件进行了批量提取,提取数据完成之后,尝试recover和open库

虽然数据库正常打开了,不过很不幸,后台还是有一些坏块报错,通过dbv检查发现有文件有一部分坏块,类似dbv报错信息

通过分析该文件在磁盘组中各个磁盘的分布情况

确认该文件确实有部分block分布在被dd磁盘的破坏的范围内这个部分的数据丢失无法挽回,只能是定位到具体对象然后由业务想办法处理.相对以往的各种dd破坏的案例恢复而言,这个应该是效果比较好的一个,而且也是恢复比较容易的一个,没有使用到asm disk 基于asm au/oracle block 扫描的级别,而且system表空间没有任何损坏,数据库甚至直接open成功了,以往的一些dd案例列举:
asm磁盘dd破坏恢复
dd破坏asm磁盘头恢复
asm disk 磁盘部分被清空恢复