Request-Verwaltungsdaten
archivieren
Verwendung
Mit der Archivierung von Request-Verwaltungsdaten stellen Sie sicher, dass die Request-Verwaltungsdaten die Performance Ihres Systems nicht beeinträchtigen.
Über die Archivadministration für das Archivierungsobjekt BWREQARCH führen Sie ein Schreibprogramm aus, das Verwaltungsdaten von ausgewählten Requests in eine Archivdatei schreibt. Im Anschluss an die Archivierung führen Sie ein Löschprogramm aus, das die Verwaltungsdaten aus der Datenbank löscht.
Sie können die initiale sowie die laufende Archivierung in einem Schritt einrichten, indem Sie die Archivierung mit geeigneten Selektionen periodisch einplanen.
Voraussetzungen
● Sie haben die notwendigen Customizing-Einstellungen vorgenommen.
Weitere Informationen:
● Die Sperrtabelle ist groß genug, um zusätzlich mindestens 10.000 Sperren für die Archivierung der Request-Verwaltungsdaten verwalten zu können.
Weitere Informationen:
Die wichtigsten
Profilparameter zum Sperrkonzept
Vorgehensweise
Sie befinden sich in der Archivadministration (Transaktion SARA).
...
1. Wählen Sie auf dem Einstiegsbild das Archivierungsobjekt BWREQARCH aus.
2. Stellen Sie im archivierungsobjektspezifischen Customizing ein, wann nach einem Archivierungslauf das Löschprogramm ausgeführt werden soll, dass die Request-Verwaltungsdaten aus der Datenbank löscht.
a. Wählen Sie Customizing.
b.
Wählen Sie auf dem folgenden Bild 
Technische
Einstellungen.
c. Wählen Sie Start automatisch in den Einstellungen zum Löschprogramm unter Löschjobs und sichern Sie Ihre Eingaben. Geben Sie ggf. einen Transportauftrag an.
Mit dieser Einstellung stellen Sie sicher, dass das Löschprogramm RSREQARCH_DELETE automatisch nach dem Archivierungslauf startet.
Wenn Sie die Archivierung inkl. anschließendem Löschen der archivierten Daten von der Datenbank manuell steuern möchten, wählen Sie Keine Einplanung. Sie können das Löschprogramm dann zu einem beliebigen Zeitpunkt nach der erfolgreichen Archivierung ausführen. Beachten Sie dabei, dass das Löschprogramm nicht parallel zu einem Archivierungslauf laufen kann, sondern nach dem Archivierungslauf gestartet werden muss. Auch sollten nicht mehrere Löschprogramme parallel laufen.
Wir empfehlen, das Löschprogramm zeitnah nach dem Schreibprogramm laufen zu lassen. Ein Request, der zwar vom Schreibprogramm ins neue Archiv geschrieben, aber noch nicht vom Löschprogramm aus der Datenbank gelöscht worden ist, ist inkonsistent. Ein Zugriff auf einen solchen Request führt zu einem Dump in Funktionsbaustein RSSM_RSSELDONE_READ.
d. Gehen Sie zurück und bestätigen Sie das folgende Dialogfenster.
Sie gelangen zurück auf das Einstiegsbild der Archivadministration.
3. Wählen Sie Schreiben.
Sie gelangen auf ein Bild, auf dem Sie einen Hintergrundjob für das Schreibprogramm einplanen können.
4. Wählen Sie eine Variante aus.
5. Wenn Sie eine neue Variante anlegen, geben Sie einen Variantennamen an und wählen Sie Pflegen.
Sie gelangen in die Variantenpflege für das Schreibprogramm RSREQARCH_WRITE. In der Variante schränken Sie über verschiedene Angaben ein, welche Daten archiviert werden, und nehmen weitere Einstellungen vor, die vom Archivierungsobjekt unabhängig sind.
Die zu archivierenden Request-Verwaltungsdaten werden durch verschiedene Angaben festgelegt:
a. Zuerst wählen Sie über Selektionsdatum der Requests einen Zeitraum aus, in dem die Requests mit den zu archivierenden Verwaltungsdaten liegen sollen.
Es werden diejenigen Requests berücksichtigt, die im angegebenen Zeitraum geladen wurden.
b. Danach wählen Sie über Requests älter als (Monate), wie alt die Requests mit den zu archivierenden Verwaltungsdaten mindestens sein müssen.
Die hier angegebenen Monate werden mit 31 Tagen berechnet.
Wählen Sie die Anzahl der Monate so, dass die Verwaltungsdaten derjenigen Requests archiviert werden, die Sie voraussichtlich nicht mehr benötigen. Somit können Sie das unnötige Zurückladen der Verwaltungsdaten vermeiden.
Wir empfehlen, Verwaltungsdaten zu Requests zu archivieren, die älter als 3 Monate sind.
c. Wählen Sie nun, für welche „Art“ von Requests archiviert werden soll:
■ Nur neue Requests archivieren
Es werden nur Requests berücksichtigt, die bisher noch nie archiviert waren.
■ Nur zurückgeladene Requests archivieren
Es werden nur Requests berücksichtigt, die bereits einmal archiviert waren und wieder in die Datenbanktabellen zurückgeladen worden sind.
■ Alle Requests archivieren
Es werden alle derzeit nicht archivierten Requests berücksichtigt, also sowohl neue als auch schon einmal zurückgeladene Requests.
Wenn Sie zum ersten Mal archivieren, empfehlen wir Nur neue Requests archivieren auszuwählen. So können Sie nach einiger Zeit überprüfen, ob archivierte Request-Verwaltungsdaten wieder zurückgeladen werden mussten und können ggf. die Monatsangabe anpassen.
d. Über Weitere Einschränkungen können Sie DataSources aus Quellsystemen auswählen, für welche die Request-Verwaltungsdaten von der Archivierung ausgenommen werden sollen.
e. Wählen Sie über Mindestanzahl Requests, wie viele Requests das Schreibprgramm finden muss, welche den Selektionsbedingungen genügen, bevor das Programm eine Archivdatei erzeugt.
Diese Angabe soll verhindern, dass zu kleine und damit zu viele Archive gebildet werden.
Wir empfehlen, mindestens 1.000 Requests als Mindestanzahl festzulegen. Wenn in Ihrem System viele Requests erzeugt werden, erhöhen Sie die Einstellung bis zu 9.999.
6. Nehmen Sie die weiteren archivierungsobjektunabhängigen Einstellungen zur Variante vor.
7. Pflegen Sie die Variantenattribute und sichern Sie diese.
8. Sichern Sie die Variante und gehen Sie zurück.
9. Pflegen Sie den Starttermin und die Spoolparameter.
Wir empfehlen, die Starttermin-Parameter so festzulegen, dass das Schreibprogramm periodisch ausgeführt wird, z. B. täglich oder an den Wochenenden.
Beachten Sie dabei, dass zu einer gegebenen Zeit immer nur ein Archivierungslauf laufen kann. Das Schreibprogramm RSREQARCH_WRITE darf nicht parallel zu anderen Archivierungsläufen gestartet werden.
10. Wählen Sie Ausführen.
Ergebnis
Das System erzeugt zum festgelegten Starttermin einen Archivierungslauf zum Objekt BWREQARCH. Dabei wird das Schreibprogramm Report RSREQARCH_WRITE ausgeführt und das System schreibt diejenigen Request-Verwaltungsdaten in eine Archivdatei, die den festgelegten Selektionsbedingungen genügen und in den Tabellen RSREQDONE und RSSELDONE gefunden werden.
Da pro Request, für den die Verwaltungsdaten archiviert werden sollen, eine Sperre gesetzt wird, kann der Archivierungslauf die Performance bei Aktionen auf Requests (z.B. Monitoraufruf) beeinträchtigen. In einem Archivierungslauf werden daher die Verwaltungsdaten von maximal 10.000 Requests archiviert.
Im Anschluss an den Archivierungslauf startet das Löschprogramm RSREQARCH_DELETE. Es verifiziert die geschriebenen Archivdateien und löscht anschließend die Einträge zu den archivierten Requests in den Datenbanktabellen. Erst wenn die archivierten Request-Verwaltungsdaten auch aus der Datenbank gelöscht sind, kann das System wieder auf die Requests zugreifen. Dies ist beispielsweise bei einem Neuaufbau aus dem PSA nötig.
Bei einer initialen Archivierung werden pro Archivierungslauf die Verwaltungsdaten für höchstens 10.000 Requests, welche den Selektionskriterien genügen, archiviert und anschließend von der Datenbank gelöscht. Wenn die Archivierung periodisch eingeplant ist, wird die Archivierung solange für je 10.000 Requests durchgeführt, bis die Verwaltungsdaten aller alten Requests archiviert sind. Danach wird nur noch dann eine Archivdatei erzeugt, wenn die festgelegte Mindestanzahl an Requests erreicht ist.
Weitere Informationen: