In einer Oracle-Datenbank wird periodisch eine große PL/SQL-Prozedur ausgeführt, die über eine Datenbankverbindung Daten von einem DB in einen anderen kopiert und danach versagt einige Stunden mit dem folgenden Fehler:ORA-03150: Dateiende auf Kommunikationskanal für Datenbankverbindung
ORA-03150: end-of-file on communication channel for database link
ORA-02063: preceding line from DBPREMOTE
ORA-06512: at "DBLOCAL.JOB_NAME", line 710
...
ORA-06512: at line 1
Linie 710 ist die erste Zeile eines Verfahrens:
execute immediate 'set constraints all deferred';
Dann macht das Verfahren einige Einfügungen und Aktualisierungen, die ich an einem gewissen Punkt erraten aufgrund fehlschlagen PK, Daten ungültig oder aus irgendeinem anderen Grund. Ich vermute, dass die Ausnahme auf diese Zeile zeigt, weil sie die erste ist, nicht weil sie dort tatsächlich versagt, aber ich weiß nicht genau die wirkliche Ausnahme.
Gibt es eine Chance, dass ich die echte Ausnahme bekomme, damit ich damit umgehen kann?
FOR aLink IN (SELECT * FROM V$DBLINK) LOOP
DBMS_SESSION.CLOSE_DATABASE_LINK(aLink.DB_LINK);
END LOOP;
oder
DECLARE
DATABASE_LINK_IS_NOT_OPEN EXCEPTION;
PRAGMA EXCEPTION_INIT(DATABASE_LINK_IS_NOT_OPEN, -2081);
BEGIN
DBMS_SESSION.CLOSE_DATABASE_LINK('DBPREMOTE ');
EXCEPTION
WHEN DATABASE_LINK_IS_NOT_OPEN THEN
NULL;
END;
Wenn die Verbindungen sowieso fallen gelassen:
Es ist wahrscheinlicher, dass Sie ein leicht flockiges Netzwerk als ein INSERT-Fehler haben. Wenn das INSERT fehlgeschlagen wäre, würden Sie immer noch einen Fehler damit bekommen (Sie können dies testen - gehen Sie nicht davon aus!) – Ben
Es ist eine verteilte Transaktion, also suchen Sie zuerst nach weiteren Details im 'alert.log' auf ** dem Remote-Server **. Das sollte Ihnen genügend Informationen geben, um zu verstehen, warum die Transaktion fehlgeschlagen ist. – APC
Wir haben gerade die alert.log Details und wir bekommen: 'TNS-12535: TNS: Timeout beim ns Sekundärcode err: 12560 nt Haupt err code: 505 TNS-00505: Operation timed out nt sekundärer Fehlercode: 110 nt OS Fehlercode: 0' in der lokalen DB, nichts in der alert.log des Remote-Servers. Wir sind also geneigt zu denken, dass es etwas im lokalen Verfahren ist. Ich denke, die Zeitüberschreitung nach 2h ist normal. – detoro84