ORA-00600 [17147] ORA-48216 When Querying V$DIAG_ALERT_EXT View

When I try to query v$diag_alert_ext appears error:

ORA-00600: internal error code, arguments: [17147], [0x110A09510], [], [], [], [], [], [], [], [], [], []
ORA-48216: Field Len Exceeds Max Field Length [5] [30] [29286] [66]

Here is query which is used for quering alert.log entries

select instance_id, originating_timestamp, message_text, '1'
  from table(gv$(cursor (select instance_id, originating_timestamp, message_text
                    from v$diag_alert_ext a
                   where originating_timestamp > (sysdate - 1)
                     and (message_text like '%ORA-%' or
                         message_text like '%CRS-%'))))
 order by originating_timestamp desc;

As I found on metalink The issue is matching unpublished Bug 21266522 duplicate of unpublished Bug 18909196 - QUERIES INVOLVING X$DBGALERTEXT SOMETIMES FAIL DUE TO ORA-48216.
Solution:

1. Download and install the one-off Patch 18909196, available for your platform (this issue only exists in 11.2.0.4). If a patch does not exist for your platform please open a Service Request for Oracle Support.
-OR-
2. Implement the workaround: remove (i.e. delete) the xml-based alert log within /alert/log.xml (and log_*.xml).

ORA-00600: internal error code, arguments: [qcisSetPlsqlCtx:tzi init], [], [], [], [], [], [], [], [], [], [], []

I was trying to restore Oracle database on another host and after open database with resetlogs option in alert.log file appear below internal error:

ORA-00600: internal error code, arguments: [qcisSetPlsqlCtx:tzi init], [], [], [], [], [], [], [], [], [], [], []

Beside this, database was working very slowly, every command was working extremely slowly and overall database working was unresponsive.
Solution:
1) Check files under $ORACLE_HOME/oracore/zoneinfo directory on database server, where backup is taken and replace files on local $ORACLE_HOME/oracore/zoneinfo where restore is done.
2) Restart database and everything is going smoothly.

ORA-00600: ORA-10567: ORA-10560: Physical standby redo applying error

It is not the first time we face the problem with applying redo on physical standby. Very old environment - Oracle 10gr2 with raw devices on old SUN storage believed to be suffering from physical lost writes. Particularly at the heavy load on primary where loads of redo log files are being generated.
So, the errors in alert.log are as follow:

ORA-00600: internal error code, arguments: [3020], [87], [154002], [365058450], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 87, block# 154002)
ORA-10564: tablespace CB_IND
ORA-01110: data file 87: '/dev/vx/rdsk/ora02dg/cb_ind05'
ORA-10560: block type '0'

Famous ORA-00600 error when metalink gets handful. It says:

“This error can be reported if any of these updates are lost for some reason.
Therefore, thoroughly check your operating system and disk hardware.
In the case of a lost update, restore an old copy of the datafile and attempt to recover and roll forward again. (Doc ID 30866.1)”

Our only option was a restore by oracle as os investigation would take significant time. Even more, you still need to restore damaged file from oracle at the end. So, as a recommendation we suggest not thinking much and start immediate restore.

Steps are as follow:

1. primary database -

 backup as copy datafile 87 format '/share/sbtarch/ind5'; 

(raw devices add more trick to backup and restore operations. In case of normal fs it would be possible to put corresponding TS in backup mode and just a copy the datafile )

2. primary database -

 copy current controlfile for standby TO '/share/sbtarch/control03.dbf'  

3. standby database – mount instance with newly copied control file

4. standby database –

  run { 
             ALLOCATE CHANNEL ch02 TYPE DISK;
             restore datafile 87; 
      }

5. on standby (in case of rman catalog you might avoid this step)

 catalog start with '/oracle/arch';  after control file copied 

6. on standby –

 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY disconnect from session; 

At this point, recovery started and all archived log files in queue applied successfully.

Thanks,