SAP Note 24806 - Database Reconnect: technical details and settings

Symptom:

This note describes the technical details such as profile parameter settings or release dependencies of the database reconnect. For a general overview of the reconnect mechanism functions see Note 98051.

Cause and prerequisites

New development in Release 2.2F and 3.0A

Solution

Contents
--------

1. DATABASE RETURN CODES OF THE "RECONNECT" CLASS

2. R/3 PROFILE PARAMETERS

3. SPECIAL APPLICATIONS OF THE DB RECONNECT

1. DATABASE RETURN CODES OF THE "RECONNECT" CLASS
After a database error of a special class "RECONNECT", the work process is not stopped and restarted, rather it attempts to reconnect to the database without restarting.
In releases up to and including 3.0C the DB reconnect must be activated without a restart of the work process by setting the R/3 profile parameter rsdb/reco_trials. As of kernel Release 3.0D this parameter is set as a default (see section on R/3 Profile Parameters).

Error return codes of the "RECONNECT" class

a) for ORACLE:
ORA1001, ORA1012, ORA1034, ORA1089, ORA1092, ORA2725, ORA3106, ORA3113, ORA3114.
As of R/3 Release 3.1I or 4.0B the following errors are also included in the "RECONNECT" class:
ORA1014, ORA1090, ORA1033, ORA12500, ORA12570, ORA12571.

b) for Informix Online:
INF60, INF78, INF258, INF259, INF285, INF459, INF25580, INF25582, INF25586, INF25587, INF25588, INF27002.

c) for ADABAS D:
ADA700, ADA807, ADA1001, ADA1089, ADA3113, ADA3114, ADA2725. ADA8000, ADA8106.

d) for DB2 on AIX:
DB2 08001, DB2 08002, DB2 08003, DB2 08004, DB2 08007, DB2 40003.

e) for DB2/390:
ICLI send and receive problems, Sqlcode -923, -924
ICLI keep alive should be switched on, see "SAP R/3 on DB2 for OS/390: Planning Guide")

2. R/3 PROFILE PARAMETERS

a) rsdb/reco_trials
Meaning: it activates the DB reconnect without a restart of the
work process.

rsdb/reco_trials =0 DB reconnect is not active.
rsdb/reco_trials =n n reconnect attempts for DB errors of the
reconnect class
The default for Releases <=3.0C is 0 and >=3.0D is 3.
If the DB reconnect is not used for a "High Availibility Solution", the default for rsdb/reco_trials should not be changed. Even if the n reconnect attempts do not succeed, the work process remains in the reconnect status and makes n reconnect attempts again in the next request (Note 98051).

b) rsdb/reco_sleep_time
Meaning: the time between each reconnect attempt
rsdb/reco_sleep_time = m (m: seconds, default: 5)
In the releases up to and including 3.0C the waiting time between two reconnect attempts is multiplied by the loop counter, that means that there is a waiting time of i*m seconds between the ith and (i+1)th reconnect attempt.

c) rsdb/reco_add_error_codes
Meaning: this parameter determines which database return code should be added to the reconnect class or removed from this class. The syntax is described in Note 41678.

3. SPECIAL APPLICATIONS OF THE DB RECONNECT

a) Offline database backup
For a general description of the offline database backup without shutting down the R/3 System see Note 98051.
This form of offline database backup should only be used as of Releases 2.2G and 3.0D (on NT and SUN as of 3.0E). See Note 34703.
In Release 2.2 (2.2G up to 2.2Z) you must make sure that every work process contains a database error and that it then reconnects after the database is rebooted, if a database request has been assigned to it. In Release 3.0 (3.0D up to 3.0Z) the DB reconnect is attempted before the the request is assigned and if it is successful, the work process does not contain a database error.

b) High Availibity Solution
If the database service is set up securely in a high availability solution (for example a two node cluster with a primary and standby database server), the work processes reconnect themselves to the database following a short-term loss of the database service via the new database reconnect. In a high availability solution, if the database service fails on a primary server, it can, by using IP address switch over software, be restarted on a standby server. This standby server can be reached after an IP address switch over using the same IP address (a logical IP address) as the previous primary server.

When testing this application option with the Oracle database, the following problem was observed: if it involved a "hard" service interruption (for example, a "system panic") of the primary database server and if the system was heavily loaded at the time (several users, several work processes with database requests), some of the work processes "stopped" and did not reconnect themselves. The stopped work processes are still waiting for an answer from the database server. The client still regards the work process' connection to the Oracle Listener Process as open, even though the primary database server encountered a "system panic" and a connection can no longer exist. The problem lies at SQL*NET V1 and TCP/IP level. The TCP/IP configuration must be modified in this case.

If the database service is set up securely with switch over software (-> high availability solution) during the installation, the reconnect default values of the reconnect profile parameters do not have to be changed. Especially the profile parameters rsdb/reco_sosw_for_db should no longer be used. We recommend that you additionally carry out a kernel upgrade to 3.1I for 3.0 and 3.1 systems (Note 102445).