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: <https://twitter.com/NenadNoveljic> @NenadNoveljic
From: 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> 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> 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.
