断电引起文件scn异常数据库恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:断电引起文件scn异常数据库恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

由于异常断电,数据库最初启动报错

Fri Mar 01 08:41:17 2024
ALTER DATABASE   MOUNT
Successful mount of redo thread 1, with mount id 1865809648
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Fri Mar 01 08:41:24 2024
ALTER DATABASE OPEN
Errors in file /home/oracle/app/diag/rdbms/XFF/XFF/trace/XFF_ora_25243.trc:
ORA-01113: file 13 needs media recovery
ORA-01110: data file 13: '/data2/oracle/oradata/data/data00.dbf'
ORA-1113 signalled during: ALTER DATABASE OPEN...

经过应用厂商一系列操作,主要是如下操作

Fri Mar 01 11:10:56 2024
ALTER DATABASE RECOVER  datafile 13  
Media Recovery Start
Serial Media Recovery started
WARNING! Recovering data file 13 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
ORA-279 signalled during: ALTER DATABASE RECOVER  datafile 13  ...
Fri Mar 01 11:11:09 2024
ALTER DATABASE RECOVER    CONTINUE DEFAULT  
Media Recovery Log /home/oracle/app/flash_recovery_area/XFF/archivelog/2024_03_01/o1_mf_1_153563_%u_.arc
Errors with log /home/oracle/app/flash_recovery_area/XFF/archivelog/2024_03_01/o1_mf_1_153563_%u_.arc
ORA-308 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
ALTER DATABASE RECOVER    CONTINUE DEFAULT  
Media Recovery Log /home/oracle/app/flash_recovery_area/XFF/archivelog/2024_03_01/o1_mf_1_153563_%u_.arc
Errors with log /home/oracle/app/flash_recovery_area/XFF/archivelog/2024_03_01/o1_mf_1_153563_%u_.arc
ORA-308 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
ALTER DATABASE RECOVER CANCEL 
Media Recovery Canceled
Completed: ALTER DATABASE RECOVER CANCEL 
Fri Mar 01 11:16:50 2024
db_recovery_file_dest_size of 10240 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.
Fri Mar 01 11:51:56 2024
Starting ORACLE instance (normal)
Fri Mar 01 12:11:35 2024
alter database datafile 13 offline
ORA-1145 signalled during: alter database datafile 13 offline...
Fri Mar 01 12:12:29 2024
alter database recover cancel
ORA-1112 signalled during: alter database recover cancel...
Fri Mar 01 12:13:24 2024
ALTER DATABASE RECOVER  database until cancel  
Media Recovery Start
 started logmerger process
Fri Mar 01 12:13:24 2024
WARNING! Recovering data file 13 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
WARNING! Recovering data file 14 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
WARNING! Recovering data file 15 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
WARNING! Recovering data file 16 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
WARNING! Recovering data file 17 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
WARNING! Recovering data file 18 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
WARNING! Recovering data file 19 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
WARNING! Recovering data file 20 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
WARNING! Recovering data file 21 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
WARNING! Recovering data file 22 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
Parallel Media Recovery started with 48 slaves
ORA-279 signalled during: ALTER DATABASE RECOVER  database until cancel  ...
ALTER DATABASE RECOVER    CONTINUE DEFAULT  
Media Recovery Log /home/oracle/app/flash_recovery_area/XFF/archivelog/2024_03_01/o1_mf_1_153563_%u_.arc
Errors with log /home/oracle/app/flash_recovery_area/XFF/archivelog/2024_03_01/o1_mf_1_153563_%u_.arc
Errors in file /home/oracle/app/diag/rdbms/XFF/XFF/trace/XFF_pr00_38097.trc:
ORA-00308:cannot open archived log '/home/app/flash_recovery_area/XFF/archivelog/2024_03_01/o1_mf_1_153563_%u_.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-308 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
ALTER DATABASE RECOVER    CONTINUE DEFAULT  
Media Recovery Log /home/oracle/app/flash_recovery_area/XFF/archivelog/2024_03_01/o1_mf_1_153563_%u_.arc
Errors with log /home/oracle/app/flash_recovery_area/XFF/archivelog/2024_03_01/o1_mf_1_153563_%u_.arc
Errors in file /home/oracle/app/diag/rdbms/XFF/XFF/trace/XFF_pr00_38097.trc:
ORA-00308:cannot open archived log '/home/app/flash_recovery_area/XFF/archivelog/2024_03_01/o1_mf_1_153563_%u_.arc'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-308 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
ALTER DATABASE RECOVER CANCEL 
Signalling error 1152 for datafile 1!
Errors in file /home/oracle/app/diag/rdbms/XFF/XFF/trace/XFF_pr00_38097.trc:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup 
ORA-01110: data file 1: '/data1/oracle/oradata/XFF/system01.dbf'
Slave exiting with ORA-1547 exception
Errors in file /home/oracle/app/diag/rdbms/XFF/XFF/trace/XFF_pr00_38097.trc:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup 
ORA-01110: data file 1: '/data1/oracle/oradata/XFF/system01.dbf'
ORA-10879 signalled during: ALTER DATABASE RECOVER CANCEL ...
Fri Mar 01 13:23:05 2024
ALTER DATABASE DATAFILE '/data2/oracle/oradata/data/data00.dbf' OFFLINE DROP
Completed: ALTER DATABASE DATAFILE '/data2/oracle/oradata/data/data00.dbf' OFFLINE DROP

接手现场之后,尝试单个文件recover操作

SQL> recover datafile 1;
ORA-00283: recovery session canceled due to errors
ORA-00264: no recovery required
SQL> recover datafile 2;
Media recovery complete.
SQL> recover datafile 3;
Media recovery complete.
SQL> recover datafile 4;
Media recovery complete.
SQL> recover datafile 5;
Media recovery complete.
SQL> recover datafile 6,7,8,9,10;
Media recovery complete.
SQL> recover datafile 11;
Media recovery complete.
SQL> recover datafile 12;
Media recovery complete.
SQL> recover datafile 13;
ORA-00279: change 1474236715 generated at 02/29/2024 17:13:00 needed for thread 1
ORA-00289: suggestion : /home/oracle/app/program/11g/dbs/arch1_153563_1136037378.dbf
ORA-00280: change 1474236715 for thread 1 is in sequence #153563


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00308: cannot open archived log '/home/oracle/app/program/11g/dbs/arch1_153563_1136037378.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3


SQL> recover datafile 14;
ORA-00279: change 1474236715 generated at 02/29/2024 17:13:00 needed for thread 1
ORA-00289: suggestion : /home/oracle/app/program/11g/dbs/arch1_153563_1136037378.dbf
ORA-00280: change 1474236715 for thread 1 is in sequence #153563


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00308: cannot open archived log '/home/oracle/app/program/11g/dbs/arch1_153563_1136037378.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

基于这样的情况,通过Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)检查发现/data2挂载点所有数据文件异常,由于以前的操作日志已经被清空无法判断原因,初步怀疑和这个挂载点本身有关系
20240303160404
20240303160524
这种情况直接使用bbed修改文件头,然后open库,再逻辑导出数据,完成本次数据恢复工作,参考类似文档
bbed 修改datafile header
使用bbed让rac中的sysaux数据文件online
当然这类故障也可以通过自研的Oracle Recovery Tools工具进行修复处理,类似文档:
Oracle Recovery Tools解决ORA-00279 ORA-00289 ORA-00280故障

ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

客户反馈,rac有一个节点无法open(可以mount),在open过程报如下错误
20240229194430


alert日志内容中报错主要为:
ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance

Thu Feb 29 17:46:15 2024
Successful mount of redo thread 1, with mount id 354054158
Database mounted in Shared Mode (CLUSTER_DATABASE=TRUE)
Lost write protection disabled
Completed: ALTER DATABASE MOUNT /* db agent *//* {1:32636:2} */
ALTER DATABASE OPEN /* db agent *//* {1:32636:2} */
Picked broadcast on commit scheme to generate SCNs
ARCH: STARTING ARCH PROCESSES
Thu Feb 29 17:46:16 2024
ARC0 started with pid=39, OS id=15401176 
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thu Feb 29 17:46:18 2024
ARC1 started with pid=41, OS id=11993228 
Thu Feb 29 17:46:18 2024
ARC2 started with pid=42, OS id=15007986 
Thu Feb 29 17:46:18 2024
ARC3 started with pid=43, OS id=12779724 
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
WARNING: The 'LOG_ARCHIVE_CONFIG' init.ora parameter settings
are inconsistent with another started instance.  This may be
caused by the 'DB_UNIQUE_NAME' init.ora parameter being specified
differently on one or more of the other RAC instances; the
DB_UNIQUE_NAME parameter value MUST be identical for all 
instances of the database.
Errors in file /oracle/oracle/diag/rdbms/xff/xff1/trace/xff1_lgwr_12976288.trc:
ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
LGWR (ospid: 12976288): terminating the instance due to error 16188
Thu Feb 29 17:46:18 2024
System state dump requested by(instance=1, osid=12976288 (LGWR)),summary=[abnormal instance termination].
System State dumped to trace file /oracle/oracle/diag/rdbms/xff/xff1/trace/xff1_diag_13041806.trc
Thu Feb 29 17:46:18 2024
ORA-1092 : opitsk aborting process
Thu Feb 29 17:46:19 2024
License high water mark = 1
Instance terminated by LGWR, pid = 12976288
USER (ospid: 15532254): terminating the instance
Instance terminated by USER, pid = 15532254

检查LOG_ARCHIVE_CONFIG和DB_UNIQUE_NAME参数配置

SQL> select inst_id,value,name,length(value) from gv$parameter where name in ('log_archive_config','db_unique_name');

   INST_ID VALUE                          NAME                                  LENGTH(VALUE)
---------- ------------------------------ ------------------------------------- -------------
         2                                log_archive_config
         2 xff                            db_unique_name                                    8
         1                                log_archive_config
         1 xff                            db_unique_name                                    8

设置尝试log_archive_config配置为”和reset 均数据库无法正常启动

SQL> alter system set log_archive_config='' sid='*';

系统已更改。

SQL> alter system reset log_archive_config scope=both sid='*';

系统已更改。

设置log_archive_config=NODG_CONFIG数据库启动成功

SQL> alter system set log_archive_config=NODG_CONFIG scope=both sid='*';

系统已更改。

SQL> alter database open;

数据库已更改。

SQL> exit
从 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options 断开

.[hudsonL@cock.li].mkp勒索加密数据库完美恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:.[hudsonL@cock.li].mkp勒索加密数据库完美恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有朋友oracle数据库所在机器被加密,扩展名为:.[hudsonL@cock.li].mkp,数据文件类似:
20240226230629


通过专业工具分析,确认这次运气非常好,每个文件就加密破坏前面31个block
20240226230757

通过研发的Oracle数据文件勒索恢复工具进行恢复
20240226214235
顺利数据库并且导出数据
20240226230950

mkp勒索病毒预防建议:
1. 教育和培训:提高用户的网络安全意识非常重要。通过定期的网络安全培训和教育,向用户传达有关勒索病毒及其传播方式的知识,让他们能够警惕潜在的威胁,并学会如何正确应对可疑的电子邮件、链接和附件。
2. 更新和维护:及时更新操作系统、应用程序和安全软件,以修补已知的漏洞,并确保系统能够及时获取最新的安全补丁。此外,定期进行系统维护和检查,确保系统的安全配置和设置。
3. 备份数据:定期备份重要的数据和文件,并将备份存储在安全的离线或云存储中。确保备份是完整的、可靠的,并且能够及时恢复,以便在发生勒索病毒感染或其他数据丢失事件时能够快速恢复数据。
4. 网络安全工具:使用可信赖的网络安全工具,包括防病毒软件、防火墙、入侵检测系统等,以提高系统的安全性和防护能力。定期对系统进行全面的安全扫描和检测,及时发现并清除潜在的威胁。
5. 访问控制:实施严格的访问控制措施,限制用户对系统和文件的访问权限,避免使用管理员权限进行日常操作,以减少恶意软件感染的风险。此外,定期审查和更新访问控制策略,确保系统安全性得到有效维护。
6. 应急响应计划:制定和实施应急响应计划,明确团队成员的责任和任务,建立应对勒索病毒和其他安全事件的应急响应流程,以最大程度地减少损失并快速恢复业务正常运营。

模拟带库实现rman远程备份

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:模拟带库实现rman远程备份

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

rman通过模拟带库备份到远程机器,需要先配置用户ssh到目标机器
linux平台oracle备份

RMAN> RUN {
2> ALLOCATE CHANNEL S1 DEVICE TYPE sbt
3> PARMS='SBT_LIBRARY=/tmp/rman_sync.so,ENV=(
4> OB_SERVER=www.xifenfei.com,
5> OB_USER=root,
6> OB_PORT=22123,
7> OB_PATH=/tmp)';
8> BACKUP CURRENT CONTROLFILE FORMAT 'ctl_%U';
9> }

allocated channel: S1
channel S1: SID=125 device type=SBT_TAPE
channel S1: SBT/SSH2-SFTP

Starting backup at 22-FEB-24
channel S1: starting full datafile backup set
channel S1: specifying datafile(s) in backup set
including current control file in backup set
channel S1: starting piece 1 at 22-FEB-24
channel S1: finished piece 1 at 22-FEB-24
piece handle=ctl_012jq4gg_1_1 tag=TAG20240222T190344 comment=API Version 2.0,MMS Version 1.0.9.0
channel S1: backup set complete, elapsed time: 00:00:25
Finished backup at 22-FEB-24
released channel: S1

RMAN> list backup;

List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
1       Full    9.50M      SBT_TAPE    00:00:24     22-FEB-24
        BP Key: 1   Status: AVAILABLE  Compressed: NO  Tag: TAG20240222T190344
        Handle: ctl_012jq4gg_1_1   Media: 0B2B9255
  Control File Included: Ckp SCN: 4438494      Ckp time: 22-FEB-24

win平台oracle备份

RMAN> RUN {
2>  ALLOCATE CHANNEL S1 DEVICE TYPE sbt
3>  PARMS='SBT_LIBRARY=D:\TEMP\rman_sync.dll,
4>  ENV=(
5>  OB_SERVER=www.xifenfei.com,
6>  OB_USER=root,
7>  OB_PORT=22123,
8>  OB_PATH=/tmp/,
9>  OB_PUBLIC_KEY=C:\Users\XIFENFEI\.ssh\id_rsa.pub,
10>  OB_SECRET_KEY=C:\Users\XIFENFEI\.ssh\id_rsa,
11>  OB_LOGFILE=d:\xifenfei.log)';
12>  BACKUP CURRENT CONTROLFILE FORMAT 'ctl_%U';
13>  }

分配的通道: S1
通道 S1: SID=156 设备类型=SBT_TAPE
通道S1: SBT/SSH2-SFTP

启动 backup 于 23-2月 -24
通道 S1: 正在启动全部数据文件备份集
通道 S1: 正在指定备份集内的数据文件
备份集内包括当前控制文件
通道 S1: 正在启动段 1 于 23-2月 -24
通道 S1: 已完成段 1 于 23-2月 -24
段句柄=ctl_012jt7mr_1_1 标记=TAG20240223T231642 注释=API Version 2.0,MMS Version 1.0.9.0
通道 S1: 备份集已完成, 经过时间:00:00:07
完成 backup 于 23-2月 -24
释放的通道: S1

RMAN> list backup;


备份集列表
===================


BS 关键字  类型 LV 大小       设备类型 经过时间 完成时间
------- ---- -- ---------- ----------- ------------ ----------
1       Full    9.50M      SBT_TAPE    00:00:05     23-2月 -24
        BP 关键字: 1   状态: AVAILABLE  已压缩: NO  标记: TAG20240223T231642
        句柄: ctl_012jt7mr_1_1   介质: 0B2B9255
  包括的控制文件: Ckp SCN: 14544437     Ckp 时间: 23-2月 -24

