2003-01-News-Wessolowski-Generic_Connectivity_DOAG

68621083
Integration von non-Oracle Datenbanken über ODBC/OLE-DB
Autor: Klaus Wessolowski, Oracle Deutschland GmbH
Bereits mit Einführung von Oracle8i wurde die Technologie zur Anbindung von Fremdsystemen auf die
Heterogeneous Services umgestellt, d.h. alle Oracle Gateway Produkte nutzen seitdem diese Technik. In diesem
Rahmen wurden auch die sogenannten Generic Connectivity eingeführt, eine Möglichkeit über ODBC oder OLE-DB
Zugriff auf non-Oracle Systeme wie Access, Foxpro, SQL-Server etc. zu ermöglichen. Generic Connectivity ist eine
Möglichkeit kostengünstig auf diese Systeme zuzugreifen, insbesondere wenn es sich um einfache Anforderungen
handelt. Die leistungsfähigeren Oracle Transparent Gateways werden dadurch nicht ersetzt. Dieser Artikel soll dazu
beitragen, Generic Connectivity richtig zu konfigurieren.
Funktionsweise
Generic Connectivity funktioniert im wesentlichen wie die Oracle Gateways unter UNIX oder Windows. Der
Gateway Prozess (auch Agent genannt) wird vom Oracle Listener gestartet und ist so lange aktiv, wie die Verbindung
zum Zielsystem besteht. Dieser Prozess wird, wie auch die Gateway-Prozesse, nicht direkt vom Client angesprochen,
sondern über einen Database-Link, der im Oracle Server angelegt wird. D.h. der Client meldet sich an der Oracle
Datenbank an. Wenn er über einen Database-Link auf ein Objekt in einem anderen System zugreift, wird, wie auch
beim Zugriff in normalen verteilten Oracle-Umgebungen, eine Verbindung vom Oracle-Server zum Zielsystem
aufgebaut.
Der Server verhält sich also zum Zielsystem wiederum wie ein Client. Dieses Verfahren bietet absolute Transparenz,
die Daten des Zielsystems erscheinen für die Anwendung als lägen sie in der Oracle Datenbank. Zudem übernimmt
die Oracle Datenbank die Datentyp-Konvertierungen sowie das Postprozessing für SQL-Funktionen, die es im
Zielsystem ggf. nicht gibt.
Oracle Instanz
Das vorliegende Beispiel demonstriert den Zugriff auf die Oracle Datenbank, von der aus auch die Verbindung
aufgebaut wird. Dies ermöglicht einen ‚stand-alone’ Test. Ein Zugriff auf andere Zielsysteme ist dann durch einfache
Umdefinition der ODBC Konfiguration möglich.
Die Schritte zum Aufsetzen der Generic Connectivity sind im folgenden näher beschrieben:
1.
2.
3.
4.
5.
6.
7.
ODBC Konfiguration
Konfiguration des Agents
Einrichten der Heterogeneous Services im Oracle Server
SQL-Net Konfiguration für den Oracle Server
SQL-Net Konfiguration für den Listener
Anlegen des Database-Links
Fehlermöglichkeiten
Page 1 of 6
68621083
1. ODBC Konfiguration:
Mit dem ODBC-Admin Utility wird ein System DSN zum Zielsystem erstellt.
In diesem Fall zur Oracle Datenbank mit dem 9.0.11 ODBC Treiber.
Die Userid wird nicht ausgefüllt, sie kann beim Testen der Verbindung manuell eingegeben werden und wird über
den Database-Link später beim Zugriff auf die Datenbank übergeben.
Es empfiehlt sich, diese Verbindung zu testen, bevor mit der weiteren Konfiguration fortgefahren wird.
Page 2 of 6
68621083
2. Konfiguration des Agents
Auch der Agent benötigt eine SID. Für dieses Beispiel wurde ODBCKWDB gewählt. Daraus ergibt sich auch der
Name der init.ora-Datei für den Agent. Im Verzeichnis $ORACLE_HOME\hs\admin’ befinden sich entsprechende
Beispiele. Es muss in diesem Verzeichnis eine neue Datei mit dem Namen „initODBCKWDB.ora“ erzeugt werden.
Hier wird über den Parameter HS_FDS_CONNECT_INFO der Name der unter 1. erstellten System DNS angegeben.
# This is a sample agent init file that contains the HS parameters that are
# needed for an ODBC Agent.
#
# HS init parameters
#
HS_FDS_CONNECT_INFO = KWDB
HS_FDS_TRACE_LEVEL = OFF
#
# Environment variables required for the non-Oracle system
#
#set <envvar>=<value>
3. Konfiguration der Heterogeneous Services im Oracle Server
Um die Heterogeneous Services nutzen zu können, müssen einige Tabellen und Views in dem Server, von dem aus
der Zugriff erfolgen soll, in der Datenbank vorhanden sein. Dies kann man z.B. mit dem Befehl:
DESCRIBE HS_FDS_INST prüfen. Sind die HS-Objekte nicht vorhanden, kann man sie mit dem Script
CATHS.SQL anlegen. Das Script befindet dich in Oracle_HOME\rdbms\admin und muss unter dem user SYS
gestartet werden..
4. Konfiguration der TNSNAMES.ORA des Oracle Servers
Die tnsnames.ora muss um den Eintrag für den Agent erweitert werden:
####################################
# TNSNAMES.ORA Configuration File:d:\oracle\ora90\NETWORK\ADMIN\tnsnames.ora
# Generated by Oracle Enterprise Manager V2
# Date..........: Fri Sep 07 15:38:14 CEST 2001
####################################
KWDB.DE.ORACLE.COM =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = kwessolo-LAP)(PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = kwdb.world))
)
Page 3 of 6
68621083
ODBCKWDB.DE.ORACLE.COM =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = kwessolo-LAP)(PORT = 1521))
(CONNECT_DATA = (SID = ODBCKWDB))
(HS = OK)
)
Der erste Eintrag in diesem Beispiel ist der Eintrag, den sowohl der Client zur Anmeldung an die Datenbank benötigt
als auch (in diesem Fall - Loopback) der Eintrag, der bei der ODBC Konfiguration als Zielsystem verwendet wurde.
Der zweite Eintrag dient zur Beschreibung wie der Server zum Agent kommt, d.h. dieser Alias wird später im
Database Link benutzt.
Wichtig ist der Parameter HS=OK und zwar an der richtigen Stelle (Klammern beachten)!
5. Konfiguration der LISTENER.ORA für den Agent
Die listener.ora des Listeners, der den ODBC-Agent starten soll, muss wie folgt erweitert werden:
# LISTENER.ORA Network Configuration File: D:\oracle\ora90\network\admin\listener.ora
# Generated by Oracle configuration tools.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = kwessolo-LAP)(PORT = 1521))
)
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = D:\oracle\ora90)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = kwdb.world)
(ORACLE_HOME = D:\oracle\ora90)
(SID_NAME = kwdb)
)
(SID_DESC =
(ORACLE_HOME = d:\oracle\ora90)
(SID_NAME = ODBCKWDB)
(PROGRAM=hsodbc)
)
)
Page 4 of 6
68621083
Wichtig ist die SID_DESC für die ODBCKWDB und hier der Eintrag (PROGRAM=hsodbc). Dadurch startet der
Listener den entsprechenden Agent. Wenn der Parameter nicht angegeben wird, startet der Listener automatisch das
Programm ‘oracle’, also einen normalen Oracle Server Prozess!
Nach der Änderung der listener.ora muss dem Listener der neue Eintarg bekannt gemacht werden, entweder
durch Neustart oder besser durch den reload Befehl des lsnrctl.
Laufen Datenbank und Listener auf dem selben System, kann man natürlich auch eine IPC Verbindung zum Listener
nutzen. Dann muss natürlich auch in der ADRESS_LIST des Listeners ein entsprechender Eintrag gemacht werden.
6. Einrichten des Database Links
Nachdem die Konfiguration beendet ist, muss nur noch der Database-Link angelegt werden, der den SQL-Zugriff auf
das Zielsystem ermöglicht. Es können sowohl ‚private’ als auch ‚public’ Database-Links angelegt werden. Die
Angabe von Userid und Password ist optional, werden die Angaben weggelassen, wird die Userid und das Passoword
verwendet, mit dem der Anwender an der Datenbank angemeldet ist.
create [public] database link HO [connect to scott identified by tiger] using ‘ODBCKWDB’.
HO ist der default Name des Gateways, wenn man nicht DB_NAME im init.ora des Gateways angibt. Wenn man den
init.ora Parameter der Datenbank GLOBAL_NAMES=TRUE gesetzt hat, muss der Name des Database-Links
identisch sein mit dem Namen des Gateways (Agents).
Danach sollte
select * from emp@ho;
funktionieren.
Will man in Anwendungen den Zugriff über den Database-Link transparent halten, empfiehlt es sich, Synonyme oder
Views einzurichten, z.B.:
create synonym angestellte for emp@ho;
Damit kann man dann auch create table localemp as select * from angestellte schreiben.
7. Fehlermöglichkeiten
ORA-28509: Einrichten einer Verbindung zu Fremdsystem nicht möglich
ORA-02063: vorangestelltes line von HO
 Vermutlich Fehler in der TNSNAMES.ORA (HOST oder PORT falsch)
