备库中ORA-00600错误的简单修复

简介: 最近偶尔会接到一条短信,提示某个备库中出现了ORA-00600的错误。对于这个问题还真不能心存侥幸,自己带着疑问查看了一下, 这是一个一主两备的库,主库和其中的一个备库没有任何的ORA-00600的错误,只有这一个备库中偶尔会出现ORA-00600的错误。
最近偶尔会接到一条短信,提示某个备库中出现了ORA-00600的错误。对于这个问题还真不能心存侥幸,自己带着疑问查看了一下,
这是一个一主两备的库,主库和其中的一个备库没有任何的ORA-00600的错误,只有这一个备库中偶尔会出现ORA-00600的错误。
这个问题如果放大还是很严重的,比如主库出现问题了,如果切换到这个备库,那么ORA-00600的错误就会直接转移过来,这个时候这儿备库就有点鸡肋的味道了。所以这个问题一种思路就是重新搭建备库,另外一种就是手工修复。我还是更希望通过手工修复的方式来先来看看能不能解决掉这个问题。
报错的备库数据库日志如下:
Media Recovery Waiting for thread 1 sequence 654 (in transit)
Recovery of Online Redo Log: Thread 1 Group 7 Seq 654 Reading mem 0
  Mem# 0: /U01/app/oracle/fast_recovery_area/TESTSOB0/onlinelog/o1_mf_7_9lo8zrpc_.log
Mon Sep 21 08:36:02 2015
Archived Log entry 650 added for thread 1 sequence 653 ID 0xfe9af939 dest 1:
Mon Sep 21 12:18:09 2015
Errors in file /U01/app/oracle/diag/rdbms/testb0/testob0/trace/ordermob0_ora_26830.trc  (incident=403849):
ORA-00600: 鍐呴儴閿欒?浠g爜, 鍙傛暟: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /U01/app/oracle/diag/rdbms/testob0/testob0/incident/incdir_403849/testob0_ora_26830_i403849.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Sep 21 12:18:11 2015
Sweep [inc][403849]: completed
Sweep [inc2][403849]: completed
Mon Sep 21 12:18:11 2015
Dumping diagnostic data in directory=[cdmp_20150921121811], requested by (instance=1, osid=26830), summary=[incident=403849].
Mon Sep 21 12:37:06 2015
Errors in file /U01/app/oracle/diag/rdbms/testob0/testob0/trace/testob0_ora_26766.trc  (incident=403918):
ORA-00600: 鍐呴儴閿欒?浠g爜, 鍙傛暟: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /U01/app/oracle/diag/rdbms/testob0/ordermob0/incident/incdir_403918/testob0_ora_26766_i403918.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Mon Sep 21 12:37:08 2015
Sweep [inc][403918]: completed
Sweep [inc2][403918]: completed
Mon Sep 21 12:37:08 2015
Dumping diagnostic data 
而对于日志中提到的trace文件,得到的内容如下:
/U01/app/oracle/diag/rdbms/testob0/testob0/trace/testob0_ora_26766.trc 
*** 2015-09-21 12:37:04.930
*** SESSION ID:(1898.8357) 2015-09-21 12:37:04.930
*** CLIENT ID:() 2015-09-21 12:37:04.930
*** SERVICE NAME:(SYS$USERS) 2015-09-21 12:37:04.930
*** MODULE NAME:(JDBC Thin Client) 2015-09-21 12:37:04.930
*** ACTION NAME:() 2015-09-21 12:37:04.930
 
* kdsgrp1-1: *************************************************
            row 0x01c55b6f.1f continuation at
            0x01c55b6f.1f file# 7 block# 351087 slot 31 not found
KDSTABN_GET: 0 ..... ntab: 1
curSlot: 31 ..... nrows: 32
kdsgrp - dump CR block dba=0x01c55b6f
Block header dump:  0x01c55b6f
 Object id on Block? Y
 seg/obj: 0x12739  csc: 0x00.10bfb352  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x1c55481 ver: 0x01 opc: 0
     inc: 0  exflg: 0
而第一次抛出ORA-00600的错误,可以追溯到2014年了,所以还是一个遗留问题。
这个错误代表的含义是对应的索引ROWID,在数据表中找不到记录,还是有数据不一致的情况。
从trace文件里也可以看到,其实是在运行一条sql语句的时候抛出来的错误。
SELECT  nvl(count(distinct USER_ID),0) as userCount,nvl(SUM(goods_price),0) as total FROM TEST_ORDER WHERE (IS_SANDBOX   = 0 or IS_SANDBOX is null) and  (order_status = 2 or order_status = 4) and UPDATE_DATE >=to_date(:1,'yyyy-mm-dd') and UPDATE_DATE <to_date(:2,'yyyy-mm-dd')+1  and (substr(MEDIA_CHANNEL_ID,0,2)='10' or substr(MEDIA_CHANNEL_ID,0,2)='20')  AND app_id = :3
至于问题怎么定位,trace中的内容值得好好琢磨一下。
* kdsgrp1-1: *************************************************
            row 0x01c55b6f.1f continuation at
            0x01c55b6f.1f file# 7 block# 351087 slot 31 not found
