Terminating the instance due to error 474

Instance Terminated With Error ORA-00474: SMON Process Terminated With Error (Doc ID 1361872.1)

Last updated on FEBRUARY 14, 2022

Applies to:

Oracle Database — Enterprise Edition — Version 11.1.0.6 to 11.2.0.4 [Release 11.1 to 11.2]
Oracle Database — Enterprise Edition — Version 11.1.0.7 and later
Oracle Database Cloud Schema Service — Version N/A and later
Oracle Database Exadata Cloud Machine — Version N/A and later
Oracle Cloud Infrastructure — Database Service — Version N/A and later
Information in this document applies to any platform.

Symptoms

The instance is terminated with error:

The alert log contains the following messages:

/diag/rdbms/ / /trace/ _smon_

.trc (incident= ):
ORA-00600: internal error code, arguments: [13011], [351384], [146850571], [7], [146850571], [4], [], [], [], [], [], []
Incident details in:В /

/diag/rdbms/ / /incident/incdir_ / _smon_

_i .trc
Mon Sep 19 15:45:46 2011
Errors in file /

/diag/rdbms/ / /trace/ _pmon_

.trc
ORA-00474: SMON process terminated with error
PMON (ospid:

): terminating the instance due to error 474
Instance terminated by PMON, pid =

The call stack is

To view full details, sign in with your My Oracle Support account.

Don’t have a My Oracle Support account? Click to get started!

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.

Oracle offers a comprehensive and fully integrated stack of cloud applications and platform services. For more information about Oracle (NYSE:ORCL), visit oracle.com. пїЅ Oracle | Contact and Chat | Support | Communities | Connect with us | | | | Legal Notices | Terms of Use

Источник

What differences if we kill SMON or we kill PMON Back ground processes ??

i am little bit confused.Please help me out.

If we kill PMON—->Instance crashed—->Alert log content
LGWR (ospid: 9764960): terminating the instance due to error 472
Instance terminated by LGWR, pid = 9764960

If we kill SMON—->Instance crashed—->Alert log content
PMON (ospid: 13041666): terminating the instance due to error 474
Instance terminated by PMON, pid = 13041666
2010-12-27 07:31:04.187000 +01:00

Then ,what is the difference in mechnism in killing either to SMON or PMON.

Answers

i am little bit confused.Please help me out.

If we kill PMON—->Instance crashed—->Alert log content
LGWR (ospid: 9764960): terminating the instance due to error 472
Instance terminated by LGWR, pid = 9764960

If we kill SMON—->Instance crashed—->Alert log content
PMON (ospid: 13041666): terminating the instance due to error 474
Instance terminated by PMON, pid = 13041666
2010-12-27 07:31:04.187000 +01:00

Then ,what is the difference in mechnism in killing either to SMON or PMON.

No difference , you kill any mandatory background process, you would have successfully messed up your instance.

There are five mandatory processes for oracle instance to working properly. Killing any one of the process will caused instance crash.

SMON, PMON, CKPT, DBWR, LGWR are the mandatory processes. If you kill any of them then the instance will be crashed.

Regards
Asif Kabir

Why you are killing those process? Those are process which make your db is avalible. To killing those process mean you mess your system. If you want to close your db and use formal close procedure

in production, sure, it is required to use only clean methods, but in testing env it is very useful command (kill -9) 😉
e.g. when shutdown hangs for some reasons.

Oh..wait. I just asked this question due to curiosity about what happen INTERNALLY when we kill any BG process(specially mandatory).

For testing..I kill all the process in each attempt and found some similar and some different lines in alert log.

LGWR (ospid: 9764960): terminating the instance due to error 472
Instance terminated by LGWR, pid = 9764960

PMON (ospid: 6553606): terminating the instance due to error 469
2010-12-27 12:08:51.650000 +01:00
Instance terminated by PMON, pid = 6553606

PMON (ospid: 13041666): terminating the instance due to error 474
Instance terminated by PMON, pid = 13041666

