Oracle SQL Developer connection storm at startup

Oracle SQL Developer (tested with version 3.2.20.09) does some unwanted network connection testing against all configured connections (by TNSPING).

We noticed that it causes a kind of unwanted “inverse” connection storm to all configured databases, when we start the SQL Developer. It’s not restoring aborted connections or stuff like that, all was quit before stopping the SQL Dev., and nevertheless each and every configured connection is “tested” at start up.

In my example, it’s doing the following for all configured connections (tested with version 3.2.20.09):

TNS connect:
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ww.xx.yy.zz)(PORT=1521))
(CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))
(SERVICE_NAME=xyz)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))))

and gets back:
(DESCRIPTION=(TMP=)(VSNNUM=186647296)(ERR=12514)(ERROR_STACK=
(ERROR=(CODE=12514)(EMFI=4))))

I’m having multiple problems with this behavior:

  1. It’s useless, since the SQL Dev. does not display any information about reachable/non-reachable databases. I simply can’t see any benefit.
  2. It’s waste of network resources
  3. It’s most unwanted since your network can see what you have configured (for example in a public WLAN, and in worst case a IDS might feel like you are doing something nasty in the (for example, customer’s) network)

Does somebody know why they are doing this, and why are they doing it
THIS very way?

Regards
Martin

EDIT:
Modify your sqldeveloper.conf:
AddVMOption -Dsqldev.tnsping=false
to disable this behavior.




You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

5 Responses to “Oracle SQL Developer connection storm at startup”

  1. usn Says:

    Here a quick answer from the oracle-l mailing list by Jeff D. Smith:

    ==================
    So that was put in to collect ping times for connections, with the
    intent at some point of displaying that visually for users.

    So you could see what databases were ‘far away.’

    Obviously that last bit was never implemented, but we could do it for
    the next release. Any thoughts on whether that would be of use to you or
    your users?

    My thought is that we should collect that on CONNECT time, not for all
    connections defined in the tool at startup time, as you have noticed.

    And since we’re getting ready with a new release, now is a good time to
    address this.

    Jeff
    ==================
    Thread / Source:
    http://www.freelists.org/post/oracle-l/Unwanted-SQL-Developer-inverse-connection-storming

  2. usn Says:

    From the follow-up correspondence I come to the conclusion that the development team is now aware of this issue and may fix it in next or one of the next release(s).

    Enjoy
    Martin

  3. usn Says:

    Oh. it’s fixed:

    > Add this to your sqldeveloper.conf file and it will no longer to the
    > tnsping on startup.
    > AddVMOption -Dsqldev.tnsping=false
    >
    > Also you should know if you do a ‘reconnect’ in SQL Developer we do a
    > TNSPing first to see if it’s even worth bothering to try to make the
    > connection.

    Thanks to Jeff Smith!

  4. Mane Says:

    the according thread on oracle-l (http://www.freelists.org/post/oracle-l/Unwanted-SQL-Developer-inverse-connection-storming) made my day. Thanks :-)

  5. Moriah Riley Says:

    Hi im Moriah Oracle consultant. I was just browsing blogs there I found your blog is interesting.. thanks for posting… keep on posting

Leave a Reply