java.sql.SQLException: - ORA-01000: Maximale Anzahl offener Cursor überschritten

ORA-01000, der Fehler "Maximum-Open-Cursors", ist ein äußerst häufiger Fehler in der Oracle-Datenbankentwicklung. Im Kontext von Java geschieht dies, wenn die Anwendung versucht, mehr ResultSets zu öffnen, als konfigurierte Cursor auf einer Datenbankinstanz vorhanden sind.

Häufige Ursachen sind:

1. Konfigurationsfehler

   • Ihre Anwendung enthält mehr Threads, die die Datenbank abfragen, als Cursor auf der Datenbank. In einem Fall haben Sie eine Verbindung und einen Thread-Pool, die größer sind als die Anzahl der Cursor in der Datenbank.
   • Sie haben viele Entwickler oder Anwendungen mit derselben DB-Instanz verbunden (die wahrscheinlich viele Schemata enthalten wird), und zusammen verwenden Sie zu viele Verbindungen.

   • Lösung:

     • Erhöhen der Anzahl der Cursor in der Datenbank (sofern die Ressourcen dies zulassen) oder
     • Verringern der Anzahl der Threads in der Anwendung.

2. Cursor undicht

   • Die Anwendung schließt ResultSets (in JDBC) oder Cursor (in gespeicherten Prozeduren in der Datenbank) nicht
   • Lösung : Cursorlecks sind Fehler; Wenn Sie die Anzahl der Cursor in der Datenbank erhöhen, wird der unvermeidliche Fehler nur verzögert. Lecks können mithilfe von statische Codeanalyse , JDBC oder Protokollierung auf Anwendungsebene und Datenbanküberwachung festgestellt werden.

Hintergrund

In diesem Abschnitt werden einige der Cursortheorien und die Verwendung von JDBC beschrieben. Wenn Sie den Hintergrund nicht kennen müssen, können Sie diesen überspringen und direkt zu "Lecks beseitigen" wechseln.

Was ist ein Cursor?

Ein Cursor ist eine Ressource in der Datenbank, die den Status einer Abfrage enthält, insbesondere die Position, an der sich ein Leser in einem ResultSet befindet. Jede SELECT-Anweisung hat einen Cursor, und gespeicherte PL/SQL-Prozeduren können so viele Cursor öffnen und verwenden, wie sie benötigen. Weitere Informationen zu Cursorn finden Sie unter Orafaq .

Eine Datenbankinstanz bedient normalerweise mehrere verschiedene Schemata und viele verschiedene Benutzer mit jeweils mehreren Sitzungen . Zu diesem Zweck steht eine feste Anzahl von Cursorn für alle Schemas, Benutzer und Sitzungen zur Verfügung. Wenn alle Cursor geöffnet sind (verwendet werden) und eine Anforderung eingeht, für die ein neuer Cursor erforderlich ist, schlägt die Anforderung mit einem ORA-010000-Fehler fehl.

Finden und Einstellen der Anzahl der Cursor

Die Nummer wird normalerweise vom DBA bei der Installation konfiguriert. Auf die Anzahl der aktuell verwendeten Cursor, die maximale Anzahl und die Konfiguration kann in den Administratorfunktionen in Oracle SQL Developer zugegriffen werden. In SQL kann eingestellt werden mit:

ALTER SYSTEM SET OPEN_CURSORS=1337 SID='*' SCOPE=BOTH;

JDBC in der JVM mit Cursorn in der DB verknüpfen

Die folgenden JDBC-Objekte sind eng an die folgenden Datenbankkonzepte gekoppelt:

• JDBC Connection ist die Clientdarstellung einer Datenbanksitzung und stellt Datenbanktransaktionen bereit. Bei einer Verbindung kann immer nur eine Transaktion geöffnet sein (Transaktionen können jedoch verschachtelt sein).
• Ein JDBC ResultSet wird von einem einzelnen Cursor in der Datenbank unterstützt. Wenn close () im ResultSet aufgerufen wird, wird der Cursor losgelassen.
• Ein JDBC CallableStatement ruft eine gespeicherte Prozedur in der Datenbank auf, die häufig in PL/SQL geschrieben wird. Die gespeicherte Prozedur kann null oder mehr Cursor erstellen und einen Cursor als JDBC-ResultSet zurückgeben.

JDBC ist threadsicher: Es ist in Ordnung, die verschiedenen JDBC-Objekte zwischen Threads zu übergeben.

Beispielsweise können Sie die Verbindung in einem Thread erstellen. Ein anderer Thread kann diese Verbindung verwenden, um ein PreparedStatement zu erstellen, und ein dritter Thread kann die Ergebnismenge verarbeiten. Die einzige wichtige Einschränkung besteht darin, dass auf einem einzelnen PreparedStatement nicht mehr als ein ResultSet geöffnet sein darf. Siehe nterstützt Oracle DB mehrere (parallele) Operationen pro Verbindung?

Beachten Sie, dass ein Datenbank-Commit für eine Verbindung erfolgt und daher alle DML-Dateien (INSERT, UPDATE und DELETE) für diese Verbindung zusammen festgeschrieben werden. Wenn Sie also mehrere Transaktionen gleichzeitig unterstützen möchten, müssen Sie für jede gleichzeitige Transaktion mindestens eine Verbindung haben.

JDBC-Objekte schließen

Ein typisches Beispiel für die Ausführung eines ResultSet ist:

Statement stmt = conn.createStatement();
try {
    ResultSet rs = stmt.executeQuery( "SELECT FULL_NAME FROM EMP" );
    try {
        while ( rs.next() ) {
            System.out.println( "Name: " + rs.getString("FULL_NAME") );
        }
    } finally {
        try { rs.close(); } catch (Exception ignore) { }
    }
} finally {
    try { stmt.close(); } catch (Exception ignore) { }
}

Beachten Sie, wie die finally-Klausel alle durch close () ausgelösten Ausnahmen ignoriert:

• Wenn Sie das ResultSet einfach ohne den try {} catch {} schließen, schlägt dies möglicherweise fehl und verhindert, dass die Anweisung geschlossen wird
• Wir möchten zulassen, dass alle Ausnahmen, die im Hauptteil des Versuchs ausgelöst werden, an den Aufrufer weitergegeben werden. Denken Sie daran, jede Anweisung innerhalb der Schleife zu schließen, wenn Sie beispielsweise eine Schleife zum Erstellen und Ausführen von Anweisungen haben.

In Java 7 hat Oracle die AutoCloseable-Schnittstelle eingeführt, die den größten Teil des Java 6-Boilerplates durch etwas syntaktischen Zucker aus Nizza ersetzt.

Halten von JDBC-Objekten

JDBC-Objekte können sicher in lokalen Variablen, Objektinstanzen und Klassenmitgliedern gespeichert werden. Es ist im Allgemeinen besser, Folgendes zu tun:

• Verwenden Sie Objektinstanz- oder Klassenmitglieder, um JDBC-Objekte zu speichern, die über einen längeren Zeitraum mehrfach wiederverwendet werden, z. B. Connections und PreparedStatements
• Verwenden Sie lokale Variablen für ResultSets, da diese abgerufen, durchlaufen und dann normalerweise im Rahmen einer einzelnen Funktion geschlossen werden.

Es gibt jedoch eine Ausnahme: Wenn Sie EJBs oder einen Servlet/JSP-Container verwenden, müssen Sie ein striktes Threading-Modell befolgen:

• Nur der Application Server erstellt Threads (mit denen er eingehende Anfragen bearbeitet)
• Nur der Anwendungsserver erstellt Verbindungen (die Sie aus dem Verbindungspool erhalten)
• Wenn Sie Werte (Status) zwischen Aufrufen speichern, müssen Sie sehr vorsichtig sein. Speichern Sie niemals Werte in Ihren eigenen Caches oder statischen Elementen. Dies ist in Clustern und unter anderen komischen Bedingungen nicht sicher, und der Anwendungsserver kann Ihre Daten schrecklich beschädigen. Verwenden Sie stattdessen Stateful Beans oder eine Datenbank.
• Insbesondere halten niemals JDBC-Objekte (Connections, ResultSets, PreparedStatements usw.) über verschiedene Remote-Aufrufe - lassen Sie dies vom Anwendungsserver verwalten. Der Anwendungsserver stellt nicht nur einen Verbindungspool bereit, sondern speichert auch Ihre PreparedStatements im Cache.

Leckagen beseitigen

Es stehen eine Reihe von Prozessen und Tools zur Verfügung, mit denen JDBC-Lecks erkannt und beseitigt werden können:

1. Während der Entwicklung ist es bei weitem am besten, Fehler frühzeitig zu erkennen:

   1. Entwicklungspraktiken: Gute Entwicklungspraktiken sollten die Anzahl der Fehler in Ihrer Software verringern, bevor diese den Entwickler-Schreibtisch verlässt. Spezifische Praktiken umfassen:

      1. Paarprogrammierung , um diejenigen ohne ausreichende Erfahrung zu unterrichten
      2. Code Bewertungen weil viele Augen besser als eins sind
      3. Komponententest Dies bedeutet, dass Sie Ihre gesamte Codebasis mit einem Testwerkzeug testen können, das die Reproduktion von Lecks trivial macht
      4. Verwenden Sie vorhandene Bibliotheken , um Verbindungen zusammenzulegen, anstatt Ihre eigenen zu erstellen

   2. Statische Code-Analyse: Verwenden Sie ein Tool wie das ausgezeichnete Findbugs , um eine statische Code-Analyse durchzuführen. Dies greift viele Stellen auf, an denen close () nicht korrekt behandelt wurde. Findbugs hat ein Plugin für Eclipse, läuft aber auch als Einzelplatzversion und ist in Jenkins CI und andere Build-Tools integriert