Now,is any knowledge about these error nos(472/469/474) .
What happen internally when we kill PMON or SMON ??

Check below please:
OERR: ORA 474 SMON process terminated with error [ID 18453.1]
OERR: ORA 472 PMON process terminated with error [ID 18451.1]

What are you trying to accomplish? From what I understand, killing any Oracle server process will require database recovery. The same goes for a shutdown abort

SMON performs instance recovery and cleans up after dirty shutdowns. PMON checks dispatchers and server processes and restarts them if they have failed. I’m not sure if it matters, but if I was forced to shoot down an oracle instance, I’d probably aim at PMON first and let SMON terminate the instance.

@PAL. I have one simple question. if u want to kill instance..what should u prefer and most important what i want to know WHY??

ps -eaf|grep pmon
kill -9

or
ps -eaf|grep smon
kill -9

Don’t think about recovery or anything else.Just simple question with what mechnism involved to proceed ??

Please note that there is no mechanism in it. You pull the power chord of your machine or the power goes out from the transformer , it’s the same things. There is no difference in the instance being killed whether you kill LGWR or PMON or SMON. If you are so keen to know the difference , thinking about it all what comes to mind is that if you would kill the P(rocess) MON. there is no other process available to re-spawn it so that’s the guaranteed way to kill the instance. OIther than that,there is no difference at all and don’t think that there is any deep internals involved in it.

Источник

10.1.0.4 bug workaround

What error you have in alert.log ?

Do you mean currently there’s no temp file in your temporary tablespace? How’s that happened?
Maybe you should drop the temp tablespace and recreate one after restart.
Since there’s no valuable information there anyway.

PMON is shutting down the instance due to SMON terminating. In the SMON trace file, is there any indication that the SMON is terminating due to an empty temp tablespace?

ORA-00474
ORA-00474: SMON process terminated with error
Cause: The system cleanup process died
Action: Warm start instance

SQL*Plus: Release 10.1.0.4.0 — Production on Wed Jan 3 16:22:06 2007

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

Connected to an idle instance.

SQL> startup mount exclusive
ORACLE instance started.

Total System Global Area 838860800 bytes
Fixed Size 1324688 bytes
Variable Size 216168816 bytes
Database Buffers 620756992 bytes
Redo Buffers 610304 bytes
Database mounted.
SQL> alter database open;
alter tablespace temp add tempfile ‘/ora1/i014/temp01.dbf’ size 1g reuse autoextend on next 1m;
alter database open
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel

And in alert log:
————————————————————————————
Wed Jan 3 16:22:41 2007
Successfully onlined Undo Tablespace 1.
Wed Jan 3 16:22:41 2007
SMON: enabling tx recovery
Wed Jan 3 16:22:41 2007
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
This condition can occur when a backup controlfile has
been restored. It may be necessary to add files to these
tablespaces. That can be done using the SQL statement:

ALTER TABLESPACE ADD TEMPFILE

Alternatively, if these temporary tablespaces are no longer
needed, then they can be dropped.
Empty temporary tablespace: TEMP
*********************************************************************
Database Characterset is WE8ISO8859P1
Wed Jan 3 16:22:41 2007
Errors in file /oracle/admin/i014/bdump/i014_smon_23426.trc:
ORA-07445: exception encountered: core dump [ksqdeli()+194] [SIGSEGV] [Address not mapped to object] [0x000000068] [] []
ORA-25153: Temporary Tablespace is Empty
Wed Jan 3 16:22:42 2007
Starting background process QMNC
QMNC started with pid=17, OS > Wed Jan 3 16:22:43 2007
replication_dependency_tracking turned off (no async multimaster replication found)
Wed Jan 3 16:22:44 2007
Errors in file /oracle/admin/i014/bdump/i014_pmon_23416.trc:
ORA-00474: SMON process terminated with error
Wed Jan 3 16:22:44 2007
PMON: terminating instance due to error 474
Instance terminated by PMON, pid = 23416
—————————————————————————————————