这个就代表错误出现在7号数据文件,351087号数据块上。
可以通过下面的语句来定位错误是否在TEST_ORDER这个表上
SQL> select owner,segment_name,segment_type from dba_extents where file_id=7 and block_id<=351087 and (block_id+blocks)>=351087;
OWNER                SEGMENT_NAME         SEGMENT_TYPE
-------------------- -------------------- ------------------------------------------------------
TESTOB             TEST_ORDER             TABLE
对于这个问题,MOS中已经提供了完整的解决方法。
ORA-600 [kdsgrp1] During Table/Index Full Scans (文档 ID 468883.1)
一种是通过dump出来数据,然后设置对应的事件,重建修复
#1 alter system dump datafile 7 block 351087;            
另外一种是直接声明跳过那些坏块,可以直接使用dbms_repair来修复。
  execute dbms_repair.skip_corrupt_blocks('TESTOB','TEST_ORDER'); 
但是因为问题发生在备库所以还是无法运行这个包的。
SQL>    execute dbms_repair.skip_corrupt_blocks('TESTOB','TEST_ORDER'); 
BEGIN dbms_repair.skip_corrupt_blocks('TESTOB','TEST_ORDER'); END;
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-16000: database open for read-only access
ORA-00604: error occurred at recursive SQL level 1
ORA-16000: database open for read-only access
ORA-06512: at "SYS.DBMS_REPAIR", line 419
ORA-06512: at line 1
所以还是需要在主库来运行,尽管主库中还是没有这个错误的。
SQL>    execute dbms_repair.skip_corrupt_blocks('TESTOB','TEST_ORDER'); 
PL/SQL procedure successfully completed.
执行过程很快,修复后自己也在观察是否还收到过ORA的错误警告,按照目前的情况来看,这个问题应该还是顺利解决了,因为已经过去了快两周,之前每一两天就会抛个错误。
目录
相关文章
|
9天前
|
Linux Shell
Linux系统安装miniconda详细教程
本文介绍在CentOS 7系统中安装Miniconda的完整步骤:首先下载Miniconda安装包至/opt目录,接着执行安装脚本并按提示操作;安装完成后,将conda添加到环境变量,通过`conda init bash`和`source ~/.bashrc`配置生效,最终验证安装成功。
164 5
|
机器学习/深度学习 人工智能 分布式计算
使用PAI+LLaMA Factory 微调 Qwen2-VL 模型,搭建文旅领域知识问答机器人
本次教程介绍了如何使用 PAI ×LLaMA Factory 框架,基于全参方法微调 Qwen2-VL 模型,使其能够进行文旅领域知识问答,同时通过人工测试验证了微调的效果。
使用PAI+LLaMA Factory 微调 Qwen2-VL 模型,搭建文旅领域知识问答机器人
|
负载均衡 Java Nacos
Nacos有几种负载均衡策略?
Nacos有几种负载均衡策略?
1405 0
Nacos有几种负载均衡策略?
|
SQL 关系型数据库 数据库
PostgreSQL性能飙升的秘密:这几个调优技巧让你的数据库查询速度翻倍!
【10月更文挑战第25天】本文介绍了几种有效提升 PostgreSQL 数据库查询效率的方法,包括索引优化、查询优化、配置优化和硬件优化。通过合理设计索引、编写高效 SQL 查询、调整配置参数和选择合适硬件,可以显著提高数据库性能。
2193 2
|
安全 Linux 数据库连接
CentOS 7环境下DM8数据库的安装与配置
【10月更文挑战第16天】本文介绍了在 CentOS 7 环境下安装与配置达梦数据库(DM8)的详细步骤,包括安装前准备、创建安装用户、上传安装文件、解压并运行安装程序、初始化数据库实例、配置环境变量、启动数据库服务、配置数据库连接和参数、备份与恢复、以及安装后的安全设置、性能优化和定期维护等内容。通过这些步骤,可以顺利完成 DM8 的安装与配置。
1317 0
|
Java 数据库连接 Android开发
SSM框架——使用MyBatis Generator自动创建代码
SSM框架——使用MyBatis Generator自动创建代码
156 2
|
机器学习/深度学习 传感器 数据采集
机器学习实战 —— 工业蒸汽量预测(一)
机器学习实战 —— 工业蒸汽量预测(一)
543 1
|
SQL 关系型数据库 MySQL
Flink CDC产品常见问题之读分布式mysql报连接超时如何解决
Flink CDC(Change Data Capture)是一个基于Apache Flink的实时数据变更捕获库,用于实现数据库的实时同步和变更流的处理;在本汇总中,我们组织了关于Flink CDC产品在实践中用户经常提出的问题及其解答,目的是辅助用户更好地理解和应用这一技术,优化实时数据处理流程。
|
监控 Linux
深入了解Linux的pmap命令:进程内存映射的利器
`pmap`是Linux下分析进程内存映射的工具,显示内存区域、权限、大小等信息。通过`/proc/[pid]/maps`获取数据,特点包括详细、实时和灵活。参数如`-x`显示扩展信息,`-d`显示设备。示例:`pmap -x 1234`查看进程1234的映射。注意权限、实时性和准确性。结合其他工具定期监控,排查内存问题。