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 188.8.131.52)
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 184.108.40.206 . 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:
(ADDRESS = (PROTOCOL = TCP)(HOST = <hostname>)(PORT = 1521))
(SDU = 1024)
(SID_NAME = <instance_name>)
If using shared server processes, set the SDU size in the DISPATCHERS parameter as follows:
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)
452 views last month, 3 views today