RGZPFM LOCK(*SHRUPD) - gelöschte Recordanzahl unverändert

[roman]

Hallo zusammen
Wir haben umfangreiche Reorganisationen gemacht in unserer DB. Eigentlich waren es nur Verdichtungen, da keine Keyfiles angegeben wurde.

Die grössten Files enthalten bis zu 44'000'000 Records (!) und 33'000'000 gelöschte Records. Darüber bis zu 22 LF's definiert.

Da wir im 7x24 Stundenbetrieb arbeiten und eine "exklusive" Reorganisation den Betrieb für längere Zeit lahmgelegt hätte, habe wir den Reorganize wie folgt aufgerufen:
RGZPFM FILE(LIB/FILE) KEYFILE(*NONE) ALWCANCEL(*YES) LOCK(*SHRUPD)

Der Reorg dauerte mehrere Tage. Nach Abschluss des Jobs wurden immer noch gleichviel gelöschte Datensätze angezeigt wie vorher.
Dies allerdings nur bei den grössten drei Files (siehe oben).

Woran kann dies liegen? Ev. an der Filegrösse? Braucht es ggf. ein IPL oder ist in dieser Grössenordnung ein RGZPFM mit *SHRUPD gar nicht möglich.

Vielen Dank für euer Feedback.

Gruss Roman

[andreaspr@aon.at]

Hallo Roman,

einer der Gründe könnte der sein, dass der Reorg nicht vollständig durchgeführt werden konnte. (Satzsperren oder ähnliches)
Da musst du den Reorg einfach nochmal anstoßen.
Die Reorganisation beginnt dann dort wo sie zuvor geendet hat.
Und dann sollten die gelöschten Sätze auch weg sein.
Zumindest war das bei uns so.

Ich kann aber jedem nur davon abraten ein RGZPFM mit ALWCANCEL(*YES) LOCK(*SHRUPD) durchzuführen!

Nach einiger Zeit ist uns aufgefallen, dass die Anwendung auf bestimmte Datensätze nicht zugreifen konnte.
Das waren genau die Sätze, die vom Reorg im Zugriff waren.
Da wir bei einigen Tabellen sehr oft Schreiben/Lesen/Ändern, gab es bei denen mit den meisten Zugriffen die größten Probleme.

Ich habe das Phänomen auch mit einem Testprogramm nachstellen können.
Betroffen waren sowohl Native I/O als auch SQL!
Beim Test wurden die Sätze die gerade Reorganisiert wurden einfach überlesen und im Programm hat man nichts davon mitbekommen!!

Kurz gesagt:
Auch wenn es sehr einfach aussieht und verlockend ist, ohne einer SEHR, SEHR detaillierten Analyse und Testen würde ich die Finger davon lassen!

lg Andreas

[Fuerchau]

Bei so vielen gelöschten Sätzen scheint mir REUSEDLT(*YES) nicht eingeschaltet zu sein. Dies sollte man mal tun.

Ansonsten kommt man wohl um ein Zeitfenster nicht herum um den RGZPFM exclusiv zu betreiben.
Zusätzlich muss natürlich auch Platz auf dem System sein.

Beschleunigen kann man den RGZPFM durch deaktivieren der LF's "CHGLF ... MAINT(*DLY)" und anschließendem reaktivieren der LF's.
Dabei kann man beim Reaktivieren je LF einen SBMJOB durchführen um ggf. die Parallelverarbeitung der AS/400 zu nutzen.

[roman]

Meine Vermutungen haben sich hiermit bestätigt:

1. an einem exklusiven RGZFPM führt kein Weg vorbei.
2. Die Aenderung auf REUSEDLT(*YES) macht tatsächlich Sinn .

Vielen Dank für die schnellen Feedbacks.
Grüsse Roman

[BenderD]

... zu allererst würde ich mal beide Fehler an IBM als Softwre defect reklamieren, damit die diesen Murks mal ordentlich machen.
Schneller als Baldurs Vorschlag (der auch offline Fenster benötigt) wäre rename, PF neu erstellen, reinkopieren aus alt nach neu, LFs neu erstellen. Mit Software-Aufwand ginge das auch mit verkürztem Fenster, durch online Kopie mit Journalisierung und nachfahren der geänderten.
Am Rande sei vermerkt, dass 44.000.000 nicht viel ist. Viel fängt derzeit bei dem 10 bis 20 fachen davon an.

D*B

[Jonny B.]

Am Rande sei vermerkt, dass 44.000.000 nicht viel ist. Viel fängt derzeit bei dem 10 bis 20 fachen davon an.
D*B

Das gilt nur für die AS400, SAP stirbt dabei schon weg.