View Full Version : Umsetzung LF mit Omit Klausel in View/Index
Hallo,
Ich möchte wegen der besseren Performance bei PHP Zugriffen auf die Datenbank meine bisherige Bibliothek in eine Collection umwandeln ohne, daß ich die RPG Programme neu schreiben muss. Ich habe bereits die Tabellen erstellt und die Inhalte kopiert. Nun gibt es ein Problem bei den Indices, wenn ich in den Zugriffspfaden eine OMIT Klausel stehen habe. Alle Indices ohne diese Klauseln habe ich erstellen können. Warum kann ich nicht für diese Fälle logische Zugriffspfade über DDS erstellen. Ich erhalte beim Wandeln immer die Fehlermeldung:
CPF320C : Datei DATEINAME in SQL-Datensammlung LIBNAME nicht zulässig.
Jede Hilfe ist willkommen.
Danke
Bernd
Hallo,
die Arbeit kannst du dir komplett sparen, CRTLIB oder create schema, oder create collection ist Performance mäßig alles Banane! Nebenbei bemerkt sei noch, dass die Option Data Dictionary reine Altlasten referenziert (IDDU, falls noch ein paar Fossile wie ich mitlesen).
Die DDS Dinger mit SELECT/OMIT, die sind durchaus Performance relevant, die erzeugen zusätzliche Maintenance und sind von SQL nicht nutzbar; aber wenn die Anwendung das braucht: wat mutt, dat mutt.
Die von einzelnen Marketiers häufig verargumentierten Vorteile von SQL erstellten Dateien versus DDS, liegen innerhalb der Grauzone (sprich nicht messbar im realen Betrieb!).
Rat: lass alles, wie es ist und konzentriere dich auf die Untersuchung der realen Probleme deiner Datenbankzugriffe aus PHP, soweit vorhanden, STRDBMON ist dein Freund und der Ooops Nerv wird zu deinem Widersacher werden!
mfg
Dieter Bender
Hallo,
Ich möchte wegen der besseren Performance bei PHP Zugriffen auf die Datenbank meine bisherige Bibliothek in eine Collection umwandeln ohne, daß ich die RPG Programme neu schreiben muss. Ich habe bereits die Tabellen erstellt und die Inhalte kopiert. Nun gibt es ein Problem bei den Indices, wenn ich in den Zugriffspfaden eine OMIT Klausel stehen habe. Alle Indices ohne diese Klauseln habe ich erstellen können. Warum kann ich nicht für diese Fälle logische Zugriffspfade über DDS erstellen. Ich erhalte beim Wandeln immer die Fehlermeldung:
CPF320C : Datei DATEINAME in SQL-Datensammlung LIBNAME nicht zulässig.
Jede Hilfe ist willkommen.
Danke
Bernd
Hallo,
eine SQL View ist nie geschlüsselt!!!
ein Index kann nur über Original-Felder ohne irgendwelche Selektionen erstellt werden!!!
Ich weiß nicht wie Du das SQL-Statement aussieht, über das Du die Views/Indices erstellst und wie Du versucht hast den Schlüssel bzw. die Selektionskriterien anzugeben, sicher ist, dass das nicht möglich ist!
Hättest Du SQL Skripte für die DDS beschriebenen logischen Dateien über iSeries Navigator Reverse Engineering erstellt, hättest Du gesehen, dass nur Views generiert werden und die Schlüssel auf der Strecke bleiben.
Für SQL benötigst Du beides Views und Zugriffswege, also SQL-Indices oder geschlüsselte logische Dateien.
(In einer View kann alles hinterlegt werden, das mit einem Select-Statement möglich ist. Mit einer Ausnahme: Order By ist nicht zulässig. In einem Index dagegen können nur Schlüssel angegeben werden.)
Solltest Du die logischen Dateien mit Select/Omit mit native I/O verwenden müssen, dann mach folgendes:
1. Erstelle eine View mit neuem Namen
2. Erstelle (sofern benötigt) einen Index über die Schlüssel-Felder
3. Erstelle die DDS beschriebene logische Datei neu.
Birgitta
Hallo Dieter Bender,
leider habe ich gegeteilige Erfahrungen gemacht. Mit RPG Programmen ist ja alles in Butter. Die PHP Zugriffe auf die Datenbank sind aber bei einer "normalen" Bibliothek erheblich langsamer als bei einer Collection. Ich habe da eine kleine Statistikdatei mit ca. 1GB Daten und 3 Mio Sätzen. Wenn ich eine Auswertungsanfrage aus PHP an die Datei in der "normalen" Bibliothek stelle kann ich zwischenzeitlich essengehen, während der Zugrif auf die Collection "Ratz-Fatz" durchgeführt wird. Ich komme also nicht um eine Umsetzung herum, wenn ich PHP nutzen will/muss.
Vielen Dank für Deine Antwort
Bernd
Es gibt noch einen wesentlichen Unterschied zwischen LIB und COLLECTION.
Beim CREATE COLLECTION werden automatisch Journale erstellt und alle, per CREATE TABLE erstellt Tabellen in diesem Journal aufgezeichnet.
Für ALTE RPG-Programme ist ein CREATE TABLE sogar tödlich:
1. Satzformatname = Dateiname (umbenennen in RPG erforderlich)
2. Neue LVLCHK-ID !
In einer SQL-Datensammlung sind ausschließlich TABLE, INDEX und VIEW erlaubt (neben FUNCTION, PROCEDURE, usw.).
Da eine SELECT-LF nicht SQL-spezifisch ist, wird dieses abgelehnt.
Ausserdem kann ein RPG zwar auf eine VIEW zugreifen, allerdings nur rein sequentiell.
Eine VIEW hat keine KEYS und damit ist SETLL/SETGT/READE nicht mehr möglich.
Nun zu SQL:
Greifst du per SQL auf eine VIEW zu, ist dies eigentlich ein vordefinierter SQL der nicht weiter mit WHERE eingeschränkt werden sollte (also nur SELECT * FROM VIEW [order by ...]).
Solltest du etwas anderes tun, kann SQL die View gar nicht verwenden sondern ergänzt deinen SQL nur mit den zusätzlichen WHERE bzw. GROUP BY und fängt die Analyse über die PF wieder von vorne an.
Auch wenn du per SQL auf eine LF-View (mit Select/Omit) zugreifst, wird dein SQL angepasst und über die PF und Indizees neu analysiert.
Wenn du deine PHP-Zugriffe optimieren willst musst du entsprechende Einträge in die QAQQINI bzgl. Diagnose-Nachrichten machen und dann den Hinweisen des Joblogs folgen. Bei mir hilfts in 95% aller Fälle.
Den Rest kann man dann per STRDBMON analysieren was etwas aufwändiger ist.
Ach ja:
Es gibt immer noch einen Unterschied bzgl. des Optimizers (alt/neu).
Wenn eine LF mit SELECT vorhanden ist, wird der ALTE Optimizer aufgerufen, ansonsten der neue.
Auch dies kann Performance-Nachteile mit sich bringen.
Hallo,
zunächst vielen Dank für die schnelle Antwort. Ist ja ein tolles Forum!
Ich möchte hier ein kleines Beispiel zeigen, was ich eigentlich benötige:
sagen wir einmal die physische Datei sieht folgendermassen aus:
ARNR Artikelnummer
ARBEZ Artikelbezeichnung
ARWG Warengruppe
:
Der 1. logische Zugriffspfad könnte dann folgendermaßen sein:
K ARNR
O ARWG COMP(NE 4)
Der 2. logische Zugriffspfad sieht die Warengruppe als ersten und die Bezeichnung als zweiten Schlüssel also:
K ARBEZ
K ARWG
Wie kann ich das vernünftig umsetzen ohne an die tausende Programme ranzu müssen, welche in irgendeine Weise auf den Artikelstamm zugreifen?
Gruß
Bernd
Wie kann ich dies in eie Collection mit Tables, Views und Indices vernünftig umsetzen?
Hallo,
das liegt nicht an Collection versus Bibliothek, sondern muss mit Database Monitor (oder unter Debug des Datenbankjobs) verifiziert werden, wass da der Query Optimizer letztlich draus macht!
mfg
Dieter Bender
Hallo Dieter Bender,
leider habe ich gegeteilige Erfahrungen gemacht. Mit RPG Programmen ist ja alles in Butter. Die PHP Zugriffe auf die Datenbank sind aber bei einer "normalen" Bibliothek erheblich langsamer als bei einer Collection. Ich habe da eine kleine Statistikdatei mit ca. 1GB Daten und 3 Mio Sätzen. Wenn ich eine Auswertungsanfrage aus PHP an die Datei in der "normalen" Bibliothek stelle kann ich zwischenzeitlich essengehen, während der Zugrif auf die Collection "Ratz-Fatz" durchgeführt wird. Ich komme also nicht um eine Umsetzung herum, wenn ich PHP nutzen will/muss.
Vielen Dank für Deine Antwort
Bernd
1. Seit Release V5R4 ist es möglich Tabellen und Views mit abweichendem Format-Namen zu erstellen, in dem man am Ende des Create Table Statements das Schlüsselwort RCDFMT und den Format-Namen eingfügt:
CREATE TABLE MySchema/MyFile
...
RCDFMT MyFormat
Auch vor Release V5R4 konnten SQL-Tabellen mit abweichendem Format-Namen erstellt werden. Allerdings waren dazu 2 Schritte notwendig:
- Die Tabelle wird zunächst mit dem Format-Namen erstellt
- Anschließend wird die Tabelle auf den gewünschten Dateienamen umbenannt. Beim Umbenennen bleibt das Format unverändert.
2. Auch wenn Dieter immer was anderes behauptet.
- Die Konvertierung von DDS beschriebene physischen Dateien in SQL beschriebene Tabellen bringt definitiv meßbare Verbesserungen.
- Das Ersetzen von geschlüsselten logischen Dateien druch SQL Indices bringt ebenfalls Vorteile, wegen der größeren Page Size von SQL Indices
3. SQL-Indices, SQL-Views und DDS beschriebene logische Dateien können durchaus nebeneinander existieren. Deshalb sollte man wie folgt vorgehen.
- Alle geschlüsselten logischen Dateien (ohne Select/Omit-Anweisungen oder Joins) in SQL-Indices umwandeln. SQL-Indices können wie jede DDS geschriebene logische Datei in die F-Bestimmungen eingebunden werden und mit native I/O verarbeitet werden.
- Anschließend alle geschlüsselten logischen Dateien mit Select/Omit-Anweisungen neu erstellen. Damit kann die logische Datei u.U. den Zugriffsweg eines SQL Indexes mitbenutzen, wodurch sie auch die größere Page Size (des SQL Indices) auf die logische Datei übertragen wird.
4. Der iSeries Navigator ist nicht so schlecht wie Dieter immer tut!
Um die SQL-Statements für alle Dateien einer Bibliothek zu erstellen oder auch nur eines einzelnen Datenbanken-Objekts, kann man den iSeries Navigator hervorragend nutzen (es braucht allerdings alles seine Zeit!).
Dazu muss man lediglich im iSeries Navigator Database auf das oder die gewünschten Datenbanken-Objekte positionieren, Rechtsclick und Generate SQL. Dann wird für alle Datenbanken-Objekte (auch für DDS beschriebene Dateien) der entsprechende SQL-Befehl erstellt. Was nicht umgesetzt werden kann, wird im Skript als Kommentar gekennzeichnet. Das Skript kann anschließend beliebig bearbeitet werden und die SQL-Commands ausgeführt werden.
5. Ein Fehler, der häufig gemacht wird und unbedingt vermieden werden sollte ist, DDS beschriebene logische Dateien in einem SQL-Statement anzugeben. Der Optimizer schreibt zunächst das SQL-Statement mit den Informationen (Feldauswahl, Select/Omit und Join) basierend auf den physischen Dateien/Tablle um. Erst anschließend beginnt die allgemeine Optimierung.
Alle SQL-Statements in denen DDS beschriebene logische Dateien angegeben werden, werden von der alten (Classic) Query Enginge (CQE) ausgeführt.
6. Ansonsten ist Performace-Analyse (über STRDBMON) das A+O. Mit Release V5R4 stellt der iSeries Navigator eine Reihe von graphischen Tools zur Verfügung um die über den Monitor gesammelten Daten auszuwerten. Die hinter den einzelnen Auswertungen hinterlegten SQL-Statements können auch als Skript generiert und beliebig verändert werden.
... Allerdings: alles braucht seine Zeit.
Birgitta
Hallo Birgitta,
ist ja 'ne Wucht. Endlich mal 'ne klare Aussage.
Ich bin so vorgegangen, wie Du es erklärt hast und habe die Indices erstellt.
Du schreibst:
"- Anschließend alle geschlüsselten logischen Dateien mit Select/Omit-Anweisungen neu erstellen. Damit kann die logische Datei u.U. den Zugriffsweg eines SQL Indexes mitbenutzen, wodurch sie auch die größere Page Size (des SQL Indices) auf die logische Datei übertragen wird."
Wie kann ich denn diese logischen mit Select/Omit neu erstellen? Momentan hat in meinem Beispiel die erste logische nur die Artikelnummer als Key.
Danke noch einmal
Bernd
Ergänzend zu Birgitta:
Wenn du ein CREATE COLLECTION/SCHEMA durchgeführt hast, können keine LF's mit SELECT/OMIT in diese Lib gestellt werden.
Allerdings wird es nicht verboten, per CRTLIB eine Lib zu erstellen und darauf die CREATE TABLE's usw. auszuführen.
In diesem Fall müsste das Erstellen der OMIT-LF möglich sein, da die Lib ja nicht als SQL-Collection erkannt würde.
Journalisierungen können dann trotzdem durchgeführt werden.