又一例:ORA-600 kclchkblk_4和2662故障

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:又一例:ORA-600 kclchkblk_4和2662故障

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户恢复请求:由于未知原因导致aix环境的rac两台主机同时重启之后数据库无法正常启动,初步判断是由于写丢失导致故障(ORA-00742 ORA-00353)

Wed Feb 21 09:23:06 2024
ALTER DATABASE OPEN
This instance was first to open
Abort recovery for domain 0
Errors in file /oracle/db/diag/rdbms/xff/xff1/trace/xff1_ora_5767246.trc:
ORA-01113: file 32 needs media recovery
ORA-01110: data file 32: '+DATA/xff/datafile/x5sys_cs.dbf'
ORA-1113 signalled during: ALTER DATABASE OPEN...
Wed Feb 21 09:23:27 2024
ALTER DATABASE RECOVER  datafile '+DATA/xff/datafile/x5sys_cs.dbf'  
Media Recovery Start
Serial Media Recovery started
WARNING! Recovering data file 32 from a fuzzy backup. It might be an online
backup taken without entering the begin backup command.
Recovery of Online Redo Log: Thread 2 Group 14 Seq 48490 Reading mem 0
  Mem# 0: +DATA/xff/onlinelog/group_14.313.1060528521
Recovery of Online Redo Log: Thread 1 Group 7 Seq 64195 Reading mem 0
  Mem# 0: +DATA/xff/onlinelog/group_7.306.1060527979
Wed Feb 21 09:24:10 2024
Errors in file /oracle/db/diag/rdbms/xff/xff1/trace/xff1_ora_5767246.trc:
ORA-00742: Log read detects lost write in thread %d sequence %d block %d
ORA-00334: archived log: '+DATA/xff/onlinelog/group_14.313.1060528521'
Errors in file /oracle/db/diag/rdbms/xff/xff1/trace/xff1_ora_5767246.trc  (incident=336478):
ORA-00353: log corruption near block 139727 change 26346459680 time 02/20/2024 20:13:50
ORA-00312: online log 14 thread 2: '+DATA/xff/onlinelog/group_14.313.1060528521'

尝试屏蔽一致性强制拉库后数据库报ORA-600 kclchkblk_4
参考:ora-600 2662和ora-600 kclchkblk_4恢复redo异常 ORA-600 kclchkblk_4 故障恢复

Wed Feb 21 09:55:26 2024
SMON: enabling cache recovery
Wed Feb 21 09:55:26 2024
Redo thread 2 internally disabled at seq 5 (CKPT)
Archived Log entry 112707 added for thread 2 sequence 4 ID 0xffffffffe144183b dest 1:
ARC0: Archiving disabled thread 2 sequence 5
Archived Log entry 112708 added for thread 2 sequence 5 ID 0xffffffffe144183b dest 1:
Wed Feb 21 09:55:28 2024
Errors in file /oracle/db/diag/rdbms/xff/xff1/trace/xff1_ora_6423264.trc  (incident=360479):
ORA-00600: internal error code, arguments: [kclchkblk_4], [6], [576721660], [6], [576702892]
Incident details in: /oracle/db/diag/rdbms/xff/xff1/incident/incdir_360479/xff1_ora_6423264_i360479.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Thread 1 advanced to log sequence 3 (LGWR switch)
  Current log# 7 seq# 3 mem# 0: +DATA/xff/onlinelog/group_7.306.1161510375
Archived Log entry 112709 added for thread 1 sequence 2 ID 0xffffffffe144183b dest 1:
Wed Feb 21 09:55:31 2024
Errors in file /oracle/db/diag/rdbms/xff/xff1/trace/xff1_ora_6423264.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [kclchkblk_4], [6], [576721660], [6], [576702892]
Errors in file /oracle/db/diag/rdbms/xff/xff1/trace/xff1_ora_6423264.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [kclchkblk_4], [6], [576721660], [6], [576702892]

后续处理中出现和这个错误类似的ORA-600 2662错误

Wed Feb 21 15:37:35 2024
SMON: enabling cache recovery
Errors in file /oracle/db/diag/rdbms/xff/xff1/trace/xff1_ora_6357664.trc  (incident=432423):
ORA-00600: internal error code, arguments: [2662], [6], [576742938], [6], [576834283], [12583104]
Incident details in: /oracle/db/diag/rdbms/xff/xff1/incident/incdir_432423/xff1_ora_6357664_i432423.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 /oracle/db/diag/rdbms/xff/xff1/trace/xff1_ora_6357664.trc:
ORA-00600: internal error code, arguments: [2662], [6], [576742938], [6], [576834283], [12583104], [], [], [], [], [], []
Errors in file /oracle/db/diag/rdbms/xff/xff1/trace/xff1_ora_6357664.trc:
ORA-00600: internal error code, arguments: [2662], [6], [576742938], [6], [576834283], [12583104], [], [], [], [], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 6357664): terminating the instance due to error 600
Instance terminated by USER, pid = 6357664

通过对oracle scn进行修改,数据库open成功

