ORA-600 3600恢复—-resetlogs scn异常

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

标题:ORA-600 3600恢复—-resetlogs scn异常

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

由于客户误操作,在有文件offline的情况下进行resetlogs操作,导致有文件resetlogs scn不对
20220128000040


尝试offline异常文件,均报ORA-600 3600

---直接offline
Wed Jan 26 11:08:15 2022
ALTER DATABASE RECOVER  database until cancel  
Media Recovery Start
 started logmerger process
Wed Jan 26 11:08:17 2022
Datafile 8 (ckpscn 731239901) is orphaned on incarnation#=2
Media Recovery failed with error 19909
Slave exiting with ORA-283 exception
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_pr00_133504.trc:
ORA-00283: recovery session canceled due to errors
ORA-19909: datafile 8 belongs to an orphan incarnation
ORA-01110: data file 8: 'D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\DATABASE\XIFENFEI.DBF'
Recovery Slave PR00 previously exited with exception 283
ORA-283 signalled during: ALTER DATABASE RECOVER  database until cancel  ...
Wed Jan 26 11:08:31 2022
alter database datafile 8 offline
Wed Jan 26 11:08:31 2022
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_dbw0_133948.trc  (incident=134637):
ORA-00600: internal error code, arguments: [3600], [8], [14], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_134637\orcl_dbw0_133948_i134637.trc
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_dbw0_133948.trc:
ORA-00600: internal error code, arguments: [3600], [8], [14], [], [], [], [], [], [], [], [], []
DBW0 (ospid: 133948): terminating the instance due to error 471
Instance terminated by DBW0, pid = 133948

---offline drop
Wed Jan 26 11:09:20 2022
alter database datafile 8 offline drop
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_dbw0_133932.trc  (incident=135837):
ORA-00600: internal error code, arguments: [3600], [8], [14], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_135837\orcl_dbw0_133932_i135837.trc
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_dbw0_133932.trc:
ORA-00600: internal error code, arguments: [3600], [8], [14], [], [], [], [], [], [], [], [], []
DBW0 (ospid: 133932): terminating the instance due to error 471
Wed Jan 26 11:09:22 2022
Instance terminated by DBW0, pid = 133932

因为resetlogs scn不对,也无法正常重建控制文件,对于这样的case,可以Oracle Recovery Tools进行修复resetlogs scn,然后直接open库

Wed Jan 26 11:15:12 2022
SMON: enabling cache recovery
Dictionary check beginning
Archived Log entry 3 added for thread 1 sequence 381 ID 0x60b930a1 dest 1:
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Starting background process QMNC
Wed Jan 26 11:15:15 2022
QMNC started with pid=25, OS id=131784 
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Completed: alter database open

软件下载:OraRecovery下载
使用说明:使用说明

frm和ibd文件数据库恢复

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

标题:frm和ibd文件数据库恢复

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

这次客户rm -rf /var/lib/mysql删除文件,删除一半及时终止,但是已经有很多mysql相关文件被删除,重要的ibdata文件已经被删除,并且客户尝试了大量的恢复工作,对该分区进行了大量的写入操作,导致后面通过对xfs文件系统进行分析,确认无法恢复对应的ibdata文件.比较幸运客户需要的核心的mysql库都还在(frm和ibd文件还存在)
20211224105004


对于这种情况,可以参考以前类似的处理方法:[MySQL异常恢复]mysql ibd文件恢复
由于客户无法提供创建表语句需要通过对frm进行解析获取语句,利用mysqlfrm获取表创建语句

E:\3>mysqlfrm --server=root:oracle@192.168.222.79:3306 --diagnostic T_XIFENFEI.frm
WARNING: Using a password on the command line interface can be insecure.
# Source on 192.168.222.79: ... connected.
# CAUTION: The diagnostic mode is a best-effort parse of the .frm file. As such, it may not identify all of 
  the components of the table correctly. This is especially true for damaged files. 
  It will also not read the default values for the columns and the resulting statement may not be syntactically correct.
# Reading .frm file for EVALUATOR_T.frm:
# The .frm file is a TABLE.
# CREATE TABLE Statement:

