View Full Version : Umsetzung LF mit Omit Klausel in View/Index
@Baldur
Wenn du ein CREATE COLLECTION/SCHEMA durchgeführt hast, können keine LF's mit SELECT/OMIT in diese Lib gestellt werden.
Wie kommst Du denn zu dieser schwindeligen Aussage?
Aus welchem Grund sollten DDS beschriebene logische Dateien mit Select/Omit Anweisungen nicht in einem SQL-Schema erstellt werden können?
Ein SQL-Schema ist nichts anderes als eine Bibliothek, mit der Ausnahme, dass zusätzlich beim Erstellen ein Journal, ein Journal Receiver und diverse Catalog Views erzeugt werden. Weder das Journal noch die Catalog Views beinflussen bzw. verhindern in irgendeiner Weise die Erstellung von DDS beschriebenen logischen Dateien mit Select/Omit-Anweisungen.
Natürlich können DDS beschriebene logische Dateien mit oder ohne Select/Omit in SQL definierten Schemata erstellt werden!
@Bernd
Wie kann ich denn diese logischen mit Select/Omit neu erstellen? Momentan hat in meinem Beispiel die erste logische nur die Artikelnummer als Key.
Du nimmst einfach Dein vorhandenes DDS und erstellst die logische Datei mit CRTLF (oder Auswahl 14 aus dem PDM).
Birgitta
Hallo,
hier geht ja wieder mal alles durcheinander. Hier muss man auseinander halten:
- CRTLF mit Select/Ommit (und ein paar andere Sachen) gehen nicht, wenn man bei CREATE COLLECTION (SCHEMA) wit Data Dictionary yes macht
- Data Dictionary sind nicht die SQL Verwaltungs Sichten, sondern IDDU Altlasten, die niemand braucht
- CRTLIB und CREATE SCHEMA (Collection ist das selbe in SQL Dialekt)
unterscheiden sich im Hinblick auf Verarbeitung der Dateien grundsätzlich nicht, nur bei der Erstellung (Journalisierung!). Das ist Performance technisch absolut identisch
- SQL versus DDS: IBM Marketiers behaupten seit mehreren Jahren, dass SQL rundherum schneller sei als DDS, um den schrittweisen Wegfall von DDS Funtionalität schmackhaft zu machen - das hat einer ernsthaften Überprüfung nie stattgehalten. Beides hat Vor- und Nachteile im Hinblick auf Performance, aber dadurch kriegt man eine langsame Anwendung nicht schnell und umgekehrt. Unterschiede von Ratz Fatz bis Kaffee trinken gehen liegen hier nie und nimmer!!! Was eindeutig für SQL spricht, ist die bessere Progranmmierer Performance (weshalb ich seit mehr als 5 Jahren nichts anderes mehr mache!!!
- ich misstraue allen Experten, die pauschal wissen wie es schnell geht, das einzige was hier zählt ist vergleichende Messung einer realen Anwendung (keine Blindschleife mit 10.000 Insert Operationen).
mfg
Dieter Bender
@Birgitta
Wenn ich einen normalen CREATE COLLECTION mache, passiert genau das, was Dieter beschreibt.
In der Lib werden Journale sowie Views der SYS-Dateien erstellt.
(Von IDDU sehe ich da allerdings nichts).
Der CRTLF scheint da eben was zu prüfen, so dass eben CRTLF mit Fehler zurückkomt und eben die LF NICHT ERSTELLT.
Wenn man das beim CREATE COLLECTION allerdings ausschalten kann (was ich nicht wusste), soll das mit der LF dann ja wohl funktionieren.
Ansonsten:
Wenn man auf die Journalisierung verzichten kann (muss), sollte man halt CRTLIB verwenden, dann kann alles andere SQL und DDS auf jeden Fall gemischt werden.
Auch mit Journalen (wenn man diese dann manuell erstellt) wird beim CREATE TABLE das Journal automatisch eingetragen.
Allerdings kann das bei "alten" Anwendungen zu einem Massenproblem werden, da hier häufig Unlock's mit Update gelöst werden, so dass viele viele Journaleinträge auflaufen (Beispiel Brain-XPPS, Journal auf TEIL, bei 200 Usern ca. 10GB pro Stunde!).
- default ist ohne Data Dictionary (IDDU) und da sollte DDS select/omit gehen, angelegt wird da ein *DTADCT Objekt und einige QID* Dateien
Antworten tue ich allerdings, weil ich das mit den Journalen so nicht stehen lassen will. Bei normaler Transaktionsverarbeitung ist Journalisierung nicht hinderlich, das Platzproblem ist kein wirkliches, das kann man an den Receivern konfigurieren, inklusive automatischem umhängen und löschen.
Eine Einschränkung gibt es: bei extremen Bulkoperationen (ganze Dateien hin und her schaufeln, zig Millionen Sätze kopieren, da sollte man dann temporär deaktivieren.
mfg
Dieter Bender
@Birgitta
Wenn ich einen normalen CREATE COLLECTION mache, passiert genau das, was Dieter beschreibt.
In der Lib werden Journale sowie Views der SYS-Dateien erstellt.
(Von IDDU sehe ich da allerdings nichts).
Der CRTLF scheint da eben was zu prüfen, so dass eben CRTLF mit Fehler zurückkomt und eben die LF NICHT ERSTELLT.
Wenn man das beim CREATE COLLECTION allerdings ausschalten kann (was ich nicht wusste), soll das mit der LF dann ja wohl funktionieren.
Ansonsten:
Wenn man auf die Journalisierung verzichten kann (muss), sollte man halt CRTLIB verwenden, dann kann alles andere SQL und DDS auf jeden Fall gemischt werden.
Auch mit Journalen (wenn man diese dann manuell erstellt) wird beim CREATE TABLE das Journal automatisch eingetragen.
Allerdings kann das bei "alten" Anwendungen zu einem Massenproblem werden, da hier häufig Unlock's mit Update gelöst werden, so dass viele viele Journaleinträge auflaufen (Beispiel Brain-XPPS, Journal auf TEIL, bei 200 Usern ca. 10GB pro Stunde!).
Hallo Baldur,
das IDDU-Verzeichnis wird nur erstellt, wenn beim CREATE COLLECTION oder beim CREATE SCHEMA "With Data Dictionnary" mit Ja angegeben wird. Der Unterlassungswert ist Nein. Viele Anwender meinen damit seien die Catalog Views gemeint, die automatisch erstellt wird.
IDDU wird nur benötigt, wenn noch mit programmbeschriebenen Dateien gearbeitet wird. Aus diesem Grund ist z.B. im iSeries Navigator schon beim Erstellen eines Schemas diese Option nicht mehr auswählbar.
Ansonsten habe ich eigentlich eine bunte Mischung aus SQL definierten und DDS definierten Schemata bzw. Biblitoheken, mit SQL-Tabellen und DDS beschriebenen Dateien mit Views, Indices und DDS beschriebenen logischen Dateien, ohne je ein Problem gehabt zu haben.
Wenn Du nicht willst, dass das Journal in der Datenbibliothek steht, dann lösche es einfach nach Erstellung des Schemas. Die automatische Journalisierung funktioniert ab V5R3 auch dann, wenn in der Datenbiblitohek der Datenbereich QDFTJRN angelegt ist, in dem die Bibliothek und der Name des Journals in dem die Tabellen aufgezeichnet werden sollen steht.
Übrigens auch DDS beschriebene physische Dateien werden dann automatisch beim Erstellen in diesem Journal registriert.
(Der Datenbereich wird vor der Existenz der Journals QSQJRN in der Datenbibliothek geprüft.)
@Dieter:
- SQL versus DDS: IBM Marketiers behaupten seit mehreren Jahren, dass SQL rundherum schneller sei als DDS, um den schrittweisen Wegfall von DDS Funtionalität schmackhaft zu machen - das hat einer ernsthaften Überprüfung nie stattgehalten.
Hast Du es je ausprobiert? Ich meine gleiche Umgebung, gleiche(s) Programm(e) sogar nur mit native I/O einmal mit DDS beschriebenen physischen Dateien und einmal mit SQL definierten Tabellen mit den gleichen logischen Dateien (mit den gleichen Daten ohne gelöschte Sätze versteht sich) und dann allein auf der Maschine (und das ganze ein paar hundertmal aufgerufen)?
Ich schon und auch wenn Du es nicht glaubst, und ich konnte eine Performace-Verbesserung von über 20% erzielen!
Birgitta
wer sich der Mühe des genauen lesens unterzieht, der wird zwei Sachen erkennen:
erstens ich habe selbstredend, sonst würde ich mich nicht dazu äußern (was soll das überhaupt?!) und zweitens rede ich immer vom realen Betrieb, also gerade nicht von alleine auf der Maschine etc.
Was mich darüber hinaus an dieser Argumentation stört ist die pauschale Art, da gibt es nämlich sehr unterschiedliche Effekte (zum Beispiel immense Verschlechterungen in einem Trigger mit Mix von RLA und SQL), diese überlagern sich und die ganze Sache hängt von der Hardware ab (ich denke da exemplarisch an eine Maschine mit parallel Database Feature und richtig Power, da hängt SQL RLA teilweise dramatisch ab, oder andererseits eine Maschine, die am Anschlag mit RLA sequentiell rumrödelt, auf der der Query Optimizer die Maschine fast zum Stillstand bringt).
Mit solchen Aussagen werden eindeutig falsche Erwartungen geweckt: ich brauche nur auf SQL umstellen und alles wird spürbar schneller und wenn es nicht so ist, dann liegt es nur daran, dass die richtigen Schräubchen nicht gedreht wurden. Nach meinen Erfahrungen kommt es bei SQL darauf an gezielt die Ecken zu bearbeiten, an denen es nicht brummt und dann passt es.
@Dieter:
Hast Du es je ausprobiert? Ich meine gleiche Umgebung, gleiche(s) Programm(e) sogar nur mit native I/O einmal mit DDS beschriebenen physischen Dateien und einmal mit SQL definierten Tabellen mit den gleichen logischen Dateien (mit den gleichen Daten ohne gelöschte Sätze versteht sich) und dann allein auf der Maschine (und das ganze ein paar hundertmal aufgerufen)?
Ich schon und auch wenn Du es nicht glaubst, und ich konnte eine Performace-Verbesserung von über 20% erzielen!
Birgitta
Gut, dann haben wir das ja geklärt.
Der CRTLF mit SELECT/OMIT kann nicht auf einer PF der Art SQL-TABLE erstellt werden.
Das hat insofern mit Lib oder Collection nix zu tun.
Ich denke, hier soll ganz einfach die neue Queryengine bevorzugt werden, damit die gar nicht erst an die alte übergeben muss, wenn SELECT-LF's vorhanden sind.
M.a.w., eine SELCT/OMIT-LF ist auf einer TABLE schlichtweg nicht mehr möglich.