This content has been marked as final. Show 6 replies
Thanks, we will look into that. It does seem to only affect the non DBA users. If I log in as SYS user as SYSDBa I don't notice it. I'll test it will another user as SYSDBA and see if any problems encountered.
What is odd to me is that the 2.x version seems unaffected and there were differences in what was affected betwee 3.0 and 3.1 SQL Developer. Plus, everything worked fine till about 24 hrs and we started having random connect issues with outside connections. We weren't sure if the 2 were related since 1 seems random and the SQL Developer problem can be easily replicated and produced.
We are using JDK 6.31 64 bit along with the 64b version of SQL Developer if that helps any with the debugging
Edited by: ChaosAD on Apr 4, 2012 9:08 PM
Wanted to add what ultimately fixed it for us.
The temp solution that Gary Graham provided, worked in the short term. What ultimately fixed it for us was switching the DB to DEDICATED from SHARED. Once that was done we were able to remove the temp fix, restart Developer and worked as good as new. It also fixed out other random connect problems with outside connections to our DB.
Honestly no clue why it was in Shared mode to begin with.
Thanks for the valuable feedback. You said...
A close read of the full thread I referenced above (both in John's comments and the comments of others) does point to the use of shared connections as a risk factor in triggering this low-level TCP bug. Actually even if the DB is configured for shared connections, a user relying on the SQL Developer connection type=TNS (as opposed to, say, Basic), could override the shared connection usage by specifying SERVER=DEDICATED in his tnsnames.ora file.
What ultimately fixed it for us was switching the DB to DEDICATED from SHARED.
Some other comments...
1. Out of Band break support in JDBC began with the drivers shipped with Oracle 11g (ojdbc5.jar for 126.96.36.199, ojdbc6.jar for 188.8.131.52).
2. SQL Developer 2.1 ships with ojdbc5.jar, whereas the 3.x releases ship with ojdbc6.jar. These jars are used if no Oracle client is present.
3. If the Oracle client's ORACLE_HOME jdbc\lib contains both ojdbc5 and ojdbc6, a 3.x install may incorrectly use ojdbc5.
4. Out of Band break failures are more common on Windows platforms.
5. Out of Band break failures are more common, per the forum posts and bugs I have reviewed, when using ojdbc6.
Presumably there are timing issues when the ratio of connections to shared server processes is too high. If use of DEDICATED is not feasible, possibly lowering that ratio may help.