Outerjoin über zwei Datenbankinstanzen in Oracle

[-tobi-]

Ich brauche einen Outerjoin über 2 Datenbankinstanzen und die Möglichkeit, wie ich diesen von Delphi aus absetze. :wall:

[Leuselator]

liegen die DB-Instanzen auf der gleichen Maschine?

[-tobi-]

Ja, auf dem gleichen Server!

[Robert_G]

Mit DB Links ist das ziemlich easy. ;)

DB liegt auf anderer Maschine:

SQL-Code:

CREATE DATABASE LINK ServiceName.Domain.de
CONNECT TO CURRENT_USER
   USING 'ServiceName';

Auf der gleichen Maschine reicht das:

SQL-Code:

CREATE DATABASE LINK ServiceName
CONNECT TO CURRENT_USER;

Bei beiden Schnipseln wird mit dem gleichen Username/password des aktuellen Schemas eine Anmeldung auf die Remote DB gemacht.

ServiceName ist der Service Name der Remote DB
Domain.de muss mit der richtigen Domäne ersetzt werden

SQL-Code:

SELECT emp.ename, emp.DeptNo, dept.loc
FROM   scott.emp emp
      ,scott.dept@DeinDBLink dept
WHERE  emp.DeptNo = dept.DeptNo

Mit Shared DB Links geht die Netzwerk Performance auch bei vielen parallelen sessions nicht in die Knie.

Zitat:

Zitat von Oracle Doku -> Managing a Distributed Database

...
Shared database links are not useful in all situations. Assume that only one user accesses the remote server. If this user defines a shared database link and 10 shared server processes exist in the local database, then this user can require up to 10 network connections to the remote server. Because the user can use each shared server process, each process can establish a connection to the remote server.

Clearly, a non-shared database link is preferable in this situation because it requires only one network connection. Shared database links lead to more network connections in single-user scenarios, so use shared links only when many users need to use the same link. Typically, shared links are used for public database links, but can also be used for private database links when many clients access the same local schema (and therefore the same private database link).

Creating Shared Database Links
To create a shared database link, use the keyword SHARED in the CREATE DATABASE LINK statement:

CREATE SHARED DATABASE LINK dblink_name
[CONNECT TO username IDENTIFIED BY password]|[CONNECT TO CURRENT_USER]
AUTHENTICATED BY schema_name IDENTIFIED BY password
[USING 'service_name'];


The following example creates a fixed user, shared link to database SALES, connecting as SCOTT and authenticated as JANE:

CREATE SHARED DATABASE LINK link2sales
CONNECT TO scott IDENTIFIED BY tiger
AUTHENTICATED BY keith IDENTIFIED BY richards
USING 'sales';


Whenever you use the keyword SHARED, the clause AUTHENTICATED BY is required. The schema specified in the AUTHENTICATED BY clause is only used for security reasons and can be considered a dummy schema. It is not affected when using shared database links, nor does it affect the users of the shared database link. The AUTHENTICATED BY clause is required to prevent unauthorized clients from masquerading as a database link user and gaining access to privileges information.
...

[-tobi-]

Wir erstellen unseren Link folgendermaßen:

SQL-Code:

create public database link test connect to dbdoku identified by "dbdoku" using 'DBTEST';

Dieser Befehl funktioniert auch, aber die Abfrage liefert nur die Teilmenge einer Spalte, und in der anderen 'NULL'.

Abfrage:

SQL-Code:

SELECT T.Tabellenname, A.Table_name FROM All_Tables A, TTabellen@Test T WHERE T.Tabellenname = A.Table_name(+) and owner = 'DBTEST';

oder:

SQL-Code:

Select T.Tabellenname, A.Table_name FROM All_Tables A right join TTabellen@Test T ON T.Tabellenname = A.Table_name;

Wo liegt der Fehler in unseren SQL-Befehlen?

Schon jetzt, danke für die Mühe.

[Robert_G]

Das sieht so schon OK aus...
Frage:
Ist DBTest wirklich ein User, der die Tabellen besitzt?
Wenn ja, hat der User DBDoku darauf SELECT-Rechte? (Nur dann sind sie in all_Tables aufgelistet)

[-tobi-]

DBTEST ist eine DB-Instanz.
DBDOKU hat auf DB-Instanz 'DBBE' Rechte zum auslesen der eigenen Tabellen.

[Robert_G]

Das Problem scheint ganz einfach...

SQL-Code:

 And Owner = 'DBTEST';

.. zu sein.

Du fragst ja damit die Tabellen in dem USER DBTEST ab.

[-tobi-]

Die Abfrage ist in sofern falsch, weil sie bei einer Abfrage bei der Tabelle A (Tabelle von OuterJoin, die mehr Werte liefern soll) richtige Werte bringt, aber bei Tabelle B (Tabelle, die nur übereinstimmende Werte liefern darf) immer nur 'NULL' zurückliefert!

Dadurch ist natürlich kein Vergleich möglich.

Liegt das am SQL-Befehl, oder am Datenbank-Link?

[Robert_G]

Was bekommst du denn dabei?

SQL-Code:

SELECT T.Tabellenname
FROM   TTabellen@Test T

Hast du dann alle Tabellen?

[-tobi-]

Bei den Einzelabfragen wie

SQL-Code:

SELECT T.Tabellenname 
FROM   TTabellen@Test T

oder

SQL-Code:

SELECT Table_name 
FROM   All_tables where owner = 'DBTEST'

erhalte ich die richtigen Ergebnisse.

[Leuselator]

Kenne Oracle nicht. Wenn owner kein Feld in der Tabelle "All_Tables ist, dann wird das wohl nicht gehen ansonsten versuch mal:

SQL-Code:

         SELECT T.Tabellenname
              , A.Table_name 
           FROM All_Tables A 
LEFT OUTER JOIN TTabellen@Test T --Left outer sollte die Lösung bringen...
             ON T.Tabellenname = A.Table_name
          WHERE A.owner = 'DBTEST'

Gruß

[-tobi-]

Ich versuche es momentan mit einer Delphi-Lösung abzufangen.

[Robert_G]

Wenn Leuselators Abfrage nicht klappt dann fresse ich einen Besen! :mrgreen:
Was mich dabei stört ist, dass es damit auch hätte klappen müssen. :gruebel:

SQL-Code:

SELECT T.Tabellenname
      ,A.Table_Name
FROM   All_Tables     A
      ,TTabellen@Test T
WHERE  A.Table_Name = T.Tabellenname(+) And
       Owner = 'DBTEST'

[-tobi-]

Danke für die Hilfe.

Ich habe das Problem über Delphi gelöst (es soll später einmal eine Update-Funkion werden).

Ich erstelle jetzt zwei getrennte Abfragen, die ich in 2 Arrays einlese und danach vergleiche.

Ich habe den OuterJoin noch einmal ausprobiert. Er funktioniert jetzt mit den Daten, die ich mit der Funktion abgeglichen habe, mit den Testdaten funktioniert es immer noch nicht.

Es muß an den Datentypen liegen.

Nachdem ich jetzt eine Lösung habe, brauche zu diesem Theme keine Lösung mehr.

Nochmals Danke
Tobi

[Robert_G]

Heißt das, dass ich jetzt keinen Besen fressen muss :?: :roll:
:mrgreen: