ANBOB™

1套Oracle 12.2  4Nodes RAC ON SELS11的本地磁盘使用率告警，DIAG目录在不断的生成redo dump的trace file, db alert log也在不停的显示如下信息:

2020-08-10T21:41:31.425544+08:00
*****************************************************************
An internal routine has requested a dump of selected redo.
This usually happens following a specific internal error, when
analysis of the redo logs will help Oracle Support with the
diagnosis.
It is recommended that you retain all the redo logs generated (by
all the instances) during the past 12 hours, in case additional
redo dumps are required to help with the diagnosis.
*****************************************************************

trace file内容

*** 2020-08-10T21:41:03.876043+08:00
Dumping Short Stack
ksedsts()+346<-kcbgtcr()+28014<-ktrget2()+1056<-kdsgrp()+527<-qetlbr()+835<-qertbFetchByRowID()+1216<-qergiFetch()+567<-qersoProcessULS()+300<-qersoFetchSimple()+1433<-qersoFetch()+210<-opifch2()+3267<-kpoal8()+3490<-opiodr()+1229<-ttcpip()+1257<-opitsk()+1940
<-opiino()+941<-opiodr()+1229<-opidrv()+1021<-sou2o()+145<-opimai_real()+455<-ssthrdmain()+417<-main()+262<-__libc_start_main()+245Dump redo command(s):
 ALTER SYSTEM DUMP REDO DBA MIN 32 2760934 DBA MAX 32 2760934 TIME MIN 1048108263 TIME MAX 1048110123
 

根据MOS

You can ignore the message related to redo log if there is no error along with this information. Please note that for now, there is no way to disable the message by setting any event,  because these informative messages are useful in some cases if something goes wrong. However it is better to retain the redo/archive logs.

If you are seeing redundant dump of redo dump command and redo advisory message in alert.log, then you can apply patch 27028251.

提示如果没有错误可以忽略，为该版本bug， 没有办法通过event禁用输出，可以安装补丁，在19.1修复。 问题就在于你怎么知道有没有问题？

这个案例是前台爆出了ora-8103 坏块，确认应该是与它有关，刚好又是个索引对象，重建索引后以上错误没有再提示。 判断ora-8103对象的方法

1. If ORA-08103 can be reproduced at will get a trace file:

From SQL*Plus execute:

alter session set max_dump_file_size=unlimited;
alter session set db_file_multiblock_read_count=1;
alter session set events 'immediate trace name trace_buffer_on level 1048576';
alter session set events '10200 trace name context forever, level 1';
alter session set events '10236 trace name context forever, level 1';
alter session set events '8103 trace name errorstack level 3';
alter session set tracefile_identifier='ORA8103';
----->>>> run the sql statement that causes the ORA-08103
alter session set events 'immediate trace name trace_buffer_off';
oradebug setmypid
oradebug tracefile_name

Identify the trace with the form of _ora__ORA8103.trc
2. If ORA-08103 is not reproducible at will, enable EVENT errorstack for ORA-08103 and event 10236 at system level, wait for the error to be reproduced and disable the events:

alter system set events '8103 trace name errorstack forever, level 3';
alter system set events '10236 trace name context forever, level 1';

Once the ORA-8103 error is reproduced, disable the events:

alter system set events '8103 trace name errorstack off';
alter system set events '10236 trace name context off';

处理方法
1，如果是索引直接重建
2，表 block 可以bbed 破坏，再使用event或package skip corrupted block，或plsql 利用rowid抽取好块上的数据，或bbed 替换block修改rdba和obj#解决
3, 表 header 使用工具扫文件抽数

The segment header block corrupted cause ORA-08103 issue (段头坏块导致ora-8103)
ora-01499 & ora-08103 caused by block corrupted or write loss a case

打赏

微信扫一扫，打赏作者吧～