My clone process is fine. I did online clone so resetlogs must be used. Once recovery performed, temp infomation is gone.

Let me repeat again, it’s a bug and needs a work around, to adding temp file before instance crash.

Источник

Prashant Atri Blog

Together we learn better

L E A R N
Listen to each other
Encourage to each other
Ask questions
Respect each other
No interrupting

Recent Posts

Categories

Blog Stats

Top Posts & Pages

Archives

Subscribe to Blog via Email

Top Clicks

Pages

Posts Tagged ‘ORA-00474’

ORA-600 ktbair1, Integrity Check of the Tables and their indexes, ANALYZE TABLE/Indexes … VALIDATE STRUCTURE

Recently I have got the chance to work on one of issue where production database was continuously getting terminated with below errors,

ORA-04031: unable to allocate 20504 bytes of shared memory (“shared pool”,”unknown object”,”sga heap(1,1)”,”KTI SGA freea”)
PMON (ospid: 13838): terminating the instance due to error 474
ORA-00600: internal error code, arguments: [ktbair1], [0], [1], [], [], [], [], [], [], [], [], []

Based on very initial investigation of alert log and traces, found that database was experiencing ORA-4031 shared pool error since long time and suddenly it got ORA-600 with instance crashed.

So, to prevent from getting it crashed, initially I increased SGA components and but it did not resolve the issue.

Then, it became more interesting.

I have again checked alert log and respective traces more in detail and found that whenever instance is crashing, it is generating below messages,

PMON (ospid: 13838): terminating the instance due to error 474
ORA-00600: internal error code, arguments: [ktbair1], [0], [1], [], [], [], [], [], [], [], [], []

So, immediately I have checked few articles in MOS – with search string as “PMON terminating the instance due to error 474 ORA-00600 ktbair1”, where i have combined these error messages so that we can get exactly matching case and I have found below,

Instance Terminated With Error ORA-00474: SMON Process Terminated With Error (Doc ID 1361872.1)

But this document indicated that there might be some index related corruption and in note it was related to SMON – SCN Table, but here we have got something different.

After getting this tips, I have started finding object where it might have some corruption, and finally from alert log I’ve got Object id based on that I could find the exact object name

Alert log contents
====================
Error 600 encountered while recovering transaction (11, 29) on object 11080
so that you can run this and get the object,

select owner, status, object_name, object_type from dba_objects where object_id=11080; ==> Here I have found the exact table name

Since I was reading this Note and based on traces i thought it might be index corruption, so found which index created on this table and tried to validate it but reported ORA-600 error, then I tried to rebuild online but again same issue, then tried to drop / recreate, it has been dropped successfully but I was not able to recreate the index because of again ORA-600 issue.

alter index XXX.XXXXXX rebuild online;
alter index XXX.XXXXXX rebuild online
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [ktbair1], [0], [1], [], [], [], [], [], [], [], [], []

And then I thought to run validate structure against the table itself the way recommended in metalink note, and it gave same ORA-600 error which really proved that something is wrong with the table.

db> analyze table XXX.XXXX VALIDATE STRUCTURE;
analyze table XXX.XXXX VALIDATE STRUCTURE
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [ktbair1], [0], [1], [], [], [], [],
[], [], [], [], []

Then I’ve tried various options at table level like below,

++ Create backup table using CTAS – gave ora-600
++ Run exp backup for that table – gave ora-600
++ Select count(1) from that table – gave ora-600
++ Alter table move to different tablespace

Above all options got failed, and finally I’ve tried truncating that table which has resolved the issue. Index also has been created successfully after that.

Major learning from this article listed below,

++ How better we should search in MOS – you should always search with supported error messages.
++ Part of regular database health check, we should also include validate structure script for all important tables/indexes and have notification in place for the
same. So if you want more details around SQL script for validate, please see below note,

SCRIPT: Database Wide ANALYZE TABLE … VALIDATE STRUCTURE CASCADE Integrity Check of the Block Structures of all Tables and their indexes. (Doc ID 1605548.1)

