Ich habe eine 400 Zeilen SQL-Abfrage, die Ausnahme mit 30 Sekunden
wirftORA-03113: Dateiende auf dem Kommunikationskanal
Unten sind Dinge zu beachten:
Die beunruhigende Bedingung ist wie folgt:
%Vor%Also meine Annahme ist, dass die Abfrage von der Server-Seite anscheinend beendet wird, weil sie als ein Ressource-Schwein identifiziert wird.
Ist meine Annahme angemessen? Wie soll ich dieses Problem beheben?
BEARBEITEN: Ich habe versucht, den EXPLAIN-Plan der fehlerhaften Abfrage zu erhalten, aber die EXPLAIN-Plan-Abfrage gibt mir auch einen ORA-03113-Fehler. Ich verstehe, dass meine Abfrage nicht sehr performant ist, aber warum sollte das ein Grund für ORA-03113 Fehler sein. Ich versuche, die Abfrage von Kröte zu laufen, und es gibt kein Alarmprotokoll oder keine Ablaufverfolgung, die meine DB-Version ist Oracle9i Enterprise Edition Version 9.2.0.7.0 - Produktion
Eine mögliche Ursache für diesen Fehler ist ein Thread-Absturz auf der Serverseite. Überprüfen Sie, ob der Oracle-Server Trace-Dateien generiert oder Fehler in seinem Warnungsprotokoll protokolliert hat.
Sie sagen, dass das Entfernen einer Bedingung aus der Abfrage das Problem beseitigt. Wie lange dauert die Abfrage ohne diese Bedingung? Haben Sie die Ausführungspläne für beide Versionen der Abfrage überprüft, um festzustellen, ob das Hinzufügen dieser Bedingung zur Auswahl eines ineffizienten Plans führt?
Ich hatte Probleme mit ähnlichen Verbindungen bei einer Abfrage. In meinem Fall sind Verbindungen bei der Verwendung von rownum unter bestimmten Umständen gesunken. Es stellte sich heraus, dass es sich um einen Fehler handelte, der eine Umgehung durch Anpassen einer bestimmten Oracle-Datenbankkonfigurationseinstellung aufwies. Wir gingen mit einem Workaround, bis ein Patch installiert werden konnte. Ich wünschte, ich könnte mich an weitere Einzelheiten erinnern oder eine alte E-Mail zu diesem Thema finden, aber ich weiß nicht, dass die Einzelheiten helfen würden, Ihr Problem anzugehen. Ich poste dies nur, um zu sagen, dass Sie wahrscheinlich auf einen Fehler gestoßen sind und wenn Sie Zugriff auf die Support-Website von Oracle (support.oracle.com) haben, werden Sie wahrscheinlich feststellen, dass andere dies gemeldet haben.
Bearbeiten: Ich habe mir kurz den Support von Oracle angesehen. Es gibt mehr als 1000 Fehler im Zusammenhang mit ORA-03113, aber ich habe eine gefunden, die möglicherweise gilt:
Fehler 5015257: QUERY FEHLT MIT ORA-3113 UND COREDUMP WENN QUERY_REWRITE_ENABLED = 'TRUE'
Zusammenfassend:
Eine andere Möglichkeit:
Bug 3659827: ORA-3113 FROM LONG RUNNING QUERY
Sie können das "UPPER" auf beiden Teilen sicher entfernen, wenn Sie das like mit Zahlen verwenden (die nicht zwischen Groß- und Kleinschreibung unterscheiden). Dies kann die Abfragezeit verringern, um den gleichen Satz zu prüfen. p> %Vor%
Ist gleich:
%Vor%Zahlen werden von UPPER nicht beeinflusst (und% ist unabhängig von der Zeichenüberdeckung).
Aus den bisherigen Informationen sieht es wie ein Back-End-Crash aus, wie Dave Costa vor einiger Zeit vorgeschlagen hat. Konnten Sie die Serverprotokolle überprüfen?
Können Sie den Plan mit set autotrace traceonly explain bekommen? Tritt es lokal oder nur mit einer Remoteverbindung von SQL * Plus auf? Sicher klingt das wie ein ORA-600 auf dem Back-End könnte der Täter sein, besonders wenn es zur Zeit des Parsens ist. Der erfolgreiche Lauf, der länger dauert als der fehlgeschlagene, scheint ein Netzwerkproblem auszuschließen. Ich vermute, dass es ziemlich schnell versagt, aber der Client braucht bis zu 30 Sekunden, um die Verbindung aufzugeben, oder der Server braucht so lange, um Trace- und Core-Dateien zu schreiben.
Was Ihnen wahrscheinlich die Möglichkeit zum Patchen gibt (wenn Sie eine entsprechende Korrektur für das spezifische ORA-600 auf Metalink finden können) oder das Aktualisieren der DB; oder die Abfrage neu schreiben, um sie zu vermeiden. Sie können einige Ideen bekommen, wie man das von Metalink macht, wenn es ein bekannter Bug ist. Wenn Sie Glück haben, kann es so einfach wie ein Hinweis sein, wenn die zusätzliche Bedingung einen unerwarteten Einfluss auf den Plan hat. Ist someMultiJoin.someColumn Teil eines Index, der in der erfolgreichen Version verwendet wird? Es ist möglich, dass die UPPER es verwirren und Sie könnten es wieder zu dem erfolgreichen Plan überreden, indem Sie darauf hinweisen, den Index trotzdem zu verwenden, aber das ist offensichtlich ziemlich spekulativ.
Es bedeutet, dass Sie die Verbindung getrennt haben. Dies ist wahrscheinlich nicht darauf zurückzuführen, dass es sich um einen Rohstofffresser handelt.
Ich habe gesehen, wo die Verbindung zur DB über ein NAT läuft und weil es keinen Datenverkehr gibt, schließt es den Tunnel und lässt somit die Verbindung fallen. Im Allgemeinen, wenn Sie Verbindungspooling verwenden, erhalten Sie das nicht.
Wie @Daniel sagte, wird die Netzwerkverbindung zum Server unterbrochen. Sie können einen Blick auf Ende der Datei im Kommunikationskanal , um zu sehen, ob es nützliche Vorschläge enthält.
Teilen und genießen.
Dies ist oft ein Fehler im Cost Based Optimizer mit komplexen Abfragen.
Sie können versuchen, den Ausführungsplan zu ändern. Z.B. Verwenden Sie WITH , um einige Subquerys herauszuziehen . Oder verwenden Sie SELECT / * + RULE * / Hinweis, um zu verhindern, dass Oracle das CBO verwendet. Auch das Löschen der Statistiken hilft, da Oracle dann einen anderen Ausführungsplan verwendet.
Wenn Sie die Datenbank aktualisieren können, machen Sie eine Testinstallation von 9.2.0.8 und sehen Sie, ob der Fehler dort verschwunden ist.
Manchmal hilft es, einen Dump des Schemas zu machen, alles zu löschen und den Dump erneut zu importieren.
Tags und Links oracle query-optimization ora-03113