oracle8: Anbindung client an server

Hallo,

ich sitze an einer Win2000-Maschine an einem Terminalprogramm und möchte (über lokales Ethernet-Router-Internet) auf eine Oracle-Datenbank (wahrscheinlich Version 8)

Fehlerbeschreibung in Kürze:
Nah Eingabe der Zugangsberechtigung (Name+PW) am Terminal erscheint die
Fehlermeldung

SQLSTATE=S1000
[Oracle]ODBCGeneral Error

Ein Test mit dem Oracleeigenem Verbindungstest brachte folgende Meldung:
ORA-12571: TNS: Fehler beim Paket-Schreiber

Wo muss die Fehlersuche ansetzen, wenn ein zweiter Rechner (gleiches BS) aus meinem Netzwerk mit den gleichen Zugangsdaten die Verbindung zur DB aufbauen kann?

Es wäre schön wenn sich das Problem in Heimarbeit lösen lassen würde, da der dazugehörige Service (welcher auch die Inst. durchführte) erst eingetaktet werden müsste. Die Hotline ist nicht so hilfreich.

Vielen Dank schon im Voraus!
Tschuess Marco.

Hallo,

bei der Oracle 8 könnte es am Treiber liegen. Ganz offensichtlich versuchst Du ja eine ODBC Verbindung. Da hast Du dann in der Regel 2 Treiber zur Auswahl, den von MS und den von Oracle. Die waren bei der 8er Version noch ziemlich mangelhaft. Manches ging NUR mit dem MS Treiber und manches nur mit dem ORACLE Treiber. Schu also mal in den ODBC Verbindungen nach, welche Treiber Du benutzt.

Evtl könntest Du auch vergessen haben, den TNSNamen anzulegen. Der ist ja auch in der Regel lokal gespeichert.

Hoffe, Du kannst damit was anfangen

Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

hi!

wahrscheinlich Version 8

eine genauere beschreibung würde erheblich weiterhelfen - „Version 8“ ist ziemlich breit gefächert

Ein Test mit dem Oracleeigenem Verbindungstest brachte
folgende Meldung:
ORA-12571: TNS: Fehler beim Paket-Schreiber

gibt’s ein sqlnet.log-file für eine genauere fehlerbeschreibung?

es scheint etwas mit den tnsnames bzw. der sqlnet.ora nicht zu stimmen

Wo muss die Fehlersuche ansetzen, wenn ein zweiter Rechner
(gleiches BS) aus meinem Netzwerk mit den gleichen
Zugangsdaten die Verbindung zur DB aufbauen kann?

sind beide rechner ident (sprich: image o.ä) aufgesetzt worden? solange sie nur das selbe bs haben, sagt das noch nix, da die client-software auch irgendwie installiert werden muß …

vergleiche mal die tnsnames.ora und die sqlnet.ora-files von jenem rechner, bei dem es funktionert und deinem bzw. kopiere sie …

grüße,
tomh

ps: hast du zufällig einen virenscanner drauf? ein bekanntes problem gibt es zumindest mit mcafee

Hallo Marco!

Ich kümmere mich in meiner Antwort mal ausschließlich darum:

Ein Test mit dem Oracleeigenem Verbindungstest brachte
folgende Meldung:
ORA-12571: TNS: Fehler beim Paket-Schreiber

So lange du nämlich keine „native“ Oracle-Verbindung herstellen kannst halte ich eine Verbindung über ODBC für sehr unwahrscheinlich.

Welchen „Oracleeigenen Verbindungstest“ verwendest du? Command line „tnsping“ oder irgendein (nach meinem dafürhalten unnötiges) Klickibunti-Ding?
Falls nicht tnsping: Gib mal auf der Command line folgendes ein:
tnsping $DB
wobei du für $DB den logischen (lokalen) Namen der Datenbank angibst. Würde die Verbindung zum Listener (sic!) funktionieren, käme dabei in etwa folgendes raus:

TNS Ping Utility for 32-bit Windows: Version 8.1.7.2.0 - Production on 05-FEB-2004 10:41:10

(c) Copyright 1997 Oracle Corporation. All rights reserved.

Attempting to contact (ADDRESS=(PROTOCOL=TCP)(HOST=hollodrio)(PORT=1521))
OK (170 msec)

Wenn das schon mal nicht geht, dann siehst du dir die Parameter an, mit denen versucht wird die Verbindung herzustellen. Wenn die richtig sind (unbedingt auch die Verbindung zum Host kontrollieren, bei TCP/IP z.B. mittels ping), dann bleibt dir kaum etwas übrig als ans Eingemachte zu gehen: Logfiles prüfen bzw. Tracen.

Die Logfiles:
Standardmässig ist das das File sqlnet.log im Verzeichnis, in dem die Applikation gestartet wird, die den Fehler verursacht hat. Geändert werden kann das in der sqlnet.ora, und zwar mittels der Parameter LOG_FILE_CLIENT (hier gibst du einen Dateinamen an) und LOG_DIRECTORY_CLIENT (das Verzeichnis…).

