Zugriff (select) von 1 WIN DB2 auf anderes DB2
- Dieses Thema hat 6 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 11 Jahre, 8 Monaten von
Anonym.
-
AuthorPosts
-
19. Mai 2009 um 16:50 Uhr #4038
AnonymInaktivHallo,
kann ich im DB2 unter LUW auf ein anderes DB2 mit select zugreifen ? Im z/OS geht das schon lange über Einträge in die Comm. DB. Gibt es das auch im LUW ?
Konkreter Fall, ich habe 2 DB2 Datenbanken in 1 Instanz auf einem Windows.
Wer weiss wies geht ?
Danke
24. Mai 2009 um 21:41 Uhr #4206
AnonymInaktivHallo Hubert,
bei DB2 z/OS machst Du einen Attach (TSO DSN SY STEM(xyz)) zu einem lokalen System auf dem LPAR. Nur bei einem entfernten System arbeitet man mit Einträgen der CDB und verwendet CO NNECT TO rdb oder arbeitet mit 3-Punkt-Namen .
Bei der DB2 UDB mußt Du die Umgebung (. /sqllib/db2profile) aufbauen, dann den Connect zur Datenbank. Bei einer 2. Datenbank derselben Instanz einfach erneut CO NNECT TO 2nd DB.
Sollte es sich um eine 2. Datenbank an einer 2. Instanz handeln, muß diese registriert werden, ganz so als würde ein Client mit einer Server-Datenbank arbeiten wollen:
[tt]db2 CA TALOG TCPIP NODE …
db2 CA TALOG DB …[/tt]
Im Grunde wie die Registrierung einer entfernten DB2 z/OS Datenbank in der CDB!Viel Erfolg
Gernot
19. Januar 2012 um 12:51 Uhr #4332
AnonymInaktivHallo Gernot,
auch wenn der Eintrag schon etwas älter ist und meine Umgebung etwas anders ist (Zwei verschiedene Instanzen auf einem Linux Rechner). Trift diese Problematik genau.
Ich habe in der Instanz1 die Instanz2 und die Datenbank registriert (catalog node…, catalog db…).
Ich mache einen connect auf die DB der Instanz1. Alles wunderbar. Wenn ich jetzt einen connect auf die registrierte DB mache, wird auch diese erfolgreich connected aber jetzt kann ich keine SQL Befehle mehr auf die 1. DB absetzten. Bei so etwas wie select * from db1.schema.table bekomme ich den Fehler: db1.schema.table is an undefined name.Wie kann ich den festellen ob ich mit beiden Datenbanken connected bin???
Wie spreche ich die Tabellen auf der zuerst connecteten DB an???Vielen Dank im voraus schon für alle Infos.
Gruß
Ingo
20. Januar 2012 um 16:47 Uhr #4422
AnonymInaktivHallo Ingo,
wenn das DB2 Feature "Data Federation" nicht zur Verfügung steht, können keine 2 Datenbanken (Datenquellen) in einem Statement miteinander verbunden werden.
Innerhalb einer Unit of Work kann man mit CONNECT TO DB zwischen den Datenbanken hin und herschalten und dann SQL Statements ausführen.
Mit dem Command db2 "get connection state" kann die Verbindung abgefragt werden; mit einem SQL Statement geht dies am einfachsten per "SELECT CURRENT SERVER FROM SYSIBM.SYSDUMMY1".
Es gibt jedoch auch eine Ausnahme: Man kann sehr komfortable mit einem Cursor auf eine entfernte Datenbank zugreifen und die Inhalte an einer lokalen DB laden:
[code sql]DECLARE mycurs CURSOR DATABASE dbsource USER dsciaraf USING mypasswd
FOR SELECT TWO,ONE,THREE FROM abc.table1
  LOAD FROM mycurs OF cursor INSERT INTO abc.table2[/code]
Auch mit einem SQL Statement:CALL SYSPROC.ADMIN_CMD ('
     LOAD FROM (     DATABASE REMOTEDB
                SELECT * FROM OTHERUSER.T1)
                OF CURSOR
                INSERT INTO MYUSER.T1 NONRECOVERABLE');Wenn Du noch mehr Infos brauchst, bitte Umgebung etwas beschreiben (DB2 Version, Ablaufumgebung etc)
Gruß
Gernot
24. Januar 2012 um 7:09 Uhr #4479
AnonymInaktivHallo Gernot,
vielen Dank für Deine Antwort.
Leider haben wir das DB2 Feature "Data Federation" nicht, und das mit dem "declare cursor" funktioniert so auch nicht.die Ablaufumgebung ist die Linux shell eines SLES10 SP1 des Instanceowners der Version DB2 8.2 (ich weiß ist schon abgelaufen, brauchen wir aber noch, da ein OS2-Client noch darauf zugreift und für OS2 gibts nach 7.x, soweit ich weiß keine RT-Clients mehr.)
Mein Ziel ist mittels eines Scripts Datensätze die ich via select aus einer OS/390 DB Abfrage (via DB2 Connect Gateway) hole in die Tabelle einer Datenbank der laufenden Instance zu schieben.
Wie gesagt, die Einzelzugriffe (connect,select,insert…) auf die DB’s funktionieren.Die Idee mit den Cursor ist interessant. Leider bekomme ich einen Fehler wenn nach der Cursor Deklaration die Info für Datenbank und Authorisierung "DATABASE dbsource USER dsciaraf USING mypasswd" kommen. Der Befehl erwartet hier schon das "for select…"
Ich habe das dann zum testen nochmal mit einer 2 DB des Instanceowner probiert, klappt aber auch nicht.
Hängt das mit der verwendeten Version zusammen???vielen Dank schon für weitere Anregungen.
Gruß
Ingo
24. Januar 2012 um 20:23 Uhr #4508
AnonymInaktivHallo Ingo,
die Umgebung ist wirklich ziemlich alt, aber nicht zu alt für den "traditionellen" Weg:
[code sql]
REM *** Verbindung zur DB2 z/OS bzw DB2 for OS/390
REM *** via DB2 Connect Gateway
db2 CONNECT TO <ddcsdb> USER tsouser USING tsopassword
db2 "EXPORT TO /home/user/myexportfile.ixf OF IXF SELECT * FROM QUELLE.TABELLE_AM_DB2_ZOS WHERE WAS_ICH_WILL =1"
db2 CONNECT RESET
REM *** Verbindung zur lokalen UDB Datenbank
db2 CONNECT TO LOCALDB
db2 "IMPORT FROM /home/user/myexportfile.ixf OF IXF INSERT|INSERT_UPDATE|REPLACE|REPLACE_CREATE INTO ZIEL.TABELLE_AM_LINUX"
db2 CONNECT RESET [/code]
Alles andere geht in dieser Konstellation definitiv nicht!Frage: Welche Art von Anwendung wird auf dem OS/2 Client betrieben?
Gruß
Gernot
26. Januar 2012 um 11:19 Uhr #4529
AnonymInaktivHallo Gernot,
danke für die Antwort.
Dann muss ich mir doch die Exportrechte für die OS/390 Tabellen besorgen.
Auf dem OS/2 Client läuft noch unser altes BDE-System (Eine Anwendung die von IBM für uns entwickelt wurde) mit dem derzeit noch von den Terminals die Daten gesammelt werden.
Gruß
Ingo
-
AuthorPosts
You must be logged in to reply to this topic.