CRTLIB oder CREATE SCHEMA/COLLECTION

[HeymannJ]

Hallo *ALL,

ich möchte per SQL Dateien in einer neu zu erstellenden Bibliothek generieren und bereits bestehende Dateien, die mittels DDS erstellt wurden aus einer bestehenden Bibliothek in die neue Bibliothek kopieren.

Was ist nun besser, die neue Lib per SQL (CREATE SCHEMA/COLLECTION) oder herkömmlich mittels CRTLIB zu erstellen ?

Worin liegen die Unterschiede oder mit welchen "Überraschungen" kann ich rechnen ?

Gruß
Jürgen

[Fuerchau]

CRTLIB erstellt einfach eine Lib.
CREATE SCHEMA erstellt eine Lib, Journal und Journalempfänger sowie SYSxxx-Views.

Zusätzlich wird jede Tabelle, die in diese Lib kopiert wird, im Journal aufgezeichnet.

Desweiteren wird das Erstellen von anderen Objekten als Tabellen/Views/Procedures/Functions usw. abgelehnt !

Man kann also nicht irgend eine DTAARA, ein Programm oder andere Nicht-SQL-Objekte in diese Lib kopieren, da sie im Journal nicht aufgezeichnet werden können.

[Pikachu]

Man kann also nicht irgend eine DTAARA, ein Programm oder andere Nicht-SQL-Objekte in diese Lib kopieren, da sie im Journal nicht aufgezeichnet werden können.

Unter V5R4 geht das anscheinend aber doch (hab's gerade ausprobiert)!?

[Fuerchau]

Ich habe da auch schon Fehlermeldungen bekommen, ich weiß allerdings nicht mehr bei welchem Objekttyp.

[BenderD]

Programme und DTAARA (leider) dürften da kein Problem machen, ich nehme mal eher an dass Dateien ohne Quelle (mit Länge erstellt), da Probleme machen könnten.
Aufpassen muss man in jedem Fall, dass man bei Data Dictionary no sagt, damit sind nämlich IDDU Beschreibungen gemeint - und dann gehen ein paar Sachen nicht, was unangenehm werden kann, abgesehen davon braucht diesen Schmonz wohl keiner mehr.

D*B

Ich habe da auch schon Fehlermeldungen bekommen, ich weiß allerdings nicht mehr bei welchem Objekttyp.

[HeymannJ]

Hallo zusammen,

habe ich denn irgendeinen Vorteil dadurch wenn ich die Lib per CREATE COLLECTION erstelle ?

Alle die per CREATE COLLECTION erstellten SYS...-Tabellen befinden sich ja auch in der QSYS2.
Gibt es dadurch, dass diese SYS..-Tabellen in der selben LIB liegen einen deutlichen Performance-Schub bei SQL-Abfragen ?

Ausserdem wollen wir die Journale für das Aufzeichnen der Tabellen in einer zentral, eigens dafür vorgesehenen Bibliothek ablegen.

Gruß
Jürgen

[BenderD]

Hallo,

Vorteile:
- man liegt näher am SQL Standard (Portierbarkeit der Erstellungsskripte der Datenbank
- das Repository liegt näher am DB2 Standard (Portierbarkeit innerhalb der Familie)
- Abgeschlossenheit bezüglich save/restore
Von der Performance her ist die Differenz, falls vorhanden, unter der Messbarkeitsschwelle.
Das mit den Journalen kann einen geringen Vorteil haben, wenn man dieser Lib einen eigenen ASP spendiert, was aber bei der wachsenden Entfernung zwischen dem, was ein OS für eine Platte hält und dem, was ein Controller draus macht, auch nichts messbares mehr hergibt.
Man kann sich natürlich auch die Frage stellen, warum man mehrere Schemas haben will, wenn die doch zusammen gehören.

D*B

Hallo zusammen,

habe ich denn irgendeinen Vorteil dadurch wenn ich die Lib per CREATE COLLECTION erstelle ?

Alle die per CREATE COLLECTION erstellten SYS...-Tabellen befinden sich ja auch in der QSYS2.
Gibt es dadurch, dass diese SYS..-Tabellen in der selben LIB liegen einen deutlichen Performance-Schub bei SQL-Abfragen ?

Ausserdem wollen wir die Journale für das Aufzeichnen der Tabellen in einer zentral, eigens dafür vorgesehenen Bibliothek ablegen.

Gruß
Jürgen

[Fuerchau]

Der "Vorteil" von Schemas ligt ausschließlich in der SQL-Programmierung.
Die SYS-Tabellen sind eingeschränkte Views auf die SQL-Objekte deiser Lib.

Sog. Schema-Abfragen sind dann eben leichter, da man ausschließlich diese Objekte sieht.

Wichtig ist dann auch, bei der SQL-Namenskonvention auf SQL statt SYS umzustellen und ggf. eine DFTRDBCOL anzugeben.

Bei ODBC-Abfragen kann hier auch direkt die SQL-Sicht auf das Schema beschränkt werden.