As everyone is aware that during upgrade to 11gR2 using manual checklist, we also do below step part of upgrade, but i think we should customize this logic and design the same for application critical tables and indexes.

This optional check is introduced to spot any logical corruption in underlying objects and their dependencies.
This proactive check is introduced to avoid any failure in database upgrade at a later stage due to such corruption. If there is corruption the upgrade will most
likely fail.

To check for corruption in the dictionary, use the following commands in SQL*Plus (connected as sys):

Set verify off
Set space 0
Set line 120
Set heading off
Set feedback off
Set pages 1000
Spool analyze.sql

SELECT ‘Analyze cluster “‘||cluster_name||’” validate structure cascade ;’
FROM dba_clusters
WHERE owner=’SYS’
UNION
SELECT ‘Analyze table “‘||table_name||’” validate structure cascade ;’
FROM dba_tables
WHERE owner=’SYS’
AND partitioned=’NO’
AND (iot_type=’IOT’ OR iot_type is NULL)
UNION
SELECT ‘Analyze table “‘||table_name||’” validate structure cascade into invalid_rows;’
FROM dba_tables
WHERE owner=’SYS’
AND partitioned=’YES’;

Another example of checking inconsistency, Reference – Quick method to identify table/index mismatch when analyze validate structure cascade takes significant time
(Doc ID 1554054.1)

Identify TABLE_NAME inconsistency with all its indexes:

SQL> execute analyze_quick(‘&TABLE_OWNER’,’&TABLE_NAME’)

If an inconsistency is detected, the procedure will stop and will not check the rest of indexes for TABLE_NAME.

Identify TABLE_NAME inconsistency with index INDEX_NAME:

SQL> execute analyze_quick(‘&TABLE_OWNER’,’&TABLE_NAME’, ‘&INDEX_NAME’)

— Note that if any of the errors below are raised, when
— performing an ANALYZE TABLE … VALIDATE STRUCTURE …
— command, then the errors will need to be addressed as
— physical data and/or index block corruption issues.
—
— ORA-01498
— ORA-01499
— ORA-01578

Источник

Доброго времени суток.
Начну с предыстории проблемы. Ранее работали на таком софте как METIMAG, затем перешли на Супермаг. С оставшимся наследством от МЕТИ давно не работали, но периодически нужны данные. Так вот в один прекрасный день это «чудо» не запустилось. Начали смотреть что и как.
1. При открытии базы вылетает ошибка, принят конец сигнала по коммуникационному каналу.
2. Начал гуглить смотреть что и как может быть, ошибка весьма размытая и предполагает много исходов
3. полез в алерт лог и трейсы, далее их содержание:
alertme01.log:

