SQL über zwei Partitions

[Fuerchau]

Nunja, in der Theorie ganz nett, in der Praxis natürlich mit Aufwand verbunden.
Weiteres siehe hier:
https://www.ibm.com/support/knowledg.../rbal1drdh.htm
Also ohne Zusatzprodukte geht das nicht.
Ist ja auch verständlich.
Um deine Abfrage durchzuführen muss die Join-Tabelle erst mal komplett lokal kopiert werden, dann kann der Join durchgeführt werden, anschließend kann die Kopie verworfen werden.
Anders macht es z.B. auch nicht SQL-Server (Verbindungsserver) oder z.B. MS-Access.
Über die Performance darf man sich dann allerdings keine Gedanken machen.

[BenderD]

Nunja, in der Theorie ganz nett, in der Praxis natürlich mit Aufwand verbunden.
Weiteres siehe hier:
https://www.ibm.com/support/knowledg.../rbal1drdh.htm
Also ohne Zusatzprodukte geht das nicht.
Ist ja auch verständlich.
Um deine Abfrage durchzuführen muss die Join-Tabelle erst mal komplett lokal kopiert werden, dann kann der Join durchgeführt werden, anschließend kann die Kopie verworfen werden.
Anders macht es z.B. auch nicht SQL-Server (Verbindungsserver) oder z.B. MS-Access.
Über die Performance darf man sich dann allerdings keine Gedanken machen.

... dieses verlinkte Produkt leistet das auch noch nicht, da müsste man erstmal permanent remote Kopien pflegen lassen, bevor man mit einem SQL drauf darf. Das Zauberwort heißt hier InfoSphere Federation Server (falls das nicht gerade wieder umbenannt wurde). Da brauchst Du allerdings noch eine nicht-Ei-DB2 und wenn Du die Preise für das Produkt siehst und den Einführungsaufwand, willst Du das nicht mehr haben...

D*B

[cbe]

Ein RPG Programm könnte die ferne Datei per DDMF lesen, ohne dass alle Daten kopiert werden müssten.
Evtl. ist dieser Ansatz einfacher?

[BenderD]

... das DDMF kann noch erheblich weniger als ein SQL connect zur remote Datenbank!!!

[Fuerchau]

Nun, wenn du per sequentiellem Read die Daten selektierst und lokal zwischenspeicherst, hast du trotzdem die gesamte Datei kopiert, auch wenn nicht alles gespeichert ist.
DDMF hat diverse Limits:
- Kein Zugriff per Schlüssel (SETLL, ...)
- Kein Zugriff per SQL
- Ausschließlich statische Definitionen zur Compilezeit
- max. 16 parallele Opens per Job
- max. 256 parallele Verbindungen per Zielsystem
Und wie Dieter schon sagte, SQL kann erheblich mehr.
Du musst dir halt nur die Mühe machen, deine SQL's selber zu zerlegen und die Daten aus den anderen Systemen partiell laden.

[prsbrc]

Also ich hab folgenden Workaround() im www gefunden:
https://www.itjungle.com/2012/08/08/fhg080812-story01/
Ich habs aber nicht probiert da ich keine zweite dastehen hab :-)

Grtx!
Christian

[Fuerchau]

Das behebt nicht dein Problem, dass Queries dieser Art nicht optimierbar sind.
D.h., dass deine UDTF für die Satzauswahl per Parameter zuständig ist um dann ein Subset an Daten zu liefern, dass dann per Where/Join-Klauseln ggf. weiter eingeschränkt wird.

Einfacher sind da eher Konzepte, für ausgewählte Tabellen mit Replizierung zu arbeiten. M.a.W., die benötigten Daten der jeweils anderen Systeme lokal zu halten und regelmäßig zu aktualisieren.

[BenderD]

... viel Lärm um nichts, das ging mit QMQRY schon solange ich denken kann:
1. QMQRY selektiert Daten von remote1 und schreibt in lokale Tabelle
2. QMQRY selektiert Daten von remote2 und schreibt in lokale Tabelle
3. UDTF lässt QMQRY1 und QMQRY2 laufen und joined mit lokalen Tabellen, wie immer es will.

Immer wieder erstaunlich, was man da an die DB2 Clientel immer wieder als sensationell neu verkauft.

D*B

PS: und schneller ist das wahrscheinlich auch noch...

[Fuerchau]

@Dieter: Du machst es dir manchmal zu einfach.
Wenn es neues gibt will es auch verwendet werden.
Telefonieren konnte ich schon mit meinem Wählscheiben-Telefon und der Klingelton (Nostalgie) war schon drin. Ich brauche heute immer noch kein Smartphone.