From Release 3.0A it is possible to activate a DB reconnect functionality for work processes where the work processes remain unaffected and are not stopped and restarted as previously.
The system attempts to perform a DB reconnect when a work process has received an error return code of a specific class from the database. A DB reconnect functionality where a work process remains unaffected is currently supported only for the ORACLE database system. This DB Reconnect functionality is activated by setting the parameter rsdb/reco_trials in the R/3 profile. If the parameter rsdb/reco_trials is not set, the system tries to perform a database reconnect by restarting the work process. The section "Changes in system administration explains with which value the parameter rsdb/reco_trials should be defined in the profile.
When the reconnect is performed by restarting the work process, the work process is terminated when it is unable to reconnect to the database after the restart. The advantage of the new DB reconnect is that a work process "survives" even if the database reconnect is not successful. The work process remains in a special status (reconnect status). When a request is submitted to the database (for example, a user calls up a transaction), the work process will repeatedly try to reconnect to the database.
The new DB reconnect can be used in connection with offline backups or a high availability solution.
For an offline backup the application servers do not need to be shut down. If the new DB reconnect functionality is activated, the work processes of the application servers reconnect to the database on request after the database has been opened again. The buffers of the R/3 System on the application servers are thus retained. Performance is thus not impaired after the application servers are restarted.
If the database service is set up within a high availability solution (e.g., a two-node cluster with a primary and standby database server, the work processes will reconnect to the database when the database service fails for a short period of time. With a high availability solution, the database service can be restarted on a stand-by server when it fails on the primary server using an IP address switch-over software. After an IP address switchover, this standby server can be reached under the same IP address as the previous primary server.
rsdb/reco_trials =0 : Database reconnect deactivated (default).
rsdb/reco_trials =n (>0): A maximum of n reconnect attempts is
performed. If the reconnect is not
successful after the n-th attempt, the
mode of the user whose request is handled
by the WP is terminated.
rsdb/reco_trials =3
rsdb/reco_trials =10
Depending on the time required until the database service is available again after a failure, a value larger than 10 can be chosen. In addition, the parameter rsdb/reco_sleep_time can be set. This parameter defines the time interval for which a work process "sleeps" during the i-th and (i+1)-th reconnect attempt. If the parameter rsdb/reco_sleep_time is defined in the R/3 profile with the positive integer value m (rsdb/reco_sleep_time =m), this time is (i*m) seconds.
rsdb/reco_trials =0 and rsdb/reco_sleep_time =5