View Full Version : RCLSTG,RGZPFM und co.............
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
03-01-07, 13:03
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.
bettina_martin
03-01-07, 13:14
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.
Das dsppfd für die komplette Lib ist auch nicht ohne von der Laufzeit..........bei 33.000 Objekten in der SAP-Datenlib komm ich auf eine Laufzeit von einigen Stunden :(
Hallo,
das bringt schon was und auch dauerhaft (bis man wieder solche Mandantenspielchen macht).
mfg
Dieter Bender
PS: manchmal tragen auch Fragen zur Verwirrung mit bei, das sind nicht nur die Antworten :)))
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 ? :)
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.
Hallo,
wenn das stimmt, dann dauert der RGZPFM Wochen und das mit dem SAP auf dieser Büchse ???
Der SAP Reorg, falls vorhanden, ob der schneller ist, da habe ich meine Zweifel...
mfg
Dieter Bender
Das dsppfd für die komplette Lib ist auch nicht ohne von der Laufzeit..........bei 33.000 Objekten in der SAP-Datenlib komm ich auf eine Laufzeit von einigen Stunden :(
bettina_martin
03-01-07, 13:21
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
bettina_martin
03-01-07, 13:25
Hallo,
wenn das stimmt, dann dauert der RGZPFM Wochen und das mit dem SAP auf dieser Büchse ???
Der SAP Reorg, falls vorhanden, ob der schneller ist, da habe ich meine Zweifel...
mfg
Dieter Bender
Dieter, damit könntest du leider recht haben. Jedoch (siehe Posting mit dem SAP-Hinweis) wenn du dir das CL am Ende ansiehst, kann ich mit dem Trashhold-Wert ja bestimmen wann ich ein rgzpfm machen will. Von den 33.000 Objekten hat ja nur ein Bruchteil gelöschte Sätze. Denkst du das dadurch die Laufzeit verringert wird ?
Ich würde nur die Dateien verwenden, bei denen es sich tatsächlich lohnt (GB statt MB oder MB > 100) wenn die Wahrscheinlichkeit der Daten sowieso für ein Neubelegen der Bereiche spricht lohnt es sich ja nicht.
bettina_martin
03-01-07, 14:20
Ich würde nur die Dateien verwenden, bei denen es sich tatsächlich lohnt (GB statt MB oder MB > 100) wenn die Wahrscheinlichkeit der Daten sowieso für ein Neubelegen der Bereiche spricht lohnt es sich ja nicht.
Ich hab jetzt die Analyse gemacht. Es ist ein rießen Brummer mit 58 Giga (!!) gelöschten Sätzen. Mit dieser Datei hatten wir vor einigen Jahren mal ein Problem, da wurde herumgetrickst damit.
58 Gig macht bei einem Gesamt-ASP von 490 Gig doch schon einiges aus.
Die anderen zusammengerechnet ergeben nur mehr 7 Gig.
Ich mache gerade ein rgzpfm von dieser 58-Gig-Geschichte. Habe ich online gestartet, ich befürchte das Ding hat bei 14.000.000 gelöschten Sätzen eine enorme Laufzeit, oder ?