Select language:

Function documentation DB Reconnect to the Same Database Instance 

Use

This section discusses how you can use

DB reconnect to reconnect to the same database instance.

Features

The following methods can be used to reconnect to the same database instance:

  • Reconnect with restart of the work process

This is the method used if the SAP internal reconnect mechanism is switched off using the profile parameter

rsdb/reco_trials .

A work process running with an error condition is restarted. This includes a rollback of the SAP logical unit of work (LUW) and a reconnect to the database. If the restart fails, the process terminates. You then have the following options to restart the process:

    • If the application server is still running (that is, if the dispatcher, at least one dialog work process, and the SAP buffers are still available), you can use transaction
sm51 to perform a "restart after error."
  • You can restart the application server. A restart of the application server means that all SAP buffers on the affected application server are lost.
  • This type of reconnect is not discussed further in this documentation.

    • Reconnect without restart of the work process

    The following diagram illustrates this situation (the work process shown is a dialog process but it might equally well be another kind of process):

    DB Reconnect to Same Instance

    This graphic is explained in the accompanying text

    The reconnect is initiated if a request sent to the database by a work process returns one of the database errors included in the RECONNECT error group. The subsequent processing depends on the type of work process that sent the request.

    The advantage of the reconnect without restart of the work process is that it does not require manual intervention. This means that you should never have to restart the whole application server. The application server buffers (that is, the table buffers) are never lost, as would happen during a full server restart. This type of reconnect is also useful if the database was shut down for maintenance or offline backups. Once the database is back up the work processes automatically reconnect.

    For this reconnect feature to be active certain parameters have to be set in the application server profile. For more information, see

    DB Reconnect Parameters.

    The following diagram summarizes the reconnect process:

    DB Reconnect: Schematic Flow

    This graphic is explained in the accompanying text

    Activities

    A work process with a connection problem is changed to "reconnect state," the current SAP LUW is rolled back and the process tries to reconnect. The next steps depend on the type of work process:

    • Dialog work process
      • Foreground request

    The scenario is that user activity generated a synchronous database request (that is, select, insert, modify, delete) that was not successful. The read is rolled back and the dialog process tries to reconnect as follows:

        • Successful reconnect

    The user receives an "ABAP run-time error" or an error message in the status line of the session screen. The user has to acknowledge the error message. The transaction (LUW) is rolled back and the session returns to the screen from which the aborted transaction was started. The user can now re-run the transaction.

        • Unsuccessful reconnect

    The user’s session screen disappears and a dialog box appears with the message that this session has lost its database connection. The dialog box disappears once it has been acknowledged.

    The dialog process that handles the user session screens stays in "reconnect state". Every time a request is passed to the dialog process requiring a database access, it tries to reconnect to the database (for example, if the user repeats the transaction that generated the database request in the first place).

    From the dispatcher’s point of view, dialog work processes in reconnect state are no different from other dialog work processes. If a frontend issues a request, the dispatcher might route the request to a dialog work process in reconnect state. This request then causes the next reconnect attempt.

      • Update request with asynchronous update

    The scenario is that changes have been posted to the database. Asynchronous updates are written by the dialog process to an update queue. An update process reads it from there and applies the changes to the actual database tables. The update queue is implemented as a cluster table (that is,

    VBLOG ) in SAP Release 2.x, and as three transparent tables (that is, VBHDR , VBMOD and VBDATA ) in SAP Release 3.x and 4.x. We use the term VBLOG in the reminder of this section for either implementation of the update queue.

    If the user transaction consists of a sequence of several screens, several data records will have been written to

    VBLOG . At commit time, a header record is written to VBLOG to complete the information for this change. The set of individual update entries and the single header entry forms one complete update record. The update process applies complete update records only. If a connection error occurred, update entries might have been written, but some update entries or the header entry are still missing. The dialog work process tries to write the missing entries but is not successful. The dialog work process then attempts to reconnect as follows:
        • Successful reconnect

    Processing is the same as described above for "Foreground Request – Successful Reconnect." That is, the user has to re-run the transaction that was aborted and enter all the data again.

        • Unsuccessful reconnect

    Processing is the same as described above for "Foreground Request – Unsuccessful Reconnect."

    • Update work process
      • Read request

    The scenario is that an update process wants to read an update record out of the VBLOG, but the read fails due to a database error. The update work process then attempts to reconnect as follows:

        • Successful reconnect

    The update process tries to read the record again. If other update processes are still connected they might also try to read the record and apply it.

        • Unsuccessful reconnect

    The update process continuously tries to reconnect and apply records that have not been processed yet.

      • Change request

    The scenario is that an update process has read an update record and wants to apply it to the actual database tables. The actual update cannot be executed due to a lost connection. The status of this update is "terminated" and the enqueue is released.

    If another update process is available, that process is posted to execute the error handling of the terminated update. This process sends an express mail to the user with the message that the update did not complete successfully.

    If no other update process is available, the error handling is put in the request queue of the "original" update process.

    The next step is the same for a successful as for an unsuccessful reconnect. The update is not repeated automatically and the locks are released. The user has to execute the terminated update again using transaction

    sm13 , if the application context allows to "redo" an update later. If the application context does not allow simply executing an update again, the user has to manually enter the data again to generate new entries in VBLOG .
      • Error handling

    The scenario is that an update process wants to do the error handling for a terminated update (that is, send an express mail to the user), but this cannot be done due to a lost database connection. The subsequent processing is independent of whether the reconnect is successful or unsuccessful.

    No express mail is sent. The terminated update is shown in transaction

    sm13 .
    • Batch work process

    Independent of the outcome of the reconnect, the batch job is terminated. The user then has to restart the batch job, assuming that the application context allows for this.

    • Spool work process

    The spool work process handles user requests to print data. The location of the data to be printed is configurable. It can reside in a table in the database or in external files at the operating system level. In both cases, access to the database is required to process the data.

    If a database request for a spool work process fails (that is, either the read of data to be printed or the write of spool administration data), then the spool request is aborted and the user has to start the spool request again. However, the data to be printed is not lost. The spool work process periodically checks for open spool requests.