Re: CDB/PDB and Listener setup?

Thanks Hans. All true. It has happened - we've had hung listeners in the past. Many had issues from running out of windows heap memory (all used the same system account) and we still have some old apps that connect/disconnect on just about every call as well as test connections before using them :( The move to Linux next year should get rid of many of the problems due to windows o/s.

Thanks for the reminder about established connections are not broken during a listener bounce.

On Thu, Jan 26, 2017 at 1:56 PM, Hans Forbrich <fuzzy.graybeard_at_gmail.com> wrote:

> 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>
> 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
>>
>>
>>
>
>
> --
> Sincerely,
>
> WoodyMcKay
>
>
>

-- 
Sincerely,

WoodyMcKay

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