Ansicht
Dokumentation

ABENBUFFER_SYNCHRO - BUFFER SYNCHRO

PERFORM Short Reference   CPI1466 during Backup  
Diese Dokumentation steht unter dem Copyright der SAP AG.

- Puffersynchronisation

Invalidierung und Aktualisierung

Eine gepufferte Tabelle oder View kommt in der Regel in den Tabellenpuffern jeder vor. Ändert ein Programm in einer der Daten einer Tabelle über , werden diese wie folgt aktualisiert:

• Die Daten werden in der Datenbanktabelle auf der Datenbank geändert.

• Der Puffer der aktuellen wird direkt invalidiert.

• Bei Änderungen über Arbeitsbereiche wird bei Tabellen mit Einzelsatzpufferung die betroffene Zeile invalidiert, bei generisch gepufferten Tabellen der betroffene generische Bereich invalidiert, bei vollständig gepufferten Tabellen die ganze Tabelle invalidiert.

• Bei Änderungen über UPDATE ... SET ... WHERE ... oder DELETE ... WHERE ... wird bei Tabellen mit Einzelsatzpufferung und vollständiger Pufferung die ganze Tabelle invalidiert. Bei generisch gepufferten Tabellen werden alle generischen Bereiche invalidiert, die von einem angegeben linksbündigen generischen Teilschlüssel getroffen werden.

• Bei gepufferten DDIC-Datenbank-Views oder CDS-Views wird unabhängig von der Pufferungsart der gesamte Puffer invalidiert. Bei mandantenabhängigen Views betrifft dies aber nur die Inhalte des aktuellen Mandanten.

• Die invalidierten Daten werden in die Protokolltabelle DDLOG der Datenbankschnittstelle geschrieben.

• Solange für eine Änderung an einer gepufferten Tabelle noch kein Datenbank-Commit erfolgt ist, greifen alle Lesezugriffe in der , in der die Änderung erfolgt ist, am Puffer vorbei direkt auf die Datenbank zu. Nach einem Datenbank-Commit gilt für Lesezugriffe in dieser :

• Im Fall der Einzelsatzpufferung und einer Änderung, die nur einen einzelnen Satz einer solchen Tabelle betrifft, wird der Puffer direkt bei einem Lesezugriff aktualisiert.

• Im Fall von generisch und vollständig gepufferten Tabellen lesen standarmäßig noch 5 Zugriffe am Puffer vorbei direkt von der Datenbank. Der Wert ist im Profilparameter zcsa/inval_reload_c festgelegt. Danach wird der Puffer bei einem Lesezugriff mit den Daten aus der Datenbank aktualisiert.

• In allen anderen haben die Puffer noch den alten Stand. Lesezugriffe erfolgen weiterhin über den Puffer und greifen damit unter Umständen auf veraltete Daten zu. Die Puffersynchronisation dieser erfolgt über folgendes asynchrones Verfahren:

• In einem bestimmten Zeitintervall von standardmäßig 2 Minuten wird in jeder eine Synchronisation ausgeführt. Der Wert ist im Profilparameter rdisp/bufreftime festgelegt. Die Datenbankschnittstelle liest die Protokolltabelle DDLOG und invalidiert die Pufferinhalte auf die gleiche Weise wie in der , in der die ursprüngliche Änderung erfolgte.

• Nach der Synchronisation wird im Fall der Einzelsatzpufferung und bei einer Änderung, die nur einen einzelnen Satz betraf, der Puffer durch einen Lesezugriff aktualisiert. Im Fall von generisch und vollständig gepufferten Tabellen wird standardmäßig 5 Mal von der Datenbank gelesen, und erst danach erfolgt beim nächsten Lesezugriff die eigentliche Aktualisierung des Puffers. Der Wert ist im Profilparameter zcsa/sync_reload_c festgelegt.

Hinweise