Tue Jun 23 17:54:26 2009
PMON: terminating instance due to error 474
Instance terminated by PMON, pid = 1564
Tue Jun 23 18:08:14 2009
Starting ORACLE instance (normal)
Tue Jun 23 18:08:14 2009
Running with 1 strand for Non-Enterprise Edition
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 2
Using log_archive_dest parameter default value
Running with 1 strand for Non-Enterprise Edition
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.5.0.
System parameters with non-default values:
processes = 200
timed_statistics = FALSE
shared_pool_size = 335544320
large_pool_size = 8388608
control_files = D:METIoracleME01control01.ctl, e:metioracleME01control02.ctl, f:metioracleME01control03.ctl
db_block_size = 8192
db_cache_size = 536870912
compatible = 9.2.0.5.0
db_file_multiblock_read_count= 16
fast_start_mttr_target = 0
undo_management = AUTO
undo_tablespace = METIUNDO
undo_retention = 10800
remote_login_passwordfile= EXCLUSIVE
db_domain =
instance_name = ME01
utl_file_dir = *
job_queue_processes = 1
hash_join_enabled = TRUE
background_dump_dest = d:metiorantrdbmstraceME01
user_dump_dest = d:metiorantrdbmstraceME01
core_dump_dest = d:metiorantrdbmstraceME01
sort_area_size = 524288
sort_area_retained_size = 262144
db_name = ME01
open_cursors = 300
star_transformation_enabled= FALSE
optimizer_index_cost_adj = 10
query_rewrite_enabled = FALSE
pga_aggregate_target = 268435456
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
CJQ0 started with pid=8
Tue Jun 23 18:08:16 2009
Oracle Data Guard is not available in this edition of Oracle.
Tue Jun 23 18:08:17 2009
/* OracleOEM */ ALTER DATABASE MOUNT
Tue Jun 23 18:08:21 2009
Successful mount of redo thread 1, with mount id 1288172625
Tue Jun 23 18:08:21 2009
Database mounted in Exclusive Mode.
Completed: /* OracleOEM */ ALTER DATABASE MOUNT
Tue Jun 23 18:08:21 2009
/* OracleOEM */ ALTER DATABASE OPEN
Tue Jun 23 18:08:22 2009
Beginning crash recovery of 1 threads
Tue Jun 23 18:08:22 2009
Started recovery at
Thread 1: logseq 30345, block 3, scn 0.0
Recovery of Online Redo Log: Thread 1 Group 3 Seq 30345 Reading mem 0
Mem# 0 errs 0: E:METIORACLEME01REDO03A.LOG
Mem# 1 errs 0: F:METIORACLEME01REDO03B.LOG
Tue Jun 23 18:08:22 2009
Completed redo application
Tue Jun 23 18:08:22 2009
Ended recovery at
Thread 1: logseq 30345, block 119, scn 0.1017135717
47 data blocks read, 47 data blocks written, 116 redo blocks read
Crash recovery completed successfully
Tue Jun 23 18:08:23 2009
Thread 1 advanced to log sequence 30346
Thread 1 opened at log sequence 30346
Current log# 1 seq# 30346 mem# 0: E:METIORACLEME01REDO01A.LOG
Current log# 1 seq# 30346 mem# 1: F:METIORACLEME01REDO01B.LOG
Successful open of redo thread 1
Tue Jun 23 18:08:24 2009
SMON: enabling cache recovery
Tue Jun 23 18:08:24 2009
Undo Segment 1 Onlined
Undo Segment 2 Onlined
Undo Segment 3 Onlined
Undo Segment 4 Onlined
Undo Segment 5 Onlined
Undo Segment 6 Onlined
Undo Segment 7 Onlined
Undo Segment 8 Onlined
Undo Segment 9 Onlined
Undo Segment 10 Onlined
Successfully onlined Undo Tablespace 1.
Tue Jun 23 18:08:24 2009
SMON: enabling tx recovery
Tue Jun 23 18:08:24 2009
Database Characterset is WE8ISO8859P1
Tue Jun 23 18:08:24 2009
ORACLE Instance me01 (pid = 6) — Error 1578 encountered while recovering transaction (5, 41).
Tue Jun 23 18:08:24 2009
Errors in file d:metiorantrdbmstraceme01me01_smon_2912.trc:
ORA-01578: ORACLE data block corrupted (file # 2, block # 30468)
ORA-01110: data file 2: ‘E:METIORACLEME01METIUNDO_01.ORA’

Tue Jun 23 18:08:26 2009
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: /* OracleOEM */ ALTER DATABASE OPEN
Tue Jun 23 18:08:28 2009
ALTER TABLESPACE METIINDEX COALESCE
Tue Jun 23 18:08:28 2009
Completed: ALTER TABLESPACE METIINDEX COALESCE
Tue Jun 23 18:08:29 2009
Errors in file d:metiorantrdbmstraceme01me01_pmon_3048.trc:
ORA-00474: SMON process terminated with error

Tue Jun 23 18:08:29 2009
PMON: terminating instance due to error 474
Instance terminated by PMON, pid = 3048

—
содержание трейса:
Dump file d:metiorantrdbmstraceme01me01_pmon_3048.trc
Tue Jun 23 18:08:29 2009
ORACLE V9.2.0.5.0 — Production vsnsta=0
vsnsql=12 vsnxtr=3
Windows 2000 Version 5.0 Service Pack 4, CPU type 586
Oracle9i Release 9.2.0.5.0 — Production
JServer Release 9.2.0.5.0 — Production
Windows 2000 Version 5.0 Service Pack 4, CPU type 586
Instance name: me01

Redo thread mounted by this instance: 1

Oracle process number: 2

Windows thread id: 3048, image: ORACLE.EXE

*** 2009-06-23 18:08:29.203
*** SESSION ID:(1.1) 2009-06-23 18:08:29.187
error 474 detected in background process
ORA-00474: SMON process terminated with error

—
по поводу ORA-00474 прочитал прогнозы неутешительные для базы. Проблема в том что поддержки нет, а дамп базы тоже уже битый.
Прошу помощи и совета, можно за эту базу побороться или оставить тщетные попытки если нет бэкапа, особо с какой стороны к этой базе подходить не знаю. Если есть способы ее завести подскажите пожалуйста как, файлы БД все лежат по местам.

We had SMON recovery crash with ORA-00607&ORA-00600: internal error code, arguments: [kdBlkCheckError]on 11.2.0.3.0 db on linux system.

Here is the all related error messages and solution:

Step 1: Check alert log

–Error Message
Block recovery from logseq 46434, block 825 to scn 14782663039152
Recovery of Online Redo Log: Thread 1 Group 50 Seq 46434 Reading mem 0
Mem# 0: +DATA/x<db_sid>/onlinelog/group_50.1918.898308101
Block recovery completed at rba 46434.847.16, scn 3441.3680573617
ORACLE Instance <DB_SID> (pid = 32) – Error 607 encountered while recovering transaction (447, 31) on object 197036643.
Errors in file /u01/app/oracle/diag/rdbms/<db_sid>/<DB_SID>/trace/<DB_SID>_smon_11855.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kdBlkCheckError], [1092], [339476], [6101], [], [], [], [], [], [], [], []
Dumping diagnostic data in directory=[cdmp_20160728141255], requested by (instance=1, osid=11855 (SMON)), summary=[incident=436122].
Errors in file /u01/app/oracle/diag/rdbms/<db_sid>/<DB_SID>/trace/<DB_SID>_smon_11855.trc (incident=436123):
ORA-00600: internal error code, arguments: [kdBlkCheckError], [1092], [339476], [6101], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/<db_sid>/<DB_SID>/incident/incdir_436123/<DB_SID>_smon_11855_i436123.trc
Thu Agu 01 14:12:57 2016
PMON (ospid: 11772): terminating the instance due to error 474
Step 2: See what happens on your system

