Ansicht
Dokumentation

Datenbank Reconnect ( RELNBC_DB_30A_RECONNECT )

General Material Data   ROGBILLS - Synchronize billing plans  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Kurztext

Datenbank Reconnect

Beschreibung

Mit Release 3.0A besteht die Möglichkeit, eine DB-Reconnect- Funktionalität der Workprozesse zu aktivieren, bei der die Workprozesse überleben und nicht wie bisher gestoppt und neu gestartet werden.

Der DB-Reconnect wird versucht, wenn ein Workprozeß einen Error-Return-Code einer bestimmten Klasse von der Datenbank erhalten hat. Eine DB-Reconnect-Funktionalität, bei der ein Workprozeß überlebt, wird momentan nur für das Datenbanksystem ORACLE unterstützt. Diese DB-Reconnect-Funktionalität wird über das Setzen des Parameters rsdb/reco_trials im R/3-Profile aktiviert. Ist der Parameter rsdb/reco_trials nicht gesetzt, so wird wie bisher ein Reconnect zur Datenbank über einen Neustart des Workprozesses versucht. Mit welchem Wert der Parameter rsdb/reco_trials im Profile definiert werden sollte, wird weiter unten im Abschnitt "Änderungen in der Systemadministration" beschrieben.

Bei dem bisherigen Reconnect über Neustart des Workprozesses wird der Workprozeß beendet, falls er sich beim erneuten Start nicht erfolgreich an die Datenbank konnektieren kann. Der Vorteil des neuen DB-Reconnects liegt darin, daß ein Workprozeß überlebt, auch wenn der Reconnect zur Datenbank nicht erfolgreich ist. Der Workprozeß verbleibt in einem speziellen Status (Reconnect-Status), in dem er bei einem Request an die Datenbank (z.B. der Request eines Users, der eine Transaktion aufruft) immer wieder versucht, sich an die Datenbank zu rekonnektieren.

Der neue DB-Reconnect kann bei einer Offline Sicherung oder bei einer High Availability Lösung eingesetzt werden.

• Offline Sicherung

Für eine Offline Sicherung müssen die Applikationsserver nicht notwendigerweise heruntergefahren werden. Ist die neue DB-Reconnect- Funktionalität aktiviert, so rekonnektieren sich die Workprozesse der Applikationsserver, nachdem die Datenbank wieder geöffnet ist, auf Request wieder an die Datenbank. Die Puffer des R/3-Systems auf Applikationsserver-Seite bleiben so erhalten, wodurch eine Performance-Einbuße (wegen leeren noch nicht gefüllten Puffern) nach einem erneuten Hochfahren der Applikationsserver vermieden wird.

• High Availability Lösung

Wird der Datenbank-Service im Rahmen einer High Availability Lösung (z.B ein Zwei-Knoten-Cluster mit einem Primary- und einem Standby-Datenbank-Server) ausfallsicher aufgebaut, so rekonnektieren sich die Workprozesse im Falle eines kurzfristigen Ausfalles des Datenbank-Service über den neuen DB-Reconnect wieder an die Datenbank. Bei einer High Availability Lösung kann unter Verwendung einer IP-Adress-Switch-Over-Software der Datenbank-Service, wenn er auf einem Primary-Server ausgefallen ist, auf einem Standby-Server neu gestartet werden. Dieser Standby-Server ist nach einem IP-Adress-Switch-Over über die gleiche IP-Adresse wie der bisherige Primary-Server erreichbar.

Einfluß auf den Datenbestand im Fehlerfall

Soft-/Hardwarevoraussetzungen

Besonderheiten bei der Installation

Auswirkungen auf die Systemverwaltung

• Die neue DB-Reconnect-Funktionalität kann über die Einstellung des folgenden Parameters im R/3-Profile aktiviert werden:

rsdb/reco_trials =0 : Datenbank-Reconnect ausgeschaltet (Default).
rsdb/reco_trials =n (>0): Im Reconnect-Fall werden maximal n Reconnect-
Versuche unternommen. Ist der Reconnect nach
dem n-ten Versuch nicht erfolgreich, so wird
der Modus des Users, dessen Benutzerkontext
vom WP bearbeitet wird, abgebrochen.

• Empfehlung für die Einstellung von rsdb/reco_trials für die Nutzung des neuen Datenbank Reconnects bei einer Offline Sicherung:

rsdb/reco_trials =3

• Empfehlung für die Einstellung von rsdb/reco_trials für die Nutzung des neuen DB-Reconnects im Zusammenhang mit einer High Availability Lösung:

rsdb/reco_trials =10

In Abhängigkeit von der Zeit, die im Falle eines Failovers des Datenbank-Service benötigt wird, bis der Datenbank-Service wieder vorhanden ist, kann auch ein Wert größer als 10 gewählt werden. Außerdem kann zusätzlich der Parameter rsdb/reco_sleep_time eingestellt werden. Dieser Parameter legt die Zeit fest, die ein Workprozeß zwischen dem i-ten und (i+1)-ten Reconnect-Versuch schläft. Wird der Parameter rsdb/reco_sleep_time im R/3-Profile mit dem positiven ganzen Wert m definiert (rsdb/reco_sleep_time =m), so beträgt diese Zeit (i*m) Sekunden.

• Default-Werte fuer die Parameter:

rsdb/reco_trials =0 und rsdb/reco_sleep_time =5

Auswirkungen auf das Customizing

Auswirkungen auf Batch-Input

Änderungen an der Oberfläche

Änderungen in der Vorgehensweise

Aktionen zum Beheben von Fehlern am Datenbestand

Abhängige Funktionen

Planungen

Weitere Hinweise

rdisp/max_wprun_time - Maximum work process run time   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 5928 Date: 20240523 Time: 165830     sap01-206 ( 141 ms )