SQL-Pakete verteile System

[BenderD]

... das geht aber nur bei ODBC Verbindungen, bzw. bei Java mit extended dynamic package support.

[volker.goers]

Danke schon mal für das erste Feedback!

Das mit der QTEMP als SQL-Paket-Lib geht nur bei ODBC bzw. Java?

Wie würde ich denn die QTEMP als Paket-Lib definieren?
Im CRTSQLRGI-Befehl bei der Option SQLPKG die QTEMP vorgeben?

Das mit der Versions-Kennzeichnung der einzelen Monitor-Programme hatte ich mir auch schon überlegt, falls es nix eleganteres gibt...

[Fuerchau]

Dafür ist der Parameter da, auch bei ODBC gebe ich immer QTEMP an, da es manchmal Berechtigungsprobleme gibt und unter z.B. Excel alle Pakete gleich heißen.
Mit QTEMP hat man nur den Startverlust beim Verbindungsaufbau, der aber zu vernachlässigen ist.

Was noch ein Problem sein kann sind die QZDASOINIT-Jobs selber.
Diese laufen ja als Prestart und werden durchaus von verschiedenen Verbindungen wieder verwendet.
Bei temporären Arbeitsdateien in QTEMP (z.B. Global Temporary) kann das zu unerlaubten Dateneinsichten führen, da die QTEMP ja nie aufgeräumt wird.

Hier kann man aber im Subsytem die Wiederverwendung bei den PJE's abschalten und die Anzahl neuer Jobs hochsetzten, dann bekommt jede Anmeldung eine saubere neue Umgebung.
Dan klappts auch mit den SQLPKG's in QTEMP.

[volker.goers]

Na, das klingt ja vielversprechend und ist ein Versuch wert.
Ich werde mal die Tage bei einem Client auf Paket-Lib auf QTEMP umstellen, dann dürfte er sich schon nicht mehr mit dem anderen Client beißen....
Ich werde ein Feedback geben!

Danke schon mal!

Volker

[volker.goers]

Guten Morgen Zusammen,

so, habe das jetzt mit der QTEMP als SQL-Paket-Bibliothek ausprobiert:

Habe auf Client A das Monitorprogramm mit CRTSQLRPGI und der Option SQLPGK(QTEMP/*OBJ) neu erstellt.
Auf Client B habe ich das Programm so belassen [Option SQLPGK(*OBJLIB/*OBJ)].

Nun müsen beide Programme definitiv unterschiedliche Konzistenztoken zu dem SQL-Paket auf dem Server aufweisen.

Nun habe ich auf beiden Clients die Monitorprogramme gestartet.
Wie erwartet hat das Monitorprogramm von Client B das SQL-Paket auf dem Server für sich passend ausgetauscht und gelockt.
Das Monitorprogramm auf Client A scheint aber auch glücklich zu sein, denn das Programm läuft.
Hier arbeitet das Programm, wie Fuerchau schon erwähnt, wohl mit seinem eigenen SQL-Paket in der QTEMP im QRWTSRVR-Job der auf dem Server läuft
(was noch zu prüfen wäre ).

Ich habe jetzt leider noch nicht genügend Daten um auf beiden Clients einen Belastungstest durchzuführen, aber für mich schauts erst mal gut aus.
Dass beide Programme laufen und zyklisch nach Daten auf dem Server suchen, stimmt mich äußerst optimistisch.

Jetzt muss ich nur noch das Softwarehaus umstimmen, dass es seine Umwandlungstools anpasst.
Diese verwende ich auch, auch deren Bibliotheken, damit die Anwendung releasefähig ist.
Nehme aber an, dass das kein Problem darstellen wird.

Ich danke nochmal allen für die Anmerkungen und Tips.

Grüße
Volker

[Fuerchau]

Per WRKJOB kannst du auch den Inhalt der QTEMP (falls in Libl) ansehen.
Perfomance-Nachteile hat das nicht, da das Paket ja nur einmalig übertragen wird.
Bei der Erstverwendung eines SQL's wird u.U. der Zugriffsweg noch mal analysiert, aber das wars halt.

Wenn allerdings dein Programm zyklisch die Daten auf dem Ziel mit Connect/Disconnect prüft, erfolgt der Vorgang allerdings jedes mal.
Ich konnte bisher nie irgendwelche Nachteile feststellen.

[volker.goers]

CONNECT und DISCONNECT verwende ich nicht.
Ich verwende die Drei-Punkt-Notation (z.B. select * from SYSTEM.LIB.TABELLE).
Sind hauptsächlich INSERTs und UPDATEs auf die lokalen Tabellen des Clients mit Daten vom Server.

Die Anwendung ist zum Glück nicht zeitkritisch.
Was die Auslastung es Server-Systems betrifft muss ich mich überraschen lassen wenn alle 16 Clients dann mal aktiv werden....
Auf den einzelnen Clients fehlt mir auch die Erfahrung, da noch kaum Daten darüber laufen.
Alles ja noch im Beta-Test.

[Fuerchau]

Es gilt dasselbe wie auch für lokale Abfragen:
Indizes sind das A&O des SQL-Zugriffes.
Wenn du dann keine 1000de von Daten abholst ist das auch unkritisch.

Bei sog. ETL-Prozessen via ODBC in einen SQL-Server mit BulkLoad können je nach Datenbreite (also Anzahl Felder) bis zu 100.000 Zeilen/Sekunde abgeholt werden ohne dass auf der IBM i nennenswerte CPU-Last auftaucht.
Selbst das Netzwerk ist nur gering ausgelastet.
Bei einem Test ohne SQL-Server konnte ich bis zu 250.000 Zeilen/Sekunde abholen (8 Spalten).
Mit (nicht realem) Parallelbetrieb in dieser Umgebung mit 5 Tasks, war das Netzwerk (1GBit) am Ende und die IBM i bei ca. 40%.

M.a.W.: Ich hoffe das beruhigt dich;-).