These days at least for me seeing an ORA 600 is a relative rare ( thank god ) occurrence. They always raise your blood pressure sometimes to unhealthy levels. Looking at one that at first glance hints at possible block corruption ... not good.
This bug 8895202 was fixed already in current environment but not "enabled" ( so thanks so much ... what use is a bug that is fixed but not enabled to be fixed ). Apparently can happen in active data guard environment after switchover/switchback?
Looks like bad interaction of commit scn and itl scn in ( index blocks )?
Good news is ( rarely do 600's give you good news ) is can enable this dynamically ... scope=both ...
Although this fix is included in 18.104.22.168 / 22.214.171.124, it has to be enabled by setting "_ktb_debug_flags"=8; Rediscovery Notes ORA-1555 / ORA-600 [ktbdchk1: bad dscn] / ktbGetDependentScn / Dependent scn violations as itl has higher commit scn than block scn. This happens in a Physical Standby database after a switchover. DBVERIFY (with fix of Bug 7517208) reports: itl[<itl_id>] has higher commit scn(aaa.bbb) than block scn (xx.yy) Page <Block#> failed with check code 6056 There is NO DATA CORRUPTION in the block. Workaround This fix is the workaround. It doesn't prevent to have a higher ITL SCN than the commit scn (csc). With this fix if parameter _ktb_debug_flags = 8 the SCN is repaired when block is cleaned out (eg: block update). While blocks are not touched dbverify still reports 6056 errors Sometimes the fix may not repair the block and the index may need rebuilding.