–login as oracle user and run adrci utulity
$ adrci

ADRCI: Release 11.2.0.3.0 – Production on Fri Aug 01 08:56:27 2016

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

ADR base = “/u01/app/oracle”

–listing home
adrci> show home
ADR Homes:
diag/asmtool/user_oracle/host_2223417381_80
diag/rdbms/<db_sid>/<DB_SID>
diag/clients/user_oracle/host_2223417381_80
diag/clients/user_oracle/host_2223417381_11
diag/tnslsnr/xx/listener_1521
diag/tnslsnr/xx/listener_1522
diag/diagtool/user_oracle/host_2223417381_80
diag/asm/user_oracle/host_2223417381_80

–setting home
adrci> set home diag/rdbms/<db_sid>/<DB_SID>

–check problem
adrci> show problem

ADR Home = /u01/app/oracle/diag/rdbms/<db_sid>/<DB_SID>:
*************************************************************************
PROBLEM_ID PROBLEM_KEY LAST_INCIDENT LASTINC_TIME
——————– ———————————————————– ——————– —————————————-
1 ORA 600 [kdBlkCheckError] 510335 2016-01-08 17:19:43.204000 +03:00
1 rows fetched
–check errors.In this case:
– problem id –> 1
– error is –> ORA 600 [kdBlkCheckError]
– last_incident –> 510335
– lastinc_time –> 2016-01-08 17:19:43.204000 +03:00

–get details about error
adrci> show incident -p “problem_key=’ORA 600 [kdBlkCheckError]’”

ADR Home = /u01/app/oracle/diag/rdbms/<db_sid>/<DB_SID>:
*************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
——————– ———————————————————– —————————————-
510335 ORA 600 [kdBlkCheckError] 2016-01-08 17:19:43.204000 +03:00
1 rows fetched

— get details about what happen on this error
adrci>show incident -mode detail -p “incident_id=411533”
ADR Home = /u01/app/oracle/diag/rdbms/<db_sid>/<DB_SID>:
*************************************************************************

**********************************************************
INCIDENT INFO RECORD 1
**********************************************************
INCIDENT_ID 411533
STATUS ready
CREATE_TIME 2016-08-01 13:39:07.944000 +03:00
PROBLEM_ID 27
CLOSE_TIME <NULL>
FLOOD_CONTROLLED none
ERROR_FACILITY ORA
ERROR_NUMBER 600
ERROR_ARG1 kdBlkCheckError
ERROR_ARG2 1092
ERROR_ARG3 339476
ERROR_ARG4 6101
ERROR_ARG5 <NULL>
ERROR_ARG6 <NULL>
ERROR_ARG7 <NULL>
ERROR_ARG8 <NULL>
ERROR_ARG9 <NULL>
ERROR_ARG10 <NULL>
ERROR_ARG11 <NULL>
ERROR_ARG12 <NULL>
SIGNALLING_COMPONENT <NULL>
SIGNALLING_SUBCOMPONENT <NULL>
SUSPECT_COMPONENT <NULL>
SUSPECT_SUBCOMPONENT <NULL>
ECID <NULL>
IMPACTS 0
PROBLEM_KEY ORA 600 [kdBlkCheckError]
FIRST_INCIDENT 411533
FIRSTINC_TIME 2016-08-01 13:39:07.944000 +03:00
LAST_INCIDENT 510335
LASTINC_TIME 2016-08-01 17:19:43.204000 +03:00
IMPACT1 0
IMPACT2 0
IMPACT3 0
IMPACT4 0
KEY_NAME SID
KEY_VALUE 2017.1
KEY_NAME ProcId
KEY_VALUE 32.1
KEY_NAME Client ProcId
KEY_VALUE oracle11@xx.local 17997_140071949428480
OWNER_ID 1
INCIDENT_FILE /u01/app/oracle/diag/rdbms/<db_sid>/<DB_SID>/incident/incdir_411533/<DB_SID>_smon_17997_i411533.trc
OWNER_ID 1
INCIDENT_FILE /u01/app/oracle/diag/rdbms/<db_sid>/<DB_SID>/trace/<DB_SID>_smon_17997.trc
1 rows fetched
—

Step 3: Solve the issue

–in pfile add below lines into pfile
*.event=”10513 trace name context forever, level 2″ ## disable SMON recovery
*.event=”10231 trace name context forever, level 10″ ## skip corrupt blocks during select

–start your database from pfile

–After db up&running find corrupted blocks
select * from v$database_block_corruption;

–Also use this sql
COLUMN owner FORMAT A20
COLUMN segment_name FORMAT A30

SELECT DISTINCT owner, segment_name
FROM v$database_block_corruption dbc
JOIN dba_extents e ON dbc.file# = e.file_id AND dbc.block# BETWEEN e.block_id and e.block_id+e.blocks-1
ORDER BY 1,2;

Select * from dba_object where object_id=’xxx’;

–drop or truncate related  objects
drop index xxx

purge dba_recyclebin;
shu immediate
startup from spfile

–check database files via RMAN
RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL;

–Also use this sql
SQL->select * from v$database_block_corruption;