Solltest du im Logfile also etwas finden, das evtl. mehr Aufschlüsse zum Fehler gibt, dann nix wie her damit (bitte nicht die gesammelten Fehler der letzten drei Jahre, nur den letzten Fehlerstack).

Weiterhelfen könnte uns auch ein Tracen des tnspings (vorausgesetzt der geht auch schief, wenn der funkt, dann müssen wir wohl wo anders weitersuchen [vermutlich am Server]).

Den Trace vom tnsping aktivierst du mit folgenden Einträgen im sqlnet.ora:
TNSPING.TRACE_DIRECTORY=$IrgendeinDirectoryDasEsAuchGibt
TNSPING.TRACE_LEVEL=admin

Danach den tnsping nochmal (1x!) ausführen und dann immer her mit dem
Trace (File heißt tnsping.trc).

Das sollte für’s erste mal reichen.

Gruß,
Martin

Hallo,

Schau also mal in den ODBC Verbindungen nach, welche Treiber Du benutzt.

Es sind beide installiert, lt. Fehlermeldung wird aber der Oracle benutzt.

Evtl könntest Du auch vergessen haben, den TNSNamen anzulegen. Der ist ja auch in der Regel lokal gespeichert.

Die gibt es zweimal. Diese hat mein Kollege von seinem Re auf meinen rübergespielt.

Das sqlnet.log-file sagt folgendes:
***********************************************************************
Fatal NI connect error 12571, connecting to:
(DESCRIPTION=(CONNECT_DATA=(SID=*)(SERVICE_NAME=tXXXX)(CID=(PROGRAM=C:\Programme\DB XXXXX.exe)(HOST=PCXX)(USER=PCXX)))(ADDRESS=(PROTOCOL=TCP)(HOST=XXXX)(PORT=1521)))

VERSION INFORMATION:
TNS for 32-bit Windows: Version 8.1.5.0.0 - Production
Windows NT TCP/IP NT Protocol Adapter for 32-bit Windows: Version 8.1.5.0.0 - Production
Time: 04-FEB-04 16:32:06
Tracing not turned on.
Tns error struct:
nr err code: 0
ns main err code: 12571
TNS-12571: TNS: Fehler beim Paket-Schreiber
ns secondary err code: 12560
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0

Die sqlnet.ora-Datei werd ich mal bei nächster Gelegenheit kopieren, soweit die Fehlermeldung Euch nicht zu einem anderen Tip bringt.

Vielen Dank Tom und Markus (?) für eure bisherigen Anmerkungen, die * sind schon vergeben.

Tschuess Marco.

Hallo Marco nochmal!

Meine Antwort hat sich mit deiner zeitlich überschnitten. Hier ein paar Kommentare zu deinem sqlnet.log:

Das sqlnet.log-file sagt folgendes:
***********************************************************************
Fatal NI connect error 12571, connecting to:

(DESCRIPTION=(CONNECT_DATA=(SID=*)(SERVICE_NAME=tXXXX)(CID=(PROGRAM=C:\Programme\DB
XXXXX.exe)(HOST=PCXX)(USER=PCXX)))(ADDRESS=(PROTOCOL=TCP)(HOST=XXXX)(PORT=1521)))

VERSION INFORMATION:
TNS for 32-bit Windows: Version 8.1.5.0.0 - Production
Windows NT TCP/IP NT Protocol Adapter for 32-bit Windows:
Version 8.1.5.0.0 - Production
Time: 04-FEB-04 16:32:06
Tracing not turned on.
Tns error struct:
nr err code: 0
ns main err code: 12571
TNS-12571: TNS: Fehler beim Paket-Schreiber
ns secondary err code: 12560
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0

Der secondary err code 12560 führt zu folgendem Fehler (© Oracle Doku):
_ORA-12560: TNS:stuck_out_tongue:rotocol adapter error

Action: The listener was unable to start a process connecting the user to the database server.

Cause: Perform these steps:

Turn on tracing and repeat the operation.
Evaluate the contents of the trace file to diagnose the problem._

Bitte also folgendes zu prüfen: Stimmt die Verbindungsinformation (also HOST, PROTOCOL, PORT im ADDRESS-Teil)? Wenn ja, gibt’s einen Log vom Listener (falls Win-Server: $ORACLE_HOME/network/log/listener.log), und wenn ja, was spricht der?

Wenn dort nichts steht, was uns auf die Sprünge helfen könnte,dann genau das tun, was Oracle vorschlägt: tracen. Mehr Infos dazu gibt’s in der Oracle-Doku oder von uns hier :wink:
Gruß,
Martin

Du kannst auch mal im NetManager die Verbindung testen. Dann weisst Du wenigstens, ob der Fehler Oracleseitig oder ODBC-seitig liegt.

Gruß

peter

Hallo Marco

Kenne mich zwar nicht so gut aus, aber vergleiche mal auf den
beiden Clients die tnsnames.ora.
Sie befindet sich im Verzeichniss c:\oracle\ora81\network\admin
Kopiere einfach die vom funktionierenden Client auf den nicht funktionierenden. vielleicht gehts dann.

mfg

Richard

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]