RCLSTG,RGZPFM und co.............

[Fuerchau]

Solange das System einwandfrei ist, bringt ein RCLSTG tatsächlich nichts da nur verwaiste Objekte gelöscht werden.

RGZPFM kann da schon mehr bringen.
Per DSPFD TYPE(*MBR) und OUTFILE kannst du prüfen, wieviele gelöschte Sätze eine Datei enthält.
Steht eine Datei jedoch auf REUSEDLT wird auch dieses nicht viel bringen. Das hängt nun mal stark von der Arbeitsweise der Anwendung ab.
Da SAP normalerweise nichts wegschmeißt gibts auch da wenig Erfolg.

Was das IFS angeht, so kann das Löscchen nur dann viel bringen, wenn auch große Dateien gelöscht werden (WRKLNK, Auswahl 8). Viele Dateien im IFS belegen aber mal nur 1 Block (4KB) so dass es vieler kleiner Dateien bedarf um messbaren Erfolg zu sehen.

Anders sieht es da ggf. mit SAVF's aus. Schau mal in der QGPL nach (PTF's), die belegen häufig wirklich Platz.

Auch nicht zu verachten ist die Diskrepanz zwischen toten und aktiven Job's (WRKSYSSTS).
Die QTEMP's der toten Job's sowie deren Spools sind nicht zu verachten.

[bettina_martin]

Hallo Fuerchau,

danke für deine Tips.

Habe da jetzt eine Frage:

in der SAP-Datenlib sind ALLE Datein auf REUSEDLT *YES !!!

Du meintes es bringt nix wenn ich hier ein RGZPFM mache.

Ich habe jetzt aber ein kleines Experiment gemacht:

So sahs vorher aus:

Teildatei Größe Art Datum Datum Uhrzeit Sätze
DBTABLOG 121511936 03.09.22 06.11.22 04:01:02 69418
Text:
Gesamtzahl an Teildateien . . . . . . . . : 1
Gesamtzahl nicht verfügbarer Teildateien . : 0
Gesamtzahl Datensätze . . . . . . . . . . : 69418
Gesamtzahl gelöschter Sätze . . . . . . . : 46422
Gesamtgröße der Teildateien . . . . . . . : 121511936
End

Dann habe ich ein RGZPFM gemacht, dann sahs so aus:

Teildatei Größe Art Datum Datum Uhrzeit Sätze S
DBTABLOG 73945088 07.01.03 07.01.03 12:39:33 69418
Text:
Gesamtzahl an Teildateien . . . . . . . . : 1
Gesamtzahl nicht verfügbarer Teildateien . : 0
Gesamtzahl Datensätze . . . . . . . . . . : 69418
Gesamtzahl gelöschter Sätze . . . . . . . : 0
Gesamtgröße der Teildateien . . . . . . . : 73945088
Ende

D.h. das Ding hat die gelöschten Sätze auf null gestellt, der Gesamtplatz ist kleiner geworden.

Jetzt weiß ich nicht wie deine Aussage gemeint war bez. das dieser Befehl nichts nützt, bin jetzt bisschen verwirrt

[BenderD]

Hallo,

it depends on (application) - oft sind gelöschte Sätze bei der Verwendung von REUSEDLT *YES Datenpuffer, die mal voll und mal leer sind (zB.: monatlicher Reorg, temporäre Daten etc.) wenn ich die jetzt wegnehme per RGZPFM, dann gewinne ich ad hoc Platz, der sofort wieder verbraten wird, wenn die Applikation losläuft. Falls an eure Büchse noch Platten drangehen, dann ist es sicher das Beste und billigste sich vom Alteisenhändler ein paar gebrauchte Platten dran zu stöpseln.

mfg

Dieter Bender

PS: Platz bringen kann nur das Löschen von Zeugs, das nicht mehr gebaucht wird (Programmierer Umgebungen, Test Umgebungen etc.) Da würde ich mal einen DSPOBJD *ALL/*ALL *ALL OUTPUT(*OUTFILE) machen und dann mal nach zuletzt benutzt schauen - alles andere fällt eher unter Erdnüsse.

Hallo Fuerchau,

danke für deine Tips.

Habe da jetzt eine Frage:

in der SAP-Datenlib sind ALLE Datein auf REUSEDLT *YES !!!

Du meintes es bringt nix wenn ich hier ein RGZPFM mache.

Ich habe jetzt aber ein kleines Experiment gemacht:

So sahs vorher aus:

Teildatei Größe Art Datum Datum Uhrzeit Sätze
DBTABLOG 121511936 03.09.22 06.11.22 04:01:02 69418
Text:
Gesamtzahl an Teildateien . . . . . . . . : 1
Gesamtzahl nicht verfügbarer Teildateien . : 0
Gesamtzahl Datensätze . . . . . . . . . . : 69418
Gesamtzahl gelöschter Sätze . . . . . . . : 46422
Gesamtgröße der Teildateien . . . . . . . : 121511936
End

Dann habe ich ein RGZPFM gemacht, dann sahs so aus:

Teildatei Größe Art Datum Datum Uhrzeit Sätze S
DBTABLOG 73945088 07.01.03 07.01.03 12:39:33 69418
Text:
Gesamtzahl an Teildateien . . . . . . . . : 1
Gesamtzahl nicht verfügbarer Teildateien . : 0
Gesamtzahl Datensätze . . . . . . . . . . : 69418
Gesamtzahl gelöschter Sätze . . . . . . . : 0
Gesamtgröße der Teildateien . . . . . . . : 73945088
Ende

D.h. das Ding hat die gelöschten Sätze auf null gestellt, der Gesamtplatz ist kleiner geworden.

Jetzt weiß ich nicht wie deine Aussage gemeint war bez. das dieser Befehl nichts nützt, bin jetzt bisschen verwirrt

[bettina_martin]

Das kann ich jetzt logisch nicht ganz nachvollziehen !

Nur als Beispiel. Bei uns haben tausende Files ein vielfaches gelöschte Sätze als 'wirkliche' Sätze in der SAP-Testlib. Das liegt z.b. daran, das wir eine Mandantenkopie, die öfters geflogen ist, mehrmals wieder gelöscht haben. Dann sind die gelöschten Sätze entstanden.

Warum sollten diese beim 'Start' der Applokation (in dem Fall SAP) wieder 'zurückkehren' ?????? Versteh ich nicht ganz.

[kuempi von stein]

Na wenn Ihr mehr Sätze löscht als täglich erstellt werden (eben durch "alte" Mandantenkopien) dann macht mir das durchaus Sinn.
Wenn diese gelöschten Mandantenkopien nicht mehr da sind, bleiben ja trotzdem die gelöschten Sätze (und damit der verbratene Platz) zurück.

Und zurück kommen die nur wenn wieder ein neuer Testmandant erstellt wird.

k.

[Fuerchau]

oder wenn die anderen Mandanten nach und nach neue Daten erzeugen.

Nach einem Mandanten-Kill lohnt ein RGZPFM allemal (selbst die Zugriffe werden dann etwas schneller).

Aber ich bin auch vom "normalen" ausgegangen.

[BenderD]

Wenn ich das alles richtig gelesen habe, dann wollt ihr die Echtumgebung ja noch auf die Testmaschine übernehmen. Wenn ihr dann die Produktionsdaten in vorhandene Dateien übernehmt, dann bedienen die sich erst mal im Reservoir der gelöschten und wenn dieses erschöpft ist, fangen die Dateien an zu wachsen. Sprich: der RGZPFM bring möglicherweise unterm Strich nichts, obwohl es erst mal so aussieht als ob das was nutzt.

mfg

Dieter Bender

Das kann ich jetzt logisch nicht ganz nachvollziehen !

Nur als Beispiel. Bei uns haben tausende Files ein vielfaches gelöschte Sätze als 'wirkliche' Sätze in der SAP-Testlib. Das liegt z.b. daran, das wir eine Mandantenkopie, die öfters geflogen ist, mehrmals wieder gelöscht haben. Dann sind die gelöschten Sätze entstanden.

Warum sollten diese beim 'Start' der Applokation (in dem Fall SAP) wieder 'zurückkehren' ?????? Versteh ich nicht ganz.

[bettina_martin]

Wenn ich das alles richtig gelesen habe, dann wollt ihr die Echtumgebung ja noch auf die Testmaschine übernehmen. Wenn ihr dann die Produktionsdaten in vorhandene Dateien übernehmt, dann bedienen die sich erst mal im Reservoir der gelöschten und wenn dieses erschöpft ist, fangen die Dateien an zu wachsen. Sprich: der RGZPFM bring möglicherweise unterm Strich nichts, obwohl es erst mal so aussieht als ob das was nutzt.

mfg

Dieter Bender

Nein, ganz so stimmt das nicht, ich muss da jetzt kurz ins Detail gehen.

Wir haben auf der SAP-Testumgebung 2(!!) SAP-Systeme, nennen wir sie D01 und D02 (wie sie auch heissen :-)

D01 wurde mittels Mandantenkopie ins D02 integriert. Der Mandant wurde 2 mal gelöscht wegen Problemen auf der D02, bis es endlich funktioniert hat.

D01 wird vor der Übernahme des Produktionssystems (P02) GEKILLT, d.h. wirklich komplett GELÖSCHT. Dann wird eine homogene Systemkopie von P02 auf D01 durchgeführt.

Das RGZPFM will ich ja auf der D02 machen, nicht auf der D01. Eben dort, wo durch Mandantenkopie die vielen gelöschte Sätze entstanden sind.

Summa sumarum: rein logisch betrachtet dürfte das doch was bringen, oder ?

[Fuerchau]

Die Erklärung hast du doch mit deinem Versuch selbst gegeben.
Mach mal einen DSPFD TYPE(*MBR) in eine Outfile und betrachte die Größe im Verhältnis zu vorhandenen und gelöschten Sätzen.

[bettina_martin]

Die Erklärung hast du doch mit deinem Versuch selbst gegeben.
Mach mal einen DSPFD TYPE(*MBR) in eine Outfile und betrachte die Größe im Verhältnis zu vorhandenen und gelöschten Sätzen.

ja, du hast schon recht, nur wurde ich durch die aussage mit dem REUSEDLT ein bisschen verwirrt.

Gibt übrigens auch eine SAP-Transaktion die die gelöschten Sätze anzeigt.

[Fuerchau]

Dann gibts vielleicht auch einen SAP-Reorg ?!

Nochmal zu REUSEDLT(*YES):
Der Platz von gelöschten Sätzen wird sofort wieder verwendet. Dadurch erübrigt sich in den meisten Fällen ein RGZPFM.
Wenn es jedoch Arbeitsdateien (nicht in QTEMP) gibt, die je nach Art mal mehr oder weniger temporäre Daten erzeugen, kann es durchaus zu großer Anzahl gelöschter Sätze kommen.
Es gibt da durchaus Fälle, dass z.B. durch ungünstige Auswahl 1Mio Sätze oder mehr temporär erstellt und wieder gelöscht werden, übliche Auswahlen jedoch nur wenige 100 oder 1000 Sätze benötigen. Hier bleiben die gelöschten Sätze eben erhalten und ein RGZPFM lohnt doch.

Dies kann man durch regelmäßige Überprüfungen (DSPFD und Query) rausbekommen.
Gute Standardapplikationen bieten aber auch häufig Reorg's an, die auch nicht mehr benötigte aktive Daten entfernt (was auch durchaus sinnvoll sein kann) und RGZ's durchführt.

[bettina_martin]

Dann gibts vielleicht auch einen SAP-Reorg ?!

Nochmal zu REUSEDLT(*YES):
Der Platz von gelöschten Sätzen wird sofort wieder verwendet. Dadurch erübrigt sich in den meisten Fällen ein RGZPFM.
Wenn es jedoch Arbeitsdateien (nicht in QTEMP) gibt, die je nach Art mal mehr oder weniger temporäre Daten erzeugen, kann es durchaus zu großer Anzahl gelöschter Sätze kommen.
Es gibt da durchaus Fälle, dass z.B. durch ungünstige Auswahl 1Mio Sätze oder mehr temporär erstellt und wieder gelöscht werden, übliche Auswahlen jedoch nur wenige 100 oder 1000 Sätze benötigen. Hier bleiben die gelöschten Sätze eben erhalten und ein RGZPFM lohnt doch.

Dies kann man durch regelmäßige Überprüfungen (DSPFD und Query) rausbekommen.
Gute Standardapplikationen bieten aber auch häufig Reorg's an, die auch nicht mehr benötigte aktive Daten entfernt (was auch durchaus sinnvoll sein kann) und RGZ's durchführt.

Falls es dich interessiert, füge ich hier mal den Hinweis von SAP an........SAP selbst spricht hier vom rgzpfm:

Zusammenfassung
Symptom
Nach dem Archivieren größerer Datenmengen oder dem Löschen eines Mandanten verringert sich die Größe der Datenbanktabellen nicht. Die Analyse der gelöschten Zeilen in Transaktion DB02 zeigt aber viele gelöschte Zeilen an, die erheblichen Speicherplatz belegen. Es kann auch vorkommen, daß Tabellen unerwartet schnell wachsen, die Spalten der Art BLOB, CLOB oder DBCLOB enthalten und häufige Satzänderungen erfahren.
Weitere Begriffe
AS/400 OS400 deleted records tables by space
Ursache und Voraussetzungen
Wenn Datensätze aus Tabellen gelöscht werden, wird der von ihnen belegte Platz nicht wirklich freigegeben, sondern nur als gelöscht markiert, so daß der Platz beim Einfügen neuer Sätze wiederverwendet werden kann. Bei Tabellen, die kontinuierlich wachsen oder in ihrer Größe in etwa konstant bleiben, führt dieses Vorgehen zu einer effizienten Nutzung des Plattenplatzes bei guter Performance.

Wenn jedoch Tabellen dauerhaft verkleinert werden, z.B. durch Archivierung oder das Löschen eines Mandanten, kann es erwünscht sein, den von gelöschten Sätzen belegten Speicherplatz auch tatsächlich freizugeben, um die Größe der Datenbank oder einzelner Tabellen zu reduzieren.
Lösung
Die Reorganisation von Datenbanktabellen erfolgt mit dem Befehl RGZPFM (Physische Teildatei reorganisieren). Bis einschließlich OS/400 V5R2M0 war es erforderlich, daß die betroffene Tabelle während der Reorganisation exklusiv gesperrt wurde. Beginnend mit i5/OS V5R3M0 ist es auch möglich eine Online-Reorganisation durchzuführen, für die keine Exklusivsperre erforderlich ist.

Aufgrund von Besonderheiten in der Speicherverwaltung von Tabellen mit Spalten der Art BLOB, CLOB oder DBCLOB kann es vorkommen, daß nach der Reorganisation einer solchen Tabelle einige wenige gelöschte Sätze überbleiben. Dies ist eine systembedingte Einschränkung,die ignoriert werden kann. Außerdem kann es bei Tabellen mit Spalten der Art BLOB, CLOB oder DBCLOB vorkommen, daß nach einer Online-Reorganisation zwar die Anzahl der gelöschten Sätze, nicht aber der belegte Speicherplatz reduziert wurde. In diesem Falle kann es helfen, anstelle der Onine- eine Offline-Reorganisation auszuführen.
Achtung!
Aufgrund eines Programmfehlers in i5/OS V5R3M0 kann es bei einer Online-Reorganisation mit dem Parameter ALWCANCEL(*YES) zu einem Abbruch kommen, wenn die Tabelle Spalten der Art BLOB, CLOB oder DBCLOB enthält. Das Problem soll in Release V5R4M0 behoben werden, zur Zeit ist aber noch kein PTF verfügbar. Wir empfehlen daher, in V5R3M0 und V5R4M0 für Tabellen mit LOB-Spalten die Offline-Reorganisation zu verwenden. Sobald ein PTF für V5R4M0 verfügbar ist, wird dieser Hinweis angepaßt werden. Um festzustellen, ob eine Tabelle LOB-Spalten enthält, können Sie den Befehl DSPFFD verwenden und nach den Datentypen BLOB, CLOB und DBCLOB suchen.
Parameter für eine Offline-Reorganisation

Für eine Offline-Reorganisation muß der Befehl RGZPFM mit folgenden Parametern aufgerufen werden:
FILE: Bibliothek und Systemname der zu reorganisierenden Tabelle.
MBR: Teildatei oder Partitionsname.
KEYFILE: *NONE oder *FILE. Für Tabellen, die einen Primärschlüssel haben, ist *FILE empfohlen, ansonsten muß *NONE verwendet werden.
ALWCANCEL: *NO (dieser Parameter ist ab i5/OS V5R3M0 verfügbar).

Während die Tabelle reorganisiert wird, kann sie nicht von einem anderen Prozeß verwendet werden, d.h. es wird häufig nötig sein, das SAP-System zu beenden, bevor häufig benutzte Tabellen reorganisiert werden können.

Achtung! Wenn Sie eine OS/400-Version vor V5R1M0 verwenden, ist es unbedingt erforderlich, nach der Tabellenreorganisation eine Datensicherung vorzunehmen, weil im Falle eines Datenverlustes nach Einspielen der Datensicherung die Journaleinträge für RGZPFM nicht angelegt werden können. Ab OS/400 V5R1M0 steht der Befehl APYJRNCHGX zur Verfügung, mit dem auch Journaleinträge für RGZPFM angelegt werden können, so daß eine Datensicherung unmittelbar nach der Reorganisation nicht mehr erforderlich ist.
Parameter für eine Online-Reorganisation

Die Online-Reorganisation ist ab i5/OS V5R3M0 möglich, sollte aber für Tabellen, die BLOB-, CLOB-, oder DBCLOB-Spalten enthalten erst verwendet werden, wenn ein PTF für V5R4M0 verfügbar ist. Für eine Online-Reorganisation muß der Befehl RGZPFM mit folgenden Parametern aufgerufen werden:
FILE: Bibliothek und Systemname der zu reorganisierenden Tabelle.
MBR: Teildatei oder Partitionsname.
KEYFILE: *RPLDLTRCD.
ALWCANCEL: *YES.
LOCK: *SHRUPD.

Während einer Online-Reorganisation kann die betroffene Tabelle weiterhin verwendet werden, um Sätze zu lesen, hinzuzufügen, zu ändern oder zu löschen. Es kann aber zu Konflikten kommen, wenn versucht wird, während der Online-Reorganisation die Tabellenstruktur zu ändern, z.B. durch Einspielen eines Transportes. Die Online-Reorganisation ist nicht so vollständig wie eine Offline-Reorganisation, speziell bei Tabellen, die Spalten der Art BLOB, CLOB oder DBCLOB enthalten. Wenn eine Tabelle nach einer Online-Reorganisation immer noch zu groß erscheint, sollte eine Offline-Reorganisation mit dem Parameter KEYFILE(*FILE) vorgenommen werden.
Automatische Reorganisation mehrerer Tabellen

Der Befehl RGZPFM erlaubt nur die Eingabe einer einzelnen Tabelle für die Reorganisation. Das folgende Beispielprogramm zeigt, wie Sie mit Hilfe eines CL-Programmes alle Tabellen in einer Bibliothek reorganisieren können, die mehr gelöschte Sätze enthalten, als im Parameter &THRESHOLD vorgegeben ist.

Beachten Sie bitte, daß das Programm nur als Beispiel dient. IBM und SAP können keine Garantie für die Korrektheit des Programmes übernehmen.
PGM PARM(&LIBRARY &THRESHOLD)
DCLF FILE(QAFDMBRL)
DCL VAR(&LIBRARY) TYPE(*CHAR) LEN(10)
DCL VAR(&THRESHOLD) TYPE(*DEC) LEN(15 5)
DLTF FILE(QTEMP/MBRLIST)
MONMSG MSGID(CPF2105)
DSPFD FILE(&LIBRARY/*ALL) TYPE(*MBRLIST) +
OUTPUT(*OUTFILE) FILEATR(*PF) +
OUTFILE(QTEMP/MBRLIST)
OVRDBF FILE(QAFDMBRL) TOFILE(QTEMP/MBRLIST)
LOOP: RCVF
MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(END))
IF COND(&MLNDTR *GT &THRESHOLD) THEN(DO)
RGZPFM FILE(&MLLIB/&MLFILE) MBR(&MLNAME) +
KEYFILE(*FILE) ALWCANCEL(*NO)
MONMSG MSGID(CPF2981) EXEC(RGZPFM +
FILE(&MLLIB/&MLFILE) MBR(&MLNAME) +
KEYFILE(*NONE) ALWCANCEL(*NO))
ENDDO
GOTO CMDLBL(LOOP)
END: ENDPGM