Lock vor Insert oder Update
4 Beiträge
•
Seite 1 von 1
4 Beiträge
Seite 1 von 1
Hallo zusammen,
ich habe einen bestehenden Report geändert, der über einen Sklaven-Report viele Hintergrund-Jobs aufruft, die verschiedene Z-Tabellen mit einer Menge Daten befüllt (ca. 2 Mio. Datensätze insgesamt). Dieser Report (und sein Sklave, dr ja nur die Jobs startet) bzw. seine Jobs sind die einzigen, die diese Z-Tabellen verändern.
Jetzt kriege ich den Report von der Qualitätssicherung um die Ohren gehauen, weil vor den Änderungen in der Datenbank kein "Lock" durchgeführt wird.
Das Tabellensperren wollte ich nach einem Beispiel aus diesem Forum durchführen, etwa so:
Es sind 6 Z-Tabellen gleichzeitig zu befüllen. Der Report erzeugt über seinen Sklavenreport die Hintergrundjobs, die alle gleichzeitig in diese Tabellen schreiben.
Mal doof gefragt: Muss ich im Report das o.g. ENQEUE_E_TABLE für jede einzelne Tabelle hintereinander aufrufen und kann dann die Jobs starten? Oder gibt es etwas Eleganteres?
Es gibt noch einen Überwachungsjob, der mit den Datenschaufeljobs gleichzeitig gestartet wird. Der wartet, bis der letzte Datenschaufeljob durchgelaufen ist und macht dann ein Update auf eine Protokolltabelle. Kann ich diesen Job dann benutzen, um die zuvor gesetzten Sperren der 6 Tabellen aufheben?
Vielen Dank für jeden Tipp!
Gruß
K.
ich habe einen bestehenden Report geändert, der über einen Sklaven-Report viele Hintergrund-Jobs aufruft, die verschiedene Z-Tabellen mit einer Menge Daten befüllt (ca. 2 Mio. Datensätze insgesamt). Dieser Report (und sein Sklave, dr ja nur die Jobs startet) bzw. seine Jobs sind die einzigen, die diese Z-Tabellen verändern.
Jetzt kriege ich den Report von der Qualitätssicherung um die Ohren gehauen, weil vor den Änderungen in der Datenbank kein "Lock" durchgeführt wird.
Das Tabellensperren wollte ich nach einem Beispiel aus diesem Forum durchführen, etwa so:
Code: Alles auswählen.
data sptab type rstable.
sptab-TABNAME = 'ZTAB'. "Deine Tabelle
sptab-VARKEY = SY-MANDT.
CALL FUNCTION 'ENQUEUE_E_TABLE'
EXPORTING
TABNAME = sptab-TABNAME
VARKEY = sptab-VARKEY
EXCEPTIONS
FOREIGN_LOCK = 1
SYSTEM_FAILURE = 2
OTHERS = 3.
Mal doof gefragt: Muss ich im Report das o.g. ENQEUE_E_TABLE für jede einzelne Tabelle hintereinander aufrufen und kann dann die Jobs starten? Oder gibt es etwas Eleganteres?
Es gibt noch einen Überwachungsjob, der mit den Datenschaufeljobs gleichzeitig gestartet wird. Der wartet, bis der letzte Datenschaufeljob durchgelaufen ist und macht dann ein Update auf eine Protokolltabelle. Kann ich diesen Job dann benutzen, um die zuvor gesetzten Sperren der 6 Tabellen aufheben?
Vielen Dank für jeden Tipp!
Gruß
K.
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 / 4414 / 224 /
1186
)
»
Die Sperren gelten nur solange wie das Programm läuft. Ein anderer Job kann die Sperren nicht aufheben.
Mal blöd gefragt: Werden die Sperren auf diese Tabellen irgendwo sonst noch in eurem System abgefragt? Vorallem da du einen allgemeinen Sperrbaustein verwendest und keine explizites Sperrobjekt für deine Tabellen angelegt hast, zweifle ich sehr daran.
Die SAP-Sperren funktionieren abseits der DB-Locks. Wenn irgendein anderes Programm auf die Tabellen zugreift und die Sperren nicht abfragt kann es trotzdem normal mit den Tabellen arbeiten.
Wenn nur du und in deinen Reports mit den Tabellen arbeitest sind die Sperren unnötig.
lg ADT
Mal blöd gefragt: Werden die Sperren auf diese Tabellen irgendwo sonst noch in eurem System abgefragt? Vorallem da du einen allgemeinen Sperrbaustein verwendest und keine explizites Sperrobjekt für deine Tabellen angelegt hast, zweifle ich sehr daran.
Die SAP-Sperren funktionieren abseits der DB-Locks. Wenn irgendein anderes Programm auf die Tabellen zugreift und die Sperren nicht abfragt kann es trotzdem normal mit den Tabellen arbeiten.
Wenn nur du und in deinen Reports mit den Tabellen arbeitest sind die Sperren unnötig.
lg ADT
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
Ist vielleicht eher gemeint, dass du jeden einzelnen Datensatz sperren sollst, damit dein "Sklavenprogramm" nicht gerade dann Daten ändert, während jemand diesen Datensatz in einer Dialogtransaktion bearbeitet?
Hallo,
in dem Augenblick, in dem die Z-Tabellen befüllt werden, greift kein anderes Programm darauf zu. Geschrieben werden diese Tabellen sowieso von meinem Programm mit seinem Sklaven und den erwähnten Jobs. Ich finde auch, dass eine Sperre nicht notwendig ist, aber sicher kennt ihr auch das Problem einer QS-Abteilung, die eben auf die Einhaltung der SAP-Development-Guides und eigener Richtlinien besteht.
Gruß
K.
in dem Augenblick, in dem die Z-Tabellen befüllt werden, greift kein anderes Programm darauf zu. Geschrieben werden diese Tabellen sowieso von meinem Programm mit seinem Sklaven und den erwähnten Jobs. Ich finde auch, dass eine Sperre nicht notwendig ist, aber sicher kennt ihr auch das Problem einer QS-Abteilung, die eben auf die Einhaltung der SAP-Development-Guides und eigener Richtlinien besteht.
Gruß
K.
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
496
Views
Views
0
Antw.
Antw.
1472
Views
Views
LSMW - Fehler bei Update, Insert or Delete der Tabelle MLAN
von strobbel » 24.07.2008 11:21 • Verfasst in ABAP® für Anfänger
von strobbel » 24.07.2008 11:21 • Verfasst in ABAP® für Anfänger
9
Antw.
Antw.
9790
Views
Views
DBTab Update from Table oder in Loop mit "Update Set" Oder ?
von RIG » 09.03.2018 11:27 • Verfasst in ABAP® Core
von RIG » 09.03.2018 11:27 • Verfasst in ABAP® Core
5
Antw.
Antw.
1312
Views
Views
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.