Re: RE: TNSNAMES.ORA QUEUESIZE?
Date: Thu, 27 Jan 2011 16:44:22 +0800
Message-ID: <AANLkTimq8xbYOFzj-zO9Dzh_s=GOnM4J3QZwhmHWReGN_at_mail.gmail.com>
Yikes. As you note, the listener could crash. Also behaviour could change in versions/patchsets.
Wonder old this BUG is.
Hemant K Chitale
http://hemantoracledba.blogspot.com
sent from my smartphone
On Jan 27, 2011 3:56 AM, "Rich Jesse" <rjoralist2_at_society.servebeer.com> wrote:
Hey Larry,
> Guess I wasn't clear. Got a half dozen replies on how to use it in
listener
> .ora
Sorry! That's what I get for replying to a reply... :(
Curiosity got the best of me, so I did some testing (using 10.1.0.5 client against same DB version). I added a connection to my local TNSNAMES.ORA file:
OTNSTEST=
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=192.168.101.101)
(PORT=1521)
)
(CONNECT_DATA=
(SERVICE=mytestdb)
)
)
tnsping and connections work fine, as expected. Now we add:
(QUEUESIZE=32) ...immediately following the PORT spec. Again, tnsping and connections work fine. tnsping even shows the QUEUESIZE that was specified. Hmmm....let's get creative. I added this line after the errant QUEUESIZE:
(SB_XLV_WINNER=GBP) Whatdya know? It worked! Starting up a client-side trace via SQLNET.ORA, I see the entries there, but they do not show up on the server listener's log.
I can glean from this overly-quaint test that unknown parameters are ignored. It could also cause the listener to crash for all I know. But this exercise suggests that the errant specs are most likely just silently ignored.
You can certainly repeat this exercise to see for yourself, perhaps expanding on the tracing, especially on the server side to determine exactly what's happening and/or not happening.
Enjoy!
Rich
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Thu Jan 27 2011 - 02:44:22 CST