Oracle-Datenbank-alert-opiodr Abbruch Prozess ORA-609

Ich arbeite mit einer batch-java-Anwendung. Die Anwendung läuft alle 10/20 Minuten in meiner Produktions-und UAT-Umgebung und ich bekomme die Datenbank-Meldungen wie diese:

Do Feb 06 15:15:08 2014
opiodr Abbruch Prozess unbekannt ospid (28246400) als Ergebnis von ORA-609

Nach Recherchen im internet ein wenig die vorgeschlagene Korrektur für diese Warnungen ist zu ändern INBOUND_CONNECT_TIMEOUT:

Sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT=180
Listener.ora: INBOUND_CONNECT_TIMEOUT_listener_name=120

Haben wir geändert, die Einstellung auf dem Datenbank-server Seite, aber nicht wissen, wo Sie änderungen in der client-Anwendung. Wir sind mit c3p0, erstellen Sie einen Verbindungspool und wir setzen nur diese Parameter:

dataSource.setAcquireRetryDelay(30000); 
dataSource.setMaxPoolSize(50);
dataSource.setMinPoolSize(20);
dataSource.setInitialPoolSize(10);

Wir haben andere web-services laufen auf dem gleichen server befinden wie die batch-Anwendung und verwenden Sie den Tomcat - DBCP pool, und Sie scheinen nicht zu schaffen, alle Warnungen. Auch, seltsam genug, unsere batch-Anwendung nicht erzeugen die Warnungen in den unteren test-Umgebungen. Sie passieren einmal in eine Weile, aber die UAT-und PROD-Umgebungen erhalten diese Warnungen sehr Häufig basierend auf dem Zeitplan. Irgendwelche Vorschläge, welche Konfigurationen in der c3p0 pool oder sollte ich versuchen den Wechsel zu einem anderen pool-API wie DBCP?

Update: ich habe noch ein paar mehr Parameter in die datasource und die Häufigkeit der Warnungen reduziert hat. Ich habe Folgendes und die Anzahl der Benachrichtigungen nach unten gegangen von 15 Stunde mit 4 Stunde.

dataSource.setLoginTimeout(120);
dataSource.setAcquireRetryAttempts(10);
dataSource.setCheckoutTimeout(60000);
Tun Sie nur das ORA-00609, oder sind Sie sehen eine TNS-Fehler als auch (in den listener-log vielleicht) ist, drücken Sie diese beheben? Es klingt nicht wie Sie etwas ändern am client-Ende sowieso. Wie für den Unterschied im Verhalten, nicht die batch nehmen deutlich mehr - mehr als 60 Sekunden? Vielleicht in einigen Umgebungen ist es beendet, bevor der Fehler ausgelöst wird; aber das klingt wie etwas merkwürdiges geschieht auf der Verbindungsebene. (Ich habe keine Erfahrung mit diesem, eindeutig, einfach nur neugierig).
Es ist nur dieser Fehler. Wir sehen nicht, dass jede schlechte Fehler entweder in der Datenbank oder der Anwendung. Es nicht zu brechen diese Anwendung oder eine andere Anwendung auf die Datenbank zugreifen. Es ist nur die Warnungen sind ein kleines ärgernis. Wir fragten auch, die Vernetzung von Menschen, um zu sehen, ob es irgendwelche Unterschiede in den Umgebungen, und Sie haben nicht gefunden, noch nichts.
Hat c3p0 haben ein "halten verbindungen" einstellen? So gibt es eine dummy-sql-Befehl alle X Sekunden?
Wir sind mit allen Standardwerten in c3p0 einschließlich idle-timeouts. Jetzt idle-verbindungen sind nie ab, sondern auch test-verbindungen ist standardmäßig nicht aktiviert. Ich bin mir nicht sicher, ob es immer noch dummy-Abfragen hinter den kulissen.

InformationsquelleAutor rishi | 2014-02-20

  1. 1

    Zog ich zu DBCP connection pooling und es scheint wurde das Problem behoben. Ich habe versucht, ändern ein paar mehr c3p0 oben genannten Einstellungen aber nichts geändert. Die Benachrichtigungen wurden reduziert, aber nicht vollständig. Also beschlossen wir, zu versuchen DBCP. Ich bin mit allen Standardwerten in DBCP außer für die Größe des Pools. Ich bin mit der tomcat-version, die von DBCP verfügbar in der tomcat lib Ordner (tomcat-dbcp.jar).

    InformationsquelleAutor rishi

Schreibe einen Kommentar