Ich habe Probleme mit einem Oracle-Update. Der Aufruf von ExecuteNonQuery hängt unbegrenzt.
Der Code:
%Vor%CommandTimeout wird auf 5 gesetzt und die Parameter werden auf kleine ganzzahlige Werte gesetzt.
Die Abfrage:
%Vor%Die Abfrage wird schnell von sqlplus ausgeführt und läuft normalerweise schnell von meinem Code ab, aber hin und wieder hängt es für immer.
Ich habe eine Abfrage für v $ locked_object ausgeführt, und es gibt einen Datensatz, der sich auf diese Tabelle bezieht, aber ich denke, das ist das Update, das nicht abgeschlossen wird.
Es gibt zwei Dinge, die ich gerne wissen würde: Was könnte dazu führen, dass das Update aufhört?
Wichtiger noch, warum wird hier keine Ausnahme ausgelöst? Ich würde erwarten, dass der Anruf fünf Sekunden wartet und dann Timeout.
Ich stoße das aufgrund seines Seitenrangs in den Suchergebnissen.
In meinem Fall war es, weil ich eine Abfrage in SqlPlus ausgeführt hatte, aber ich habe vergessen, es zu bestätigen. In diesem Fall war es, wie Vincent sagte: Die Reihe war in einer anderen Sitzung gesperrt.
Durch das Commit des SqlPlus-Updates wurde das Problem behoben.
Wenn ein einfaches Update aufhört, bedeutet dies oft, dass Sie von einer anderen Sitzung blockiert werden. Oracle lässt nicht zu, dass mehr als eine Transaktion eine Zeile aktualisiert. Bis eine Transaktion ihre Änderungen festgeschrieben oder rückgängig gemacht hat, werden die Zeilen, die aktualisiert / gelöscht wurden, gesperrt. Dies bedeutet, dass eine andere Sitzung warten muss, wenn sie dieselben Zeilen ändern möchte.
Sie sollten SELECT ... für UPDATE NOWAIT vor dem UPDATE, wenn Sie nicht hängen wollen.
Ich hatte ein ähnliches Problem, das durch einen Sql-Befehl verursacht wurde, der nicht ausgeführt wurde - ich vermute, dass das Programm irgendwann mitten in einem abgestürzt ist.
Hier habe ich mein Problem behoben:
Öffnen Sie zunächst SqlPlus und führen Sie eine Festschreibung durch, um das Problem zu beheben.
Als nächstes ändern Sie den Code, um die Transaktion zu committen oder Rollback, wenn eine Ausnahme auftritt. Das wird verhindern, dass das Problem erneut auftritt.
Sie könnten Ihren Code so ändern:
%Vor%Sie können sehen, auf welches Ereignis Ihre Sitzung wartet, indem Sie V $ SESSION_WAIT abfragen (nachdem Sie die SID der Sitzung identifiziert haben, wahrscheinlich durch Betrachten von V $ SESSION). Wenn das Ereignis etwas wie "Enqueue" ist, warten Sie auf eine Sperre, die von einer anderen Sitzung gehalten wird, was in diesem Fall eine wahrscheinliche Erklärung zu sein scheint.
Ich habe dieses Problem häufig und mit mehr als nur Update-Abfragen (insbesondere "INSERT INTO ... SELECT FROM" -Abfragen). Dies ist auf Oracle 9i.
Ich habe die Lösung gefunden, also habe ich beschlossen, dieses verwandte SO-Thema zu finden: Legen Sie in der Verbindungszeichenfolge fest:
%Vor%in der Verbindungszeichenfolge. Eine vollständige, funktionierende Verbindungszeichenfolge könnte folgendermaßen aussehen:
%Vor%Vorbehalte: Wenn Sie pooling auf false festlegen, muss Ihre Abfrage bei jeder Ausführung eine neue Verbindung sichern. Bei Abfragen, die sehr häufig ausgeführt werden, kann es im Vergleich zu ODP.NET zu Leistungseinbußen kommen. Wenn man das Problem betrachtet, ist es etwas besser, etwas langsamer zu laufen, als zu hängen.