Max. DB-writes pro Sekunde?
3 Beiträge
•
Seite 1 von 1
3 Beiträge
Seite 1 von 1
Hallo zusammen,
folgende Situation:
Ich habe ein API deren Aufrufe in einer DB-Tabelle für 30 Tage geloggt werden müssen. D.h. jedes Mal, wenn die API von jemandem aufgerufen wird, wird ein DB-Eintrag erzeugt. Das Problem ist jetzt, dass diese API zum Beginn jeder Stunde von einem Batch-Job ca. 10.000 Mal aufgerufen wird. Sowie vereinzelt von anderen Verwendern an nicht vorhersehbaren Zeitpunkten.
Aus Gründen der Datenintegrität darf das Logging nicht an die Aufrufer der API delegiert werden, womit es (glaube ich) unmöglich wird, die Einträge erst in einer internen Tabelle zu sammeln und dann auf einmal in die DB-Tabelle zu schreiben. Aktuell bedeutet das, dass ich stündlich 10.000 „modify“ + „commit work“ habe.
An den Randbedingungen kann ich leider nichts ändern, weshalb ich zwei Fragen habe:
1. Wie viele einzelne DB-writes kann ich denn pro Sekunde sinnvoll tolerieren?
2. Gibt es eine Möglichkeit die DB-Writes irgendwie zu puffern bevor ich sie auf die DB schreibe (shared momory oder so)?
Danke und Gruß
Corn
folgende Situation:
Ich habe ein API deren Aufrufe in einer DB-Tabelle für 30 Tage geloggt werden müssen. D.h. jedes Mal, wenn die API von jemandem aufgerufen wird, wird ein DB-Eintrag erzeugt. Das Problem ist jetzt, dass diese API zum Beginn jeder Stunde von einem Batch-Job ca. 10.000 Mal aufgerufen wird. Sowie vereinzelt von anderen Verwendern an nicht vorhersehbaren Zeitpunkten.
Aus Gründen der Datenintegrität darf das Logging nicht an die Aufrufer der API delegiert werden, womit es (glaube ich) unmöglich wird, die Einträge erst in einer internen Tabelle zu sammeln und dann auf einmal in die DB-Tabelle zu schreiben. Aktuell bedeutet das, dass ich stündlich 10.000 „modify“ + „commit work“ habe.
An den Randbedingungen kann ich leider nichts ändern, weshalb ich zwei Fragen habe:
1. Wie viele einzelne DB-writes kann ich denn pro Sekunde sinnvoll tolerieren?
2. Gibt es eine Möglichkeit die DB-Writes irgendwie zu puffern bevor ich sie auf die DB schreibe (shared momory oder so)?
Danke und Gruß
Corn
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4330 / 214 /
1156
)
»
Werden diese 10.000 Aufrufe innerhalb der selben LUW (gleicher User/gleiches Programm) erzeugt oder sind das mehrere Jobläufe zusammengenommen?
Wenn du das versuchst zu "sammeln" läufst du im Fehlerfall meist erst recht in ein Problem mit der Datenintegrität. Daher wäre es besser das ganze so "rasch" als möglich aus dem Speicher des Appl.Server zu haben.
Die SAP bietet hier mit dem BAL (Basic Application Logging) eigentlich bereits ein recht brauchbares Framework das man dafür nutzen kann. Zum einen ist es mittels RFC-Aufruf von der Programmlogik entkoppelt. Im Fehlerfall oder bei einem Commit/Rollback im Hauptprogramm geht damit nichts verloren. Zum anderen hat man die Wahl die Daten SOFORT auf die Datenbank zu speichern oder in einer Puffer-Tabelle zwischenzulagern um sie im Nachgang mit einen asynchronen Job in die eigentliche Logging Tabelle zu schreiben. Die geloggten Daten werden zudem noch "komprimiert" abgelegt um den DB-Platz möglichst effizient zu nutzen.
Was die 10.000 "modify" und "commit" angeht, sollte das die Datenbank eigentlich problemlos wegsteckent können. Wie "schwach" ist deine Hardware denn ausgelegt?
Wenn du das versuchst zu "sammeln" läufst du im Fehlerfall meist erst recht in ein Problem mit der Datenintegrität. Daher wäre es besser das ganze so "rasch" als möglich aus dem Speicher des Appl.Server zu haben.
Die SAP bietet hier mit dem BAL (Basic Application Logging) eigentlich bereits ein recht brauchbares Framework das man dafür nutzen kann. Zum einen ist es mittels RFC-Aufruf von der Programmlogik entkoppelt. Im Fehlerfall oder bei einem Commit/Rollback im Hauptprogramm geht damit nichts verloren. Zum anderen hat man die Wahl die Daten SOFORT auf die Datenbank zu speichern oder in einer Puffer-Tabelle zwischenzulagern um sie im Nachgang mit einen asynchronen Job in die eigentliche Logging Tabelle zu schreiben. Die geloggten Daten werden zudem noch "komprimiert" abgelegt um den DB-Platz möglichst effizient zu nutzen.
Was die 10.000 "modify" und "commit" angeht, sollte das die Datenbank eigentlich problemlos wegsteckent können. Wie "schwach" ist deine Hardware denn ausgelegt?
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Die 10k Aufrufe kommen alle von einem Job (gleiches Programm). Die Hardware ist eigentlich nicht schwach ausgelegt... ich habe nur ein "schlechtes" Gefühl, bei solchen Brute Force Writes^^ Man bekommt ja immer beigebracht, möglichst wenige DB Zugriffe zu haben.
BAL gucke ich mir mal an, danke!
BAL gucke ich mir mal an, danke!
Seite 1 von 1
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.