ORA-03113 : end-of-file on communication channel
ORA-02068: following severe error from <name>
Remote HO agent received unexpected rpc disconnect.
ncropi_recv_procid, called from horg.c
 caths.sql ist vermutlich nicht, oder nicht als SYS gelaufen.
ORA-28546: connection initialization failed, probable Net8 admin error
ORA-02068: following severe error from HO
ORA-03114: not connected to ORACLE
 (HS=OK) fehlt in der TNSNAMES.ORA
In der Listener.log sollte bei erfolgreichem Verbindungsaufbau folgender Eintrag zu finden sein:
Page 5 of 6
68621083
28-MAI-2002 18:20:36 * (CONNECT_DATA=(SID=ODBCKWDB)) * (ADDRESS=(PROTOCOL=tcp)
(HOST=140.84.23.80) (PORT=1169)) * establish * ODBCKWDB * 0
sowie:
28-MAI-2002 18:20:39 * (CONNECT_DATA=(SERVICE_NAME=kwdb.world)
(CID=(PROGRAM=D:\oracle\ora90\bin\hsodbc.exe)(HOST=kwessolo-lap)(USER=SYSTEM))) *
(ADDRESS=(PROTOCOL=tcp)(HOST=140.84.23.80)(PORT=1172)) * establish * kwdb.world * 0
(Zeilen umgebrochen)
Wenn der Parameter HS_FDS_TRACE_LEVEL = 16 in der init.ora des Agents gesetzt ist, erhältt man Trace
Ausgaben in der $ORACLE_HOME\hs\trace directory.
Schlussbemerkung
Generic Connectivity bietet eine einfache Möglichkeit auf ODBC oder OLE-DB kompatible Datenquellen
zuzugreifen, für die Oracle kein Transparent Gateway anbietet. Sie können theoretisch auch alternativ zu den
Gatweways eingesetzt werden, haben allerdings einige Einschränkugen (z.B. kein Two Phase Commit) im Gegensatz
zu den Transparent Gateways, die speziell auf das Zielsystem ausgerichtet sind und die nativen Zugangsprotokolle
der Zielsysteme nutzen. Transparent Gateways sind u.a. verfügbar für DB2/390, DB2/400, DRDA, Terradata,
Microsoft SQL-Server, Informix und Sybase.
Page 6 of 6