CREATE TABLE `T_XIFENFEI` (
  `ID` varchar(32) COLLATE `utf8_general_ci` DEFAULT NULL comment '主键',
  `BO_TYPE_DEFINE_ID` varchar(32) COLLATE `utf8_general_ci` DEFAULT NULL comment '业务对象类型ID',
  `MAIN_ID` varchar(32) COLLATE `utf8_general_ci` DEFAULT NULL comment '业务对象主表记录ID',
  `PARENT_ID` varchar(32) COLLATE `utf8_general_ci` DEFAULT NULL comment '父ID',
  `ROW_NUM` decimal(32,0) DEFAULT NULL comment '行号',
  `VERSION` decimal(32,6) DEFAULT NULL comment '版本',
  `CREATE_DATE` datetime DEFAULT NULL comment '创建时间',
  `UPDATE_DATE` datetime DEFAULT NULL comment '更新时间',
  `BO_SOURCE_ROW_ID` varchar(32) COLLATE `utf8_general_ci` DEFAULT NULL comment '来源明细行ID',
  `EVALUATORS` text COLLATE `utf8_general_ci` DEFAULT NULL,
  `IMPORTANCE` decimal(32,6) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8, COMMENT '评分人';
#...done.

对于有些获取语句失败,比如类似这样错误

E:\TEMP\10000246_1108\db\ync2_fssc_2000003>mysqlfrm --server=root:oracle@192.168.222.79:3306 --diagnostic T_XFF.frm
Traceback (most recent call last):
  File "G:\ade\build\Python-2.7.6-windows-x86-64bit\lib\site-packages\cx_Freeze\initscripts\Console.py",
    line 27, in <module>
  File "scripts\mysqlfrm.py", line 419, in <module>
  File ".\mysql\utilities\command\read_frm.py", line 396, in read_frm_files_diagnostic
  File ".\mysql\utilities\common\frm_reader.py", line 1538, in show_create_table_statement
  File ".\mysql\utilities\common\frm_reader.py", line 1385, in _build_create_statement
  File ".\mysql\utilities\common\frm_reader.py", line 1273, in _get_key_columns
IndexError: list index out of range

使用专门的工具对其进行解析
20211224105004


然后利用这些创建表语句在库中创建表,并利用以下方法进行操作

mysql> alter table  `t_xifenfei` discard tablespace;        
Query OK, 0 rows affected (0.00 sec)

--上传老的t_xifenfei.ibd文件,并修改所有者和属组

mysql> alter table  `t_xifenfei` import tablespace;                
Query OK, 0 rows affected, 2 warnings (0.01 sec)

mysql> select count(1) from   `t_xifenfei` ;              
+----------+
| count(1) |
+----------+
|       78 |
+----------+
1 row in set (0.00 sec)

使用类似的方法对于数据进行批量处理,然后使用mysqldump进行导出.在这个ibd的discard和import的过程中,有些异常情况这三种错误的处理

mysql> alter table T_LOG_XIFENFEI                   import tablespace;
ERROR 1808 (HY000): Schema mismatch (Table has ROW_TYPE_DYNAMIC row format, .ibd file has ROW_TYPE_COMPACT row format.)
mysql> alter table     `T_LOG_XIFENFEI` import tablespace;
ERROR 1817 (HY000): Index corrupt: Externally stored column(4) has a reference length of 4 in the cluster index PRIMARY
mysql> alter table       `T_LOG_XIFENFEI` import tablespace;
ERROR 1815 (HY000): Internal error: Cannot reset LSNs in table `XFF`.`T_LOG_XIFENFEI` : Data structure corruption

Schema mismatch (Table has ROW_TYPE_DYNAMIC row format, .ibd file has ROW_TYPE_COMPACT row format.) 这种错误是由于row_format设置不正确导致,重新创建表使用正确的row_format然后执行discard和import操作.
Index corrupt: Externally stored column(4) has a reference length of 4 in the cluster index PRIMARY 这种错误是由于表的创建语句和ibd中记录数据不匹配,主要是由于创建表语句不完全正确导致,重新获取正确语句进行恢复
Internal error: Cannot reset LSNs in table `XFF`.`T_LOG_XIFENFEI` : Data structure corruption 这种错误是由于ibd文件本身不一致无法使用该方法恢复,对于这类情况使用我们专业的工具进行处理
20211224142855


重现sql执行计划SYS_OP_C2C隐式转换

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

标题:重现sql执行计划SYS_OP_C2C隐式转换

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

在一次的sql优化中,遇到SYS_OP_C2C函数,通过分析是由于一个表的varchar2和另外一个表的nvarchar2列进行关联导致,通过以下简单使用进行重现.对于这个问题,如果需要使用index,需要创建SYS_OP_C2C的函数index,或者把列类型修改一致.

SQL> create user xff identified by oracle;

用户已创建。

SQL> grant dba to xff;

授权成功。

SQL> create table xff.t1(id number,name varchar2(100));

表已创建。

SQL> insert into xff.t1 select  object_id,object_name from dba_objects;

已创建 89932 行。

SQL> commit;

提交完成。

SQL> create table xff.t2(id number,name nvarchar2(100));

表已创建。

SQL> insert into xff.t2 select  object_id,object_name from dba_objects;

已创建 89933 行。

SQL> commit;

提交完成。


SQL> exec dbms_stats.gather_table_stats('XFF','T1',cascade=>true);

PL/SQL 过程已成功完成。

SQL> exec dbms_stats.gather_table_stats('XFF','T2',cascade=>true);

PL/SQL 过程已成功完成。


SQL> set autot on
SQL>  select count(1) from xff.t1, xff.t2 where t1.name=t2.name;

  COUNT(1)
----------
    160752


执行计划
----------------------------------------------------------
Plan hash value: 906334482

------------------------------------------------------------------------------------
| Id  | Operation           | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |      |     1 |    74 |       |   760   (1)| 00:00:10 |
|   1 |  SORT AGGREGATE     |      |     1 |    74 |       |            |          |
|*  2 |   HASH JOIN         |      |   146K|    10M|  3256K|   760   (1)| 00:00:10 |
|   3 |    TABLE ACCESS FULL| T1   | 89932 |  2195K|       |   137   (1)| 00:00:02 |
|   4 |    TABLE ACCESS FULL| T2   | 89933 |  4303K|       |   205   (1)| 00:00:03 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("T2"."NAME"=SYS_OP_C2C("T1"."NAME"))

还有一种情况也可能发生该转换,比如使用dblink的访问远程库,本地库和远程库字符集不一致.参考:SQL Statements Performed Across Database Links run Slowly. Explain Plan Shows Function SYS_OP_C2C has been Applied to Predicates, and Query uses a Full Table Scan. (Doc ID 2010872.1)

drop tablesapce 数据恢复

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

标题:drop tablesapce 数据恢复

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

有客户执行了drop tablespace xxx including contents and datafiles,虽然删除命令返回错误,但是该表空间中大量对象被删除,文件没有被从系统层面删除

Tue Jun 29 14:38:26 2021
DROP TABLESPACE "XFF" INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS
Tue Jun 29 14:38:32 2021
Thread 1 advanced to log sequence 975 (LGWR switch)
  Current log# 3 seq# 975 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\XFF\REDO03.LOG
ORA-604 signalled during: DROP TABLESPACE "XFF" INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS...
Tue Jun 29 14:40:44 2021
ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF'  AUTOEXTEND ON NEXT 50M
Completed: ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF'  AUTOEXTEND ON NEXT 50M
ALTER TABLESPACE "XFF" DROP DATAFILE  'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF'
WARNING: Cannot delete file D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF
Errors in file d:\app\administrator\diag\rdbms\XFF\XFF\trace\XFF_ora_2528.trc:
ORA-01265: 无法删除 DATA D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF
ORA-27056: 无法删除文件
OSD-04024: 无法删除文件。
O/S-Error: (OS 32) 另一个程序正在使用此文件,进程无法访问。
Completed: ALTER TABLESPACE "XFF" DROP DATAFILE  'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF'
Tue Jun 29 14:58:51 2021
ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF'  AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED
Completed: ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF'  AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED

通过工具获取obj$字典信息,结合user$,判断业务用户表数据基本上全部删除
20210701193502


对于这类情况,常规方法无法恢复,只能按照表被drop的思路进行恢复.参考文章:dul恢复drop表测试,通过结合客户提供的表结构和一些特殊方法恢复出来所有对象的obj#,dataobj#信息,快速的恢复了客户数据,得到客户认可
20210701194153

/u01空间100%导致数据库报ORA-01114 ORA-29701

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

标题:/u01空间100%导致数据库报ORA-01114 ORA-29701

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

数据库操作报ORA-01114 ORA-29701错误
ORA-01114 ORA-29704


通过分析发现磁盘/u01分区使用100%
20210629191917

sqlplus / as sysdba 无法登陆
20210629191935

清理trace,释放/u01空间之后,数据库恢复正常,mos中关于ORA-01114错误描述

APPLIES TO:
BI Publisher (formerly XML Publisher) - Version 11.1.1.7.x and later
Information in this document applies to any platform.

SYMPTOMS
 While generating reports the following error occurred.

oracle.xdo.XDOException: java.sql.SQLException: ORA-01114: IO error writing block to file (block # ) 
ORA-01114: IO error writing block to file 201 (block # 755561) 
ORA-27072: File I/O error Additional information: 4 
Additional information: 755561 Additional information: 36864

CHANGES
 

CAUSE
 The issue is caused due to DB not having enough space.

SOLUTION
Cleared space in DB and the report worked fine.

文件系统重新分区oracle恢复

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

标题:文件系统重新分区oracle恢复

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

最近处理的一个恢复,算是这几年中的一个奇葩.
1. oracle dg 主备库raid同时损坏,找硬件恢复厂商软件重组raid,恢复厂商判断所有磁盘全部都是好的
2. 主库系统被重装,文件系统重新分区.备库在使用duplicate搭建dg的过程中(通过alert日志分析以前的dg是正常的,直接rm掉了所有文件,然后使用duplicate搭建),只是部分文件拷贝到了备库
3. 备份放在一台单独的存储上,但是当上去看是发现存储上面空空的,没有任何数据(通过对ctl的分析,确认存储上面只有一个月之前的备份记录,估计也被删除或者重新分区了(通过后续分析,判断应该是被重新分区了)
客户没有和我们说任何信息,就是说突然两个raid都损坏了,找硬件厂商进行恢复,硬件厂商开始也觉得这个会比较简单,直接通过raid模拟恢复出来lun,然后通过软件恢复出来一些数据文件(反馈给我的信息是少了redo,需要我们协助恢复),通过深入分析,发现少了大量数据文件,基于现在的恢复基本上没意义.然后通过低主库的raid模拟恢复,拷贝出来数据文件,结果发现恢复出来的文件大小,和文件头记录不匹配
20210607232818


这里显示文件大小应该是30G,但是实际拷贝的文件只有26G大小
20210607232731

通过底层进一步分析,发现任何大于4G的文件,按照4G为单位间隔损坏(4G好,4G损坏,4G好……)
20210605203719
20210605201235

出现这类情况,通过底层分析,判断是客户对磁盘进行了重新分区,引起底层问题导致
20210607214629

基于这样的情况,没有太多好的方法处理,直接使用底层碎片技术进行恢复
20210607233847

运气不错,顺利open数据库
20210607234450

本次恢复走了很多弯路,主要是客户不清楚客户那边处于什么原因,多次隐秘故障原因,没有如实的告知我们故障情况,一步步尝试,走了很多弯路,耽误了不少时间.如果可能请尽量告诉我们准确情况,便于我们准确做出判断,快速高效的恢复.
类似oracle 碎片层面恢复,我们进行了挺多的,类似:
dbca删除库和rm删库恢复
文件系统损坏导致数据文件异常恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
alter database create datafile 导致数据文件丢失恢复
rm -rf 删除数据文件恢复方法—文件系统反删除+oracle碎片重组

提供19.11(含202104patch)完整版db和grid下载

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

标题:提供19.11(含202104patch)完整版db和grid下载

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

最近实施了一套19c rac并且打上patch 32545008(GI Update 202104)和32399816(OJVM Update 202104),通过createGoldImage 创建了安装程序,直接使用该zip包即可安装含gi/db(含ojvm) 2021年4月的patch

[oracle@dzbl1 ~]$ $ORACLE_HOME/runInstaller -createGoldImage -silent -destinationLocation /tmp/soft_img
Launching Oracle Database Setup Wizard...

Successfully Setup Software.
Gold Image location: /tmp/soft_img/db_home_2021-05-20_09-05-40PM.zip


[oracle@dzbl1 ~]$ exit
logout
[root@dzbl1 ~]# su - grid
Last login: Thu May 20 20:57:05 CST 2021
[grid@dzbl1 ~]$ ./gridSetup.sh -createGoldImage  -silent -destinationLocation /tmp/soft_img
-bash: ./gridSetup.sh: No such file or directory
[grid@dzbl1 ~]$ $ORACLE_HOME/gridSetup.sh -createGoldImage  -silent -destinationLocation /tmp/soft_img
Launching Oracle Grid Infrastructure Setup Wizard...

Successfully Setup Software.
Gold Image location: /tmp/soft_img/grid_home_2021-05-20_09-13-58PM.zip


[grid@dzbl1 ~]$ md5sum  /tmp/soft_img/grid_home_2021-05-20_09-13-58PM.zip
7cefb1be8ead8250435d5a95785d1239  /tmp/soft_img/grid_home_2021-05-20_09-13-58PM.zip
[grid@dzbl1 ~]$ md5sum /tmp/soft_img/db_home_2021-05-20_09-05-40PM.zip
325841792c44f168c524b440440773b0  /tmp/soft_img/db_home_2021-05-20_09-05-40PM.zip
[grid@dzbl1 ~]$ opatch lspatches
32585572;DBWLM RELEASE UPDATE 19.0.0.0.0 (32585572)
32584670;TOMCAT RELEASE UPDATE 19.0.0.0.0 (32584670)
32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)
32576499;ACFS RELEASE UPDATE 19.11.0.0.0 (32576499)
32545013;Database Release Update : 19.11.0.0.210420 (32545013)

OPatch succeeded.
[grid@dzbl1 ~]$ su - oracle
Password: 
Last login: Thu May 20 21:04:33 CST 2021 on pts/1
[oracle@dzbl1 ~]$ opatch lspatches
32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)
32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)
32545013;Database Release Update : 19.11.0.0.210420 (32545013)

OPatch succeeded.
[oracle@dzbl1 ~]$ ls -l /tmp/soft_img/
total 9225956
-rw-r--r-- 1 oracle oinstall 4268265132 May 20 21:13 db_home_2021-05-20_09-05-40PM.zip
-rw-r--r-- 1 grid   oinstall 5179109549 May 20 21:21 grid_home_2021-05-20_09-13-58PM.zip
[oracle@dzbl1 ~]$ 

20210520212657


下载到win,并且按照oracle官方命名方式进程重命名,并且md5验证,确定文件完整性
20210520234704

C:\Users\XFF>CertUtil -hashfile E:\vm_shared\LINUX.X64_1911000_grid_home.zip md5
MD5 的 E:\vm_shared\LINUX.X64_1911000_grid_home.zip 哈希:
7cefb1be8ead8250435d5a95785d1239
CertUtil: -hashfile 命令成功完成。

C:\Users\XFF>CertUtil -hashfile E:\vm_shared\LINUX.X64_1911000_db_home.zip md5
MD5 的 E:\vm_shared\LINUX.X64_1911000_db_home.zip 哈希:
325841792c44f168c524b440440773b0
CertUtil: -hashfile 命令成功完成。

提供下载link,可以直接下载19.11完整版db和grid(该版本含2021年4月份patch):Oracle 19.11 database和grid软件下载,提取码为:bamf.下载之后请验证md5,确认没有别其他人修改.

sqlplus 报 Segmentation Fault故障分析

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

标题:sqlplus 报 Segmentation Fault故障分析

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

有客户反馈sqlplus 登录报错 Segmentation Fault
20210510190752


通过strace跟踪报错信息
20210510190943

上述显示和正常环境sqlplus一样,对应的lib信息一致
20210510191202

通过查询信息发现客户自行对glibc进行了升级
20210510190449
20210510191512

在mos上找到匹配文章说明,升级了glibc之后,sqlplus 报Segmentation Fault说明:Segmentation Fault when Running Sqlplus (Doc ID 2702934.1),在此提醒客户,运行oracle的数据库,升级glibc请谨慎

ora-600 2662和ora-600 kclchkblk_4恢复

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

标题:ora-600 2662和ora-600 kclchkblk_4恢复

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

这两天连续处理两个case,一个是12.1.0.2版本数据库屏蔽一致性,强制open之后,报ORA-600 2662故障
20210429220218


这个错误本身是一个非常常见的错误,直接推scn即可解决,但是问题是12.1.0.2版本,oracle不允许以前常规的操作方法,就连oradebug都报错oradebug poke ORA-32521/ORA-32519故障解决,而且可以是rac环境,bbed修改文件头也相当麻烦,最后我们使用patch方法轻松解决

另外一例是11.2.0.4版本,强制open库报ora-600 kclchkblk_4

Wed Apr 28 21:25:38 2021
SMON: enabling cache recovery
Instance recovery: looking for dead threads
Instance recovery: lock domain invalid but no dead threads
Errors in file /u01/app/oracle/diag/rdbms/dc/dc1/trace/dc1_ora_27832.trc  (incident=564430):
ORA-00600: internal error code, arguments: [kclchkblk_4], [2959], [904341694], [2959], [904131717], []
Incident details in: /u01/app/oracle/diag/rdbms/dc/dc1/incident/incdir_564430/dc1_ora_27832_i564430.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/app/oracle/diag/rdbms/dc/dc1/trace/dc1_ora_27832.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [kclchkblk_4], [2959], [904341694], [2959], [904131717], []
Errors in file /u01/app/oracle/diag/rdbms/dc/dc1/trace/dc1_ora_27832.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [kclchkblk_4], [2959], [904341694], [2959], [904131717], []
Error 704 happened during db open, shutting down database
USER (ospid: 27832): terminating the instance due to error 704
Instance terminated by USER, pid = 27832
ORA-1092 signalled during: alter database open resetlogs...

这个比较简单,参考redo异常 ORA-600 kclchkblk_4 故障恢复.

ORA-600 kcratr_scan_lastbwr 恢复

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

标题:ORA-600 kcratr_scan_lastbwr 恢复

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

有朋友找到我们,系统断电之后,数据库无法正常启动,报ora-600 kcratr_scan_lastbwr错误

Thu Mar 25 20:33:45 2021
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: alter database mount exclusive
alter database open
Ping without log force is disabled
.
Thu Mar 25 20:33:47 2021
Beginning crash recovery of 1 threads
 parallel recovery started with 32 processes
Thu Mar 25 20:33:47 2021
Started redo scan
Hex dump of (file 10, block 176517) in trace file C:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_4176.trc

Reading datafile 'C:\APP\ADMINISTRATOR\ORADATA\ORCL\XFF.DBF' for corruption at rdba: 0x0282b185 (file 10, block 176517)
Reread (file 10, block 176517) found same corrupt data (logically corrupt)
Write verification failed for File 10 Block 176517 (rdba 0x282b185)
Errors in file C:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_4176.trc  (incident=165355):
ORA-00600: ??????, ??: [kcratr_scan_lastbwr], [], [], [], [], [], [], [], [], [], [], []
Incident details in: C:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\incident\incdir_165355\orcl_ora_4176_i165355.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Thu Mar 25 20:33:50 2021
Slave encountered ORA-10388 exception during crash recovery
Thu Mar 25 20:33:50 2021
Slave encountered ORA-10388 exception during crash recovery
Thu Mar 25 20:33:50 2021
Aborting crash recovery due to error 600
Thu Mar 25 20:33:59 2021
Errors in file C:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_4176.trc:
ORA-00600: ??????, ??: [kcratr_scan_lastbwr], [], [], [], [], [], [], [], [], [], [], []
Thu Mar 25 20:33:59 2021
Errors in file C:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_4176.trc:
ORA-00600: ??????, ??: [kcratr_scan_lastbwr], [], [], [], [], [], [], [], [], [], [], []
ORA-600 signalled during: alter database open...

故障原因,写丢失导致

Crash or instance recovery may fail because of a lost write even
though one of the mirrors has a good copy.  Reading a file header 
can corrupt a good mirror copy with a bad one.
 
Rediscovery Notes:
 ORA-600 [kcratr_scan_lostwrt] or ORA-600 [kcratr_scan_lastbwr] are signaled 
 even though one of the mirrors has a good copy.

解决方案比较简单直接recover顺利open库
20210326113024