View Full Version : Übersicht über logische Dateien
Jau, die hilft mir doch enorm weiter.
Danke, ich hatte nur die o.g. gefunden.
Mal sehen, was man daraus basteln kann!
Hallo,
in der View SYSKEYS sind nur die Schlüssel-Felder aus SQL-Indices oder Key Constraints hinterlegt.
Ansonsten kannst Du ja mal prüfen ob Dich der Befehl ANZDBFKEY eventuell weiterbringt.
Ansonsten schau doch mal unter help/400 nach, ob sich da nicht ein brauchbares Tool finden lässt:
Help400 (http://www.help400.de/Freeware.htm)
Eine nicht kostenfreie Lösung u.a. bietet auch das Tool FileAccess der Fa. SSS. Hier können die auf einer physischen Datei liegenden logischen Dateien (oder SQL Indexes und Views) angelistet werden. Weiterhin kann eine Auswahl an Schlüssel-Feldern angegeben werden. Alle logischen Dateien mit den angegebenen Schlüssel-Feldern in der vorgegebenenen Reihenfolge werden Reverse Intense angezeigt.
Weitere Informationen erhälst Du unter dem folgenden Link:
SSS-Software GmbH is a specialist for iSeries Tools (http://www.sss-software.de)
Birgitta
K.Schuricht
08-10-07, 15:00
ohne Werbung zu machen, aber kann das Tool FileAccess auch nur empfehlen !!
Es wird Dir beim Arbeiten eine sehr große Hilfe sein.
Eine Testinstallation ist glaub ich möglich.
Gruss Kai
Warum schreibst Du Deine Programme nicht sofort mit SQL, dann brauchst Du Dir bei einer Datei mit über 100 LF überhaupt keine Gedanken über logische Dateien machen! Läuft sowies wesentlich besser als Lesen per LF.
loeweadolf
09-10-07, 19:35
Warum schreibst Du Deine Programme nicht sofort mit SQL, dann brauchst Du Dir bei einer Datei mit über 100 LF überhaupt keine Gedanken über logische Dateien machen! Läuft sowies wesentlich besser als Lesen per LF.
Gerade auch bei SQL ist der Zugriffspfad sehr wichtig. Auch hier muss man sich Gedanken machen bzgl. log. Dateien bzw. Indizes.
Ja schon, aber gerade das ist ja wesentlich einfacher.
Einfach im Debugmodus testen, Joblog analysieren und erst dann ggf. Index anlegen (obwohl er den dann auch nicht immer nimmt).
Bei nativen Zugriffen muss ich mir leider VORHER über LF's Gedanken machen.
Bei SQL's meistens HINTERHER oder sogar erst, wenn's beim Kunden nicht so performant ist (weil der ja mehr Daten hat).
Dann kann man immer noch optimieren ohne die Programme anpassen zu müssen.
loeweadolf
09-10-07, 20:21
Ja schon, aber gerade das ist ja wesentlich einfacher.
Einfach im Debugmodus testen, Joblog analysieren und erst dann ggf. Index anlegen (obwohl er den dann auch nicht immer nimmt).
Bei nativen Zugriffen muss ich mir leider VORHER über LF's Gedanken machen.
Bei SQL's meistens HINTERHER oder sogar erst, wenn's beim Kunden nicht so performant ist (weil der ja mehr Daten hat).
Dann kann man immer noch optimieren ohne die Programme anpassen zu müssen.
Dann gehöre ich wohl zu der austerbenden Art von Spezies, die sich vor dem Einsatz beim Kunden Gedanken machen, um nach Möglichkeit Reklamationen zu vermeiden.
:-)
Hallo,
Bei nativen Zugriffen muss ich mir leider VORHER über LF's Gedanken machen.
Bei SQL's meistens HINTERHER oder sogar erst, wenn's beim Kunden nicht so performant ist (weil der ja mehr Daten hat).
Auch bei SQL sollte man sich vorher (und nicht erst hinterher) Gedanken über die Zugriffswege machen, um von vornherein Performance-Problemen soweit wie möglich aus dem Weg zugehen.
(Proaktive Indexing Strategie)
Es kann natürlich vorkommen, dass aufgrund der unterschiedlichen Datenkonstellationen oder unterschiedlichen Release-Ständen auf Echt- und Test-Maschinen verschiedene Zugriffswege verwendet werden. Im Extremfall kann das sogar dazu führen, dass auf der Test-Maschine ein Zugriffsweg gefunden wurde, während der Optimizer sich auf der Echt-Maschine für einen Table-Scan entscheidet.
(Reaktive Indexing Strategie)
Beim Einsatz von SQL sollte man halbwegs verstehen, wie die Query Engines arbeiten und wann welche Query Engine eingesetzt wird. Viele Performance-Probleme kommen außerdem daher, dass SQL-Statements so gestaltet werden, dass der Optimizer überhaupt keine Chance hat einen Index zu verwenden. (z.B. Zugriff über relative Record-Nr. oder die Verwendung von skalaren Funktionen auf der linken Seite der Vergleichsoperatoren in den Where-Bedingungen)
Mit zunehmendem Einsatz von SQL, sind die Zeiten, in denen kein Datenbanken-Administrator notwendig war vorbei. Selbst IBM empfiehlt inzwischen, dass jemand regelmäßig ein Auge auf die (SQL-)Performance hat, der gegebenenfalls neue Zugriffswege (geschlüsselte logische Dateien oder SQL Indices) anlegt, bzw. nicht mehr benötigte Zugriffswege löscht. Es gilt zu bedenken, dass jeder zusätzliche Zugriffsweg Performance kostet, d.h. bei jedem Insert, Update oder Delete eines Datensatzes in der zugrundeliegenden physischen Datei (oder SQL Tabelle) müssen alle Zugriffswege aktualisiert werden.
Birgitta
Hallo,
das ist ja nicht verkehrt, denn gerade hier gilt, dass gutes Design durch einfache Programmierung belohnt wird und Probleme (z.B. Performance) ihre Ursachen in Huddel Design haben. Konsequente Normalisierung der Datenbank und anlegen aller daraus resultierenden Constraints und der fachlich begründeten (unique) Constraints führen dazu, dass die allermeisten Zugriffspfade damit bereits angelegt sind. Wenn man jetzt noch die Datenbankzugriffe in eine eigene Zugriffsschicht zusammen fasst, dann hat man sehr überschaubare Verhältnisse, die schnell und effektiv verifiziert werden können, meist reicht dann zur Verifikation schon ein PRTSQLINF für die Serviceprogramme der Zugriffsschicht.
Bei variablen order by Kriterien und Filtern (was mit Rekord Löffel Ekzem garnicht geht!), brauchts dann schon ein wenig mehr, aber auch hier gilt, gutes Datenbank Design hilft immens, normalisierte Tabellen haben selten mehr als 10 oder 15 sinnvolle Zugriffspfade und eine vernünftige Teststrategie (Stichwort QS) mit hinreichender Abdeckung und Produktions nahen Datenbeständen (auch vom Volumen!) sollte da Lücken in den meisten Fällen aufdecken.
mfg
Dieter Bender
Dann gehöre ich wohl zu der austerbenden Art von Spezies, die sich vor dem Einsatz beim Kunden Gedanken machen, um nach Möglichkeit Reklamationen zu vermeiden.
:-)
Jetzt möchte ich in einem Dialog eben diese Datei nach verschiedenen Kriterien / Bedingungen, etc anzeigen.
Aber beim Zugriff auf eine logische Datei (über die QADBKFLD) kommt der Fehler:
E/A-Fehler CPF5029 in KEYSLF1 erkannt (C G S D F).
(wobei KEYSLF1 die logische Datei ist).
Als Nachrichtentext kommt dann im QPPGMDMP:
Datenzuordnungsfehler in Teildatei KEYSLF1.
Woran kann das liegen, bzw. wie kann ich das vermeiden?
IRgendwo habe ich etwas gefunden, dass diese Meldung bedeutet, dass NULL-Werte vorhanden sind!?
€dith hat herausgefunden, dass ich beim Umwandeln die Option "ALWNULL" auf *YES setzen kann...und schon läuft es ^^