ORA-02068: following severe error from string string

I got ” ORA-02068: following severe error from string string ”  error in Oracle database.

 

ORA-02068: following severe error from string string

 

Details of error are as follows.

ORA-02068: following severe error from string string

Cause: A severe error (disconnect, fatal Oracle error) received from the indicated database
 link. See following error text.

Action: Contact the remote system administrator.

On RAC instance, with db link, select query is failing with

ORA-07445: exception encountered: core dump [] [SIGSEGV] [unknown code] [0x000000060] [] []
ORA-02068: following severe error from <db_name>
ORA-03113: end-of-file on communication channel


The complete sequence of messages in the alert log is similar to:

Errors in file /../../../admin/<dbname>/udump/<instname>_reco_28993.trc:
ORA-07445: exception encountered: core dump [] [SIGSEGV] [unknown code] [0x000000060] [] []
ORA-02068: following severe error from <db_name>
ORA-03113: end-of-file on communication channel
Mon Sep 26 02:23:58 2005
Trace dumping is performing id=[cdmp_20050926022358]
Mon Sep 26 02:23:59 2005
Errors in file /../../../admin/<dbname>/bdump/<instname>_pmon_28971.trc:
ORA-00476: RECO process terminated with error
Mon Sep 26


Also, we might see the following errors in alert.log:

ORA-02068: following severe error from dblink_name
ORA-03113: end-of-file on communication channel
ORA-07445: exception encountered: core dump [lxsCpStr()+688] [SIGSEGV] [Address not mapped to object] [0x60] [] []

 

 

following severe error from string string

This ORA-02068 is related with the severe error (disconnect, fatal Oracle error) received from the indicated database
link. See following error text.

Contact the remote system administrator.

TAF is not supported for remote database links. TAF is not supported for DML statements. This limitation is now documented in Oracle 10.2

The instance crash is caused by Bug 4496339 RECO PROCESS DIES WITH ORA-7445 [lxsCpStr] (Fixed-Releases: 10.2.0.3 and 11.1.0.6)

The fix avoids the instance from crashing.

 

1. To implement the solution, do the following while connected as sysdba. Please keep a spool of the output.

The procedure you are adopting is to clean up stranded 2pc entries in the database. Stranded entries means RECO process is not able to clean up the entries even after failure due to some reason. For every database where the action plan is applied identify the local_tran_id from dba_2pc_pending and use the procedure to purge it. The below steps would resolve the issue:

 

1. SQL> select * from dba_2pc_pending;

2. -- check the current value of _smu_debug_mode (default 0):

SQL> show parameter debug -- if default 0, it will show no entry

-- set it temporarily to 4:

3. SQL> alter system set "_smu_debug_mode" = 4; -- in 9.2x alter session can be used instead.

4. SQL> commit; -- so that the call to DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY is the first step of the transaction

5. SQL> execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('<transaction id>');

6. SQL> commit;

7. SQL> alter system set "_smu_debug_mode" = <original value>;

8. SQL> commit;

9. SQL> select * from dba_2pc_pending;

 

2. Download <patch 5021063> for 10.1.0.4 which includes the fix for this bug

– OR –

3. Download patch 4496339 if available on your database version and platform.

– OR –

4. The bug also lists a workaround: do not use failover for dblinks.

– OR –

5. The bug is fixed in 10.2.0.3 and 11.1.0.6 . Upgrade to one of these patchsets or higher.

 

Second case is as follows.

 

o Certain SQL statements over a database link intermittently fails with ORA-2068 following severe error from. Insert can fails whilst select woks fine.

o No other errors reported

o When Oracle Net tracing is enabled, the problem does not reproduce.

 

 

Without diagnostics, root cause is not possible.Enabling Oracle Net tracing allows the insert to work, but working from past experiences, it is believed the physical network performance is effecting the SQL running across the link.

Performance of Oracle Net can be affected by sending more or less packets Oracle Net packets. It has been found, that by lowering the value of the Session Data Unit (SDU) in Oracle Net, allows the insert to work correctly, even when the physical network has a problem.

 

Lower the value for Oracle Net SDU size and send more packets across the database link.

The default SDU size is 2k.

To configure the client, set the SDU size with the SDU parameter in a connect descriptor as follows:

SERVICE.DOMAIN.COM =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = <hostname>)(PORT = 1521))
)
(SDU = 1024)
(CONNECT_DATA =
(SID_NAME = <instance_name>)
)
)

If using shared server processes, set the SDU size in the DISPATCHERS parameter as follows:

DISPATCHERS=”(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<hostname>))(SDU=1024))”

Ensure that the SDU size matches the value configured for the client

If using dedicated server processes for a database that is dynamically registered with the listener through service registration, then the SDU size cannot be set. Instead, the 2 KB default is used.

If using dedicated server processes for a database that is registered with the listener through static configuration in the LISTENER.ORA file, then set the SDU size in the SID_DESC section of the LISTENER.ORA file as follows:

 

SID_LIST_listener_name=
  (SID_LIST=
    (SID_DESC=
     (SDU=1024)
     (SID_NAME=<sid_name>)))

 

Ensure that the SDU size matches the value configured for the client.

SDU can also be changed for dynamic (SERVICE_NAME) connections. By adding DEFAULT_SDU_SIZE to the SQLNET.ORA file, now means SDU can be set on a per connection basis. See Note 44694.1 SQL*Net Packet Sizes (SDU & TDU Parameters)

 

 

 

 

Do you want to learn Oracle Database for Beginners, then read the following articles.

Oracle Tutorial | Oracle Database Tutorials for Beginners ( Junior Oracle DBA )