ORA-600 [kwqitnmphe:ltbagi], [1], [0] reported in the alert log file.

ORA-00600 [kwqitnmphe:ltbagi]

Cause: This issue arises in 12.1.0.2. The error occurs because there are still Historical Messages without a current Subscriber (a.k.a. orphaned entries in the History table), and can be confirmed by the following SQL statement:

select
sub_hist.NAME, sub_hist.SUBSCRIBER#, sub_hist.MSGID, msg.QUEUE, msg.MSG_STATE
from
AQ$_SYS$SERVICE_METRICS_TAB_H sub_hist,
AQ$SYS$SERVICE_METRICS_TAB msg
where
sub_hist.MSGID = msg.MSG_ID and
NOT EXISTS (select sub.SUBSCRIBER_ID from aq$_SYS$SERVICE_METRICS_TAB_s sub where sub_hist.subscriber# = sub.SUBSCRIBER_ID)
;

There are several bugs reported to cause this issue:
Bug 17831758: ORA-600 [kwqitnmphe:ltbagi] in Qnnn background process
Bug 18536720: ORA-600 [kwqitnmphe:ltbagi] processing History IOT in AQ
Bug 16204151: -ORA-600 [kwqitnmphe:ltbagi] when subscriber is dropped pending enqueue/dequeue
However, even with the fix for these bugs in place the ORA-00600 [kwqitnmphe:ltbagi] errors are still seen because the problem data still exists in the queue table.

Solution:
1.  Do the following to purge the data in the queue table and IOTs

connect / as sysdba

DECLARE
po dbms_aqadm.aq$_purge_options_t;
BEGIN
po.block := FALSE;
DBMS_AQADM.PURGE_QUEUE_TABLE(
  queue_table => 'SYS.SYS$SERVICE_METRICS_TAB',
  purge_condition => NULL,
  purge_options => po);
END;
/

The data in this queue table is transitory, so although it is lost it will soon be replaced.


2.  Apply the fixes for bug 17831758, bug 18536720 and bug 16204151 and ensure that post-install steps are followed.

All bugs will be resolved in 12.2 when it is available.
Recompile all invalid objects

@?/rdbms/admin/utlrp.sql

ORA-01105: mount is incompatible with mounts by other instances ORA-19808: recovery destination parameter mismatch

ORA-01105: mount is incompatible with mounts by other instances
ORA-19808: recovery destination parameter mismatch


Cause: it occurs in RAC environment. issue is due to mismatch of DB_RECOVERY parameters between nodes.
Solution: Make sure the parameters db_recovery_file_dest,db_recovery_file_dest_size are same for all nodes

Example:

Node-1
SQL> show parameter recovery
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string +DATA
db_recovery_file_dest_size big integer 10G
recovery_parallelism integer 0

Node-2
SQL> show parameter recovery
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string +DATA
db_recovery_file_dest_size big integer 100G
recovery_parallelism integer 0

SQL> startup
ORACLE instance started.
Total System Global Area 4275781632 bytes
Fixed Size 2235208 bytes
Variable Size 1694500024 bytes
Database Buffers 2566914048 bytes
Redo Buffers 12132352 bytes
ORA-01105: mount is incompatible with mounts by other instances
ORA-19808: recovery destination parameter mismatch

to clear this error and mount the database set  db_recovery_file_dest_size same on both nodes.
SQL> alter system set db_recovery_file_dest_size = 100G scope=spfile;
 System altered.

SQL> startup
ORACLE instance started.
Total System Global Area 4275781632 bytes
Fixed Size 2235208 bytes
Variable Size 1694500024 bytes
Database Buffers 2566914048 bytes
Redo Buffers 12132352 bytes
Database mounted.
Database opened. 

ORA-01264: Unable to create datafile file name ORA-19800: Unable to initialize Oracle Managed Destination

ORA-01264: Unable to create datafile file name
ORA-19800: Unable to initialize Oracle Managed Destination

Error Description:
----------------------------------
 ERROR at line 1:
ORA-01264: Unable to create datafile file name
ORA-19800: Unable to initialize Oracle Managed Destination
Solaris-AMD64 Error: 13: Permission denied

Or in linux the error stuck is,

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01264: Unable to create logfile file name
ORA-19800: Unable to initialize Oracle Managed Destination
Linux Error: 13: Permission denied

Cause of The problem:
-------------------------------------
The user don't have the permission to write in the specified location. This is Operating system permission. I got this error while duplicating the database from from backup location. in my case the exact cause is I forgot to mention the db_recovery_file_dest parameter.

Solution of The problem:
----------------------------------
Give the necessary permission to the user so that OS user who is running oracle can create file in the specified directory. or put the db_recovery_file_des in the duplicate command

First Scenario:
------------------------------------------
 duplicate target database to 'TARGET_1' from active database
spfile
set db_file_name_convert '/u01/dba/db/data/SOURCE_1','/u02/TARGET_1/db/data/TARGET_1'
set LOG_FILE_NAME_CONVERT '/u01/dba/db/data/SOURCE_1','/u02/TARGET_1/db/data/TARGET_1'
set control_files '/u02/TARGET_1/db/data/TARGET_1/control01.ctl','/u02/TARGET_1/db/fast_recovery_area/TARGET_1/control02.ctl'
set diagnostic_dest '/u02/TARGET_1/db'
set db_recovery_file_dest '/u02/TARGET_1/db/fast_recovery_area'
set audit_file_dest '/u02/TARGET_1/db/admin/TARGET_1/adump'
SET log_archive_dest_1 'location=/u02/TARGET_1/db/arch'
;


Second Scenario:
--------------------------------
In the second scenario user don't have permission on flash recovery area.
You can see flash recovery area location by,
SQL> show parameter db_recovery

# chown -R oracle:dba /u02/TARGET_1/db/fast_recovery_area


Now try to do operation and hopefully it will work.

ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout

ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout

KUP-11024: This external table can only be accessed from within a Data Pump job.

Alert log File information:

DBMS_STATS: GATHER_STATS_JOB encountered errors.  Check the trace file.

Errors in file /u01/app/oracle/admin/testdb/diag/rdbms/testdb/testdb/trace/testdb_j000_22426.trc:

ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout

KUP-11024: This external table can only be accessed from within a Data Pump job.

Trace File Information:

*** 2015-03-26 08:30:18.342

DBMS_STATS: GATHER_STATS_JOB: GATHER_TABLE_STATS('"OPS$ORACLE"','"ET$016FA3770001"','""', ...)

DBMS_STATS: ORA-20011: Approximate NDV failed: ORA-29913: error in executing ODCIEXTTABLEOPEN callout

KUP-11024: This external table can only be accessed from within a Data Pump job.

Cause:

The primary cause of this issue is that an external table existed at some point in time but does not now. However, the database still believes the table exists since the dictionary information about the object has not been modified to reflect the change. When DBMS_STATS is run against the table in question, it makes a call out to the external table which fails because the object is not there.

There are many reasons that an external table may not exist including:

1. Temporary Data pump external tables have not been cleaned up properly. The dictionary information should have been dropped when the DataPump jobs completed.

2. An External table has been removed without clearing up the corresponding data dictionary information. For example: Oracle Demo Schema Tables such as the external table “SALES_TRANSACTIONS_EXT” may have been removed but the dictionary has not been updated to reflect this. The "SALES_TRANSACTIONS_EXT" table is an external table in the "SH" schema which is one of Demo Schema provided by Oracle.

Note:Our issue is due to point one. External tables are not cleaned properly.

Solutions:  To clean up the Orphaned datapump jobs.

Check and cleanup orphaned datapump jobs:

SELECT owner_name, job_name, operation, job_mode,state, attached_sessions FROM dba_datapump_jobs

WHERE job_name NOT LIKE 'BIN$%'

ORDER BY 1,2;

To identify the external tables.

SQL> conn / as sysdba

Connected.

SQL>

set linesize 200 trimspool on

set pagesize 2000

col owner form a30

col created form a25

col last_ddl_time form a25

col object_name form a30

col object_type form a25

select OWNER,OBJECT_NAME,OBJECT_TYPE, status,

to_char(CREATED,'dd-mon-yyyy hh24:mi:ss') created

,to_char(LAST_DDL_TIME , 'dd-mon-yyyy hh24:mi:ss') last_ddl_time

from dba_objects

where object_name like 'ET$%'

/

OWNER                          OBJECT_NAME                    OBJECT_TYPE               STATUS  CREATED                   LAST_DDL_TIME

------------------------------ ------------------------------ ------------------------- ------- ------------------------- -------------------------

OPS$ORACLE                     ET$000E4FF90001                TABLE                     VALID   16-oct-2012 13:10:15      16-oct-2012 13:10:15

OPS$ORACLE                     ET$007360190001                TABLE                     VALID   18-sep-2012 23:17:32      18-sep-2012 23:17:32

OPS$ORACLE                     ET$00F39F430001                TABLE                     VALID   16-oct-2012 13:33:10      16-oct-2012 13:33:10

OPS$ORACLE                     ET$016FA3770001                TABLE                     VALID   16-oct-2012 13:57:36      16-oct-2012 13:57:36

8 rows selected.

SQL> select owner, TABLE_NAME, DEFAULT_DIRECTORY_NAME, ACCESS_TYPE

from dba_external_tables order by 1,2

 /

OWNER                          TABLE_NAME                     DEFAULT_DIRECTORY_NAME         ACCESS_

------------------------------ ------------------------------ ------------------------------ -------

OPS$ORACLE                     ET$000E4FF90001                PRODUCT_REFRESH_DIR            CLOB

OPS$ORACLE                     ET$007360190001                PRODUCT_REFRESH_DIR            CLOB

OPS$ORACLE                     ET$00F39F430001                PRODUCT_REFRESH_DIR            CLOB

OPS$ORACLE                     ET$016FA3770001                PRODUCT_REFRESH_DIR            CLOB

To Drop the external temporary datapump tables.

SQL> drop table OPS$ORACLE.ET$000E4FF90001;

SQL> drop table OPS$ORACLE.ET$007360190001;

SQL> drop table OPS$ORACLE.ET$00F39F430001;

SQL> drop table OPS$ORACLE.ET$016FA3770001;

5.To ensure there is no datapump temporary tables.

SQL> select OWNER,OBJECT_NAME,OBJECT_TYPE, status,

to_char(CREATED,'dd-mon-yyyy hh24:mi:ss') created

,to_char(LAST_DDL_TIME , 'dd-mon-yyyy hh24:mi:ss') last_ddl_time

from dba_objects where object_name like 'ET$%'

/

no rows selected

SQL> select owner, TABLE_NAME, DEFAULT_DIRECTORY_NAME, ACCESS_TYPE from dba_external_tables order by 1,2

 /

Reference doc   1274653.1  

ORA-01116: error in opening database file 1 ORA-01110: data file 1: '/u01/app/oracle/TESTDB/oradata/dbf/system01.dbf'

How to recover database when system datafile is lost using RMAN backup?
or 
how to resolve ORA-01116: error in opening database file 1  ORA-01110: data file 1: '/u01/app/oracle/TESTDB/oradata/dbf/system01.dbf'?

Cause: ORA-01116: error in opening database file 1 means either system datafile is either missing or corrupted
Action: we need to perform recovery as shown below

DB Name: TESTDB
[oracle@avalance_testserv dbf]$   ls
redo01.log  redo02.log  redo03.log  sysaux01.dbf  system01.dbf  temp01.dbf  undotbs01.dbf  users01.dbf
[oracle@avalance_testserv dbf]$  rm system01.dbf
SQL> select * from sys.aud$;
select * from sys.aud$
                  *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01116: error in opening database file 1
ORA-01110: data file 1: '/u01/app/oracle/TESTDB/oradata/dbf/system01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Note: Since the normal shutdown is not possible in this case we shall use shut abort
SQL> shut abort
ORACLE instance shut down
[oracle@avalance_testserv dbf]$ sqlplus / as sysdba
SQL> startup mount
[oracle@avalance_testserv dbf]$ rman target/
RMAN> restore datafile 1;
Starting restore at 25-SEP-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=98 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/TESTDB/oradata/dbf/system01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/TESTDB/flash_recovery_area/TESTDB/backupset/ORA_rman_full_backup_ttdtest_0lpjddnk_1_1.bck
channel ORA_DISK_1: piece handle=/u01/app/oracle/TESTDB/flash_recovery_area/TESTDB/backupset/ORA_rman_full_backup_ttdtest_0lpjddnk_1_1.bck tag=FULL_OPEN_BACKUP_DISK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:15
Finished restore at 25-SEP-14
RMAN> recover datafile 1;
Starting recover at 25-SEP-14
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 22 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_22_859142042.arc
archived log for thread 1 with sequence 23 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_23_859142042.arc
archived log for thread 1 with sequence 24 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_24_859142042.arc
archived log for thread 1 with sequence 25 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_25_859142042.arc
archived log for thread 1 with sequence 26 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_26_859142042.arc
archived log for thread 1 with sequence 27 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_27_859142042.arc
archived log for thread 1 with sequence 28 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_28_859142042.arc
archived log for thread 1 with sequence 29 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_29_859142042.arc
archived log for thread 1 with sequence 30 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_30_859142042.arc
archived log for thread 1 with sequence 31 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_31_859142042.arc
archived log for thread 1 with sequence 32 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_32_859142042.arc
archived log for thread 1 with sequence 33 is already on disk as file /u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_33_859142042.arc
archived log file name=/u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_22_859142042.arc thread=1 sequence=22
archived log file name=/u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_23_859142042.arc thread=1 sequence=23
archived log file name=/u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_24_859142042.arc thread=1 sequence=24
archived log file name=/u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_25_859142042.arc thread=1 sequence=25
archived log file name=/u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_26_859142042.arc thread=1 sequence=26
archived log file name=/u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_27_859142042.arc thread=1 sequence=27
archived log file name=/u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_28_859142042.arc thread=1 sequence=28
archived log file name=/u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_29_859142042.arc thread=1 sequence=29
archived log file name=/u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_30_859142042.arc thread=1 sequence=30
archived log file name=/u01/app/oracle/TESTDB/oradata/arch/TESTDB_1_31_859142042.arc thread=1 sequence=31
media recovery complete, elapsed time: 00:00:00
Finished recover at 25-SEP-14
sql>alter database open;
It is suggested to take RMAN backup immediately after the activity is over. please follow the link to take RMAN backup: http://orcl11gdba.blogspot.in/2014/05/taking-database-backup-using-rman-method.html