You are on page 1of 4

SAP Note


  98051 - Database Reconnect: Architecture and function
Version   8     Validity: 22.04.2008 - active  


Language   English

Header Data
Released On 22.04.2008 20:25:32
Release Status Released for Customer
BC-DB-DBI DB Independent Database Interface
Recommendations / Additional Info
Help for error analysis

This note describes the database reconnect mechanism and provides an overview of its functions. This
note does not deal with technical details, such as profile parameter settings or release
dependencies. Note 24806 in particular covers a great deal of these technical details and informs
you of the latest technical reference.

Other Terms
Reconnect, switch over, high availability, offline backup

Reason and Prerequisites
1) Introduction
2) What are the prerequisites for the reconnect mechanism?
3) Functions
4) Profile parameters
5) Restrictions
6) Offline backup
7) Switch over
8) Problem analysis
9) FAQ (Frequently asked questions)
1. Introduction
Every ABAP dialog, batch, update and spool work process sets up its own (private) connection to
the database at the start. If this database connection is interrupted, the work process attempts
to set up a new connection. This process is called "database reconnect".
The advantage offered by the database reconnect without restarting the work process is that a
work process survives, even if reconnecting to the database is unsuccessful. The work process
remains in a special status (reconnect status) in which it always attempts to set up the
database connection again whenever a request is made to the database, for example, the request
from a user who calls a new transaction.
2. What are the prerequisites for the reconnect mechanism?
The reconnect mechanism is activated by default by rsdb/reco_trials > 0 for all kernel releases
as of 3.0D. For details about from which release which default is set, see Note 24806.
The work process uses the database error codes to recognize a situation which requires the
database connection to be set up again. In this case, the work process must analyze whether the
error is a "normal" SQL error or whether the error code signifies a collapsed connection (there
may be connection problems to the database, such as network instability or the function of the
database itself is impaired). The reconnect-relevant return codes are, on the one hand,
predefined in the kernels, and on the other hand, they can be dynamically enabled and
deactivated. If a return code is neither in the static nor in the dymamic reconnect list, no
reconnect occurs. The dynamic list is determined by the profile parameter
rsdb/reco_add_error_codes. Note 24806 provides information about which return codes fall into
the reconnect class (release-dependent). Note 41678 describes the profile parameter
3. Functions
a) The reconnect scenario is triggered by the breakdown of the database when the R/3 System
is in operation. Those work processes that already started an R/3 transaction before the
database breakdown receive a database (SQL) error.
b) To keep the R/3 System in a consistent status, a rollback is carried out within R/3 and
on the database in which the cancelled transaction is reset. This is also mostly documented
in a short dump. If the work process finds the return code in the reconnect class, the
system first stores a message of the following structure in the developer trace dev_w*:
B ***LOG BYM=> severe db error 12571    work process is in the reconnect state [dbsh    
A similar message (with BYM) is then entered in the SYSLOG.
c) After the R/3 rollback, the work process attempts several times to set up the database
connection again. Here, the profile parameters rsdb/reco_trials and rsdb/reco_sleep_time
determine the number of attempts and the pauses in between. In the case of short-term
problems (for example, when the network or database capacity is overloaded), the work
process will be able to set up the connection again when the appropriate settings are made.

Offline backup For an off-line backup. With the exception of cleaning up (rollback) in R/3 and in the database. 5. Oracle Parallel Server). the user involved receives the following dialog box: "Connection to database lost. e) The name of the reconnect host must differ from the primary host name. uncritical and repetitive database accesses determine the missing database connection. the system informs all work processes of the application server about the database problem. Note: The work process does not end but is ready to receive the next user request. a reconnect is not carried out for all the other connections. The informed WPs write the following messages in their developer traces: B  ***LOG BV4=> reconnect state is set for the work process f) From there on. they attempt to set up the database connection again before they start processing the request. At present. 6. for whatever reason. 7.               You should therefore change reconnect profile parameters only for well-founded reasons. Through the database reconnect without restarting the work processes. from the viewpoint of R/3.0D) ensure correct reconnect behavior for all databases supported. After the attempts determined in rsdb/reco_trials. This should not be misinterpreted as a malfunction. you want to restart a work process in productive operation.  If the database is not available. the futile reconnect attempts have the following effect: M  *** ERROR => ThHdlReconnect: db_reconnect failed (-1) [thxxhead 1304] g) If the database (connection) is available again. in transaction SM50). In the developer trace. it is highly probable that internal. 4. session terminated". which will . the work process stops. Restrictions a) At the start or restart of a work process. As a result. Whenever they are assigned a new user request in this status.  It is not in reconnect status and you must manually restart it once you can access the database again (for example. Switch over Switch over or high availability database solutions require a second database host. e) In addition. Use the 31H kernel patch level 84 or higher (Note 92412) if you want to perform offline backups when R/3 is in operation. the application server work processes reconnect themselves on request again to the database. The buffer contents of the R/3 system are retained on the application server. it carries out an initial connection setup. Note 24874 addresses this topic. c) The reconnect mechanism is implemented in the database interface. However. You must implement these actions manually or using a corresponding application logic. This is documented in the developer trace: B  ***LOG BYY=> work process left reconnect state [dblnk    1467] An equivalent message also appears in the SYSLOG. NO reconnect occurs but an initial connection setup does occur. the reconnect attempt is also successful and the above-mentioned loop is broken. However. you must note that. an offline backup of the database when the R/3 System is in productive operation represents the same "disruption" as an unplanned nonavailability of the database. yet to be filled buffers) after you restart the application server. no further steps are triggerred during a connection termination. the reconnect of this work process and the respective message also only occur at this later time. If the system load is very low and a work process edits a user request hours after the database loss. the user receives the dialog box "Connection to database lost. that is. Exception: a) The database error code is not within the reconnect class and must be supplemented with the profile parameter rsdb/reco_add_error_codes (Notes 24806 and 41678) b) You are using a parallel database (for example. the system performs a reconnect only for the default connections set up automatically at the start of the work process. The user's session is terminated with this message. and check that the following parameters are set to their (default) value: rsdb/reco_sosw_for_db = OFF (important!) rsdb/reco_trials      = 3 rsdb/reco_sleep_time  = 5 You should also choose the setting rsdb/reco_sosw_for_db=OFF together with a high availability solution for this offline backup variant (when R/3 is in use). the WP stops. This therefore does not affect any high priority processes. you do not have to shut down the application servers. h) A work process can restore only one database connection and write a SYSLOG or developer trace message when it executes a request. d) If a work process sets up several database connections to databases that may be different (multiconnect). after the database is opened again. The database interface therefore cannot determine whether you should/must reschedule a batch job or whether you must repeat an update. b) If. session terminated" and the user's session terminates. there is no loss in performance (due to the empty. the WP remains in the reconnect status and waits for the next request. If an initial connection setup is unsuccessful after three attempts. Profile parameters The default values of the profile parameters should (as of Kernel Release 3.d) If the connection setup fails. all work processes are in the reconnect status. However. if you perform the offline backup when R/3 activity is at its lowest.

The developers traces may also enable such an interpretation. Problem analysis Reconnect scenarios should basically run as described above. In particular.) should appear in the dev_w* developer traces. It is most likely that you will find the background and cause of the errors only with SAP Support. even though the database (connection) is available again? Using another tool (for example. 103754   Database Reconnect: Information strategy of WPs 92412   Reconnect after offline backup 81499   No reconnect after offline backup 65663   Batch/Spool: Database reconnect problem in 30E/30F 41678   Database reconnect: Additive error return codes 34703   3.51 Service Pack 4      R/3 3. FAQ (Frequently asked questions) Other Attributes Transaction codes HIER SM50 Validity This document is not restricted to a software component or software component version References This document refers to: SAP Notes 1633292   Suspending security session cleanup during offline backups 864267   Code page conversion error after WP has left reconnect state 592393   FAQ: Oracle 459268   Database reconnect: EXEC SQL and work process messages 437362   Composite note ORA-12500 393768   DB2/390: VIPA exploitation is supported. no longer returns.3. 8. This means that the subroutine call of the database library. ensure that you describe the error scenario as accurately as possible.0F     Kernel 3. try to determine whether important connect information is perhaps not accessible (anymore) (for example. If problems occur.replace the primary database host if this fails (IP address switch over). communication software and operating system: An SQL statement or a connect call up that was issued by the work process hangs. the work process is unable to break out of this status and must eventually be terminated.. c) One or all work processes hang: If problems occur or also when the database shuts down. In this situation. you may find that the following situation arises in the interaction of database software.1G Version 84 DB:  SQL*NET V2    without additional patches      Oracle 7. A high availability solution does not require you to change the profile parameters. You can use the profile parameter rsdb/reco_add_error_codes (Note 41678) to correct this.. you must describe your configuration in this case as accurately as possible. Is there a core file in the "work" directory? This may contain information about the cause of the process termination. It is therefore important to find the reason for the restart. the case that is described in the section 'Restrictions' occurs and no reconnect occurs. which should trigger the corresponding action. The flow of operation for the default setting of the parameter is described in the "Functions" section with the exception that the standby host is active when the work processes set up the connection again. One cause may be the fact that the database return code does not (yet) belong to the reconnect class (Note 24806). the entries described in the FUNCTIONS section (B ***LOG BYM=> . a configuration file). For example: HW:  COMPAQ OS  :  NT 3. R3trans -d). Can the work process restore the database connection after restart (for example. So that SAP and the database manufacturer can process the error. You should pay particular attention to the following points: a) The work process fails to set up the reconnect time and time again. You can use the R/3 tool dpmon to track down signs for this. If you contact SAP concerning your problem. using transaction SM50)? b) The affected work process was (automatically) restarted: This can be seen in the developer traces and SYSLOG. despite the fact that the database (connection) is working: Does the system continue to write entries concerning the unsuccessful reconnect attempts to the developers trace files of the affected work processes. it is useful to analyze the trace files.0: Offline Backup with R/3 System running .3  without additional patches 9. When you restart.

0: Offline Backup with R/3 System running 41678   Database reconnect: Additive error return codes . hang in Reconnect 24874   Database Reconnect for Oracle parallel server 24806   Database Reconnect: technical details and settings This document is referenced by: SAP Notes (16) 592393   FAQ: Oracle 864267   Code page conversion error after WP has left reconnect state 1633292   Suspending security session cleanup during offline backups 459268   Database reconnect: EXEC SQL and work process messages 437362   Composite note ORA-12500 393768   DB2/390: VIPA exploitation is supported. hang in Reconnect 29849   30A.29849   30A. 65663   Batch/Spool: Database reconnect problem in 30E/30F 81499   No reconnect after offline backup 92412   Reconnect after offline backup 103754   Database Reconnect: Information strategy of WPs 24806   Database Reconnect: technical details and settings 24874   Database Reconnect for Oracle parallel server 26455   NT 3. 30B: sql error 0 performing CON 26455   NT 3. 30B: sql error 0 performing CON 34703   3.51 Oracle: Work procs.51 Oracle: Work procs.