2. Zur Laufzeit:

   1. Haltbarkeit und Commit

      1. Wenn die Haltbarkeit von ResultSet ResultSet.CLOSE_CURSORS_OVER_COMMIT ist, wird ResultSet geschlossen, wenn die Methode Connection.commit () aufgerufen wird. Dies kann mithilfe von Connection.setHoldability () oder mithilfe der überladenen Connection.createStatement () -Methode festgelegt werden.

   2. Protokollierung zur Laufzeit.

      1. Fügen Sie gute Protokollanweisungen in Ihren Code ein. Diese sollten klar und verständlich sein, damit der Kunde, die Supportmitarbeiter und die Teammitglieder ohne Schulung verstehen können. Sie sollten knapp sein und das Drucken der Status-/internen Werte von Schlüsselvariablen und Attributen einschließen, damit Sie die Verarbeitungslogik verfolgen können. Eine gute Protokollierung ist für das Debuggen von Anwendungen von grundlegender Bedeutung, insbesondere von Anwendungen, die bereitgestellt wurden.

      2. Sie können Ihrem Projekt einen Debugging-JDBC-Treiber hinzufügen (zum Debuggen - stellen Sie ihn nicht tatsächlich bereit). Ein Beispiel (ich habe es nicht verwendet) ist log4jdbc . Sie müssen dann einige einfache Analysen für diese Datei durchführen, um festzustellen, welche Ausführungen keinen entsprechenden Abschluss haben. Das Zählen von Öffnen und Schließen sollte aufzeigen, ob ein potenzielles Problem vorliegt

         3. Datenbank überwachen. Überwachen Sie Ihre ausgeführte Anwendung mit Tools wie der SQL Developer-Funktion "SQL überwachen" oder Quest's TOAD . Die Überwachung wird in dieser Artikel beschrieben. Während der Überwachung fragen Sie die offenen Cursor (z. B. aus Tabelle v $ sesstat) ab und überprüfen deren SQL. Wenn die Anzahl der Cursor zunimmt und (am wichtigsten) von einer identischen SQL-Anweisung dominiert wird, wissen Sie, dass Sie ein Leck mit dieser SQL haben. Suchen Sie Ihren Code und überprüfen Sie.

Andere Gedanken

Können Sie mit WeakReferences Verbindungen schließen?

Mit schwachen und weichen Referenzen können Sie ein Objekt auf eine Weise referenzieren, die es der JVM ermöglicht, den Referenten zu jedem Zeitpunkt, den sie für geeignet hält, mit Garbage zu sammeln (vorausgesetzt, es gibt keine starken Referenzketten zu diesem Objekt).

Wenn Sie eine ReferenceQueue im Konstruktor an die weiche oder schwache Referenz übergeben, wird das Objekt in die ReferenceQueue eingefügt, wenn das Objekt zum Zeitpunkt seines Auftretens GC-geprüft wird (falls überhaupt). Mit diesem Ansatz können Sie mit der Finalisierung des Objekts interagieren und das Objekt in diesem Moment schließen oder finalisieren.

Phantomreferenzen sind etwas seltsamer. Ihr Zweck ist nur, die Finalisierung zu steuern. Sie können jedoch niemals einen Verweis auf das ursprüngliche Objekt erhalten. Daher wird es schwierig sein, die Methode close () für dieses Objekt aufzurufen.

Es ist jedoch selten eine gute Idee, zu versuchen, zu steuern, wann der GC ausgeführt wird (Weak, Soft und PhantomReferences lassen Sie wissen , nachdem , dass sich das Objekt in der Warteschlange für den GC befindet). Wenn die Speicherkapazität in der JVM groß ist (z. B. -Xmx2000m), können Sie das Objekt möglicherweise nie GC, und der ORA-01000 tritt weiterhin auf. Wenn der JVM-Speicher im Verhältnis zu den Anforderungen Ihres Programms klein ist, stellen Sie möglicherweise fest, dass die Objekte ResultSet und PreparedStatement unmittelbar nach der Erstellung (bevor Sie daraus lesen können) gecodet werden, was wahrscheinlich zu einem Fehlschlagen Ihres Programms führt.

TL; DR: Der schwache Referenzmechanismus ist keine gute Methode zum Verwalten und Schließen von Statement- und ResultSet-Objekten.