Umsetzung LF mit Omit Klausel in View/Index

[Fuerchau]

@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!).

[BenderD]

- 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!).

[B.Hauser]

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