java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1

You relocated a database to another server and receive the following errors in the alert log:

Errors in file d:\oracle\product\10.2.0\admin\maxnips1\bdump\maxnips1_cjq0_5812.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-06544: PL/SQL: internal error, arguments: [56319], [], [], [], [], [], [], []
ORA-06553: PLS-801: internal error [56319]

Cause:-

The database on the new location was built using datafiles from a different word-size database. For example, you used the datafiles from a 64-bit database for your new 32-bit database OR you used the datafiles from a 32-bit database for your new 64-bit database. Either of these scenarios results in PL/SQL objects that are inconsistent with the Oracle executable.

Solution:-

SQL> shutdown immediate; 
SQL> startup upgrade; 
SQL> @$ORACLE_HOME/rdbms/admin/utlirp; 
SQL> shutdown immediate; 
SQL> startup; 
SQL> @@$ORACLE_HOME/rdbms/admin/utlrp;

ORA-06544: PL/SQL: internal error, arguments: [56327], [], [], [], [], [], [], []

You relocated a database to another server and receive the following errors in the alert log:

Errors in file d:\oracle\product\10.2.0\admin\maxnips1\bdump\maxnips1_cjq0_5812.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-06544: PL/SQL: internal error, arguments: [56319], [], [], [], [], [], [], []
ORA-06553: PLS-801: internal error [56319]

Cause:-

The database on the new location was built using datafiles from a different word-size database. For example, you used the datafiles from a 64-bit database for your new 32-bit database OR you used the datafiles from a 32-bit database for your new 64-bit database. Either of these scenarios results in PL/SQL objects that are inconsistent with the Oracle executable.

Solution:-

SQL> shutdown immediate; 
SQL> startup upgrade; 
SQL> @$ORACLE_HOME/rdbms/admin/utlirp; 
SQL> shutdown immediate; 
SQL> startup; 
SQL> @@$ORACLE_HOME/rdbms/admin/utlrp;

ORA-06553: PLS-801: internal error [56327]

You relocated a database to another server and receive the following errors in the alert log:

Errors in file d:\oracle\product\10.2.0\admin\maxnips1\bdump\maxnips1_cjq0_5812.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-06544: PL/SQL: internal error, arguments: [56319], [], [], [], [], [], [], []
ORA-06553: PLS-801: internal error [56319]

Cause:-

The database on the new location was built using datafiles from a different word-size database. For example, you used the datafiles from a 64-bit database for your new 32-bit database OR you used the datafiles from a 32-bit database for your new 64-bit database. Either of these scenarios results in PL/SQL objects that are inconsistent with the Oracle executable.

Solution:-

SQL> shutdown immediate; 
SQL> startup upgrade; 
SQL> @$ORACLE_HOME/rdbms/admin/utlirp; 
SQL> shutdown immediate; 
SQL> startup; 
SQL> @@$ORACLE_HOME/rdbms/admin/utlrp;

How to use Oracle Recycle bin Utility

Oracle Recycle bin Utility

Oracle has introduced "Recycle Bin" Feature Oracle 10g to store all the dropped objects. 
If any table in Oracle 10g is dropped then any associated objects to this table such as indexes, 
constraints and other dependent objects are simply renamed with a prefix of BIN$$.


Testing


Go to SQL*PLUS


1) connect to database

2)  Issue the command select * from tab;

3) Now we will delete DEPT table

4) Issue the command select * from tab;

5) Issue the command as shown in figure to check tables in Recycle bin

6) Now recover table DEPT from Recycle bin

7) Now check your table successfully recovered

This is use of recycle bin.

If you really don't want that table. Before flashback. Just  issue following command.
your tables will deleted permanently

SQL > PURGE RECYCLEBIN

ORA-03114: not connected to ORACLE

There are multiple scenarios that cause this error. Check the following list of solutions:

1. Verify there is no firewall or router setting which terminates connections which are active for longer than x minutes.

2. Verify there is no firewall or router setting which terminates connections which are idle for longer than x minutes.

3. Verify the Oracle configuration. Let the database send a packet every x minutes, so that the firewall, router, etc does not close the connection due to being 'idle'.