• Die asynchrone Synchronisation hat gegenüber einem synchronen Verfahren, bei dem jede Änderung an den gepufferten Daten einer sofort allen anderen mitgeteilt wird, den Vorteil, die Netzlast des Systems gering zu halten. Der Nachteil der asynchronen Synchronisation gegenüber einem synchronen Verfahren besteht darin, dass die Daten während der Zeitspanne zwischen zwei Synchronisationen nicht aktuell sind.

• Das asynchrone Verfahren zur Puffersynchronisation hat Einfluss auf die Entscheidung, ob eine Datenbanktabelle gepuffert werden kann oder nicht. Tabellen, auf die häufig schreibend zugegriffen wird, sind nicht für die Pufferung geeignet, da die Tabellenpuffer dann zum einen oft inkonsistent wären und das System zum anderen ständig mit dem Invalidieren und Laden der Puffer beschäftigt wäre.

• Änderungen mit einer WHERE-Bedingung belasten die Pufferverwaltung der aktuellen erheblich mehr als Änderungen von Einzelzeilen.

• Bei vollständig gepufferten mandantenabhängigen Tabellen bzw. Views ist zu beachten, dass intern eine generische Pufferung mit der Mandantenspalte als generischem Schlüssel ausgeführt wird und dass deshalb eine Invalidierung des gesamten Puffers nur die Inhalte des aktuellen Mandanten betrifft.

• Bei Systemen mit nur einer ist es nicht notwendig, die Protokolltabelle DDLOG mit den Modifikationen der gepufferten Tabellen zu füllen und kann durch Setzen des Profilparameters rdisp/bufrefmode auf sendoff, exeauto abgeschaltet werden.

Verdrängung

Wenn der freie Speicherplatz im Puffer einen voreingestellten Wert unterschreitet oder die Zugriffsqualität zu schlecht ist, werden Daten aus dem Puffer verdrängt. Die Zugriffsqualität hängt von der Anzahl der Zugriffe ab, die direkt aus dem Puffer befriedigt werden können.

Ob eine Verdrängung notwendig ist, wird asynchron zu bestimmten Zeitpunkten überprüft, die dynamisch anhand der Zugriffe auf den Puffer bestimmt werden, wodurch die Zeit zwischen zwei Verdrängungen von der Auslastung des Puffers abhängt.

Verdrängt werden die Daten von Tabellen, auf die am seltensten zugegriffen wurde. Die Zugriffe auf eine Tabelle werden hierfür in Abhängigkeit vom Zeitpunkt, an dem sie erfolgten, verschieden gewichtet. Zugriffe, die weiter in der Vergangenheit liegen, werden geringer gewichtet als solche, die erst kurz vor dem Zeitpunkt der Verdrängung erfolgten. Dadurch können Tabellen, auf die nur zu einem bestimmten Zeitpunkt sehr häufig zugegriffen wird, die aber danach nicht mehr benutzt werden, nach einiger Zeit aus dem Puffer verdrängt werden.

Hinweis

Da die einzelnen generischen Bereiche von generisch gepufferten Tabellen wie eigenständige Tabellen behandelt werden, kann es sein, dass bestimmte generische Bereiche einer Tabelle verdrängt werden, während andere generische Bereiche der gleichen Tabelle im Puffer erhalten bleiben.

Puffer zurücksetzen

Über die Eingabe von /$TAB im Befehlsfeld der Systemfunktionsleiste im SAP GUI kann der Tabellenpuffer der aktuellen zurückgesetzt werden, in dem alle dort befindlichen Daten invalidiert werden.

Hinweis

Der Tabellenpuffer sollte nur dann zurück gesetzt werden, wenn Inkonsistenzen im Puffer entstanden sind. Das Füllen des Tabellenpuffers kann in großen Systemen lange dauern. Während dieser Zeit ist die Performance erheblich beeinträchtigt.

CL_GUI_FRONTEND_SERVICES - Frontend Services   CPI1466 during Backup  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 9338 Date: 20240606 Time: 090836     sap01-206 ( 157 ms )