When our application tries to connect Oracle database, this exception is thrown:
java.sql.SQLRecoverableException: Connection has been administratively disabled by console/admin command. Try later. java.lang.Exception: It was disabled at Tue Oct 20 23:55:14 CEST 2015
But, from Weblogic console the connection test returns OK.
Weblogic version: 12.1.3.0.0
Any explanation is welcome. Thanks
The reason the test works is because that is creating a connection and running a test query. That is not what your code is doing when it is using the data source in an ejb. The code is going through the connection pool and that is what has been marked as bad. There is no solution provided by Oracle that I have found except to: restart the server and that will re-enable the connection pool.
I suspect you have "Test connections on reserve" set because that is when this usually arises. What Weblogic does is: before it returns a connection from the pool it will run a test query, if the test query fails it waits and runs it one more time. If the query fails again it marks the connection as unhealthy. If all the connections in the pool become unhealthy it will mark the pool as disabled and gives you the error message you see: 'Connection has been administratively disabled by console/admin command. Try later.'
In regards to the 'Try Later' part of the error message, as far as I can tell Oracle is wrong about trying again later. I have never seen it recover later.
I'd like to share this article that help me out to understand better my problem:
https://www.techpaste.com/2012/09/connection-administratively-destroyed-reconnect-oracle-weblogic-server/
The “java.sql.SQLException: Connection has been administratively destroyed.” is expected:
the DB was shutdown; even if it was restarted later, the JDBC connection are pointing to DB processes
that have been destroyed.
You need to restart your WebLogic Server to recreate new JDBC connections.
All the current transactions are lost, as the database was shutdown.
High availability of your RDBMS is required to minimize this issue.
Is there any other error before that one ?
Maybe in the log you can find that connection is been closed.
You can avoid this by selecting "Test on Connection Reserve" in the datasource.
Related
I use a DBLINK/Oracle Gateway to connect to an external non-oracle database. i have a timeout setting of 5 minutes.
when I connect using dblink, for the first time, it runs fine. After the idle time of 5 minutes, when I run the same sql again, it throws me the bellow error -
ORA-28511: lost RPC connection to heterogeneous remote agent using SID. ****
ORA-28509: unable to establish a connection to non-Oracle system
ORA-02063: preceding line from DB2T
Then when i run the sql again, its connecting fine. i guess its establishing a new connection.
Why am i getting the connection error and why oracle is not simply establishing a new connection when the previous connection is timed out?
Is there a way to not get the error and connect seamlessly or to suppress the error?
Easily replicable in sql developer by running a sql and waiting for 5 minutes.
Thanks in Advance.
I am getting the error as 'ORA-03135: connection lost contact' from my C# code while making connection to oracle DB. The same job works just fine from our test server. But it failed with ORA-03135: connection lost contact error from prod server.
The C# code use ODAC to connect to oracle DB.
Appreciate your inputs.
Thank you
This error is most likely caused by a firewall blocking the connection request. Check for any firewalls in your network or on the database server and make sure your access rules are configured correctly.
Also check this link for more troubleshooting tips: http://www.dba-oracle.com/t_ora_03135_connection_lost_contact.htm
ORA-03135: connection lost contact tips
What can I do to avoid the ORA-03135 error?
Answer: The oerr utility shows this for the ORA-03135 error:
ORA-03135: connection lost contact
Cause:
1) Server unexpectedly terminated or was forced to terminate.
2) Server timed out the connection.
Action:
1) Check if the server session was terminated.
2) Check if the timeout parameters are set properly in
sqlnet.ora.
The ORA-03135 error is common when connecting remotely when a firewall
terminates the connection.
One solution for the ORA-03135 error is to increase the value of the
sqlnet.ora expire_time parameter in the sqlnet.ora file or to check
for a expire parameter in a SQL*Plus profile.
To diagnose the ORA-03135 error, start by checking to see if the OS
PID still exists, using the "ps -ef | grep" syntax.
Check to see if there is a Network Address Translation (NAT) between
the client and server
In Windows, check to see if a Windows firewall is checking for your
local connections.
...
Also, setting the parameters sqlnet.inbound_connect_timeout and
inbound_connect_timeout_listenername to 0 can stop the ORA-03135
error.
We have a web application with the stack Spring, Hibernate, C3P0, Oracle DB Driver (habing an Oracle DB behind).
From time to time we experience blocking locks over a longer period of time which then get killed on the DB end. (we know this is caused by bad application design and we will fix it, but it's not the point of this quesion).
After the DB session was killed by DB it seems that the connection pool reuses the now broken connection which results in the error:
A PooledConnection that has already signalled a Connection error is still in use!
Another error has occurred [ java.sql.SQLRecoverableException: Closed Connection ] which will not be reported to listeners!
On the DataSource we configured
dataSource.setTestConnectionOnCheckin(true);
dataSource.setTestConnectionOnCheckout(true);
But it did not help. We expected that the connections fail these tests and then get renewed. But this does not happen.
Any hints for us how to recreate the broken connections?
This warning is given when a Connection that is already checked out experiences an Exception that causes c3p0 to treat it as invalid (so it will not be reincorporated back into the pool on close()), but the Connection continues to be used and experiences an Exception again. These are not broken Connections in the pool. They are broken Connections in-use by the application. So testing them on checkout (or checkin) doesn't do anything about them.
To get rid of this, you need to examine the Exception handling within your application code. Are there circumstances where an invalid Connection might have thrown an Exception, but that Exception was caught and the Connection reused?
The warning itself is harmless. It's just saying c3p0 already knows the Connection is bad, it won't emit an event to signal that again.
I`m in the development stage of an app and I don't make many server\cloud sql calls but for some reason I have an average of 400 usage hours a month.
When I look at the cloud sql active connections dashboard I see there is always at least one active connection but in the read\write operations it's usually on 0 besides the occasional small bumps.
I create a new connection each time I make a request to the server\cloud sql and close the connection each time when I return the response.
the connection code is(I followed the guestbook tutorial\example)
Class.forName("com.mysql.jdbc.GoogleDriver");
this.dbUrl = "jdbc:google:mysql://trivia9991:triviadb?user=root";
this.dbConn = DriverManager.getConnection(dbUrl);
the closing connection code is
this.dbConn.close();
How can this keep a connection open at all time?
If the connection close code is actually running this should not be the issue. You should make sure that the connection is closed even if an exception occurs before hand.
It is also possible that a connection you made using the MySQL command line client is still open.
You can examine what connections are open by connecting using the MySQL command line client and running a SHOW PROCESSLIST; statement.
We are using ADO to access Oracle 10g release 2, Oledb provider for Oracle 10g. We are facing some issue with the connection pooling. The database reside on the remote machine and connection pooling is occuring as it should. But if the remote machine goes down for some reason, the connection is returned from the pool and query on that connection fails. When this connection is closed, it is returned back to the pool instead of being invalid. The subsequent connection opening requests are sucessfull but query fails. This is strange behaviour, according to OLEDB specifications, provider must support DBPROP_CONNECTIONSTATUS property, thus in case of invalid connection, it would not be returned back to the pool.
Things get weired when the remote machine comes up. The connections in the pool are still invalid and although the connection opening succeeds, query on the connection fails. Oracle OLEDB is unable to connect to the server anymore and we have to restart our application. Well this is undesired cause our application is a critical application.
Any ideas on how to get over this.
Thanks
Mubashir
If you are doing this programmatically, use a try block, so that if something does happen, it won't fail. With a try block, you can catch an exception and ignore it, so that the errors are shushed.
You could tell the pool to not accept invalid connections, by marking the connection invalid before it is returned to the pool.
Connections are recovered after 10 minutes by default. Time can be set by the registry key SPTimeout under the oledb provider's root key.
Actually the default connection pool timeout is 120 seconds at least for this Oracle 11 32-bit OLEDB installation. You can find the registry settings at:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Oracle\KEY_orac
Where KEY_orac is the KEY_<oracle_home_name>
The key name is ORAMTS_CONN_POOL_TIMEOUT and the default value is 120.
It does not appear that you can set connection pool parameters at the connection string level.
In most connection pool implementation it is possible to check the connection before using it. For example: you define a check query like select * from dual and if you pick up a connection from the pool this query will be executed. If it fails, then the connection will be excluded from the pool and a new one will be opened.