1. The Oracle documentation lists the following details for the  sqlnet.ora parameter: SQLNET.EXPIRE_TIME

Purpose:
Use parameter SQLNET.EXPIRE_TIME to specify the time interval, in minutes, to send a probe to verify that client/server connections are active. Setting a value greater than 0 ensures that connections are not left open indefinitely, due to an abnormal client termination. If the probe finds a terminated connection, or a connection that is no longer in use, it returns an error, causing the server process to exit. This parameter is primarily intended for the database server, which typically handles multiple connections at any one time.
Limitations on using this terminated connection detection feature are:
 

- It is not allowed on bequeathed connections.
 

- Though very small, a probe packet generates additional traffic that may downgrade network performance.
 

- Depending on which operating system is in use, the server may need to perform additional processing to distinguish the connection probing event from other events that occur. This can also result in degraded network performance.

Default:  0
Minimum Value: 0
Recommended Value: 10
Example:
SQLNET.EXPIRE_TIME=10
Perform the following test:

• Stop your Oracle database instance
• Edit the $ORACLE_HOME/network/admin/sqlnet.ora file and add SQLNET.EXPIRE_TIME=3
• Restart the Oracle database instance
• Do a full connect with the Oracle WP driver via ODBCTest as SYSTEM/MANAGER
• Execute the following stored procedure: {call dbms_lock.sleep(3000)} (sleeps for 50 minutes). Adapt the value to your needs.

2. Check the Oracle setting connection idle time limit.

• This can be set in the Oracle Enterprise Manager Console.
• Select the database you are using and click down to the "security\profile\\idle time".
• Setting this to something lower than 60 minutes will cause the user to be disconnected after that XX minutes of inactivity.

ORA-01000: maximum open cursors exceeded

You get this error when a user of a host program attempts to open more cursors than they are allowed.

The number of cursors allowed is dictated by the OPEN_CURSORS initialization parameter, and this quota can be eaten up by both implicit and explicit cursors.

However, it is possible that the OPEN_CURSORS number is just too low for the needs of your application and has to be upped. The default value is 50, however the only factor limiting how high this number can go – 300, 1000, 2000 even – is what the operating system can take.

However, it may be unwise to choose to change the OPEN_CURSORS parameter too steeply, rather than examine your code for leaks.

Below are the steps :-

SQL> alter system set open_cursors=1000 (any higher value) scope=both sid='*';

or

If you want to use initi.ora file, then you can create one using spfile or if it already exists you can modify it

 To create pfile

Login as sysdba

 SQL> create pfile='/location/init.ora' from spfile;
File Created;

Cd to location and edit init.ora file

*.open_cursrors=1000 # higher value

sql> shutdown immediate
sql> starutp mount pfile='/location/init.ora';
sql> alter database open;
sql> show parameter open_cursors;

ORA-03113: end-of-file on communication channel

This error pretty much means that your connection has clutched its chest and died.

For some reason, your client machine and the database server are acting like an old married couple and have stopped talking to each other.

That reason could be one of a rather long list:

1. Has your server crashed?   -  Try to ping the server
2. Has someone pulled out your network cable?   -  Try to ping the server
3. Was your process killed at the O/S level?   - Contact your Sys Admin
4. Is your Windows log full?  -  Check yourself or Contact your Sys Admin
5. Maybe there is an Oracle internal error?  - Need to check Alert log , if you are a DBA check it yourself to ask your DBA for HELP!!

My advice is this do not overlook the obvious.

This error is sometimes caused by the simplest of things.

If, however, it is caused by an Oracle internal error, look to your alert log for further information.

Solution:- Wait for some time and try again

ORA-12154: TNS:could not resolve the connect identifier specified

Simply put, it means that you have named the database you wish to be connected to and Oracle doesn’t know who the heck you’re talking about.

This error is often caused by typos, maybe in your connection string, but possibly in your tnsnames.ora file.

Best thing to do is open a command prompt and issue following command. I am assuming that connection name is "ORCL"

tnsping orcl

It is also possible that the tnsnames.ora file is not accessible or does not even exist. If it does, ensure that it contains the service name you are using.