One further thought: the 'connection string' the client enters and the
connection string seen by the listener may not be the same thing.
Unless I am totaly mistaken, assuming TCP, the TNSNAMES *alias* that
many people use as the client-supplied connection string is translated
to a host:port/service form before it even hits the network (with the
exception of going to LDAP to decode the alias). Basically, no matter
what the client supplies, with a TCP connection the listener is going to
see a simple resolved request.
I have not validated this, but it should be easy enough to do with a
decent wireshark (or equiv) session.
/Hans
On 2017-06-12 6:46 AM, Mark W. Farnham wrote:
The evolution of this thread from “how can you figure out the connection string used from something like sys_context” into suggestions of the best possible means to make connections easy has been interesting.
I think the OP’s question was answered: There is no simple place in the database to look up what connection string was used.
Comprehensive log mining of the listener logs might do the trick, but that is certainly not a simple look up. Hmm. This might be something useful for whatever they currently call Enterprise Manager to do. It would be useful to be able to put in a sid and a serial# as a parameter to an API and be able to get back the actual connection string used, regardless of how connection opportunities to the database are served up.
A decent case can be made for not exposing the database to connections except by via a security layer, but that is of course at odds with making ease of access a feature. And that’s not this thread either. Wow. It certainly is easy to drift from actual questions to musing on network topics. And a beautiful thread it been, chock full of options and opportunities.
If I missed a note giving an easier way of knowing the connection string used than recording the actual connection string used from listener logs constantly and recording those connections to the sid, serial# created, please highlight that back to me.
mwf
*From:*oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Noveljic Nenad
*Sent:* Monday, June 12, 2017 1:32 AM
*To:* 'andrew.kerber@xxxxxxxxx'; Norman Dunbar
*Cc:* Mladen Gogala; ORACLE-L
*Subject:* RE: sys_context to get connection string?
Andrew,
Why don’t you use LDAP servers for the names resolution? It is the real centralized solution. Not only does it save you of trouble with deployment of tnsnames.ora, but any change to a connection string is instantaneously visible to all of the database clients.
If Active Directory is not a viable solution in your organization, you can setup your own Oracle Directory Server (ODS) for this purpose. For me, ODS is one of the key enabler of the agility in database provisioning.
Nenad
Home Page: http://nenadnoveljic.com/blog/
Twitter: @NenadNoveljic <https://twitter.com/NenadNoveljic>
*From:*oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Andrew Kerber
*Sent:* Sonntag, 11. Juni 2017 23:58
*To:* Norman Dunbar
*Cc:* Mladen Gogala; ORACLE-L
*Subject:* Re: sys_context to get connection string?
And even assuming they use dns, it only 'centralizes' the host name. I prefer to centralize the database connection definitions. With a single tns, i can simply tell users that if they dont use the centralized tnsnames.ora file I will decline they are entirely on their own in defining their connections from the desktop.
On another subject, has anyone else noticed that dgmgrl can be inconsistent as to whether it is using the tnsnames.ora file from the database home or the asm home? It might just be with the ODA (unlikely) but working with one recently I found occasions when it used the db home tnsnames.ora and other occasions where it uses the asm home tnsnames.ora.
On Sun, Jun 11, 2017 at 4:31 PM, Norman Dunbar <oracle@xxxxxxxxxxxxxxx <mailto:oracle@xxxxxxxxxxxxxxx>> wrote:
Does it Malden? I have a funny feeling that the host part of an ezconnect string is permitted to be an IP address. No DNS required. :-(
Cheers,
Norm.
On 11 June 2017 22:23:19 BST, Mladen Gogala <gogala.mladen@xxxxxxxxx <mailto:gogala.mladen@xxxxxxxxx>> wrote:
On 06/11/2017 05:22 PM, Andrew Kerber wrote:
You lost me completely. How does ezconnect centralize anything? if anything it decentralizes everything.
EZCONNECT relies on DNS, which is usually centralized.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
Important Notice
This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system.
E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of the Vontobel Group and its affiliates for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.
