ORA-00600: internal error code, arguments: [audins:Invalid_param_type_for_binding

Error in Alert Log:

Errors in file /u03/app/oracle/diag/rdbms/primeprd/primeprd1/trace/primeprd1_ora_303370.trc (incident=1070393):

ORA-00600: internal error code, arguments: [audins:Invalid_param_type_for_binding], [], [], [], [], [], [], [], [], [], [], []

 

Error in Broker :

DGMGRL> add database primedr as connect identifier is primedr maintained as physical;
Database “primedr” added

DGMGRL> enable configuration;
Enabled.
DGMGRL> show configuration

Configuration – dg_primeprd

Protection Mode: MaxPerformance
Members:
primeprd – Primary database
primedr – Physical standby database
Error: ORA-16664: unable to receive the result from a database

DGM-17016: failed to retrieve status for database “primedr”
ORA-16664: unable to receive the result from a database

Broker logfile error:

11/22/2017 16:42:26
ENABLE CONFIGURATION
11/22/2017 16:42:55
Site primedr returned ORA-16664.

 

Description:

We had this error when we were adding a Standby database to the Dataguard Broker. After enabling the configuration always it used to give error ORA-16664: unable to receive the result from a database. After literally months of digging around and opening multiple SR’s we discovered it was related to AUDIT logs which are written in AUD$. It was clear after searching the trace logfiles that an application context package has some issues with the Audit in Oracle 12c.

Error Showing Up in TraceFile

DDE: Problem Key ‘ORA 600 [audins:Invalid_param_type_for_binding]’ was flood controlled (0x2) (incident: 1070379)
ORA-00600: internal error code, arguments: [audins:Invalid_param_type_for_binding], [], [], [], [], [], [], [], [], [], [], []
*********START PLSQL RUNTIME DUMP************
***Got internal error Exception caught in pl/sql run-time while running PLSQL***
***Got ORA-2002 while running PLSQL***
PACKAGE BODY TCTDBS.SV_DB_CONTEXT:
library unit=677604e58 line=225 opcode=86 static link=7fb08c2b4888 scope=1
FP=0x7fb08c2b4d10 PC=0x9e7cdec82 Page=0 AP=0x7fb08c2b4888 ST=0x7fb08c2b5158
DL0=0x7fb0872edd50 GF=0x7fb0872edf60 DL1=0x7fb0872ede48 DPF=0x7fb0872edf48
HS=0x9e7cd8ae8 AR=0x7fb0872e9fc8 DS=0x9e7ce0148
PB_PC=(nil) SV_PC=(nil)

Solution:

The solution is simply to turn off the auditing for the objects which is giving error. Since we are already running an auditing solution;  native auditing of Oracle was not required in this scenario.

— Dynamic SQL to generate and execute the no audit statements —

DECLARE
l_sql_stmt varchar2(1000);
BEGIN
FOR t IN (SELECT owner, table_name
FROM all_tables
WHERE owner = ‘TCTDBS’
and
iot_type IS NULL
or
iot_type != ‘IOT_OVERFLOW’
)
LOOP
l_sql_stmt := ‘NOAUDIT ALL ON ‘ || t.owner || ‘.’ || t.table_name;
EXECUTE IMMEDIATE l_sql_stmt;
END LOOP;
END;

Once this was done we added the Standby Database to the Dataguard Broker and Enabled the configuration without any issues.

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s