ORA-00600: Internal Error Code, Arguments: [3020]/ORA-10567 Reported Shortly After converting Snapshot Database to Physical Standby and Starting Managed recovery
(Doc ID 2333621.1)
Last updated on NOVEMBER 12, 2024
Applies to:
Oracle Database - Enterprise Edition - Version 11.2.0.4 to 12.2.0.1 [Release 11.2 to 12.2]Oracle Database Cloud Schema Service - Version N/A and later
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Information in this document applies to any platform.
Symptoms
Primary and Standby Configuration.
The sequence of events leading up to the ORA-00600:[3020] is this:
1. alter database convert to snapshot standby;
2. open read write
3. alter database convert to physical standby;
4. start media recovery
5. after a short time, media recovery fails with ORA-00600:[3020]
The ORA-10564 shows the problematic block is in the SYSAUX tablespace.
ORA-10567: Redo is inconsistent with data block (file# 200, block# 12256, file offset is 1004019712 bytes)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 200: '+<PATH>/<FILE_NAME>'
ORA-10560: block type '0'
.
ORA-00600: internal error code, arguments: [3020], [200], [12256],
The ORA600 tracefile includes these msgs:
- KCOX_FUTURE: CHANGE IN FUTURE OF BLOCK
- RECOVERY STUCK AT BLOCK <block#> OF FILE <file#>
> Direct Load insert might be involved(When in Snapshot database mode)
Call stack :- kcbr_mapply_change <- kcbrapply <- kcbr_apply_pending <- krp_slave_apply
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Symptoms |
| Cause |
| Solution |
| References |