SQL> recover database;
Media recovery complete.
SQL> 
SQL> 
SQL> 
SQL> oradebug setmypid
Statement processed.
SQL> oradebug DUMPvar SGA kcsgscn_
kcslf kcsgscn_ [700000000019B70, 700000000019BA0) = 00000000 00000000 00000000 00000000 
SQL> oradebug poke 
BEFORE: [700000000019B70, 700000000019B78) = 00000000 00000000
AFTER:  [700000000019B70, 700000000019B78) = 00000006 22710D2B
SQL> oradebug DUMPvar SGA kcsgscn_ 
kcslf kcsgscn_ [700000000019B70, 700000000019BA0) = 00000006 22710D2B 00000000 00000000 
SQL> alter database open;

Database altered.

后续检查发现obj$中的index异常(ORA-08102: index key not found, obj# 39)
类似文章:通过bbed修改obj$中dataobj$重现I_OBJ4索引报ORA-08102错误

SQL> truncate CLUSTER "SYS"."SMON_SCN_TO_TIME_AUX";

truncate CLUSTER "SYS"."SMON_SCN_TO_TIME_AUX"
                       *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-08102: index key not found, obj# 39, file 1, block 967206 (2)

SQL> SQL> select object_name,object_type from dba_objects where object_id=39;

OBJECT_NAME                    OBJECT_TYPE
------------------------------ -------------------
I_OBJ4                         INDEX

对于此类问题使用非常规方法把obj$字典表进行重建(需要注意undo需要为自动管理方式,temp不能为空),参考:
bootstrap$核心index(I_OBJ1,I_USER1,I_FILE#_BLOCK#,I_IND1,I_TS#,I_CDEF1等)异常恢复—ORA-00701错误解决

Oracle误删除数据文件恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:Oracle误删除数据文件恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户通过sftp误删除oracle数据文件,咨询我们是否可以恢复,通过远程上去检查,发现运气不错,数据库还没有crash,通过句柄找到被删除文件

oracle@cwgstestdb[testwctdb]/proc/20611/fd$ls -ltr
total 0
lr-x------ 1 oracle oinstall 64 Feb 20 14:03 9 -> /oracle/db19c/rdbms/mesg/oraus.msb
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 8 -> /oracle/db19c/dbs/lkTESTWCTDB
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 7 -> /oracle/db19c/dbs/hc_testwctdb.dat
lr-x------ 1 oracle oinstall 64 Feb 20 14:03 6 -> /var/lib/sss/mc/passwd
lr-x------ 1 oracle oinstall 64 Feb 20 14:03 5 -> /proc/20611/fd
lr-x------ 1 oracle oinstall 64 Feb 20 14:03 4 -> /oracle/db19c/rdbms/mesg/oraus.msb
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 305 -> /oradata/ftms_zx_test01_data8.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 304 -> /oradata/ftms_zx_test01_data7.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 303 -> /oradata/ftms_zx_test01_data6.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 302 -> '/oradata/ftms_zx_test01_data5.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 301 -> '/oradata/ftms_zx_test01_data4.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 300 -> '/oradata/ftms_zx_test01_data3.dbf (deleted)'
lr-x------ 1 oracle oinstall 64 Feb 20 14:03 3 -> /dev/null
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 299 -> '/oradata/ftms_zx_test01_data2.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 298 -> '/oradata/ftms_zx_test01_data1.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 297 -> '/oradata/ftms_zx_test01_data.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 296 -> /oradata/ftms_zx_test_data.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 295 -> '/oradata/TESTWCTDB/sd.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 294 -> /oradata/TESTWCTDB/ftms_cs3_jiamiceshi
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 293 -> /langchao/dumpdata/FTMS_CS_TDE.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 292 -> /oradata/ftms_zx_test01.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 291 -> /langchao/dumpdata/FTMS_CS_DATA4.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 290 -> '/oradata/ftms_zx_data5.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 289 -> /langchao/dumpdata/FTMS_CS_DATA3.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 288 -> /langchao/dumpdata/FTMS_CS_DATA2.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 287 -> /langchao/dumpdata/FTMS_JD_DATA2.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 286 -> '/oradata/LCBIPECDS _TEMP_DAT.DBF'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 285 -> '/oradata/rTB_MBFE_TEMP (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 284 -> '/oradata/TESTWCTDB/temp01.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 283 -> '/oradata/ftms_credit_data5.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 282 -> /oradata/ftmshtdata.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 281 -> '/oradata/dump_data/FTMS_CSBF_DATA.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 280 -> /langchao/dumpdata/FTMS_NEWBL2_DATA.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 279 -> /langchao/dumpdata/FTMS_CS_DATA.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 278 -> /oradata/LCBIPECDS_DAT.DBF
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 277 -> /oradata/rTB_MBFE
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 276 -> /oradata/udpcount_02.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 275 -> /oradata/udpcount_01.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 274 -> '/oradata/ftms_credit_data_6.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 273 -> /langchao/dumpdata/FTMS_JD_DATA.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 272 -> '/oradata/ftms_old.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 271 -> '/oradata/ftms_credit_data2.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 270 -> /langchao/dumpdata/PJDIP_DATA.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 269 -> '/oradata/ftms_credit_data.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 268 -> /langchao/dumpdata/FTMS_NEWBL_DATA.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 267 -> '/oradata/ftms_zx_data4.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 266 -> /langchao/dumpdata/QIANZHANG_DATA.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 265 -> '/oradata/ftms_zx_data3.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 264 -> '/oradata/ftms_zx_data2.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 263 -> '/oradata/ftms_zx_data.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 262 -> /langchao/dumpdata/FTMSDIP_DATA.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 261 -> /oradata/TESTWCTDB/users01.dbf
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 260 -> '/oradata/TESTWCTDB/undotbs01.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 259 -> '/oradata/TESTWCTDB/sysaux01.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 258 -> '/oradata/TESTWCTDB/system01.dbf (deleted)'
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 257 -> /oradata/TESTWCTDB/control02.ctl
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 256 -> /oradata/TESTWCTDB/control01.ctl
l-wx------ 1 oracle oinstall 64 Feb 20 14:03 2 -> /dev/null
lrwx------ 1 oracle oinstall 64 Feb 20 14:03 10 -> 'socket:[823411]'
l-wx------ 1 oracle oinstall 64 Feb 20 14:03 1 -> /dev/null
lr-x------ 1 oracle oinstall 64 Feb 20 14:03 0 -> /dev/null

查询数据文件大小(被删除的文件文件大小通过v$datafile查询为0)

SQL> select name,bytes/1024/1024/1024 from v$datafile;

NAME                                                                             BYTES/1024/1024/1024
-------------------------------------------------------------------------------- --------------------
/oradata/TESTWCTDB/system01.dbf                                                                     0
/oradata/TESTWCTDB/sysaux01.dbf                                                                     0
/oradata/TESTWCTDB/undotbs01.dbf                                                                    0
/oradata/TESTWCTDB/users01.dbf                                                             .004882813
/langchao/dumpdata/FTMSDIP_DATA.dbf                                                                 3
/oradata/ftms_zx_data.dbf                                                                           0
/oradata/ftms_zx_data2.dbf                                                                          0
/oradata/ftms_zx_data3.dbf                                                                          0
/langchao/dumpdata/QIANZHANG_DATA.dbf                                                               5
/oradata/ftms_zx_data4.dbf                                                                          0
/langchao/dumpdata/FTMS_NEWBL_DATA.dbf                                                             30
/oradata/ftms_credit_data.dbf                                                                       0
/langchao/dumpdata/PJDIP_DATA.dbf                                                                  20
/oradata/ftms_credit_data2.dbf                                                                      0
/oradata/ftms_old.dbf                                                                               0
/langchao/dumpdata/FTMS_JD_DATA.dbf                                                                15
/oradata/ftms_credit_data_6.dbf                                                                     0
/oradata/udpcount_01.dbf                                                                            5
/oradata/udpcount_02.dbf                                                                            5
/oradata/rTB_MBFE                                                                              .03125
/oradata/LCBIPECDS_DAT.DBF                                                                         .5
/langchao/dumpdata/FTMS_CS_DATA.dbf                                                                30
/langchao/dumpdata/FTMS_NEWBL2_DATA.dbf                                                            30
/oradata/dump_data/FTMS_CSBF_DATA.dbf                                                               0
/oradata/ftmshtdata.dbf                                                                    .087890625
/oradata/ftms_credit_data5.dbf                                                                      0
/langchao/dumpdata/FTMS_JD_DATA2.dbf                                                                3
/langchao/dumpdata/FTMS_CS_DATA2.dbf                                                       31.9999847
/langchao/dumpdata/FTMS_CS_DATA3.dbf                                                               10
/oradata/ftms_zx_data5.dbf                                                                          0
/langchao/dumpdata/FTMS_CS_DATA4.dbf                                                        12.109375
/oradata/ftms_zx_test01.dbf                                                                19.0527344
/langchao/dumpdata/FTMS_CS_TDE.dbf                                                                  1
/oradata/TESTWCTDB/ftms_cs3_jiamiceshi                                                     .029296875
/oradata/TESTWCTDB/sd.dbf                                                                           0
/oradata/ftms_zx_test_data.dbf                                                             .009765625
/oradata/ftms_zx_test01_data.dbf                                                                    0
/oradata/ftms_zx_test01_data1.dbf                                                                   0
/oradata/ftms_zx_test01_data2.dbf                                                                   0
/oradata/ftms_zx_test01_data3.dbf                                                                   0
/oradata/ftms_zx_test01_data4.dbf                                                                   0
/oradata/ftms_zx_test01_data5.dbf                                                                   0
/oradata/ftms_zx_test01_data6.dbf                                                          12.5976563
/oradata/ftms_zx_test01_data7.dbf                                                          9.08203125
/oradata/ftms_zx_test01_data8.dbf                                                                6.25

45 rows selected.

把数据文件拷贝回来

cp /proc/20611/fd/302   /langchao/orabak/
cp /proc/20611/fd/301   /langchao/orabak/
cp /proc/20611/fd/300   /langchao/orabak/
cp /proc/20611/fd/299   /langchao/orabak/
cp /proc/20611/fd/298   /langchao/orabak/
cp /proc/20611/fd/297   /langchao/orabak/
cp /proc/20611/fd/295   /langchao/orabak/
cp /proc/20611/fd/290   /langchao/orabak/
cp /proc/20611/fd/285   /langchao/orabak/
cp /proc/20611/fd/284   /langchao/orabak/
cp /proc/20611/fd/283   /langchao/orabak/
cp /proc/20611/fd/281   /langchao/orabak/
cp /proc/20611/fd/274   /langchao/orabak/
cp /proc/20611/fd/272   /langchao/orabak/
cp /proc/20611/fd/271   /langchao/orabak/
cp /proc/20611/fd/269   /langchao/orabak/
cp /proc/20611/fd/267   /langchao/orabak/
cp /proc/20611/fd/265   /langchao/orabak/
cp /proc/20611/fd/264   /langchao/orabak/
cp /proc/20611/fd/263   /langchao/orabak/
cp /proc/20611/fd/260   /langchao/orabak/
cp /proc/20611/fd/259   /langchao/orabak/
cp /proc/20611/fd/258   /langchao/orabak/

由于涉及system表空间数据文件被删除,无法在open情况下直接操作,直接关闭数据库,启动到mount状态,重命名数据文件路径,recover数据文件,open库,恢复完成
参考以前类似恢复:
Solaris rm datafile recovery—利用句柄误删除数据文件恢复
如果数据库已经关闭,需要考虑以下类似恢复方式:
dbca删除库和rm删库恢复
记录一次rm -rf 删除数据文件异常恢复

Oracle 19C 备库DML重定向—DML Redirection

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:Oracle 19C 备库DML重定向—DML Redirection

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

在19c之前,oracle Data Guard备用数据库上不能执行DML操作,但是,从19c开始备库就可以进行DML操作了;Active Data Guard备用数据库上运行DML操作,可以在备用数据库上运行只读应用程序,偶尔执行DML(太频繁影响主库性能),备库上的DML操作可以透明地重定向到主数据库并在主数据库上运行。也包括PL/SQL块中的DML语句。Active Data Guard会话将等待,直到将相应的更改发送到Active Data Guard备用数据库并将其应用于Active Data Guard备用数据库为止。在DML操作期间将保持读取一致性,并且运行DML的备用数据库可以查看其未提交的更改。但是,所有其他备用数据库实例只有在提交事务后才能查看这些更改。
在主库上创建测试表

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
BANNER_FULL
--------------------------------------------------------------------------------
BANNER_LEGACY
--------------------------------------------------------------------------------
    CON_ID
----------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.5.0.0.0
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
	 0


SQL> select database_role ,open_mode from v$database;

DATABASE_ROLE	 OPEN_MODE
---------------- --------------------
PRIMARY 	 READ WRITE

SQL> create table system.t_xff as select * from dba_objects;

Table created.

SQL> select count(*) from system.t_xff;

  COUNT(*)
----------
     72407

在备库上进行dml操作

SQL> select database_role ,open_mode from v$database;

DATABASE_ROLE	 OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY READ ONLY WITH APPLY



SQL> select count(*) from system.t_xff;

  COUNT(*)
----------
     72407

SQL> alter session enable adg_redirect_dml;

Session altered.

SQL> delete from system.t_xff;

72407 rows deleted.

SQL> commit;

Commit complete.

在主库上验证备库dml操作结果

SQL> select count(*) from system.t_xff;

  COUNT(*)
----------
	 0

SQL> 

在18c中可以通过_enable_proxy_adg_redirect隐含参数实现dml重定向

ORA-01595/ORA-600 4194处理

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ORA-01595/ORA-600 4194处理

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

又一个客户由于服务器断电,导致oracle无法正常启动报ORA-600 4194错误

Sat Jan 20 13:45:22 2024
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
 parallel recovery started with 32 processes
Started redo scan
Completed redo scan
 read 31 KB redo, 5 data blocks need recovery
Started redo application at
 Thread 1: logseq 9, block 3
Recovery of Online Redo Log: Thread 1 Group 3 Seq 9 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO03.LOG
Completed redo application of 0.02MB
Completed crash recovery at
 Thread 1: logseq 9, block 66, scn 81924188
 5 data blocks read, 5 data blocks written, 31 redo k-bytes read
Thread 1 advanced to log sequence 10 (thread open)
Thread 1 opened at log sequence 10
  Current log# 1 seq# 10 mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_smon_5164.trc  (incident=384222):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\oracle\diag\rdbms\xff\xff\incident\incdir_384222\xff_smon_5164_i384222.trc
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_ora_6832.trc  (incident=384270):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\oracle\diag\rdbms\xff\xff\incident\incdir_384270\xff_ora_6832_i384270.trc
Doing block recovery for file 3 block 207
Resuming block recovery (PMON) for file 3 block 207
Block recovery from logseq 10, block 64 to scn 81924393
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery stopped at EOT rba 10.66.16
Block recovery completed at rba 10.66.16, scn 0.81924391
Doing block recovery for file 3 block 160
Resuming block recovery (PMON) for file 3 block 160
Block recovery from logseq 10, block 64 to scn 81924389
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery completed at rba 10.64.16, scn 0.81924390
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_smon_5164.trc:
ORA-01595: 释放区 (2) 回退段 (3) 时出错
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Trace dumping is performing id=[cdmp_20240120134525]
Doing block recovery for file 3 block 3857
Resuming block recovery (PMON) for file 3 block 3857
Block recovery from logseq 10, block 64 to scn 81924396
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery stopped at EOT rba 10.66.16
Block recovery completed at rba 10.66.16, scn 0.81924391
Doing block recovery for file 3 block 272
Resuming block recovery (PMON) for file 3 block 272
Block recovery from logseq 10, block 64 to scn 81924390
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery completed at rba 10.66.16, scn 0.81924391
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Sat Jan 20 13:45:26 2024
QMNC started with pid=56, OS id=8052 
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x66F8B134] [PC:0x93C7D88, kgegpa()+38]
Dump file d:\oracle\diag\rdbms\xff\xff\trace\alert_xff.log
Doing block recovery for file 3 block 3857
Resuming block recovery (PMON) for file 3 block 3857
Block recovery from logseq 10, block 64 to scn 81924396
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery completed at rba 10.66.16, scn 0.81924399
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_mmon_7876.trc  (incident=396089):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-06512: 在 "SYS.DBMS_HA_ALERTS_PRVT", line 310
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], 
Doing block recovery for file 3 block 3857
Resuming block recovery (PMON) for file 3 block 3857
Block recovery from logseq 10, block 64 to scn 81924396
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
  Mem# 0: D:\ORACLE\ORADATA\xff\REDO01.LOG
Block recovery completed at rba 10.66.16, scn 0.81924399
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_pmon_8876.trc  (incident=384102):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Sat Jan 20 13:45:39 2024
Errors in file d:\oracle\diag\rdbms\xff\xff\trace\xff_pmon_8876.trc:
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
PMON (ospid: 8876): terminating the instance due to error 472
Instance terminated by PMON, pid = 8876

这个故障比较简单,由于undo回滚异常导致,对异常的undo进行处理,数据库正常open,重建undo表空间导出数据,完成本次恢复工作

从ORA-00283 ORA-16433报错开始恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:从ORA-00283 ORA-16433报错开始恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

接手一个客户无法正常启动的故障数据库,尝试recover 报ORA-00283 ORA-16433错误

[oracle@xff trace]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Sat Jan 27 04:46:23 2024

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


???:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> show pdbs;
SQL> select open_mode from v$database;

OPEN_MODE
--------------------
MOUNTED

SQL>
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-16433: The database must be opened in read/write mode

通过对控制文件进行处理,再次尝试recover库

SQL> recover database;
ORA-00399: corrupt change description in redo log
ORA-00353: log corruption near block 134877 change 3249721295 time 01/27/2024 00:21:05
ORA-00312: online log 1 thread 1:'/u01/app/oracle/oradata/xff/redo01.log'

由于redo和数据文件不匹配,无法正常recover库,尝试强制打开库报ORA-600 2662错误

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [0], [3249721308], [0],[3249730440], [16777344],[],[],[],[],[],[]
ORA-00600: internal error code, arguments: [2662], [0], [3249721307], [0],[3249730440], [16777344],[],[],[],[],[],[]
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [0], [3249721303], [0],[3249730440], [16777344],[],[],[],[],[],[]
Process ID: 117336
Session ID: 1146 Serial number: 11764

基于这种错误,尝试oradebug修改scn

SQL> oradebug setmypid
oradebug DUMPvar SGA kcsgscn_
Statement processed.
SQL> kcslf kcsgscn_ [06001FBB0, 06001FBE0) = 00000000 00000000 00000000 00000000 00000000 
SQL> oradebug poke 0x06001FBB0 4 0x10000000
oradebug DUMPvar SGA kcsgscn_
ORA-32521: error parsing ORADEBUG command:

发现报ORA-32521错误,证明常规的oradebug方法无法修改scn,参考相关文章:
oradebug poke ORA-32521/ORA-32519故障解决
第一次通过其他方法处理,由于计算失误导致数据库启动报ORA-600 2252错误

SQL> ALTER DATABASE OPEN RESETLOGS;
ALTER DATABASE OPEN RESETLOGS
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [2252], [45264], [0], [11641],[3340959744], [],[],[],[],[],[]

该错误是相关文章参考:
记录一次ORA-00600[2252]故障解决
ORA-00600: internal error code, arguments: [2252], [3987]
主机断电系统回到N年前数据库报ORA-600 kcm_headroom_warn_1错误
处理正确的scn值之后,数据库open成功,然后逻辑方式导出数据,恢复工作完成

SQL> alter database open ;

Database altered.

近期又遇到ORA-600 16703和ORA-702故障

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:近期又遇到ORA-600 16703和ORA-702故障

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

比较常见的由于软件注入恶意代码或者被人恶意破坏的常见故障ORA-600 16703和ORA-702故障
ORA-702


上面的故障是由于bootstrap$表被删除导致,以前处理过类似case:
恶意删除bootstrap$导致数据库无法正常启动
恶意删除bootstrap$导致数据库无法正常启动
2019恢复第一单—ORA-704-ORA-702恢复
ORA-00702: bootstrap verison ” inconsistent with version ’8.0.0.0.0′
ORA-600-16703

该故障的原因是一般是由于在互联网上下载了带恶意脚本的oracle安装介质,300天之后数据库重启会导致tab$被删除,参见:
ORA-600 16703故障解析—tab$表被清空
警告:互联网中有oracle介质被注入恶意程序导致—ORA-600 16703
再次提醒oracle使用者:
1. 不要使用从第三方网站下载非官方的数据库访问软件(发生过被注入恶意脚本的plsql dev案例:plsql dev引起的数据库被黑勒索比特币实现原理分析和解决方案
2. 从官方下载oracle 安装程序和补丁程序(防止被注入恶意脚本,参考:警告:互联网中有oracle介质被注入恶意程序导致—ORA-600 16703