[NEWSboard IBMi Forum]
Seite 2 von 3 Erste 1 2 3 Letzte
  1. #13
    Registriert seit
    Apr 2006
    Beiträge
    85
    Zitat Zitat von 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.
    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

  2. #14
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    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 ))

    Zitat Zitat von bettina_martin
    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 ?
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  3. #15
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  4. #16
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    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

    Zitat Zitat von bettina_martin
    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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  5. #17
    Registriert seit
    Apr 2006
    Beiträge
    85
    Zitat Zitat von 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.
    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

  6. #18
    Registriert seit
    Apr 2006
    Beiträge
    85
    Zitat Zitat von BenderD
    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 ?

  7. #19
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  8. #20
    Registriert seit
    Apr 2006
    Beiträge
    85
    Zitat Zitat von Fuerchau
    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 ?

  9. #21
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Hallo,

    das lässt sich schwer prognostizieren, das hängt von darauf basierenden Indexen und CLOB un Co. ab.
    Das mit der Threshold - das CL macht ja vorher den von Baldur empfohlenen DSPFD *MBRLIST...

    mfg

    Dieter Bender

    Zitat Zitat von bettina_martin
    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 ?
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  10. #22
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Manchmal (je nach Abhängigkeit) empfielt sich ein CPYF->TEMPFILE, CLRPFM CPYF->MYFILE.

    Übrigens, der DSPFD wird bei exclusiven Sperren auf Dateien ausgebremst (Objektwartezeit).
    Daher empfielt sich ein solcher DSPFD ggf. beim IPL.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  11. #23
    Registriert seit
    Apr 2006
    Beiträge
    85
    Zitat Zitat von Fuerchau
    Manchmal (je nach Abhängigkeit) empfielt sich ein CPYF->TEMPFILE, CLRPFM CPYF->MYFILE.

    Übrigens, der DSPFD wird bei exclusiven Sperren auf Dateien ausgebremst (Objektwartezeit).
    Daher empfielt sich ein solcher DSPFD ggf. beim IPL.
    du wirst lachen, aber DAS habe ich mir vorher auch überlegt, nur will ich das nicht riskieren, es handelt sich hier um eine systemtabelle vom sap (log). und ohne 'offizielles' sap-okay dazu sollte man solche dinge NIE machen. jaja, sap ist da eigen ;-)

    das rgzpfm hat leider nicht funktioniert, muss das im sap-down-zustand mit exklusivem lock nochmals machen.

  12. #24
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... was natürlich bei der Anwesenheit von Referential Constraints nicht unbedingt gehen muss

    Zitat Zitat von Fuerchau
    Manchmal (je nach Abhängigkeit) empfielt sich ein CPYF->TEMPFILE, CLRPFM CPYF->MYFILE.

    Übrigens, der DSPFD wird bei exclusiven Sperren auf Dateien ausgebremst (Objektwartezeit).
    Daher empfielt sich ein solcher DSPFD ggf. beim IPL.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

Similar Threads

  1. Tools von Support Software Klaus Klemm GmbH & CO KG
    By Kirsten Steer in forum NEWSboard Server Software
    Antworten: 0
    Letzter Beitrag: 30-01-04, 11:45
  2. Doku zu "#leftmargin" & Co
    By Booley in forum IBM i Hauptforum
    Antworten: 0
    Letzter Beitrag: 03-07-02, 10:28

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •