View Full Version : index oder lf
Hallo zusammen,
ich habe noch eine Frage zu embedded SQL.
Ich habe ein RPGLE-Programm, dass in einer Datei liest, die keinen Key hat.
Die Datei hat ca. 1,5 Mio Datensätze und ist eigentlich eine Logdatei.
Da ich eigentlich aus der PC-Welt komme (Mysql/MS SQL) verstehe ich die Sache mit PF/LF,Table und Index auf der i5 nicht so ganz.
Nun überlege ich, wie ich mein RPGLE-Programm etwas optimieren kann.
Erstelle ich ein LF oder einen INDEX ?
Bestehende Programme sollen dadurch nicht beeinträchtigt werden.
mfg
jogi
Hallo,
physische und logische Dateien kommen aus der DDS-Welt, während Tabellen, Indices und Views aus der SQL-Welt stammen.
Eine physische Datei entspricht einer SQL Tabelle (mit kleinen architektonischen Unterschieden). Eine SQL Tabelle kann mit Native I/O genau so wie eine physische Tabelle problemlos verarbeitet werden. Umgekehrt kann SQL physische Dateien ohne Probleme verarbeiten.
Eine logische Datei kann eine Mischung zwischen View und Index sein, d.h. in einer logischen Datei können Join-Anweisungen, Select/Omit-Anweisungen (=Where-Bedingungen) und Keys hinterlegt sein.
Eine SQL-View hat niemals einen Key, während ein Index nur Schlüssel-Informationen (zumindest bis vor V5R4) enthalten kann.
Ein DDS beschriebene logische Datei kann in einem SQL-Statement verwendet werden, sollte aber aus den folgenden Gründen vermieden werden:
Eine SQL-Abfrage in der eine logische Datei angegeben wurde wird immer mit der alten/Classic Query Engine (CQE) verarbeitet. Neue Features können u.U. nicht eingesetzt werden.
Eine SQL-Abfrage in der eine logische Datei angegeben wurde wird vor dem eigentlichen Optimierungs-Prozess umgeschrieben, so dass das SQL-Statement auf den physischen Dateien bzw. SQL-Tabellen basiert und die Join und Select-/Omit-Anweisungen in Join- und Where-Anweisungen übersetzt wird. Der Schlüssel wird dabei ignoriert. Bei der eigentlichen Optimierung werden ALLE Zugriffswege (in logischen Dateien und SQL Indices) bewertet.
SQL-Views können mit native I/O verarbeitet werden, da sie aber ungeschlüsselt sind, ist der Einsatz meist wenig sinnvoll.
Obwohl SQL-Indices nicht in einem SQL-Statement angegeben werden können, können sie mit native I/O wie andere physische und logische Dateien verarbeitet werden.
Da SQL Indices im Vergleich zu DDS beschriebenen logischen Dateien eine größere Page-Size (8K versus 64K) sollten auch mit native I/O Indices verwendet werden.
Einen zusätzlichen SQL-Index, sofern er von dem SQL-Statement auch verwendet wird, beeinträchtig die normale Verarbeitung nicht. Allerdings sollte man beachten, dass jeder neue Zugriffsweg Performance kostet und damit die Anlage neuer Indices nicht übertrieben werden sollte.
Birgitta
klare Frage, kurze Antwort:
Index
D*B
Hallo zusammen,
ich habe noch eine Frage zu embedded SQL.
Ich habe ein RPGLE-Programm, dass in einer Datei liest, die keinen Key hat.
Die Datei hat ca. 1,5 Mio Datensätze und ist eigentlich eine Logdatei.
Da ich eigentlich aus der PC-Welt komme (Mysql/MS SQL) verstehe ich die Sache mit PF/LF,Table und Index auf der i5 nicht so ganz.
Nun überlege ich, wie ich mein RPGLE-Programm etwas optimieren kann.
Erstelle ich ein LF oder einen INDEX ?
Bestehende Programme sollen dadurch nicht beeinträchtigt werden.
mfg
jogi
Hallo nochmal,
Danke für die Antworten bisher.
@Dieter
Wenn ich einen create index mache, beinträchtig das die bestehenden RPG-Anwendungen/PFs und LFs nicht ?
d.h. LF und INDEX kommen sich nicht in die Quere.
Ich möchte zwei Tabellen verknüpfen.
Tabelle taba
af1
af2
af3
af4
...
af50
Tabelle tabb
bf1
bf2
bf3
...
bf30
SELECT a.af1,a.af2,a.af3,b.bf30
FROM taba a INNER JOIN tabb b
ON a.af1 = b.bf1 AND a.af2 = b.bf2 AND a.af3 = b.bf3
WHERE a.af3 = 4711 AND a.af50 <> ''
Ziel ist, alle Sätze aus a, bei denen af50 gefüllt und af3=4711, und alle passenden aus b.
Was muss ich beachten, damit das SQL-Statement flott abgearbeitet wird?
Welche Felder müssen indiziert sein ?
(Birgitta schreibt ja, dass man LFs nicht verwenden soll)
Nach diesem Muster habe ich versucht einen Join bei uns zu testen, aber der war recht langsam.
Danke für eure Hilfe
Gruß jogi
Hallo,
logische Dateien und SQL indices können nebeneinander existieren, sie können sogar den gleichen Zugriffsweg verwenden (Shared Access Path).
Man sollte allerdings beachten, wenn man einen SQL index und eine DDS beschriebene logische Datei hat, dass man den Index zuerst erstellt und die logische Datei anschließend. In diesem Fall wird nur ein einziger Zugriffspfad erstellt. Im umgekehrten Fall werden 2 Zugriffspfade erstellt, die beide bei jedem Insert, Update oder Delete auf die physische Datei bzw. Tabelle aktualiert werden müssen.
Für eine gejointe Abfrage müssen Zugriffswege (in logischen Dateien oder SQL Indices) über die Felder, über die gejoint werden soll vorhanden sein. Weiterhin ist vorteilhaft, wenn die Felder, die in der Where-Bedingung mit = abgefragt werden ebenfalls in dem Index angegeben sind.
Birgitta
Hallo Birgitta
Für eine gejointe Abfrage müssen Zugriffswege (in logischen Dateien oder SQL Indices) über die Felder, über die gejoint werden soll vorhanden sein. Weiterhin ist vorteilhaft, wenn die Felder, die in der Where-Bedingung mit = abgefragt werden ebenfalls in dem Index angegeben sind.
bedeutet dass, es muss ein LF für taba mit genau den Feldern
af1,af2,af3 und af50
und
ein LF für tabb mit genau den Feldern
bf1,bf2,bf3
existieren
oder können in den LFs auch weitere Felder vorhanden sein, und die SQL-Enginge sucht sich dann seinen richtigen Weg ?
jogi
Der Create Index tangiert die Anwendungen, die per ISAM Methoden zugreifen (was anderes ist der sogenannte native I/O nicht. nicht negativ. Was deinen Join angeht, solltest du auf alle Fälle bei beiden Tabellen einen gleich gestaffelten Index über die Join Felder anlegen. Bei der where Klausel hat die Bedingung für a.af3 eine hohe Selektivität, sollte dahinter eine unique Bedingung liegen, dann sollte man auch diese in der Datenbank als Constraint oder unique Index anlegen; die Bedingung für af50 lässt sich nicht unterstützen.
Im richtigen Leben legt man zuerst alle fachlich erforderlichen Constraints an ( Primary Key, unique Bedingungen und referentielle Bedingungen, wie bei jeder SQL Datenbank eben und das war dann 80 % der Arbeit, den Rest kann man sich auch von der Datenbank sagen lassen, wenn der Job unter debug läuft sagt die Datenbank in dignostic Meldungen welche Indexe helfen könnten.
Bezüglich langsam: was ist denn hier konkret unter langsam zu verstehen?
D*B
Hallo nochmal,
Danke für die Antworten bisher.
@Dieter
Wenn ich einen create index mache, beinträchtig das die bestehenden RPG-Anwendungen/PFs und LFs nicht ?
d.h. LF und INDEX kommen sich nicht in die Quere.
Ich möchte zwei Tabellen verknüpfen.
Tabelle taba
af1
af2
af3
af4
...
af50
Tabelle tabb
bf1
bf2
bf3
...
bf30
SELECT a.af1,a.af2,a.af3,b.bf30
FROM taba a INNER JOIN tabb b
ON a.af1 = b.bf1 AND a.af2 = b.bf2 AND a.af3 = b.bf3
WHERE a.af3 = 4711 AND a.af50 <> ''
Ziel ist, alle Sätze aus a, bei denen af50 gefüllt und af3=4711, und alle passenden aus b.
Was muss ich beachten, damit das SQL-Statement flott abgearbeitet wird?
Welche Felder müssen indiziert sein ?
(Birgitta schreibt ja, dass man LFs nicht verwenden soll)
Nach diesem Muster habe ich versucht einen Join bei uns zu testen, aber der war recht langsam.
Danke für eure Hilfe
Gruß jogi