Aufbau des Zugriffspfads beim CRTLF unterdrücken

[Fuerchau]

Soweit ich das sehe (laut Doku), hilft dieser Befehl nur bei kaputten Zugriffspfaden:

Zugriffspfade wiederherstellen - Hilfetext

Die Anzeige "Zugriffspfade wiederherstellen" zeigt den Namen der
Teildateien an, die über ungültige Wartungszugriffspfade mit
direktem oder verzögerten Zugriff verfügen:

In dieser Anzeige kann der Zugriffspfad für eine bestimmte Teildatei
wiederhergestellt werden. Der Zugriffspfad für eine Teildatei wird
als ungültig markiert, wenn das System abnormal beendet wird,
während die Teildatei benutzt wird.

Dateien mit aufgezeichneten Zugriffspfaden und Dateien mit
Wiederherstellung des Zugriffspfads werden in der Anzeige
"Zugriffspfade wiederherstellen" nicht aufgeführt.

Wahrscheinlich hilft tatsächlich nur die Lösung, die LF's einfach später wieder zu erstellen.
Allerdings ist die parallele Zugriffspfadwartung beim CPYF meist effektiver.

Prüf doch einfach mal, ob da ggf. FRCRATIO(1) bei den Dateien eingestellt ist. Ggf. ist das eher die Ursache.

Ich helfe mir da meist mit:
chgpf ... frcratio(*none)
cpyf
chgpf ... frcratio(Ursprungswert)

Der CPYF läuft dann u.U. um Faktoren schneller.

[Matthias182]

Der Wert für FRCRATIO ist bei uns standardmäßig auf *NONE gesetzt, da wir Journale auf den Dateien aufgesetzt haben.

Sehe ich das richtig, dass es keine Möglichkeit gibt, den Zugriffspfad kontrolliert zu erstellen?

[Pikachu]

Soweit ich das sehe (laut Doku), hilft dieser Befehl nur bei kaputten Zugriffspfaden: ...

Er hilft auch bei Zugriffspfaden, die von den Systemjobs QDBSRV04 und QDBSRV05 aufgebaut werden.

[Fuerchau]

Natürlich

Erstelle die LF erst, wenn du sie brauchst.

[UFK]

Der Wert für FRCRATIO ist bei uns standardmäßig auf *NONE gesetzt, da wir Journale auf den Dateien aufgesetzt haben.

Sehe ich das richtig, dass es keine Möglichkeit gibt, den Zugriffspfad kontrolliert zu erstellen?

Ich hab hier keine AS400, aber ich glaube, es gibt da einen Parameter der das Recovery-Verhalten beschreibt, und der kann auf NONE oder so gesetzt werden.

Wenn man öfters riesengroße Dateien mit Zig-Mio Satensätzen bekommt, und indexieren muß, merkt man schnell, daß CPYF und ein mit IMMED geführter Index, besonders natürlich ein UNIQUE-Index, ein arges Hinderniss darstellt.

Deswegen mein Tip: Die LF's ohne Member erstellen, und das Member erst nach Abschluß in einer eigenen CL-Routine hinzufügen. Wenn sich viele Sätze (> 50 % der Daten) ändern, würde ich die LF-MBR's per CL entfernen, und sie zu passender Zeit wieder hinzufügen. Ein Vorteil ist, daß dies ohne DDS geht, und die Datenbankstruktur im Prinzip bestehen bleibt. Ein anderer Vorteil ist, daß man selber kontrollieren kann, welcher Index zuerst erstellt werden sollte, weil er von den anderen am besten geshared werden kann, denn wenn man es der Recovery-Automatik überläßt, werden u.U. Indizes auch redundant gebildet (es können z.B. mehrere auf parallel gebildet werden, die entbehrlich sind, wenn man den Prozeß besser kontrolliert)

Ich hatte mir auch ein Verfahren gebildet, um die ungewollte "Wiederherstellung" gesicherter und zurückgeladener Indizes zu verhindern, was ja überflüssig ist, wenn sie sowieso mitgesichert wurden. Man kann das alles per Programm kontrollieren, es ist nur mühesam dahin zu kommen. Also Jungs und Mädels, ich sage Euch, es geht (irgendwie), nur nicht aufgeben ...

[BenderD]

für DDS kann ich da nicht sprechen. Bei SQL erstellten drehen wir die Indexe ohne unique constraint vor einer Copy Arie per CHGLF auf *DLY und nach Abschluss per CHGLF wieder auf *IMMED, letzteres in parallelen Jobs, pro CHGLF ein eigener; was uns bei einer Table mit mehreren hundert Mio Sätzen viel gebracht hat.

D*B

Der Wert für FRCRATIO ist bei uns standardmäßig auf *NONE gesetzt, da wir Journale auf den Dateien aufgesetzt haben.

Sehe ich das richtig, dass es keine Möglichkeit gibt, den Zugriffspfad kontrolliert zu erstellen?

[Matthias182]

Ok, ich habe das mal für DDS basierte versucht und da wird der Zugriffspfad direkt aufgebaut, auch wenn MAINT auf *DLY gesetzt ist.

Wo ist da der Unterschied zwischen SQL tables und DDS basierten?

[UFK]

So, und jetzt bist Du nur noch keinen kleinen Schritt von meinem Ansatz des Entkernens entfernt:

• Erstelle die LF bei CRTLF erstmal ohne Teildatei. Sie ist dann nur die Hülle einer später anwendbaren logischen Datei.

Wenn die Maschine später mal wenig belastet ist, und Du die LF danach auch brauchen wirst, läßt Du einen ADDLFM im Batch einplanen. Der Job läuft dann z.B. nach Mitternacht oder am Wochenende, also da, wo Du das beste Zeitfenster dafür siehst. Den Befehl ADDFM also mit Angabe von Datum & Zeit in den Batch submitten, und evtl. alles (SBMJOB und ADDLFM) mit Bedienerführung (F4) ausfüllen, soweit er besondere Angaben für die Teildateien und Bibliothekslisten braucht

Wenn Du das mit SBMJOB mal getestet hast, und es gut funktioniert hat, kannst Du diesen Job natürlich auch im Jobscheduler eintragen, oder die Anweisung dazu in größere CL-Programme (Monatsabschluß oder so) aufnehmen.

Ich meine, das geht auch dann, wenn die LF UNIQUE ist, und alles andere nicht wirklich hilft.

[Fuerchau]

Solange keine Anwendungsprogramme die LF benötigen, mag das so ok sein.

Normalerweise sind die LF's aber in Benutzung, so dass nach der Kopierarie die LFM's wieder angelegt werden müssen.
Ob das in Summe allerdings tatsächlich schneller ist, kann ich nicht prüfen.

[Matthias182]

Hallo Leute,

um das Ganze hier zu einem vernünftigen Abschluss zu bringen.

Ich habe mich jetzt dafür entschieden, die Logischen auf eine leere Physische zu erstellen und dann per CPYF die Daten zu übertragen.

Die Methode bietet zwar nicht die Kontrolle über die Zugriffspfade, aber ist bei ab einer Anzahl von etwa 3 Logischen erheblich schneller als alles andere. Und das ist zuletzt für mich entscheidend.

Vielen Dank euch allen für die Unterstützung.


Gruß
Matthias