Re: CDB/PDB and Listener setup?

Bouncing a listener only impacts connection *attempts*. A fully automated bounce would stop people from *asking* for a new connection for, say, 1/50th of a second? This might impact a badly written application that gets a new connection for each data lookup, but that would have other serious consequences.

Remember that the listener is no longer involved once the connection is established. Bouncing a listener does absolutely nothing to those established connections.

I find it fairly rare to needc to bounce a listener anyway. But ... to each his own.

/Hans

On 2017-01-26 11:36 AM, Woody McKay wrote:
> Thanks Hans.
>
> All connections would be via JDBC from applications. Ok, one or more
> listeners as needed and jdbc thin with host:port/service. Each PDB
> defaults with a service of the same name/domain.
>
> Should be easy enough. Hosting prefers one listener per customer so
> that a needed bounce only impacts that one customer.
>
> Thanks...
>
>
> On Thu, Jan 26, 2017 at 1:23 PM, Hans Forbrich
> <fuzzy.graybeard_at_gmail.com <mailto:fuzzy.graybeard_at_gmail.com>> wrote:
>
> When you add a PDB to a container instance, the PDB's service is
> automatically registered based on the pdb name and the domain.
> You can optionally add one or more services that direct to the PDB
> if needed, for example, for resource management.
>
> The big question is "How do you connect to the environment?"
>
> - if you use TNSNAMES.ORA ('_at_tnsentry'), then you pretty much want
> to manage te TNSNAMES.ORA manually. The service is not
> automatically added; This needs to be managed at each
> TNSNAMES.ORA location. Consider centralizing using LDAP ...
>
> - if you use "CONNECT to root and 'alter session set
> container={pdb}" then you might simply ignore tnsnames.ora all
> together.
>
> - similarly, if you use EZConnect or JDBC:thin
> ("_at_//host:port/service") then ignire TNSNAMES.ora
>
> - I've noticed a lot of people still try ("_at_//host:port:sid")
> which obviously does not work (a PDB is NOT an instance) unless
> you monkey with the service==sid setting. While possible, it
> becomes one more workaround thing to manage, so I'd avoid it and
> prefer to use the correct .../service syntax.
>
> As for listener, I'd use one listener properly configured, unless
> multiples are absolutly required due to load or setting differences.
>
> /Hans
> The above being my opinion, and not an official statement by my
> employer.
>
> On 2017-01-26 11:01 AM, Woody McKay wrote:
>
> Hi,
>
> Is anyone using multi-tenant in production or about to? What
> have you found to be the best listener setup?
>
> I'm doing R&D using many PDB's with one per customer
> district. Each PDB would have its own service, but I'm not
> exactly sure on how listener.ora and/or tnsnames.ora entries
> should look like. Each PDB would have the same schema, but
> unique with customer data. The connection schema name would be
> the same in each PDB.
>
> I've not found much documentation discussing this...
>
> --
> http://www.freelists.org/webpage/oracle-l
> <http://www.freelists.org/webpage/oracle-l>
>
>
>
>
>
> --
> Sincerely,
>
> WoodyMcKay

--
http://www.freelists.org/webpage/oracle-l